The STAR method for senior mobile engineers: what the interviewer scores after the R

STAR solves an ordering problem. Without it, candidates start in the middle, jump to the fix, and remember the context halfway through. With it, the listener always knows where they are. That is worth something, and it is why every prep guide teaches it.

What STAR does not tell you is what the interviewer is writing down. The letters are slots, not criteria. A candidate can fill all four with true sentences and still give the interviewer nothing to score, because none of the sentences shows a choice. At senior level, the rubric is built around a short list of questions:

• Ownership. What were you, personally, accountable for? Not what the team was asked to do.
• The decision. Where was the fork, what did you choose, and what did you give up to choose it?
• What changed. Is there a number, and is there something that still works differently because of you?
• Durability. Does the story stay consistent when the interviewer asks for a detail you did not volunteer?

None of those is a letter. They cut across the letters. That is the gap between a junior STAR answer and a senior one.

Share Your Screen lays out this upgrade as a table in its behavioral chapter, and the idea is simple: keep the four parts, change what goes in them.

Two things in that table are easy to miss. The situation gets shorter, not longer. Senior candidates spend too long here because the context feels important to them; to the interviewer it is setup. And the result has three parts, not one. The last part, what you would change now, is the one that most often separates a senior answer from a mid-level one. A story that ends on "and it shipped" sounds finished. A story that ends on what you learned and still do sounds like judgment.

Here is one story, a schema migration in a release, told the way most candidates tell it. The story is an illustrative composite written for this page.

• Situation: "We had an app with a local database, and the data model had grown a lot over the years, so it was getting hard to work with. There were a lot of legacy tables, and the product team wanted new features that needed a different structure."
• Task: "We were asked to migrate the database to a new schema."
• Action: "We designed the new schema, wrote the migration, and tested it a lot. We used feature flags and did a phased rollout. There were some issues with older versions, but we fixed them."
• Result: "The migration was successful and it made the codebase much cleaner. The team was happy with it."

Every letter is filled. Nothing in it is false. And the interviewer has almost nothing to write down. Count the problems:

• The situation runs three sentences and contains no stake. Why did it matter this quarter?
• The task is "we were asked". Who owned the risk if users lost data?
• The action is a list of standard practices. Feature flags and phased rollout are what everyone says. Which decision was hard?
• "Some issues with older versions" is the most interesting sentence in the answer, and it is buried. That was the story.
• The result has no number, no mechanism, and no reflection. "The team was happy" is not an outcome.

Same project, same facts, rebuilt around ownership, a decision and what changed. Still about two minutes out loud.

• Situation: "We needed a new local schema to support offline edits, and a meaningful share of our active users were still on app versions several releases old. A failed migration on launch would mean a crash loop with their data on the device."
• Task: "I owned the migration plan and the go or no-go call for the release that carried it."
• Action: "The fast option was one migration step from any old version to the new schema. I chose to chain the existing per-version steps instead and add one new step, because I could test each step against a real database copied from an old build, and one big jump would only be tested from the versions we happened to have. It cost us about a week. I also made the app keep a copy of the old database until the first successful sync, so a failure could be retried instead of losing data."
• Result: "In the phased release, crash reports showed a migration failure on launch for users coming from one very old version, a case none of our fixtures covered. Because the old database was kept, those users recovered on the next build with no data loss. Afterwards I added a migration test that opens a database from every supported old version on each pull request, and that test caught two regressions in the following months. What I would do differently is build that fixture set before writing the migration, not after."

Look at what changed. The situation shrank and gained a stake. The task names a risk with an owner. The action contains a fork: one step or a chain, and a stated cost. The failure is not hidden; it is the middle of the story, and it is owned. The result has an outcome, a mechanism that outlived the project, and a reflection that sounds like a habit, not a slogan.

The Senior Signal puts the same idea as a three-part rule in its chapter on the human interview: a number at the start, a mistake in the middle, an artifact at the end. A story missing all three is the kind interviewers are trained to doubt.

Mobile work is team work. Releases, migrations and incidents involve backend, QA, product and often another platform team. So candidates say "we" out of habit and out of fairness, and both reasons are good. The problem is what it does to the score.

