How to check for understanding without stopping the class

Silence after "any questions?" sounds like understanding, but it rarely is. Students who are lost often don't know what to ask, students who half understand don't want to say so in front of the room, and the one student who does answer speaks for nobody else. Barak Rosenshine's review of classroom research describes exactly this habit in the less effective teachers: they asked "Are there any questions?", heard none, assumed the class had learned the material and handed out the practice work.

"Thumbs up if you understand" has the same problem. It asks students to judge their own understanding, and a student who has misunderstood usually doesn't know it yet. A check for understanding asks a question that has an answer, so you see what students can do, not how they feel about it.

Ask the whole class at the same time, so nobody waits to copy a neighbour and you hear from the quiet students too. Any of these works:

• Mini whiteboards or paper: everyone writes an answer, then holds it up on your signal.
• Fingers: one to four fingers for options A to D, held against the chest so neighbours can't see.
• A poll on their screens: each student taps an answer, and you watch the count come in.
• Show me the result: in a hands-on class the work is the answer. "Paste what your terminal printed into the chat" tells you more than a question about it.

Keep it to one question and a minute or two. Greg Wilson suggests a check like this every 10 to 15 minutes; in a hands-on lesson the natural place is the end of a step, before the next new idea.

The most useful check is a multiple-choice question whose wrong answers are mistakes students actually make. Then the answers tell you not only how many students are confused, but what they are confused about.

Wilson's example is a question for children learning to add: what is 37 + 15? The right answer is 52. A child who picks 42 doesn't understand carrying. One who picks 412 treats each column as a separate sum. One who picks 43 carries the 1, but back into the column it came from. Each wrong answer calls for a different explanation.

The same works in a coding class. Ask what this prints:

x = 5
y = x
x = 7
print(y)

Offer 5, 7 and x. The right answer is 5. A student who picks 7 thinks y stays tied to x; a student who picks x thinks the name was copied, not the value. You know which explanation to give before you say a word.

Good wrong answers come from the mistakes students made the last time you taught this, the questions they asked, and the mistakes you made yourself when you learned it.

Answers are only worth collecting if they change what you do next. Decide before you ask what each result will mean:

The 80% comes from research on guided practice: Rosenshine reports that the optimal success rate while students practise appears to be about 80 percent, high enough that they are learning and low enough that they are challenged. Australia's education research organisation gives teachers the same 80% as the point to move students on to practise on their own. The neighbour discussion is Eric Mazur's peer instruction. Students answer alone, then spend two to four minutes convincing the people around them, then answer again. In Crouch and Mazur's courses, discussion raised the share of right answers substantially whenever 35% to 70% had been right at first. Below that there isn't enough right reasoning in the room for discussion to help, and that is when you teach it again.

Between the rows, it's your call. Wilson puts it plainly: you won't always be able to give everyone what they need, and deciding whether to catch up the few or keep the many moving is the teacher's job.

A check stops the class only if the class has to wait for it. A few habits keep it in the flow of the lesson:

• Ask at the end of a step, when students would pause anyway, not while they are halfway through typing something.
• Put the question where they are already looking, on their own screen or the projector, so you don't need everyone's attention first.
• Don't wait for the last answer. Once most of the room has answered, read the answers and decide. Latecomers can still answer.
• Give the fast finishers something to do, such as the next step or a stretch task, while you deal with what the answers showed.
• Don't grade it. The check is for you, to decide what to teach next. Students answer honestly when a wrong answer costs nothing.

Between checks, a done signal at the end of each step tells you who is moving and who isn't. That is a different question from who understood, and how to tell which students are stuck covers it.

Workshopy has two ways to ask, and both reach every student's screen while they work.

A quiz step, written into the lesson. #[quiz] starts a quiz step, each ## heading inside it is a question, and - [x] marks the right answer (how to add a quiz to a workshop has the whole format):

#[quiz] Quick check

## Where does the style tag go?

- [x] Inside the head
- [ ] After the closing html tag
- [ ] Inside a paragraph

When the class reaches it, answers come in live. You see how many students have answered, how many picked each option, which option is right, and how many each student got right. None of that is on the students' screens. They see whether they were right only when you press Publish results, or as soon as they answer if you turn on Show answers right away.

A poll in the middle of a step, for the question you didn't plan. Open Send in the console beside the room (Broadcast in the ⋯ menu on a phone), press New, write the question, set Students answer to One choice and add the answers. It pops up on every student's screen, or sits as a banner across the top, and the panel counts each answer as it arrives.

After the class, the report's Polls & quizzes card keeps every question: how many answered, how many were right, and how the answers split. The question most of the class got wrong points at the step to explain differently next time.