How to Approach a Coding Problem

Repeat the problem back in your own words, then ask 1-3 clarifying questions before writing anything. This surfaces hidden assumptions (can inputs be empty? negative? duplicated?) and buys you thinking time.

• Ask about edge cases: empty input, single element, all-duplicate values, negative numbers.
• Confirm the expected output format and whether ties/multiple valid answers are allowed.
• If the prompt is ambiguous ("find the largest"), ask what "largest" means precisely.

Before coding, say which pattern you recognize and why ("this is sliding window because we need a contiguous range and can check the condition incrementally"), and state the loop invariant you'll maintain. This is what interviewers are actually listening for.

• If you don't recognize a pattern immediately, talk through the brute force first, then ask "what's making this O(n²) and can I avoid re-scanning?"
• Naming the invariant catches your own bugs before you write a line of code.

Trace your approach on a small example by hand (on paper or out loud) before typing, to confirm the pointer movements or state updates actually work. Then write the code, narrating each meaningful chunk.

• Pick an example that exercises the tricky case, not just the happy path.
• It's fine to write helper functions or leave a TODO for a subroutine and come back to it.

Trace your actual code (not just your mental model) against the example from step 3. Then explicitly walk the edge cases you identified in step 1. Finish by stating time and space complexity and whether there's a further optimization you're choosing not to make.

• Tracing the real code (not re-explaining the idea) is what catches off-by-one and null-check bugs.
• "I could optimize further by X, but it would cost Y — I don't think it's worth it here" reads as senior-level judgment.

If the interviewer offers a hint, take it — don't argue or ignore it. If you're stuck, narrate your reasoning ("I know a hash map would give me O(1) lookup here, but I'm not sure how to handle the ordering requirement") instead of going silent; a visible thought process is gradable even when incomplete.

• Silence is the worst outcome for an interviewer to grade — always be narrating your current hypothesis.
• "Let me think out loud for a second" is a completely normal, expected thing to say.

• State the pattern and invariant before writing code, not after.
• Have a small example ready to trace both your plan and your final code against.
• Know your target time budget per step (roughly: 3-5 min clarify, 5 min plan, 15-20 min code, 5 min verify, for a 30-45 min slot).
• Practice narrating out loud — silent coding is the single most common feedback interviewers give.