14.10 — The Interview Compendium

Most people who fail an interview loop were technically capable of passing it.

They failed because they did not know what each round was measuring. They coded in silence when communication was half the score, gave a system design with no numbers, answered a behavioural question with a summary of their job, and told a hiring manager they were an eight out of ten at React.

This chapter is the map of what is actually being assessed, and how to use the rest of this book to prepare.

1. The rounds, and what each one measures

Round	Actually measuring
Recruiter screen	Basic fit, motivation, compensation range
Technical screen	Can you code at all, and communicate while doing it
Coding	Problem-solving process, not just the answer
Low-level design	Modelling, class structure, extensibility
System design	Trade-off reasoning under ambiguity
Domain deep-dive	Depth in something you claim to know
Behavioural	Collaboration, ownership, self-awareness
Hiring manager	Judgement, motivation, will you thrive here

Two things to internalise before any of it.

They are hiring for a colleague, not a contestant. Every round is partly "what would working with this person be like for two years".

And ambiguity is deliberate. Under-specified questions are testing whether you ask, or assume. Asking is the correct move in every round, and it is the single most common difference between candidates at the same technical level.

2. The coding round

What is graded, roughly in order:

1. Do you clarify before coding?
2. Do you explain your approach before writing?
3. Can you analyse the complexity, including the non-obvious part?
4. Is the code correct and readable?
5. Do you find your own bugs?
6. Do you take a hint gracefully?

Notice that only one of six is the code. A perfect silent solution frequently scores below a slightly imperfect one delivered with clear reasoning, because the interviewer is trying to predict how you will work on problems where nobody knows the answer.

The protocol, which works every time:

Restate the problem. Ten seconds, and it catches misunderstandings before they cost twenty minutes.

Ask clarifying questions. Input size, ranges, duplicates, empty input, sorted or not, memory limits, and whether you may modify the input. Chapter 4.0's constraint-to-complexity table is exactly this: the bounds tell you the intended complexity, so n \le 20 means exponential is expected and n \le 10^5 means O(n \log n).

Work an example by hand, including an edge case. This often reveals the pattern.

State the approach and its complexity before writing. "Brute force is O(n^2); a hash map makes it O(n) time and O(n) space — shall I write that?" This is the highest-value thirty seconds in the round, because a wrong approach caught here costs nothing and caught in code costs everything.

Then code, narrating decisions, with real variable names.

Walk through it with an example — out loud, on the actual code. You will find a bug, and finding your own bug scores well while having it pointed out does not.

Then discuss improvements unprompted: what breaks at scale, what you would do differently in production.

When stuck, say what you are considering. Silence is the only genuinely bad response, because the interviewer has nothing to grade and nothing to help with. And a hint is not a mark against you — ignoring one is.

Preparation: the problem chapters 4.4–4.30, not a list of problems. Recognising which of about eighteen patterns applies is the whole skill, and Chapter 4.0's recognition table is the index. Solve fewer problems and understand each completely — including the "this same move also solves…" generalisation, which is what makes it transfer to a problem you have not seen.

3. The low-level design round

"Design a parking lot." "Design an elevator." Forty-five minutes, classes and interfaces.

Chapter 9.7.1's nine-step method is the protocol: clarify scope, identify actors, list use cases, find entities, define relationships, design interfaces first, walk the core flow, name the race condition, and handle the twist they will add.

What separates a good answer:

Interfaces before implementation. Show the shape, then fill it.

Name the concurrency problem before being asked. "Two barriers could be told the same bay is free — I would settle that with a conditional update" is the sentence that moves a round (Chapter 9.7.4).

Extensibility on the axis they will test. They will add a requirement at minute thirty-five. A design where that is a new class rather than a change to five is what the round is for (Chapter 9.3.6).

And do not over-pattern. Naming five design patterns in a parking lot signals pattern fever rather than judgement (Chapter 9.4.1).

4. The system design round

Chapter 11.0 is the full protocol. Compressed:

Requirements with numbers. Ask the clarifying questions and say what each answer changes. Write down functional, non-functional and explicitly out-of-scope.

Estimate on screen — users, requests per second, storage, bandwidth — and say what each number forces. "Fifty thousand writes per second means one database will not do, so we shard" is the sentence that turns arithmetic into architecture.

API, then data model, with the partition key justified against the access patterns (Chapter 7.5.2).

Draw the architecture, and narrate the read path and the write path separately.

Go deep on two or three things, with real numbers and the alternative you rejected.

