Coding Interview Preparation: Patterns, Platforms, and How to Practice

What a coding interview actually tests (signal vs noise)

A coding interview is not an exam in algorithms. The interviewer already has the answer. What they're measuring, in roughly this order, is: can the candidate clarify an ambiguous problem, can they pick a data structure that fits the constraints, can they write code that compiles and runs the first time on small inputs, and can they explain trade-offs without being defensive when challenged. The actual algorithm is the easiest of the five.

This matters because most candidates over-invest in the wrong axis. They solve four hundred LeetCode problems but freeze when the interviewer interrupts with "what if the input doesn't fit in memory?" They memorize the merge-sort recursion but can't say out loud why it's n log n instead of n squared. They write the optimal solution and then can't debug a one-character typo because they've never typed the problem from scratch in a real editor.

The signal an interviewer is looking for is a small set of behaviors:

• The candidate restates the problem in their own words before writing anything.
• The candidate names the data structure they're reaching for and says why before they declare it.
• The candidate writes code in roughly the order a person would type it — not the order a textbook would print it.
• The candidate runs through one small example by hand before claiming they're done.
• The candidate, when challenged, says "you're right" or "let me think about that" instead of defending the wrong answer.

Everything in this guide is in service of producing those five behaviors. The patterns, the platforms, the language choices — they all collapse to: can you, on a foreign machine, with someone watching, demonstrate that you think like an engineer rather than a person who has memorized solutions.

The eight data-structure patterns that cover ~80% of questions

If you sit down with the last two years of phone-screen and onsite questions from a typical FAANG-tier loop and group them by approach, the same eight patterns show up again and again. Internalizing these is more valuable than solving twice as many problems blind, because pattern recognition is what carries you when the question is phrased in a way you've never seen.

1. Two pointers

Two pointers is the answer when the problem is on a sorted array, a string, or a linked list, and you need pairs, partitions, or in-place rearrangement. The cost is linear in the input; the memory is constant. The classic prompts are "two-sum on a sorted array," "remove duplicates in place," "container with most water," and "is this string a palindrome." If the problem says sorted or palindrome or in place, reach for two pointers before anything else.

The trap is failing to maintain the invariant. Whenever the pointers move, you should be able to state in one sentence what's true between them — for example, "everything left of i is non-duplicate, everything right of j is unprocessed." If you can't articulate the invariant, your loop will be off by one.

2. Sliding window

Sliding window is two pointers' close cousin. Use it when the problem asks for a contiguous subarray or substring with a property — longest substring without repeating characters, smallest window that contains all letters, maximum sum of size-k. Both pointers move forward; the window grows on the right and shrinks on the left when the property is violated. Linear time, constant or alphabet-bounded space.

The diagnostic is the words contiguous and subarray or substring. The mistake to avoid is treating it as nested loops with a shortcut — if you find yourself recomputing the window's contents from scratch on each step, you've fallen back to O(n²) and lost the point.

3. BFS and DFS on trees and graphs

Breadth-first search is for shortest paths in unweighted graphs, level-order traversal of trees, and any problem where the answer depends on distance. Depth-first search is for connectivity, topological order, cycle detection, and most recursive tree questions. Both are linear in the size of the graph or tree.

In an interview, the choice is usually obvious from one keyword. Shortest, minimum number of steps, or level — that's BFS with a queue. All paths, count components, can we reach — that's DFS with recursion or an explicit stack. Get fluent enough that you can write the iterative form of both without having to think.

4. Heap and top-k

When the question asks for "the k largest," "the k smallest," "the median of a stream," or "merge k sorted lists," the answer is a heap. A min-heap of size k solves top-k-largest in O(n log k). Two heaps — a min-heap of the upper half and a max-heap of the lower half — give you a running median.

The interview value of recognizing this pattern is mostly in the explanation. You should be able to say, before writing any code, "I'll keep a min-heap of size k; I push every element and pop when the size exceeds k; at the end, the heap contains the answer." That sentence alone often is the answer.

5. Binary search on the answer

The vanilla binary search — find a value in a sorted array — is rarely asked anymore because everyone has memorized it. The interesting variant is binary search on the answer: when the problem has a monotonic predicate, binary-search the range of possible answers and check feasibility at each midpoint.

Examples: "split this array into k contiguous subarrays minimizing the largest sum," "find the smallest number of pages a worker can read so all books finish in m days," "minimize the maximum distance between gas stations." The pattern is always the same — define a predicate feasible(x) that's monotonic in x, binary-search x, and return the smallest or largest x for which the predicate holds. If you can name the predicate out loud, you have the solution.

