The default technical-prep plan is “grind LeetCode until the heat death of the universe.” Coding fluency matters — but plenty of strong engineers grind for months and still stumble, because the interview tests things LeetCode never does: explaining your thinking, handling design ambiguity, and not freezing when someone's watching.
This is a plan that covers all of it without disappearing into a problem set forever.
The four things to cover
- Coding fluency: enough pattern practice that common problem shapes feel familiar. Depth over volume — understanding 50 problems beats half-remembering 500.
- System design: a repeatable framework for open-ended design questions. Weighted heavier the more senior you are.
- Spoken communication: narrating your approach clearly while you work. Most-neglected, highest-leverage. This is where the plan earns its keep.
- Behavioural: yes, even for engineers. A story bank for the “tell me about a time” round.
A sane weekly split
If you have a few weeks, roughly:
~50% Coding patterns (arrays, hashing, trees, graphs, DP basics) ~25% System design (framework + 1-2 prompts end to end) ~25% Out-loud practice (narrate solutions; mock the behavioural round) Week before: stop learning new material. Full simulations only.
That last quarter — doing it out loud — is the part people skip and the part that decides interviews. Solve problems while narrating. Explain a design to a wall, a friend, or a mock interviewer. The goal is to make “think and talk at the same time” automatic, so nerves can't take it away.
Adjust the mix for your level
One split doesn't fit every role. Rebalance.
Junior
Weight coding heaviest. You'll get more algorithmic rounds and lighter design. Your edge is clean fundamentals and clear narration — “here's my approach, here's the complexity.” Behavioural is mostly “can you communicate and are you coachable.”
Intermediate
Even split. Expect a real system design round and behavioural questions about ownership and conflict. Interviewers probe deeper on your code — “why this data structure, what's the trade-off.” You're expected to drive, not be led.
Senior or staff
Design and behavioural dominate; raw algorithm rounds shrink. The stories get harder — influence without authority, a call you got wrong, how you set technical direction. Coding still appears, but they're watching judgment and communication more than whether you nail an optimal solution. The STAR structure stops being optional here.
Two weeks out, working evenings. Days 1–7: two coding patterns a day, solved out loud, plus the design framework and one full prompt. Days 8–11: mixed mock rounds — a coding problem narrated end to end, then a design prompt, then three behavioural stories. Days 12–14: full simulations only, timed, out loud, no new material. You walk in having already done the thing, not having only read about it.
Don't over-index on volume
Five hundred problems half-understood is worse than a hundred you can explain. Interviewers probe; if you pattern-matched your way to an answer you can't reason about, the first “why?” exposes it. Depth is what survives follow-up questions.
Treating prep as pure input — watching solutions, reading design write-ups, collecting resources — and never once performing under a clock with your mouth moving. Input feels productive and rarely transfers. If you've never rehearsed the actual act, the real interview becomes your first live rep. See how many mocks you actually need.
Rehearse the remote format specifically
Almost all of this now happens over a call — a shared editor for coding, a collaborative canvas for design, a screen-share for both. That's its own skill, and it's worth a rehearsal or two. The traps are practical: going silent while you type, wrestling an unfamiliar editor, talking over the interviewer on a laggy line, or freezing because you can't read the room the way you would in person.
- Practise in the actual medium. Solve in a plain shared editor with no autocomplete, not your fully-loaded IDE — that's closer to what you'll get.
- Narrate through the silence. On a screen-share, a quiet cursor is unnerving. Say what you're about to type before you type it.
- Confirm before you move on. “Shall I go deeper here, or move to the next part?” keeps a video call in sync when body language is missing.
The week before
Ease off cramming and switch to full simulation — timed, out loud, end to end. You're not learning new material now; you're rehearsing performance under pressure. That single shift is the difference between knowing the material and being able to access it when your heart's pounding. If the freeze is your specific fear, the mechanics of not going blank are worth a read on their own.
- Can you solve a medium problem while narrating, in one sitting, without going silent?
- Can you run a design prompt end to end in 40 minutes?
- Do you have 5–6 behavioural stories in STAR shape, ready to adapt?
- Have you done at least a couple of full, timed, out-loud simulations?
- Is your mix weighted for your actual level, not a generic template?
Pick one medium coding problem you already know the answer to. Solve it again from scratch, out loud, on a timer, as if being watched — restate, plan, narrate, test. Knowing the answer and performing the solution are different skills, and this exposes the gap fast.
The whole plan comes down to one reframe: prep isn't studying, it's rehearsal. Read less, perform more.
Turn your prep plan into reps
Run realistic voice mock interviews — coding, design, and behavioural — and get a scored report with a model answer for every question. Free to start.
Start freeFrequently asked questions
How long does it take to prepare for a technical interview?
Commonly a few weeks of focused prep: coding patterns, a system design framework, behavioural stories, and — crucially — practising out loud. Quality and realistic simulation matter far more than raw problem count.
Is LeetCode enough to prepare for a technical interview?
No. LeetCode builds coding fluency but ignores spoken communication, system design, behavioural rounds, and performing under pressure — the things that actually trip people up. Balance it with out-loud practice and mock interviews.
How should I split my prep time?
Roughly half on coding patterns, a quarter on system design, and a quarter on out-loud practice — then rebalance for your level. Juniors weight coding; seniors weight design and behavioural. The week before, switch entirely to full simulations.