Pathway · Sample Problems
Computing in Business
What real problems look like — and what separates a serious one from the easy way out
You have already read what computing in business 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 real business need a student genuinely cares about, and grow their own problem around it. 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 · Turn business data into a decision
A business is usually sitting on data — sales, customers, transactions — but data on its own changes nothing. A strong problem starts with a real decision someone has to make: which products to stock more of, which region to invest in, which month to prepare for. It then uses analysis to answer that question clearly enough that a person could act on it.
The computational core is turning raw, messy data into information. That means cleaning data so it can be trusted, finding a genuine pattern rather than an obvious one, and presenting the result so a non-technical decision-maker understands it at a glance. This is the identity of the whole pathway.
The easy way out
- Load a clean, tidy dataset and draw one chart
- Report something obvious ("sales rise in December") that no one needs a program to learn
- Stop at the chart, with no decision attached to it
What a serious version demands
- A real question tied to an actual decision
- Messy data that you genuinely clean and validate
- An insight that is not obvious, drawn from the data
- A clear recommendation, with an honest note on how confident you are
Sample problem 2 · Build an operational tool a business would rely on
Businesses run on software that has to be correct: an inventory system that tracks stock, a scheduling system that books staff without clashes, a records system people depend on every day. Building one is a genuine software problem, because it has to keep working — the data must survive after the program closes, and the tool must refuse to enter impossible states.
The real difficulty is in the parts a demo hides: persistence, edge cases, and bad input. A tool that works once, for you, with perfect input is not the same as a tool a business could actually use.
The easy way out
- Add and remove items in a list that vanishes when the program stops
- Assume the user always enters valid, sensible data
- Ignore conflicts entirely — negative stock, a double-booked employee, a crash on bad input
What a serious version demands
- Data that persists between runs, in a file or database
- Real error and conflict handling — no impossible states, no crashes on bad input
- A design someone other than you could pick up and use
- Testing that deliberately tries to break it
Sample problem 3 · Predict something the business needs to see coming
The most valuable business questions are about the future: which customers are about to leave, what next quarter's sales look like, which orders are likely to be returned. Using past data, you can build a model that predicts an outcome — and give a business a chance to act before it happens.
Building the model is the easy part. The real work is evaluating it honestly, because a single accuracy number can hide a useless model. If only 5% of customers leave, a model that predicts "nobody leaves" is 95% accurate and completely worthless. Understanding what a wrong prediction costs is the point.
The easy way out
- Run a model, print an accuracy percentage, declare success
- Never ask whether that accuracy is actually meaningful
- Ignore what a false alarm or a missed case would cost the business
What a serious version demands
- Thoughtful inputs and a clearly defined target
- Evaluation beyond raw accuracy — how many real cases you catch, how many false alarms you raise
- A clear account of what the business should do with the prediction
- Honesty about where the model is unreliable
Sample problem 4 · Find the few records that matter
Some business problems are about spotting the rare, suspicious thing hidden inside an enormous amount of ordinary activity: a handful of fraudulent transactions among tens of thousands, the few accounts behaving strangely. No one can scroll through it by hand. A program that reasons about amounts, timing, and frequency can flag what deserves a closer look.
The core is statistics applied at scale, plus careful judgment. The hard part is defining what "unusual" actually means, and reasoning well enough to catch real anomalies without accusing every large-but-legitimate transaction.
The easy way out
- Sort by amount, call the biggest few "fraud," and stop
- Treat every outlier as guilty, with no reasoning
- Work with a tiny dataset that avoids the real challenge of scale
What a serious version demands
- A defensible definition of "suspicious," built from more than one signal
- Analysis over a genuinely large dataset
- Reasoning that separates real anomalies from normal variation
- A short, evidence-based case for each record you flag
Choosing your own problem
These four problems span a lot of the pathway: turning data into a decision, building a tool a business relies on, predicting what is coming, and finding the rare signal in a flood of records. Other genuine problems live here too — reading the mood of customer feedback at scale, automating a report that is done by hand every month, and more. They are all meant to show you the shape of the space, not to fence you into it.
If a real business problem genuinely interests you, 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 the surface.