# Three anonymized AI coding interview problems and the method used to cut them > The repository collects three project problems taken from real AI coding hiring processes, anonymized down to technical goals, constraints, and acceptance criteria, plus a six step method for working under a time limit. The author's own implementations live in three separate repositories, so this one keeps only the retrospectives and the playbook. **CHENG-LIANG1/real-company-interview-ai-coding-projects** — 三个匿名化真实 AI Coding 面试项目题与一套通用解题方法 - Repository: https://github.com/CHENG-LIANG1/real-company-interview-ai-coding-projects - Stars: 351 · Forks: 24 - Language: Unknown - License: not declared - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/cheng-liang1-real-company-interview-ai-coding-projects ## Anonymization strips the brief to acceptance criteria The stated purpose is three project problems from real recruitment processes, plus a method that transfers to timed written tests, take-home assignments, and live pair programming sessions. The privacy treatment is spelled out because it changes what you get to read. No company, interviewer, recruiter, or client name appears anywhere. The problem statements were anonymized and structurally rewritten rather than copied verbatim. Only the technical objectives, constraints, and acceptance criteria that demonstrate engineering ability were kept. The effect is that you cannot reconstruct the original brief, and that is the point. A real brief carries domain vocabulary, a client's internal framing, and details that leak the source; stripping those leaves a spec that reads like a requirements document rather than a story someone told you. It also means the difficulty you feel here is not necessarily the difficulty of the original exercise. Everything else in the repository follows from that choice. What remains is a short index, five linked documents, and three pointers to implementations that live elsewhere. ## Problem 01 is a tool loop wearing a dashboard's name The first problem is a Computer Use Agent Dashboard, delivered as web plus agent plus an isolated desktop. The column that lists what it examines names the actual subject: Computer Use, tool loops, session isolation, observability, and runtime reliability. The dashboard is the surface a reviewer looks at, but none of the five examined skills is about building a dashboard. Session isolation and runtime reliability are the two items that separate this from a chatbot demo. An agent that drives a desktop can leave a session half finished, so the question is what happens to the second session while the first is still holding state, and whether a failure mid-run leaves the environment usable for the next attempt. Those are the same questions an operations team asks about a long job. The author's implementation is published separately as ai-agent-dashboard. This repository keeps the retrospective and the methodology, not the source. ## Problem 02 puts a 48 hour clock on multimodal action The second problem is a screenshot action agent for React Native on iOS, and unlike the other two it carries an explicit budget of 48 hours. What it examines is multimodal understanding, structured actions, human in the loop, native tools, and memory. That list reads like a single pipeline: look at a screenshot, decide, emit a structured action, hand control back to a person when the decision is consequential, call a native capability, and remember enough to avoid repeating work. Human in the loop is the item that most affects how the 48 hours get spent, because every confirmation point is a design decision rather than a checkbox. Where you place those points determines whether the agent can finish unattended or stalls on a screen nobody is watching. The author's implementation is ContactFlow. Nothing about its source lives here, which keeps this repository small and also means the solutions cannot be read alongside the problems. ## Problem 03 asks what you chose to leave out The third problem is a Jira-style task management system, web, with a one-day MVP budget. The examined skills are requirement tradeoffs, CRUD, board drag and drop, local persistence, a timeline, and delivery quality. Every item on that list after the first is a well-known building block, and the first one is the exam. A one-day budget against that feature list means the scoring is in the cuts. Drag and drop can be a library call or a weekend. Persistence can be local storage or a file. The timeline can be derived from existing records or maintained separately. Each choice is defensible, and the reviewer is comparing which ones you defended. The author's implementation is ForceTrack, and the repository also links a separate document with 24 real conversation turns covering ForceTrack from PRD to repository wiki. That artifact is the closest thing here to a work log, and it documents how the project actually unfolded rather than how it was planned. ## The six step playbook freezes scope before design The general method is published as a separate playbook document and splits the whole process into six steps: requirements clarification and scope freeze, starter or existing repository audit, design of data, state, tools, and runtime, vertical slices and AI task splitting, human review with automated verification, and finally time-boxed tradeoffs, demo, and delivery. The ordering is the useful part. Scope is frozen before any design work, so the design of state and runtime is shaped by what was kept rather than by what could be built. Slices come after that design, and verification after the slices, which means the thing being tested is the thing that was frozen. Nothing in the sequence lets a late idea reopen scope without an explicit tradeoff. The last step names three deliverables in a row, a decision on what to cut, something to demonstrate, and the handoff. Under a one-day or 48 hour limit, those three are competing for the same hours, and the playbook makes that competition explicit instead of implicit. ## AI raises the speed while the judgment stays with you One line in the shared requirements deserves to be quoted in full, because it is the whole point of doing these exercises with AI: use AI to raise implementation speed while keeping your own technical judgment. The repository also says the goal is a complete closed loop rather than a pile of pages or a thin wrapper over a model API, and that what actually separates candidates is not code volume. The named differentiators are requirements understanding, architecture boundaries, process control, acceptance evidence, and tradeoff ability. Three of those five are things an assistant cannot supply for you, since they are judgements about what to keep and what to prove. The suggested reading order is the three problems first and the playbook second, and the practical instruction for someone about to start is to copy the requirements matrix, the task contracts, and the delivery checklist out of the playbook before trimming them for the specific problem. ## This is a retrospective, not a question bank The repository is two entries, a README and a docs directory holding five documents, and the README says so plainly. The three solution repositories are described as the author's personal implementations for the corresponding problems, containing source code, design documents, tests, and actual delivery records, and they are hosted separately under the same account. This repository deliberately keeps only the problem retrospectives and the methodology. That division is the design decision to be aware of. Reading the problems alone gives you the brief without the evidence of how it was solved, and reading the solutions alone gives you an answer without the constraints. The link between them is the ForceTrack conversation history, which is the one artifact in the set that shows the intermediate work. The closing note is the part to take seriously. The repository is written for personal retrospection, job preparation, and engineering study, and it states that the actual problem statements, time limits, and confidentiality requirements differ between hiring processes, so the formal material you receive should always take precedence. ## Conclusion This repository is worth reading if you are preparing for a timed AI coding exercise, because it shows three briefs stripped to acceptance criteria and a method that freezes scope before design work starts. It is not a question bank and it is not a substitute for the brief you are handed, since the original wording, time limits, and confidentiality rules differ by hiring process. Before using any of it, read the three problems first, then trim the requirements matrix, task contracts, and delivery checklist to the problem in front of you. ## FAQ ### What does real-company-interview-ai-coding-projects actually contain? Three project problems taken from real recruitment processes plus a reusable method for timed tests, take-home assignments, and pair programming. The author's own implementations are kept in three separate repositories, so this one holds only the retrospectives and the methodology. ### How was privacy handled in real-company-interview-ai-coding-projects? No company, interviewer, recruiter, or client names appear, the problem statements were anonymized and structurally rewritten rather than copied verbatim, and only the technical goals, constraints, and acceptance criteria were kept. ### What are the six steps of the playbook in real-company-interview-ai-coding-projects? Requirements clarification and scope freeze, starter or existing repository audit, design of data, state, tools and runtime, vertical slices and AI task splitting, human review with automated verification, then time-boxed tradeoffs, demo, and final delivery. ### How much time do the problems in real-company-interview-ai-coding-projects allow? The React Native screenshot action agent is a 48 hour React Native and iOS task, and the Jira-style task system is a one-day MVP. The Computer Use Agent Dashboard problem does not state a time limit in this repository. ### What should I copy from real-company-interview-ai-coding-projects before starting a problem? Copy the requirements matrix, the task contracts, and the delivery checklist from the general method, then trim them for the specific problem. The suggested reading order is the three problems first and the playbook second. ## Sources - [CHENG-LIANG1/real-company-interview-ai-coding-projects on GitHub](https://github.com/CHENG-LIANG1/real-company-interview-ai-coding-projects) - [Issues](https://github.com/CHENG-LIANG1/real-company-interview-ai-coding-projects/issues) - [README](https://github.com/CHENG-LIANG1/real-company-interview-ai-coding-projects/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cheng-liang1-real-company-interview-ai-coding-projects