The interview gauntlet

The interview process is a calibration test, not a knowledge test. This is the single most useful frame to walk in with, and most students never adopt it. They treat each interview as a quiz with a right answer they’re trying to produce, get nervous when they don’t see the answer fast, and either bomb or pass on luck. The students who do well do something different: they treat the hour as a chance to show how they think, get unstuck, listen, and update. They are not faster than the next candidate. They are clearer.

This module is the practical version of that frame. It covers the four formats you’ll actually see (DSA, system design, behavioral, take-home), the prep that actually matters for each, and the honest tactics that move you from “competent” to “memorable.” Treat it as a 2-3 month plan, not a weekend cram. Cramming for interviews is the worst possible use of the resource the rest of this curriculum gave you.

Set up — the realistic timeline

Two-to-three months before your first onsite, your week should look like this:

Day	Block	What
Mon	1 hr	LeetCode — 1 problem from a pattern you’re working through
Tue	1 hr	LeetCode — same
Wed	1 hr	System design — read 1 case study, take notes
Thu	1 hr	LeetCode — same
Fri	1 hr	Behavioral — write or refine 1 STAR story
Sat	90 min	Mock interview with a friend — alternate roles
Sun	60 min	Review the week, redo any LC problem you got wrong

That’s roughly 8 hours a week. Less, and you don’t build muscle. More, and you crash before the interviews. Stick to 8 for 10 weeks and you’ll be over the bar at most companies.

Read these first

Three sources, in this order, then build:

1. Gayle McDowell — Cracking the Coding Interview (just chapters 1-7 and the behavioral chapter). book · still the canonical structure, even in 2026.
2. Alex Xu — System Design Interview, Vol. 1. book · 8 hours total · skim it, build in your head.
3. Ellen Spertus — Why I post these problems before they’re polished. post · 10 min · why “narrate your thinking” is the actual skill being tested.
4. LeetCode Top Interview 150 — if you do these 150 well, you’re ready. Not 500. 150.

Stop. Specifically: do not buy a $400 interview-prep course. The three above plus a friend to mock with you cover 95% of what those courses teach, often better.

The four formats

Every interview round you’ll see falls into one of these. The play is different for each.

Format	Time	What’s tested	Key habit
DSA / coding	45-60 min	Can you solve a real algorithmic problem under pressure, narrating?	Narrate your thinking out loud, always
System design	45-60 min	Can you reason about a real-scale system, making trade-offs?	Drive structure; don’t wait for prompts
Behavioral	30-45 min	Are you someone who’ll be net-positive on a team?	Specific stories with numbers, no rehearsal smell
Take-home / onsite project	4-24 hours	Can you ship working code to a real spec?	Timebox. Ship a README. Document trade-offs.

DSA — solve patterns, don’t grind problems

The trap most students fall into is grinding 500 LeetCode problems and getting stuck at “fast on stuff I’ve seen, lost on stuff I haven’t.” This is the trained-robot failure mode. The fix is to study 75-150 problems but study them by pattern.

The patterns from module 02.2 — sliding window, two pointers, BFS, DFS, binary search, dynamic programming on 1D / 2D, heap-based, graph traversal, backtracking, prefix sums, monotonic stack — are roughly 12. There are 5-10 canonical problems per pattern. Doing all of them well is 75-120 problems.

The actual study loop, per problem:

1. Read the problem. Spend 5 minutes thinking before coding. Write the brute force first, even if it’s O(n^3). Establish the baseline.
2. Implement, on paper or whiteboard if you can. Tools that auto-complete or auto-test you out of mistakes are your enemy in prep.
3. Get it working. Then only after that, look at the editorial or a top solution.
4. If your solution was different, ask why. If theirs is better, redo your solution from scratch using their approach. Don’t just read it.
5. Two weeks later, redo the problem cold. This is the step almost no student does, and it’s the one that makes patterns stick.

Five problems a day for three weeks gives you 75. Then redo every problem you struggled on. That’s the 10-week plan in one paragraph.

The “narrate your thinking” rule

