Senior and staff signals

Structure the answer, because an unstructured one is scored on whatever the interviewer manages to extract. Situation, what you specifically did, what happened, and what you took from it. The common weakness is the collective we: it hides which decisions were yours, and an interviewer who cannot tell what you did cannot credit you for it.

Prepare stories rather than answers. Two or three real ones, each with numbers, cover most questions asked at senior level, because the same project can answer conflict, ownership, failure and influence depending on which part you tell. Preparing per question produces a memorised list; preparing per story produces material you can actually think with.

Numbers matter more than they should. Reduced deploy time from forty minutes to six lands differently from improved our deployment process, not because the interviewer is checking, but because specificity is evidence of having been there. Vagueness is what an answer sounds like when it is being reconstructed rather than recalled.

The failure story is the one that separates candidates. Everybody has one; the ones who describe it precisely, own their part without over-apologising, and name what changed afterwards are demonstrating exactly the self-assessment that senior work requires. Certainty about a past decision reads as never having examined it.

Conflict questions are asking about how you handle being wrong and how you handle being right when someone disagrees. The strong version names the other person's reasoning fairly, says what evidence would have changed your mind, and describes what you did once the decision went one way or the other. Winning is not the point; the point is whether the team could keep working afterwards.

Finally, prepare questions of your own and make them real. What does the on-call rota look like, what happened in the last incident, how does a decision like this one get made here. Those answers are the ones you will live with, and asking them signals someone evaluating the job rather than hoping to be chosen.

Restate the problem in your own words and confirm an example before writing anything. It costs a minute and it catches the misunderstanding that would otherwise cost twenty, and clarifying an ambiguous constraint is itself part of what is being scored rather than a delay before the real work.

Say the brute force and its complexity, then improve on it. A working slow solution beats an unfinished clever one every time, and stating the naive version first demonstrates that you can find an optimisation rather than that you have seen this problem before. If you already know the optimal answer, show the progression anyway; the reasoning is the thing being sampled.

Narrate while you work. Silent brilliance scores worse than narrated competence, because the interview is a proxy for what working with you is like, and a colleague who thinks silently through hard problems is genuinely harder to work with. Say what you are trying, and say when something is not working and what you will try instead.

Test unprompted, with cases you choose: empty input, one element, duplicates, the maximum size, a value at a boundary. Walking through your own code with a concrete input catches the off-by-one before the interviewer does, and doing it without being asked is one of the strongest signals available in the format.

Write code you would accept in review. Real names, small functions, no cleverness that needs explaining. Under time pressure people produce single-letter variables and one dense line, and it reads as exactly what it is, which is a habit the reviewer would rather not inherit. If you get stuck, say so and say what you are stuck on. Interviewers can offer a hint to someone who has articulated the obstacle and cannot help someone staring silently at a screen. Being stuck is normal; being stuck without communicating it is the part that scores badly.

A hiring loop is not one assessment repeated. Each stage is scored against something different, and knowing which is which changes how to spend the time in it. The recruiter screen checks the basics and the story: level, availability, salary band, and whether your background matches what the role says. Precision here saves everyone a fortnight.

The technical screen is a filter, so the objective is to pass it cleanly rather than to impress. Finish the problem, communicate while you work, and treat it as a lower-variance version of the onsite. Nobody has been hired on a screen and plenty have been eliminated on one.

The onsite rounds are the real assessment and they are usually split deliberately: coding for whether you can build, system design for judgement at scale, behavioural for how you work with people, and often a domain round for the specific thing the team does. They are scored separately by people who then meet, which is why an outstanding design round does not compensate for a coding round nobody could follow.

The debrief is where the decision is actually made, and understanding it explains a lot about what to optimise for. Interviewers write feedback separately, then argue it. Specific evidence travels between people, and impressions do not, so an interviewer who can quote something concrete you said is far more useful to you than one who thought it went well. Give people evidence they can repeat.

The offer conversation is a separate skill from all of it and worth preparing with the same seriousness. Ask about the level and the band before discussing numbers, because the level determines the range and is much harder to change afterwards. And ask the questions that decide whether you would stay: what the on-call rota looks like, what happened in the last incident, how a technical disagreement got resolved recently.