Mercury-Interview-Project Docs

Interview Day Walkthrough

2 min read

Interview Day Walkthrough

This walkthrough is the human-oriented path for using the repository during the Mercury coding interview.

1. Confirm the Repo Still Runs

Before the session starts, verify the local baseline:

echo '{"hello":"world"}' | uv run mercury
uv run --extra dev pytest -v

The goal is not to test the final solution. The goal is to prove the environment is healthy before the prompt arrives.

2. Review the Problem, Not the Tooling

Once the solo portion begins, read the prompt end to end before writing code.

The repo already has:

  • a runnable CLI
  • tests
  • packaging
  • docs
  • release automation

That means the time-boxed work should go into understanding the problem and shaping the data flow.

3. Check Any Zoom-Delivered Zip First

If the prompt or dataset arrives as a .zip artifact through Zoom, inspect it before extracting anything:

mise run check-zip path/to/interview-artifact.zip

That is the repo’s explicit “confirm this interview has not secretly become a spear-phishing exercise” step. It checks the archive structure, looks for suspicious contents, and only then gives you the option to inspect extracted files.

4. Implement in the Existing CLI Shape

Start from the path that already works:

uv run mercury

If the prompt expects file arguments instead of stdin, adapt the CLI deliberately, but keep the demo path simple and easy to explain.

5. Keep Notes Worth Turning into Docs

As you work, capture the decisions that will matter later:

  • input and output contract
  • data structures
  • edge cases
  • rejected alternatives
  • testing approach

Those notes can become explanation and how-to cards after the implementation is stable.

6. Export AI Transcripts if Needed

If Mercury asks for AI usage history after the solo segment:

mise run transcript

Pick the relevant session ID from the list, then export it.

7. Release After the Solution Is Documented

After the implementation exists, the intended endgame is:

  1. add solution-specific docs cards
  2. add changelog fragments
  3. trigger the release workflow
  4. use the generated docs tarball and package artifacts as the polished handoff surface

Graph View

Backlinks