6. Dynamic programming families

Dynamic programming is the pattern that intimidates the most candidates and is also the one with the cleanest taxonomy. Most DP problems fall into one of five families:

• One-dimensional state — climbing stairs, house robber, Fibonacci variants. The state is one index; the recurrence depends on a constant number of previous states.
• Two-dimensional grid — unique paths, minimum path sum, edit distance, longest common subsequence. The state is a pair of indices.
• Knapsack — 0/1 knapsack, subset sum, coin change. The state is "items considered so far × capacity remaining."
• Interval DP — burst balloons, matrix-chain multiplication, palindrome partitioning. The state is a pair of indices defining a range.
• DP on trees — house robber III, longest path in a binary tree. The recurrence is on subtree results combined at the parent.

If you can identify the family within the first thirty seconds, the recurrence is usually mechanical. The trap is jumping straight to code — write the recurrence on the whiteboard first, then the base case, then the iteration order, then the code. Reverse this and you will spend the rest of the round patching bugs.

7. Backtracking

Backtracking is the brute force you reach for when the problem asks for all solutions — all permutations, all combinations, all subsets, all valid Sudoku boards, all ways to partition a string into palindromes, N-queens, word search. The structure is recursive: try a choice, recurse, undo the choice, try the next.

The two skills the interviewer is looking for are pruning and the undo step. Pruning is the difference between exponential and merely large; the undo is the difference between correct and a subtle bug. Always state, before coding: "I make a choice, recurse, and then undo on the way back up." If you forget to undo, you'll silently corrupt the state for the next branch.

8. Graph traversal patterns

Beyond plain BFS and DFS, two graph patterns come up often enough to deserve their own slot. Topological sort — for course-schedule-style problems with prerequisites, schedule deadlines, and dependency resolution. The two implementations are Kahn's algorithm with in-degrees and a queue, and a DFS-based post-order. Either is fine; pick the one you can write without thinking.

Union-find (disjoint set) — for connectivity questions, redundant edge detection, the number of provinces, accounts merge, and most "are these two nodes in the same component" problems. With path compression and union by rank, the amortized cost is effectively constant per operation. Memorize the eight-line implementation; you'll use it more than you expect.

Together these eight patterns — two pointers, sliding window, BFS/DFS, heap top-k, binary search on the answer, DP families, backtracking, and topological sort plus union-find — cover roughly eighty percent of every coding round you'll see. The remaining twenty percent is mostly tries, segment trees, and bit manipulation, which are worth knowing but rarely show up in a one-hour screen.

Time complexity, properly: how to talk about Big-O on a whiteboard

Most candidates can recite that hash-map insertion is O(1) and merge-sort is O(n log n). Far fewer can do the thing that actually matters in an interview: derive complexity from the code in front of them, out loud, without flinching.

The mechanical procedure is:

1. Identify the loops and recursions. A single loop over the input is O(n). Two nested loops over the same input is O(n²). A loop with a halving step is O(log n). A recursion that splits in half and does linear work at each level is O(n log n).
2. Multiply across nesting, add across sequence. A loop containing a hash-map lookup is O(n) total, not O(n²). A loop followed by a sort is O(n + n log n) = O(n log n).
3. State the dominant term. O(n + log n) is O(n). O(n² + n) is O(n²). Drop the lower-order terms and the constant factors.
4. Separately state the space. Auxiliary memory is what your code allocates beyond the input. A recursion has stack space; a hash-map has O(n) space; sorting in place is O(1) extra.

Practice this out loud. The tell of an experienced candidate is that they say "this is O(n log n) time and O(n) extra space, dominated by the sort and the auxiliary array" before the interviewer asks. Saying it first signals confidence; saying it after, in a defensive tone, signals you're guessing.

When the interviewer pushes back — and they often will, especially on the constant factor — the right move is to engage with the specific pushback rather than recite the asymptotic again. "You're right, the constant factor here is large because each comparison does a string copy; if we precompute the keys, the constant drops by roughly a factor of k" is a good answer. "Well, asymptotically it's still O(n log n)" is a bad one.

Live coding platforms: where the interviews actually happen

Recruiters in 2026 distribute coding rounds across roughly seven platforms. Each has its own quirks; the editor that feels natural on one is sluggish on another. Practicing only in your IDE is a mistake — the platform's quirks become your quirks during a high-stakes round.

