Interview season

The funnel truth the LeetCode bubble hides

Most candidates do not fail the algorithm round. Most candidates never reach it. The resume screen kills more applications than every whiteboard combined, and the prep industry barely mentions it because there is no subscription to sell for it.

The cautionary tale is the canon's own author: John Washam, of Coding Interview University, studied full-time for eight months and was rejected by Google without a phone screen. All that preparation, and the funnel cut him at the layer preparation can't reach. His later advice centres on referrals, which, as he puts it, push you toward the top of the mountain of resumes instead of the bottom.

• One page. Not negotiable at this career stage.
• Accomplishment-first. "Built and deployed X", not "was responsible for X". Your task-6 projects go on it with URLs.
• Quantified wherever honest numbers exist: users, requests, milliseconds, dollars.
• Referrals before cold applications, every time you can manage it. A lukewarm referral beats an enthusiastic cold apply.

The Tech Interview Handbook resume guide covers the mechanics, including the boring ones like beating the parsing software. Spend a full week of this season on the funnel. It has the best ROI of any week in the entire plan.

Behavioural rounds carry real weight

The bubble treats behavioural interviews as a formality. They are scored, they sink candidates, and at some companies they outweigh a mediocre-but-passing coding round. Two facts to internalise:

First, behavioural questions are answered out of your resume. The interviewer reads it, picks a line, and says "tell me more about this". Every claim on the page is a question you have invited, so make sure each one has a story behind it that you would enjoy telling.

Second, your task-6 projects are the story bank. The bug that ate a weekend, the deployment that failed in a new way, the rewrite in Go that changed your mind about error handling: these answer "tell me about a challenge" with specifics no rehearsed anecdote can match. Write six stories down, one page each, before your first onsite. If you kept the debugging log from task 6, half of this is already written.

The season itself: /interview runs the show

From here, the interview section is the operating manual, and this plan steps back. The pieces, in the order you should meet them:

• The rubric first, so you know what is actually being graded. Most candidates optimise "got the answer" while the interviewer scores communication, testing, and judgement.
• Levels, to calibrate which bar you are being held to and stop comparing yourself to the wrong one.
• Timed loops for stamina. A full onsite is four to five hours of sustained performance; nobody's first full loop should be the real one.
• The 45-minute system-design simulator, now that task 7 made the components real. This is where the second half of system design, the interview-formatted half, finally belongs.
• Request-trace for the eternal "what happens when you type a URL", which you can now answer from DNS to database with stops at every layer you studied.

Mock cadence

Tech Interview Handbook's rule of thumb: start mocking when you are about two-thirds of the way through your practice plan, not when you feel ready, because you will never feel ready. If you followed task 5, you passed that mark weeks ago, so start now.

Career retrospectives are blunt on this point; "five mocks taught me more than six months of grinding" is a sentiment that recurs almost verbatim across them. Solo practice cannot teach the things mocks teach: talking while typing, recovering from a wrong first approach in front of a witness, and hearing your own silence.

And the habits from task 5 do not stop for the season: the daily warm-up every morning, one contest most weekends. Stamina decays in weeks. Season is the wrong time to discover that.

The exit criterion, restated

The bar this plan set at the start, restated now because now it is due: two unseen mediums, 35 minutes each, talking aloud the whole way, in two separate sessions in a row.

Every clause is load-bearing. Unseen, because recognition of new problems is the actual skill. 35 minutes, because that is the realistic budget inside a 45-minute round after introductions and questions. Talking aloud, because a silent solve scores worse than an imperfect narrated one. Two sessions in a row, because once is luck. Meet the bar and you are ready, whatever your nerves claim. Miss it and you know exactly what to drill, which is more than a feeling of unreadiness ever tells you.

What not to do in season

• No new topics out of fear. Washam's retrospective describes the spiral exactly: "what if they ask red-black trees" leads to a week on red-black trees, which leads to the next exotic fear. The syllabus closed when season opened. Interviews are won on fluent fundamentals, not on having once read about the thing they probably won't ask.
• No hards for vanity. Solving a hard the night before an interview is a confidence lottery with bad odds. Stick to mediums you can finish well; you are tuning performance now, not capability.
• No comparing solved-counts. Not in week one of the plan, and especially not now. The only number that matters is the exit criterion, and it is measured against the clock, not against strangers.
• No skipping the warm-up on interview day. Two easies with breakfast. Athletes do not sprint cold; neither should you.

Further reading

• Washam — Why I studied full-time for 8 months for a Google interview — the funnel lesson, learned the expensive way and written up honestly.
• Tech Interview Handbook — resume preparation — the screen-passing mechanics nobody else bothers to document.
• Tech Interview Handbook — coding interview best practices — the in-room checklist: before, during, and after the question.
• jwasham — Coding Interview University — worth skimming at this stage mostly to notice how much of it you no longer need.