real-company-interview-ai-coding-projects: Three Anonymized AI Coding Interview Briefs and a Reusable Method

What the three anonymized briefs actually cover

The repository is a set of documents describing interview projects, not a codebase you clone and run. The README presents a table of three briefs, each with a number, a form factor, and the skills it is meant to probe. Brief 01 is a Computer Use Agent Dashboard, described as Web plus Agent plus an isolated desktop, examining computer use, the tool loop, session isolation, observability and runtime reliability. Brief 02 is a React Native screenshot action agent, given as a 48-hour React Native / iOS task, examining multimodal understanding, structured actions, human-in-the-loop, native tooling and memory. Brief 03 is a Jira-style task management system, a one-day Web MVP, examining requirement trade-offs, CRUD, kanban drag and drop, local persistence, a timeline, and delivery quality. The README states the material was anonymized and structurally rewritten rather than reproduced verbatim: no company, interviewer, recruiter or client names appear, and only technical goals, constraints and acceptance criteria are kept. Each brief links to a personal solution repository on a separate branch of the same author's work (ai-agent-dashboard, ContactFlow, ForceTrack), and the README is explicit that this repository keeps only the brief retrospectives and the methodology. That separation is the first thing to understand: if you want reference implementations, you leave this repository. If you want to see how a brief was framed and what a candidate was expected to decide, this is the part that is here.

Who this is written for, and who it is not

The README states the purpose plainly: personal retrospective, job-search preparation and engineering learning. The intended reader is someone facing a timed written exercise, a take-home assignment, or live paired development, who wants to rehearse the decision layer rather than the coding layer. The README's own framing of what the three briefs jointly test is the clearest statement of audience: whether a candidate can turn vague requirements into an acceptable P0 scope, use AI to speed up implementation while keeping their own technical judgement, produce a complete loop rather than a pile of pages or a thin wrapper over a model API, handle state, failure, recovery, permissions, persistence and boundary conditions, prove the result with tests, builds, demos and documentation, and actively cut low-value scope when time is short. The README's closing line in that section says the differentiator is usually not the amount of code but requirement understanding, architectural boundaries, process control, acceptance evidence and trade-off ability. That is a specific claim about what these interviews measure, and it defines the audience narrowly. Anyone looking for a library, a scaffold generator, or a template to start a project from will find nothing to install. There is no package manifest, no build, no test runner described in the material. The repository's primary language is not stated, and no licence is stated either, which matters and is covered below.

The six-step playbook and the order it imposes

docs/04-ai-coding-playbook.md is the reusable part, and the README lists its six stages in sequence: requirement clarification and scope freezing; auditing the starter or existing repository; designing data, state, tools and runtime; vertical slicing and splitting work for AI; human review and automated verification; and time-boxed trade-offs, demo and final delivery. The ordering is the substance. Scope freezing comes before auditing the starter repo, which comes before any design work, which comes before delegating anything to a model. That is the opposite of the common pattern where a candidate opens an editor, asks a model for a first draft, and discovers the actual constraints halfway through. The README also gives a reading order for the repository itself: read the three briefs first, then the playbook, and when actually attempting a task, copy the requirement matrix, task contract and delivery checklist from the playbook and then trim them to the specific brief. Note that the requirement matrix, task contract and delivery checklist are named as artifacts inside the playbook document rather than as files in the repository root, so you retrieve them by reading that document, not by copying a template directory. The playbook is a method description, and the material does not indicate that it ships as tooling.

The AI coding conversation history as a worked example

The README links one artifact that is not a brief and not the playbook: docs/05-forcetrack-ai-coding-conversation-history.md, described as 24 real conversation turns covering ForceTrack from PRD to repository wiki. This is the only place in the supplied material where the method is shown against a concrete delivery rather than stated as steps. Its value is that it makes the playbook falsifiable. A reader can compare the six stages against what actually happened across those turns and see where scope was frozen, where design decisions were made before code, and where review and verification were inserted. The material does not summarize what those 24 turns contain, so the only way to judge whether the history supports the playbook's claims is to read the document. Treat it as the evidence file for the methodology. If the turns show the process being abandoned under time pressure, that is itself useful information for anyone planning a 48-hour task, and the repository does not pre-empt that reading by presenting a cleaned-up narrative in the README.

