An unseen problem is less about instant recognition than controlled uncertainty. Use a repeatable sequence so the interviewer can evaluate your reasoning even before the final code is complete.
1. Clarify the contract#
Restate inputs and outputs. Ask about constraints, duplicates, ordering, invalid input, and whether mutation is allowed. Prefer questions that could change the algorithm.
2. Build one useful example#
Choose a small example that exposes the central behavior. Add an edge case after you have a candidate approach instead of enumerating every possibility at the start.
3. State a correct baseline#
A brute-force solution creates a correctness anchor. Explain its bottleneck precisely, then improve the operation responsible for that cost.
4. Name the invariant#
Before coding, state what remains true as pointers move, a window changes, or a traversal progresses. This is more valuable than naming a pattern without justification.
5. Implement in reviewable steps#
Use clear names and explain decisions, not keystrokes. Pause briefly when the approach changes rather than silently patching a broken invariant.
6. Test deliberately#
Trace a normal case, the smallest valid case, and a case that stresses the key branch. State expected output before executing the trace.
7. Close with complexity and tradeoffs#
Give time and auxiliary space in terms of the relevant inputs. Mention recursion stack or output storage when it materially affects the analysis.