How to Approach a Coding Problem

The five steps

Step 1: Clarify. Restate the problem in your own words and ask about edge cases and constraints. Can the array be empty? Are there negatives or duplicates? How large is n? That last question secretly bounds the acceptable complexity: n up to 100,000 rules out O(n squared) but welcomes O(n log n), while n around 20 hints that exponential backtracking is intended.

Step 2: Brute force. Say the simplest correct approach out loud, with its complexity, before hunting for anything clever. This is not wasted time. It proves you understand the problem, gives you a safety net if optimization stalls, and provides the baseline you are about to beat.

Step 3: Optimize. Interrogate the brute force: what work is repeated? Would sorting help? Would a HashMap trade memory for lookup speed? Step 4: Code, only after the approach is agreed. Step 5: Test. Trace your code line by line on a small input and the nastiest edge cases you can think of. Most candidates skip half these steps under pressure; simply doing all five puts you ahead.

Worked example: Two Sum, steps 1 through 3

The problem: given an array of integers and a target, return the indexes of two numbers that add to the target. Clarify first: exactly one solution? (Say yes.) Can the same element be used twice? (No.) Sorted? (No.) Negatives allowed? (Yes.) Two of those answers matter enormously. Unsorted rules out immediate two-pointers on indexes, and single-solution simplifies returns.

Brute force: try every pair with nested loops. Outer loop picks i, inner loop picks j after it, check whether nums[i] + nums[j] equals target. Correct, easy to state, O(n squared) time, O(1) space. Say all of that in one breath and move on.

Optimize by interrogating the waste: for each number, we rescan the whole array hunting for one specific value. Target minus the current number, its complement. Rephrased that way, the inner loop is just a lookup, and fast lookups are exactly what a HashMap provides: O(1) average instead of O(n).

static int[] twoSumBrute(int[] nums, int target) {
    for (int i = 0; i < nums.length; i++) {
        for (int j = i + 1; j < nums.length; j++) {
            if (nums[i] + nums[j] == target) {
                return new int[]{i, j};
            }
        }
    }
    return new int[]{-1, -1};
}

Steps 4 and 5: code it, then attack it

The optimized plan: walk the array once, and for each number check whether its complement is already in a HashMap of previously seen values; if yes, done, if no, store the current number with its index and continue. One pass, O(n) time, O(n) space. State the plan in sentences like that before typing; code written from a spoken plan comes out cleaner.

Now test like an adversary, not a fan. Trace nums = [2, 7, 11, 15], target 9: i=0, complement 7 not in the map, store 2. i=1, complement 2 is in the map. Return indexes 0 and 1. Then hit edge cases: a two-element array, negative numbers, and the trap case nums = [3, 3] with target 6. Does the code accidentally match an element with itself? (It does not, because the complement check happens before inserting the current element.)

Saying that last sentence out loud is the level of care interviewers remember. Finding your own bug in testing reads as strength; the interviewer finding it for you reads as the opposite.

static int[] twoSum(int[] nums, int target) {
    Map<Integer, Integer> seen = new HashMap<>();
    for (int i = 0; i < nums.length; i++) {
        int complement = target - nums[i];
        if (seen.containsKey(complement)) {
            return new int[]{seen.get(complement), i};
        }
        seen.put(nums[i], i);
    }
    return new int[]{-1, -1};
}

Think out loud, always

An interview is not an exam where only the final answer counts; the interviewer is deciding whether they want to solve problems next to you for years. Silence gives them nothing to evaluate. Narrate continuously: I am considering sorting first, but that destroys the indexes we need to return, so instead I will try a HashMap.

Narration also buys concrete advantages. A stuck-but-talking candidate can be nudged with a hint; a stuck-and-silent one cannot. Dead ends spoken aloud still earn credit as evidence of judgment. And explaining a plan often surfaces its flaw before you have spent ten minutes coding it.

When you genuinely stall, use a reset script: re-read the problem statement slowly, re-examine the example input by hand and watch what your brain does naturally, or say let me reconsider the brute force and what makes it slow. All three restart motion, and motion is what the framework exists to protect.

Pattern recognition: cues in the problem statement

Experienced solvers are not smarter mid-interview. They have a lookup table from problem phrasing to technique, built through practice. Start building yours with these cues.

Sorted array plus pair-finding: two pointers. Longest, shortest, or count of a contiguous subarray or substring: sliding window. Fewer than or equal to 20 elements, or generate all combinations, subsets, or permutations: backtracking. Count the number of ways, minimum cost, or maximum value with overlapping choices: dynamic programming. Interval scheduling or maximize the number you can take: consider greedy, then try to break it. Need fast lookups or have you seen this before checks: HashMap. Top K or K-th largest: a heap. Nested structure, matching brackets, or most recent item first: a stack.

Two habits make the table stick. After every practice problem, write one sentence: which cue should have told me the technique sooner? And practice by pattern, a week of sliding window problems wires the cue far faster than random problem-hopping. The framework tells you how to move; the pattern table tells you where. From here, the best next step is volume: pick a pattern from this section, and work through its practice problems with all five steps, out loud, every time.

Frequently asked