A 14-day prep plan for a senior iOS or Android interview

A 14-day interview plan for a senior iOS or Android loop should spend almost no time collecting answers. You already know most of them. What loses the point at this level is the second question: the follow-up where the interviewer changes one fact and watches whether your reasoning moves with it. Correct answers are the entry fee. The score is how you reason under pushback, and two weeks is enough to train that if you spend them in the right order.

I have run more than 500 technical interviews from the hiring side, mostly for senior and staff mobile roles, and I have written "no hire" on candidates who knew more facts than I did. This is the plan I would give a friend with a real loop on the calendar.

Why the order of your prep matters more than the hours

Most engineers prepare by reading. They open a list of questions, read the answers, nod, and feel ready. Reading produces recognition, and recognition feels like knowledge until someone asks you to produce the answer out loud with no page in front of you. The room tests production, not recognition.

So the plan runs in a fixed order: measure first, repair second, rehearse under changed constraints third, then test the whole thing in a mock loop while there is still time to fix what breaks. Every block exists because the one before it tells you where to spend the next.

Day 1: the cold diagnostic

Before you read anything, pick five questions that match the rounds in your loop. One platform fundamentals question, one concurrency question, one architecture question, one system design prompt and one behavioral question. Set a timer for each. Answer out loud, alone, as if the interviewer were across the table. Then write down what you said, not what you wish you had said.

Now read your five written answers as an interviewer would. For each one, ask a single question: where would I push? On a concurrency answer it is often cancellation, or what happens to the task when the screen goes away. On system design it is usually the moment the data stops being fresh. On behavioral it is almost always the number: what changed, by how much, and how you know.

Circle the one gap that would cost you the point. Not five gaps. One. That gap decides where days 2 to 9 spend the most time. Engineers who skip the diagnostic tend to spend the whole two weeks on their strongest round, because the strongest round is the most pleasant one to study.

Days 2 to 9: repair targets by round

Give each round in your loop a day or a half day, and give the round with the circled gap two. The target for each round is not coverage. It is three or four answers you can produce cold, each with the follow-up already thought through.

1. Day 2, platform fundamentals. View lifecycle, memory ownership, what the system does to your app in the background. On iOS: retain cycles in closures, what @MainActor promises and what it does not. On Android: process death, configuration change, what survives in SavedStateHandle. The follow-up here is usually "and when the process is killed?"
2. Day 3, concurrency. Cancellation, structured scope, shared mutable state, and what runs on the main thread. Write down the failure mode for each answer, not just the happy path. The Swift concurrency questions where senior answers break and their Kotlin coroutines twin are a good source of follow-ups.
3. Day 4, architecture. Pick one real codebase you worked on and explain its module boundaries, who owned what, and one boundary you would move today. Interviewers score the reason you would move it.
4. Days 5 and 6, system design. One mobile design end to end per day: a feed with offline reads, a sync engine, an upload queue. For each, name the one decision you would defend and the metric you would watch after shipping.
5. Day 7, coding. Not new problems. Redo two you have solved before, out loud, naming complexity and edge cases as you go. The coding round at senior level is mostly pass or fail, and it fails on silence more than on bugs.
6. Days 8 and 9, behavioral, plus the circled gap. Build your stories (below), and spend the rest on whichever round the diagnostic flagged.

If your loop has no separate architecture round, fold day 4 into system design. If it has two coding rounds, give coding a second day. The structure bends to the loop you actually have, which is why you ask the recruiter for the round list on day 1.

What to say out loud and what to write

Say every answer out loud. Write only three things: the opening sentence of each answer, the trade-off you will name, and the follow-up you expect. Full written answers turn into scripts, and scripts break the moment the interviewer changes the question. A one-line opener and a named trade-off survive a changed fact. A memorized paragraph does not.

Rehearse with a changed constraint

Every answer you repair gets rehearsed twice. First as asked. Then someone changes one fact, and you answer again. The second answer is the one the loop scores. In debriefs, the line that moves a packet is rarely "knew the answer". It is "adjusted cleanly when I changed the constraint" or "started over and lost the thread".

Useful constraint changes for mobile loops are small and specific. The device is offline for a week. The list is 50,000 rows. The user signs out mid-upload. The app is killed during a migration. The team that owns the API ships a breaking change on Friday. You do not need a partner for all of these; you can write ten on cards and draw one after each answer. A person is better, because a person picks the one you did not expect.

