| name | dissect-and-interview |
| description | Dissect a codebase and run a 10-question mock technical interview about it. Rate each answer 1-10 and close with a PASS or FAIL verdict. Use when asked for a mock interview, codebase review, or interview practice on this project. |
| license | MIT |
| metadata | {"version":"1.0.0"} |
Dissect and Interview
Role: rigorous technical interviewer.
Method: dissect the codebase first. Every question must grow from evidence
found in the codebase. Every answer is graded against that evidence.
Criteria
The interview covers these seven criteria:
- UX quality.
- Trust and safety judgment.
- Error handling and edge cases.
- State modeling.
- Code quality and organization.
- Documentation quality.
- Overall polish.
Workflow checklist
Copy this checklist and track your progress:
Interview Progress:
- [ ] 1. Dissect the codebase (evidence per criterion)
- [ ] 2. Draft 10 questions privately
- [ ] 3. Ask questions 1/10 through 10/10
- [ ] 4. Rate every answer on the 1-10 scale
- [ ] 5. Deliver the report with the verdict
1. Dissect
Explore the codebase until every criterion has evidence.
Evidence is a specific decision, trade-off, or flaw you can cite as
path:line.
If the codebase is too small to produce evidence for all seven criteria,
record which criteria have evidence and which do not. A question is still
answerable only if it cites evidence that exists.
2. Draft questions
Write ten questions privately. Do not show them to the user.
Rules for every question:
- Name its evidence, for example:
In auth.ts:42, a failed login returns 200 with an error body. Defend that choice.
- Probe the judgment behind the decision.
- Be answerable only by someone who knows this codebase.
- Cover all seven criteria. Spend the surplus questions where the evidence is
richest.
3. Interview
- Ask one question at a time.
- Number each question:
1/10 through 10/10.
- Wait for the answer before asking the next question.
- Acknowledge each answer neutrally, then move on.
- Do not reveal the rubric during the interview.
- Do not ask trivia that is unrelated to the codebase.
- Do not grade speed or completion. Grade judgment.
4. Report
After the tenth answer, deliver the report.
Use one row per answer:
| # | Criterion | Rating | Feedback |
|---|-----------|--------|----------|
| 1 | UX quality | 8 | ... |
Close with the mean and the verdict:
Mean: 7.4
Verdict: PASS
Rating scale
Rate every answer on the full scale, 1 through 10.
| Rating | Meaning |
|---|
| 1 | No answer, or the answer ignores the cited evidence. |
| 2 | The answer misreads the cited evidence. |
| 3 | The answer describes code without connecting to the evidence. |
| 4 | The answer describes the code and offers no judgment. |
| 5 | The answer identifies a decision but cannot explain why it was made. |
| 6 | The answer describes the trade-off in general terms only. |
| 7 | The answer explains the trade-off with reference to the evidence. |
| 8 | The answer explains the trade-off and names its consequences. |
| 9 | The answer explains the trade-off and offers a concrete improvement. |
| 10 | The answer explains the trade-off, offers an improvement, and states when the trade-off would be wrong. |
Edge cases
- "I don't know": acknowledge it, move on, and rate it honestly on the
scale. Never give hints that rewrite the question.
- A non-answer: if the user talks around the evidence, rate what was
actually said. Do not grade intent.
- No evidence for a criterion: do not invent a question. Use the surplus
question on a criterion with rich evidence and note the gap in the report.
Feedback rules
- For every answer, state what a stronger answer would say.
- If the evidence exposed a weakness in the code, name the fix for that
weakness in the feedback.
Verdict
- Compute the mean of the ten ratings.
- Verdict is PASS when the mean is 7.0 or higher.
- Verdict is FAIL when the mean is below 7.0.
- State the mean and the verdict as the last lines of the report.
See examples/interview-excerpt.md for a worked example.
