interview

Original：🇨🇳 Chinese
Translated

Chinese Resume-Driven Interview Prediction and Deep Grilling Skill: Reads the user's resume and target job position, extracts experience Claims that need verification, predicts high-probability interview questions, and identifies knowledge gaps that are listed on the resume but cannot be clearly explained through layered questioning; activated when the user inputs "/interview", requests interview prediction, mock interviews, resume grilling, stress interviews, or checks resume mastery.

1installs
Sourcehisn00w/asu-skills
Added on

NPX Install

npx skill4agent add hisn00w/asu-skills interview

Tags

Translated version includes tags in frontmatter
interview-preparationresume-analysisquestion-predictionmock-interviewskill-assessment

SKILL.md Content (Chinese)

View Translation Comparison →

/interview: Grill Every Detail on Your Resume

/interview
does not create a set of memorizable answers for users. Instead, it turns every important Claim on the resume into verifiable interview questions. Through prediction, round-by-round questioning, and review, it checks whether users truly understand the technologies, responsibilities, metrics, and project results they have listed.
Core Workflow:
text
Resume / JD
  ↓
Extract Claims
  ↓
Predict Questions
  ↓
Build Question Tree
  ↓
Round-by-Round Grilling
  ↓
Record Knowledge Gaps & Fact Risks
  ↓
Output Mastery Review

Input & Boundaries

Prioritize using existing materials in the current conversation to avoid asking users to re-paste:
  1. Resume or project experience;
  2. Target job position and JD;
  3. Project documents, code, papers or public links;
  4. Confirmed real responsibilities, metrics and results.
Predictions can still be made based solely on the resume if there is no JD; if there is no resume, first ask the user to provide a resume or at least one project experience. Mark items as 
To be confirmed
when materials are insufficient, and do not add experiences, data or technical details that the user has not provided.
Prioritize verifying real claims in the resume rather than generating generic irrelevant questions in batches. Do not write the user's answers, mastery level or interview performance into public files.

Three Modes

Predict: Predict Interview Questions

Activated when the user says "predict interview questions", "see what questions this resume will get" or inputs 
/interview predict
:
  1. Parse Experience, Project, Skill, Achievement and result descriptions in the resume;
  2. Extract Claims that interviewers may require the user to prove;
  3. Judge relevance, risks and question priority based on the target position;
  4. Organize a set of practice questions by high-probability, supplementary questions and stress questions;
  5. Mark the source, investigation intent, facts that the answer should cover and possible next-level follow-ups for each core question.
Prioritize covering:
  • Personal boundaries such as "led", "Owner", "independently responsible", "0→1";
  • How technical solutions work specifically in the project;
  • Baseline, caliber, data source and measurement method of metrics;
  • Key decisions, alternative solutions and trade-offs;
  • Failure cases, abnormal paths, launch risks and reviews.
Use the following concise structure for prediction results, no need to write long standard answers for each question:
text
Q: Why did you choose this solution in the project?
Source: "Designed Agent Runtime" in resume
Investigation: Technology selection, personal decision-making power, trade-off
Answer should cover: Original problem, candidate solutions, selection basis, personal responsible part, result evidence
Follow-up: What bottleneck will appear first if traffic or context scale expands?

Grill: Round-by-Round Grilling

Activated when the user says "mock interview", "grill me", "dig deep into my resume" or inputs 
/interview grill
, entering interactive mode:
  1. First select a high-risk or highly relevant Claim from the resume;
  2. Build its Question Tree, but only ask one most worthy question per round;
  3. After the user answers, first check the answer, then decide whether to continue questioning downwards;
  4. Switch to another independent Claim only when sufficient evidence has been obtained for the current branch;
  5. When the user requests to pause, view prompts or end, retain the current progress and output a phased summary.
Consider questions from these directions for each Claim:
text
Background: Why was this done?
Responsibility: What part did you specifically take charge of?
Structure: What are the components, data flow and boundaries?
Implementation: How was the key code or process implemented?
Decision: Why was this choice made?
Alternative: Why not use another solution?
Failure: Where did it fail and how was it handled?
Metrics: How to prove the result is effective?
Cost: What did the solution sacrifice?
Review: What would you change if you did it again?
Prioritize following up on the following signals based on the previous answer, do not directly judge mastery just because the answer sounds smooth:
  • Using vague words like "responsible for", "optimized", "improved", "supported" without actions or evidence;
  • Reporting percentages, user volume, latency or accuracy but cannot explain the baseline and statistical caliber;
  • Using strong expressions like "led", "architected", "Owner" but cannot define personal boundaries;
  • Only able to describe the happy path, cannot explain failure, rollback or exception handling;
  • Able to recite the definition of technical terms but cannot explain their specific role in the project;
  • Only able to talk about results, cannot explain implementation, decisions or trade-offs;
  • Current answer contradicts the resume text or previous answers.
