silvanicus/skills/interview-guide-generator

Overview

Generates a structured interview guide for technical engineering roles — software engineers, UI/frontend engineers, QA engineers, and similar. Questions are anchored to the competency framework for the specified level and weighted by engagement mode.

Engagement modes:

• Freelance — under 6 months, project-based. Weights immediate technical depth in the exact stack, scope discipline, and low-overhead async communication.
• Long-term contractor — 6+ months, embedded in a team. Weights cultural fit, mentoring, and team contribution alongside technical depth.

---

When to Use This Skill

• Opening a new technical position (FTE, freelance, or long-term contractor) and preparing the interview loop.
• Hiring a freelancer for a short, scoped engagement and needing to confirm they can deliver without ramp-up.
• Hiring a long-term contractor who will embed in a team and needs evaluation closer to a full-time hire.
• Hiring for a project with specific technical, domain, or client requirements.
• Calibrating a hiring panel that includes people who don't interview frequently.
• Creating a repeatable guide for a role you hire for often (e.g., Senior UI Engineer).
• Refreshing an outdated interview process for an existing technical role.

When NOT to Use This Skill

• For non-technical roles (sales, marketing, design management, operations, etc.) — the framework, dimensions, and competency anchors assume engineering disciplines.
• For internal transfers or promotions (use a growth roadmap or a calibration conversation).

---

Workflow

Follow these steps in order every time this skill is invoked.

Step 1 — Extract Role and Level

Identify the technical role and level from the user's prompt. Normalize to a standard label:

• Examples: Senior Frontend Engineer, Mid Backend Engineer, Junior QA Engineer, Senior UI Engineer, Staff Software Engineer, Mid Mobile Engineer.
• If the role is not technical (e.g., sales, marketing, design management): Stop and explain that this skill is scoped to technical/engineering roles only.
• If no role is provided: Do not assume. Ask the user to specify the technical role before continuing.
• If no level is provided: Do not assume. Ask the user to specify the level (e.g., Junior, Mid, Senior, Staff/Lead) before continuing.
• If the level is ambiguous (e.g., user says "developer"): Ask for clarification before continuing.

Role and level are required inputs. Never proceed to Step 2 without both confirmed.

Step 2 — Confirm Engagement Mode

Identify the engagement type. Determine it as follows:

• If the user has stated it explicitly (e.g., "freelancer", "long-term contractor", "6-month embedded engagement"): Confirm and continue.
• If the engagement length is mentioned but mode is not (e.g., "3-month engagement"): Infer reasonably (under 6 months → freelance; 6+ months → long-term contractor) and confirm with the user in one short sentence.
• If neither is mentioned: Ask directly:

  "What type of engagement is this?

  • Freelance — short, project-based, hit-the-ground-running expected.
  • Long-term contractor — extended engagement, embedded in a team, evaluated closer to a full-time hire."

Engagement mode is a required input. Never proceed to Step 3 without it confirmed.

Step 3 — Load Role Context

3a — Load the Competency Framework (primary)

Look for a competency file for the confirmed role. Use the following lookup order:

1. shared/competencies/<role-slug>.md — default location, Markdown format.
2. Any file the user has already provided or referenced in their prompt (e.g., a path, a pasted document, or an attached file such as a PDF or CSV).
3. Any file in the current working context that matches the role name or slug, regardless of format or location.

Accepted formats: .md, .pdf, .csv, plain text paste.

• If found: Load it. This is the primary source — level-specific expectations, behavioral signals, delivery standards, ways of working. Proceed to Step 4.
• If not found: Do not ask the user. Proceed to Step 3b.

3b — Load the Role Reference (fallback only)

Only reach this step if no competency framework was found in 3a.

Look for a matching role file in references/ inside this skill:

• UI Engineer / Frontend Engineer → references/ui-engineer.md
• Software Engineer / Backend Engineer / Full-stack Engineer → references/software-engineer.md
• QA Engineer / SDET → references/qa-engineer.md

Match flexibly — title aliases ("Frontend Developer", "Web Developer", "Backend Developer", "QA Analyst", etc.) should map to the closest reference.

• If a matching reference is found: Load it as the technical baseline. Note in the guide's "Before You Start" section that no competency framework was loaded and the guide uses the built-in role reference.
• If no matching reference exists (e.g., Mobile Engineer, Data Engineer, DevOps): Proceed from the prompt only. Note this in the guide's "Before You Start" section.

Step 4 — Review Candidate Background (Optional)

