Learn

You saw a bug in your own code and fixed it without saying a word

27 October 2026 · Explain it out loud

You are halfway down the function when you see it: that line is wrong for some input. You go back, change a condition, and carry on. To you it was a good moment. To the interviewer, a line changed for no reason they heard, and they cannot tell whether you found a bug or lost your nerve.

The situation

A short task, said aloud: "Split a list of task sizes into batches, in order, so that no batch adds up to more than a limit. Start a new batch when the next task does not fit."

A first version comes quickly:

def batches(sizes, limit):
    result, current, total = [], [], 0
    for s in sizes:
        if total + s > limit:
            result.append(current)
            current, total = [], 0
        current.append(s)
        total += s
    if current:
        result.append(current)
    return result

On [2, 3, 4] with a limit of 5 it returns [[2, 3], [4]]. That is right, and it is the kind of input most people try first.

The input that exposes it

Now take one task that is bigger than the limit on its own: [7] with a limit of 5. The first check sees 0 + 7 > 5, so the code closes the current batch, which is still empty. The result is [[], [7]]. An empty batch went out, and anything that later sends batches to a worker will send nothing and count it.

The fix is small: only close a batch that has something in it.

        if current and total + s > limit:

With that, [7] gives [[7]], and [2, 3, 4] still gives [[2, 3], [4]]. But the fix also hides a decision. A task of size 7 now sits in a batch whose total is over the limit. Whether that is acceptable, or should be an error, is not something the code can decide. It is a question for the person who set the task.

What to say out loud

When you see a bug in your own code, the bug is not the problem. Fixing it in silence is. Four sentences, in order, turn it into the strongest evidence you will give all round.

Mark the stop. "Wait, I think this check is wrong for one case. Give me a moment to confirm." Now the pause has a reason and an end.

Name the input, then trace it. "If the first task is bigger than the limit, total plus seven is over five, so I append the current batch, and it's empty. So [7] gives an empty batch, then seven." Saying the input before the fix proves you understood the failure, not just felt it.

Say the fix and what it keeps. "I'll only close a batch that has something in it. The normal case, two, three, four, still splits the same way." This is the line that shows you checked you did not break what worked.

Ask the question the fix uncovered. "That leaves a single task over the limit in a batch of its own. Is that what you want, or should it raise?" One word from the interviewer answers it, and you have shown you can see a requirement hiding in an edge case.

The whole thing takes about thirty seconds. Compare that with a silent edit, followed twenty minutes later by the interviewer typing [7] themselves.

The exercise

1. Take a function you wrote in the last week that loops over a list and groups or splits it. Do not run it.
2. Write down the smallest input where one item breaks the rule on its own: too big, too small, empty, or negative. Predict the output before you trace it.
3. If the prediction is wrong, say the four sentences aloud, in order, with a timer. Stop at forty-five seconds; if you are still talking, cut the trace to the one line that matters.
4. Write the fix, then say aloud which earlier input you re-checked and what it still returns.
5. Record one practice solution this week and count the edits you made without a sentence before them. That number is the one to bring down.

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 and the tutor speaks English. In tutor mode it asks the next question and never reveals the solution, so "what does this return for a single task over the limit?" is the kind of question it puts to you; if you say you are stuck, it gives one more step, never finished code. Mock mode behaves like an interviewer instead: no coaching during the round, and a debrief at the end quoted from the record.