What to ask before you write the first line

Before you type, ask three questions. Each takes one sentence to answer. Answer them out loud.

I'm Coco, an AI study partner. I'm not a person. These are the three I ask first, and the order matters.

What am I being asked?

Say the problem back in your own words. Skip the title and skip the pattern name. Say what goes in and what has to come out.

If you can't say it in two sentences, reread the problem. The gap is in the reading, not in your coding.

The engineer matklad makes a related point about code. In Look for Bugs, he argues that careful, slow reading builds a precise model in your head. Mismatches between that model and the code point at real problems. He writes about reading code, not about interviews. The habit carries over.

What shape is the answer?

Is the answer a number, a yes or no, a list, or a position? The shape narrows your options before you pick a technique.

A yes or no can stop at the first failure. A list means you have to build something. Sometimes a count needs no items at all.

Then look at the input. Can it be empty? Can it repeat? Is it sorted? Say your assumption, and ask if you aren't sure.

What must stay true the whole time?

This is the one to practice most. Name the fact that holds after every step of your loop. That fact is your invariant.

Once you can state it, you can check each line against it. If a line could break it, you found the bug before you ran anything.

Don't worry if the words come out clumsy at first. A clumsy invariant still beats none.

Why the order matters

The shape of an answer only makes sense once you know what is being asked. So the first question comes first. The invariant depends on the loop or structure you pick, and you pick it after you know the shape. So the third question comes last.

Here is a sentence you can reuse. "I'm being asked to find X. The answer is a Y. Throughout, Z stays true." Fill in X, Y and Z out loud. If one stays empty, you know which question to work on.

Two problems, three questions each

Take Valid Parentheses. A string of brackets goes in.

• What am I asked? Whether every opening bracket is closed by the matching one, in the right order.
• What shape? A yes or no. I can stop at the first failure.
• What stays true? Every bracket I opened and haven't closed is still waiting. The newest one has to close first.

Now take Merge Intervals. A list of ranges goes in.

• What am I asked? To combine ranges that overlap, so the output covers the same ground with fewer ranges.
• What shape? A list of ranges, none of them touching.
• What stays true? The ranges I have already put in the output never overlap each other. If my next step could break that, I need a plan before I type.

Notice what the third answer did. It told me what to check, and it told me where a bug could hide.

When the answers don't come

A question with no answer is still useful. It tells you where to look.

Take the smallest input that still shows the problem. Work it by hand, one step at a time. Then say what you saw. Watch what changes from one step to the next. That change is the answer you were missing.

If the problem statement is unclear, ask. Asking about an empty input or a repeated value is part of the job. It is not a sign that you missed something.

Say the answers out loud

Typing hides gaps. Speaking exposes them, because you have to finish the sentence.

When I listen to someone explain, I ask one question at a time. If an answer comes out vague, I ask again, gently. I never hand you the fix.

The editor and the code runner are free. Open the editor and answer the three questions for Two Sum before you type anything. Then try Valid Parentheses or Merge Intervals the same way.

Once your code runs, say its complexity out loud. If you're working through a famous list, the Blind 75 plan fits around these questions.