I've been teaching competitive programming at Purdue since 2022, and I'm still thinking about how to make the course better. Each semester, I ask whether students are learning what I hope they are, whether my assessments let them demonstrate what they know, and what I could do differently.

The course is built around solving problems. Students encounter an unfamiliar problem, figure out what it is asking, design an efficient algorithm, implement it, and test it. Along the way, they make mistakes, get stuck, try again, and develop a better understanding of how they solve problems.

Students with laptops face a projection of the Floyd-Warshall algorithm during class.
A typical day in competitive programming.

I push students hard, but I don't expect them to remember every algorithm or problem we cover. My goal is for them to leave with stronger problem-solving skills that they can apply long after they forget the details of the course. These lasting abilities are among the course's Enduring Outcomes, which help guide its learning objectives and assessments.

Why didn't I have a final?

For a long time, I resisted the idea of a traditional final exam. I don't think a timed, individual exam gives all students the best opportunity to show what they can do. A student might understand a problem and have a sound approach, but spend most of the exam stuck on one small bug. I've been there too!

Instead, I have used short interviews throughout the semester. Students explain one of their solutions without looking at their code, and I ask questions about their approach. I find these conversations valuable because I can see how students think, ask follow-up questions, and give them a chance to explain their understanding in their own words.

Why have one now?

This semester, fewer students have been coming to office hours. Last semester, I saw a few students each week. This semester, I've seen a few across the entire semester, even though I haven't changed my office-hours policies or approach. We're seeing a similar trend in other CS courses at Purdue.

I suspect that more students are going to GenAI for help instead of instructional staff, although I can't know that from the attendance numbers alone. My feelings about that possibility are mixed. One consequence of the drop in attendance, regardless of the cause, is that I've had far fewer opportunities to talk with students about their solutions and get a sense of how their problem-solving skills are developing.

An accepted submission tells me that a program passed the tests, but it doesn't really tell me how a student arrived at the solution, what they understood, or whether they could apply the same ideas to a new problem. I wanted another opportunity to see what students could do near the end of the course.

My first thought was to interview everyone. With around 60 students, though, even ten-minute interviews (our standard) would take roughly ten hours, not including scheduling or follow-up. That's a lot to add at the end of the semester, even with help from my TAs.

So I started thinking about an in-person final. But I still had the concerns that made me resist one in the first place. How could I learn more about students' abilities without making the assessment depend too heavily on whether they got stuck on one small issue?

Ethan at his desk with one dog on his lap and another under the chair. A monitor reads CLASSIFIED.
Pondering the final.

One part of my answer was to give students up to five hours. I expect most to finish in two or three, and they can leave when they're done. I don't like timed exams, so the longer window is meant to give students plenty of time to think, test, and recover when something goes wrong.

But I kept coming back to the question of what should happen when a student gets stuck. More time helps with some things, but these problems are complex, and I personally know how long it can take to find a tiny bug. Spending the rest of the final chasing that bug could turn into unproductive struggle (as opposed to the productive struggle of solving problems alone during the regular semester). Just giving students more time didn't feel like a complete answer.

What if we let students ask for help?

In office hours, I trust my TAs to guide students without giving away the answer. That's how I train them: ask about the student's approach, help them examine their assumptions, and work through where they are in the problem-solving process. This kind of support (scaffolding) is intended to help students make progress while leaving the thinking to them. The goal is for the student to be able to solve a similar issue on their own in the future.

If I can trust my TAs to do that in office hours, why not trust them to do it on the final?

Ethan stands in an inflatable dinosaur costume beside students working on laptops.
Keeping an eye on things, Halloween 2026.

I decided to let students ask us for guidance during the exam. We can talk through their approach, look at their code, and potentially help with debugging once they've demonstrated that they're on the right conceptual path. We'll guide them toward identifying the issue rather than telling them what the solution or bug is.

I don't want my TAs to act as “next-hint bots,” simply pointing students toward the next step whenever they get stuck. I want them to act as teachers: listen to how a student is thinking, ask questions that help the student examine their own work, and help them develop an approach they can use again. That is a difficult balance, but it's one we already work on in office hours.

I settled on a simple structure for asking for help during the final:

  • Students can ask a TA or me for help three times.
  • After that, they can still ask for help, but they'll come directly to me.
  • Questions that only clarify a problem statement don't count toward the three, and there is no grade penalty for asking for help.

I chose to handle additional questions myself because I want to understand where a student is having trouble and think about how best to help them move forward without taking over the problem.

The final will still contribute to the course grade (it's still a summative assessment), but the guidance also gives students feedback they can use while they are working. I want them to have an opportunity to learn from the assessment itself, not just receive a result at the end.

Of course, if a student solves a problem after receiving guidance, an accepted submission alone doesn't show that they could have solved it completely on their own. But the problems require many steps, and we won't be walking students through all of them. Students will still need to develop, implement, and test their solutions. When they do ask for help, the conversation can give us a better look at how they're thinking, what they understand, and how they respond when asked to examine their own work.

I don't know yet exactly how this will play out. I'll pay attention to the kinds of questions students ask, talk with my TAs about what they observe, and use that experience to think about future versions of the course.

I want students to become independent problem solvers, and I want the final to give them a meaningful opportunity to demonstrate what they've learned. I also want them to be able to keep learning during the assessment, without one small issue preventing them from showing the rest of what they can do. This is my attempt to bring those goals together.

Ethan teaches beside a projected graph in an inflatable dinosaur costume.
Teaching algorithms, Halloween 2023.
Students and Ethan pose in costume at the front of the classroom. Ethan wears a black unicorn costume with a yellow mane.
Halloween in competitive programming, 2025. I’m the unicorn.

Related ideas in the literature

As I put my formal CS education researcher cap back on, I found that other computing educators have wrestled with the same question: how can we help a student past an obstacle during an assessment while still learning what they can do?

Bennedsen and Caspersen (2007) described a practical programming exam in which TAs helped students who had spent several minutes stuck on a small issue, but did not help with more fundamental problems. When unsure how far to go, the TAs consulted the lecturer or examiner. Their exam assessed both the programming process and the finished product, whereas credit on my final will depend on accepted solutions.

Kumar (1999) also allowed students to request hints during programming exams, with the goal of preventing one obstacle from derailing the rest of the test. In that design, students gave up points for the part they received help on. I made a different choice: students won't lose points for asking, but we will limit what we tell them.

There are examples in competitive programming courses, too. At Aalto University, staff have offered hints during the second half of practice contests that count toward students' grades. That's a different format from a final, but it is another example of combining contest problems with instructional support.

The question of when to help and what to say remains difficult. An ITiCSE working group (2022) studied how experts decide when to provide feedback to novice programmers and found that they did not always agree. Their work concerns programming practice rather than a final exam, but the question is directly relevant to how I prepare my TAs.

There is also a connection to dynamic assessment (cf. Poehner and Wang, 2021), which considers how a learner responds to support during an assessment. My final is not designed to systematically measure students' responsiveness to guidance, but those conversations may still help us understand their thinking in ways that a submission alone cannot.

References