The 8-step loop you'll run on autopilot
When these steps become muscle memory you stop "thinking about what to do next" and spend that cognitive budget on the problem. Same loop SoloMock's interviewer uses.
What a "coding interview" actually is — and what this loop is for
A coding interview (sometimes called a "technical screen" or "DSA round," where DSA = Data Structures and Algorithms) is a 30-to-60-minute session where an interviewer gives you a small programming problem and watches you solve it — usually in a shared editor or on a whiteboard while you talk. Here is the part beginners get wrong: the interviewer is not grading the final answer, they are grading the process they watched you use to get there. Two candidates can both reach a correct solution; the one who clarified the problem, reasoned out loud, and tested their own code gets the offer. A "loop" here just means a repeatable sequence of steps — the same eight moves, in the same order, on every single problem. The point of memorizing a loop is that decisions you've pre-made don't cost you anything under stress.
Think of it like a pilot's pre-flight checklist. A pilot doesn't improvise which gauges to check — they run the same list every flight, so 100% of their attention is free for anything unusual. This loop is your checklist. The first few times it will feel slow and mechanical; that is exactly the point. By the time it's automatic, you'll be spending your brainpower on the algorithm, not on "wait, what am I supposed to do next?"
A few words you'll see throughout
Two terms appear all over these steps, so let's pin them down once. Time complexity describes how the number of steps your code takes grows as the input gets bigger; space complexity describes how much extra memory it needs as the input grows. Both are written with Big-O notation — a shorthand like O(n) or O(n²) that names the shape of that growth while ignoring constant factors. Read O(n) as "grows in proportion to the input size n" (double the input, roughly double the work) and O(n²) as "grows with the square of the input" (double the input, roughly four times the work). A brute force solution is the most obvious, usually-slow approach you can think of first — the one you'd describe to a friend before optimizing anything. Don't worry if Big-O still feels fuzzy; a later lesson treats it in full, and you only need the gist to run this loop.
-
1
Clarify before coding
Restate the problem. Ask about bounds, types, duplicates, negatives, empty input, return shape. Never assume.
-
2
Walk a small example by hand
Trace one concrete case out loud before code. Cheap insurance against misunderstanding.
-
3
Brute force, then optimize
State the obvious O(n²) solution + complexity. Then: "the bottleneck is X — can I avoid recomputing it?"
-
4
Commit before typing
State complexity, name data structures, get a verbal nod. Writing is the slow part; re-writing kills you.
-
5
Code in pieces, narrate why
Top-down: signature → outer loop → inner logic → return. Talk about why, not what.
-
6
Trace your code on a sample
Don't say "I think this works." Say "let me trace it." Catches off-by-ones before the interviewer does.
-
7
Volunteer edge cases
Empty / single / all-duplicate / negative / overflow / cycle. You list them, you fix them.
-
8
Talk tradeoffs
"O(n) time, O(n) space. Could trade for O(1) space at O(n log n) by sorting first." Senior signal = naming axes.
Each step, unpacked
The eight cards above are the loop in its shortest form. Below, each one is spelled out with what it means, why it earns points, and exactly what to say or do.
1 · Clarify before coding
Before writing a line, restate the problem back in your own words and ask about everything left unstated. Bounds means the allowed size and range of the input ("how large can the array get? can values be in the millions?"). Types means what kind of data it is (integers? floating-point decimals? strings?). Return shape means the exact form of the answer you must hand back (a single number? a list? a list of pairs? sorted or not?). Also probe for duplicates (can the same value appear twice?), negatives, and empty input (what if the list is empty?). Why it matters: interviewers routinely leave the prompt vague on purpose to see if you ask. Solving the wrong problem perfectly is the most expensive mistake there is.
Example. Given "find two numbers that add up to a target," you might ask: "Is the input sorted? Can numbers repeat? Is there always exactly one answer, or could there be none or several? Do I return the two values or their positions?" Each answer can completely change the right approach.
2 · Walk a small example by hand
Pick a tiny concrete input and work the expected answer out loud, by hand, before touching code. "Trace" means to step through the data manually as if you were the computer. Why it matters: it confirms you and the interviewer agree on what the answer even is, and it often reveals the pattern your code will need.
Example. For the two-sum problem with input [2, 7, 4] and target 9: "2 plus 7 is 9 — that's the pair, at positions 0 and 1. So my output should be [0, 1]." Thirty seconds here saves you from coding the wrong thing for ten minutes.
3 · Brute force, then optimize
Say the obvious slow solution out loud first and name its complexity — even if you already see a faster one. The bottleneck is the single most expensive part of your approach; optimizing means attacking that part, usually by avoiding repeated work. Why it matters: stating the brute force shows you understand the problem and gives you a baseline to improve from. Jumping straight to a clever trick (and stumbling) reads worse than a clean, narrated progression.
Example. "The brute force is: for each number, scan every other number to see if they sum to the target — that's two nested loops, so O(n²) time. The bottleneck is that inner scan. If I instead remember numbers I've already seen in a hash map, I can check 'is the complement here?' in one step, dropping it to O(n)." A hash map (also called a dictionary) is a lookup table that finds a stored value almost instantly.
4 · Commit before typing
Once you've chosen an approach, state it in one breath — the data structures you'll use and the complexity you expect — and get a verbal "sounds good" before you start typing. To commit here means to lock in the plan. Why it matters: typing is the slow, error-prone part; deleting half-written code mid-interview wastes time and rattles you. A nod from the interviewer is a cheap checkpoint that you're not about to walk off a cliff.
Example. "Plan: one pass over the array, storing each value's index in a hash map, checking for the complement as I go. O(n) time, O(n) space. Good to start?" — then code.
5 · Code in pieces, narrate why
Build the solution top-down — outline first, details later: write the function signature (its name and inputs), then the outer loop, then the inner logic, then the return statement. As you go, explain why each piece exists, not just what it literally does. Why it matters: narrating your reasoning is the single biggest "senior" signal, and a skeleton you fill in is far less error-prone than writing one perfect line at a time.
Say "why," not "what." Bad: "Now I write a for loop." Good: "I loop once through the array because I want to examine each number exactly one time and remember the ones I've seen."
6 · Trace your code on a sample
After writing, run a real input through your finished code line by line, out loud, tracking how each variable changes. Why it matters: this catches an off-by-one error — a bug where a loop runs one time too many or too few, or an index is off by one position (the classic example: confusing the last valid index n-1 with n) — before the interviewer points it out. Saying "let me trace it" instead of "I think this works" projects rigor.
Example. With [2, 7, 4], target 9: "First number is 2; complement is 7; not in the map yet, so I store 2. Next is 7; complement is 2; 2 is in the map at index 0 — return [0, 1]. Matches my hand-traced answer."
7 · Volunteer edge cases
An edge case is an unusual or boundary input that ordinary code often mishandles. List the usual suspects yourself and confirm your code survives each: empty (no elements at all), single (exactly one element), all-duplicate (every element identical), negative numbers, overflow (a value too large for the number type to hold — less of a worry in Python, which grows integers automatically, but real in languages like Java or C++), and cycle (for linked structures, a loop that points back on itself and would trap a naive traversal forever). Why it matters: volunteering these — "you list them, you fix them" — shows ownership. Letting the interviewer find them shows the opposite.
8 · Talk tradeoffs
Close by naming the axes you could trade along — the dimensions (time, space, readability) you'd give up one to gain another. Why it matters: the clearest senior signal is recognizing that there's rarely one "best" answer, only choices that fit different constraints.
Example. "My hash-map solution is O(n) time but O(n) space. If memory were tight, I could sort the array first and use two pointers from the ends — that's O(1) extra space, but sorting pushes the time up to O(n log n). So it's a time-for-space trade." That single sentence names two solutions, two complexities, and the constraint that picks between them.
Common pitfalls. Beginners overwhelmingly fail steps 1, 3, and 5 — not the coding. The three deadliest habits: (1) silently coding — typing for two minutes without a word, leaving the interviewer no idea what you're thinking; (2) skipping the brute force and gambling on a clever solution you can't quite finish; and (3) treating it as a written exam — heads-down, no narration. If you remember only one thing, remember this: a coding interview is a conversation, not a test you take in silence.