The 3 Questions I Ask Before Writing Any Interview Code | Learn

You know the moment.

The interviewer finishes explaining the problem. There's a pause. And most candidates do the worst possible thing — they start typing.

I've watched hundreds of candidates do this. The ones who get offers don't. They pause for 60–90 seconds, ask 2–3 questions, and then touch the keyboard.

Here's the difference: they're running a checklist. Not consciously — it's muscle memory by the time you're good at it. But there are exactly three questions, and if you skip any of them, you'll waste 10 minutes going the wrong direction.

Diagram

Rendering diagram...

Question 1: "What am I actually being asked?"

Not the title. Not "it's a two-sum problem." The actual constraint.

Aleksey Kladov (matklad) puts it better than anyone: programming is all about building a precise understanding inside your mind. The code is secondary — the mental model is the thing. If your mental model is wrong, your code will be wrong no matter how fast you type.

Example: 'Find the longest substring without repeating characters'

What most candidates hear

"Longest substring" → sliding window → start coding

// Already writing a while loop...

1 / 3

That 30-second difference — parsing the actual constraint vs. hearing the title — is worth 15 minutes of coding time.

Fin's rule: If you can't explain the constraint in one sentence without using the problem's title, you don't understand the problem yet.

Question 2: "What's the shape of the answer?"

This is the question that unlocks the approach.

Before you pick an algorithm, ask: what does the OUTPUT look like? Not the process — the result.

Output Shape

Likely Approach

Single number

Length, count, max/min

Sliding window, two pointers, binary search

Boolean

Yes/no, exists/doesn't

Hash set, early termination, DFS

Array (sorted)

Sorted result needed

Sort first, then merge/scan

Array (order matters)

Preserve input order

Stack, queue, linked list

All valid combos

Permutations, subsets

Backtracking, DFS + pruning

Tree/graph path

Path between nodes

BFS (shortest), DFS (any)

This isn't pattern matching. It's structural reasoning. You're not memorizing "if X then Y" — you're asking "what shape does this answer need to be, and what tools produce that shape?"

Diagram

Rendering diagram...

Fin's rule: Name the output type before you name the algorithm. "The answer is a single integer representing the maximum length" is more useful than "I think this is a sliding window problem."

Question 3: "What must stay true the whole time?"

This is the question. If you read our sliding window vs. two pointers post, you've seen this before — but it applies to every problem, not just windows.

The invariant is the thing that must be true at every step of your algorithm. If you can name it before coding, you'll:

Know when to stop expanding (the invariant breaks)
Know when to start shrinking (restore the invariant)
Know your loop condition (maintain the invariant)
Catch bugs instantly (check the invariant)

Finding the invariant: Maximum subarray sum ≥ target

Name the invariant

"The window [left, right] always represents a contiguous subarray. When the sum meets the target, we record the length and try to shrink."

1 / 3

Aleksey Kladov's advice maps here too: stare at the state. Identify the key data structures and fields. Search for all places where they are created and modified. Build a spatial and temporal understanding of what must hold.

Fin's rule: If you can't state the invariant in one sentence, you're not ready to code. "The window always contains unique characters" is an invariant. "I'm using a hash map" is not.

The 90-second version

In a real interview, here's what this looks like:

TEXT

Interviewer: "Given an array of integers and a target, find the
             shortest subarray with sum at least target."
 
You (30s):   "So I need a contiguous subarray — not a subsequence —
              where the sum is >= target, and I want the shortest one.
              The answer is a single integer: the length."
 
You (30s):   "Since it's contiguous and I want minimum length, this
              feels like a shrinking window. Expand until I hit the
              target, then shrink to find the minimum."
 
You (30s):   "The invariant: my window always represents a valid
              subarray. When the sum meets the target, I record the
              length and shrink from the left."
 
You:          "Let me code that up."

That's 90 seconds. The interviewer just watched you demonstrate problem decomposition, structural reasoning, and algorithmic thinking — before writing a single line.

The code almost writes itself after that.

Unlock the full guide

Complete walkthrough, diagrams, and practice problems — all included with StrongYes Pro.

Unlock with Pro

This is how Fin coaches at strongyes.io — one question at a time, until the code writes itself. Try a session →

Sources:

Kladov, A. "Look for Bugs" (2025) — on building mental models before code
Kladov, A. "Kafka vs Nabokov" (2024) — on starting with the simplest working thing
Post 1: Sliding Window vs. Two Pointers — The Invariant Question

Question 1: "What am I actually being asked?"

What most candidates hear

Unlock the full guide

Practice Interview strategy.