Project 3: The Job Application Tracker API, Assembled and Reviewed

Over the last articles you built one application a piece at a time. This article assembles it, checks it against its requirements, and prepares you to explain it. It is the third project of the course, after the Expense Tracker CLI and the PostgreSQL version.

• The final architecture and where each concept lives.
• How to build, run and test the project from scratch.
• A requirements checklist, an honest limitations list, and extension ideas.
• How to present the project in an interview.

The Job Application Tracker API lets a registered user keep track of the jobs they are pursuing: create applications, move them through the stages (WISHLIST, APPLIED, INTERVIEWING, OFFER, REJECTED, WITHDRAWN), record interviews, filter and page the list, and edit safely when several clients are involved. Every user sees only their own data.

HTTP request   |   vSpring Security filter chain   JWT verification, deny by default, CORS, security headers   |   vControllers                    AuthController, JobApplicationController (HTTP only, DTO records)   |   vServices                       AuthService, TokenService, JobApplicationService (rules, transactions)   |   vSpring Data repositories       JobApplicationRepository, AppUserRepository (every query scoped to the owner)   |   vHibernate / JPA entities       JobApplication, Interview, AppUser   (Flyway owns the schema)   |   vPostgreSQL

The project has 35 main source and resource files and 16 test files. The complete code is in the article that introduced it (the diffs show each change), and the last snapshot is the sum of articles 33 to 38.

You need JDK 21 or newer, Maven 3.9 and a PostgreSQL 18 server with an empty database (the Docker route is described in article 38 and was not verified here). Create the database, then supply the configuration through the environment, never through a file you commit:

export DB_URL=jdbc:postgresql://localhost:5432/jobtrackerexport DB_USER=jobtrackerexport DB_PASSWORD='your-database-password'export JWT_SECRET="$(head -c 32 /dev/urandom | base64)"mvn clean verifyjava -jar target/jobtracker-0.0.1-SNAPSHOT.jar

mvn clean verify runs the 125 tests (they start their own PostgreSQL through the embedded test server, so they do not need yours) and builds the jar. Flyway creates the tables when the application starts. If you forget JWT_SECRET, the application refuses to start and tells you which variable to set.

What was verified for this course: the full test suite passes on JDK 21 and JDK 25, and the HTTP sessions in articles 33 to 38 were produced by the packaged jar on both JDKs (identical output) against a real PostgreSQL 18.6.

1. A GET /api/applications/summary endpoint with counts per stage, computed in SQL.
2. Soft delete and an audit trail of status changes (a new table and a migration).
3. Notes and attachments per application.
4. Login throttling and a refresh-token flow.
5. A scheduled reminder for interviews coming up, with a test using the injected Clock.
6. A Testcontainers version of the database tests, if you have Docker.

Be ready to explain, in your own words and with the code open:

• Why DTOs and not entities in the controllers (mass assignment, stable contracts).
• Where each rule lives and why: validation at the edge, business rules in the service, constraints in the database.
• How ownership is enforced and why other users get 404.
• How you found and fixed the lower(bytea) bug, the N+1 problem and the lagging-version bug, because real problems with real fixes are the strongest evidence of experience.
• What @Transactional does, and the self-invocation and checked-exception traps.
• Why optimistic locking, and what the client must send.
• How passwords and secrets are handled, and what a JWT does and does not protect.
• How you tested it, what the coverage number means, and what the mutation experiment showed.
• What you would do next, from the limitations table.

Article 41 turns these into prepared answers.

• Can someone build and run it from a clean clone using only your README?
• Is anything secret in the repository or its history?
• Does every endpoint have a test for success, invalid input and a missing resource?
• Do you know the generated SQL for each endpoint and the number of statements?
• Can you explain every annotation in the entities and the security configuration?
• Is the README honest about what is missing?

• A project nobody can run, because the README is missing or wrong.
• Committed secrets or a .env file.
• No tests, or tests that only check mocks.
• Entities exposed as the API.
• Claims you cannot defend: "secure", "scalable", "production-ready", without evidence.
• Copying a tutorial without understanding it, which is obvious in the first follow-up question.

• Next: Interview Concepts, Part 1: Core Java, Collections, Functional, JVM, Concurrency.
• Then: Interview Concepts, Part 2: SQL, Spring, Backend, and the Job-Ready Checklist.