Interview Repo Architecture
This repository is intentionally heavier than the current application code because it is optimized for a constrained coding interview, not for a blank-slate greenfield project.
What Is Prebuilt
Before the real prompt exists, the repository already provides:
- a runnable Python package and CLI
- tests
- release automation
- a documentation system
- changelog machinery
- hook-based local enforcement
- practice prompts and datasets
- transcript export support for AI handoff
That lets the implementation session focus on solving the actual problem instead of bootstrapping infrastructure.
Why the Application Is Tiny
The current CLI mostly echoes parsed JSON back to stdout. That is deliberate.
It proves:
- stdin-driven execution works
- packaging works
python -m mercury,uv run mercury, and released package installs all share the same entrypoint- the repo can build, test, and release before the real solution lands
Why the Docs Exist Before the Solution
The documentation system is designed so that after the interview implementation is complete, the remaining work is mostly additive:
- add cards that explain the chosen design
- add any prompt-specific runbooks
- add changelog fragments
- trigger a release to produce a coherent docs bundle and packaged artifact
That is lower-risk than trying to document everything after a time-boxed implementation session.
Why the Practice Problems Stay Secondary
The problems/ directory is there to exercise the workflow and sharpen parsing instincts, not to dominate the repository narrative.
It should remain visible enough to show preparation, but not so prominent that it distracts from the actual interview submission once that work exists.
Related
- interview-session-strategy — how the repo aligns with the expected interview flow
- practice-problem-reference — summary of the rehearsal material