CHENG-LIANG1/real-company-interview-ai-coding-projects: three anonymised AI coding interview briefs and a reusable playbook

What three briefs this repository actually contains

The repository collects three project briefs taken from real hiring processes, anonymised and restructured. The README lists them in a table with an ID, the project, its form, what it assesses, and a link to the author's own solution repository.

Brief 01 is a Computer Use Agent Dashboard, described as Web plus Agent plus an isolated desktop. The stated areas of assessment are computer use, the tool loop, session isolation, observability and runtime reliability. Brief 02 is a React Native screenshot action agent for React Native on iOS with a 48 hour limit, assessed on multimodal understanding, structured actions, human-in-the-loop, native tooling and memory. Brief 03 is a Jira-style task management system, a web one-day MVP assessed on requirement trade-offs, CRUD, kanban drag and drop, local persistence, a timeline and delivery quality.

The three solution repositories are separate projects: ai-agent-dashboard, ContactFlow and ForceTrack. The README states that this repository keeps only the brief retrospectives and the methodology, so anyone expecting the implementations in place will be disappointed. That split is deliberate, and it is the first thing to understand about the layout.

The six-stage method and what the three briefs have in common

docs/04-ai-coding-playbook.md breaks the process into six stages: 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 finally time-boxed trade-offs, demo and delivery.

The README then argues that all three briefs, despite looking like an agent task, a mobile task and a project management task, are testing the same set of abilities. It lists them: turning vague requirements into an acceptable P0 scope; using AI to speed up implementation while keeping your own technical judgement; producing a complete closed loop rather than piling up pages or wrapping a model API; handling state, failure, recovery, permissions, persistence and edge cases; proving the result with tests, builds, a demo and documentation; and cutting low-value scope when time runs short.

The sentence worth quoting is the one about where candidates separate: requirement understanding, architectural boundaries, process control, acceptance evidence and the ability to make trade-offs, rather than the volume of code. That is a claim, not a measurement, but it is consistent with the three briefs as described. A one-day MVP with local persistence and a timeline is not a code-volume exercise; the constraint is what you leave out.

Reading order and how to use the briefs before a timed round

The README gives an explicit reading order. If you are preparing for a similar written test, read the three briefs first and the general method afterwards. When you actually sit down to work, it suggests copying the requirement matrix, the task contract and the delivery checklist from the general method, then trimming them to fit the brief in front of you.

That is the whole workflow the repository offers, and it is a documentation workflow rather than an installable one. There is no package to install and no server to start. The repository's top-level entries are README.md and docs/, and there are no releases. The practical first step is therefore to clone and read, for example:

git clone https://github.com/CHENG-LIANG1/real-company-interview-ai-coding-projects
cd real-company-interview-ai-coding-projects
ls docs

The docs directory holds the three brief files, the playbook and the ForceTrack conversation history. Open docs/04-ai-coding-playbook.md and copy the requirement matrix and delivery checklist into your own working notes before you touch a starter repository. What you should see is a set of Markdown documents, not a scaffold you can run.

The ForceTrack conversation history is the most concrete artefact here

docs/05-forcetrack-ai-coding-conversation-history.md is described as 24 real conversation turns covering ForceTrack from PRD to repository wiki. Of everything in the repository, this is the part that shows process rather than asserting it. The briefs tell you what was asked; the playbook tells you what the author thinks you should do; the conversation history shows a sequence of exchanges across a single project, from an initial product requirements document through to generated documentation.

Read it with a specific question in mind: at which turn does the author accept an AI suggestion, and at which turn does the author override one? The README's claim about keeping technical judgement while using AI is exactly the thing that a transcript can demonstrate or fail to demonstrate. A transcript is also easier to argue with than a checklist, because you can see the prompt and the response and decide whether the direction was right.

Note the scope: it is one project's history, ForceTrack, the Jira-style task system. It is not a general sample of how these rounds go at other companies, and the README says nothing about which model or tooling was used.

Where this repository stops being useful

The limitation is structural. This is a retrospective repository. The README states plainly that company names, interviewers, recruiters and business clients are removed, that the briefs are anonymised and structurally rewritten rather than verbatim reproductions, and that only technical goals, constraints and acceptance criteria are kept.

That means you cannot use it to reverse-engineer a specific employer's assignment, and you should not try. It also means the briefs are thinner than the originals: the parts that make a real take-home hard, such as an ambiguous stakeholder request or an unfamiliar existing codebase, have been normalised away. If your goal is to practise against the exact friction of a real brief, a rewritten brief is a weaker substitute.

The repository is also the wrong tool if you want working code. The implementations live in three other repositories, and the README does not document how to run, test or deploy any of them. No licence is stated, so reuse terms for the text are unclear. And because the README itself warns that time limits and confidentiality requirements vary between processes, treating these briefs as a template for what you will be given is a mistake.

How this differs from practising on a generic interview question bank

A conventional question bank gives you a prompt and an expected answer, and the unit of practice is the answer. This repository works at a different level: the unit is the brief plus a method for cutting it down. Brief 03, for instance, is a one-day MVP with local persistence and a kanban board, which forces an explicit decision about what a one-day scope excludes. A question bank rarely asks you to make that decision, because the expected solution is already fixed.

The trade-off is verification. A question bank can tell you whether your answer was right. A brief cannot, because the README gives no grading rubric and no reference solution inside this repository; the linked solution repositories are the author's own implementations, not official answers. You get a more realistic shape of problem and less feedback on whether you solved it. If you need a correctness signal, you will have to generate it yourself, for example by writing the tests the playbook's verification stage asks for.

Maintenance, licence and the cost of following along

The last push to the default branch was on 2026-08-26, so the repository has been touched recently. It is not archived. There are no releases, which is consistent with a documentation-only project: there is nothing to version and nothing to upgrade. The upgrade cost is therefore near zero, and so is the maintenance surface. A change to the repository means a change to a Markdown file.

No licence is stated, so the terms under which the briefs and the playbook text can be reused, quoted or redistributed are not established by anything in the repository. If you plan to reuse the requirement matrix or the delivery checklist in your own material, that is the gap to close first. Nothing in the repository indicates how the briefs were cleared for publication beyond the anonymisation described in the README, and that description is a statement of intent rather than a legal position.

Editorial conclusion

Adopt this repository if you are preparing for a take-home or timed AI coding round and want to see how a brief is decomposed into a P0 scope, a data and state design, and acceptance evidence before you write code. Skip it if you want a runnable project to clone and extend: the repository holds documentation only, with README.md and docs/ as its top-level entries, and the three solution repositories are linked out to separate GitHub projects. Before relying on it, open docs/04-ai-coding-playbook.md and docs/05-forcetrack-ai-coding-conversation-history.md and check that the six-stage method matches the constraints in the brief you actually received, because the README states that real briefs, time limits and confidentiality requirements differ and that the formal material you were sent takes precedence.

Frequently asked questions

Official sources

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