How to Approach Coding Interview Problems: Read the Constraint Block Before You Code
- Read n before anything else: the constraint block tells you the required complexity class before you pick an algorithm
- Constraints are the spec, not footnotes: "sorted array" implies two pointers; "values in [1, n]" opens cycle detection and pigeonhole tricks
- Pattern-matching breaks on twists: retrieval fails on novel inputs; reasoning from structure doesn't
- The four-step pre-coding checklist: complexity class, invariants, what they eliminate or enable, then pattern
- Ask when constraints aren't stated: clarifying questions on input size and uniqueness are a scored signal, not stalling
- Floyd's beats hash set on Find Duplicate: only visible if you interrogate the value-range constraint, not just reach for the obvious pattern
You see the problem. Your brain fires: "array, window, sliding window." You start typing. Twelve minutes later the approach doesn't fit, you're deleting code, and the interviewer has developed a specific expression on their face. It's not angry. It's just patient in a way that makes things worse.
That's not a knowledge gap. That's a sequencing problem. The first two minutes of any coding interview problem decide whether you finish clean or end the session typing "sorry, let me restart" with six minutes left on the clock.
Pattern Matching Is the Wrong First Move
Pattern recognition works until the problem has a twist. In interviews, there's always a twist. The problem looks familiar enough to trigger recall but different enough to snap the template in half once you're three functions deep.
When you pattern-match first, you're doing retrieval. When you reason from constraints, you're deriving. Retrieval fails on novel inputs. Derivation doesn't, because you're working from what the problem actually guarantees instead of what it smells like.
The fix isn't memorizing more patterns. It's changing when you reach for them.
If you've blanked on a problem you thought you knew, this is almost always why.
Bubble sort grabbed "sort this array" and ignored "0s, 1s and 2s." That constraint is screaming Dutch National Flag, O(n) single pass. Pattern matching saw the genre. It missed the spec.
What the Constraints Are Actually Telling You
Most people read the story. They skim the constraint block at the bottom. That's completely backwards.
The constraints are a near-complete specification of the solution space. The narrative is flavor text. Before you think about approach, find n and read it like it owes you money.
Then read the data constraints. "Sorted array" is screaming two pointers or binary search. "Integers in range [1, n]" means every value is a valid index into the array, which opens cycle detection and pigeonhole tricks. "Lowercase letters only" means you can use a 26-element array instead of a hash map. These aren't footnotes. They're the spec.
The story told you someone "has an array of people's ages." The constraints told you n is at most 100 and values are in [1, 120]. Those two facts just ruled out everything except a counting sort.
Read the Constraint. The Algorithm Is Already There.
Find the duplicate in an array of n+1 integers where every value is in [1, n].
Pattern-match answer: hash set. O(n) time, O(n) space. Correct. Ship it.
Actually, wait. Go back to "values in [1, n]." Every value is a valid index into the array. If you treat values as pointers, you have a functional graph where every node has exactly one outgoing edge. A duplicate means two nodes point to the same destination. That's a cycle.
Floyd's algorithm solves it in O(n) time and O(1) space. The constraint wasn't just informing the solution. It was the solution, sitting there in the problem statement the whole time while you were reaching for your hash map.
The hash set passes. Floyd's is what the interviewer was hoping for. The difference wasn't knowledge. It was whether you interrogated the constraint or skimmed it on the way to your first instinct.
Run This Before You Touch the Keyboard
Before you reach for a pattern:
- What does n tell me about the required complexity class?
- What invariants does the problem guarantee? (sorted, unique, bounded range, binary tree, etc.)
- What do those invariants eliminate or enable?
- Now which pattern fits that space?
Ninety seconds. It shifts your starting question from "what does this look like?" to "what does this problem allow?" Those are completely different questions, and the second one has a much more reliable answer.
The stuck feeling almost always comes from committing to an approach before understanding the structure. Three steps into a sliding window before you notice the input isn't contiguous. Two minutes into a DFS before realizing the graph has cycles. You got stuck because you started too early.
If the Problem Doesn't State It, Ask
Asking "can the input be empty?", "are values unique?", "what's the size of n?" isn't stalling. It's reading the spec before writing code. And it's why asking the right clarifying questions first is one of the clearest signals an interviewer can observe.
If the constraint isn't given, you ask for it. If it's already in the problem, you read it before doing anything else.
The next time you blank, stop. Read the constraint block top to bottom. Write down what each number rules out. The algorithm is almost always already there. You just walked past it on the way to the code.
SpaceComplexity gives you rubric-based feedback on exactly this kind of structural reasoning, not just whether your code ran.