Reverse-Engineer an App's Undocumented API and Rebuild It With Better UX

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:** reverse engineer the undocumented APIs of another app, and rebuild the app to improve its user experience. Assume the original is a web or mobile app you can use with your own account, its backend API has no public documentation, and its user experience has clear problems. Confirm which app, and whether you have permission to build on it, before you start. ### Constraints and Clarifications - Time box: 8–12 hours for discovery, 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 - Which app and platform? Do you have an account, and do its terms allow building a client on top of it? - Is the goal a new client over the same backend, or a new product that imports the data? - Which UX problems in the original matter most to its users? - Is the rebuild read-only, or must it also create and change data? - Are there rate limits or other restrictions on automated access? ### Part 1 — Discover the API and plan the rebuild Explain how you would discover and document the API the app uses, how the rebuilt app will talk to it (including authentication), which UX problems you will fix first, and what the prototype defers. Explain how you will use AI coding agents so that the submitted logs show a disciplined workflow. ```hint One action at a time Tie every captured request to the single user action that caused it; a pile of unlabeled traffic is hard to turn into an API description. ``` #### What This Part Should Cover - A systematic discovery method and a written API description with inferred schemas, pagination, authentication and errors. - The rebuilt app's architecture, especially where upstream credentials live and how cross-origin requests are handled. - A prioritized list of UX improvements tied to problems observed in the original. - Legal and ethical checks, and agentic practice with captured traffic redacted before any tool sees it. ### 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 rebuilt app stops scaling first, which user needs it does not yet meet, and where its UI falls short. ```hint The API was never promised to you List every assumption your code makes about the upstream API, and ask what users experience on the day each one breaks. ``` #### What This Part Should Cover - Fragility: how upstream changes are detected and contained. - Scaling limits imposed by upstream rate limits and anti-automation defenses. - User needs: credential safety, reliability, and parity with the features people rely on. - UX in failure states, not only on the happy path. ### 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: users want to create and edit records through the rebuilt app, not only read them, and they need it to keep working when the original app changes its private API. ```hint Retries can duplicate writes Assume the upstream API offers no idempotency keys. Decide what the rebuilt app does when a write request times out. ``` #### What This Part Should Cover - Integrating writes safely: request tokens, duplicate protection, optimistic UI and confirmation of destructive actions. - Detecting and containing upstream changes before users hit them. - A task-level estimate, a roadmap order, and success measures. ### What a Strong Answer Covers - A scope that fits the time box and still delivers a working rebuilt flow with visibly better UX, with deferred items stated. - Engineering for an API that can change without notice: validation at the boundary, contract checks, and graceful degradation. - Sound judgment on permission, terms of service, credential handling and other users' data. - Evidence of disciplined use of AI coding agents rather than wholesale acceptance of generated code. ### Follow-up Questions - If the original app used certificate pinning or signed requests, what would you do, and where is the line you would not cross? - The original company later publishes an official API. How do you migrate your users? - How would you test the rebuilt app without putting load on the real service? - API responses contain data about other users. How do you handle it?