Interview Drills — Practical Prompt Craft
6 drills with frameworks and rubrics.
Interview Drills — Practical Prompt Craft
Open-ended, hands-on drills. Each has a Framework (the structure a strong answer follows), a Model answer (a concise worked example), and a Rubric (what an interviewer listens for). These are live exercises: in a real 2025 AI-adjacent interview you'll be asked to write or fix a prompt on the spot and narrate your reasoning. Practice thinking aloud and always tie the prompt back to a goal and a way to check the output. The app can role-play these as mock interviews (see
mock-interview.md).
The universal prompt-craft structure (Topic 4): Assign a Role → state the Task → list the Constraints (context, audience, length, what to avoid) → specify the Output Format → then iterate: try, diagnose what's off, refine, repeat — and verify anything important. Use it on almost any "write me a prompt" or "fix this prompt" question.
D1
- difficulty: easy
- concept: prompt-engineering-fundamentals Write a prompt that gets an AI to draft a cold sales email for a small B2B SaaS. Walk me through how you structure it.
- Framework: Use Role + Task + Constraints + Output Format. Assign a role (who the AI should act as) → state the task in one clear sentence → add the constraints that actually matter (audience, length, tone, what to avoid) → specify the exact output format → say one word about how you'd check the result.
- Model answer: "Role: 'You are a B2B sales copywriter who writes short, no-fluff cold emails.' Task: 'Write a cold email introducing our tool that helps small accounting firms automate client onboarding.' Constraints: 'Audience: a busy office manager who's never heard of us. Under 90 words. Friendly but not salesy. No jargon, no fake urgency. One clear call to action: a 15-min call.' Output format: 'Subject line + body. End with the CTA on its own line.' Then I'd read it for whether it sounds human and would actually get opened — and tweak from there."
- Rubric: Strong answers explicitly hit all four pieces (Role, Task, Constraints, Output Format), make the constraints specific (audience, word count, tone, what to avoid), and pin down the output shape. Weak answers give one vague line ("write a sales email"), skip the audience, or never say what the output should look like.
D2
- difficulty: medium
- concept: prompt-engineering-fundamentals Here's a weak prompt: "Summarize this article." Improve it out loud and explain each change.
- Framework: Diagnose what's missing → add it piece by piece using Role + Task + Constraints + Output Format → name why each addition makes the output more reliable. Cover: for whom, how long, what to keep/drop, and the format.
- Model answer: "It's missing everything except the verb. I'd diagnose: no audience, no length, no format, no role. Rewrite: 'You are an editor briefing a busy executive. Summarize the article below for someone who won't read the original. Keep it under 120 words, focus on the main finding and why it matters, skip background and methodology. Output as 3–4 bullet points, then one bold takeaway line.' Each change removes a guess the AI would otherwise make — without a length it picks a random one, without an audience it writes generically, without a format I get an unpredictable blob."
- Rubric: Strong answers diagnose before rewriting, then add audience, length, focus, and format with a stated reason for each ("this removes a guess"). Weak answers just make the prompt longer without explaining what gap each addition fills, or add only one dimension (e.g., length) and stop.
D3
- difficulty: medium
- concept: prompt-engineering-fundamentals You want an AI to classify support tickets as "billing", "bug", or "feature request". Show me how few-shot examples make this prompt reliable.
- Framework: Start with Role + Task + the fixed label set → explain why a classification task needs examples (it pins down edge cases and output format) → add 2–3 labeled examples that cover the tricky boundaries → lock the output format so it's parseable → mention testing across inputs.
- Model answer: "Task: 'Classify each ticket as exactly one of: billing, bug, feature_request. Reply with only the label.' Then I add few-shot examples to remove ambiguity: 'Ticket: "I was charged twice this month." → billing. Ticket: "The export button does nothing." → bug. Ticket: "Can you add dark mode?" → feature_request.' The examples teach the boundary cases (a charge complaint vs. a broken feature) and lock the one-word output so it's machine-readable. Then I'd test it on 10–15 real tickets to catch where it's unsure or invents a fourth label."
- Rubric: Strong answers explain why few-shot helps here (disambiguates edge cases + fixes output format), choose examples that cover boundaries rather than obvious cases, constrain the output to be parseable, and mention testing across multiple inputs. Weak answers add random examples, pick only easy/obvious ones, or never connect examples to reliability.
D4
- difficulty: medium
- concept: prompt-engineering-fundamentals The model's first answer to your prompt is "almost right." Walk me through your iteration loop instead of just rewriting from scratch.
- Framework: Name the loop: try → diagnose the specific gap → make a targeted refinement (don't restart) → repeat → verify. Stress diagnosing precisely ("too long" vs. "missed requirement X" vs. "wrong tone") and giving the AI a surgical follow-up rather than a vague "do better".
- Model answer: "I treat prompting as a refinement loop, not a one-shot. First I diagnose precisely — is it too long, wrong tone, or did it miss a requirement? Say it's right but too formal and it dropped the CTA. I don't rewrite the whole prompt; I give a targeted follow-up: 'Good — make it warmer and add the call-to-action as the last line.' I repeat until it's right, then verify the facts and tone before using it. Targeted fixes converge faster than starting over, and they teach me which part of my original prompt was underspecified."
- Rubric: Strong answers describe the explicit loop (try/diagnose/refine/repeat/verify), emphasize precise diagnosis and surgical follow-ups over restarting, and include verification. Weak answers say "I'd just rephrase it" with no diagnosis step, or jump straight to a full rewrite, or omit verifying the result.
D5
- difficulty: hard
- concept: prompt-engineering-fundamentals Critique this prompt: "You are the world's best lawyer. Give me a contract that protects me completely from any lawsuit. Make it perfect." What's wrong and how would you rewrite it?
- Framework: Identify the flaws — empty superlatives that don't add information, an impossible/unverifiable goal, no real constraints, no context, and a high-stakes domain where hallucination is dangerous → rewrite with a grounded role, a scoped task, real constraints, an output format, and an explicit verification/escalation step.
- Model answer: "Flaws: 'world's best' and 'perfect' add no real instruction; 'protect me completely from any lawsuit' is an impossible, unverifiable goal that invites confident nonsense; there's no context (what contract? what jurisdiction? what risk?). And law is high-stakes, so hallucinated clauses are dangerous. Rewrite: 'You are a contracts assistant helping a freelancer draft a plain-English services agreement (US, single client). Draft clauses covering scope, payment terms, IP ownership, and a liability-limitation section. Flag any clause a licensed attorney should review and note assumptions. Output as numbered clauses with a one-line purpose each.' Then I'd treat it as a draft to verify with a real lawyer, never final output."
- Rubric: Strong answers call out the empty superlatives, the impossible/unverifiable goal, and the missing context, recognize the high-stakes hallucination risk, and rewrite with a grounded role, scoped task, real constraints, a format, and a verification/escalation step. Weak answers only tweak wording, keep the "make it perfect" framing, or miss that confident-but-wrong output is the core danger here.
D6
- difficulty: hard
- concept: evaluating-ai-output Design a prompt for a product feature that auto-replies to customer reviews, and tell me how you'd know your prompt is good — not just that one output looked fine.
- Framework: Build the prompt (Role + Task + Constraints + Output Format, including safety constraints) → then define evaluation: test across varied inputs (positive, angry, edge cases), check accuracy/tone/safety/instruction-following, and set a pass bar — because a prompt baked into a product must work reliably, not once.
- Model answer: "Prompt: 'You are a calm, empathetic support rep. Write a reply to the customer review below. Constraints: under 60 words, thank them, address their specific point, never promise refunds or admit legal fault, escalate angry/legal cases by offering a support email instead of resolving. Output: just the reply text.' How I'd know it's good: I'd run it across a test set — glowing reviews, 1-star rants, vague ones, and a fake legal threat — and score each on tone, whether it addressed the actual complaint, instruction-following (length, no refund promises), and safety (does it escalate when it should?). I'd set a bar like 'no unsafe replies and 90%+ on-tone' before shipping, since this runs unattended on real customers."
- Rubric: Strong answers write a complete, safety-aware prompt and shift to systematic evaluation — testing across varied/adversarial inputs, naming the dimensions (accuracy, tone, safety, instruction-following), and setting a pass bar because it's productionized. Weak answers only produce a prompt, judge it on a single happy-path output, or ignore safety/escalation and reliability entirely.