Projects That Help¶

~12 min

In short¶

A project helps an interview conversation when you can explain what it does, why it is built the way it is, what breaks, and what you would change next. Finishing matters more than size. Pick a project at a level you can complete, make it run from a clean clone, and write down its trade-offs and limits.

The three levels¶

Level	Example	What it shows	Acceptance check
1. Working tool	CLI expense tracker that saves to a file or SQLite	You can write, run and test a program, and handle input and errors	Runs from a clean clone using only the README steps; at least 5 tests; bad input gives a clear message, not a crash
2. Small service	REST notes API with a database	HTTP, a schema, input validation, error codes, basic tests	Create, read, update and delete endpoints; schema file in the repo; one test per endpoint; README shows example requests and responses
3. Design with trade-offs	A rate limiter, a URL shortener or a job queue with a worker	Reasoning about the design, measurement, and stated limits	A one-page design note covering requirements, components and at least two trade-offs; one measurement with the method written down; a "known limits" section

Level 1 and 2 projects are where most students start. Level 3 is where you show that you can reason about a system rather than only build one. A level 3 project does not need to be large. A single component, such as a rate limiter with a written design note and a load test, can meet the check.

How to choose¶

Pick a problem you use yourself, or one you can describe to a non-programmer in two sentences.
Go one level above what you have already finished, not three.
Treat a to-do list, a calculator or a weather app as a practice exercise. These are very common. (Author's view.) They stand out only when you add something real, such as tests, storage or a design note.
Do not copy a tutorial and call it yours. If you followed a course, say so in the README and describe what you changed.

Finish checklist¶

[ ] A clean clone runs with the README steps and nothing else
[ ] One command runs the tests
[ ] No secrets are committed (API keys, passwords, .env files)
[ ] A "Limits and next steps" section that is honest about what is missing
[ ] Commits are small and have clear messages
[ ] You can explain each main file in 30 seconds

Using the capstones¶

The Python section has three capstones: a CLI expense tracker, a text adventure and a REST notes API. They map roughly to levels 1 and 2. Build one, then add a level 3 feature, or write the design note for one part of it. Adding a feature you can explain is worth more than adding a feature you copied.

What to avoid¶

Many projects that are all the same CRUD app with different names.
Projects with no tests, no README and no run instructions.
Claims in the README such as "production ready" or "scales to millions" when nothing was tested for that.
A project you cannot run anymore. If the setup breaks on your laptop, it will break for a reviewer.

Try this¶

Pick one project you already have. Write its acceptance checks from the table above into a notes file, then run each check today. Fix the first one that fails.