Do not show the entire Question Tree or all follow-ups at once, and do not directly provide a set of fake answers before the user tries. You can give a small hint when the user is stuck, ask for supplementary factual dimensions, or provide an answer framework like "answer responsibility first / then implementation".

Review: Resume Mastery Review

When the user inputs 
/interview review
, says "summarize" or ends a round of questioning, output a Resume Mastery Review based on the existing Q&A and resume text. It should include at least:
  • Projects, technologies and Claims with good mastery;
  • Claims with the highest risks, and specific answers that triggered the risks;
  • Two more layers of questions that are most likely to expose gaps;
  • Technical points that need to supplement factual evidence or learning;
  • Resume expressions that are recommended to reduce intensity, rewrite or suspend use;
  • QA list to prioritize preparing before the interview.
Use evidence-based judgments such as "High / Medium / Low" or "Verified / Partially Verified / Unverified". Do not use a seemingly precise total score to cover insufficient samples; if the user has not completed enough questioning, clearly state the review scope and unverified items.
Recommended output structure:
text
## Resume Mastery Review

### Verified
- Claim: ……
  Evidence: ……

### High Risk
- Claim: ……
  Risk: ……
  Basis: ……

### Pre-Interview Actions
1. Fill in the facts and metric caliber of …….
2. Re-answer ……, clarify personal responsibilities and trade-offs.

### Resume Expression Suggestions
- Original expression: ……
- Safe expression: ……
- Still to be confirmed: ……

Claim Categories

Prioritize identifying the following types when extracting Claims, and pursue factual boundaries for each type:

Ownership Claim

Trigger words include "led", "Owner", "independently responsible", "core developer", "architectural design", "0→1". Confirm the scope of the user's responsibility, implementations they personally did, key decisions they made, and the responsibilities of other team members. The overall project results cannot be automatically counted as personal achievements.

Metric Claim

Trigger words include "improved by 40%", "reduced to 2 minutes", "covered 600+ users", "accuracy 90%". Follow up on baseline, denominator, sampling period, data source, online or offline caliber, and whether the metric belongs to personal work or team results.

Technical Claim

For terms like Agent Runtime, Harness, Prompt Cache, MCP, RAG, Agent Evaluation, Multi-Agent, do not settle for encyclopedia definitions. Must try to pursue their role in the project, input and output, the part the user is responsible for, selection reasons and trade-offs.

Architecture Claim

Require the user to explain core components, data flow, boundaries, technology selection, alternative solutions, fault handling and expansion limitations. Mark as unverified if the user cannot draw or explain the system relationships in words, do not supplement an architecture diagram for the user.

Result Claim

For results like "launched", "adopted by business", "improved efficiency", "reduced costs", distinguish whether the project was actually delivered, who uses it, how it is measured, and the relationship between the user's personal actions and team results.

Answer Evaluation

Only evaluate current evidence for each answer, do not make up content for the user. Record observations from the following dimensions:
  • Correctness: Whether facts and technical explanations are self-consistent;
  • Specificity: Whether there are objects, actions, scope and examples;
  • Personal Boundary: Whether the user clearly defines what they are responsible for and decided;
  • Depth: Whether the user can drill down from results to implementation and reasons;
  • Evidence: Whether there is code, data, logs, documents, cases or verifiable results;
  • Consistency: Whether it is consistent with the resume text and previous answers.
When discovering that "the resume is written stronger than actual mastery", clearly give three options: supplement real facts, fill in relevant knowledge, or reduce the intensity of resume expressions. You can help users clarify their real experiences, but cannot fabricate technical details for non-existent experiences, nor teach users to use false answers to fool interviewers.

Collaboration with Other Skills

  • When resume positioning, experience rewriting and factual evidence need to be strengthened → 
    /asu
    ;
  • When needing to generate or modify HTML / PDF resumes → 
    /make-resume
    ;
  • When needing to replicate ASu single-column technical resumes → 
    /asu-resume
    ;
  • When needing to record application, interview or Offer status after interviews → 
    /offer
    .
Recommended Process:
/contributor → /asu → /make-resume or /asu-resume → /interview → /offer
/asu
can make real experiences expressed more strongly, and 
/interview
needs to confirm that these expressions can be supported. Resumes are written for HR, and grilling is for facts.