Six Markdown files make a study pack, not a software project
Real Company Interview AI Coding Projects contains 6 files at commit 883fd50: a README and 5 Markdown documents. Three documents reconstruct anonymized hiring assignments, one gives a general working method, and one records 24 AI-coding conversations around the author's ForceTrack implementation. The last file movement is reflected in the reviewed commit. There is no application entry point, package manifest, or container definition in this repository.
The entire 6-file pack is written in Chinese. English product terms such as Computer Use, React Native, Action Card, and Human-in-the-loop appear inside the text, but they do not amount to an English edition. Each assignment links to a separate personal implementation. Those links are useful examples, yet the main repository only promises the question retrospectives and method. Readers should assess the documents on that narrower basis.
Three assignments reward product judgment over typing speed
The first brief defines 7 acceptance scenarios for a Computer Use Agent Dashboard built from an existing starter. They cover a visible tool loop, isolated desktop sessions, queued prompts, tool failure, desktop reconnection, and credential boundaries. The assignment explicitly rejects a chat screen that merely claims work was completed. It wants observable computer and shell actions tied to stable run identifiers, plus a final answer based on the action results.
The second brief specifies a React Native iOS MVP with a 48-hour limit. A user supplies a chat screenshot, the model proposes structured cards, and the app may create a meeting or create or update a contact only after confirmation. That approval boundary is the strongest part of the prompt. Failed, cancelled, or unconfirmed actions cannot become durable memory, and repeated taps must not create duplicate calendar or contact records.
The third assignment is smaller and more conventional: build a Jira-style single-user web app in about 8 hours. It expects task CRUD, board dragging, search, filters, a timeline, local persistence, Chinese and English modes, and theme retention. The target is current Chrome at 1280 by 720 or larger. That specificity makes the document usable as a self-test, even if the exercise itself does not prove AI engineering skill.
The playbook turns vague prompts into acceptance checks
The playbook gives separate scope rules for 8-hour and 48-hour take-homes. Across 13 sections, it starts with a requirements matrix, converts prose into acceptance sentences, and tracks each requirement through implementation, testing, and evidence. Before adding features, it asks the candidate to audit the supplied starter, identify existing runtime assumptions, and freeze a minimum vertical path. This is ordinary engineering advice, which is precisely why it works under interview pressure.
AI receives a task contract with context, goal, scope, constraints, acceptance conditions, and required checks. The human keeps responsibility for architecture, tradeoffs, review, security, and the final acceptance run. Validation is split across static checks, domain tests, component tests, end-to-end tests, manual acceptance, and a production build. The text treats an 8-hour exercise differently from a 48-hour project instead of prescribing one process for both.
What happened when we ran it
Our sandbox did not run commit 883fd50. Our measurement setup was a fresh Debian container with 3 CPUs, 8 GB of RAM, no secrets, and unprivileged access, but the harness detected no supported programming-language ecosystem. The repository also has no Dockerfile. We measured repository eligibility only; there was no supported install, build, or test step and no dependency, timing, or test result to report.
That outcome is consistent with the repository's contents: all 6 files are documentation. It should not be scored as a broken app, since it does not present itself as the implementation. It also means the detailed acceptance criteria remain proposals inside this checkout. The separate ai-agent-dashboard, ContactFlow, and ForceTrack repositories would need their own measurements before their code or delivery claims could support a buying or hiring decision.
Twenty-four conversation rounds reveal one worked process
The ForceTrack history condenses 24 real conversation rounds into 7 phases, beginning with scope freezing and ending with handoff material. It shows the project growing from task management into multiple projects, onboarding, feedback-driven polish, and a repository wiki. This is more useful than a polished prompt dump because it exposes sequencing: core state and interactions come before guided tours and documentation cleanup.
There is an evidence limit across the 3 briefs. The company names, interviewers, customers, and original wording are intentionally removed, and the briefs are structured rewrites rather than verbatim materials. That protects people involved, but it prevents an independent reader from checking how closely the documents match actual assignments. Treat the collection as one developer's retrospective and working template, not as a canonical account of how companies assess AI coding.
A one-day-old repository cannot show community health
GitHub says the repository was created and last pushed on August 26, 2026. By August 27 it had 105 stars, 0 open issues or pull requests, no issue history, and no published release. The quick attention is notable, but there is too little elapsed time or discussion to judge maintenance. A zero count here means no public queue, not evidence that readers found no errors.
GitHub also reports no license. Reading the pages on GitHub is straightforward; copying, translating, or redistributing them has less certain terms. For a candidate who reads Chinese, the 3 assignments and shared checklist are worth using to rehearse scope decisions and acceptance evidence. For a team building training material, the missing license and anonymous source history are reasons to choose a longer-running, explicitly licensed alternative.