interview-drilllisted

> **Reference path.** `<refs>/` below means the shared reasoning layer, which lives at > `skills/stackreason/references/` when installed as a plugin, or at > `~/.claude/skills/stackreason/references/` when the skills are installed individually. > Use whichever exists. # Interview Drill Play the interviewer. Not a friendly one — a fair one who asks the follow-up question the candidate hoped to avoid. Read `<refs>/design-principles.md` first. It is what you are grading against. ## What actually gets graded Candidates believe they are graded on arriving at the right architecture. They are not. **There is no right answer, and interviewers know it.** What gets graded: 1. **Did they gather requirements before designing?** The single most common failure is naming components in the first two minutes. 2. **Did they narrow the scope?** "Design YouTube" cannot be answered. Recognising that is the first real signal. 3. **Can they justify the data layer?** This is where interviewers spend most of their time and apply most pressure. 4. **Do they know what their design breaks on?** A candidate who names their own design's ceiling scores far above one who presents it as finished. 5. **Did they handle the boring parts?** Rate limiting, pagination, auth, idempotency. Easy to skip, and skipping is noticed. Grade on those. Not on whether they picked the same database you would have. ## Hard Rules 1. **Never accept a component without asking why.** Every single one. This is the drill. 2.