On this page
The round you think it is, and the round it actually is
Who this is for
Anyone walking into a live coding or data-structures round and quietly terrified of going blank: new grads, self-taught switchers, and anyone who can solve problems at home but freezes the moment someone is watching the cursor.
Most people prepare for the coding round as if it's a vocabulary test: memorise enough solutions and hope your problem comes up. It almost never does, and that framing is why the round feels like a trap. The interviewer is not checking whether you've *seen* this exact question. They're watching how you behave when you haven't.
Here's the order they actually score in: can you understand the problem, can you communicate while you work, can you produce something correct, and only then, can you make it efficient. Optimization is last. A clear, talked-through, working brute force beats a half-remembered optimal solution typed in silence that doesn't run.
They're not hiring the candidate who already knew the answer. They're hiring the one they'd want next to them at 2am on a problem nobody has seen before.
What's actually on the scorecard
Interviewers usually fill a rubric, not a gut feeling. The exact wording varies, but the categories are remarkably consistent across companies. Knowing them tells you where to spend your energy.
| What they score | What it means in the room |
|---|---|
| Problem-solving | Do you find a path to a solution, or do you stall? Can you break a big problem into smaller ones? |
| Communication | Can they follow your thinking out loud? Silence reads as 'lost', even when you're not. |
| Correctness | Does the code actually work on the example and the edge cases, not just look right? |
| Code quality | Readable names, sane structure, no tangle. Would they want to review this in a real pull request? |
| Optimization | Can you reason about time and space, and improve a first attempt? Scored last, not first. |
Pro tip
Notice 'memorised the answer' is not a row. Reciting a solution you clearly didn't derive often scores you down, because the interviewer can't see any problem-solving to grade.
Stop grinding 500 problems. Learn the patterns.
The single biggest waste of prep time is solving hundreds of random problems hoping to bump into the right one. Problems feel infinite. The underlying patterns are not. Most interview questions are one of roughly fifteen recurring shapes wearing a different costume. Learn to recognise the shape and the right data structure falls out almost for free.
| Pattern | Signal that it applies | Example problem type |
|---|---|---|
| Two pointers | A sorted array or list, looking for a pair or a window from both ends | Find two numbers that sum to a target; reverse in place |
| Sliding window | 'Longest / shortest / max sum' over a contiguous run of elements | Longest substring without repeats; max sum of k consecutive items |
| Hashing (map / set) | 'Have I seen this before?' or 'how many of each?' in one pass | First non-repeating item; group items by a key; deduplicate |
| BFS | Shortest path or level-by-level spread on a graph or grid | Fewest steps in a maze; nearest exit; level-order of a tree |
| DFS / backtracking | Explore all paths, combinations, or fully traverse a structure | All subsets; valid permutations; can a path reach a goal |
| Binary search | A sorted space, or a yes/no answer that flips at some threshold | Find an element in a sorted list; smallest value that satisfies a rule |
| Heap (priority queue) | 'Top k', 'k smallest', or repeatedly pulling the next best item | K closest points; merge sorted streams; running median |
| Dynamic programming | 'How many ways' or 'best value' with overlapping subproblems | Min coins for an amount; longest common subsequence; grid paths |
| Stack | Matching pairs, or 'most recent unmatched thing' | Valid brackets; next greater element; evaluate an expression |
Work *depth-first* through these, not breadth-first across random problems. Take one pattern, solve five or six problems that use it, and explicitly name the signal each time: "sorted array, looking for a pair, so two pointers." After a couple of dozen problems chosen this way, new questions stop feeling random. You start seeing the skeleton under the wording.
Note
If the underlying data structures feel shaky, the patterns won't stick. The platform's Data Structures & Algorithms learning path builds those foundations first, so the patterns above have something to attach to.
The in-room method: a script for when your mind goes blank
The freeze happens because the room is silent and you're trying to leap straight to the perfect answer. The fix is a fixed sequence you can run on autopilot. Even when you have no idea yet, you always know the next step, and the next step always produces something to say.
- 1
Restate the problem in your own words
Say it back: inputs, outputs, constraints. "So I get an array of integers, possibly with duplicates, and I return the two indices that sum to the target. Is the input sorted? Can the same index be used twice?" This catches misunderstandings before they cost you, and the clarifying questions are themselves scored.
- 2
Work one example by hand
Pick a small concrete input and solve it on the whiteboard the slow human way. This is where the pattern reveals itself, and it gives you test data for later. Add one nasty edge case now: empty input, a single element, all duplicates.
- 3
State a brute force out loud first
"The naive approach is to check every pair, that's O(n squared). Let me get that working, then improve it." This guarantees you have something correct on the board and shows you can reason about cost. Never sit in silence hunting for the optimal solution.
- 4
Then optimize, narrating the trade-off
"I'm doing repeated lookups, a hash map turns each into O(1), so the whole thing drops to O(n) time for O(n) extra space." Naming what you trade away is the optimization conversation they want to hear.
- 5
Write the code, still talking
Say what each block does as you type it. Use real variable names. If you hit a tricky line, say what you intend before you write it, so a wrong character doesn't read as a wrong idea.
- 6
Test it yourself, out loud
Walk your example through the code line by line. Then run the edge cases from step two. Finding and fixing your own bug scores higher than the interviewer finding it. End by stating the final time and space complexity.
When you're genuinely stuck
Don't freeze and don't go silent. Narrate the wall: "I'm trying to avoid the nested loop but I haven't found the structure that lets me. Let me reconsider what I'm repeating." Stuck-but-talking is a strong signal. Stuck-and-silent looks identical to stuck-and-lost. Asking for a small hint is normal and rarely costs you much; staring at the wall costs you more.
Same problem, two candidates
Here are two people solving the exact same question with the exact same final code. One narrates, one doesn't. The interviewer can only grade what they can hear.
Silent panic
[Reads the problem. Long pause. Starts typing immediately. Deletes it. Types again. Five minutes of silence broken only by 'hmm'. Produces a working hash-map solution but never says a word about why, never tests it, and waits for the interviewer to ask if it's done.]
Narrated thinking
"Let me restate it: I return two indices that sum to the target. Quick question, is the array sorted, and can I reuse an index? Okay. Brute force is check every pair, O(n squared) time, no extra space. That works but it's slow. The repeated work is the lookup, so I'll keep a hash map of value to index as I go, and for each number check if its complement is already in the map. That's one pass, O(n) time, O(n) space. Let me code it... and now let me trace [2, 7, 11] with target 9 to be sure, plus the empty array and a single element."
- Same final algorithm, same lines of code. The difference is entirely audible, and audible is what gets scored.
- The 'after' candidate gave the interviewer five separate things to mark: clarifying questions, brute force, complexity reasoning, the optimization trade-off, and self-testing.
- The 'silent' candidate may be just as smart, but the rubric has nothing to grade. 'Correct code, no communication' is a borderline result, not a pass.
- Restating and clarifying up front cost about thirty seconds and prevented solving the wrong problem, the single most common way strong coders fail this round.
A prep plan that survives interview week
Cramming the weekend before does almost nothing, because pattern recognition is built by spacing, not by volume in one sitting. Treat it like training a muscle: short, frequent, deliberate, with rest in between. The goal is recognition speed, not a high problem count.
- 1Pick one pattern per few days. Solve five or six problems in it and name the signal out loud each time before you write any code.
- 2Solve out loud, alone, from day one. Talking while coding is a separate skill from coding, and it's the one that breaks first under pressure. Build it early.
- 3Time the back half of your sessions. Give yourself the real clock, around 30 to 45 minutes, so the pace stops feeling alien on the day.
- 4Keep a short log of problems you got wrong and revisit them a few days later, not the same day. The delay is what moves a pattern into long-term recall.
- 5Do one or two mock interviews with another person before the real thing. The watched-cursor feeling is the actual thing being tested, and you can rehearse it.
- 6The day before: rest and re-read your own pattern notes. Do not try to learn a new pattern. Tired pattern-matching is worse than rested recall.
What to carry into the room
- They score process, communication, and correctness before optimization. Talked-through and working beats silent and clever.
- Don't grind 500 random problems. Learn ~15 patterns and practise naming the signal that triggers each one.
- Run the same script every time: restate, example by hand, brute force out loud, then optimize, then test your own code.
- Never go silent. Stuck-but-narrating scores well; stuck-and-silent is indistinguishable from lost.
- Build recognition with spaced, out-loud practice over weeks, not a cram the night before.
Reading is step one. Now do it for real.
When you're ready, the platform has live mock interviews and portfolio-grade capstone projects you can actually talk about.
Keep reading
This is general, educational career guidance, not legal, financial, immigration, or professional advice. Examples are illustrative and simplified. Norms vary widely by country, company, role, and over time, so always verify what applies to your own situation. Nothing here guarantees an interview, an offer, or any particular outcome.