Staff mobile system design interview, scored against Senior

This page is for Senior mobile engineers interviewing for a Staff role, and for Seniors who want to know where the bar sits before they try. It is the rubric I use when I decide between Staff and Senior after a Staff mobile system design interview: the questions I ask, what a strong Senior says, what a Staff candidate says, the follow-up that separates them, and how a candidate who did well still ends up levelled at Senior.

Most of this is not about the diagram. A Staff candidate and a strong Senior often draw the same boxes. What differs is what they ask before drawing, what they refuse to build, and who they think owns the thing after launch.

One prompt, two rubrics

The question I am answering for a Senior candidate is: can this person lead the execution of a hard problem very well?

The question for Staff is different: can this person improve how the organisation solves hard problems? I am not looking for a very good Senior. I am checking whether I could hand this person an important, ambiguous problem that spans several teams, with no obvious solution and no limits defined for them, and get back a good technical direction, alignment between the people involved, and a better outcome for the organisation.

There is no universal definition of Staff. Companies shape the role differently: some want a tech lead, some an architect, some a solver for the hardest problems, some a right hand to an engineering leader. The common thread is impact beyond your own work, and usually beyond one team.

Here is the difference on one prompt: “Migrate from system A to system B with no downtime.”

• The strong Senior builds an excellent migration plan. Dual writes, backfill, a read switch behind a flag, verification, rollback.
• The Staff candidate asks first. Why are we migrating? What problem does it solve, and for whom? Who pays for it? What depends on A? Do we need a full migration, or can we remove most of the problem by changing the contract between the two systems? Sometimes the Staff answer is “we should not migrate”. That is judgement, and it is what I am there to find.

What a Senior answer must cover

The Staff bar sits on top of the Senior one, not instead of it. A Staff candidate who skips the fundamentals does not get credit for strategy. The Senior baseline in a mobile round is the device: a local source of truth, writes that survive the process being killed, a sync design with a conflict rule, background limits stated correctly, and a way to know it works in production. The mobile system design interview guide lists the seven areas I expect.

If those are shaky, the round becomes a Senior round and stays one. If they are solid by minute twenty, I start pushing on the things below.

What I watch for at Staff

In a Staff system design round I am watching eleven things at once:

1. Problem framing
2. Which requirements you prioritise
3. The constraint that determines the design
4. Trade-offs you chose, not trade-offs you listed
5. How the system evolves from version one to version three
6. What happens when it breaks
7. The migration from the system that exists today
8. Ownership after launch
9. The impact on other teams
10. Cost
11. The exit strategy

The last five separate Staff from Senior more than anything else. Ideally a Staff candidate brings up migration, ownership, organisational impact, cost and exit without being asked.

The questions I use, and what separates the answers

These are prompts and follow-ups I use for the Staff decision. For each one: what is scored, what a strong Senior says, what the Staff signal is, and the follow-up.

1. “Three of our mobile apps implement authentication differently. What would you do?”

What is scored: whether you look at the organisation before you look at the code.

Strong Senior answer: extract a shared SDK. Common protocols, token storage, refresh, tests, and a gradual migration of each app onto it. That is a good answer and I would hire the person who gives it, at Senior.

Staff signal: first find out why they diverged. If some differences are deliberate, a shared SDK turns legitimate variation into a rigid abstraction that three teams now have to fight. So: identify the owners in the three teams, in security and in backend auth. Define the contract you want to standardise. Separate policy from mechanism. Maybe start with shared observability and contract tests, which cost little and tell you where the real differences are. If centralising is worth it, then the SDK needs a clear owner, a compatibility policy, and a rollout that does not block three teams at the same time.

That answer covers the system, the organisation and the lifecycle. That combination is the Staff signal.

The follow-up: “Who owns the SDK in two years?” If there is no name or team in the answer, the design is not finished.

2. “What are you intentionally making worse?”

This is my favourite follow-up, and I ask it after any design choice.

What is scored: whether trade-offs are ranked or recited.

Strong Senior answer: “Option A is faster to build, option B scales better.”

Staff answer: “For the next eighteen months our bottleneck is the delivery time of four teams, not throughput. I accept A’s limit because it keeps the option to migrate later, and reversing it is cheap.” A Staff candidate can say what we optimise, what we sacrifice, why, for how long, and what would change the decision. That last part is the one most answers leave out, and it is what makes a decision record useful after you leave the room: without a condition for revisiting it, the next engineer sees a choice with no reason and reverses it.

