Writing
Free essays on mobile interviews and senior engineering.
Interviews, architecture, leadership and AI, written from the hiring side. Most essays have an audio edition, so you can listen instead of reading.
All 84 essays
Reading the answer is not the same as giving it.
Most interview preparation stops at recognition. Loops score what you can produce once the question changes. Why I built Interview Runtime, and what it asks you to do.
Featured essay · Interviews
Career strategy
How I tried to clean up my LinkedIn and doubled the problem
I posted a fake dream job to thin out the wrong connections. Requests went up, CVs arrived, and people tagged friends under the post explaining there was no job.
7 min read
The engineer nobody chases
The most common reason capable engineers stall has nothing to do with code. It is how much coordination work lands on other people after you have finished.
8 min read
The two documents that decide your career are written by other people
One gets written after your interview. The other gets written after your offer. You never see either, and that is exactly why they cost you money.
4 min read
Resume bullets for senior iOS engineers
How to turn mobile engineering work into evidence of scope, judgment and impact without exaggerating.
3 min read
LinkedIn profile optimization for software engineers
An optimized profile is one a recruiter can find and a hiring manager can place at the right level in under a minute. Most engineer profiles fail the second test, not the first.
9 min read
Software engineer LinkedIn headline examples
A headline has two jobs: come back in a recruiter's search and place you at the right level in one line. These examples are organised by level and platform, and each one says why it works.
7 min read
Staff software engineer resume
Staff is not Senior with more technologies. A Staff resume has to show decisions that changed how other teams work, and most Staff candidates bury exactly that under a list of features.
6 min read
Principal software engineer resume
There is no universal definition of Principal. There is a common thread: your decisions set the technical direction for more than one team, and the resume has to prove that without a list of titles doing the work.
5 min read
Personal branding for software engineers
An engineer's brand is not a voice or a posting schedule. It is what a stranger can verify about your judgment before they talk to you. Most engineers have the work and none of the evidence.
4 min read
Software engineer portfolio website
A portfolio website does one job: let a stranger verify your work in a minute. Most engineer portfolios are built to impress a designer and forget to prove anything to an engineer.
5 min read
Interviews
Senior Android interview questions: the 5 follow‑ups that decide the loop
Your first answer rarely decides a senior Android interview. The follow-up does. Five follow-ups, the answer that loses the point, the one that earns it, and what to say when you wobble.
7 min read
Senior iOS interview questions: the 5 follow‑ups that decide the loop
Your first answer rarely decides a senior iOS interview. The follow-up does. Five follow-ups, the answer that loses the point, the one that earns it, and what to say when you wobble.
7 min read
iOS coding interview: what the live round actually tests
The iOS coding interview is rarely a puzzle. It is a small app task under a clock, and the score comes from how you build it, not whether it compiles on the first try. The five common tasks, what gets scored in each, and what to say when it breaks.
10 min read
Kotlin coroutines interview questions that senior Android loops ask
Ten coroutines and Flow questions senior Android loops ask, what each one tests, the follow-up that decides the score, and four short bugs worth practising until you can fix them out loud.
9 min read
The STAR method for senior mobile engineers: what the interviewer scores after the R
Every senior mobile candidate knows STAR. Most still give answers that cannot be scored, because the situation is long, the action is "we" and the result is "it shipped". A weak and a senior answer to the same migration story, the follow-ups that come next, and the "we" versus "I" trap, from the hiring side.
11 min read
Merge intervals in a mobile coding interview: the calendar version
Merge intervals is the algorithm question that keeps arriving dressed as a calendar. A worked answer from the hiring side: what to ask first, the brute force, the insight, the code in Swift and Kotlin, and the follow-ups that separate levels.
12 min read
Tell me about a production incident you owned: the senior mobile answer, scored
"Tell me about the worst bug you shipped" is not a debugging question. It is scored on what you did between the first signal and the last change, on a platform where you cannot take a binary back. The structure, the follow-ups and the recovery lines, from the hiring side.
14 min read
Tech lead interview questions: what each one scores, from the hiring side
Most lists of tech lead interview questions stop at the question. The loop does not. Eleven questions a tech lead round actually asks, what each one is scoring, the weak answer and the strong one side by side, and the follow-up that checks whether the strong one was yours.
20 min read
Tell me about a time you influenced a decision without authority: the senior and staff answer, scored
"Tell me about a time you influenced a decision without authority" is not a persuasion question. It is scored on whether you found the decision under the problem, moved it before the room and kept it closed afterwards. The structure, the follow-ups and the recovery lines, from the hiring side.
14 min read
You have 40 interview tabs open and still don't know what to study.
Interview preparation gets worse when everything looks important. The closer the interview gets, the more your calendar should force you to cut.
5 min read
You watched the solution. Then you opened an empty editor.
Watching someone code can make you feel ready. Live coding exposes the gap between recognition, retrieval, and making your judgment visible under pressure.
6 min read
AI can pass the assessment. You still have to survive the interview.
AI can produce a polished assessment. The harder part starts when a Senior engineer asks why the code exists and whether you own the decisions behind it.
6 min read
A correct Android answer can still fail the interview
Two answers to the same Android question, both correct, scored completely differently. What senior loops are measuring once you clear the knowledge bar.
7 min read
Senior iOS interviews are about risk
The strongest candidates do not just answer the question. They show how they think about production risk, tradeoffs and recovery.
4 min read
A modern Swift concurrency interview map
A senior interview map for async/await, actors, cancellation, task lifetime, Sendable and the bugs hidden around awaits.
8 min read
What interviewers score while you share your screen
The code is only one part of a live round. The interviewer is also recording how you frame, choose, verify and recover while the screen is shared.
5 min read
React Native interviews happen at the boundary
The framework answer is only the surface. Senior judgment appears where JavaScript, native work and product constraints meet.
7 min read
Test automation is not the senior SDET answer
The tool is not the decision. Senior test engineering begins with what failure costs, what evidence is trustworthy and who owns the response.
2 min read
Mobile architecture
iOS system design interview: a worked answer from the hiring side
The round is not scored on the diagram. It is scored on the decisions. A worked answer for an offline-capable messaging app on iOS, minute by minute, with the follow-ups interviewers use and how the Android answer differs.
11 min read
Android system design interview: a worked answer from the hiring side
On Android the round is decided by one question: what does the green check promise when the process dies a second later? A worked answer for an offline field inspection app, minute by minute, with the follow-ups interviewers use.
12 min read
Design Uber on iOS: a system design interview answer from the hiring side
"Design Uber" is not scored on the map. It is scored on one question: what does the driver's pin mean when it is 21 seconds old? A worked iOS answer, minute by minute, with the follow-ups interviewers use.
10 min read
Offline sync system design interview: what happens when two devices disagree
"Design offline sync for a notes app" is decided by one question: two devices edited the same thing while apart, and both synced. Which one wins, and who decided? A worked answer from the hiring side, for iOS and Android alike.
9 min read
SwiftUI state management best practices, from production
Most SwiftUI state bugs are not wrapper bugs. They are ownership bugs: a value with two owners, a binding nobody needed, a store everything reads. The wrappers, the Observation framework and the environment, explained by who owns what.
12 min read
Short video feed system design interview: a vertical video feed, from the hiring side
"Design a short video feed" sounds like a ranking question. On mobile it is a resource question: how many videos you prepare, how many players exist, what the cache throws away, and what the phone does when it gets hot. A worked answer from the hiring side.
13 min read
Image loading system design interview: a scrolling feed, answered from the hiring side
"Design the image loading for a scrolling feed" sounds like a library question. It is a memory question: what an image costs once it is decoded, who still wants it, and what you give back when the system asks. A worked answer from the hiring side, for iOS and Android.
12 min read
Eventual consistency in mobile apps, per field
"The app is eventually consistent" describes no app. Each field gets its own choice: strong, provisional, eventual or human. Then come the parts users notice: what the screen shows while data converges, how an optimistic change rolls back, and which edit wins. Last write wins, hybrid logical clocks and CRDTs, with what each costs, for iOS and Android.
15 min read
TCA vs MVVM in SwiftUI: who owns the state
A team decision, not a style preference. Since Observation, both sides render efficiently; what still separates TCA and MVVM is who may mutate state, how effects are represented, what a test has to prove, and what the team pays to learn, upgrade and one day leave the library.
14 min read
ADR examples for mobile teams, with a template
Most ADR templates were written for servers, where a bad decision can be redeployed away. Mobile decisions live on in installed builds. A copyable ADR template with a versions-in-the-wild section, three complete mobile examples, revisit triggers that name evidence, where the records live, and how they keep a decision closed.
14 min read
Kotlin Multiplatform in an existing app
In an app that already has two good native codebases, Kotlin Multiplatform is not a framework choice. It is a boundary: which rules become one implementation, who owns them on iOS, and what evidence stops the expansion.
14 min read
Best mobile architecture books for senior engineers
Most lists of the best software architecture books are written for backend systems. A mobile app adds clients you cannot recall, versions that stay installed for years and releases that wait for review. A reading list grouped by the problem you have, with what each book is for, where it stops on mobile, and which ones are mine.
11 min read
Background sync on iOS and Android: what you can promise
A product manager asks for sync every fifteen minutes in the background. Neither platform will give it to you, and the honest answer is not "we can't". It is a different promise: work the user did is never lost, data is current when the app opens, and the screen says how old it is. What iOS and Android actually guarantee, checked against their documentation, and a design that survives process death and deferral.
14 min read
Do you need a BFF for your mobile app?
A BFF is usually sold as a way to turn many calls per screen into one. The harder half is organizational: someone has to own and run it, and every app version you shipped pins its contract. When a backend for frontend pays off, who owns it, how to change it safely, and when not to build one.
15 min read
Server‑driven UI on mobile: when it pays off
Server-driven UI does not remove the release problem. It moves it into a schema that every supported app version has to keep rendering. What it buys, what it costs, where it fits, and the rules that keep it from turning into a language.
15 min read
UIKit to SwiftUI migration strategy for a large app
Most SwiftUI migrations measure progress in screens converted. The ones that hold measure it in boundaries: a stable entry contract, one owner for state, one authority for navigation, a rollback that is a flag and not a revert. A strategy for a large UIKit app that keeps shipping.
12 min read
Mobile release train: cut‑off, hotfix and go/no‑go
A mobile release train is a schedule plus a set of decision rights: who cuts, who may board late, who calls go or no-go, who can stop it at night. How to set the cadence, run the cut-off, ship a hotfix while a train is in flight, and measure the train itself.
13 min read
How to choose a sync solution for a mobile app
Most sync decisions start with a comparison table of products. The table is the last step. Before it come three decisions no product makes for you: what the app promises offline, who owns the truth for each kind of data, and which conflicts a machine may settle. A vendor-neutral guide for iOS and Android teams, with a build-or-adopt rule.
13 min read
Rewrite or refactor a mobile app? Write the kill criteria first
"We should rewrite the app" is usually said in a planning meeting by someone who is tired of the old code, and decided by someone who cannot see it. How to make the case either way: what a rewrite hides, which unit you are really changing, the evidence to gather first, the conditions that stop the work, and how to put it to a manager who wants a clean slate.
13 min read
Phased release vs staged rollout: what halting does
Apple's phased release and Google Play's staged rollout both stop the spread of a build, and neither takes it back. What each store documents, what pausing and halting reach, why a crash-free number at 1 percent proves little, and how to write the halt rule before day one.
14 min read
How long to support old mobile app versions
The support window for old app versions is not a number you copy from another company. It is read off the tail of your own adoption curve, written down as two floors, and owned by a named person. Plus what a forced update cannot fix.
14 min read
Mobile feature flag cleanup: the flag outlives the release that removed it
On a server, cleaning up a feature flag is one motion. On a phone it is three, on three clocks, and the last one belongs to the installed fleet. Expiry by job, the order that survives old binaries, and how to price the flags you already have.
11 min read
When to modularize a mobile app (and when not to)
Modularization is usually sold as the cure for a slow build. A module is a rule the team pays for every week, in build configuration, review, navigation and onboarding. When a boundary earns that cost, when it does not, and how to tell you have gone too far, for iOS and Android.
10 min read
Mobile app kill switch: how to design one
A remote kill switch is the one control you still hold after a binary is installed. How to design it so it works on the day you need it: what off means, safe defaults, caching, independence, reach, audit and drills.
12 min read
MVVM, MVI, TCA, Redux or VIPER? The senior answer names the pressure first
"Which architecture would you choose?" sounds like a pattern quiz. It is scored on whether you name the pressure before the pattern, and whether you know what each pattern costs to leave. A worked answer from the hiring side, for iOS and Android.
10 min read
Mobile architecture migration interview: change the app without stopping the release train
"How would you migrate this app's architecture without stopping the release train?" is a question about the months between two diagrams, not about the destination. A worked answer from the hiring side, for iOS and Android alike.
12 min read
Swift 6 rejected the race. ARC stayed atomic.
Swift 6 can prove that some code is safe from data races. That does not mean reference counting suddenly becomes non-atomic.
9 min read
You cancelled the caller. Why is the shared Task still running?
Swift cancellation is cooperative. Cancelling the task that is waiting does not automatically cancel the separate task it is waiting on.
5 min read
An actor protects state. It does not own every retain and release.
Actor isolation is a concurrency guarantee. ARC is a lifetime mechanism. Treating one as a complete proof about the other is where the mental model starts to drift.
6 min read
Your SwiftUI app works. Production is where it starts lying to you.
Three failures that appear after the happy path: stale results, slow "lazy" lists, and state ownership that no longer scales.
10 min read
What minimumScaleFactor trades away in SwiftUI
I ran into a typography inconsistency in a production SwiftUI interface, then reduced it to a reproducible case to understand what minimumScaleFactor was trading away.
10 min read
Mobile system design is not backend system design
Why offline, device constraints, sync, app lifecycle and platform boundaries change the interview and the architecture.
5 min read
Why iOS apps feel slow even when the API is fast
A practical look at the client-side bottlenecks that make mobile apps feel slow after the backend has already done its job.
9 min read
Swift concurrency bugs that pass code review
Four Swift concurrency bugs that survive code review at good companies: actor reentrancy, leaked tasks, ignored cancellation, and the onAppear trap. With fixes.
7 min read
How to review a mobile architecture proposal
A practical review framework for mobile architecture decisions: constraints, reversibility, ownership, migration and production proof.
3 min read
SwiftUI vs UIKit: architecture is state ownership
Why production SwiftUI architecture is less about folder names and more about ownership, identity, effects and boundaries.
4 min read
Security requirements that cannot be tested are not finished
A security requirement becomes useful when a team can observe the behavior, test the boundary and know who owns failure.
2 min read
Staff engineering
Best books for tech leads and staff engineers
Most lists of the best books for tech leads and staff engineers rank the same titles and stop. This one groups eleven books by the problem you have this quarter: the role is unclear, you are choosing a track, you are right and nothing moves, teams keep colliding, or the hard part is the system itself. For each, who it is for and what it leaves out. Three are mine, and I say so where they appear.
13 min read
Tech debt business case: a one‑page template, and how to get it funded
"We need a sprint for tech debt" is usually right about the code and usually unfunded. A debt case gets funded when it names the decision and the one person who owns the capacity, prices the debt as interest and principal in units your tools already record, and speaks in what that person is scored on. A one-page template you can copy, a filled example, and what to do with a partial yes or a no.
18 min read
A project status update template for tech leads that cannot hide red
Most status updates report effort and a color, and the color is a mood. A status update template for tech leads where green has to be earned: status definitions tied to evidence, an end-to-end path test behind every green, four lines that carry the week, and how to report bad news while it is still a planning input.
14 min read
Staff engineer vs senior engineer: what changes in scope, decisions and evidence
Most comparisons say staff means bigger scope and more influence. From the hiring side the difference is narrower and easier to test: a senior engineer moves the problem, a staff engineer moves the decision around it. What changes in scope, decisions, influence and evidence, how interview loops and promotion committees read it, and the senior-plus trap.
15 min read
Staff engineer 30/60/90 day plan: map the decisions, then move one
The usual 30/60/90 template plans activities. A staff role is judged on decisions. A week-by-week plan for a new staff engineer: map the hidden decisions and power, pick one stuck outcome, run Surface, Shift and Secure on it, and leave evidence a reviewer can open.
13 min read
A technical design doc template for staff engineers, and when an ADR is enough
Most design docs describe a solution well and still fail, because nobody named who decides, the objection arrived in the meeting, and nothing said what would reopen the call. A complete design doc template you can copy, what each section is for, how a staff engineer gets it approved, and when a short ADR does the job instead.
16 min read
Engineering manager vs tech lead: who owns what, and what each is judged on
The tech lead owns decisions about the system. The engineering manager owns decisions about people and capacity. Most comparisons stop there. This one, from the hiring side, adds what each role is evaluated on, the exact place a tech lead's authority stops, how to choose between the two paths, and what interviewers ask each.
15 min read
From senior developer to tech lead: what changes when the outcome is yours and the authority is not
The transition from senior developer to tech lead is not more of the same work. Your name goes on an outcome that depends on teams you do not manage, and being right stops being enough. What changes, a first 90 days built from that, the tech lead responsibilities that are actually evaluated, and the mistakes that keep strong engineers stuck.
16 min read
Disagree and commit: what engineers owe after the call
Disagree and commit is usually taught as a meeting habit. For engineers, the commit half happens later, in pull requests, review comments and status reports. When to disagree, how to record the disagreement, what commit obliges you to do, the reopen criteria that keep the door open, and the risks you should never commit to.
19 min read
Staff engineer promotion packet: the evidence a calibration committee needs
The review that decides your level is mostly over before you walk into it. What a calibration committee can actually read, the evidence ledger that turns staff work into proof while it is happening, and the one field that keeps a promotion packet from reading as inflation.
13 min read
How to say no to a project as a tech lead, with the exact words
"There is no way we hit that date" is usually true, and it usually fails. A tech lead rarely owns the decision to drop a project or move a date. What you own is making the trade visible: whose call it is, the promise hiding inside the date, three options with one recommended, and the words that hand the choice back.
13 min read
How to escalate as a tech lead without starting a status war
Most escalations that go wrong were right to happen and wrong in the way they were fired: too late, too loud, to an audience instead of an owner. How to escalate as a tech lead: find the decision first, name the threshold before you need it, and send a brief the owner can decide without reconstructing the conflict.
17 min read
Green on the dashboard, red in reality: what a tech lead does, and what the interviewer listens for
Every team is green, and the feature has never once worked end to end. False green is rarely a lie; it is the truth from the wrong instrument. What a tech lead changes, the sentence that goes to the sponsor, and what an interviewer listens for when they ask how you know a project is on track.
12 min read
Staff iOS engineer is not senior plus
The staff role is not just harder tickets. It is scope, leverage, decision quality and making other engineers more effective.
3 min read
Tech lead code review is a system
Good code review is not comment volume. It is a system for quality, ownership, mentoring and risk control.
2 min read
Staff engineers change the decisions a team can make
The platform changes. The staff transition does not: your work must improve decisions beyond the feature and beyond your own presence.
2 min read
Independent consulting
Related resources
Free resources the essays lean on
Checklist
Developer career bottleneck checklist
A short diagnostic for software engineers. Find whether visibility, interviews, system design, scope or leadership is the real thing holding you back, then take the first action that fixes it.
Answer card
Senior iOS interview answer card
A speakable answer format for senior iOS questions: the first sentence, the production answer, the trap, the pushback and the recovery line.
Checklist
Swift concurrency interview checklist
A senior-level Swift concurrency audit for cancellation, task ownership, actor reentrancy, MainActor boundaries, Sendable and flaky async tests.
FAQ
About the writing
What is the Salari writing section?
Field notes on interviewing, mobile architecture, staff engineering, independent consulting and AI-era engineering, the working notes behind the books.
Who writes these essays?
Mike Salari, a staff mobile engineer and mobile architect, drawing on real production work and 500+ technical interviews from the hiring side.
Are the essays iOS-specific?
Many examples are iOS, but topics like system design, code review, staff scope and positioning apply across mobile and senior software roles.
How is the writing organized?
Into six sections: Career strategy, Interviews, Mobile architecture, Staff engineering, Independent consulting and AI-era engineering.
Do the essays connect to the books?
Yes. Most books start here as field notes, then grow into chapters once an idea proves itself in real interviews, reviews and production systems.
What is mobile system design?
Designing the whole system around a mobile app: offline behavior, sync, caching, backend contracts, performance and failure modes, not just the client code.
How is staff engineering different from senior engineering?
Staff is about scope, leverage and decision quality, making other engineers more effective and owning ambiguous problems, not just handling harder tickets.
Is the writing free to read?
Yes. Every article is free.
