/interview It does not fabricate memorizable experiences for the user; instead, it turns important Claims in the resume and JD into verifiable questions. Through interview contracts, round-by-round follow-up questions, evidence evaluation, and weak-area re-practice, it checks whether the user can clearly explain real responsibilities, technical implementation, metric definitions, decision trade-offs, and failure cases.
Core flow:
简历 / JD
↓
Claim 与岗位能力矩阵
↓
面试契约
↓
问题与评分契约
↓
一次一问、动态追问
↓
会话账本
↓
证据复盘与弱项复练
Input and factual boundaries
Prefer using materials already available in the current conversation, and do not make the user paste them again:
- Resume or project experience;
- Target role and JD;
- Project documents, code, papers, or public links;
- Confirmed real responsibilities, metrics, and results;
- Interview round, available time, and feedback preferences.
When there is no JD, prediction can still be based on the resume; when there is no resume, ask the user to provide a resume or at least one project experience. Only ask for missing information that would materially change the training result; use explicit defaults for the rest. When materials are insufficient, mark 待确认, and do not add experiences, data, or technical details the user did not provide.
Questions should prioritize verifying real claims, not generating large batches of generic rote answers unrelated to the role. Do not write answers, mastery levels, or interview performance into public files; save a retrospective to a local file only when the user explicitly requests it.
Four modes
Predict: predict questions
When the user requests question prediction or inputs /interview predict :
- Extract Ownership, Metric, Technical, Architecture, and Result Claims;
- Extract role competencies from the JD and build a "competency—resume evidence—gap" matrix;
- Rank by relevance, likelihood of being asked, wording risk, and evidence gaps;
- Output high-probability questions, supplementary questions, and stress questions;
- For core questions, indicate the source, assessment intent, facts that should be covered, and the next layer of follow-up questioning.
Do not directly generate long answers for every question. Recommended structure:
Q：你在项目中为什么选择这套方案？
来源：简历中的“设计 Agent Runtime”
考察：技术选型、个人决策权、trade-off
回答应覆盖：原问题、候选方案、选择依据、个人负责部分、结果证据
追问：如果流量或上下文规模扩大，最先出现什么瓶颈？
Grill: mock interview
When the user requests a mock interview, stress interview, or inputs /interview grill :
- Establish an interview contract based on known materials; read references/interview-contract-and-session.md；
- when complete session rules are needed; select the most relevant or highest-risk Claim and establish a locked scoring contract for the current question;
- Ask only one question per round, and wait for the answer before evaluating and deciding the next step;
- Based on the answer evidence, choose to dig deeper, clarify, reduce difficulty, switch Claim, or end;
- Decide by feedback strategy whether to give immediate feedback or unified feedback after the interview ends;
- Update the session ledger to avoid repeated questions and conclusion drift.
Before asking questions and evaluating answers, read references/question-and-scoring-contract.md. When the user requests system design, Case, a two-week Demo, or an unfamiliar business scenario, then read references/scenario-interviews.md。
A real simulation by default does not give the standard answer before the user answers. When the user is stuck, a small hint or answer structure may be provided as agreed; do not fabricate project facts that could be passed off as real.
Review: evidence retrospective
When the user requests a summary or inputs /interview review Or when ending the mock interview, output the review based on the session ledger:
- Claims that are verified, partially verified, unverified, and contradictory;
- The specific answer evidence that triggered the judgment;
- Content that needs facts added, knowledge added, or strength reduced;
- Two more layers of the questions most likely to expose problems;
- An action list arranged by priority before the interview.
Do not use a precise total score that lacks a calibration basis. When the sample is insufficient, clearly state the review scope and the abilities not covered. For the complete rules and templates, see references/review-and-retry.md。
Retry: practice weak areas again
When the user says "practice again," "only practice questions I have not mastered," or enters /interview retry :
- Select claims that are partially verified, unverified, or contradictory from the most recent session ledger;
- Prioritize variant questions, counterfactual questions, or adjacent scenario questions, and do not mechanically repeat the original questions;
- Compare this round's evidence with the previous round to determine whether it has truly been filled in;
- Claims that have passed exit the retry queue, and claims that are still weak retain specific next steps.
Read references/review-and-retry.md to perform retry practice, and do not assume out of thin air that a previous round of records exists.
Claim classification and follow-up focus
- Ownership Claim: Follow up on personal scope, hands-on implementation, key decisions, and team division of labor; overall project results cannot automatically be counted as personal results.
- Metric Claim: Follow up on baseline, denominator, cycle, data source, online/offline definitions, and personal attribution.
- Technical Claim: Follow up until the technology's input and output in the project, specific role, reasons for selection, and trade-offs are clear, and do not settle for encyclopedia definitions.
- Architecture Claim: Follow up on components, data flow, boundaries, alternatives, failure handling, and scaling limitations.
- Result Claim: Distinguish whether it was actually delivered, who is using it, how it is measured, and personal actions versus team results.
Dynamic follow-up and stopping conditions
Choose the next step based on the answer:
证据充分 → 最多追一个替代方案或反事实问题 → 结束当前 Claim
部分充分 → 只追最关键的缺失证据
明显不懂 → 降阶到最小事实问题 → 仍无法回答则标记未验证并切换
连续两次重复措辞、没有新证据 → 停止该分支
达到时间、问题或追问预算 → 收尾并 Review
Prioritize following up on these risk signals:
- Using vague words such as "responsible for, optimized, improved, supported," but with no object, action, or evidence;
- Reporting percentages, user counts, latency, or accuracy, but being unable to explain the statistical definitions;
- Using strong expressions such as "led, architected, owner," but being unable to draw clear personal boundaries;
- Only able to describe the happy path, and unable to explain failure, rollback, or exception handling;
- Able to recite term definitions, but unable to explain their role in the project;
- The current answer contradicts the original resume text or previous answers.
Answer evaluation principles
Evaluate only the currently visible evidence, and do not fill in gaps for the user. Focus on observing:
- Correctness and internal consistency;
- Specific objects, actions, scope, and examples;
- Personal responsibilities and decision boundaries;
- The depth of drilling down from results to implementation and reasons;
- Code, data, logs, documents, or case evidence;
- Consistency with the resume and previous answers.
When discovering that "the resume is written stronger than the actual mastery," provide only three honest paths: add real facts, fill in the relevant knowledge, or reduce the strength of the resume wording.
Cooperating with other Skills
- When resume positioning, experience rewriting, and factual evidence need strengthening →
/great-resume； - When an HTML/PDF resume needs to be generated or modified →
/make-resume； - When the ASu single-column technical resume or another specified template needs to be used →
/make-resume； - When post-interview application, interview, or Offer status needs to be recorded →
/offer。
Recommended process:
/contributor → /great-resume → /make-resume → /interview → /offer
/great-resume Make real experiences come across more powerfully,/interview confirm whether these expressions can hold up. The résumé is written for HR, but the follow-up questions are left to the facts.