This is the most important sentence in this module. The live coding interview is not testing whether you reach the answer. It’s testing whether you can think out loud in a way the interviewer can follow.

Most students go silent the moment the problem is read, freeze for 5 minutes, then start coding. The interviewer has no idea what’s happening. Even if they get to a working solution, the interviewer’s note reads “got there but unclear how, didn’t communicate.”

Talk through:

• “My first instinct is brute force — for each pair, check… that’s O(n²).”
• “Can we do better? If we sort first… no, that loses the index. What if we used a hash map…”
• “Let me think about edge cases. Empty input, single element, all duplicates.”
• “Okay, let me code the brute force first to make sure I understand, then optimise.”

You’ll get partial credit for thinking visibly even when you don’t reach the optimal answer. You’ll get zero credit for silently getting it right and being unable to explain why.

The drill: every LeetCode problem you do, do it out loud. Talk through every step as if someone’s watching. It feels stupid for the first few. It is the most under-rated tactic in the entire prep stack.

System design — drive the structure

Most candidates wait for the interviewer to ask the next question. That’s a bad pattern. The strongest candidates drive the structure of the conversation. The play for any system-design question:

1. Clarify the problem (5 min)
   Functional requirements, non-functional requirements, scale.
   Repeat back the problem to confirm.

2. Estimate the back-of-envelope numbers (3 min)
   QPS, storage, bandwidth. Get rough.

3. High-level design (10 min)
   Boxes and arrows. Client → API → service → data.
   Don't go deep yet. Get the whole shape on the board.

4. Deep dive (15 min)
   Pick the 1-2 most interesting components. Storage choice.
   Scaling bottleneck. Consistency model. Show the trade-offs.

5. Failure modes & extensions (5 min)
   What breaks at 10x scale? What about the edge cases?
   Mention monitoring, deployment, data migration if time.

You’re driving this whole loop. The interviewer might prompt at each phase, but you should not be waiting for it. The prep: pick 8-10 canonical questions (Twitter/X, Uber, TinyURL, distributed cache, news feed, photo sharing, chat, ride hailing, search autocomplete, video streaming) and walk through each one in 45 minutes, on paper, alone. Then with a friend.

The trap to avoid: jumping to a specific tech stack (“I’d use Kafka and Cassandra”) in minute 3. Hold off until you’ve established why. The “why” is what’s being tested, the tech name is just bookkeeping.

Refer back to module 05.1 for the underlying primitives. If you don’t know how a load balancer or a write-ahead log actually works, no amount of interview-trick rehearsal saves you.

Behavioral — STAR, but the stories must be real

Every senior engineer has roughly 5 behavioral stories ready to deploy. They cover the 5 questions every interviewer is some variation of:

Story	Question it answers
Conflict	”Tell me about a disagreement with a teammate.”
Failure	”Tell me about a time you failed.”
Leadership	”Tell me about leading something.”
Ambiguity	”Tell me about a project with unclear requirements.”
Technical disagreement	”Tell me about a time you pushed back on a senior engineer.”

For each of these, write a STAR-format story:

Situation: 1-2 sentences. The context.
Task: 1 sentence. What you specifically had to do.
Action: 3-5 sentences. The specific actions you took.
Result: 1-2 sentences with numbers. Outcome and what you learned.

The trap is rehearsing them until they sound rehearsed. Don’t. Memorise the 4 beats — what happened, what you did, what the outcome was, what you learned — and tell each story conversationally. The “rehearsed smell” comes from over-polishing the prose; the cure is to tell the story to 5 different friends, slightly differently each time.

Specific is everything. “We had a deadline conflict with the design team about the launch date” is generic. “In my third week at the internship, I disagreed with my mentor about whether to migrate the rate limiter from Redis to Postgres before the launch on Aug 15. I argued for keeping Redis because…” is real, and an interviewer can interrogate the specifics. Real stories survive interrogation. Generic ones don’t.

Take-home rules

The take-home is the format that screens out students hardest, because they treat it like coursework — “make it perfect” — and burn 30 hours on a 6-hour spec. The rules:

