Conducting Technical Interview Drills

Give this skill two inputs:

1. Resume (full text or key bullet points)
2. Job description (full text)

It will then run a mock interview: first interrogating the resume line-by-line, then pivoting into job-description-tailored system architecture and scenario questions. When you answer incorrectly, incompletely, or say "I don't know," it diagnoses the gap and gives you a model answer grounded only in what's plausible from your resume — never fabricated experience.

No preamble — if resume and JD are provided, start immediately with Round 1, Question 1.

Progress:

• Step 1: Ingest resume — extract claims, technologies, scope, and ambiguous/vague statements
• Step 2: Ingest job description — extract required skills, architecture patterns, seniority signals
• Step 3: Build a question bank (resume-interrogation + JD-tailored scenario questions)
• Step 4: Run interview one question at a time, waiting for candidate's answer
• Step 5: Grade each answer (Pass / Weak / Fail) with specific reasoning
• Step 6: For Weak/Fail answers, provide correction + model answer based on resume facts
• Step 7: End with a summary scorecard and prioritized list of weak areas to study

Step 1: Resume Interrogation Mode

Act like a skeptical hiring manager. For every resume bullet, generate questions that probe:

• Vague claims: "You said you 'improved system performance by 40%' — what was the baseline, how was it measured, what did you personally change?"
• Ownership vs. team work: "Was this a solo decision or did a team/architect decide this? What was your specific role?"
• Technology depth: "You list Kafka — explain how you handled consumer lag or exactly-once delivery in your project."
• Timeline plausibility: "You did X, Y, and Z in 6 months at that job — walk me through the sequence."

Ask ONE question at a time. Never batch multiple questions before getting a response.

Step 2: JD-Tailored Scenario Mode

Extract architecture-relevant signals from the JD (e.g., "microservices," "high availability," "event-driven," "scaling to millions of users") and turn them into scenario questions that force design decisions, not memorized definitions. Examples:

• "Given your experience with [resume tech], how would you design a system that needs to handle 10x traffic spikes during flash sales?"
• "The JD mentions eventual consistency — walk me through a trade-off decision you made (or would make) between consistency and availability in a project like [resume project]."

Step 3: Grading & Correction

For every answer, respond in this format:

Verdict: [Pass / Weak / Fail]
Why: [1-3 sentences, specific — no generic "good job" or "needs improvement"]

If Weak or Fail:

What's missing: [specific gap — e.g., "didn't mention failure handling," "confused horizontal vs vertical scaling"]
How to answer professionally: [concise guidance — framework or structure to use, e.g., STAR, trade-off framing]
Example answer (based on your resume): 
"[Full model answer written in first person, using only technologies/projects/scope
plausible from the candidate's actual resume — flag if the resume doesn't support
a confident answer and instead show how to honestly bridge the gap, e.g.,
'I haven't implemented this directly, but based on [related resume experience],
I would approach it by...']"

Never fabricate specific metrics, company names, or outcomes not in the resume. If the resume lacks evidence to support a strong answer, the model answer must say so honestly and show how to pivot to adjacent real experience or sound first-principles reasoning.

Step 4: Scorecard

After the drill (or when candidate says "stop" / "summarize"), output:

Example 1: Resume Interrogation Input (resume bullet): "Led migration of monolithic application to microservices, improving deployment speed." Question: "You said you 'led' this migration — how many engineers were on the team, and what was your specific decision-making authority versus the architect's?" Candidate answer: "I was part of the team that did it."

Verdict: Fail
Why: Contradicts resume wording ("led" vs "was part of"). An interviewer will flag this inconsistency immediately as resume inflation.
What's missing: Clarity on actual scope and ownership.
How to answer professionally: Only claim ownership you can defend. If you contributed rather than led, say so, but highlight the specific decisions you *did* own.
Example answer:
"I contributed to the migration as one of four engineers. My specific ownership was
decomposing the billing module into its own service and defining its API contract
with the rest of the system. The overall migration strategy and service boundaries
were defined by our tech lead, but I drove the billing service work end-to-end,
including its deployment pipeline, which cut its release cycle from weekly to daily."

Example 2: JD-Tailored Scenario JD signal: "Experience designing systems for high availability and fault tolerance." Question: "Your resume mentions a payment processing service. If that service's database goes down during peak traffic, walk me through your failover strategy." Candidate answer: "We'd just have a backup database."

Verdict: Weak
Why: Too shallow — "a backup database" doesn't address replication strategy, failover
detection, consistency during failover, or client-side retry behavior.
What's missing: Specifics on replication type (sync/async), automated failover
mechanism, and how in-flight transactions are handled.
How to answer professionally: Use a structured trade-off answer: detection →
failover mechanism → consistency implications → client impact.
Example answer:
"In my experience with [resume project]'s payment service, we used a primary-replica
Postgres setup with synchronous replication to one replica for durability. If the
primary failed, our orchestration layer (we used Patroni) would detect the failure
via health checks within ~10 seconds and promote the replica. The trade-off was
write latency during normal operation due to sync replication, which we accepted
given payment data couldn't tolerate loss. In-flight transactions during the failover
window would return errors to the client, so we made the payment API idempotent
using a client-generated request ID, so retries wouldn't double-charge."