Interview prep

Interview Prep Skill

This skill has two modes:

1. Prep Mode — Personalize an existing interview template for a specific candidate (resume + template → prep doc)
2. Template Creation Mode — Build a new interview template from a job description (JD → interview template)

Detect the mode from context:

• Resume uploaded + template exists or referenced → Prep Mode
• Job description uploaded or user asks to create/build an interview template → Template Creation Mode
• Ambiguous → ask: "Are you prepping for a specific candidate, or building a new interview template for a role?"

---

Mode 1: Prep Mode

Generate a personalized, opinionated interview prep document by analyzing a candidate's resume against an interview template, enriching with web research, and asking the interviewer targeted questions before producing the final output.

Prep Workflow Overview

1. Gather inputs (resume, template)
2. Analyze resume → build candidate profile
3. Web-search the candidate (LinkedIn, GitHub, articles)
4. Identify gaps, claims to probe, strengths, and risks
5. Ask the interviewer dynamic targeted questions
6. Generate personalized interview prep (markdown)

Phase 1: Gather Inputs

Resume

Look for uploaded PDF or text files that look like resumes. If multiple files are uploaded, check whether some are resumes and some are interview templates. Read the resume fully — use the pdf-reading skill if needed for PDFs.

Interview Template

Find the template using this priority order:

1. Uploaded template — any file matching *interview*template*, *interview*guide*, or *interview*.md in /mnt/user-data/uploads/
2. Templates directory — check ~/interviews/templates/ for saved templates. If Filesystem MCP tools are available, use them to list and read from the user's machine. Otherwise check the container filesystem.
3. Ask the user — if no template is found, ask what position they're interviewing for and whether they have a template to upload. Suggest creating one using Template Creation Mode if they don't have one yet.

If multiple templates exist (uploaded or in ~/interviews/templates/), ask the user which position this interview is for.

Read the full template. Identify:

