What I write in the debrief after a senior mobile interview

The decision on a senior mobile interview is not made in the room. It is made in the interview debrief, usually a day or two later, by people reading notes. I have written those notes for more than 500 technical interviews, from early career screens through staff and engineering manager loops, and I have sat in the debriefs where they were read aloud and picked apart. What survives that reading decides the offer and, more often than candidates realize, the level.

This article shows what those notes actually look like, how a rating gets argued from them, and what gets thrown out. The note excerpts below are composites: the kind of lines I write, assembled from patterns across many loops, not any real candidate and not any company's template.

What interviewer notes look like

During the round I type fast and badly. Timestamps, fragments, and as many of the candidate's exact words as I can get down. After the round, usually within the hour, I clean them up into a form someone else can read. The raw version is where the evidence lives, so I keep it attached.

[composite, not a real candidate]
Round: mobile system design, senior loop
Prompt: offline edits to a shared list, two devices

14:06  Starts with the data model, not the UI. Good order.
14:09  "I'd store operations, not the final list, so I can replay
       them if the server rejects one."
       -> Signal: conflict handling. Unprompted.
14:15  Pushed: server may reorder ops.
       "Then last write wins on position breaks for us. I'd move
       ordering to the server and keep local order as a hint."
       -> Changed one part, kept the rest. Senior.
14:22  Asked: how do you know it works in prod?
       "Conflicts per active user per day, and ops dropped after
       the last retry. The second one should be zero."
       -> Measurement named with a target. Staff-leaning.
14:31  Never raised migrating the local schema when the op
       format changes. Did not probe; ran out of time.
       -> Gap, unverified. Not a concern yet.

Four things are in almost every line. What the candidate said, as close to verbatim as I can manage. Whether it was prompted. The signal it supports. And, where I can, the level it points to. The last entry matters as much as the good ones: it records a gap I did not test, so nobody in the debrief treats it as a failure or as a pass.

Notice what is missing. There is nothing about confidence, energy, or whether I liked the person. That is deliberate, and it is the most important habit an interviewer can build.

Observations survive the interview debrief, impressions do not

An observation is something another person could have witnessed: a sentence, a decision, a question the candidate asked, a thing they did not mention when it was relevant. An impression is my conclusion about the person. Impressions are allowed in the summary, but only if an observation sits under them. On their own they do not survive, because the first thing anyone in the debrief asks is "what did they say?"

Here is the same round written two ways. The first version is what tired interviewers write at 6 p.m. The second is what they should have written.

[composite] Version A
Very strong communicator. Clearly senior, maybe staff.
Knows Compose deeply. Would enjoy working with.
Rating: Strong hire.

[composite] Version B
Explained why the list recomposed on every scroll: an unstable
lambda captured the view model. Fixed it by hoisting the
callback and checked it with the recomposition counter before
moving on. Prompted only by "it feels slow".
When I asked about a 10x longer list: "Then my fix is not the
problem, the item layout is. I'd profile before touching it."
Rating: Hire, senior. Staff not tested in this round.

Version A reads as more enthusiastic and carries less weight. A chair can do nothing with "clearly senior" except ask what it rests on, and if the answer is a feeling, the rating gets discounted toward whatever the other interviewers wrote. Version B is quieter and far harder to argue with. It also tells the reader what the round did not cover, which is what stops one enthusiastic note from carrying a staff offer on its own.

When I review another interviewer's feedback, I read it looking for verbs the candidate performed. Explained, chose, rejected, measured, asked. Adjectives about the candidate get skipped.

How strong hire, hire, lean no and no hire get argued

Most loops I have worked in use some version of a four point scale. The labels vary. The logic underneath them is consistent, and it is not a scale of how well the round went. Each rating is a claim about evidence against a specific level.

• Strong hire means I would argue for this person against the other interviewers, and I have specific lines that clear the bar for the level, including at least one I did not prompt.
• Hire means the evidence clears the bar and nothing I saw contradicts it. Most offers are made on a set of plain hires.
• Lean no means I saw something that worries me, or I did not see enough to clear the bar. The note has to say which. "Not enough signal" and "a real concern" lead to different outcomes.
• No hire means I have a specific observation that falls below the bar for the level, and I can quote it.

Two consequences follow. A "no hire" without a quoted line is weak, and a good chair will push on it. And the rating is always for a level. "Hire at senior, lean no at staff" is one of the most common things I write, and it is a complete, useful sentence. Senior and staff mobile roles at large US tech companies commonly carry $300k to $400k total compensation, and the level decides most of that number. The difference between those two ratings is often a single paragraph of evidence.

The unowned trade-off that sinks a leveling case

Candidates tend to think a level is lost on a wrong answer. In my notes it is more often lost on a claim that could not be backed up, or a decision whose cost the candidate did not own. A staff case needs the candidate to show they see second order effects. One moment where they did not tends to be the line the debrief remembers.

[composite, not a real candidate]
Round: past project deep dive, staff loop

10:12  "We cut cold start by about 40 percent."
10:13  Asked how that was measured.
       "It felt much faster, and QA signed off on it."
       Asked about the metric before and after: not tracked.
10:18  Chose to move all startup work behind a feature flag
       service call. Asked what happens when the call fails.
       "It hasn't been a problem." Did not name the fallback.
10:25  Strong on the migration plan itself. Sequenced it well,
       kept two teams unblocked.

Level: senior is clear. Staff not supported: the headline
result is unmeasured and the main design risk was not owned.

