Resume grilling

They will pick one figure off your resume at random, so prepare every one of them — each percentage, duration, cost and user count. Next to each, write four facts before your first interview: the period it covers, the tool it was measured in, the baseline it moved from, and the verified change. Filled in with placeholders, it looks like this:

Once those four facts are written down, expect these ten follow-ups:

1. Which number here are you least sure of? Name it before they find it, and say how you would firm it up.
2. Was it your work, or the team's? Say which part you did, and who else moved the number.
3. What else changed at the same time? A release, a marketing push or the season can move a number as much as your fix did. (If you do not know, say you do not know — that is the honest and correct answer.)
4. Which pages, which metric? "Faster" means nothing until you say which pages, and whether it was the largest paint, the time to interactive or the full load.
5. What did it look like before, step by step? For a time saving, walk through what used to take the time.
6. How do you measure something fuzzy? For boilerplate, name the proxy. (Lines of state-management code per feature is a defensible one. Say it in exactly those words.)
7. Registered, or active? Have the daily or monthly active figure ready. (Registered is a vanity number and a good interviewer knows it.)
8. Adopted by whom? A usage figure needs its denominator: who could have used it, and how many did.
9. What did it cost? Every improvement traded something — build time, complexity, a feature cut. Name it.
10. Could you do it again somewhere else? Say what you would look at first on a system you have never seen.

Prepare each one in the four-beat form from R4.14: measured → diagnosed → changed → verified. Any answer that has all four beats survives; any answer missing "measured" does not.

Pick the one you know best and practise drawing it in ninety seconds, on paper, three times tonight. What has to be on the board:

• The client and how it is served.
• The reverse proxy or load balancer in front.
• The services and what each one owns.
• The datastores — database, cache, file storage — and what each holds.
• The integrations with outside services, and which direction the calls go.
• The environments and what differs between them.
• Where any real-time data comes from.

Draw the boxes, then draw the arrows with direction, then label the arrows with the protocol. Most candidates draw boxes and stop; the arrows are where the architecture actually lives.

Pick something real, medium-sized and genuinely owned by you. The shape: the decision → why it looked right at the time → what it actually cost, concretely → how you found out → what you did about it → the rule you now carry.

A common one is committing to a state-management or rendering approach in week one of a project and paying the migration cost later. If you have lived that — a Redux store chosen before anyone knew the shape of the data, say — tell it honestly and end with a real rule: "I now decide state management after the first three features rather than in week one, because the shape of the state is not knowable at the start."

Have three ready, each with its reason attached. Rules without reasons sound borrowed:

• Every endpoint returns the same error envelope. Because otherwise every client writes bespoke error handling per call, and the third one gets it wrong.
• No business logic in a controller. Because a controller can only be tested through HTTP, so logic that lives there is logic nobody tests.
• Validation at the boundary with unknown properties stripped. Because it prevents both malformed data and mass assignment, and it means every layer below can trust its inputs.

Then be ready for the harder question underneath: how did you get the team to follow them? The honest answer — documented, enforced in code review, and where possible automated with a lint rule or a shared base class, because a standard that depends on remembering is a standard that decays.

Structure: what broke → how you found out → what you did in the first ten minutes → the root cause → the change that made recurrence impossible.

Two things that separate a good answer:

• Restore first, diagnose second. If your story has you debugging before rolling back, expect to be marked down at any level above three years.
• The prevention has to be structural. "We were more careful after that" is not a fix. "We added a constraint / an alert / a test that would have caught it" is.

And "how you found out" matters more than people expect: if the answer is "the client told us", say so honestly and then say what monitoring you added so that it would not be the client next time.

• What is the largest data volume you have worked with?
• What is the highest traffic you have personally handled? (Answer honestly. If it is small, "Not high by product-company standards — <your number> users. What I have depth in is the delivery and reliability side of that" is a fine answer; inflating it is not.)
• How do you decide what to test? What is your coverage on the services you designed? (Prepare this one — if testing is missing from your most recent roles on the resume, they will notice.)
• Describe your code review standard. What do you actually reject a PR for?
• How do you mentor a junior? Name a specific person and what changed for them.
• How do you estimate? When were you last badly wrong, and what did you do about it?
• How do you handle a client asking for something you think is a bad idea?
• Which part of your stack do you know least well? (Answer it. Refusing to name one is worse than any answer you could give.)
• What have you learned in the last six months? (Have a real, specific answer — the React Compiler, the Next 16 caching model, something you actually read.)
• What would your current lead say your weakness is?
• Why have you changed jobs as often as you have? (If each move came after a year or more, it is not a red flag. Have the arc: each move added scope — for example feature work, then ownership, then architecture.)
• Walk me through a piece of code you are proud of. (Have one. Ideally on GitHub, ideally something you can open.)