The trap: answering “nothing”. Every design makes something worse. Not knowing what is the finding.

3. “Mobile reliability is getting bad. Where do you start?”

What is scored: how you handle ambiguity, in both directions.

What I want to hear: questions. What does “bad” mean? Who experiences it? What changed? Is it reliability, latency, correctness, or perceived performance? What is the business consequence? What evidence exists? Which decisions are blocked by it? Over what time horizon?

The second half, which counts as much: converging. After a few questions I need to hear something like “based on what we know, I frame it as X, assuming A and B. If either assumption is wrong, I revisit.” A candidate who keeps asking questions for twenty minutes has shown me the other failure. A Senior asks for clarity. A Staff candidate creates it.

4. “We have three unknowns and the decision is due tomorrow.”

What is scored: deciding with incomplete information.

The two weak extremes: paralysis (“we need to collect more data” when the decision is tomorrow), and cowboy architecture (“Kafka, it scales”).

The mature answer: “Two of these three are reversible after launch. One is not: the consistency model. I validate that one before we commit, I document the assumptions for the other two, and we proceed.” A Staff candidate can say “we do not know X, and we do not need X for this decision”, and also “I cannot take this decision responsibly without Y”.

5. “Your design needs Team B to change something that is not on their roadmap.”

What is scored: leadership without authority.

Insufficient: “I would talk to their manager.”

Staff answer: first check whether they really must do it. If our dependency forces work on them with no benefit to them, maybe our design is the problem. If the need is legitimate, lower their cost: write the RFC, propose the implementation, contribute the code. Only when there is a real priority conflict do you escalate, and you escalate to the place where the two priorities can be compared.

The strongest version makes the case in terms Team B already measures. “Old app versions will fail to parse this” sounds like a favour for mobile. Put it as their risk instead: the parse failure happens on phones, so their canary metrics stay green, the automatic rollback never triggers, and their on-call is the one paged for a breakage their own graphs do not show. Now they have a reason to want the fix.

6. “Tell me about an architectural decision you would make differently today.”

What is scored: whether you own mistakes and change the system that produced them.

Insufficient: “We chose Realm, and later switched to Core Data.” That is a fact, not a lesson.

Staff answer, in shape: “I pushed that decision. I optimised for our team’s velocity and missed that the platform team would standardise persistence six months later. Technically it was fine. Organisationally we ended up with two standards. The signal I missed was that three other teams had the same problem at the same time. What we changed afterwards was the process for cross-cutting decisions.” The structure is: my mental model was wrong, and here is how I changed the system that produced the mistake.

7. “Tell me about a technical decision where the organisation initially disagreed with you.”

What is scored: influence, and whether you can tell a technical objection from another kind.

Red flags: “I proved I was right.” “My manager backed me.”

Strong answer, in shape: “I thought the disagreement was about the technology. After two conversations I understood that Team B was worried about ownership and on-call. I changed the design so they kept ownership, and the objection disappeared.” An objection is not always a technical objection. Staff candidates find out which kind it is.

8. “Tell me about an important technical problem your organisation was solving incorrectly before you got involved.”

This is the best single behavioural question I know for Staff. I follow it with: how did you notice? Why did others not see it? How did you demonstrate it? What alternatives did you consider? Who had to be convinced? What did it cost the organisation? What did you do personally, and what did others do? What was the result? What would you do differently?

A real Staff engineer can spend thirty minutes on this without generalities. When the story evaporates at the second “how?”, that is the answer.

9. “That will not work. Writes arrive out of order.”

An interviewer says something like this in the middle of your design.

What is scored: how fast you update your model.

A candidate who says “you are right, that invalidates my assumption about ordering” and rebuilds the sync design around it can score better than one who had a better first design and spends fifteen minutes proving me wrong. Updating your model quickly matters more than looking infallible.

Recovery line when you have already started defending: “Let me stop defending that. If writes can arrive out of order, my ordering assumption is gone, so the server has to own sequencing. Here is what that changes.”

Reversibility decides how much process you spend

A Staff candidate spends process in proportion to how hard a decision is to undo. This is roughly my ladder, from easiest to reverse to hardest:

The Staff version of a rollout sounds like “try it on five percent of traffic and roll back if the metric moves” for the cheap end, and “slow down here, ten teams will build on this contract” for the expensive end. A candidate who runs every decision through the same process, heavy or light, is not reading the ladder.

Red flags that can mean No Hire despite technical excellence

