Resume grilling
Everything on your resume is a promise. This round collects on it. Write a real, specific answer to each of these before your first interview — not a script, the actual facts, so that in the room you are recalling rather than improvising.
If you cannot defend a figure, do not remove it from the resume — reframe it in the room. "That was our internal estimate from log counts rather than an instrumented measurement, so I would treat it as directional" is a completely acceptable sentence and it costs you almost nothing. Inventing a methodology on the spot and then contradicting yourself two questions later ends the interview.
- 40% fewer production runtime errors — over what period, measured how, from what baseline?
- 35% faster page loads — which pages, which metric, measured with what tool?
- 50% less state boilerplate — how do you measure boilerplate? (Lines of state-management code per feature is a defensible proxy. Say it in exactly those words.)
- 4 hours to 15 minutes deployment — what took four hours before, step by step?
- 25% infrastructure cost cut — from what monthly figure to what?
- 40% lower initial load across 15 commerce pages — what were they before?
- 10,000 unique monthly mobile visitors — was that attributable to the PWA work or to marketing? (If you do not know, say you do not know — that is the honest and correct answer.)
- 75% user adoption on the Mindbell dashboard — adoption of what, by whom, over what window?
- 30% lower sync latency from batching 15 APIs — what was the batching strategy?
- 5,000 registered users — how many were active daily or monthly? (Registered is a vanity number and a good interviewer knows it.)
Prepare each one in the four-beat form from R4.13: measured → diagnosed → changed → verified. Any answer that has all four beats survives; any answer missing "measured" does not.
Pick GetDandy and practise drawing it in ninety seconds, on paper, three times tonight. What has to be on the board:
- Client (Next.js) and how it is served.
- The reverse proxy or load balancer in front.
- The Nest services and what each one owns.
- MySQL, Redis, S3 — and what each holds.
- The AI agent integration and which direction the calls go.
- The five environments and what differs between them.
- Where the real-time dashboard 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.
- Where is the bottleneck?
- What would you change if you started again tomorrow?
- What happens if Redis goes down?
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 good candidate for you is committing to a state-management or rendering approach in week one of a client project and paying the migration cost later — you have lived that with Redux, so you can 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."
Two failure modes. One: a fake weakness ("I take on too much"). Two: a decision that was not yours, told as though it was — interviewers probe, and the story collapses when they ask what you would have done differently and you have no answer because you never made the call.
- How long did it take you to notice?
- Who else was affected?
- What stopped you from seeing it earlier?
Three, 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.
- How do you handle someone who disagrees with a standard?
- Which of your own rules do you break, and when?
- How do you introduce a standard to an existing codebase?
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.
- How long was it down?
- What did you tell the client?
- Did it happen again?
- What is the largest data volume you have worked with?
- What is the highest traffic you have personally handled? (Answer honestly. "Not high by product-company standards — five thousand 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 — there is no testing on your two most recent roles in the resume, and 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 three companies in six years? (Two years, one year three months, three years is not a red flag. Have the arc: each move added scope — 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.)