The scouting report

Thirty percent fewer runtime errors. Forty-five percent faster pages. A fifth off the infrastructure bill. I will pick one at random and ask exactly how you measured it, over what window, and against what baseline. If you cannot answer that, every other number on the page turns from a fact into a claim — including the ones you can defend.

Prepare every number on your resume. R10 gives the template.

Eight thousand registered users and twenty-five thousand monthly visitors is a small system. If I am hiring for traffic, I want to know whether you can think about ten times or a hundred times that.

The answer is not to inflate it. It is to be precise about what you have done — depth on delivery, reliability and architecture ownership — and then demonstrate in R8 that you can reason about scale you have not met. Those are different skills and interviewers know it.

No message queue, no background job system, no event bus anywhere on the page. Five NestJS services communicating with no async messaging means either tight HTTP coupling or something missing from the story.

The full answer is R5.4. Learn its shape: name the trade-off honestly, give the specific trigger that would change the decision, name the tool and why that tool.

"Structured logging" is where your monitoring story ends. No metrics, no tracing, no alerting, no error-tracking tool named. For someone who claims to own reliability after launch, that is the biggest genuine hole on the page.

Own it in the room: logs today, and here is the order I would add things — error tracking first, then p95 latency and error rate with alerts, then tracing last because it costs the most to instrument. That sequencing is the senior answer.

EC2, S3 and Route 53. No RDS, no ECS or EKS, no Lambda, no CloudFront, no load balancer, no auto-scaling group. It reads like a few VMs with Docker on them — which is completely fine, but say so before they work it out. R9.1 has the wording.

Jest appears under an early role and nowhere in your recent roles — the ones where you own architecture. I will ask what your coverage looks like on the five services you designed.

Have a real answer. If the coverage is thin, say what is covered (the domain logic, the validation) and what is not (e2e), and what you would do first with a week.

Every role on the page is at a client-delivery shop. The doubt is whether you can iterate on a single product, own its debt, and care about retention rather than handover.

Your "why leaving" answer in R1.2 is built to defuse exactly this — it names handover as the limitation and turns it into the reason you want their job. Use it early, before they form the doubt.

You are listed in <your home city> and remote. Every interviewer will quietly wonder.

Do not defend the gaps. Convert them into decisions.

"We did not add a queue" is a weakness. "At eight thousand users with a p95 under two hundred milliseconds, a queue would have been infrastructure we had to operate for no measurable gain — the point where I would add one is when notification sends started blocking the request path" is an architect talking.

The gap is identical. The candidate is not.

Every scripted answer in this book is written at one level — six years, mid-to-senior. If that is not you, using it verbatim reads wrong in both directions: too thin against a staff bar, too grand against a two-year role. The fix is not different facts. It is knowing what each level is expected to volunteer.

• 2–3 years. Say the mechanism correctly. That is the whole bar. "Microtasks drain before the next macrotask" is a pass; you are not expected to have a production story attached to it.
• 5–7 years. Mechanism, plus where it bit you. The proof that you have used a thing is that you know how it fails, and you name the number — the latency, the cost, the incident.
• 10+ years. Mechanism, failure, and the trade-off you would make differently. At this level an answer that is only correct is a weak answer; they are listening for judgement about when the correct thing is the wrong choice.

Eleven questions across this book carry a ladder: the bar at each level, the words you would actually say there, and why those words land at that level and not the one above. They sit on the questions every loop asks — tell me about yourself, the event loop and closures, useEffect and reconciliation, stacking contexts, machine coding, the DSA round, system design, disagreeing with a decision, and the number. Read the column that matches you, then read the one above it, because that is the gap you are being asked to close.

Service & consulting walk-in same day · 3–5 hours

Two hundred people in a hall, a token number, a lot of waiting. Resume shortlist (2 min) → Technical 1, rapid-fire breadth (30–40 min) → Technical 2, projects and a light design question (40–60 min) → HR fitment (15 min).

How you win: answer fast and confidently, never say "I have not used that" without immediately saying what you used instead, have your notice period and joining date ready. The failure mode is over-explaining — they have ninety candidates left to see.

Series A–C product startup 5–10 days · 4–5 rounds

Recruiter screen (20 min) → Machine coding (90–120 min) → Technical deep dive (60 min) → System design (60 min) → Hiring manager (45 min) → HR close.

How you win: the machine coding round decides it and everything after is confirmation. Practise building a small CRUD feature with clean module separation in ninety minutes until it is boring.

Mid-size product & SaaS 2–3 weeks · 5 rounds

Online assessment (2 DSA problems) → DSA interview (60 min) → Frontend or backend deep dive (60 min) → System design with a real bar (60 min) → Manager and values, often scored against a written rubric.

How you win: do not walk into these cold. Give yourself the seven days first, spent mostly on DSA and design.

Agency & product studio 2–4 days · 2–3 rounds

Technical plus portfolio walkthrough (60 min) → take-home or pairing (often waived if your GitHub is convincing) → founder chat (30 min).

How you win: your client-ownership story is their exact pain. Talk about delivery, estimation and client communication more than about code — and push hard for fully fixed pay.