Build an App That Helps Friends Decide Where and When to Eat

This prompt is one of five offered in a take-home for a software engineering role on an AI product team. The candidate picks one prompt; across the set they cover frontend, backend and infrastructure work. The take-home is budgeted at 8–12 hours. The chat logs from the AI coding tools you use (such as Cursor, Codex or Claude Code) are submitted along with the code, and the work is judged on agentic development practice, 0-to-1 product scoping, and user or developer experience design. A later onsite round reviews the submission in detail. **Prompt:** build a product that helps a group of friends decide where and when to eat together. ### Constraints and Clarifications - Time box: 8–12 hours for design, code, tests and a written explanation. - AI coding tools are allowed, and their session logs are part of what is evaluated. - The review round treats the submission as a prototype, so anything you defer should be written down with a reason. ### Clarifying Questions - Is this for one group planning one meal, or for groups that plan meals repeatedly? - Must every friend create an account, or can people respond through a shared link? - Where does restaurant data come from: a places or maps API, or suggestions entered by the group? - What should decide "where": travel fairness, cuisine and dietary needs, budget, votes, or some mix? - Is there a deadline for deciding, and who makes the final call when the group is split? ### Part 1 — Scope and build the prototype Decide the smallest version of the product that takes a group from "let's eat together" to a confirmed time and place, and what it defers. Describe the user flow, how the time and place are chosen, the data model and API, and how you will use AI coding agents so that the submitted logs show a disciplined workflow. ```hint Shrink the loop Find the shortest path that ends with every friend knowing the same time and place, and cut anything that does not serve it. ``` #### What This Part Should Cover - A minimal end-to-end flow, including how friends join and respond with the least effort. - A clear, explainable rule for picking the time and ranking places, covering travel fairness and dietary or budget constraints. - A data model and API that fit the flow, with deliberate handling of location privacy. - Agentic practice visible in the logs: a written spec as context, small tasks, tests, and reviewed diffs. ### Part 2 — Product review: trade-offs and scaling limits In the onsite review, the interviewer treats your submission as a prototype and probes it in detail; expect every shortcut to be found and asked about. Explain the trade-offs you made, where the product stops scaling first, which needs of its users it does not yet meet, and where its UI falls short. ```hint Follow the least engaged friend Walk through the flow as the friend who opens the link last and cares least. Where that person stops responding is where the product fails. ``` #### What This Part Should Cover - Trade-offs in identity, how availability is collected, how travel is estimated, and how updates reach people. - Scaling limits, including the cost and quotas of external place and routing services. - User needs: fast decisions, fairness, dietary safety, and changes after a decision. - Mobile UX: effort per response, visibility of who is still pending, reminders. ### Part 3 — A new customer requirement The interviewer then introduces requirements from other customers and asks how you would integrate them, how long the work would take, and how it changes the roadmap. The requirements vary; practice with this one: groups want the app to book a table at the chosen place and time, and to put the plan on everyone's calendar. ```hint Not every restaurant has an API Plan for the places you cannot book automatically as carefully as for the ones you can. ``` #### What This Part Should Cover - Integration with reservation and calendar systems, including fallbacks, updates and cancellations. - A task-level estimate with risks. - A roadmap order and the measures that show the feature works. ### What a Strong Answer Covers - A scope that fits the time box and still delivers one working end-to-end decision flow, with deferred items stated. - Decision rules users can understand and trust, not an opaque score. - Continuity from Part 1 decisions to the Part 2 limits and the Part 3 plan. - Evidence of disciplined use of AI coding agents rather than wholesale acceptance of generated code. ### Follow-up Questions - How would the product change for a group that eats together every week? - How would place ranking change if some friends drive and others take public transit? - What location data would you store, for how long, and who can see it? - Half the group has not responded and the deadline is close. What should the product do?