Check whether the user has provided any candidate context. This step is optional — if nothing is provided, skip it and continue.

Accepted inputs:

• CV or résumé — any format (PDF, Word, plain text paste)
• LinkedIn profile URL — fetch and extract publicly available information
• A brief summary — written by the hiring manager or recruiter

If candidate context is available, extract and note:

• Relevant experience — years in similar roles, industries, company types (agency, startup, enterprise). Note if their background matches or diverges from the hiring context.
• Technical signals — technologies, tools, and domains they've worked in. Flag gaps relative to what the role requires.
• Career trajectory — progression pattern, lateral moves, tenure. Note anything that warrants probing (e.g., short stints, significant level jumps, career pivots).
• Potential strengths to validate — experience claims that are impressive but vague, and worth making concrete in the interview.
• Potential gaps to probe — areas the role requires that are absent or thin in their background.

Use this to personalize questions: reference specific experiences, probe gaps directly, and skip areas they've clearly done extensively.

Step 5 — Identify Gaps

Note what the prompt has not addressed: ramp-up window and timeline pressure; team composition and client-facing expectations; hard stops or must-avoids; competency dimensions the prompt does not speak to. These gaps drive the clarifying questions in Step 6.

Step 6 — Ask Clarifying Questions

Ask 2–3 targeted questions to fill the most important gaps from Step 5. Prioritize questions that would meaningfully change the questions generated.

Always include this option at the end:

"Or, if you prefer, just say 'generate' and I'll build the guide with what I have."

Universal

• Who else will be in the interview loop, and what will they cover? (Avoids duplication.)
• Will this person be client-facing, and if so, how much? (Shapes consulting/influence questions.)
• Are there any non-negotiables — skills or behaviors that would immediately disqualify a candidate?

Freelance-specific

• How much ramp-up time is realistic on day one — are they expected to ship in week one, or is there a structured onboarding?
• Will they be working solo on a deliverable, or alongside other engineers? (Shapes the autonomy vs. collaboration weighting.)
• What does "done" look like for the engagement — a defined scope, an open-ended brief, or something in between?

Long-term contractor-specific

• Is this a net-new role or a backfill? (Backfills may signal a specific gap to probe.)
• Is there potential to convert to full-time, and should the interview be calibrated for that possibility?
• Will they be expected to mentor, contribute to standards, or shape team practices — or strictly to deliver?

Wait for the user's answers before proceeding. If the user says "generate" at any point, skip directly to Step 7.

Step 7 — Generate the Interview Guide

Using all collected information, produce the interview guide following the Framework and Output Format sections below.

Once the guide is complete, export it as a PDF file and share it with the user. Name the file using the pattern: interview-guide-[role-slug]-[YYYY-MM-DD].pdf (e.g., interview-guide-senior-ui-engineer-2025-03-15.pdf).

---

Interview Question Framework

Questions must collect signal across four dimensions. Every generated guide should balance coverage across all four, weighted by what matters most for the specific role, level, and engagement mode.

Mode Calibration

Use this to decide how much weight each dimension carries and which signals to prioritize within it.

Freelance mode

• Heavier weight: Technical Knowledge (depth in the exact stack required), Delivery & Process (scope discipline, autonomy, predictable delivery, async communication).
• Lighter weight: Collaboration & Communication (team dynamics, mentoring), Growth & Ownership (long-term curiosity, learning trajectory).
• Reframe: Within Collaboration, focus on low-overhead, async-friendly working style and minimal context-switching cost. Within Growth & Ownership, focus on accountability for the engagement deliverable rather than long-term growth signals.
• Hard stops to probe: Inability to demonstrate concrete prior delivery in the exact stack; vagueness about scope and timelines; reliance on heavy ramp-up or constant context.

Long-term contractor mode

• Balanced weight across all four dimensions — closer to a full-time hire bar.
• Reframe: Cultural fit, mentoring junior engineers, and contributing to team practices matter alongside technical depth. Growth & Ownership questions can lean into learning trajectory and how the candidate has improved teams they've been part of.
• Hard stops to probe: Misalignment with team's ways of working; lack of evidence of constructive collaboration in extended engagements; signs of "lone wolf" delivery that won't translate to embedded work.

Reflect the chosen mode in the suggested time per section, the number of questions per dimension (within the ranges below), and the framing of "what to listen for" in each question.

Dimension 1 — Technical Knowledge

Questions that assess depth and quality of technical knowledge. Anchored to the "Technical Skills" section of the competency table. Include any project-specific technologies from the prompt.

