Extend a Spring Boot data service with APIs for user stories, plus a test plan

This onsite round is a hands-on build exercise. Ahead of the interview you receive a small starter repository: a Spring Boot application (a Python version is also offered) that exposes a few endpoints which read data from a datastore. You are free to clone it, run it and explore it before the day. In the session, which follows a short self-introduction and leaves you roughly an hour, you are handed user stories and extend the service with the APIs they require. The interviewers say up front that they care most about how you break the problem down, how you design your classes, and what you would test and how. A fully running solution with unit tests earns extra credit but is not the main bar, and you may use an AI assistant to produce test boilerplate as long as you can explain which behaviors the tests must pin down. The real starter domain and stories were not reported. For practice, assume the starter app serves a catalog of items, each with an `id`, `name`, `description`, `category`, `price` and `createdAt`, and already offers `GET /items/{id}` and an unfiltered `GET /items`. The stories are: 1. As a shopper, I can list items filtered by category and by a price range, sorted by price or newest first, one page at a time. 2. As a catalog admin, I can add a new item, and I get a clear error when my input is invalid. 3. As a shopper, I can save items to my favorites, remove them, and list my favorites. ### Constraints and Clarifications - Work in the starter repository's language and framework, following its existing conventions. - There is no authentication system; for the favorites story, assume the caller's user id arrives in a request header. - Assume the datastore is a relational database reached through the repository's existing data-access layer. - Manual verification with an HTTP client is acceptable. Automated tests are a bonus, but a clear test plan is expected either way. ### Clarifying Questions - What default and maximum page sizes should listings use, and is offset-based pagination acceptable? - Is the price range inclusive at both ends, and what should happen if only one bound is given or the bounds are reversed? - Which fields are required when creating an item, and are duplicate names allowed? - Should saving an item that is already a favorite be an error or a no-op, and what if the item does not exist? ### Part 1 — Turn the stories into API contracts Before writing code, define the endpoint for each story: method, path, parameters or body, the success response, and every error response. Explain how the new endpoints fit the conventions already present in the starter repository. ```hint Contracts first Settle parameter names, defaults and status codes before touching code; every edge case you resolve here becomes a line in your test plan later. ``` #### What This Part Should Cover - Resource-oriented paths and methods consistent with the existing endpoints - Explicit defaults, bounds and validation rules for every parameter and field - Status codes and a consistent error body for each failure - Retry-safe behavior for the favorites operations ### Part 2 — Implement with a clean class design Implement the three stories. Walk through the classes you add or change at each layer, where validation and error handling live, and how the listing query is assembled so that it stays correct as optional filters and sort orders combine. ```hint Keep the layers honest Decide what the web layer is allowed to know about storage, and what the business layer is allowed to know about HTTP. ``` #### What This Part Should Cover - Web, business and data-access layers, with request and response models kept separate from stored entities - Centralized validation and error mapping - A safe, composable way to apply optional filters and a stable sort - The data-model change for favorites, including how duplicates are prevented ### Part 3 — Decide what to test and how List the tests you would write for these stories and the level each belongs at. Name specific cases rather than categories, and describe how you would verify the service by hand if there were no time left to automate. ```hint Break it on purpose For each rule you set in Part 1, ask which test would fail if you got that rule wrong. ``` #### What This Part Should Cover - A layered plan: fast unit tests, web-layer tests, data-access tests and at least one end-to-end path - Concrete boundary, invalid-input and not-found cases - Sensible use of test doubles, and where a real database is needed instead - A short manual verification script for when automation is cut ### What a Strong Answer Covers - Resolves ambiguous story details before coding and states the decisions taken - Working, readable code that follows the repository's existing structure - A class design that keeps business rules testable without a running server - Tests chosen by risk and traced back to the rules in the contracts - Time management: a working slice of every story before polishing any single one ### Follow-up Questions - The listing endpoint slows down badly once the catalog grows large. What do you look at first? - Items are being added while a user pages through a listing. What can go wrong with your pagination, and how would you fix it? - Two requests save the same favorite at the same instant. What happens in your implementation, and is it correct? - Product now wants a per-user "recently viewed" list. Where does it fit in your class design, and what changes in storage?