• Timebox. If the spec says 4 hours, spend 4 hours. If it says “as long as you need,” spend 6. Document the timebox in your README.
• Ship a real README. What you built, how to run it, what you’d do with more time. The README is more of the interview signal than the code.
• Document your trade-offs. “I chose SQLite over Postgres because the spec didn’t require concurrent writes. With more time, I’d add X.” This is the senior-engineer move.
• Tests, but proportional. A test for the core logic. Two tests for the obvious edge cases. Skip the 100% coverage performance — they didn’t ask for it.
• Don’t over-architect. No microservices for a 200-line spec. Senior interviewers see this and downgrade.

The students who get strong take-home reviews don’t write the most code. They write the cleanest 200 lines, with a README that reads like a real engineer wrote it.

Reading interviewer signal in real time

The interview is a conversation, not a monologue. Watch the interviewer:

• They’re nodding and writing. Keep going, you’re on track.
• They’re asking clarifying questions. They’re confused, slow down and re-explain.
• They’re hinting at a different direction. “What if the input were enormous?” Take the hint. They want you to scale your answer.
• They’re impatient or fidgeting. You’re either too slow or in the weeds. Wrap up the current point and move on.
• They’ve gone quiet. Either you’re doing well (good silence) or they checked out (bad). Ask: “Should I keep going on this approach, or do you want me to consider something else?”

The willingness to ask is itself a signal. Strong candidates don’t soldier through bad approaches; they reset.

Salary expectations questions — the answer

You will be asked, often early: “What are your salary expectations?” The wrong answer is to give a number — you’ll either anchor too low or too high. The right answer:

“I’d like to focus on whether this is the right fit first. Once we’re both clear on the role, I’m sure we can find a number that works. Could we revisit this later in the process?”

That sentence, said calmly, defers the question to the offer stage where you have more leverage and more data. Module 07.4 covers what to do then. For now: don’t give a number, don’t apologise for not giving a number, just defer.

The frame that ties it together

Every interviewer is asking themselves the same question: would I want to work with this person on a real project?

Not: do they know the answer. Not: are they smart. Would I be glad to debug a production issue with them at 11pm?

Everything in the prep above is downstream of that question. Narrating your thinking signals “I won’t be a black box on the team.” Driving system-design structure signals “I’ll bring clarity to the planning meeting.” STAR stories with specifics signal “I have judgment, not just opinions.” Reading interviewer signal signals “I’ll be coachable and adaptive.”

If your prep makes you better at the test but worse at being someone an interviewer wants to work with, you’re prepping wrong. The robot move — speed, perfection, no hesitation — is exactly the thing that fails this bar. Slow, clear, honest beats fast and confident.

Going deeper

When you have specific questions, in this order:

1. NeetCode 150 / NeetCode roadmap — the cleanest curated problem set, with explanations.
2. Donne Martin — System Design Primer. github · long but skimmable, the broadest free system-design resource.
3. Gergely Orosz — The Senior Engineer Interview Process. post · helpful even early — knowing what they look for two levels up makes you better today.
4. Yossi Kreinin — Why bad jobs find great people and vice versa. post · 15 min · the meta-frame on which interviews are worth your time.

Skip the “I cracked Google in 2 weeks” YouTube content. The real story is always 6 months of consistent prep, retold as if it were 2 weeks.

Checkpoints

If any one wobbles, the corresponding section above is what to reread.

1. What are the four interview formats? Name the key habit for each.
2. Why does “narrate your thinking” matter even more than reaching the answer? What’s the failure mode of silent solving?
3. Walk through the 5-phase system-design playbook from memory. What’s the trap of jumping straight to a tech stack?
4. List the five behavioural stories every senior engineer keeps ready. What’s the difference between rehearsed and real?
5. What’s the answer to “what are your salary expectations” in an early interview, and why is that the right move?

If you can answer all five, you’ve earned 07.2. Next is 07.3 — what to actually do with the offer once you’ve earned it.