• LeetCode is the largest problem corpus and the closest thing to a shared lingua franca for interview questions. The editor is fine for short problems, less pleasant for long ones; the test runner is fast; the discussion threads are an underrated source of pattern recognition.
• HackerRank is what most large enterprises use for their first technical screen — companies in finance, consulting, and traditional tech. Its language coverage is broad, but its editor is heavier and the test cases are stricter about input parsing.
• Coderpad is the live-collaboration sandbox that most modern software companies use during the actual interview. It supports run-as-you-type for many languages and has a built-in drawing tool for system-design discussions.
• CodeSignal runs the General Coding Assessment that several large employers use as a single standardized score. Its problems are timed and varied; pacing is the main skill.
• InterviewBit has a curated track of problems organized by topic, which makes it easier to drill a single pattern at a time. The editor is closer to LeetCode than to Coderpad.
• HackerEarth is widely used in India and by companies hiring globally; problem quality varies but the platform is reliable.
• Codility is the platform of choice for several European companies; the test suite is opaque (you don't always see which case failed), which makes it a useful proxy for the discipline of reasoning about edge cases without the safety net of a debugger.

Practice on at least two of these before any real interview. Use one for breadth (LeetCode) and one for the feel of a live shared editor (Coderpad). The cognitive cost of the platform itself should approach zero by the time you're sitting in a real round.

Languages worth picking: when to choose which

You do not need to know twelve languages to interview well. You need one you can think in, and a passing reading knowledge of one or two others. Here is the honest list, in roughly the order most candidates should consider them.

• Python is the default. Concise syntax, batteries-included standard library (collections.Counter, heapq, bisect), no boilerplate, and a forgiving runtime. Recommended unless the role specifically demands otherwise.
• JavaScript and TypeScript are reasonable for front-end and full-stack roles. JavaScript has a friendly syntax for interviews; TypeScript adds the types but slows you down slightly because the compiler nags. Pick TypeScript only if the role is explicitly typed.
• Java is the safe pick for backend roles at large enterprises and for any company where the interviewer is likely to write Java themselves. The verbosity is a tax; the type system catches mistakes that Python won't.
• C++ is the right pick for systems, infrastructure, and game-engine roles, and for companies where the interviewer expects to see iterators and std::priority_queue. Pointer arithmetic and the absence of garbage collection give you more rope to hang yourself with under time pressure.
• Go is increasingly common in backend infrastructure and DevOps roles. The interview signal is mostly in concurrency questions; if you can write a correct goroutine + channel implementation of producer-consumer, you've shown you understand the language.
• Rust is rare in interview rounds but appearing more often in systems-heavy companies. Borrow-checker friction is real; do not pick Rust for an interview unless you've practiced with it specifically.
• Kotlin is the right pick for Android and a growing number of JVM backend roles; the syntax is friendlier than Java and the standard library is closer to Python's.
• Ruby is rare outside Rails-heavy companies; pick it only if the role uses it.
• SQL is its own discipline and shows up in data-engineering and analytics interviews. Window functions, common table expressions, and the difference between WHERE and HAVING are the consistent points of differentiation.
• PHP still shows up in companies with mature WordPress or Drupal installations; rarely the right interview pick unless the role demands it.
• Scala appears in data-platform companies (Spark, Akka). The functional features are powerful in interview answers but only if you're already fluent.

The single largest mistake candidates make on language is to switch under pressure. If you've spent six months drilling in Python, do not switch to Java the morning of the interview because you think the company "prefers" Java. They prefer correct working code in any of the supported languages. Use the one your fingers know.

System-design rounds: a brief frame for coding-prep

For senior coding loops, system design is the other half of the round. The 45-minute structure — clarify, estimate, high-level, deep-dive, trade-offs — is the same regardless of the role, and the level-by-level expectations shift sharply: L3 often gets an object-oriented design (parking lot, vending machine); L4 a real distributed-systems question (URL shortener, rate limiter); L5+ the senior expectation that you drive the round and name trade-offs without being asked.

The full level ladder, the five-component skeleton, and the recommended reading list (Alex Xu's System Design Interview and Kleppmann's Designing Data-Intensive Applications) live in our software engineer interview guide. For coding-focused prep, treat system design as the pillar that comes after pattern fluency: patterns and Big-O are table stakes; system design is what separates senior signal from mid-level signal, and it has to be drilled differently — by writing up cases, not by typing code.

How AI changes coding-interview prep

The most useful thing AI does for coding interview preparation, today, is also the least flashy: it gives you a tireless reviewer who can look at the solution you just wrote, spot the bug, classify it under one of the eight patterns, and produce a follow-up question in the same family.

Three concrete uses are worth committing to:

Pattern recognition drills. Paste a problem statement into a model and ask, before you read further, "which of the eight patterns is this, and why?" Compare the model's answer to your own. After fifty problems, your pattern-recognition reflex will be sharper than from solving twice as many problems without the meta-step.

Code review on your own solutions. Once you've submitted, ask the model to critique the code as if it were a senior engineer in a code review. Ask specifically: are there edge cases I missed; is the variable naming clear; is there a one-liner I'm reaching for that obscures the logic; does the time complexity match the constraints. The honest critiques get past the "great work!" reflex.

Live assistance during real interviews. This is what Acedly is built for: the recruiter on Zoom asks the question, the assistant transcribes it, identifies the pattern, drafts an outline grounded in your résumé, and renders the outline on a screen the interviewer can't see — typically in under two hundred milliseconds. The assistant doesn't write the code for you; it surfaces the right pattern and the right starting structure so your cognitive budget goes to typing the solution rather than remembering whether this is sliding window or two pointers.

The mistake in all three uses is to let the model think for you. The drills work because you commit to an answer first and then check; the code review works because you've already written code; the live assistance works because you've already drilled the patterns and only need a prompt to trigger recall. Used the wrong way, AI replaces your brain. Used the right way, it externalizes the bookkeeping so your brain is free to do the part it's actually good at.

AI-assisted prep vs LeetCode grind vs mock platforms vs textbooks

Most candidates do some mixture of all four. The question is not which is best — it's which mix matches your weakness. Here is the honest comparison.

Feature	AI-assisted prep	LeetCode grind	Mock-interview platforms	Textbooks (CLRS, EPI)
Best for	Pattern recognition, code review, live assistance	Volume and breadth	Time pressure and verbal explanation	Foundations, proof, and depth
Time to first useful signal	Same session	After ~50 problems	After 2–3 mocks	Multiple weeks
Catches blind spots	Yes, by classifying mistakes	Only via gut feel	Yes, via interviewer feedback	No (passive reading)
Builds the talking-out-loud skill	Partial (text-based)	Weak	Strong	None
Builds the typing-fast-on-foreign-platform skill	Indirect	Strong	Strong	None
Cost	Subscription (often <$50/mo)	Free or LeetCode Premium	Per-mock fees, often $50–$150	Book cost, time
Risk	Over-reliance, skipping the typing	Pattern blindness from rote	Coaching style varies	Slow, easy to skim

The combined recipe most working engineers settle on is: textbooks for foundations on a slow read, LeetCode for volume during commute and weekend blocks, AI-assisted review for pattern recognition and bug-spotting, and a small number of paid mocks in the two weeks before a real loop. None of these alone is enough; the mix is the point.

A four-week prep schedule that actually works

If you have four weeks before a loop, the schedule below is a workable allocation. It's not the only one, but it has the right shape — patterns first, platform fluency second, system design third, mocks last.

• Week 1 — patterns. Two hours a day. Pick one of the eight patterns each weekday. Solve five medium problems in that pattern. Write the one-sentence post-mortem for each. By the end of the week you should be able to recognize each pattern from the first read.
• Week 2 — language fluency on the platforms. Drop the variety. Solve fifteen problems on LeetCode and ten on whichever platform the company actually uses (HackerRank, Coderpad, or CodeSignal). The skill being trained is typing speed and editor familiarity, not algorithm.
• Week 3 — system design. Spend forty-five minutes per session, every weekday, on a different design question. Use the five-phase structure every time. Record yourself; play it back. The first three are bad. By the fifth, the structure starts to feel automatic.
• Week 4 — mocks and rest. Two paid mocks in the first half of the week. The second half: rest. Lighter problems, a system-design refresher, sleep. Do not cram in the last forty-eight hours; the marginal return is negative.

Adjust the weights to your own gaps. If you have eight years of system-design experience and limited LeetCode reps, flip weeks one and three. If you're early-career with a strong CS background, double the platform-fluency week. The constant is the rest week — every candidate underestimates how much sleep matters in the last forty-eight hours.

Frequently asked questions

How many LeetCode problems do I actually need to solve?

Should I use Python, Java, or C++ for coding interviews?

How do system-design interviews differ from coding rounds?

Is using AI to prepare for coding interviews considered cheating?

How early should I start coding interview preparation?

What's the single highest-leverage thing I can do tonight to improve?