Code walkthroughs let instructors ask students to explain how a program works, why they made particular choices, and how they would change it.
Used alongside review of the submitted code, they offer useful evidence of understanding while avoiding the assumption that an automated score can prove who wrote it.
What a code walkthrough can show
A code walkthrough is a focused conversation in which a student traces, explains, or modifies code.
The instructor might ask what a function returns, how data moves through a program, or what happens when an input changes.
The goal is to observe the student’s grasp of the work, not to turn a short interview into a perfect measure of authorship.
Walkthroughs can reveal whether a student can connect code to its intended behavior.
They can also surface misconceptions that are hard to see in a finished submission, such as confusion about scope, control flow, data structures, or error handling.
A student may have written working code without being able to explain every detail, so interpret answers in context and allow time to think.
Plan a fair, focused walkthrough
Choose a short section of the student’s own submission that reflects a meaningful learning objective.
Avoid trying to cover the entire project.
A five-to-ten-minute conversation can focus on one function, algorithm, or design decision, with a few follow-up prompts ready in advance.
- Use consistent prompts. Ask students doing the same assignment comparable core questions.
- Share the format ahead of time. Explain the purpose, approximate length, and what students should bring or review.
- Offer reasonable access arrangements. Follow applicable course and institutional processes for accommodations, language access, and scheduling.
- Keep the tone exploratory. Frame the discussion as a chance to explain and learn, not as an interrogation.
- Use the assignment rubric. Assess the same stated learning goals that the course has taught.
Consistency does not require identical conversations.
Students may need different follow-ups to clarify their thinking, but the underlying criteria should remain stable.
If the course has policies about collaboration or AI assistance, communicate them separately and apply them according to the institution’s process.
Questions to ask during a code walkthrough
Start with a broad explanation, then move to a concrete trace or small change.
Open-ended prompts give students a chance to describe their approach before you test a specific detail.
- “What problem is this function meant to solve?”
- “Can you trace what happens for this input, one step at a time?”
- “Why did you choose this data structure or approach?”
- “What would happen if this value were empty, unusually large, or invalid?”
- “Where would you look if this test failed?”
- “Could you change this condition to handle the additional case?”
- “What is one limitation or tradeoff in this implementation?”
Questions should match the student’s level and the concepts covered in class.
Avoid relying on trivia, syntax memorization, or surprise requirements unrelated to the assignment.
If a student cannot answer immediately, invite them to reason aloud, consult permitted materials, or work through a small example.
The reasoning process may be more informative than a quick, polished response.
Use a simple rubric and record observations
A brief rubric makes the conversation easier to assess consistently.
For example, evaluate whether the student can describe the code’s purpose, trace its behavior, explain a relevant design decision, and reason about a small modification.
Define what developing, proficient, and strong performance look like for each criterion before conducting walkthroughs.
Record concrete observations rather than conclusions about intent. “Could trace the loop for the sample input after one prompt” is more useful than “seemed suspicious.” Note the question asked, the student’s explanation, and any support provided.
If the walkthrough contributes to a grade, make its weight and criteria clear in advance.
A walkthrough is a limited sample of performance.
A student may be nervous, tired, unfamiliar with the interview format, or stronger in written than spoken communication.
Consider the submitted code, course work, drafts, version history where appropriate, and the student’s explanation together.
No single answer should carry more weight than the evidence supports.
Interpret AI detection and similarity tools carefully
AI writing classification and source-code similarity analysis answer different questions.
An AI writing classifier estimates whether text may have been generated with AI; a similarity tool compares code for overlap with other sources or submissions.
Similarity can prompt closer review, but shared starter code, standard solutions, libraries, and permitted collaboration can also produce overlap.
Neither kind of result proves authorship or misconduct.
Scores and flags should be treated as leads for review, with attention to the assignment, tool limitations, and applicable institutional policies.
Policies vary, so follow the process established by the relevant school or program rather than creating a separate standard during a conversation.
Turnitin states that its AI writing model does not reliably detect code.
Its AI writing report should not be confused with source-code similarity tools.
Codespy is an external source-code detector; if considering it, review its own documentation and treat any output as one limited input.
This article does not report independent testing or endorse a particular product.
When a walkthrough raises concerns
If the student’s explanation differs from the submitted work, ask neutral, specific follow-ups.
A discrepancy can have many explanations, including misunderstanding, collaboration, use of references, or assistance permitted by the assignment.
Clarify the relevant facts before drawing conclusions.
When a concern remains, document the evidence and follow the course or institution’s review procedure.
Give the student a fair opportunity to respond, and avoid treating a tool score or one difficult answer as a verdict.
A well-run walkthrough supports better teaching and a more informed review because it centers observable understanding and keeps claims proportional to the evidence.