Learn

Your first idea failed halfway through, and you went quiet until the end

8 November 2026 · A practice plan for the week

You picked an approach, wrote half of it, and saw that it could not work. Then came silence: deleting lines and saying nothing until the new version compiled. The interviewer saw a candidate who was lost, even if you were not.

The weakness

Most practice ends at a correct solution, so we rehearse the path that works and almost never the moment a path stops working. In the room that moment is common.

One engineer wrote on DEV this week about a first interview that ended after twelve minutes. The feedback they eventually got was two sentences, and the second began: "You went quiet for three minutes and I had no idea what you were thinking." This week is built around the fix they chose: practising recovery lines on purpose.

What goes wrong, on one small question

An original example. "Given a list of integers and a number k, is there a pair whose difference is exactly k?"

A natural first idea is to sort and compare neighbours:

def has_pair_with_difference(values, k):
    s = sorted(values)
    return any(s[i + 1] - s[i] == k for i in range(len(s) - 1))

On [2, 9] with k = 7 it returns True. Now try [1, 3, 5] with k = 4. The neighbours differ by 2 and 2, so it returns False, but 1 and 5 differ by 4. The pair is not adjacent, and the idea is dead.

The candidate who goes quiet now usually throws everything away. But the question is still "does v + k exist?"; only the lookup was wrong, and a set answers it directly. And the second version has its own trap: with k = 0, every value finds itself in the set, so [7] returns True. Zero needs its own rule, a repeated value:

def has_pair_with_difference(values, k):
    k = abs(k)
    if k == 0:
        return len(set(values)) < len(values)
    seen = set(values)
    return any(v + k in seen for v in seen)

This returns True on [1, 3, 5] with k = 4, False on [7] with k = 0, and True on [7, 7] with k = 0. Two failures in one small question is normal. What counts is what you said at each.

What to say out loud

The recovery sentence has three parts: the input that broke the idea, what you keep, and what you try next.

"This fails on one, three, five with k equal to four: the pair is one and five, and they are not neighbours. I keep the question, does v plus k exist. I drop the neighbour check and use a set, which makes it linear."

And for the second failure, the same shape in one breath: "With k equal to zero, every value finds itself, so a single seven says yes. For zero I need a value that appears twice; I'll handle it first."

When you hesitate between two workable orders, say the choice and the reason before typing: "Both orders work. I'll do the cheaper one first, and I'll say so if it breaks." A spoken decision can be followed; silent switching cannot.

The exercise

Seven days, starting tomorrow. Each day has one check, and you write the result down in one line.

1. Monday: the baseline. Solve one problem you have not seen, aloud, recording yourself on your phone. Then mark every change of approach. Check: for how many of those changes did you say the input that made you change?
2. Tuesday: break your own first ideas. For three solved problems, write the first idea a hurried candidate would try and the smallest input that breaks it. Check: did you find each input in under two minutes?
3. Wednesday: the three-part sentence. For each of Tuesday's three, say the recovery sentence aloud: the input, what you keep, what you try next. Check: did every sentence name something you keep, and did each fit in twenty seconds?
4. Thursday: two orders, one decision. Take a problem with two workable orders, such as filter then sort, or count then scan. Say which you take and why before typing anything. Check: did you start typing within thirty seconds of saying it?
5. Friday: a name you do not remember. Solve a problem in your weaker language, Java or Python, without looking anything up. Each time a method name escapes you, say the behaviour you need and carry on. Check: how many times did you stop typing instead of saying it?
6. Saturday: a timed round. Forty minutes, one new problem, recorded. Take the first idea that comes, even if you doubt it. Check: from the moment you saw it fail to the moment you said the next plan, how many seconds passed?
7. Sunday: the review. Play Monday's and Saturday's recordings back. Count the approach changes you explained with an input, and the ones you did not. Check: which of the three parts do you still skip? Write it on a card for the next round.

Where this fits in Gadfly

Gadfly has four rooms: algorithms, system design, behavioral and code review. In the algorithms room you code in Java or Python. Tutor mode asks the next question and never reveals the solution, so "what input breaks this?" is the kind of question it puts to you; saying "I'm stuck" gives one more step, up to pseudocode, never finished code. Mock mode gives no coaching during the round, and a debrief at the end quoted from the record, not a grade. Gadfly also records what went wrong in a session and uses it when choosing what you practise next. The plan above works with a phone recorder and a timer instead.