Coding Interview Questions: Categories, Patterns, and How to Prep

Most coding interviews pull from the same eight or nine question categories. Once you can recognize the category from the problem statement, you already know which tool to reach for. That recognition is what separates candidates who freeze from candidates who start writing.

Here's the short version:

• The categories are finite. Arrays/strings, hash maps, two pointers, linked lists, trees/graphs, recursion/backtracking, dynamic programming, and sorting/searching cover the large majority of what you'll see.
• Each category maps to a small set of patterns. Two Sum is a hash-map problem. "Find a pair that sums to a target in a sorted array" is a two-pointer problem. Same surface, different signal.
• The code is half the score. Interviewers also grade how you reason out loud, how you handle complexity, and how you respond when your first idea is wrong.
• Prep is pattern practice, not problem memorization. You can't memorize 2,000 problems. You can learn 12 patterns and apply them to anything.

This guide walks through each category with real example problems, the patterns to study, how to talk through a solution, and the mistakes that sink otherwise-strong candidates.

The core question categories

Below is a map of the categories that show up most, roughly ordered by how often they appear in a standard 45-minute coding round and how hard they tend to be. Use it to decide where to spend your study time.

A few notes on reading this table. Arrays, strings, and hash maps are the bread and butter of warm-up rounds and phone screens, so you'll touch them constantly. Trees and graphs dominate on-site loops. Dynamic programming is the one that varies most by company: some firms rarely ask it, others lean on it heavily, so check the interview reports for the place you're targeting before you over-invest.

Arrays, strings, and hash maps

These three travel together. Most array and string problems get easier the moment you add a hash map.

A classic example is Two Sum: given an array of numbers and a target, return the indices of the two numbers that add up to the target. The brute-force answer checks every pair in O(n²). The better answer walks the array once, storing each number's complement in a hash map, and finishes in O(n). The trade you're making is time for space, and that trade is exactly what the interviewer wants to hear you name.

Hash maps win because their average lookup, insert, and delete are constant time. As the Wikipedia entry on hash tables puts it, in a well-dimensioned table the average cost per lookup is independent of how many elements are stored. Any time a problem says "count occurrences," "find duplicates," or "check if you've seen this before," a hash map or set is usually the answer.

Other common problems here: valid anagram (compare character counts), group anagrams (use a sorted-string key in a map), and longest substring without repeating characters (a set plus a sliding window).

Two pointers and sliding window

Two pointers is what you reach for when a hash map would work but you can do better by exploiting order. Given a sorted array and a target sum, you put one pointer at the start, one at the end, and move them inward based on whether the current sum is too big or too small. That's O(n) time and O(1) extra space, beating the hash-map version on memory.

The sliding window is the same idea applied to contiguous subarrays or substrings. Maximum sum subarray of size k, minimum window substring, and longest substring with at most k distinct characters all shrink and grow a window instead of recomputing from scratch. The signal to watch for: the word "contiguous" or "consecutive" in the problem statement.

Linked lists

Linked-list problems test whether you can manipulate pointers without losing your place. The greatest hits are reversing a linked list, detecting a cycle, and finding the middle node.

Cycle detection is worth memorizing because the trick is elegant and reused: run a slow pointer one step at a time and a fast pointer two steps at a time. If they ever meet, there's a cycle. If the fast pointer hits the end, there isn't. This "fast and slow pointer" technique also finds the midpoint of a list in a single pass.

Trees and graphs

This is where on-site rounds get serious. Almost everything reduces to a traversal — visiting each node exactly once — which the tree traversal literature splits into depth-first (pre-order, in-order, post-order) and breadth-first orderings.

Depth-first search (DFS) uses recursion or an explicit stack and is your default for "explore every path" problems: maximum depth of a binary tree, path sum, number of islands on a grid. Breadth-first search (BFS) uses a queue and is your default for "shortest path in an unweighted graph" or "level-by-level" problems: binary tree level-order traversal, word ladder, rotting oranges.

A practical tip: when a problem mentions "shortest," "fewest steps," or "minimum number of moves" on an unweighted graph, start with BFS. When it mentions "all paths," "connected components," or "does a path exist," start with DFS.

Recursion, backtracking, and dynamic programming

These three are a family that scales up in difficulty.

Recursion is the base skill — a function that calls itself on a smaller input. Backtracking is recursion that builds a candidate solution one piece at a time and abandons a branch the moment it can't lead to a valid answer, which is exactly how Wikipedia describes the technique. Classic backtracking problems include generating all permutations, subsets, combination sum, and N-queens. The pattern is always the same: choose, explore, un-choose.

Dynamic programming (DP) is the hardest category and the one candidates fear most. Dynamic programming breaks a problem into overlapping subproblems and stores each subproblem's answer so you never recompute it. The entry-level problems are climbing stairs, house robber, and coin change; the medium ones are longest common subsequence and edit distance. The way in is to ask two questions: what is the smallest subproblem, and how does a bigger answer build on smaller ones? If you can write the recurrence, the table fills itself.

If you want a broader walkthrough of non-coding rounds too, our guide to technical interview questions covers the behavioral and systems side that often bookends the coding portion.

Sorting and searching

You rarely have to implement a sort from scratch, but you do need to know when sorting first makes a problem trivial — like finding duplicates, merging intervals, or the two-pointer setup above. Sorting costs O(n log n), so always check whether it's worth it.

Searching is mostly binary search, which runs in O(log n) on sorted data by halving the search space each step, as the binary search reference confirms. Beyond the textbook version, interviewers love "binary search on the answer" problems — search in a rotated sorted array, find peak element, median of two sorted arrays — where the array isn't obviously sorted but the solution space still is.

Patterns to study, mapped to when they apply

