Job Application Tracker case study

How a request flows

Menu loopinput() prompts
ValidationStatus and date checks
sqlite3Parameterised queries
applications.dbLocal file

Why

Job searching at volume gets messy fast. I wanted one local place for statuses, dates, links, and notes.

What I built

01
Designed a menu-driven CLI for adding applications with company, role, status, date, link, and notes.
02
Stored everything in SQLite with Python’s built-in sqlite3 module, so data persists between runs.
03
Added status updates (Applied, Interview, Rejected, Offer, Accepted) with validation, and filtering by status.

See it run

python main.py

[1] Add application
[2] View all
[3] Update status
[4] Filter by status
[5] Exit
Choose: 1
Company: Klue
Role: Software Co-op
Status: Interview
Job link: https://example.com/coop
Notes: Tech screen Thursday
Use today's date? (Y/N): Y
Application added successfully

Choose: 4
Status (Applied, Interview, Rejected, Offer, Accepted): Interview
2 | Klue | Software Co-op | Interview | 2026-10-03 | https://example.com/coop | Tech screen Thursday

Recorded from the real program. Input typed at each prompt is shown after it.

Outcome

A dependency-free tool that keeps a full application history on your own machine. The session on this page was recorded from the real program.

The trade-off

A terminal interface instead of a web one. It was fast to build and keeps data on my machine, but it is harder to use on a phone.

What I learned

Even a small CLI benefits from a clear data model, and persistent storage changes how you think about program state.

What I'd fix next

Add editing and deleting, sorting by date, CSV export, and eventually a small Flask front end.