Interview Session Strategy
Mercury’s Phase 2 format is a three-hour session with a short intro, about two hours of solo implementation time, and a debrief. This repo is shaped around that reality.
Constraints That Drive the Repo Design
- AI assistance is allowed only during the solo portion
- the work is open-book
- the prompt is expected to be JSON-oriented
- local execution must already work before the meeting starts
- the implementation needs to be explainable live over screen share
Strategy Encoded in the Repository
The repository favors:
- Python for fast JSON-heavy iteration
- a CLI-first interface that is easy to demo
- prebuilt testing and packaging to remove setup risk
- docs that explain infrastructure and leave only the solution-specific cards to be added later
- transcript export so AI usage can be handed over if requested
Working Rhythm During the Interview
The intended rhythm is:
- read the prompt end to end
- identify the data model and transformation shape
- get a working path running quickly
- improve structure and edge-case handling
- leave time for explanation and cleanup
This is why the repo already has guardrails but not a lot of preemptive application architecture. The prompt should determine the final shape.
Date-Specific Context
This docs pass is preparing the repository for the Mercury coding interview scheduled for April 20, 2026.
That timing matters because the goal is not abstract polish. The goal is to make the repo releaseable and self-explanatory before the implementation session begins.
Related
- interview-repo-architecture — why the repo is pre-staged this way