What you should be able to demonstrate
A project interview is an opportunity to explain how a piece of software behaves and why you made particular choices. A useful preparation target is one complete request journey, one design trade-off, one failure you investigated, and a clear boundary around your contribution. This is a practice framework, not a promise about any employer's interview format.
Choose a project you can run and inspect today. A modest application with understood behavior provides better discussion material than an ambitious repository whose implementation you cannot explain. If it began as a tutorial, acknowledge that starting point and identify your independent changes. Keep credentials and personal user data out of demonstrations.
Build an evidence sheet
Write a single page with five entries: user problem, implemented scope, your contribution, evidence, and remaining limitations. For a fictional campus equipment booking application, the problem is overlapping reservations. Implemented scope might be login, time-slot selection, booking, and cancellation. Your contribution could be the booking endpoint and its tests, while a teammate implemented the interface.
Evidence should point to something observable: a test, a commit, a request trace, or a reproducible measurement. “Scalable backend” is not evidence. “Two concurrent booking requests for the same fixed slot produce one reservation and one conflict” is a claim you can test. Put the accurate version into the resume builder, and retain the details needed to defend it.
Prepare a 90-second introduction: explain the user problem, show the important flow, name your contribution, and mention one unresolved constraint. Stop there and let the interviewer choose a direction. A long technology inventory hides the interesting decisions.
Worked example: trace a booking request
Assume the product offers predefined, non-overlapping slots. A student sends a slot identifier. The server verifies the student's session, validates the slot, checks availability, and attempts to create a reservation. The interface then displays confirmation or a conflict message.
An application-only availability check is insufficient. Requests A and B may both observe an empty slot before either writes. For this simplified model, a database uniqueness constraint on the equipment and slot identifiers prevents two active reservations for the same slot. Cancellation must fit that model: either remove the active reservation while retaining history separately, or use an appropriate uniqueness design for active rows.
PostgreSQL's constraint documentation explains uniqueness and composite constraints. Uniqueness on slot identifiers does not prevent arbitrary overlapping time ranges; a free-form calendar needs a different design. State that limitation before claiming the application solves every scheduling problem.
Explain the result precisely: the database rejects one conflicting insert; the API translates that known condition into a useful response. An unexpected connection failure is a separate case. Your interface should not tell a student the booking succeeded merely because the button was clicked.
Worked example: investigate a slow endpoint
Suppose a fictional search endpoint feels slow. First separate interface rendering, network delay, and server processing. Collect timings with a fixed dataset and repeatable query. If the database filters by equipment category, inspect the query and its plan before adding an index.
Imagine your local experiment records a median of 180 milliseconds before a change and 70 milliseconds afterward over 30 warmed requests against 5,000 seeded rows. Those invented numbers illustrate reporting; replace them with your own measurements. Explain the dataset, machine, query, and sample size. Do not convert a local experiment into a claim about production traffic.
An index can help particular queries while increasing storage and write work. An honest trade-off answer explains why that cost was acceptable for your measured workload and which conditions might change the decision. “Indexes make everything faster” is not a defensible conclusion.
Practise follow-up answers
Use these prompts with a friend or a voice recording:
- Where does the verified user identity come from?
- What happens when two requests race?
- Which error reaches the user, and which detail stays in logs?
- What did you test without external services?
- Which part would you redesign with another week?
For the identity question, explain that request-supplied ownership is untrusted. The server derives identity from verified authentication and checks access to the requested resource. OWASP's authorization guidance recommends permission checks on every request. Hiding a button does not establish server-side authorization.
For an unknown question, identify what you know and what you would inspect: “I have not measured that limit. I would test concurrent requests, inspect database contention, and record failures.” This gives the interviewer a concrete investigation path without inventing certainty.
Practical exercise: a 45-minute project defence
Spend ten minutes drafting the evidence sheet and drawing the request journey. Spend fifteen minutes reproducing one important behavior, including its failure case. Use Testing to choose checks that exercise behavior rather than only implementation details.
Next, record a five-minute explanation without reading your README. Use the remaining fifteen minutes for follow-up questions and revisions. Ask your partner to change an assumption, such as allowing arbitrary booking times. Explain which parts of your design stop being sufficient.
Finish with three artifacts: an evidence sheet, a reproducible test or demonstration, and one corrected resume bullet. Use DSA practice for algorithm weaknesses, aptitude practice for quantitative preparation, and company research to identify role-specific topics. These complement project work; they do not replace understanding your application.
Self-review rubric
Score each dimension from zero to two: zero means unsupported, one means partly explained, and two means explained with evidence.
| Dimension | Evidence for two points |
|---|---|
| Ownership | Your work and teammates' work are distinguished |
| Request flow | Validation, authentication, storage, and failures are traced |
| Trade-offs | A reasonable alternative and its cost are discussed |
| Verification | A meaningful failure case can be reproduced |
| Honesty | Measurements and limitations have clear boundaries |
Eight to ten points is a useful practice target. A lower score tells you what to repair, not whether you will be hired. Rehearse again after repairing the weakest dimension.
Continue on the SDE preparation track
Build on this lesson with Behavioural communication, Responsible AI coding, Revision readiness, Placement mock practice.
Source links
The database and authorization sources linked above support the technical guidance. Exercises, fictional measurements, and the rubric are original teaching material, not employer scoring criteria.