QA Interview Sheet

What this produces

A two- or three-page PDF the interviewer prints or opens on a second screen and writes on during the interview. Every design decision follows from that: questions anchored to this candidate's actual experience, answer signals that let an interviewer calibrate someone more senior than themselves, follow-up probes for when an answer is thin, and a notes column so the filled sheet becomes the artifact handed back to the recruiter.

The failure mode to avoid is a generic question list. A candidate can rehearse "what is the difference between smoke and regression testing" the night before, so it tells you nothing. Questions that reference their stack, their systems, and their claims cannot be rehearsed.

Step 1 — Collect inputs without blocking

Only two things are genuinely required: the position and either a CV or an explicit statement that there isn't one. Everything else has a sensible default, and stalling the user through several rounds of questions before any work happens costs more than a stated assumption does.

Input	If missing
Position title	Ask. It anchors everything.
CV	Ask once. If the user says there's no specific candidate, build a role-generic sheet (see below).
Seniority	Infer from the title, or from years of experience on the CV. Only ask when the title is genuinely ambiguous.
Job description / required stack	Infer from the position title and CV. Ask only if the role could plausibly mean very different things.
Interview duration	Default to 60 minutes.
Recruiter notes	Never ask. Use them if offered.
Focus areas to emphasize or skip	Never ask upfront. Offer to adjust after showing the sheet.

Ask for anything still missing in one message, then proceed. Record every assumption you made and surface it in the sheet header, so the interviewer can catch a wrong guess before the call rather than mid-question.

Reading the CV: if its text is already in your context, use that; re-reading from disk wastes a step. If you only have a path, consult /mnt/skills/public/file-reading/SKILL.md (or /mnt/skills/public/pdf-reading/SKILL.md for a PDF) so you extract it correctly instead of guessing at the format.

No CV: build a role-generic sheet. Skip the candidate summary and the CV-probing questions, anchor questions to the role's stack and to realistic scenarios instead, and mark the sheet as role-generic in the header so nobody mistakes it for a tailored one.

Step 2 — Read the candidate before writing questions

Work through the CV and note, for your own use:

• Stack, domains, and scale (team size, traffic, release cadence, regulated industry)
• Systems they describe concretely enough to ask about
• Requirements from the role that the CV never mentions — the gaps are where the interview earns its value
• Claims worth verifying: a tool listed for longer than it has existed, a seniority jump that doesn't match the timeline, a stack that appears in the skills list but never in any job description, very short tenures

On that last point: only flag what is actually there. Manufacturing suspicion about a clean CV produces an unfair interview and burns question slots that should have gone to depth. If nothing warrants verification, say so in the sheet header in one line and use those slots for harder technical questions instead. When something does warrant it, phrase it neutrally as a thing to confirm, not an accusation, and note why it's flagged so the interviewer can drop it if the explanation is obvious.

Read references/question-bank.md before drafting. It carries per-topic coverage checklists and per-seniority calibration so the questions land at the right level and nothing important gets skipped.

Step 3 — Draft the questions

Budget

A 60-minute slot is not 60 minutes of questions. Reserve roughly 5 minutes for introductions and 10 for the candidate's own questions, then assume each core question runs 2–3 minutes including its follow-ups.

Slot	Core questions	Technical time
30 min	6–8	~20 min
45 min	9–12	~30 min
60 min	12–15	~40 min
90 min	20–26	~65 min

Each core question carries 1–2 follow-up probes. These aren't extra questions; they're what the interviewer asks when the first answer is shallow, or to push a strong candidate until they hit their limit. Finding the ceiling is how you distinguish a mid from a senior.

Tag every question must-ask or optional. Interviews run long, and an interviewer who knows which three questions to drop at minute 40 keeps the coverage that matters.

Structure

Group by topic and order easier to harder inside each group, so a nervous candidate warms up rather than freezing on the hardest thing first. Use only the groups relevant to the role, drawn from: testing fundamentals, test automation, process and methodology, the role's domain specialties (API, web, mobile, performance, security, data), debugging and investigation, and CV verification.

Assign each group a time budget, and put the resulting pacing line in the header. An interviewer who can see they're eight minutes behind at the automation section will adjust; one who can't, won't.

Anchoring

Every question must attach to something concrete: a tool from their stack, a system they described, a claim on their CV, or a scenario from the role's actual domain. Compare:

Weak: What is the test pyramid?

Anchored: Your CV says the suite at Acme was about 400 UI tests and 60 API tests. How did it end up shaped that way, and what did it cost you?

Both target the same knowledge. The first can be answered from a blog post; the second requires having been there. Two deliberate warm-up questions at the start are fine and often kind — beyond that, anchor everything.

Keep the sheet technical. A separate HR round covers motivation, culture, and conflict, so repeating that here duplicates their work and spends technical minutes you don't have.

Answer signals

For each question write two short lines rather than one model answer:

• Strong answer covers — the substance you're listening for, in keywords
• Weak signal — what a memorized or inexperienced answer sounds like

A single "expected answer" fails in the two cases that matter most: when the interviewer is less deep in the topic than the candidate, and when the candidate gives a correct answer that differs from the crib sheet. Contrast between strong and weak handles both.

Step 4 — Self-review before building anything

Reread the full draft with fresh eyes and cut or rewrite:

1. Any question a competent candidate could answer from a textbook without having done the work (beyond the two warm-ups)
2. Any question whose strong-answer line is really just the question restated
3. Any flagged verification item that isn't supported by something actually on the CV
4. Duplicate coverage — two questions probing the same skill from the same angle
5. Anything that drifted into behavioral territory

Then check the count against the budget table and the section minutes against the technical time. This pass matters more than it looks: first drafts reliably contain two or three textbook questions that survive simply because nobody reread them.

Step 5 — Build the PDF

Write the sheet as JSON, then render it with the bundled script. The script owns layout, page breaks, repeated table headers, and print sizing, so you never re-derive styling and every sheet comes out consistent.

cd <skill-dir>
python3 scripts/build_sheet.py --data interview.json --out /mnt/user-data/outputs/<candidate-or-role>-interview.pdf

Run python3 scripts/build_sheet.py --schema to print the exact JSON structure with an example. The script validates as it goes and prints warnings when the question count or the section minutes don't fit the duration, which is a cheap last check on Step 4.

Language: default to English. If the job description or CV is clearly in another language, follow that instead, and always honor an explicit request. The template renders Cyrillic and Georgian correctly. Avoid emoji anywhere in the JSON — the PDF fonts render them as empty boxes, which looks broken on a document handed to a hiring manager.

Present the PDF with present_files. If the user asks for an editable version, read /mnt/skills/public/docx/SKILL.md and produce a DOCX from the same JSON; keep PDF as the default since it prints predictably.

Finish by telling the user, in a couple of lines, what you assumed and what you flagged, and offer to re-cut the sheet toward a particular area. Do not restate the questions in chat — they're in the file.