Cracking the Coding Round

The coding round rewards a process, not a flash of genius. Interviewers have watched hundreds of candidates; they can instantly tell the difference between someone pattern-matching to a memorized answer and someone reasoning their way through. The good news: the reasoning process is learnable and repeatable. Use the same four-phase framework every time until it’s automatic.

The four phases

1. 1

   Clarify2–4 min · inputs, ranges, edge cases
   →
2. 2

   Plan3–5 min · brute force → pattern, agree
   →
3. 3

   Code15–20 min · clean, narrated
   →
4. 4

   Test5 min · trace + edge cases

Catch a wrong approach in Plan, not after you've coded it.

1. Clarify (2–4 min). Never start coding off the raw prompt. Restate the problem in your own words, ask about inputs, ranges, and edge cases, and confirm the expected output. “Can the array be empty? Are there duplicates? Is it sorted? How large can n get?” These questions do double duty: they prevent you from solving the wrong problem, and they emit signal that you think about edge cases before writing code.

2. Plan (3–5 min). State a brute-force approach and its complexity first — this proves you understand the problem and gives you a baseline. Then improve it, thinking out loud about which pattern applies: is this a two-pointer sweep? A sliding window? A hash-map lookup? Get the interviewer to agree on the approach before you write a line. A wrong turn caught here costs seconds; caught after coding it costs the whole round.

3. Code (15–20 min). Now write clean, readable code — good names, small helper functions, no golfing. Narrate as you go, but don’t narrate everything; explain the parts that involve a decision. If you get stuck, say what you’re stuck on rather than going silent.

4. Test (5 min). Walk through your code with a concrete example, out loud, as if tracing it by hand. Then hit the edge cases you surfaced in phase 1: empty input, a single element, duplicates, the maximum size. Finding and fixing your own bug is a strong positive signal — far better than the interviewer finding it.

Silence is the enemy. An interviewer cannot give you credit for thinking they cannot hear. Narrate your reasoning — especially your trade-offs and your course-corrections.

Thinking out loud without derailing

There’s a balance. You want a continuous stream of reasoning, not a monologue of every keystroke. A good rhythm:

• Announce the approach before each block: “Now I’ll build the frequency map.”
• Verbalize decisions and trade-offs: “I’ll use a set here for O(1) lookups, trading a little memory for speed.”
• When stuck, externalize it: “The off-by-one is here; let me check the loop bound.”

When you’re stuck

Being stuck is not failure — how you handle it is the signal. Fall back to a brute force and optimize from there. Try a tiny concrete example to expose the pattern. Consider what data structure would make the expensive step cheap. Ask a clarifying question. Interviewers routinely give small nudges; taking one gracefully and running with it is exactly what working with a teammate looks like.

Practice deliberately

Grinding hundreds of random problems has diminishing returns. Instead, master the handful of patterns in the DSA module — two pointers, sliding window, binary search, BFS/DFS, hashing — because the vast majority of interview questions are one of these in disguise. When you finish a problem, ask “what pattern was this, and what signaled it?” That question is what transfers to the next problem.

Pattern recognition

Variations

Worked problems

MockEasy

• Process
• Communication

Practice clarify → plan → code → test out loud

The interviewer says: “Given a list of integers, return the length of the longest contiguous subarray whose sum is at most k. Assume all integers are non-negative.”

Approach. This drill is about narration. Do not jump straight into code. Show the four phases: clarify constraints, name the pattern, describe the invariant, then test with a concrete example.

Show solution

A strong spoken walkthrough:

Phase	What you might say
Clarify	“Are all numbers non-negative? Great — that matters because shrinking the left side can only reduce the sum. If negatives were allowed, this approach would break.”
Plan	“The brute force checks all subarrays. Because the answer is contiguous and values are non-negative, I can use a sliding window. I’ll expand right, and while the sum exceeds k, shrink left.”
Code	“I’ll track left, running, and best. Each element enters and leaves the window at most once.”
Test	“For [2, 1, 3, 2] and k = 4, the best window is [2, 1] or [3], length 2. Let me trace the shrink when adding 3 pushes the sum over 4.”
Complexity	“O(n) time because both pointers only move forward, O(1) extra space.”

The key senior signal is the non-negative assumption. Without it, the window invariant fails and you would need a different technique.

DrillMedium

• Stuck
• Recovery

You're stuck: what do you say?

You are ten minutes into a problem. Your brute-force solution is clear, but you cannot see the optimization. You feel yourself going quiet.

Approach. Silence makes the interviewer guess what is happening. Convert the stuck moment into useful signal: state the brute force, name the expensive step, try a small example, and ask for a nudge only after showing work.

Show solution

A strong recovery script:

“The brute force is O(n²) because for every start index I’m scanning forward to recompute the same information. The expensive step is redoing work across overlapping ranges. Let me try a tiny example and see whether a prefix sum or a window would let me update incrementally. If the intended direction is different, a small hint on the data structure would help.”

Why it works:

Move	Signal
Names brute force	You understand the baseline.
Names expensive step	You are optimizing for a reason, not guessing.
Tries a tiny example	You can debug your own thinking.
Asks for a targeted hint	You collaborate without giving up.

Bad version: “I don’t know.” Strong version: “Here is exactly where the current approach is too slow, and here are the two patterns I am testing against it.”

DrillMedium

• Complexity
• Rigor

Communicate complexity without hand-waving

You finish a solution that uses a heap to keep the top k scores from a stream of n events. The interviewer asks for time and space complexity.

Approach. Do not just say “O(n log n)” reflexively. Tie the complexity to the operations your code actually performs and to the size of the data structure you maintain.

Show solution

A strong answer:

“For each of the n events, I may push into the heap, and if the heap grows past k, I pop once. The heap size never exceeds k + 1, so each heap operation is O(log k), not O(log n). Total time is O(n log k), and extra space is O(k). If k were close to n, this approaches O(n log n), but for small k it is much cheaper than sorting the full stream.”

Why it works:

Detail	Signal
Counts operations	Complexity follows the code.
Uses heap size k	Avoids the common O(log n) overstatement.
Mentions space	Completes the analysis.
Compares to sorting	Shows trade-off awareness.