# Sample review

This is a fictional training example for the $99 Interview Answer Review. It demonstrates how to turn a technically accurate answer into a clear account of ownership, problem solving, and evidence. Every fact below belongs to the fictional project.

## The fictional project

Project name: WarehousePickup

- A four-engineer team built an internal React and Node/Express web app.
- The app let warehouse staff reserve pickup windows for outgoing orders.
- The candidate owned the reservation API and the PostgreSQL schema for pickup windows.
- The team found that rapid double clicks could create duplicate reservation attempts for the same order and pickup window.
- The candidate added a PostgreSQL unique constraint for the order and pickup-window combination.
- The candidate updated the server to handle the duplicate-conflict response from that constraint.
- The candidate manually tested repeated clicks.
- The team did not run a concurrency or load test.
- The team did not measure a production reduction in duplicate reservations.

The last point matters. The answer can describe the fix and the test. It cannot claim a percentage reduction, successful production adoption, or user satisfaction that the project did not measure.

## Weak but truthful answer

> I worked on the backend for an internal warehouse app. We had duplicate booking attempts from double clicks, so I fixed the database, added error handling, and tested it.

This answer is accurate, but it makes the reviewer do too much work. "Worked on the backend" hides the reservation API and PostgreSQL schema the candidate owned. "Fixed the database" hides the unique key and the order and pickup-window combination. "Added error handling" hides how the server handled the duplicate-conflict response. "Tested it" gives no way to distinguish repeated-click testing from a concurrency or load test, and it says nothing about the missing production measurement.

## Probing questions

Ask these questions before rewriting the answer. They are designed to recover facts, not to invite a better-sounding story.

1. When you say "the backend and database," which pieces did you personally own?
2. What exact combination had to be unique?
3. What did the PostgreSQL constraint do, and what did the server do when it received the conflict?
4. What did repeated-click testing show?
5. What did that test not show? Did you run a concurrency or load test?
6. What can you honestly say about production impact? Do you have a measured before-and-after number?
7. Which part of the answer describes your work, and which part describes the team?
8. If the interviewer asks what you would test next, what would you propose? Keep that answer separate from what you actually built.

For a real candidate, pause whenever a question exposes a missing fact. Write "not measured" or "I do not know" instead of filling the gap with a metric.

## Improved concise answer

> On a four-engineer team, I owned the reservation API and PostgreSQL schema for WarehousePickup, an internal React and Node/Express app that let warehouse staff reserve pickup windows for outgoing orders. We found that rapid double clicks could create duplicate reservation attempts for the same order and pickup window. I added a PostgreSQL unique constraint for that combination and updated the server to handle the duplicate-conflict response, then manually tested repeated clicks. We did not run a concurrency or load test, and we did not measure a production reduction, so I would describe the implementation and the limits of the test rather than claim a percentage.

The answer uses exactly the project facts above. It does not add users, traffic, performance numbers, concurrency coverage, or a claim that every duplicate was eliminated.

## Why the revision is clearer

- It names the team size and the candidate's owned components in the opening sentence.
- It gives the interviewer a specific failure: rapid clicks could create a duplicate reservation attempt for one order and pickup window.
- It names the database rule and the server's conflict handling without claiming that an application check solved every concurrency concern.
- It says how the change was checked and names the tests that were not run.
- It preserves the absence of a production measurement instead of turning a manual test into a measured outcome.

The point of the review is communication. The candidate supplies the facts, and the reviewer helps make the sequence easier to follow under questioning.