Signal to collect:

• Depth of expertise in core technical areas for this role.
• Approach to code quality, testing, and performance.
• Ability to make and articulate architecture decisions.
• Awareness of trade-offs, not just solutions.
• Fluency with AI-assisted development — how they use tools like GitHub Copilot, Cursor, or Claude in their workflow, and critically, how they validate, review, and take ownership of AI-generated output. At senior levels, look for judgment about when AI assistance helps vs. when it introduces risk.

Mode note — In freelance mode, prioritize concrete, recent depth in the exact stack required (no learning on the job) and one applied scenario question that mimics the engagement context. In long-term contractor mode, you can also probe broader architectural judgment and how they'd evolve patterns over time.

Dimension 2 — Delivery & Process

Questions that assess how the candidate manages work, ambiguity, and complexity. Anchored to the "Delivery" competency.

Signal to collect:

• How they scope, estimate, and manage risk.
• How they handle competing priorities or unclear requirements.
• Their relationship with process (Agile, CI/CD, documentation).
• How they communicate progress and problems to the team and stakeholders.

Mode note — In freelance mode, weight this dimension heavily: probe scope discipline, time-boxing, async status updates, and how they avoid scope creep on short engagements. In long-term contractor mode, also probe how they adapt to and improve a team's existing process over time.

Dimension 3 — Collaboration & Communication

Questions that assess how the candidate works with others — teammates, cross-functional partners, and clients. Anchored to "Builds Together" and "Influence" competencies.

Mode note — In freelance mode, focus on low-overhead async collaboration, working with minimal context, and clear handoffs; you can drop the mentoring/team-building probes entirely. In long-term contractor mode, treat this dimension closer to a full-time hire: cultural fit, mentoring, and contribution to team practices all matter.

Calibrate questions to the role's track and level:

Individual contributors Signal to collect:

• How they navigate disagreement or misalignment within a team.
• Whether they elevate others or work in isolation.
• How they communicate technical concepts to non-technical audiences.
• Their approach to feedback — giving and receiving.

Leads and Staff engineers Signal to collect:

• How they drive alignment across teams or workstreams without formal authority.
• How they sponsor or unblock others' work, not just their own.
• Their approach to technical decision-making in group settings (e.g., RFCs, design reviews).
• How they handle conflict between technical quality and business pressure.

Directors and people managers Signal to collect:

• How they build, develop, and retain a team — not just manage output.
• How they give difficult feedback and handle underperformance.
• How they represent their team's needs upward and advocate for resources.
• Their approach to hiring and what they look for in candidates.
• How they balance hands-on involvement with delegation.

Dimension 4 — Growth Mindset & Ownership

Questions that assess accountability, curiosity, and initiative. This dimension is a strong predictor of long-term fit and cultural alignment — weight it accordingly, especially when the environment is fast-moving or ambiguous.

Mode note — In freelance mode, focus narrowly on accountability for the engagement deliverable: how they own outcomes within a short window, how they surface problems early. The long-term curiosity and learning trajectory probes carry less weight here. In long-term contractor mode, all sub-areas matter — accountability, curiosity, and initiative.

Signal to collect:

Accountability

• Can they describe a specific failure — what happened, what they did, and what changed as a result? Watch for deflection, blame-shifting, or overly polished answers with no real consequence.
• Do they distinguish between effort and outcome? Ownership means caring about the result, not just the work.

Curiosity and learning

• How do they actively keep up with a fast-moving field — not just "I read blogs" but specific examples of how learning has changed how they work.
• Have they taught themselves something outside their job description? Proactively adopted a new tool, method, or practice without being asked?
• How are they adapting to AI-augmented development — are they experimenting, ignoring it, or thoughtfully integrating it?

Initiative and proactiveness

• Can they give an example of improving something that wasn't their responsibility? Raising a problem, proposing a solution, or pushing back on a direction they thought was wrong.
• Do they wait to be told, or do they move when they see something that needs doing?

Keep this to 2 questions — they should feel like natural conversation, not interrogation. The best answers here are specific and unprompted. If a candidate volunteers accountability or learning moments in other sections, note it — it counts.

---

Output Format

The generated guide must follow this exact structure:

---

Interview Guide: [Role Title] — [Level]

Engagement type: [Freelance — short-term, project-based] or [Long-term contractor — extended, embedded] Generated for: [Project or context name, if provided] Suggested duration: [e.g., 60 minutes]

---

Candidate & Role Snapshot

