How to Solve Any Coding Interview Question in 7 Steps

You can solve almost any coding interview question with 7 steps: clarify, work through examples, state a brute force, optimize, write the code, test it, and analyze complexity. The order matters more than speed, because each step produces something the interviewer can grade even if you never reach the optimal answer. Practice the routine on 20 to 30 problems over 2 to 3 weeks and it becomes automatic, leaving your attention free for the problem itself. This guide is for engineers preparing for coding rounds at FAANG and similar companies. It does not teach data structures from scratch; it teaches the method for applying them under a 45-minute clock.

What you need before you start

• Fluency in one interview language and its standard collections (lists, hash maps, sets, heaps, sorting).
• Basic Big-O analysis for loops, recursion and common data structure operations.
• A blank editor or doc without autocomplete, and a timer set to 45 minutes.
• A set of unseen medium problems, plus someone who can play the interviewer at least twice a week.

Step 1: Clarify the question and its constraints

Repeat the problem back in your own words, then ask about input size, value ranges, duplicates, empty input and the exact output format. Write the answers down where you and the interviewer can both see them.

Why it matters: Input size tells you the target complexity before you design anything. The USACO Guide's reference table suggests O(n^2) is workable up to about n = 7,500, while n up to 5 x 10^5 calls for O(n log n).

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

# Clarified:
# - n up to 10^5, values fit in 32-bit ints, may be negative
# - exactly one valid pair exists
# - cannot use the same index twice
# - return [i, j] in any order

Common mistake: Assuming the array is sorted because the sample input happened to be.

Step 2: Work through examples by hand

Build one example big enough to be interesting and one edge case, then solve both by hand before thinking about code. Say the answer out loud and confirm it with the interviewer.

Why it matters: Gayle Laakmann McDowell, author of Cracking the Coding Interview, makes this step 2 of her method and asks for an example that is "big enough and general purpose". Tiny or special-case examples hide the pattern you need.

Example: Before: [1, 2], target 3, which is too small to show anything. After: [7, -2, 11, 4, 15], target 9, where the answer is indices 1 and 2 (-2 + 11). Edge case: [3, 3], target 6 tests duplicates.

Common mistake: Using the interviewer's sample only. Make your own example, too.

Step 3: State a brute force solution first

Describe the simplest correct approach and its complexity in two or three sentences. Do not code it yet unless the interviewer asks you to.

Why it matters: A correct baseline proves you understand the problem and gives you something to improve. McDowell's own step is labelled "a stupid and terrible solution is okay".

Example wording: "Brute force: check every pair with two nested loops. That is O(n^2) time and O(1) space. With n up to 10^5, that is around 5 x 10^9 pair checks, so it will be too slow, but it is correct."

Common mistake: Skipping this step to chase the clever answer, then running out of time with nothing working.

Step 4: Optimize by removing the bottleneck

Find the repeated or wasted work in the brute force and replace it with a better data structure or technique: hashing, sorting with two pointers, a sliding window, a heap, or memoization. Agree the new approach with the interviewer before writing it.

Why it matters: Most optimizations are a lookup cost change. The Python wiki lists membership checks as O(n) for a list but O(1) on average for a set or dict, which is exactly what turns a nested loop into a single pass.

Example wording: "The inner loop searches for target - x. If I store each value's index in a hash map as I go, that search becomes O(1) on average, so the whole thing is one pass, O(n) time and O(n) space. Does that sound good?"

Common mistake: Optimizing silently in your head. Narrate the bottleneck you are attacking.

Step 5: Write clean, modular code

Write real code, not pseudocode, using clear variable names and small helpers where they make logic easier to read. Talk through each block as you write it.

Why it matters: Interviewers grade code quality alongside correctness. McDowell's step 6 is "Write Beautiful Code", meaning good style and upfront modularization, and interviewing.io scores candidates separately on technical ability, problem solving and communication.

Example:

def two_sum(nums, target):
    seen = {}  # value -> index
    for i, x in enumerate(nums):
        need = target - x
        if need in seen:
            return [seen[need], i]
        seen[x] = i
    return []  # unreachable if exactly one pair exists

