Pathway · Sample Problems
Computer Science
What real problems look like — and what separates a serious one from the easy way out
You have already read what computer science is and whether it might be for you. This page goes one level deeper. It shows what actual problems in this pathway look like, in enough detail that you can picture the real work involved — and see the difference between engaging with a problem seriously and doing the least you can get away with.
These are examples, not a menu
Every problem below is an illustration of the kind of work this pathway contains — not a list to choose from. You do not have to pick one of these. In fact, the strongest projects usually begin with a problem a student is genuinely curious about — often a real-world task they realise maps onto a known algorithm. You are welcome to build on one of these examples or design something entirely your own. Either way, the standard is exactly the same.
What makes a problem serious
Across every pathway in this course, the difference between a strong project and a weak one is almost never the topic. It is whether the work shows these six things:
- A real question. You are answering something, not just making something.
- A genuine computational core. A real algorithm, model, or analysis does the work — not a few lines that print a result.
- A design decision you can justify. You considered more than one approach and can say why you chose yours.
- Evidence that you tested it. You checked your result against something you can trust, not just "it ran."
- The ability to explain it live. You can walk through your own code and answer questions about how and why it works.
- Honesty about its limits. You can say what your work does not do, and why that matters.
The easy way out is to take any problem — including the ones below — and build only the shallow version: the part that runs quickly and looks finished. That shortcut is visible almost immediately, and it is unmistakable in the oral defense, where you have to explain and modify your own code on the spot. A problem is only as serious as what you do with it.
The thing to understand before you start
You are not assessed on how difficult your topic sounds. You are assessed on the depth of your engagement with it. A simple question taken seriously beats an ambitious one done shallowly, every time.
Sample problem 1 · Implement an algorithm, and prove which one is better
The heart of computer science is not just making something work — it is knowing why one method is better than another, and being able to prove it. A strong problem in this space implements more than one approach to the same task — two ways to sort a list, two ways to compress data — and measures them honestly against each other.
The computational core is the comparison. You implement each approach correctly, then test them across small, medium, and large inputs to see how their behaviour diverges as the data grows — and you connect what you observe to why it happens, in terms of how each one scales. This is the identity of the whole pathway.
The easy way out
- Copy one algorithm from somewhere and run it once on a small list
- Report "it works" with no comparison and no measurement
- Never ask why, or whether anything else would be faster
What a serious version demands
- Two approaches, implemented and understood by you
- Timing and measurement across a range of input sizes
- An explanation of where one pulls ahead and why it scales that way
- A defensible answer to "which would you choose, and when?"
Sample problem 2 · Map a real problem to the right algorithm and data structure
A huge part of computer science is recognising that a messy real-world problem is secretly a known one. Suggesting spelling corrections is really about measuring the "distance" between two words. Matching donors to recipients, or finding the quickest route through a network, are known problems with known techniques. The skill is seeing the problem underneath and choosing the right tool for it.
The core is identifying the right algorithm and the right data structure to support it — and being able to justify that choice against a simpler alternative that would not scale or would miss cases.
The easy way out
- Brute-force it — compare everything to everything — and hope the input stays small
- Grab the first approach that produces any answer
- Give no thought to the data structure or the cost
What a serious version demands
- Recognising the known problem underneath the messy one
- Choosing an algorithm and data structure, and justifying them over an alternative
- Handling the real complications — ties, no valid answer, large inputs
- Knowing the cost of your approach and where it would strain
Sample problem 3 · Tackle a genuinely hard problem
Some problems have no perfect solution — only better and worse ones. Scheduling students into classes without clashes, assigning teachers and rooms, fitting many constraints together at once: these are famously hard problems where you cannot simply try every combination, because there are far too many. Wrestling with one is your introduction to optimisation and constraint satisfaction.
The core is representing the constraints, choosing a strategy that produces a good-enough answer, detecting the conflicts that arise, and reasoning honestly about how good your solution actually is. Here, "good enough, and I know how good" is the real goal — not perfection.
The easy way out
- Assign things in the first order that comes to mind
- Ignore the clashes that result
- Call the messy output a schedule and move on
What a serious version demands
- Modelling the constraints explicitly
- Choosing and justifying a strategy for handling them
- Detecting and resolving conflicts, or honestly reporting the ones that remain
- Evaluating how good the solution is, and where it falls short
Sample problem 4 · Apply machine learning, and understand what it is doing
You can train a model to predict something from data: which course suits a student, what grade someone is likely to earn. Building the model is only a few lines of code. Understanding what it is actually doing — and whether you can trust it — is the real computer science.
The core is not the training call. It is preparing the data, evaluating the model on data it has never seen, and understanding which features actually drive its decisions. A decision tree, for instance, can literally be drawn and read — so "I cannot explain why it predicted that" is never an acceptable answer.
The easy way out
- Paste in a model, print an accuracy number, and treat the prediction as truth
- Leave it as a black box you cannot explain
- Never test it on data it has not already seen
What a serious version demands
- Data prepared thoughtfully, and a clearly defined target
- Proper evaluation on unseen data, not the data it trained on
- An explanation of which features matter and how the model decides
- Honesty about what it cannot know, and where trusting it would be a mistake
Choosing your own problem
These four problems span a lot of the pathway: analysing and comparing algorithms, choosing the right tool for a problem, taking on something genuinely hard, and applying machine learning with real understanding. Other CS problems live here too — building a system around a well-chosen data structure, implementing a classic like a compression scheme, or writing a tool that helps others understand a computing idea. They are all meant to show you the shape of the space, not to fence you into it.
If a problem genuinely pulls at your curiosity — especially a real task you notice maps onto an algorithm — follow it. Bring it to your teacher, shape it into a real question, and hold it to the same six standards above. The students who do well here are not the ones who pick the most impressive-sounding topic — they are the ones who take a real problem and refuse to stop at "it runs."