Technical interview patterns

The common advice is to solve some large number of problems. The number is the wrong target. Two candidates who have each done two hundred problems can have completely different outcomes: the one who did them shuffled and forgot most of them, and the one who worked in blocks by pattern and can now classify an unseen problem in thirty seconds.

Recognition is the actual skill under test. In a live round you get a problem you have not seen, and the first two minutes decide the round — either you identify the shape and start reasoning toward a known technique, or you flail. Everything below is organised to build that classification reflex.

A realistic target is around one hundred fifty well-chosen problems worked in pattern blocks, with the harder ones revisited. That beats five hundred shuffled problems comfortably, and it fits inside a working engineer schedule.

The highest-frequency family in coding rounds. Two pointers walk a sorted array from both ends or at different speeds; sliding window maintains a contiguous range that expands and contracts; prefix sums precompute cumulative totals so any range query becomes constant time.

The unifying idea is avoiding the nested loop. Most of these problems have an obvious quadratic solution, and the pattern is the linear one. Say the brute force out loud, state its complexity, then improve it — interviewers explicitly reward that progression.

Not glamorous and extremely high-yield. A hash map turns a linear scan into a constant-time lookup and is the difference between quadratic and linear in a large fraction of problems. Frequency counting, deduplication, grouping, and complement lookups all reduce to it.

The interview-relevant subtlety is knowing when a hash map is the wrong choice: when you need ordering, when you need range queries, or when the memory overhead matters. Being able to say why you are paying O(n) space is part of the score.

Everyone knows binary search on a sorted array. The variant that separates candidates is binary search on the answer space: when the question asks you to minimise a maximum or maximise a minimum, and there is a monotonic feasibility check, you binary search over the possible answers rather than over an array.

The classic framing is: can we achieve the goal with budget X? If the answer is monotonic — feasible for every value above some threshold and infeasible below — you can binary search the threshold. Recognising this is a strong senior signal because most candidates never make the leap from searching data to searching answers.

Get the boundary conditions right and practise them deliberately. Off-by-one errors in the loop condition are the single most common way candidates lose an otherwise correct binary search.

Trees are the friendliest topic to prepare because the recursion is uniform: most tree problems are a depth-first traversal with a small amount of work at each node. Get comfortable writing pre-order, in-order and post-order without hesitating, and know which one a given problem needs.

Graphs extend the same traversals with a visited set. The main additions worth explicit practice are topological sort for dependency ordering, union-find for connectivity and grouping, and Dijkstra for weighted shortest paths. Grid problems are graph problems in disguise — treat each cell as a node with up to four neighbours and the pattern becomes obvious.

A heap gives you the smallest or largest element in logarithmic time, which is exactly what you want for top-k, merging sorted streams, and running statistics. The two-heap trick — a max-heap for the lower half and a min-heap for the upper — solves the running median family.

Interval problems are a separate small family with a reliable opening move: sort by start time, then sweep. Merging, inserting, and counting overlaps all follow from that. Meeting-rooms style problems combine both, using a heap to track the earliest ending interval while sweeping.

The topic candidates fear most, largely because it is usually taught as a list of tricks instead of a method. It is a method. Find the recurrence first, in plain language: what is the answer for state i in terms of smaller states? Write the brute-force recursion. Add memoisation. Only then convert to a bottom-up table if it helps.

Most interview DP falls into a handful of shapes, and the state definition is where the difficulty actually lives. If you can state precisely what dp[i] or dp[i][j] means in one sentence, the transition usually follows in a minute. If you cannot, no amount of staring at the table will help.

In a real interview, a working memoised recursion with correct complexity is a perfectly good answer. Do not burn ten minutes converting to tabulation for constant-factor gains unless the interviewer asks for it.

Backtracking is systematic exhaustive search with pruning: choose, explore, un-choose. The template barely changes between problems, so the work is in defining the choice at each level and the condition that prunes a branch early.

Be explicit about complexity here, because it is exponential and interviewers want to hear you acknowledge that. Saying "this is O(n times 2 to the n) and the pruning helps in practice but does not change the worst case" is exactly the kind of statement that earns marks.

Train the mapping deliberately. For the first month of practice, before writing a line of code, say out loud which pattern you think it is and which signal in the prompt told you. Getting this wrong is fine and informative; not doing it at all is what leaves recognition slow.

Naming the pattern in the interview is itself a scored signal. "This is asking for the longest contiguous substring with a constraint, so I am going to use a sliding window" tells the interviewer you have a plan before you write anything, and it gives them a chance to redirect you early if you have misread the problem.

Work five to ten problems of a single pattern back to back until the shape is automatic, then move on. Blocked practice builds recognition much faster than a shuffled list, because you are explicitly learning what the pattern looks like from different angles.

Then invert it. Once you have covered the patterns, do mixed sets where you do not know the pattern in advance — that is the interview condition, and it is a different skill from executing a pattern you have been told to use. A good rhythm is blocked practice while learning, mixed practice in the final few weeks.

Redo problems. Solving something once and never returning to it produces the illusion of coverage. Anything you struggled with should come back after a week and again after a month.

State time and space complexity for every solution, unprompted, and be ready to justify both. Candidates who wait to be asked look like they had not thought about it.

Know the trade-off you are making and say it. An O(n) solution using O(n) extra space versus an O(n log n) in-place one is a real decision, and articulating why you chose one is worth more than the choice itself. Also be honest about amortised versus worst case — claiming hash map operations are O(1) worst case is a small error interviewers do notice.

A candidate who produces a working optimal solution in silence often scores below one who produces a slightly weaker solution while narrating clearly. The round is a simulation of working with you, not a test with an answer key.

If you want a schedule rather than a reading list, this covers the material at a sustainable pace for someone working full time. Roughly five problems per pattern in week one of each block, then harder variants.