Common mistake: Naming variables a, b and tmp, which makes your own testing in step 6 much harder.

Step 6: Test with your examples and edge cases

Read the code once for typos, then trace your step 2 example line by line, writing variable values as you go. Next run the edge cases: empty input, one element, duplicates, negatives, maximum size.

Why it matters: In many interviews you cannot run code, so the trace is your test suite. McDowell's final step reads "analyze first, then use test cases", and Google's recruiting guidance says to "try to find edge cases".

Example:

# nums = [7, -2, 11, 4, 15], target = 9
# i=0 x=7  need=2   seen={}            -> store 7:0
# i=1 x=-2 need=11  seen={7:0}         -> store -2:1
# i=2 x=11 need=-2  seen has -2 -> return [1, 2]  correct
# edge [3, 3], 6: i=0 store 3:0; i=1 need=3 found -> [0, 1]  correct

Common mistake: Fixing a bug by patching the symptom. Say why the bug happened before you change anything.

Step 7: Analyze time and space complexity

Finish with a short complexity statement for time and space, naming every variable, plus one tradeoff you made and when you would choose differently.

Why it matters: Complexity is a pass or fail skill at top companies. Former Google engineer Steve Yegge wrote that if you "struggle with basic big-O complexity analysis, then you are almost guaranteed not to get hired".

Example wording: "Time is O(n), one pass with O(1) average map operations. Space is O(n) for the map. If memory were tight and I could modify the input, I would sort and use two pointers for O(n log n) time and O(1) extra space, but I would lose the original indices unless I sort pairs."

Common mistake: Quoting average-case hash map cost as if it were guaranteed. Mention the worst case if asked.

How to know it worked

• After 2 to 3 weeks, you finish unseen medium problems in under 35 minutes, tests included, on most attempts.
• You never start typing before steps 1 to 3 are done, even under pressure.
• Your hand trace finds your own bugs before an interviewer does.
• Mock interviewers stop asking "what are you thinking?" because you narrate by default.
• Repetition with a real interviewer helps: interviewing.io's analysis of 158 Google applicants found predicted phone screen pass probability of 69% after 2 mock interviews and 76% after 3.

Troubleshooting

• If you cannot see any approach: go back to step 2, solve a bigger example by hand, and write down exactly what your brain did.
• If you finish the brute force but cannot optimize: ask what work is repeated, then try each common technique (hash map, sort, two pointers, window, heap) for 30 seconds each.
• If you keep running out of time: cap steps 1 to 4 at about 15 minutes in practice and track it.
• If you get a hint: repeat it back, connect it to your current approach, then continue from that point rather than starting over.

FAQ

Should I always code the brute force solution?

Usually no. State it and its complexity, then move to the optimized version. Code the brute force only if the interviewer asks, or if you are stuck on optimizing and have less than about 15 minutes left. A working simple solution beats an unfinished clever one.

How long should each step take in a 45-minute interview?

A practical split is about 5 minutes for clarifying and examples, 5 to 10 minutes for brute force and optimization, 15 minutes for coding, and the rest for testing and complexity. Treat this as a planning target and adjust it to the problem.

Is this the same method as in Cracking the Coding Interview?

It is closely related. Gayle Laakmann McDowell's 7 steps are listen, draw an example, brute force, optimize, walk through, write beautiful code and test. This version merges walking through into optimizing and adds an explicit final complexity step, because interviewers ask for it so often.

What if the interviewer wants me to code right away?

Follow their lead, but compress the first steps instead of skipping them. Spend one minute confirming constraints and one example, state your approach in a sentence, then code. Testing and complexity still come at the end.

To recap: clarify, work examples, state a brute force, optimize, code, test and analyze complexity, every time. Rehearsing it with a live interviewer is the fastest way to make it stick, so book an anonymous coding mock interview and get a scorecard on each step. Then apply the method to a real format with how to pass the Google technical phone screen, or browse company formats in the interview guide.