The difference between candidates who pass and fail is not intelligence or knowledge — it is approach. Candidates who follow a structured problem-solving framework consistently outperform those who jump into coding. This guide provides the definitive framework for approaching any coding problem in an interview, from reading the problem to testing your solution.
Step 1: Understand the Problem (3-5 minutes)
Read the problem twice. Then: (1) Restate in your own words. “So I need to find two numbers in the array that add up to the target and return their indices.” This catches misunderstandings immediately. The interviewer will correct you if you are wrong. (2) Identify inputs and outputs. Input: integer array, integer target. Output: array of two indices. What if there are multiple solutions? Return any? What if no solution? Return empty/null? (3) Clarify constraints. Array size (10? 10^6?). Value range (positive? negative? zero?). Sorted or unsorted? Duplicates allowed? Can I modify the input array? These questions are NOT wasting time — they demonstrate thoroughness and may reveal simplifying constraints that change your approach entirely. (4) Work through examples. Trace the given example. Create one more: an edge case (empty array, single element, all same values). Write the examples on the whiteboard/editor — you will use them to test later. This step takes 3-5 minutes but prevents the most expensive mistake: solving the wrong problem.
Step 2: Brute Force First (2-3 minutes)
Always start with the brute force solution, even if you see a better approach. Say: “The brute force would be to check every pair with nested loops. That is O(N^2) time, O(1) space. This works but we can do better.” Why brute force first: (1) It proves you understand the problem. A correct brute force means you know what the answer looks like. (2) It gives you a baseline to optimize from. “We are doing O(N^2) because of the inner search. If we use a hash map, the inner search becomes O(1), making the total O(N).” (3) If you get stuck on the optimal solution, you have a correct solution to fall back on. A working O(N^2) solution scores better than an incomplete O(N) solution. (4) It demonstrates structured thinking. Senior engineers always consider the simple solution first and optimize only when needed. The interviewer does not want to see you spend 30 minutes on an elegant solution that does not work. They want to see: correct first, then fast. State the brute force approach verbally (do not code it unless the interviewer asks). State its complexity. Then move to optimization.
Step 3: Optimize (5-10 minutes)
Identify the bottleneck in the brute force and eliminate it. Common optimization strategies: (1) Hash map — replace O(N) search with O(1) lookup. If the brute force has a nested loop where the inner loop searches for something, a hash map often eliminates it. (2) Sorting — sort the input to enable two pointers, binary search, or greedy approaches. Adds O(N log N) but often reduces O(N^2) to O(N log N). (3) Two pointers — for sorted arrays, opposite-direction pointers avoid nested loops. (4) Sliding window — for contiguous subarray problems, a window avoids recomputing from scratch at each position. (5) Precomputation — prefix sums, frequency arrays, or memoization tables that trade space for time. (6) Better data structure — a heap for top-K, a trie for prefix queries, a monotonic stack for next-greater. If stuck after 5 minutes: (1) Think about what information is being recomputed. (2) Think about the problem constraints — if N <= 20, O(2^N) is acceptable (bitmask DP). (3) Think about similar problems you have solved. Which pattern does this resemble? (4) Ask the interviewer for a hint — this is better than silence. State your approach before coding: "I will use a hash map to store each number and its index. For each element, I check if (target – element) exists in the map." Get confirmation.
Step 4: Code (10-15 minutes)
Now that you have a confirmed approach, code it. Rules: (1) Write the function signature first. def twoSum(self, nums: List[int], target: int) -> List[int]. This anchors the code. (2) Handle edge cases first (1-2 lines at the top). if not nums: return []. (3) Code the main algorithm. Use meaningful variable names. Comment briefly if the logic is non-obvious (one-line comments, not paragraphs). (4) Think out loud while coding. “Now I iterate through the array. For each number, I check if the complement exists in the map.” (5) Do NOT optimize prematurely during coding. Write the clean, correct version first. Micro-optimizations (avoiding an extra variable, clever bit tricks) can introduce bugs and are not worth the risk. Code quality matters: clean structure, no dead code, proper indentation, and meaningful names. The interviewer reads your code — make it readable. If you realize your approach has a bug mid-coding: stop, explain the issue, and fix it. Do not silently change code and hope the interviewer does not notice. “Wait, I realize this does not handle negative numbers correctly. Let me adjust the comparison.” This shows debugging ability.
Step 5: Test (5 minutes)
After coding, test before saying “done.” (1) Trace through the given example step by step. Show variable states: “i=0, num=2, complement=7, not in map. Add {2:0}. i=1, num=7, complement=2, found in map at index 0. Return [0,1].” (2) Test edge cases: empty input, single element, no solution exists, duplicate values. (3) Check boundary conditions: loop termination, off-by-one errors, return type. (4) State complexity. “O(N) time — single pass with O(1) hash map lookups. O(N) space for the hash map.” Why testing matters: it demonstrates thoroughness, catches bugs before the interviewer does (much better impression), and shows you do not consider code done until verified. Many interviews end with the interviewer saying “looks good” after you test — but if you had not tested and they found a bug, it would be “let me see if this handles edge cases” (a worse outcome). The 5 minutes spent testing is the highest-ROI activity in the entire interview. After testing: ask “Does this look correct to you? Should I handle any other cases?” This invites the interviewer to share concerns and demonstrates collaboration.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”What is the 5-step framework for solving any coding interview problem?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Step 1 Understand (3-5 min): restate the problem, clarify inputs/outputs/constraints, trace examples including edge cases. Step 2 Brute Force (2-3 min): describe the naive solution and its complexity. Even if you see a better approach, this proves understanding and provides a fallback. Step 3 Optimize (5-10 min): identify the brute force bottleneck, apply optimization (hash map for O(1) lookup, sorting for two pointers, precomputation). State approach before coding. Step 4 Code (10-15 min): write the function signature, handle edge cases, implement the algorithm with meaningful names. Think aloud. Step 5 Test (5 min): trace through examples step by step, test edge cases, verify boundary conditions, state time/space complexity. This framework prevents the two most common failures: solving the wrong problem (Step 1 catches this) and submitting buggy code (Step 5 catches this).”}},{“@type”:”Question”,”name”:”Why should you always start with the brute force solution?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Four reasons: (1) It proves you understand the problem — a correct brute force means you know what the answer looks like. (2) It gives an optimization baseline: We are O(N^2) because of the inner search. A hash map makes it O(1), total O(N). This narrative shows structured thinking. (3) If you get stuck on the optimal, you have a correct fallback. A working O(N^2) scores better than an incomplete O(N). (4) It demonstrates engineering judgment — senior engineers consider the simple solution first and optimize only when needed. State the brute force verbally (do not code it unless asked), state its complexity, then move to optimization. The interviewer evaluates your reasoning process. Jumping to the optimal solution without mentioning brute force looks like memorization, not problem-solving.”}}]}