Writing Exam Questions That Test What You Mean

If you are asked to draft an exam or quiz question for the course you TA, this page is for you. A good exam question tells the instructor exactly what each student understands. A weak one mostly measures who read the question the way you meant it. The techniques below come from well-written computer science exams, and most of them fit in a sentence or two of the question. Your instructor's expectations come first; where this page and your course differ, follow your course and ask.

Defaults that work. If you only take four things from this page:

Start from what students should be able to do, and test one of those things per part.
Show the expected behavior with examples that cover the edge cases.
Write the answer key and the partial credit as you write the question, not after.
Have another TA take it cold with a timer before it goes to the instructor.

Before you write anything

What should students be able to do?

Write one sentence per skill: "trace the flow of an update through an MVC app", "implement an iterator without storing the elements". Each part of your question should test one of these sentences. If a part tests none of them, cut it.

What does the instructor count as correct?

Read their lecture slides and their past exams on the same topic. When a course has more than one instructor, write to the ideas they share, and check any point where their slides disagree before you build a question on it.

How long should it take?

Size the question to the time. If the exam is 2 hours for 100 points, a 20-point question gets about 24 minutes. Students usually need two to three times as long as you do to solve it.

Techniques that make questions work

Show the expected behavior with examples.

Give three or four input and output pairs, and choose them to cover the edge cases on purpose: an empty input, a single element, a typical case, and the case where everything is the same. Students know exactly what "correct" means, and you have your first grading test cases.

runs("")        produces nothing
runs("b")       produces "b"
runs("aabccc")  produces "aa", "b", "ccc"
runs("dddd")    produces "dddd"

Add constraints that force the idea you are testing.

Ask yourself what shortcut a student would take, then rule it out in one line. "Use constant space; do not copy the input into an array" means the only way through the question above is to actually walk the input once.

Give the scaffolding.

Provide the class header, the interface, or a short list of method signatures. Students should spend their time on the concept, not on remembering syntax.

Say what you will grade.

Sentences like "Your solution must reuse the base class's behavior" or "Make no other properties or methods public" tell students what counts. A student who misses it has misread the question, not guessed wrong about your intent.

Hide a design decision inside a coding task.

"You must decide whether to extend the class or wrap it" asks students to write code and show judgment in the same answer. This is a good way to test design thinking without an essay question.

Build wrong answers from real misconceptions.

In a multiple-choice part, every wrong option should be a mistake students actually make. Take them from what you hear in lab, office hours and on the forum. Then a wrong choice tells you what the student believes, not just that they missed.

Limit the length of explanations.

"In one sentence, say whether this follows the pattern and why" forces a precise answer and keeps grading fast. One sentence is enough to show understanding, and it is hard to hide a wrong idea in one.

Test one idea per part.

A question with five or six short parts, each checking one thing, means a student who misses one idea still earns the others, and the scores show the instructor exactly what the class did not get.

Check the size of your own solution.

Model answers for a 15 to 25 minute coding question usually run 5 to 15 lines. If your answer key is much longer, the question is too big. Split it or cut it.

Change the surface, keep the structure.

Students study old exams. Reuse a question's shape with a new scenario so you test the idea, not their memory of last year's answer.

Avoid tricks.

No double negatives, no "all of the above", no wording that only works if you read it twice. Make the hard part the concept, not the sentence.

Be careful with "circle all that apply"

These parts look quick to grade but often are not. If a reasonable student could argue for a different set of answers, you will be writing a paragraph in the key and handling regrade requests. Either choose a case with one defensible answer, or ask for a one-sentence reason and grade the reasoning.

The answer key and rubric

Write the key while you write each part, not after. Writing the answer is how you find out the question is unclear.
Decide partial credit before the exam. For every part, write down what earns full, half and no credit. If you cannot, the question is not yet clear enough.
Have someone take it cold. Ask another TA to solve your draft with a timer, without the key. Anything they argue with is something students will argue with.
Send the instructor a short table with your draft: each part, the skill it tests, and where that skill appears in the lecture material. Ask: "Is there anything here you would not accept as an answer?" Settle disagreements before the exam, not while grading.

When you are the one test-taking it

Instructors often ask a TA to take an exam before it is given. Do it properly; it is one of the most useful checks an exam gets.

Take it under real conditions: closed book if students will be, in one sitting, with a timer. Note your time for each question.
Report your total time and an estimate for students (two to three times yours). Flag it if that won't fit the exam slot.
Mark every place you hesitated over wording, guessed what was wanted, or saw two readings.
Compare the points with the time and difficulty of each question.
Check the answer key against your answers. Every disagreement is a key error or an ambiguity.
Suggest partial-credit steps, and the wrong answers you expect students to give.
Send one list of typos, numbering errors and broken code, by question number.
Keep it confidential, and delete your copies when the instructor says to.