PanelMock-Interview App

Panel is a mock-interview coach. You pick a role, a seniority, and an interview type, and it asks you questions one at a time, scores each answer against a rubric, and shows the exact words from your answer that earned each score. After a session you get a radar chart, your best and weakest answers, an improved example, and a practice plan.

Claude mode has only been tested with a fake fetch. It was never run live against the 12 references, so I do not know yet how well the model and the local scorer agree. Voice dictation needs a real microphone and browser, so it was not checked. The full click-through was not done by hand; each view was rendered in headless Chrome, including a live question with the timer running.

This was on the Claude Code list on the tandem day with Codex. I set the spec: the eval loop is the headline, local mode has to be deterministic and tested, and the API is never called during the build. Claude Code wrote the pure core first (text analysis, rubrics, local scorer, grader validation, session machine, report), then the test suite, then the UI.

Claude drafted the 65 questions, their key points and synonyms, and 12 reference answers: weak, okay, and strong. The bands for those answers were fixed before any tuning. Then it tuned the local scorer until every reference landed in its band, with weak below okay below strong for every question.

The optional Claude grader has to return a score plus a quote from your answer for every criterion. The core normalizes case, quotes, and punctuation, then checks that each quote is really in the answer and at least three words long. Grounded scores blend 60/40 with the local score. Ungrounded ones drop to 15% weight. If fewer than half the criteria are grounded, the model's grade gets thrown out.

The API connection kept dropping long responses, so we wrote small modules (roughly 4 KB per write) and split the tests into parts.

• A grader is only as trustworthy as its calibration set. Answers with bands set up front showed the blind spots fast: follow-up answers were being scored against the full STAR rubric and the full-length target, which was unfair. They now get their own lighter treatment.
• Requiring quoted evidence turns hallucinated grading into something you can check in code. A substring test after normalization catches invented quotes without needing a second model.
• Keyword matching needs stemming on both sides. "disagreed" did not match "disagree" until the stemmer also stripped a trailing e.
• Short tool names cause false hits. "go with Postgres" was counting "go" as a named tool, so "go" and "rest" came out of the list.
• Tooling quirk: a shell substitution turned escape sequences into literal digits inside a regex. The word-count test caught it.

Panel uses the sprint's tested-core shape, split into small test-*.mjs and ui-*.js modules. The evidence idea lines up with #71 and #76: make the model show its work, then verify it in code instead of trusting it.

I would start with the calibration set and the grounding check before writing any UI, because they define what "correct" means. Then I would run Claude mode live against the same 12 references and measure the agreement.