• What sections need personalization (candidate profile, background probes, scenario selection, challenge selection, etc.)
• What dimensions the template evaluates (e.g., system thinking, code quality, AI fluency)
• What choices the template offers (e.g., Scenario A vs B, Node.js vs C# challenge)

Phase 2: Analyze the Resume

Build a mental model of the candidate across these dimensions:

Experience Profile

• Total years of experience
• Current role, company, tenure
• Career trajectory (startup → enterprise? lateral moves? growth?)
• Primary tech stack vs. secondary/claimed stack
• Domain experience (fintech, security, retail, etc.)

Strength/Gap Analysis (relative to the role)

Map the candidate's experience against what the template tests. For each evaluation dimension in the template, assess:

• Strong fit — clear, deep experience
• Plausible but unvalidated — claims it but no depth signals
• Gap — no evidence, would need to learn on the job

Claims to Probe

Identify 3-5 resume claims that are either:

• Impressive but vague — percentages without methodology, scale claims without specifics
• Keyword-heavy — long lists of technologies with no project context
• Potentially inflated — title/scope doesn't match tenure or company size
• Contradictory — claims that don't align with the rest of the resume

Red Flags & Hypotheses

Form 2-3 hypotheses about the candidate that the interview should test. These are NOT disqualifying — they're open questions. Examples:

• "Lists Node.js but every project is Java — is Node.js real or decorative?"
• "All enterprise background — can they operate in startup ambiguity?"
• "Claims 'led team' at a 7-month role — what does 'led' mean here?"

Phase 3: Web Enrichment

Search for the candidate to fill in what the resume doesn't say. Do this thoroughly — this is where you find the context that separates a real personalized prep from a template fill-in. Treat the resume as a starting point, not the whole story. Research the candidate like you're planning to invest in them.

Minimum Searches (every candidate, no exceptions)

Start with at least 4-6 searches. This is a floor, not a ceiling. Combine the candidate's name with:

• Their current company — validate current role and watch for recent changes
• "LinkedIn" — expanded job descriptions, recommendations, activity feed
• "GitHub" or github.com {name} — repos, languages, stars, commit recency
• Their most distinctive technical claim — see if they've written or spoken about it
• "Medium" / "Substack" / their personal site — public writing reveals depth AND temperament
• For founder or publicly active candidates: the product/project name directly

Follow the Thread (mandatory)

Never stop at the minimum when a signal warrants more. If any of these appear, run follow-up searches until the thread is resolved:

• Recent tenure change — If their current or most recent role ended within the last 6 months (or appears to be ending "now" based on dates), search for why. Queries like "{name}" {company} leaving, "{name}" {company} departure {year}, or "{name}" fired surface voluntary exits, layoffs, firings, and public disputes. A candidate's last 90 days at a company is disproportionately predictive.
• Short tenure (<12 months) at a name-brand or senior role — dig for context. Could be contract, layoff, performance, culture mismatch, or founder-on-the-side.
• Named side project with claimed traction — search the project name directly. Look for real user counts, Hacker News threads, press coverage, GitHub stars. Founders routinely conflate marketing numbers with real metrics.
• Big quantified claims ($X in revenue, N users, X% improvement) — try to find independent corroboration, especially for claims attributed personally rather than to a team.
• Controversy or public writing signals — if a search surfaces a dispute, grievance post, or emotionally-charged piece, read the original source fully. This is the single highest-ROI signal for culture fit.
• Contradictions with the resume — GitHub shows zero activity in their claimed core stack, LinkedIn role title differs from resume, dates don't align. Flag and probe in the prep doc.

What to Extract

• LinkedIn details that differ from or expand on the resume (role scope, reporting lines, endorsements, recent activity)
• GitHub: language breakdown, repo quality, whether their stated "core stack" matches what they actually ship
• Public writing: Medium, Substack, personal blog, company engineering blog. Read enough to get tone and temperament, not just topic.
• Talks, podcast appearances, panels — these reveal how they talk about themselves unscripted
• Any public conflict, departure story, or strong opinion — especially about former employers, managers, or co-workers
• Community presence (Discord, Twitter/X, HN) where relevant to the role

Calibrate Depth to the Candidate

• Unknown candidate, standard profile: 4-6 searches, surface-level.
• Founder or publicly active candidate: 8-12 searches. Their public footprint is their resume — read it end-to-end.
• Senior/staff-level candidate: expand to their public talks, architectural writing, open-source leadership.
• Recent departure or short tenure: expand until you understand the transition. Don't stop before you do.

What NOT to Do

• Don't make hiring judgments from non-work social media (religion, politics unrelated to tech, personal life)
• Don't surface protected-class information (age, family status, health, national origin, etc.)
• Don't penalize lack of public presence — many excellent engineers aren't online
• Don't let research override what the interview reveals — research is context, not verdict
• If you find nothing useful after reasonable effort, say so in the prep doc and move on

Phase 4: Ask the Interviewer

Based on the resume analysis and template options, ask the interviewer targeted, dynamic questions. These should be specific to what you found — not generic.

Always Ask

Present these as a compact interactive question set:

1. Scenario/challenge selection — If the template offers choices (e.g., system design scenarios, coding challenges), recommend one based on the candidate's weaker areas and ask the interviewer to confirm or override.

2. Claims to probe — Present the top 3-5 claims you identified and ask: "These are the claims I'd push hardest on. Want to adjust the priority or add anything?"

3. Known context — "Do you know anything about this candidate beyond the resume? Any referral context, prior interactions, or specific concerns?"

Dynamically Generated Questions

Based on what the resume reveals, ask 1-3 additional questions. Examples of when to generate these:

• Ambiguous stack depth: "Jose lists both Java and Node.js. The template has both a Node.js and C# coding challenge. I'd go Node.js to validate his depth — agree?"
• Career pattern: "They've had 4 jobs in 5 years. Want me to build in questions about what they're looking for in their next role?"
• Domain mismatch: "No security background at all. How much weight should I put on security intuition vs. treating it as trainable?"
• Seniority calibration: "16 years of experience but applying for a mid/senior role. Should I calibrate questions for senior-level expectations?"

Keep the total question count to 3-5. Use the ask_user_input tool with multi_select and single_select where appropriate to make it fast for the interviewer to respond.

Phase 5: Generate the Interview Prep

Produce a single markdown file saved to /mnt/user-data/outputs/. Filename: {candidate_first_name}_{candidate_last_name}_interview_prep.md

Document Structure

The output should follow this structure, adapted to the specific template's sections:

# Interview Prep: [Candidate Full Name]

**Position:** [from template]
**Date:** [today]
**Interviewer:** [if known from memory/context]

---

## Candidate Profile
[Fill in the template's profile table with analyzed data]

---

## Key Concerns & Hypotheses Going In
[2-4 paragraphs: the honest assessment of what worries you,
what's unclear, and what the interview needs to answer.
Be direct and opinionated — this is for the interviewer's eyes only.]

---

## Part N: [For each section in the template]

### [Section name from template]

[Personalized version including:]
- Specific opening questions referencing THEIR resume
- Follow-up probes tailored to THEIR claims
- What to listen for given THEIR background
- Recommended scenario/challenge with rationale
- Candidate-specific angles to push
- Green flags and red flags specific to this person

---

## Hiring Decision Framework

### What Would Make [Name] a Hire
[Specific to their profile — what signals would close the gaps?]

### What Would Make [Name] a No-Hire
[Specific to their profile — what would confirm the concerns?]

### The Real Question for [Name]
[One paragraph: the single most important thing this interview
needs to answer about this candidate.]

---

## Logistics Reminders
[Checklist of practical setup needed for this specific interview]

Writing Style for the Prep Document

• Be opinionated. This is a private document for the interviewer. Don't hedge everything — state hypotheses clearly.
• Be specific. Every question should reference something from the candidate's actual resume, not generic interview questions.
• Quote the resume. When probing a claim, reference it specifically: "You mention '95%+ code coverage' — how did you measure that?"
• Explain your reasoning. When recommending a scenario or challenge, say why: "Use Scenario A because their background is entirely data/ETL with no event-driven experience."
• Think like a coach. Tell the interviewer what to watch for, what body language or hesitation might signal, what "good" and "bad" answers look like for this specific person.
• Address the meta-question. Every candidate has one big question the interview needs to answer. Name it explicitly at the end.

Adapting to the Template

The output structure should mirror the template's sections. If the template has 4 parts, the prep doc has 4 corresponding sections. If the template has a scoring rubric, reference those dimensions throughout. If the template offers choices (scenarios, challenges), make a recommendation and explain it.

Don't just fill in blanks — rewrite each section to be about THIS candidate. A personalized interview prep for a Java enterprise engineer should look completely different from one for a startup Python engineer, even if they're using the same template.

Edge Cases

• Multiple resumes uploaded: Ask which candidate they're prepping for, or if both are the same person (resume vs. LinkedIn PDF), merge the information.
• No template found or provided: Ask for the position title, then generate a reasonable interview structure from scratch based on common engineering interview patterns. Warn that results will be better with a template.
• Template for wrong position: If the resume suggests a frontend engineer but the template is for backend, flag it and ask.
• Very junior candidate against senior template: Note the calibration mismatch and suggest adjusting expectations in specific sections.
• Candidate seems overqualified: Flag it — the interviewer may want to probe motivation and retention risk.

---

Mode 2: Template Creation

Build a new interview template from a job description through a structured interview with the hiring manager. The goal is to produce a template as thorough and opinionated as the examples in ~/interviews/templates/ — not a generic question list.

Template Creation Workflow Overview

1. Ingest the job description
2. Research the role and domain
3. Interview the hiring manager (multiple rounds of questions)
4. Generate the interview template
5. Review, iterate, and tell them where to save it

TC Phase 1: Ingest the Job Description

Look for an uploaded JD (PDF, markdown, text, or even a URL). If the user just names a role without a JD ("we're hiring an SRE"), that's fine — you'll build from the conversation instead. But flag that a written JD would improve the template.

Extract from the JD:

• Position title and level
• Required vs. nice-to-have skills
• Team/product context
• Day-to-day responsibilities (what they'll actually do, not HR fluff)
• Anything that implies evaluation criteria ("must be comfortable with ambiguity" → test for that)

TC Phase 2: Research

Search the web for context that will make the template smarter:

• What does the company do? What's their tech stack? (if not already known)
• What are common interview patterns for this role type at similar companies?
• What are the hardest-to-evaluate skills for this position?
• Domain-specific knowledge: if hiring for AppSec, search for common AppSec interview approaches; if SRE, look for SRE interview best practices

This research informs the questions you'll ask the hiring manager — come prepared, don't make them do all the thinking.

TC Phase 3: Interview the Hiring Manager

This is the core of template creation. Ask questions in 2-3 rounds, not all at once. Each round should build on previous answers. Use ask_user_input for bounded choices and prose questions for open-ended ones.

Round 1: Role & Team Context

Understand what this person will actually do day-to-day, and what success looks like. Ask:

• Interview format: "How long is the interview? Single session or multi-round? Who else interviews them?" (single_select: "Single 90-min session" / "Multi-round with different interviewers" / "Pair with existing team member" / "Other")
• What does week 1 look like? "What would this person work on in their first week? First month?" (open-ended — this reveals what skills actually matter vs. what the JD says)
• Team composition: "Who's on the team today? What seniority levels? What gaps does this hire fill?" (open-ended)
• Failure modes: "Think about hires that didn't work out for this type of role. What went wrong?" (open-ended — this is gold for designing evaluation criteria)

Round 2: Evaluation Dimensions

Based on the JD and Round 1 answers, propose a set of evaluation dimensions and ask the hiring manager to validate. Present them ranked by your assessment of importance.

Example:

"Based on the JD and what you've told me, here are the dimensions I'd evaluate. Rank these by importance for this specific hire, and tell me if I'm missing anything:"

Typical dimensions (adapt to role):

• Problem decomposition
• System thinking / architecture
• Code quality and craft
• Domain knowledge (security, data, infra, etc.)
• Communication and collaboration
• Learning velocity / adaptability
• AI/LLM fluency (if relevant)
• Debugging and incident response
• Ownership mindset

For each dimension the hiring manager confirms, ask a follow-up:

• "What does 'strong' look like for [dimension] specifically on your team? Give me an example of what a great answer would be."
• "What's the minimum bar? What answer would make you say 'not enough'?"

Round 3: Practical Design Choices

Now get into the specifics of what the interview will contain:

System design scenarios:

"I want to create 2 system design scenarios for the template — one that tests [their likely strong area] and one that tests [their likely weak area], so the interviewer can choose. Here's what I'm thinking based on your product..."

Present 2-3 scenario ideas pulled from the company's actual domain (based on research). Ask:

• "Which of these resonate? Should I adjust the scale, constraints, or domain?"
• "What follow-up twists should we add?" (e.g., "now add LLM costs", "now it needs to handle 10x traffic")

Coding challenge:

"For the coding challenge, what matters more?"

(single_select: "Debugging existing code — can they read and fix?" / "Building from scratch — can they design and implement?" / "Extending a system — can they work in an existing codebase?" / "We have our own challenge already")

If they have their own challenge, ask for it. If not, ask:

• What language(s) should it support?
• Should it be timed or open-ended?
• Should it test specific patterns (async, error handling, data modeling)?

AI/LLM section:

"How important is AI/LLM experience for this role?"

(single_select: "Critical — they'll build AI systems" / "Important — they'll work alongside AI systems" / "Nice-to-have — we use AI tools but it's not the core job" / "Not relevant")

If important, ask what specific AI skills matter: prompt engineering, output parsing, cost optimization, evaluation/metrics, fine-tuning, RAG, agents?

Background deep-dive focus:

"When you look at resumes for this role, what claims make you skeptical? What do you always want to probe?"

(open-ended — this shapes the "Follow-up Probes" section of the template)

Optional Round 4: Calibration

If the hiring manager seems engaged and the role is nuanced, ask:

• "Describe your ideal candidate for this role — someone you've worked with or a hypothetical. What made/would make them exceptional?"
• "What's the biggest tradeoff you'd accept? e.g., 'I'd take someone weaker on [X] if they're exceptional at [Y]'"
• "Is there anything about your team culture that the interview should screen for? e.g., comfort with ambiguity, async communication, strong opinions loosely held?"

TC Phase 4: Generate the Template

Produce a markdown file that follows the structural pattern of existing templates. Check ~/interviews/templates/ for examples to match. If the user has existing templates there, read one first to match the format, tone, and level of detail. If no existing templates are available (first template being created), follow the template structure defined below.

Template Structure

# [Company] [Position] Interview Guide

**Position:** [title and level]
**Format:** [duration, single/multi-round]
**Last Updated:** [today's date]

---

## Candidate Profile

<!-- Fill in before each interview -->

| Field | Details |
|-------|---------|
| **Name** | ___________________ |
| **Education** | ___________________ |
| **Years of Experience** | ___________________ |
| **Background** | ___________________ |
| **Core Stack** | ___________________ |
| **Gaps for [Company]** | ___________________ |
| **Resume Claims to Probe** | ___________________ |

---

## Interview Philosophy

[What this interview tests and why. Written in the voice of the team,
not generic HR language. Should reflect the hiring manager's actual
values from the interview.]

[List the evaluation dimensions with one-line descriptions]

---

## Part 1: Background Deep-Dive ([time] min)

**Goal:** [specific to this role]

### Opening
> "[A specific opening question tailored to this role]"

### Follow-up Probes
[Role-specific probes — not generic. Each one should test something
the hiring manager said matters.]

### What to Listen For
[Specific signals, not generic]

---

## Part 2: [Technical Section — System Design / Architecture / etc.] ([time] min)

**Goal:** [specific to this role]

### Scenario A: [Name] ([what it tests])
> "[The prompt, with realistic scale numbers and constraints]"

**Guide the conversation through:**
[Specific discussion points with explanations of why each matters]

### Scenario B: [Name] ([what it tests])
> "[Alternative scenario that tests different skills]"

### [Company]-Specific Follow-ups
[Twists that relate to the actual product/domain]

### Green Flags / Red Flags
[Specific to this role and level]

---

## Part 3: [Practical Challenge] ([time] min)

**Goal:** [what the challenge reveals]

[Challenge description, setup instructions, evaluation criteria]

### Extensions
[Stretch problems for strong candidates]

---

## Part 4: [Additional Section if needed — AI/LLM, Domain Knowledge, etc.] ([time] min)

[Only include if the role warrants it]

---

## Scoring Rubric

| Dimension | Strong (4-5) | Adequate (2-3) | Weak (0-1) |
|-----------|-------------|----------------|------------|
[One row per evaluation dimension, with SPECIFIC descriptions
of what good/adequate/weak looks like for THIS role]

### Hiring Bar
[Clear, numeric thresholds]

---

## Post-Interview Notes

[Fillable template for the interviewer — same structure as existing templates]

---

## Pre-Interview Personalization Checklist

[Checklist the interviewer follows before each interview to customize
the template for a specific candidate. This is what Prep Mode automates.]

### Candidate-Specific Notes
<!-- Add per-candidate notes here before the interview -->

Template Quality Bar

The generated template should be:

• Opinionated — reflects what the hiring manager actually cares about, not a generic competency matrix
• Actionable — every section has specific questions to ask, not just "evaluate system design skills"
• Choosable — offers alternatives (Scenario A vs B) so the interviewer can push candidates into their weak spots
• Calibrated — the scoring rubric uses concrete behavioral descriptions, not vague adjectives
• Self-contained — a new interviewer could pick it up and run a good interview without additional briefing
• Domain-specific — system design scenarios, coding challenges, and probes should relate to what the company actually builds

Before generating, if existing templates are available in ~/interviews/templates/, re-read one to match the depth and tone. The new template should feel like it belongs in the same collection. If this is the user's first template, follow the structure defined above carefully — it sets the standard for future templates.

TC Phase 5: Review, Iterate, and Save

Present the generated template to the user. Ask:

"Here's the template. A few things to review:

1. Do the system design scenarios feel realistic for your product?
2. Does the scoring rubric capture your actual hiring bar?
3. Anything missing that you always wish you'd asked about after interviews?"

Iterate based on feedback. When the user is satisfied, save the final template to /mnt/user-data/outputs/ for immediate download, and tell them where to put it permanently:

"Your template is ready. To make it available for future interview prep, save it to your templates directory:

~/interviews/templates/[position]_interview_[year].md

For example: ~/interviews/templates/sre_interview_2026.md

If the directory doesn't exist yet, create it:

mkdir -p ~/interviews/templates

Next time you upload a resume and ask to prep for this role, the skill will find the template automatically."

If Filesystem MCP tools are available, offer to save it directly:

"I can save this directly to ~/interviews/templates/ on your machine. Want me to do that?"

If the user confirms, use Filesystem tools to write the file (creating the directory if needed).

Save the template to /mnt/user-data/outputs/ with the naming convention: {position_snake_case}_interview_{year}.md

Template Creation Edge Cases

• No JD provided, just a role name: That's fine — the interview with the hiring manager fills the gaps. But push for specifics: "Without a JD, I'll need you to be more detailed about what this person does day-to-day."
• JD is generic HR boilerplate: Call it out. "This JD is pretty generic — 'team player, fast learner, etc.' Let me ask you what actually matters for this hire." Then lean harder on the interview rounds.
• User wants to clone/adapt an existing template: Read the existing template, identify what carries over vs. what needs to change for the new role, and ask targeted questions about the differences only.
• User uploads a JD URL instead of a file: Fetch the URL content and extract the JD.
• Multiple positions at once: Push back gently. "Each template needs its own interview — let's do one at a time. Which role is most urgent?"