Nothing in that excerpt is wrong in a technical sense. The project may have been excellent. But the headline claim has no measurement under it, and the biggest design decision has a failure mode the candidate had not thought through or chose not to discuss. At staff, both of those are the job. The excerpt ends as a hire at senior, and the candidate will probably never know which two sentences did it.

The fix in the room is small. "We cut cold start by about 40 percent at p50 on mid range Android devices, measured from process start to first frame in our startup trace, and the p90 barely moved, which I'm still not happy about" is the same project. It turns into a staff line because the candidate owns the number and its limits.

What the debrief chair asks the interviewer

Whoever runs the debrief, a hiring manager, a bar raiser, a committee member, has one job: make sure the decision rests on evidence and not on the loudest person in the room. Across the loops I have sat in, the questions they ask interviewers are remarkably similar.

• "What did they say that made you write that?" The request for the observation under the impression.
• "Was that prompted?" A trade-off named after two hints is worth less than one named unprompted.
• "Did you test it, or did you assume it?" Especially for concerns. An untested gap is not a negative signal.
• "Is this concern showing up in any other round?" One interviewer's worry is a data point. The same worry from two rounds is a pattern.
• "Would you be a hire at the level below?" This is how most down leveling decisions actually happen.
• "What would change your rating?" If the interviewer cannot answer, the rating is softer than it looks.

As an interviewer, you learn to answer these before you are asked. That is most of what separates useful feedback from a paragraph of adjectives. As a candidate, you can read this list the other way round: each question is a place where your words either exist in the notes or do not.

Why interviewers plan follow-ups before the loop

Before a senior loop, I know which signals my round is supposed to cover, and I plan two or three follow-ups for each one. That can look like a script from the other side of the table. It is not there to trap anyone. It is there so that I walk into the debrief with an answer to "did you test it?"

A follow-up is a way to generate an observation on purpose. Without one, I am left with whatever the candidate happened to volunteer, and the notes fill with gaps I cannot classify. With one, every signal the round owns ends up as either evidence, a concern, or an explicit "not reached". The loop coordinator can then see which signals were covered by which rounds and where the holes are.

Planning also keeps me consistent. If I change the same fact for every candidate at a level, their responses are comparable, and my ratings drift less from week to week. The candidates who do well are not the ones who predict the follow-up. They are the ones whose first answer already had a visible seam for it to press on. I wrote more about that moment in the follow-up decides the senior mobile interview.

Where structured notes push bias out, and where it gets back in

Structured notes remove a lot. "Culture fit" with nothing under it does not survive the first question from the chair. Neither does "reminded me of myself", which is rarely written but often felt. Neither does a rating built on the candidate's previous employer. Requiring a quoted line under every rating forces the interviewer to separate what happened from how they felt about it, and a surprising amount of the feeling falls away once you try to write it down.

It does not remove everything, and I would be misleading you if I said it did. Four leaks I have seen persist even in loops with good discipline:

• Selection. I decide which sentences to write down. If I like a candidate early, I catch more of their good lines. The notes look like evidence, and they are, but they are a sample I chose.
• Fluency read as depth. A candidate who speaks quickly in their first language, with the vocabulary of the team they are joining, gets quoted more cleanly than one who pauses and reformulates. The idea may be the same. The note is not.
• Anchoring. If I read another interviewer's feedback before writing mine, my rating moves toward theirs. The loops I trust make you submit before you can read anyone else's.
• Stack familiarity. When a candidate describes a pattern I have used, I recognize it as good faster. When they describe an equivalent I have not seen, I have to work harder to credit it, and on a busy day I sometimes do not.

None of these is fixed by a better template. They are reduced by a chair who asks the questions above, by more than one interviewer per signal, and by interviewers who know their own leaks. I try to write my notes during the round rather than after, precisely because memory edits toward the impression.

How to leave quotable evidence in the room

You cannot write the interviewer's notes. You can decide what is available to be written. After reading a lot of feedback, including my own, I think three sentences do more for a senior candidate than any amount of extra preparation on topics.

Say the trade-off. Not "there are trade-offs", but the specific cost of the thing you just chose, and who pays it. "This doubles memory for the thumbnail cache, which is fine on the devices we support but not on the low end Android tier." That is a line I can paste directly under "judgment".

Say what you would measure. A metric, where it comes from, and roughly what number would tell you it worked. This is what separates a senior answer from a staff one more often than any architecture choice, because it shows you expect to be wrong sometimes and have a way to find out.

Say what would change your mind. "If the team was already on a shared sync layer, I would not build this and would push the conflict logic to the server." It shows the decision is a decision, tells me where its edges are, and it gives the interviewer a natural follow-up, which you now control.

Two smaller things help the person writing about you. When you make a decision, say that you are making it: "I'm going to pick X." It turns a stream of thinking into a line I can timestamp. And when you do not know something, say how you would find out, which reads as a strength in the notes, where a confident guess reads as a concern once someone checks it.

If your target is staff, the bar for these sentences moves up, and the senior vs staff mobile interview article covers what changes round by round.

Practice built around the notes

Interview Runtime is organized around the lines that end up in notes like these: each question has the answer that loses the point, the answer that keeps it, and the follow-ups that test it. There is iOS Interview Training and Android Interview Training, both aimed at senior and staff roles. Free samples: the iOS sample and the Android sample. They will not write your debrief for you, but they give you practice saying the sentences that do.

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