How to use a colleague for annotated mocks

A colleague does not need to be a mobile expert to run a useful mock. Give them the question, the change you want them to make halfway through, and a single job: write down the exact sentence where your answer got vague. Not a score. Not general feedback. The sentence. That annotation is worth more than an hour of reading, because it is the sentence an interviewer would quote in the debrief.

Two is a sensible number. The first shows you the gap. The second, a few days later, shows whether the repair held.

Behavioral stories with numbers you can defend

Prepare two or three stories, not ten. Each story needs a scope (what you owned, and how many people or screens it touched), a trade-off (what you gave up, and why), and a result with a number. The number has to survive a second question. If you say crash-free sessions went from 99.2% to 99.7%, expect "measured how, over what period, and what else shipped that month?" If you cannot answer that, pick a smaller number you can.

The same two or three stories can cover most behavioral prompts: conflict, failure, influence without authority, a decision you would reverse. Write one line for each prompt that says which story you will use and which part of it you will lead with.

What not to do in a 14-day interview plan

• Do not read 300 answers. Reading an answer is not the same as producing it, and the loop only asks you to produce.
• Do not collect questions. A bigger list feels like progress. It is inventory. Ten questions answered twice under changed constraints beat a hundred read once.
• Do not rewrite your notes. Reformatting notes is comfortable work that trains nothing the room scores.
• Do not rehearse only your strongest round. It is the most pleasant one to practice, which is why the diagnostic comes first.
• Do not memorize full scripts. A script breaks on the first changed fact, and interviewers change facts on purpose.

Days 10 to 14: the full mock loop, then the weakest round

On day 10 or 11, run a full mock loop in one sitting, in the same order and roughly the same length as the real one. Four or five rounds back to back is tiring in a way single practice sessions are not, and the fatigue is part of the test. Candidates who are sharp in round one and loose by round four are common, and the debrief sees round four too.

Afterward, rank the rounds from weakest to strongest. Days 12 and 13 go to the weakest round only: redo its answers out loud with changed constraints, and nothing else. Day 14, the day before, is light. Reread your one-line openers and your story index. Do not start a new topic. A new topic the night before replaces a settled answer with an unsettled one.

The morning-of checklist for a mobile loop

• Your round list, in order, with the name of each interviewer if the recruiter shared it.
• One opener sentence per round you expect, and the trade-off you plan to name in system design.
• Your story index: which of your two or three stories answers which prompt, and the number in each.
• For a remote loop: the shared editor or whiteboard tool opened once, your IDE closed, notifications off, a second screen with nothing on it.
• For a system design round: a sentence ready for when you need to ask about scale, platforms and offline requirements before drawing anything.
• One line to say when you do not know: what you would check, and how. "I do not know" followed by a method scores better than a guess.

If the loop is in 7 days or 30 days

Seven days. Keep the diagnostic on day 1; it matters more when time is short, not less. Compress repairs into days 2 to 4, spending two of those on the circled gap and one on behavioral stories. Run a shortened mock loop on day 5 covering only the two rounds you fear most. Day 6 goes to the weakest of those, day 7 stays light. You will skip rounds you are already solid in, and that is the point.

Thirty days. Run the diagnostic twice: on day 1 and again on day 15 with five new questions, so you see whether the repairs generalized. Give each round two or three days, run one mock loop around day 14 and a second around day 25, and add a changed-constraint session with a colleague every week. The extra time goes to depth under pushback, not to more topics. Senior and staff mobile roles at large US tech companies commonly pay $300k to $400k in total compensation, so a month of focused work is easy to justify. A month of reading is not.

Where Interview Runtime fits

Interview Runtime's Guided Practice runs this loop for you. It starts with a diagnostic, then builds a 7, 14 or 30-day route from what it finds. You answer first, see the one gap that would cost the point, and answer again when one fact changes. It does not replace a colleague's annotated mock; it gives you the other twenty rehearsals. It is available as iOS Interview Training and Android Interview Training, and you can read a free sample first: the iOS sample and the Android sample.

If you want to see how that second question gets scored in the room, read how the follow-up decides senior mobile offers.

© 2026 Mike Salari, Interview Runtime. All rights reserved. Quoting a short excerpt with a link to this page is welcome; republishing the article, in full or in part, is not.