Every one of you has a chore. Something small and repeated and mildly irritating that you do by hand: a tally you keep, a list you retype, a count you always get wrong once, a thing you check three times because you do not trust yourself.

Today you are somebody’s client, and somebody is yours. Nobody builds anything. The only product is a single sentence, written by the interviewer, that the person being interviewed agrees is true.

The task

Twelve minutes each way, in three rounds. Interviewer takes notes; client talks. Then swap, completely, before either of you says anything clever about solutions.

Round one — what happens now (five minutes). “Walk me through it, from the beginning, as if I have never seen it.” Ask for the actual steps, in order, including the boring ones. Where do the numbers come from? What do you write them on? What do you do with it afterwards?

Round two — where it goes wrong (four minutes). “What makes it go wrong?” Then wait. The first answer is rarely the real one, and the silence after it is doing work — do not fill it. Follow up with: “when was the last time that happened?” A specific story beats a general complaint every time.

Round three — what would be enough (three minutes). “If this got better but not perfect, what would ‘better’ look like?” And: “what would you do with the time?” If the answer is “nothing much”, you may have found a chore that is not worth automating, and finding that out in twelve minutes rather than three weeks is a win.

The sentence

Now write one sentence, in your client’s words, not yours:

[Name] spends [how long] doing [what], and it goes wrong when [when], which matters because [why].

Read it back to them out loud. Watch their face. They will correct you — everybody gets corrected — and the correction is the entire lesson of this exploration. Write down what you had wrong.

The manners, which are not optional

  • Ask before you write anything down, and say what the notes are for.
  • Never record another person’s name, contact details, marks, health, or money in your notes. If the chore involves other people, refer to them as “a student”, “a parent”, “a coach”.
  • If your client says something is private, it is private. Do not repeat it in the debrief, and do not put it in a design document.
  • Your client can stop, change their mind, or ask you to delete the notes at any time, including later.

These are the same rules that govern the real interview behind The Community App. Practising them on a friend, about a chore that does not matter, is how they become automatic when the stakes are a real person’s real work.

What tends to surface

That listening is harder and more active than it looks. That the first description of a problem is a summary, and summaries hide exactly the detail that matters. That “it takes ages” turns out to mean four minutes, and “it is fine, honestly” turns out to mean twenty. That the question you did not think to ask is the one that changes what you would have built.

And usually one uncomfortable discovery: the thing your client actually wants is not the thing you were already imagining building for them. Better to learn it now, from a friend, in a room where nothing is at stake.

Where this goes next

The real version — a real person, consent, notes, and a problem statement they sign off on — is Interviewing Your Client, and it is the first milestone of The Community App. The five-minute drill that keeps the habit sharp is What Would You Ask. The reason all of this counts as computer science, rather than as manners, is The Software Development Process: a specification you did not clarify is a program you will build twice.

The answer is not on this page

There is no list of correct questions here, and there could not be. The right question depends on the person in front of you and on the answer they just gave, which is why we practise it on each other before anyone’s real client is in the room.

Curriculum connection

B4.2

use a variety of techniques (e.g., dialogue, questionnaires, surveys, research) to clarify program specifications;

Link to original

B1.2

demonstrate the ability to solve problems independently and as part of a team;

Link to original