Senior vs staff mobile interview: the signals that set level

The senior vs staff decision in a mobile interview is rarely about whether you got the answers right. By the time a loop is debating level, you did. What moves you up is whether your answers set direction beyond your own code: scope you claimed, trade-offs you owned, numbers you said you would watch. I have sat in hundreds of debriefs where the packet said "strong hire" and the level line said "senior", and the reasons were almost always the same few.

This article is written from the hiring side. It covers what staff signal looks like in each round of a mobile loop, how "hire, but at senior" gets written, and what you can do in the room so the people scoring you have something to quote.

Why level decides most of the offer

At large US tech companies, senior and staff mobile roles commonly carry total compensation in the $300k to $400k range, and level decides most of where inside that range, and above it, you land. Negotiation moves an offer within a band. Level picks the band. levels.fyi publishes per-company data, and it is worth checking the specific companies in your pipeline before you decide how much preparation a loop deserves.

The practical consequence: a loop where you pass every round and get leveled one step lower is, financially, closer to a rejection than to the offer you wanted. Many candidates prepare for pass or fail. The loop is also answering a second question the whole time.

What staff mobile engineer interview signal actually is

In a staff mobile engineer interview, the interviewer is looking for evidence that you change outcomes for a group of engineers, not only for your own feature. Across the loops I have run and sat in, that evidence falls into four shapes. They show up in every round, in different clothes.

• Scope. You define the problem wider than it was asked, then deliberately narrow it. A senior answer solves the screen. A staff answer asks which teams, releases and app versions the screen touches, then picks a boundary out loud.
• Ambiguity handling. You turn a vague prompt into two or three decisions and say which one you would make first and why. Asking questions is not the signal. Collapsing the answers into a plan is.
• Trade-off ownership. You choose, you say what the choice costs, and you say who pays that cost. "It depends" is where senior answers end. Staff answers keep going.
• Measurement. You name what you would watch after shipping and what number would make you reverse the decision. This one is the most reliable separator I know, because it is hard to fake.

None of these are about knowing more APIs. A senior engineer who knows Sendable checking in detail and a staff engineer who knows it in detail will both pass the concurrency question. Only one of them will say what the migration to strict concurrency costs forty engineers across two quarters.

Senior vs staff in the mobile system design round

System design is where level is decided most often, because it is the round with the most room. The prompt is usually a feature: a chat inbox, a feed with offline reading, a payments confirmation flow. Both levels will draw boxes. The difference is what sits outside the boxes.

Notice what the staff answer does not do. It does not add Kafka, CRDTs or a sync engine. Over-building is a common failure at this level: candidates hear "staff" and draw the backend. The interviewer wants to see the client engineer who knows exactly where the client ends and what it needs from the other side. I go deeper on that particular prompt in offline-first sync at staff level.

The architecture round: decisions other teams live with

Architecture rounds in mobile loops usually start from something you built: "walk me through the architecture of an app you worked on." Senior candidates describe the pattern. MVVM with coordinators, or MVI with a unidirectional store, the dependency graph, the module list. That is a fine answer and it scores as senior.

The staff version describes a decision and its blast radius. On iOS that might be: "we split the app into feature modules as Swift packages, and the hard part was not the split, it was that build times got worse for three months because every feature still imported the networking module's concrete types. We introduced interface modules, which added boilerplate every team complained about, and I owned that complaint." On Android the same story is often about Gradle: moving to convention plugins, or deciding that feature modules may not depend on each other and routing through an api module instead.

The follow-up I ask most in this round is "what would you undo?" Senior candidates tend to name a library. Staff candidates name a boundary or a rule they set, what it cost other teams, and what they learned about enforcing it. If you can answer that question with a real decision you drove, you have handed the interviewer a staff signal. The modularization article covers the follow-ups that come after it.

The coding round still has a level

Many candidates assume the coding round is pass or fail and that level is settled elsewhere. Mostly true, with one exception: the way you treat the code as something other people will run. Here is a common shape of prompt, a retry helper for a network call in Kotlin.

import java.io.IOException
import kotlin.random.Random
import kotlinx.coroutines.delay

