Coding Interview Prep: What Gets Scored and a 6-Week Plan

The four signals coding interviewers score, the patterns behind most problems, complexities people get wrong, and a week-by-week study plan.

2026-10-24 · 6 min read

Two candidates get the same problem: find the length of the longest substring without repeating characters. The first writes a correct O(n) sliding window in eight minutes, in silence, and says "done". The second talks through a brute force, explains why it is O(n²), spots the sliding window, codes it in fifteen minutes, then traces "abba" by hand and fixes an off-by-one before the interviewer mentions it. In many debriefs the second candidate gets the stronger score.

Coding interviews reward a visible process as much as a correct answer. This guide covers what the round measures, a study plan by week, the patterns worth learning, and the mistakes that sink otherwise capable engineers. Track your topics in the Coding Interview Prep Checklist as you work through them.

What interviewers score

Most coding rubrics, whatever they are called, measure four things:

An optimal solution helps, but it is one input. A clean brute force plus a clear explanation of the faster approach can pass. A fast, silent, buggy solution often does not.

The seven-step method in practice

The checklist page lists seven steps. In a 45 minute round they compress to something like this:

1. Understand (2 to 3 min). Restate the problem. Ask about input size, value ranges, duplicates, empty input, and what to return when there is no answer.
2. Examples (2 min). Work one normal case and one edge case by hand.
3. Break it down (2 min). Name the pattern you think applies and why.
4. Plan (3 to 5 min). Describe the algorithm and its time and space complexity before writing code. Get a nod from the interviewer.
5. Code (15 to 20 min). Write it cleanly, narrating as you go.
6. Test (5 min). Trace your own example through the code, then the edge case.
7. Optimize (remaining time). Discuss what you would improve and the trade-offs.

The step people skip is 4. Coding before agreeing on a plan is how you end up rewriting half your solution with ten minutes left.

Patterns that cover most problems

Interview problems are drawn from a fairly small set of patterns. Learn to recognise the trigger in the problem statement:

Complexities you must not get wrong

Interviewers notice when a candidate states a complexity confidently and incorrectly. The usual offenders:

• Quicksort is O(n log n) on average and O(n²) in the worst case. Merge sort is O(n log n) in all cases but uses O(n) extra space.
• Hash map operations are O(1) on average and O(n) in the worst case, when many keys collide.
• Building a heap from n items is O(n). Inserting n items one at a time is O(n log n).
• Binary search is O(log n), but only on sorted data. Sorting first costs O(n log n).
• String concatenation in a loop can be O(n²) in languages with immutable strings. Use a list and join.
• Recursion uses stack space. A DFS over a tree of height h needs O(h) space, which is O(n) for a skewed tree.

A quick self-check: say the complexity, then say what the input size limit implies. With n up to 100,000, O(n²) is ten billion operations, which is too slow; O(n log n) is about 1.7 million, which is fine.

Worked example: two sum, three ways

"Given an array and a target, return the indices of two numbers that add up to the target."

def two_sum_brute(a, target):
    # 1. Brute force: O(n^2) time, O(1) space
    n = len(a)
    for i in range(n):
        for j in range(i + 1, n):
            if a[i] + a[j] == target:
                return [i, j]

    # 2. Sort plus two pointers: O(n log n) time, but sorting loses
    #    the original indices unless you sort (value, index) pairs.

def two_sum(a, target):
    # 3. Hash map: O(n) time, O(n) space
    seen = {}
    for i, x in enumerate(a):
        if target - x in seen:
            return [seen[target - x], i]
        seen[x] = i

Saying all three out loud, with the trade-off for each, takes about a minute and shows the interviewer the full range of your thinking. Then code the hash map version. Test it on [3, 3] with target 6: checking before inserting is what makes duplicates work.

A study plan by week

Most working engineers need four to eight weeks at 8 to 10 hours a week. A six-week version:

• Week 1: Arrays, strings, hash tables. Two pointers and sliding window. Get the seven steps into your habits from the first problem.
• Week 2: Binary search (including on the answer space), linked lists, stacks and queues.
• Week 3: Trees: traversals, BST operations, lowest common ancestor. Heaps.
• Week 4: Graphs: BFS, DFS, topological sort, union-find. Dijkstra for weighted paths.
• Week 5: Dynamic programming and backtracking. These take the longest, so do not squeeze them.
• Week 6: Mixed problems under a 45 minute timer, plus at least three mock interviews with another person.

Tick a topic in the checklist only when you can solve a new problem of that type without hints. The percentage is for you, so keep it honest. Revisit any problem you failed after three or four days and solve it again from a blank file.

Common mistakes

Not asking clarifying questions. Input constraints change the right answer. Ask.

Coding in silence. The interviewer cannot score thinking they cannot hear.

Ignoring the edge cases you listed. Empty input, one element, all duplicates, negative numbers, integer overflow.

Grinding one topic. Three hundred array problems will not help when the question is a graph.

Not testing. Trace your code with a real example before you say you are finished. Finding your own bug is a positive signal; having it found for you is a negative one.

Putting it together

Use a stopwatch for every practice problem, because time pressure changes how you think. Keep a short log of each problem: pattern, mistakes, time taken. Once coding feels steady, start on the System Design Interview Framework if your loop includes it, and prepare behavioral stories with the STAR answer builder. Candidates who prepare for all three rounds usually do better than those who spend every hour on algorithms.

Open the Coding Interview Prep Checklist