Role summary: 1–3 sentences on what this role requires, what success looks like in the first 90 days (or within the engagement window for freelance roles), and what the non-negotiables are. Explicitly state the engagement type so interviewers calibrate their bar accordingly. Written so any interviewer can align quickly before the call, even without reading the full job description.

Candidate overview (include only if a CV, LinkedIn profile, or summary was provided): 2–4 bullet points summarizing the candidate's background as it relates to this role. Cover:

• Current or most recent role and how it maps to what's being hired for.
• Relevant experience highlights — specific domains, technologies, or contexts that are directly applicable.
• Anything in their trajectory worth noting before the interview — a career pivot, a level jump, extended tenure in a very different environment, etc.
• Initial read on fit: where they look strong on paper, and where the interview should probe harder.

---

Before You Start — Interviewer Notes

Generate only what is relevant — skip any point that doesn't add information beyond the obvious.

• Scope of this session: What this guide covers within the broader loop. What other interviewers are handling (if known) so there's no duplication.
• Priority areas: The 1–2 dimensions that matter most for this specific role and context. Where to spend time if the interview runs short.
• Candidate-specific watch points (only if background was provided): What to probe based on the candidate's CV or profile — gaps to dig into, claims to make concrete, or transitions worth understanding.
• Hard stops: Any non-negotiable signals — skills or behaviors — that would end consideration regardless of performance elsewhere.

---

Section 1 — Technical Knowledge

Suggested time: [X minutes] Competencies covered: [List from framework]

For each question include:

Q: [Question text]

What to listen for: [2–3 specific signals that indicate strong, average, or weak answers] Follow-up: [One follow-up to probe depth or test for specificity]

Include 4-7 questions in this section. Mix conceptual and applied. If project-specific technologies were provided, at least one question must address them directly.

---

Section 2 — Delivery & Process

Suggested time: [X minutes] Competencies covered: [List from framework]

Same question format as Section 1. Include 2–3 questions.

---

Section 3 — Collaboration & Communication

Suggested time: [X minutes] Competencies covered: [List from framework]

Same question format as Section 1. Include 2–3 questions. At least one must probe client-facing or cross-functional behavior if the role has any client exposure.

---

Section 4 — Growth Mindset & Ownership

Suggested time: [X minutes] Competencies covered: [List from framework]

Same question format as Section 1. Include 2 questions.

---

Red Flags to Watch For

Role-level flags — 3–5 signals grounded in the competency framework for this role and level, and tuned to the engagement mode (e.g., for freelance: "vague about prior delivery in this exact stack" or "needs ramp-up to be productive"; for long-term contractor: "prefers to work in isolation" or "no examples of contributing to team practices"). Each flag must be specific to what's actually being hired for, not generic. Format:

• [Signal]: What it looks like in the interview and why it matters for this role and engagement type.

Candidate-specific flags (include only if background was provided) — 1–3 flags derived directly from the candidate's CV or profile. Only include if there's a real concern — don't manufacture flags.

For each candidate-specific flag, include one optional follow-up question the interviewer can use to probe it directly:

• [Flag based on their background]: Brief explanation of the concern.
  • Optional probe: "[A direct question targeting that specific flag]"

These are signals to surface in debrief — not automatic disqualifiers. The interviewer's job is to collect evidence, not reach a verdict mid-call.

---

Scorecard

Designed for engineers with no hiring process background. Should take 2–3 minutes to fill out immediately after the interview, while it's fresh.

Scale — one score per dimension:

| Score | What it means | |-------|---------------| | 3 — Strong | Clear evidence. Answered with specifics, not generalities. | | 2 — OK | Some evidence, but incomplete or needed a lot of prompting. | | 1 — Weak | Little to no evidence. Vague, deflected, or clearly unfamiliar. |

Fill in after the interview:

| Dimension | Score (1–2–3) | One thing that stood out (good or bad) | |-----------|---------------|----------------------------------------| | Technical Knowledge | | | | Delivery & Process | | | | Collaboration & Communication | | | | Growth & Ownership | | |

Overall call — pick one:

• Yes — Scored 2 or above in all dimensions, at least two 3s.
• Yes, but — One dimension at 1 with a specific, addressable reason. Note it.
• No — Any dimension at 1 with no clear explanation, or mostly 2s with no standout signal.

If you're unsure, write down the specific moment that's making you hesitate. That's what debrief is for.

---

Examples

See EXAMPLES.md in this skill directory for eval-ready example prompts with step-by-step expected behavior and output assertions.