• Absolutism. “Microservices, always.” “Never use singletons.” “MVVM is the correct architecture.”
• Cannot explain why. Architecture bingo: “Kafka for scalability.”
• Complexity bias. Strong candidates say “we do not need this”, “one table is enough”, “keep it synchronous”, “that is not the bottleneck at our volume”.
• Blame in every story. “Everyone was incompetent, I arrived, I fixed it.”
• Hero syndrome. “Then I rewrote it over the weekend.” “Only I understood the system.” That is a bus factor of one, presented as a strength. The Staff version is “I made the team able to solve the next one without me.”
• Confusing influence with authority. “I told them to.” “They should follow the architecture.”
• Blind to organisational cost. “We will create a platform team.” That sentence contains ownership, staffing, on-call, a roadmap and new coupling.
• Over-indexing on consensus. Sometimes the right answer is “I heard the objections, we need a decision today, I choose B and I own it.”
• Stakeholder vocabulary with no mechanism. I ask who disagreed, what they wanted, what changed, which document, who decided, and what happened three months later. If the story has no answers to those, it did not happen the way it was told.

Good Senior answers that are not Staff answers

These come up often in Staff loops. None of them is wrong. They are just not evidence of Staff.

• “I designed the architecture.” How did you choose the problem? Who had to be convinced? Which alternatives did you drop? Which teams were affected? Who operated it afterwards? What did you change when the first assumption turned out wrong?
• “I mentored juniors.” Mentoring makes one engineer better. Staff leverage changes how thirty engineers work: design review, standards, debugging tooling, incident practice, hiring calibration, onboarding, a reusable platform, technical strategy.
• “I led the project.” What did leading mean? Splitting tickets is not a Staff signal. Redefining the project boundary so three teams with incompatible goals could ship independently against a shared contract is.
• “I proposed microservices” or “I proposed a monolith.” Zero signal either way. The Staff part is why that solution, for that organisation, at that moment.
• “We migrated 200,000 lines of Objective-C.” That invites “so what?”. Link problem, intervention and outcome: the component caused a large share of build failures, you migrated the three boundaries that caused most of them, incidents dropped, and two teams stopped maintaining a workaround. The metrics do not have to be perfect. The link has to be there.

How down-levelling happens in the debrief

This is the scorecard I think with. It is conceptual, not a form.

The final decision is not an average. Coding 10, algorithms 10, design mechanics 9, influence 4, judgement 4, scope 4 is “Strong Senior, not Staff”. The near-gating dimensions are technical judgement, scope, ambiguity, influence, leverage and decision quality. Missing two or three of those is not compensated by an excellent coding round.

A typical debrief for that profile reads like this: best coding of the quarter; excellent fundamentals; every project confined to their own team; defended the design instead of exploring my concern; no example of influencing a team they did not own; a strong execution leader with no organisation-level technical leadership. Verdict: Hire at Senior or Senior plus, not Staff.

If after the interview the main thing I can say is “technically excellent”, there is no Staff evidence yet. When I start arguing for a Staff hire, the sentence sounds more like: I would trust this person with a messy, politically difficult, technically ambiguous problem involving four teams, to find what matters, make the trade-offs explicit, align the right people, decide, and leave the organisation stronger.

Preparing for the level above you

Behavioural evidence for Staff is a repeated pattern, not one great story: ambiguity, framing, alignment, decision, execution, adaptation, measurable impact. If every project you can describe was “my manager gave me requirements and I executed them very well”, you are probably a very good Senior today, and the preparation is to find or create the other kind of work, not to rehearse harder.

For the design round itself:

1. Take one design you already know well and add the last five items from the list above to it: migration from today’s system, ownership after launch, impact on other teams, cost, exit strategy. Write each in two sentences.
2. Answer “what are you intentionally making worse?” for every major choice in that design, out loud.
3. Practise saying “we do not need this”. Pick one component in your design and argue for removing it.
4. Prepare question 8 for one real problem you worked on, and check that you can answer every “how?” underneath it with a name, a document or a date.

What I do not require at Staff: being the fastest coder, knowing every algorithm or every API, being an expert in every layer, being a manager, charisma, talking constantly, or leading dozens of people. Staff engineers still write code.

The shortest version I have: a Senior is someone I can trust with a difficult project. A Staff engineer is someone I can trust with the judgement for a difficult area of the organisation.

What to do next

• Build a prep plan for your loop with the round and the time you have left.
• Read offline-first mobile system design, the scenario where Staff follow-ups on migration and old app versions come up most.