I recently received some feedback online about the Python challenges I have been creating for students. The criticism was that some of the challenges were too open ended. They did not always specify an exact input, they did not always prescribe an exact output, and in some cases there was no automated test that could definitively say that the problem had been solved correctly.
What interested me was how different that feedback was from what I see in the classroom.
My Python Code Lab challenge collection includes a mixture of tightly focused exercises and more open-ended problems. Some are designed to practise a particular technique, while others leave students with more freedom over how they approach the task. In my lessons, those more open challenges are often the ones students enjoy most because they are able to solve the problem in their own way rather than trying to guess the exact solution I had in mind.
One of the most common things I hear is simply, “I’ve finished.”
That sounds unremarkable, but it is actually quite interesting. The student has had to decide what finished means. They have read the challenge, chosen an approach, written the code, tested it and judged whether the program actually solves the problem. Instead of waiting for a website to give them a green tick, they have made that decision themselves.
That often leads to a much richer conversation. I might ask them to show me how it works, explain why they chose a particular approach or test it with an unexpected input. Another student may have solved the same challenge in a completely different way. At that point, the activity becomes less about reaching one prescribed answer and more about discussing design decisions.
This is quite different from the way many online coding platforms work. A typical programming puzzle gives a precise set of inputs, defines exactly what should be produced and then checks the solution against a series of visible or hidden test cases. There are very good reasons for that model. It is clear, scalable and easy to assess. It also teaches an important programming skill: implementing a specification accurately.
That matters. Real programmers often work with precise requirements. If a function needs to accept a particular type of data and return a particular result, creativity does not mean ignoring those constraints. There are times when the exact input, output and behaviour are the whole point of the exercise.
But I do not think every programming challenge needs to work like that.
Programming is also about making decisions. Imagine asking students to create a program that helps someone choose a film. One student might ask for the user’s age, another might ask about genre, another might use a list of films and make recommendations, while someone else might add ratings or random choices. The challenge can still involve selection, lists, validation and user input, but the final result does not have to look the same for every student.
There is no single correct output in a task like that, but there can still be a great deal of computational thinking. Students have to decompose the problem, decide which information matters, choose appropriate data structures, build algorithms and test whether their solution behaves sensibly. Those decisions are not separate from programming. They are a core part of it.
Of course, there is a difference between an open-ended challenge and a vague one. Telling a beginner to “make something cool in Python” may work brilliantly for one student and leave another completely stuck. Good open-ended challenges still need enough structure to give students a clear starting point. The concept can be constrained while the final implementation remains flexible.
That balance is something I increasingly value. I can require a student to use a loop, validate data or work with a list while still leaving them room to decide what the finished program should actually do. The learning objective remains clear, but the student retains some ownership over the solution.
There is also something valuable in asking students to decide whether their own program is complete. They have to consider whether it works, whether it has been tested properly and whether it actually solves the problem they were given. These are questions that professional programmers ask all the time. Real software rarely ends with a giant green tick appearing on the screen.
I still use tightly specified exercises, especially when I want students to focus on a particular algorithm, syntax feature or assessment-style problem. Sometimes precise inputs and outputs are exactly what is needed. But I also want students to experience programming as something more than producing the answer expected by an automated judge.
Perhaps the real question is not whether programming challenges should be open ended or tightly specified, but when each approach is most useful. Precise tasks are excellent for practising accuracy and specification. Open-ended tasks can create space for creativity, judgement and ownership.
For me, the most interesting moment is when a student stops asking, “What answer do you want?” and starts saying, “I’ve finished – let me show you what I made.”
That feels like a small but important shift. They are no longer just completing programming exercises. They are beginning to think like people who can design and build software.
