Why coursework is enough
An interviewer asking a first- or second-year student this question already knows what the answer will be about. They are not hoping for a product with paying users. They want to hear how you think about something you made, and coursework is an ideal sample because the setting is controlled: everyone in your year had the same brief, so what you did differently is visible.
The two failure modes sit at opposite ends. One candidate apologises ("it was just a uni assignment") and then describes the brief, which tells the interviewer what the lecturer designed. The other dresses the assignment up as a product, with "users" and "the team", and collapses at the first follow-up. Both miss the actual scoring point, which is your judgement inside the constraints.
Choosing which coursework project
Choose the project with the most decisions you made, not the one with the most impressive title. A small command-line tool where you chose the data structure, designed the file format and wrote your own tests beats a group web app where you styled one page.
Choose something you can still explain in detail. Read your old code the night before. If you cannot say why a function exists, the interviewer will find that function. If you have a longer project, a final-year project walkthrough has its own shape, and a tutorial project you extended works the same way as coursework: credit the source, then talk about your decisions.
If it was group work, be ready to say exactly what was yours. The proudest-work question covers how "we" quietly expands over a long answer; at intern level, the fix is the same. State the team size and your part in the first thirty seconds.
Finding the decisions in assigned work
Students often think coursework has no decisions in it, because the brief told them what to build. Look again. Almost every assignment leaves you to choose how to store the data, how to split the code into functions, how to handle bad input, how to test it and what to do when you ran out of time. Those are the decisions to talk about.
| Weak sentence | Strong sentence |
|---|
| "We had to build a library management system in Java." | "The brief fixed Java and the features. I chose to keep books in a hash map keyed by ISBN, because every operation started with a lookup." |
| "It was quite challenging." | "Returns were double-counted for two days. I added print statements, then wrote a test for the return path, and found I was updating the count in two places." |
| "It worked well and I got a good mark." | "It passed the marking tests, but loading reads the whole file into memory. That was fine for the sample data and would not be for a real library." |
| "I learnt a lot about programming." | "I would write the tests first next time. I wrote them at the end, and they only confirmed what I already believed." |
Each strong sentence gives the interviewer something to ask about. That is what you want. A follow-up on a decision you made is a conversation you are ready for.
Overclaiming the scope of an assignment
Here the answer is won or lost. Describe the project at its true size: an assignment, two weeks, you and one partner, tested against the lecturer's sample data. Then let the decisions carry the weight.
Overclaiming is easy to detect at this level. Interviewers have read hundreds of student CVs and recognise standard assignments. Calling twelve classmates who tried your app "users" invites the question "how many, and what did they report?". Saying "it was a group project of four and I wrote the search and the tests" invites a question about search and tests, which you can answer.
Scope honesty also includes what you did not do. "I did not handle concurrent edits because the brief was single-user" is a strong sentence. It shows you know the limit exists, which is exactly what an interviewer wants from someone they will give a real codebase.
What to say about what you would change
Expect the question "what would you do differently?" about any coursework project, and do not hear it as criticism. The interviewer is checking whether your standards have moved since you built it. Name one concrete change and the reason: a different data structure, tests written earlier, a function you would split, an error you swallowed. One specific change beats a list of five vague ones.
If you have since learnt something that makes the old code look naive, say so. "I wrote my own sort because I did not know the standard library had one" is a perfectly good answer from a second-year student, and a likeable one.
Say that it was coursework, say what the brief fixed, and spend the answer on what you decided. The decisions are the evidence; the assignment title is not.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).