An interviewer cannot hire a team. Every "we" in the action section is a sentence they cannot attribute. Tell a whole story in "we" and the honest note on the scorecard is: unclear what the candidate did. That is not a neutral note. It reads as either someone who was present but not deciding, or someone who is hiding which part was theirs.

The opposite failure is real too. A story told entirely in "I", where you designed, built, tested, shipped and fixed everything alone, does not survive in a senior loop. Interviewers know a migration across a large app is not one person's work, and a story with nobody else in it reads as either a small project or an inflated one.

The fix is to separate the two cleanly, out loud:

• Credit the team specifically: "Two engineers on my team wrote the migration steps, and QA built the device matrix."
• Then claim your part precisely: "The part that was mine was the decision to chain the steps, and the call to keep the old database."
• If you did not make the key decision, say who did and what you contributed to it. That is still a strong answer if your contribution was real.

Expect the direct probe: "What was your specific contribution versus the team's?" It exists to find exactly this. A candidate who has already drawn the line answers in one breath. One who has not either retreats into "we" or overclaims, and both are visible.

The first telling of a story is rehearsed. The follow-ups are not. That is why interviewers spend most of a behavioral slot on them, and why a story that only works in one direction fails here.

• "Why did you choose that over the alternative?" Tests whether the decision was yours and reasoned, or inherited.
• "What did the data show at the time?" Tests whether the numbers were measured then or reconstructed now.
• "Who disagreed, and what did they say?" Tests whether other people appear as obstacles or as input that changed the plan.
• "What specifically was your mistake?" Tests whether the failure is yours or the team's, the timeline's, the vendor's.
• "What happened after you left the project?" Tests whether the change outlived your attention.
• "If you did it again tomorrow, what would you change?" Tests whether the reflection is real or a closing line.

You cannot script answers to these. You can make them easy by telling a story that happened and keeping its details straight: the version numbers, the order of events, who decided what. Threads only hold on stories that happened, and the follow-up is where an interviewer finds out.

The STAR structure does not change between levels. What the interviewer listens for inside it does.

The staff column is not a bigger project. It is the same kind of story told about structures instead of code: the decision record, the shared test, the adoption across teams. If you are interviewing for staff, check whether your stories have anyone in them besides your own team.

The usual preparation is a document of forty answers, one per likely question. It produces forty rehearsed answers that each break on the first follow-up, because none of them is known deeply.

The better preparation is a handful of real incidents, each written down once with its facts: the stake and its number, what you owned, the fork and the rejected option, the mistake, the outcome, the mechanism left behind. Then practise telling each one from different angles. The schema migration above answers "a hard technical decision", "a mistake you made", "a time you pushed back on a deadline" and "something you improved for the team", depending on which thread you lead with.

• Cover the common categories: a failure, a disagreement, a trade-off under a deadline, influence without authority, ambiguous scope, and someone you helped grow.
• For each story, write one sentence that starts "The part that was mine was...".
• Say each one out loud, at two minutes, and stop. Then have someone ask the six follow-ups above.

For the prompts themselves, by category, see the guides to iOS behavioral interview questions and Android behavioral interview questions.

Is the STAR method enough for a senior mobile behavioral interview?

No. STAR gives the story an order, and most candidates who reach a senior loop already use it. What gets scored is what you put inside it: what you personally owned, the decision you made and the option you rejected, what changed afterwards, and whether the story still holds when the interviewer pulls a thread.

Should I say "I" or "we" in a behavioral interview?

Say "we" for what the team did and "I" for what you did, and make the line between them easy to see. An answer told only in "we" cannot be scored, because the interviewer cannot tell your part. An answer told only in "I" sounds like an empty room. Name who built what, then say which decision was yours.

How long should a STAR answer be?

Aim for about two minutes for the first telling, with the situation in a sentence or two. Leave room for follow-ups. The interviewer learns more from the threads they pull than from a long first pass, and a long situation section is the most common way senior candidates run out of time.

How many stories should I prepare?

Fewer than you think, known more deeply. A small bank of real incidents, each written down with its numbers and your decision, covers most prompts if you practise telling each one from different angles: the failure, the disagreement, the influence, the trade-off.