A well-defined goal, as 0005.a described, tells you where students are going, and assessing readiness tells you where they are starting. A readiness check has to answer three questions. The first is what students already know and believe about the content, including the mistaken ideas they hold. The second is what they bring from outside the classroom, since much of what students know about computing wasn't learned in school. The third is about the check itself: whether it is measuring computing knowledge at all, or something else, such as reading in English. This section takes the three in order.

What students know and believe#

Diagnostic assessment identifies what students already know before instruction begins. It can be a brief pre-assessment, a code-reading task, or an interview with individual students. The most revealing tasks ask students to show their reasoning, and asking students to predict the output of a short program and explain why is especially useful, because a prediction shows how a student thinks code works. "What do you think this code will output, and why do you think so?" reveals far more than asking students how confident they feel, what courses they have taken, or what grades they earned, none of which shows what they can reason through. Similarly, a list of unfamiliar terms to define shows little about reasoning, however long it takes to complete. A diagnostic check should be low stakes, used as ungraded information about what each student knows, since students haven't yet been taught the content and grading it would be unfair; a low-stakes check also gets more honest answers. The results should then be used, especially to group and support students. If half a class traces a loop correctly and half doesn't, reteaching tracing to the whole class ignores what half the class has shown, while forming a group that gets targeted support on tracing, as the others extend their work, responds to the evidence.

Readiness checks should probe for misconceptions, mistaken ideas that are common among novice programmers and that instruction must address directly. Three are especially common, and each can be caught with a small, well-chosen task.

The first is treating = as a statement of lasting equality, as it is in mathematics, when in most programming languages it is assignment, a command to store a value. Consider this program:

a = 5
b = a
a = 7
output(b)

A student who thinks the second line creates a lasting relationship between a and b will predict 7. In fact, the second line copies the value 5 into b, so changing a afterward doesn't change b, and the program outputs 5. A related difficulty is confusing assignment with comparison: a student who gives one meaning to both uses of the equals sign, storing a value in x = 3 and checking a value in if x == 3, may not yet distinguish the two, and a readiness check should probe whether they do.

The second is assuming that a computer infers intent, acting on what the programmer meant even when it isn't written in code. A student who expects a program to do something stated only in a comment holds this belief, since the computer ignores comments and runs only the statements. Asking the student to trace what each statement actually does with the values shows that a computer does only what is written. A task that relies on a library call would hide the problem, because the student never sees the steps.

The third is thinking that a variable can hold several values at the same time. A good check is to predict the output of three lines:

int x = 1
x = 2
output(x)

A student with this belief may report both 1 and 2, while the correct answer is 2, because assignment replaces the earlier value. The choice of task matters here. A program with two different variables, each assigned once, never reassigns a variable, so it can't reveal the belief at all.

What students bring#

Students arrive with widely different computing experience, and much of it comes from outside school, so their experience is far from uniform even when they attend the same school and use the same devices. One student may have built spreadsheets for a family business, another may design levels for a video game, and another may have no programming experience at all. A readiness check should identify existing assets as well as gaps. A student's experience with spreadsheet formulas, for instance, gives the teacher something to build on, although it doesn't replace instruction. Finding these assets requires asking broadly. A survey limited to formal programming courses misses real knowledge gained outside school and tells the teacher nothing about students who have taken no courses, while a survey that asks about many kinds of digital making, such as spreadsheets, games, video editing, and websites, reveals what students know. Asking broadly also avoids ranking students: even a private exam on prior programming still treats one kind of experience as the only kind that counts. Once a teacher knows how varied the class is, instruction can respond, for example by offering extensions to experienced students while using turn-taking structures so that all students contribute. Asking experienced students to teach the others may seem efficient, but it places an undue burden on them.

Whether the check measures what it should#

A readiness check written in academic English measures two things at once, the student's computing knowledge and the student's proficiency in reading English, and for a multilingual learner the second can hide the first. If a student who scores poorly on a written question about loops explains the same loop correctly when shown code and asked aloud, the written format may have limited what the student could show. Using visuals, examples, and a student's preferred language in a readiness check helps separate content understanding from language proficiency, so that the results reflect what the student actually knows. A wordy question about the effect of removing a statement from a loop can be rewritten by showing the loop, marking the statement, and asking, "What happens if this is removed?", which keeps the same idea while removing unnecessary language. Task formats can lower language demands too. Putting scrambled lines of code in a working order focuses on logic with little reading, whereas matching vocabulary words to definitions has low language demands but doesn't test reasoning about a loop. Translation helps, but machine-translated assessments should be checked for technical errors, because a mistranslated technical term can change what a question measures. Knowing what students already know, and what they bring, is the starting point for connecting new learning to it, which is the subject of 0005.c.

• diagnostic assessment: an assessment before instruction that identifies what students already know
• misconception: a common mistaken idea that instruction must address directly
• assignment: storing a value in a variable, written with = in many languages
• comparison: checking whether values are equal, often written ==
• asset: knowledge or experience a student brings that instruction can build on

Practice: practice questions for 0005.b