Then trade-offs, scale and failure. Chapter 10.19 is the ledger of pairs; Chapter 11's failure tables are the format.

The three failure modes: naming technologies instead of reasoning ("we'll use Kafka" with no argument), no numbers at all, and never mentioning what breaks. The interviewer is grading the reasoning, and a defended simple design beats an undefended complex one every time.

5. The deep-dive

"Tell me about a system you built."

Structure it, because a chronological narrative loses them:

Context — what it did, who used it, what scale. Constraints — what made it hard: deadline, legacy, compliance, cost, team size. Decisions — two or three real ones, with the alternatives you rejected and why. Trade-offs — what you knowingly gave up. What broke — and what you did about it. What you would change — the strongest signal of a senior engineer.

Have one such story ready in real depth. They will ask why at every level, and the point where you cannot answer is where the round finishes. So pick something you genuinely built and understand end to end, not the most impressive thing on your CV.

6. Behavioural rounds

STAR: Situation, Task, Action, Result. Brief on situation and task, most of the time on action — what you did — and always finish with a result, quantified if possible.

"We" is the most common mistake. They are hiring you, not your team. Describe the team's context and then your specific contribution.

Build a bank of six to eight stories covering: a conflict with a colleague, a real failure, leading without authority, disagreeing with a decision, extreme ambiguity, a tight deadline and what you cut, mentoring someone, and your biggest impact. Most questions map onto one of these, so you are recombining rather than inventing under pressure.

The failure question is a real test. A disguised success ("I worked too hard on quality") fails it. A genuine mistake, its consequence, what you did about it, and what changed in how you work is what scores — and it demonstrates the self-awareness the round exists to find.

And say what you did to fix the situation, not only what you learned. Learning without repair reads as observation.

7. The hiring manager round

Less structured, and it is measuring judgement, collaboration, self-awareness and how you handle disagreement.

"Rate yourself out of ten in React." A trap in both directions: nine invites a question you cannot answer; four undersells you. The answer that works has three parts.

Decline the false precision, politely and briefly. "It depends what ten means — if ten is someone on the React core team, nobody in this room is a ten."

Then define a scale and place yourself with evidence. "I'd say I'm strong: I've built and maintained production applications, I understand reconciliation and the rules of hooks and why they exist, and I've debugged real rendering performance problems. Where I'm weaker is the newest server-component patterns — I've read them and not shipped them."

That answer does three things at once: it shows calibration, it gives concrete evidence, and it steers the conversation toward what you want to be asked about. Naming a genuine gap makes the strength credible.

The rest of the round:

"Why are you leaving?" Forward-looking and honest. Never criticise a current employer — it is the fastest way to lose a room, regardless of whether you are right.

"What are your salary expectations?" Section 9.

"Do you have any questions for us?" Always yes, and ask questions that inform you:

• What does on-call look like, and how often does someone get paged at night?
• How often do you deploy, and how long from merge to production?
• What is the biggest piece of technical debt, and what is the plan for it?
• How are technical decisions made when people disagree?
• What happened to the last person in this role?
• What would success look like for me in six months?

These are also signals to them that you think about the work rather than only the offer — and the answers frequently decide whether you want the job.

8. Take-home assignments

Time-box strictly, and state what you spent. "Four hours; with more time I would add X and Y" is a strong answer, and it demonstrates prioritisation.

What is actually graded: whether it works, whether the code is readable, whether the structure is sensible, whether you handled errors and edge cases, and whether the README explains your decisions. The README is disproportionately weighted and disproportionately neglected.

Do not gold-plate. A clean, complete, small solution beats an over-engineered one — and over-engineering is itself a negative signal (Chapter 9.3.4).

And it is fair to decline an unpaid multi-day assignment, or to ask whether a conversation about work you have already done could substitute.

9. Negotiation

The recruiter expects a counter. The first offer is rarely the maximum, and negotiating politely does not cost you the offer — that fear is the single reason most people leave money on the table.

Avoid giving the first number. "I'd rather understand the role and the level first — what range is budgeted for this position?" If pressed, give a researched range with the bottom at a number you would accept, since you will not get more than the bottom.

Negotiate the level, not only the money. Level determines the band, future increases and scope. A level change is worth more than a percentage.

Negotiate the package: base, bonus, equity, sign-on, start date, remote arrangement, learning budget, and title. A sign-on bonus is the easiest thing for a company to move, because it does not affect the band.

A competing offer is the strongest lever, and it must be real.

