Practice
Coding rounds without grinding
Most of the value is in a small number of patterns practised badly on purpose — spaced out, from a blank page, out loud.
The default advice is to solve a large number of problems. I did that, and it worked less well than the hours suggested it should. The failure mode is specific and easy to miss: solving a problem you have seen recently exercises recognition, not retrieval, and recognition is not what the interview asks for. You feel fluent and you are only familiar.
What I would do instead, in order of how much it mattered:
- Cover the pattern inventory once, carefully. There are perhaps a dozen shapes that account for the large majority of what gets asked. Cover them slowly enough to understand why each one works, not just what its code looks like.
- Re-solve, don't re-read. Come back to a problem three or four weeks later and write it again from an empty file. If you can, you know it. If you can only recognise the trick, you do not.
- Practise out loud, alone if necessary. The narration is a separate skill from the solving, it is scored, and it competes for working memory. Practising them together is the only way to find out how much it costs you.
- Write in a plain editor with no completion. Interview editors have no autocomplete, no type checking, and no run button. Discovering how much you leaned on those is better done in your own room.
The inventory
Roughly ordered by how often I have seen each one asked or asked it myself. The point of a list like this is not to memorise it — it is to notice when you have a gap that you have been quietly avoiding for months.
| Pattern | Recognise it by | Typical cost |
|---|---|---|
| Hash map counting | Anything about duplicates, frequencies, pairs summing to a target | O(n) |
| Two pointers | Sorted input, or a partition you can maintain from both ends | O(n) |
| Sliding window | Longest or shortest contiguous run satisfying a property | O(n) |
| Binary search | Sorted array — or a monotone predicate over an answer range | O(log n) |
| Sorting first | Intervals, scheduling, anything where order removes a case | O(n log n) |
| Heap / top-k | "K largest", streaming medians, merging sorted sources | O(n log k) |
| Graph BFS | Shortest path with uniform edge cost, level-by-level spread | O(V+E) |
| Graph DFS | Connectivity, cycle detection, topological order | O(V+E) |
| Tree recursion | Anything on a binary tree; usually a post-order return value | O(n) |
| Backtracking | Enumerate all valid arrangements; permutations, subsets, boards | exponential |
| 1-D dynamic programming | Overlapping subproblems along one index; "ways to", "minimum cost to" | O(n) |
| 2-D dynamic programming | Two sequences compared, or a grid with choices at each cell | O(nm) |
| Union-find | Merging groups, connectivity queries in any order | near O(1) |
| Prefix sums | Repeated range queries over a static array | O(1) per query |
| Monotonic stack | Next greater or smaller element, spans, histograms | O(n) |
Two entries on that list are worth more attention than the rest, because they are where under-prepared candidates most often stall: binary search over an answer range rather than an array, and dynamic programming stated as a recurrence before any code is written. Both are learnable in an afternoon each and both come up far more than their reputation suggests.
A practice schedule that survives a job
The schedule below assumes an hour a day, which is what I could actually sustain. It is built around returning to problems rather than accumulating them.
One pattern per day from the inventory. Two problems each: one worked through with the explanation open, one attempted cold. Keep a one-line note per problem recording the idea, not the code.
Mixed sets of three problems with the pattern label hidden. This is the first honest test — in an interview nobody tells you which drawer to open, and picking the drawer is most of the difficulty.
Timed, narrated, from an empty file. Forty-five minutes, speaking throughout, no run button. Re-solve anything from week 1 that you have not touched since, and expect to be humbled by at least one of them.
Two or three problems a week, always mixed, always cold. Add anything you failed back into the queue three weeks out rather than immediately.
If you take one thing from this page: the review interval is the active ingredient. A problem re-solved after three weeks is worth several solved once. The discomfort of having forgotten something you "knew" is not a sign the practice is failing — it is the practice working.
Structuring the forty-five minutes
Roughly, and adjusting for how much the interviewer talks:
- Minutes 0–5, clarify. Restate the problem in your own words. Ask about input size, duplicates, empty input, and whether the input is sorted or mutable. State the examples you will use later as tests. This is scored, and skipping it to look decisive costs more than it saves.
- Minutes 5–12, choose an approach. Say the brute force out loud, give its complexity, then say what makes it wasteful and what structure removes the waste. Do not write code before the interviewer has agreed the plan is worth writing.
- Minutes 12–33, write it. Narrate structure, not syntax — "outer loop over the right edge, and I'll shrink from the left while the window is invalid" is useful; reading your own code aloud is not.
- Minutes 33–42, trace an example. Walk your own code through the example you chose earlier, line by line, with actual values. This is where you find your bug rather than having it found for you, and the difference is worth a great deal.
- Minutes 42–45, close. State time and space complexity, name the edge cases you handled, and name one you would test first if you had another ten minutes.
Failure modes I saw most often
- Coding in silence. Common, understandable, and expensive. A stretch of quiet reads as being stuck even when it is concentration. If you need to think, say that you need a moment to think — that sentence costs two seconds and buys a minute.
- Optimising before there is anything to optimise. A working brute force at minute fifteen is a far better position than an elegant half-written idea at minute forty.
- Defending a broken approach. When the interviewer offers a counterexample, the correct move is to work through it and say what it breaks. Arguing costs the round.
- Skipping the trace. The single highest-return habit and the first thing dropped under time pressure.
- Treating a hint as a failure. Interviewers offer hints because they want you to succeed; how gracefully you take one is itself a signal, and refusing one is worse than needing it.