What is missing: no code, no licence, no runnable path

Three gaps are visible directly in the supplied material, and each changes how you should use the repository. First, there is nothing to run. The README describes three briefs and a method, and states that this repository keeps only the retrospectives and methodology while the solution code lives in three separate repositories. There is no installation command, no configuration key, no test command and no build step anywhere in the material provided. Any article or guide that gives you a command to run for this repository is inventing it. Second, the licence is not stated. The repository metadata does not identify one, and the README does not mention licence terms. Absence of a stated licence is not the same as permissive reuse, and it is not the same as prohibition either; it means the terms are unknown from this material. If you intend to reuse the brief text, the requirement matrix, the task contract or the delivery checklist in your own material, that is the question to resolve first, by checking the repository directly rather than assuming. Third, the briefs are anonymized and structurally rewritten, so they are not the original documents. The README says this explicitly and also warns that different hiring processes have different actual briefs, time limits and confidentiality requirements, and that the formal material you receive always takes precedence. Reading these briefs as a preview of a specific company's exercise will mislead you; reading them as a shape of exercise is what they support.

How it compares with a general system design interview guide

The obvious alternative is a conventional system design interview resource, and the difference in approach is structural rather than a matter of quality. A system design guide typically presents a problem, a reference architecture, and a discussion of trade-offs at the level of components and capacity, with no requirement to produce working software inside the session. This repository goes the other way: every brief has a deliverable with a time box (a 48-hour React Native task, a one-day Web MVP) and an explicit acceptance dimension, and the playbook's stages are ordered around producing a demonstrable result rather than around articulating a design. The unit of evaluation is different too. A design guide asks whether you can reason about a system; these briefs, per the README, ask whether you can turn vague requirements into a frozen P0 scope, use AI to move faster without handing over judgement, and prove the outcome with tests, builds, demos and documentation. If your interview is a whiteboard architecture discussion, this material addresses a different exercise. If your interview hands you a repository and a deadline, the playbook's sequence (freeze scope, audit the starter repo, design state and tools, slice vertically, review and verify, then trade off and demo) maps onto the actual working day in a way a component diagram does not.

Maintenance cost, staleness and licence questions

The repository is not archived and the last push is recorded as 2026-08-26, so it is being touched. There are no releases, which is consistent with a documentation-only project: there is nothing to version and nothing to upgrade. The maintenance cost to a reader is therefore not dependency churn but relevance decay. Interview formats change, and the README itself concedes that actual briefs, time limits and confidentiality requirements vary between processes. A brief that described a 48-hour React Native task in one hiring cycle may be a different shape in the next. The practical consequence is that you re-read the four documents rather than tracking a changelog, and you treat the playbook as the durable part and the briefs as samples. On licensing: no licence is identified in the supplied material, so no reuse permission can be inferred from it. That is a statement about what is known, not legal advice. If you plan to redistribute the brief text or the playbook artifacts, verify the terms at the repository before doing so, and if the terms are absent, ask the author rather than assuming a default.

Editorial conclusion

Adopt this repository if you are preparing for a timed AI coding take-home or paired session and want structured briefs plus a scope-freezing method to rehearse against. Do not adopt it if you need runnable code, a starter template, or an installable tool: the repository holds briefs and method documents only, and the three solution repositories are separate projects. Before relying on it, open docs/01-computer-use-agent-dashboard.md, docs/02-react-native-action-agent.md, docs/03-jira-style-task-system.md and docs/04-ai-coding-playbook.md and confirm the briefs match the format your own hiring process uses, since the README states the actual briefs, time limits and confidentiality requirements may differ and that the formal material you receive takes precedence.

Official sources

1. CHENG-LIANG1/real-company-interview-ai-coding-projects on GitHub
2. Issues
3. README