Categories tell you what data you're working with. Patterns tell you what to do. This table pairs the most reusable patterns with the trigger that should make you reach for them.

The payoff of learning patterns instead of problems is leverage. A few dozen patterns generalize across the thousands of problems on practice platforms, so once "this is a sliding-window problem" clicks, every future window problem is recognition rather than invention.

How to talk through a solution out loud

Interviewers grade your thinking as much as your code. Silence reads as being stuck, even when you're not. Use a consistent structure so you never go quiet:

1. Restate the problem and confirm the inputs. "So I'm given an array of integers that may have duplicates, and I return the indices — not the values — of two that sum to the target. Can the same element be used twice?" Clarifying questions are points, not weakness.
2. State a brute-force approach first. Naming the O(n²) version shows you understand the problem before you optimize. Then say why it's not good enough.
3. Narrate the optimization. "If I store complements in a hash map, I trade O(n) space for O(n) time." This single sentence is often what gets you the offer over an equally correct but silent candidate.
4. Walk a small example by hand before coding, then write the code while explaining each line.
5. Test out loud. Run through an empty input, a single element, and a case with duplicates. Catching your own bug is far better than the interviewer catching it.

If you want to rehearse the soft mechanics — pacing, recovering from a wrong turn, reading the room — our guide on how to ace an interview pairs well with the technical drilling here.

Time and space complexity, briefly

You should be able to state the time and space cost of every solution you write, in Big O notation — the standard way to describe how an algorithm's cost grows as its input grows. A quick reference for the costs that come up constantly:

• O(1) — constant. Hash-map lookup, array index access.
• O(log n) — logarithmic. Binary search, balanced-tree operations.
• O(n) — linear. A single pass through the data.
• O(n log n) — the cost of a good comparison sort.
• O(n²) — quadratic. Nested loops over the same input; a red flag to optimize.
• O(2ⁿ) — exponential. Naive recursion without memoization; usually a sign you need DP.

Space complexity counts the extra memory your solution allocates — the hash map, the recursion stack, the DP table. Stating both numbers unprompted signals seniority. Getting the optimal time but ignoring an O(n) space cost you could have avoided is a common way to leave points on the table.

Mistakes that sink strong candidates

• Jumping to code before clarifying. Solving the wrong problem fast is still solving the wrong problem. Ask about input ranges, duplicates, empty cases, and what to return.
• Going silent under pressure. When you're thinking, say what you're thinking. "I'm trying to decide between sorting first or using a heap" keeps the interviewer with you.
• Memorizing solutions instead of patterns. A slightly reworded problem will expose memorization instantly. Understand why the approach works.
• Ignoring edge cases. Empty arrays, single elements, all-duplicate inputs, and integer overflow are where bugs hide and where careful candidates stand out.
• Forgetting to test. Walking through your own code with a concrete example catches more bugs than re-reading it.
• Not stating complexity. If you don't say it, the interviewer assumes you don't know it.

How to prep efficiently

You don't need to grind a thousand problems. A focused plan beats raw volume:

• Learn data structures first, patterns second. You can't recognize a graph problem if you're shaky on what a graph is. Get fluent with arrays, hash maps, linked lists, stacks, queues, trees, and graphs before pattern-drilling.
• Practice by pattern, not at random. Do five sliding-window problems in a row until the shape is automatic, then move to the next pattern. Curated lists like the Blind 75 are organized this way for a reason.
• Simulate the real thing. Set a 35-minute timer, talk out loud the whole time, and write code in a plain editor without autocomplete. The pressure of the clock and the voice is half the skill.
• Review your wrong answers. A problem you got wrong and then understood teaches more than three you breezed through.
• Specialize for your target. If you're aiming for front-end roles, weight your prep toward the language and DOM problems in our JavaScript interview questions guide; if you're interviewing for senior roles, budget time for system design interview questions, which often carry more weight than the coding round.

Two to four weeks of focused, pattern-based practice is enough for most candidates to walk in confident.

Get in front of the person who decides

Solving the problem on the whiteboard gets you to the offer conversation. Getting the interview in the first place is the harder gate — and it's rarely won through the apply button. Articuler helps jobseekers find the actual hiring manager or engineering lead behind a posting using semantic search across 980M+ profiles, then build a Playbook on what that person works on so your conversation lands. Its AI-drafted outreach earns roughly 8x the reply rate of a generic cold message, which means more first-round interviews to put this prep to work on.

FAQ

How many coding interview questions should I do before an interview?

Quality beats quantity. A focused list of 75 to 150 problems organized by pattern is enough for most candidates, as long as you can re-solve each one and explain why the approach works. Doing 500 problems you've forgotten helps less than 100 you truly understand.

Which question categories are most common?

Arrays, strings, and hash maps dominate phone screens and warm-up rounds. Trees and graphs show up heavily in on-site loops. Dynamic programming is the most company-dependent — some firms rarely ask it, others lean on it — so check interview reports for your target before over-investing.

Do I need to memorize time complexity for every algorithm?

You don't memorize a table, but you should be able to derive the time and space cost of any solution you write. Knowing the handful of common classes — O(1), O(log n), O(n), O(n log n), O(n²) — and what causes each gets you most of the way there.

What's more important, getting the optimal solution or explaining my thinking?

Both are graded, but clear communication often tips a close decision. A candidate who narrates a working solution and names its trade-offs frequently beats one who silently produces slightly better code. Talk through your reasoning the entire time.

How long does it take to prepare for coding interviews?

For someone with a solid grasp of data structures, two to four weeks of focused, pattern-based practice is usually enough. If you're starting from rusty fundamentals, give yourself six to eight weeks and spend the first stretch on data structures before drilling patterns.