suspend fun <T> retrying(
    maxAttempts: Int = 4,
    baseDelayMs: Long = 250,
    block: suspend () -> T,
): T {
    var attempt = 0
    while (true) {
        try {
            return block()
        } catch (e: IOException) {
            attempt++
            if (attempt >= maxAttempts) throw e
            val cap = baseDelayMs shl attempt
            delay(Random.nextLong(cap / 2, cap))
        }
    }
}

A senior solution often catches Exception, which also catches CancellationException and keeps retrying after the caller's scope is gone. That gets flagged, the candidate fixes it, and it scores fine. The staff signal is in what comes unprompted: catching only IOException on purpose, adding jitter and explaining it as protection for the backend when a million phones reconnect at once after an outage, and saying that a 4xx should never be retried. Then one sentence about measurement: "I'd log attempt count on success, because if most successes need three attempts the timeout is wrong, not the network."

The Swift equivalent is the same conversation with Task.isCancelled and Task.sleep. The code is short either way. The level lives in the three sentences around it.

Behavioral and leadership: where down-leveling is written

The behavioral round is where I have written "hire, but at senior" most often, and almost never because the stories were bad. They were good stories about the candidate's own work. The staff bar in this round is influence without authority: a decision you drove that other engineers, other teams or your manager did not initially agree with.

The stories that score as senior

• "I fixed a crash that affected 2% of sessions." Real impact, but you were the whole team.
• "I mentored two junior engineers." Expected at senior, and without an outcome it is not evidence.
• "I pushed back on a product deadline." Only staff if you say what you proposed instead and how it landed.

The stories that score as staff

Staff stories have a shape: a problem nobody owned, a decision you made that crossed a team boundary, disagreement you worked through, and a result you can put a number or a date on. On mobile the classic examples are dropping support for an OS version, setting a crash-free sessions target that product had to trade features against, moving both apps to a shared API contract, or killing a cross-platform experiment. The detail that tips it is the part where someone disagreed and you say what you changed your mind about.

How down-leveling happens in the debrief

The debrief is not a vote on whether you are good. Each interviewer brings a hire or no hire and a level, with evidence. When levels disagree, the lower one usually wins unless someone can point to specific evidence for the higher one. A pattern I have seen many times: three interviewers write "strong, staff" on vibes, one writes "solid senior" with quoted examples of answers that stayed inside the module, and the packet goes out at senior. Specific beats enthusiastic.

The phrases that signal a coming down-level in written feedback are predictable: "needed prompting to consider", "good once I pushed on", "strong executor", "stayed at the feature level", "didn't discuss rollout". Every one of them describes an answer that was correct and incomplete. None of them says the candidate was wrong.

This is also why pushback matters so much at this level. The interviewer's follow-up is the part of the round designed to test level. If the first answer was senior and the follow-up recovered it to staff, that counts. If the first answer was staff and the follow-up collapsed it, that counts more. I wrote about that dynamic in the follow-up is the interview.

How to get leveled correctly in the room

1. Say the level out loud before the loop. Tell the recruiter which level you are interviewing for and ask whether the loop is calibrated for it. Some loops are run at one level and adjusted afterwards; knowing that changes how much space you take.
2. State the boundary in every design answer. One sentence: what is in scope, what is out, and what you need from other teams. It costs twenty seconds and it is the first thing a staff rubric looks for.
3. End each decision with its cost and its measurement. "This costs us X, I'd watch Y, and if Y crosses Z I'd reverse it." Practice until it is a reflex, on both platforms.
4. Bring two influence stories, not five achievement stories. Each one with a disagreement, a cross-team decision and a result. Prepare them to survive "what would you do differently?"
5. Treat pushback as the scoring moment. When the interviewer challenges you, do not restart. Name what their point changes, keep what it does not, and restate the decision.

What does not work: saying "at staff level I would..." or listing your title. Interviewers score behavior in the room. A past title with no evidence behind it can hurt, because it raises the bar the answers are compared against.

Practice material for senior and staff mobile loops

I wrote iOS Interview Training and Android Interview Training around this exact gap: each question comes with the answer that passes, the follow-up that tests level, and the wording that holds up under it. The free samples show the format before you decide: iOS sample and Android sample. No book guarantees a level. What it can do is give you enough reps with the follow-up that your staff answers come out when the clock is running.

© 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.