The Coding Interview Method

A coding interview tests more than whether you can produce a correct function. The interviewer is scoring how you get there: whether you clarify before coding, whether you reason about trade-offs out loud, whether your code is clean, and whether you test it without being asked. A repeatable method makes all of that automatic, so your working memory is free for the actual problem.

1What Interviewers Actually Score

Most companies use a rubric with four or five dimensions. The exact names vary, but they map to the same things:

At senior level, the bar on communication and trade-offs rises: you are expected to drive the session, not wait to be led.

2The Six Steps

1. Clarify. Restate the problem in your own words. Ask about input size, value ranges, duplicates, empty input, sorted or not, and the expected output for ties or "not found".
2. Examples. Write one normal example and one or two edge cases before thinking about an algorithm. Agree on the expected outputs with the interviewer.
3. Brute force. State the simplest correct approach and its complexity in one or two sentences. You usually don't code it, but saying it proves you understand the problem and gives you a baseline.
4. Optimize. Find the bottleneck in the brute force (the repeated work) and pick a pattern that removes it: a hash map instead of a nested loop, two pointers on sorted data, a heap for top-k, memoization for overlapping subproblems.
5. Code. Write the optimized solution cleanly. Talk while you write, but keep sentences short. Use helper functions for distinct steps.
6. Test and analyse. Trace your first example through the code line by line, then run the edge cases. Finish by stating time and space complexity.

"Let me restate: given an array of integers and a target, return the indices
of two numbers that sum to the target. Can there be duplicates? Is there always
exactly one answer? Can I use the same element twice?  ... OK.

Brute force: check every pair, O(n²) time, O(1) space.
The repeated work is searching for the complement. A hash map from value to
index makes that lookup O(1), so one pass gives O(n) time and O(n) space."

3Time Budget for a 45-Minute Round

If you are still choosing an approach at minute 15, say so and ask a narrowing question. Interviewers would rather give a small hint early than watch you run out of time.

4Recognizing the Pattern From the Problem Statement

Most interview problems are variations of about twenty patterns. Certain phrases are strong signals:

5Communicating While You Code

• Narrate intent, not syntax. Say "now I shrink the window until it's valid again", not "while left less than…".
• Flag shortcuts. "I'll assume the input is valid here; in production I'd validate it." This shows judgment without wasting time.
• When stuck, think out loud. Say what you've ruled out and why. That gives the interviewer something to hint against.
• Take hints gracefully. Repeat the hint back, connect it to your approach, and move on. Hints are normal; ignoring them is a red flag.

6Testing Like a Senior Engineer

After coding, trace one example by hand with concrete variable values. Then check this list:

• empty input, single element, two elements
• all elements equal, already sorted, reverse sorted
• negative numbers and zero, very large values (overflow in C#/Java int)
• the answer at the very first or very last position
• no valid answer

When you find a bug, say what was wrong before fixing it: "the window shrinks one step too late because I check after moving left".

⚠️ Common Pitfalls

1. Coding before agreeing on the approach. You may solve the wrong problem or an over-complicated version.
2. Silence while thinking. Interviewers can't score what they can't hear.
3. Skipping the brute force. Without a baseline, your optimization has nothing to be compared against.
4. Testing by rereading. Rereading finds typos; tracing concrete values finds logic bugs.
5. Forgetting space complexity of recursion (the call stack) and of output buffers.
6. Over-engineering: classes and interfaces where one clear function is expected.

📋 Quick Reference

Clarify → Examples → Brute force (+ complexity) → Optimize (find repeated work)
→ Code (narrate intent) → Trace + edge cases → Time & space

Edge cases: [] · [x] · duplicates · negatives/zero · sorted/reversed · no answer
45 min: 5 clarify · 5 plan · 20 code · 8 test · 7 follow-ups

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: algo_coding_interview_method_theory.md · generated by tools/build_lessons.py