Be specific and pleasant. "I'm excited about this. Based on my research and my other conversations, I was expecting X. Is there flexibility?" This is not adversarial — the recruiter's job is to close you, and they usually have room.

Get everything in writing before resigning. And do not accept in the moment; asking for a few days is normal and universally granted.

10. Preparing with this book

A twelve-week plan, if you are starting from a working knowledge:

Weeks 1–4 — problem solving. Chapter 4.1 for complexity, then the problem chapters 4.4–4.30 pattern by pattern. Recognition, not volume. Solve out loud.

Weeks 3–6 — design, in parallel. Chapter 9.7 for low-level design — do six problems fully, writing real interfaces. Chapters 9.1 to 9.4 for the principles behind them.

Weeks 5–9 — system design. Chapter 11.0's method, then one case study every two days. Say the answer out loud with a timer, because that is the round.

Throughout — the fundamentals you will be asked about: Chapter 7 for databases (isolation levels, indexing, N+1), Chapter 5 for networking (TCP, HTTP, DNS, TLS), Chapter 8.4 for authentication, Chapter 10 for distributed systems, and Chapter 3.6 to 3.8 for JavaScript and Node if that is your stack.

Weeks 10–12 — the human rounds. Write your six to eight stories out. Practise the deep-dive. Do mock interviews with a person, because the gap between knowing something and explaining it under time pressure is the thing being tested.

Each Part's ## What the interviewer will push on sections are an index into the follow-up questions, which is what they were written for.

11. On the process itself

Rejection is a noisy signal. The same candidate passes one loop and fails an equivalent one, on the interviewer they drew, the day, and the fit. Do not update heavily on one result — and do ask for feedback, because occasionally it is specific and useful.

Interview while employed if you can. It removes the desperation that shows.

Practise out loud. Reading a solution and explaining one while someone watches are different skills, and only the second is tested.

Keep notes after each interview — what was asked, what went badly, what you would say differently. Two loops in, the patterns are obvious.

And when it is over, the thing that made this preparation worth it is not the offer. The engineers who interview well are usually the ones who understand systems deeply — which is the same thing that makes them good at the job. That is the honest case for all of it, and it is why this Volume covered the material rather than the questions.

Recall

• Every round has a different target, and the common failure is not knowing which. They are hiring a colleague, and under-specified questions are testing whether you ask.
• Coding: only one of six graded things is the code. Restate → clarify → work an example → state the approach and complexity before writing → code aloud → walk through and find your own bug → suggest improvements. Silence is the only bad response, and ignoring a hint is worse than needing one. Prepare patterns, not problems (Chapter 4.0).
• Low-level design: interfaces first, name the race condition before being asked, and design for the axis they will extend at minute thirty-five. Do not over-pattern.
• System design: numbers on screen with what each number forces, read path and write path separately, two or three deep dives with rejected alternatives, then failure. A defended simple design beats an undefended complex one.
• Deep-dive structure: context, constraints, decisions, trade-offs, what broke, what you would change — and pick something you actually understand end to end, because they will ask why until you run out.
• STAR with most of the time on your action, a bank of six to eight stories, and a real failure with a real repair — not a disguised success.
• "Rate yourself out of ten": reject the false precision, define a scale, give evidence, and name a genuine gap — which makes the strength credible and steers the conversation.
• Negotiate: the recruiter expects a counter. Avoid the first number, negotiate the level as well as the money, treat it as a package, get it in writing, and never accept in the moment. Rejection is a noisy signal — practise out loud, and keep notes.

Self-test: Which part of the coding round is graded highest, and which is graded least? · What sentence turns estimation into architecture in a design round? · What must a failure story contain besides the failure? · What are the three parts of a good answer to "rate yourself out of ten"? · What is worth more than a percentage increase in an offer? · Why is preparing for interviews and being good at the job the same activity?

Volume I ends here. Fourteen Parts, from a transistor as a switch to a system design interview: the physics underneath computation, the operating system that schedules it, the languages that express it, the algorithms that make it tractable, the network that connects it, the interface that presents it, the data that persists it, the security that protects it, the designs that structure it, the distribution that scales it, the studies that apply it, the models that learn from it, the infrastructure that runs it, and the craft that sustains a career doing all of it.

Volume II opens the mathematics that several of these Parts leaned on — from arithmetic through calculus and linear algebra to the transforms behind signals and the probability behind learning — and Volume III restores the electronics that Chapter 1.1 deliberately deferred.