Marcus runs technical recruiting at a 90-person climate-tech startup, and last quarter he ran the loop for a senior backend engineer role that drew four strong finalists. After the on-sites, he had eleven pages of interview notes from five interviewers and a hiring manager who wanted a recommendation by end of day. He had read every page twice and still could not have told you, cleanly, which candidate had the deepest distributed-systems experience or which one would thrive on a five-person team that ships daily. The notes told the story of each interview. What Marcus needed was something the notes did not give him directly: the same handful of decision-relevant facts about every candidate, organized the same way, with the evidence still attached. That gap - between a narrative and a structured comparison - is exactly what AI-assisted extraction closes.

Summary Versus Extraction: Why the Distinction Matters

A summary and an extraction sound like the same task, but they serve different jobs. A summary answers "what happened in this interview overall." An extraction answers "what are the specific qualifications, skills, and fit signals, organized by dimension." The first is a story; the second is a data structure.

For a hiring decision, the data structure wins. "This candidate has three years of backend experience, shipped two production payment systems, and stayed calm when the interviewer kept changing the requirements" is more decision-useful than three warm paragraphs about how the conversation went. The story is pleasant to read and easy to forget. The structured version can be lined up against three other candidates and compared field by field.

When Marcus asks an AI tool - he uses Anthropic's Claude for this, though ChatGPT handles the same task - to summarize an interview, he gets prose. When he asks it to extract, he gets the four-part structure this lesson is built around. The shift from "summarize this interview" to "extract these specific things from this interview" is the single highest-leverage change a recruiter can make to how they use AI on interview notes.

The Four-Part Extraction Framework

A good extraction has four parts, and each one answers a different question about the candidate.

Part 1: Direct qualifications. These are explicitly stated or easily verifiable facts - years of experience, technologies used, roles held, certifications. For Marcus's backend role, a clean extraction reads: "Five years backend engineering, two at a fintech. Primary languages Python and Go. Databases PostgreSQL and Redis. Led a team of four." These are the easy facts, but they still need to be pulled out and stated plainly so they can be compared.

Part 2: Demonstrated skills. These are abilities shown through the candidate's work or how they describe it - problem-solving approach, learning speed, communication clarity, technical depth. The key word is demonstrated. "Debugged a complex concurrency issue by systematically eliminating possibilities, explained the trade-offs clearly, and picked up the team's Rust conventions in a day" is a demonstrated skill. It is anchored in something that happened in the room, not a self-description.

Part 3: Fit signals. These are indicators the candidate would succeed in your specific situation - comfort with ambiguity, ownership mentality, communication style, collaboration. For a five-person team that ships daily, fit signals matter enormously: "Takes ownership of problems rather than waiting for direction. Comfortable working from incomplete requirements. Asks clarifying questions instead of assuming." Fit is not general competence; it is competence in your context.

Part 4: Concerns. These are gaps or red flags specific to your role, with context attached. A concern without context is a landmine: "Limited experience with distributed systems" reads as disqualifying until you add "though they learned Kafka in a weekend for the take-home and clearly enjoy the depth." Marcus's rule is that every concern carries its mitigation or its ambiguity: "Asked few questions about the team - unclear whether that signals low interest or just a reserved style."

All four parts matter, and they matter for different reasons. Drop concerns and you build a hype document. Drop fit signals and you hire a technically excellent person who quits in four months. The framework's value is that it forces you to look in all four places for every candidate.

Building Your Extraction Prompt

An effective extraction prompt tells the AI exactly what to look for, dimension by dimension. Vague prompts produce vague extractions. Here is the prompt Marcus built for the backend role, which he keeps in his prompt library and reuses with small edits for every engineering req:

"I'm extracting key information from interview notes for a senior backend engineer role on a five-person, fast-moving team. From the notes below, identify the following. For every claim, cite the specific example or quote from the interview that supports it.

Direct qualifications:

• Years of backend engineering experience
• Primary programming languages and proficiency level
• Databases and infrastructure technologies
• Team sizes worked with
• Company types (startup, scale-up, enterprise)

Demonstrated skills (with the example that shows each):

• Problem-solving approach
• Communication clarity when explaining technical decisions
• Learning speed and evidence of picking up new technologies
• Ownership and evidence of taking initiative
• Code-quality mindset (testing, documentation)

Fit signals for a five-person team that ships daily:

• Comfort with ambiguity
• Ability to move quickly with examples of shipping speed
• Collaboration style
• Mentoring inclination, if shown

Concerns: For each, give (1) the concern, (2) the context that explains it, and (3) how significant it is for this specific role. Mark whether each is supported by demonstrated behavior or only by what the candidate stated.

Format each section as a bulleted list. Be specific, stay concise, and do not include anything you cannot tie to evidence in the notes."

The closing instruction is doing heavy lifting. By asking the AI to cite evidence for every claim and to refuse to invent what is not in the notes, Marcus gets an extraction he can audit rather than one he has to trust blindly.

Comparative Extraction Across Candidates

Extraction becomes most powerful when you run the same structure across several candidates and then ask for a comparison. Marcus pastes the notes for all four finalists into a single prompt: "I have interview notes from four candidates for a senior backend engineer role. Extract the same four-part structure for each, then build a comparison table scoring technical depth, relevant experience, fit for a five-person fast-moving team, and growth potential. Cite the evidence behind each score, and flag where a candidate's notes are too thin to judge a dimension."

Two details in that prompt do the work. The first is that the extraction structure is spelled out again rather than assumed, so every candidate is pulled apart along identical lines. The second is the list of comparison dimensions: technical depth, relevant experience, fit for the specific team culture, and growth potential. Those four are what the hiring decision actually turns on, and naming them keeps the comparison from drifting into whichever candidate happened to be described most vividly.

For three of his finalists, the comparison came back like this. Candidate A: eight years of experience, deep distributed-systems background, but every fit signal pointed to a big-company rhythm - "asked twice about formal code-review SLAs," "wanted to know the on-call rotation policy in detail." Strong on depth, uncertain on the five-person-team fit. Candidate B: four years, narrower stack, but the demonstrated-skills section was the richest of the three - "shipped a feature end to end during the take-home," "rewrote the failing test rather than skipping it." High fit, moderate depth, clear growth trajectory. Candidate C: six years, solid across the board, no standout strengths and no real concerns, the safe middle.

That table changed the conversation. Marcus's hiring manager had been leaning toward Candidate A on the strength of the resume. The extraction surfaced, with evidence attached, that A's fit signals were the weakest of the three for this particular team - and that B, who looked less impressive on paper, had demonstrated exactly the ship-it-and-own-it behavior the team needed. They advanced B and A to final references with eyes open about each one's risk.

The time math matters too. Reading and mentally cross-referencing eleven pages of notes for four candidates took Marcus the better part of ninety minutes the old way, and the comparison lived only in his head. The extraction-and-compare pass took about twelve minutes of prompting and review, and it produced an artifact he could share with the hiring manager and defend in the debrief. Call it roughly fifteen minutes saved per candidate, but the real gain was the shared, evidence-backed structure, not just the clock.

Anti-Patterns to Avoid

Extracting too much. The first time Marcus tried this, he asked the AI to pull out everything in the notes. The extraction came back nearly as long and as dense as the original eleven pages. He had duplicated the problem rather than solving it. Extraction is supposed to simplify - to reduce eleven pages to the dozen facts that drive the decision. If your extraction is as hard to scan as the source, your prompt is too broad. Name the specific things you care about and let the rest fall away.

Over-weighting explicit statements. It is tempting to trust only what a candidate said outright and to penalize what they did not mention. Marcus nearly downgraded Candidate B on front-end work because the notes never quoted them claiming front-end skill - until he noticed the technical round described them debugging a CSS layout issue cleanly. They had demonstrated the skill without claiming it. What people show under pressure is a stronger signal than what they list. Ask your extraction to mark each finding as "claimed" or "demonstrated" so the difference stays visible, and weight demonstrated behavior accordingly.

Losing the evidence. The most dangerous extraction is a clean list of conclusions with the evidence stripped out. "Strong communicator" tells you nothing - different interviewers mean wildly different things by it. "Strong communicator: walked through the trade-offs of the rate-limiter design without jargon and checked the interviewer was following" tells you what was actually observed, and lets you judge whether it meets your bar. Always require the AI to attach the specific example or quote behind every claim. An extraction you cannot audit is worse than no extraction, because it launders a vague impression into something that looks rigorous.

Putting It Into Practice

Start with one role you are actively filling. Build an extraction prompt that names the direct qualifications you genuinely care about, the demonstrated skills you want to assess, the fit signals specific to that team, and the concerns that would actually matter for the work. Run it against two or three real or mock interviews, then read the output critically: what is useful, what is missing, what is noise you should prompt away.

Then run the same prompt across the candidates side by side and ask for a comparison. Notice how much faster the decision gets when the same facts sit in the same place for everyone. Finally, do an evidence check - take any major claim in the extraction, "strong technical depth," "great team fit," and confirm the AI tied it to something that happened in the interview. If it did not, tighten the prompt until it does. The discipline of always citing evidence is what separates an extraction you can defend in a debrief from one that just looks organized.

One more pass is worth building into the habit: simplify. If your extraction is hard to scan, or if the decision-relevant material keeps getting buried under everything else the candidate mentioned, ask yourself what the top five things you actually need to know about this candidate are, and rebuild the prompt around those five. An extraction earns its place by being shorter and sharper than the notes it came from, not by being complete.

A Week of Structured Comparison

The best hiring decisions come from comparing structured information rather than competing impressions. When you have three candidates extracted through the same framework, three questions answer themselves quickly: who has the technical depth, who fits the team best, and who has the most growth potential. That structured thinking is what leads to better decisions, and it is available to you as soon as the same fields exist for everyone.

So give it a week. Build one extraction prompt for the role you are filling right now, use it on two or three candidates, and pay attention to how much easier the comparison becomes when the information arrives in the same shape every time. The prompt you end that week with is the one you will reuse for the rest of the year.

The Vocabulary of Extraction

Five terms carry the weight of this lesson, and it is worth keeping them distinct when you talk about the work with a hiring manager.

• Extraction. The act of identifying and organizing specific information out of notes or documents. It is more structured than a summary and more useful for making a decision.
• Demonstrated skills. Abilities shown through actions or work during the interview rather than merely claimed. A more reliable signal than an explicit statement.
• Fit signals. Evidence that a candidate would succeed in your specific role and team environment, which is a different question from whether they are generally competent.
• Comparative extraction. Using one extraction structure across several candidates so that direct, dimension-by-dimension comparison becomes possible.
• Evidence-based. An extraction that carries specific examples or quotes from the interview behind each claim, so a reader can judge the claim rather than accept it.

Practice Exercises

Work through these in order on a live req rather than a hypothetical one; the value shows up when the notes are messy and the deadline is real.

• Build your extraction prompt. For the role you are hiring now, write out the direct qualifications you care about, the demonstrated skills you want assessed, the fit signals particular to that team, and the concerns that would genuinely matter for this work.
• Extract from interview notes. Run your prompt against a real or mock interview and review what comes back. What is useful, what is missing, what would you add or remove before you send it to anyone?
• Compare two candidates. Extract from two interviews with the identical prompt and compare them directly. Which candidate is stronger, and on which dimensions specifically?
• Run an evidence check. Take one extraction and, for every major claim such as strong communicator, technical depth, or fit for the team, confirm the supporting evidence from the interview is present. Anything unsupported goes back to the model or comes out.
• Simplify. If the extraction is hard to scan or the decision-relevant material is getting lost, cut it down to the top five things you actually need to know and refocus the prompt there.

Reflection

Before you standardize anything, sit with four questions about how you make these calls today.

• When you evaluate candidates, what information do you actually need to reach a decision, and what currently gets lost because you are reading narrative notes?
• How would your hiring decisions change if you had structured comparisons of candidates instead of narrative summaries?
• Which dimension of fit, whether technical, team, or growth potential, are you deciding on without enough information right now, and how could extraction close that gap?
• If you extracted every candidate through one standard framework, what would you learn about your own hiring patterns?

Related Lessons

• AI Summarization: Capabilities and Typical Errors sits directly underneath this one. Extraction is a specialized form of summarization, and the failure modes covered there, especially omission and confident invention, are the same ones that will damage an extraction if you do not require evidence.
• Flagging Red Flags and Concerns Without Bias takes up the fourth part of the framework in full. Concerns are the hardest part of an extraction to get right, because the line between a legitimate role-relevant gap and a bias-driven flag is thin, and that lesson is where you learn to hold it.
• Formatting and Organizing Summaries for Decision-Making is the natural next step once you have the content. Extraction determines what goes into the document; formatting determines whether a hiring panel can act on it in two minutes.
• Documenting Decisions: Clear Records for Legal and Fairness Review explains why the evidence discipline in this lesson pays off beyond the debrief. An evidence-backed extraction is also the record you would want to have if a hiring decision were ever questioned.

Key Takeaways

• Extraction beats summary for hiring decisions. A summary tells the story of an interview; an extraction gives you a structured, comparable set of facts. The shift from "summarize this interview" to "extract these specific things" is the highest-leverage change you can make to how you use AI on interview notes.
• Use the four-part framework every time. Direct qualifications, demonstrated skills, fit signals, and concerns. Each answers a different question, and dropping any one of them produces a distorted picture - a hype document, a culture mismatch, or a candidate who looks better on paper than in the room.
• Specificity in the prompt drives quality in the output. Name the exact qualifications, skills, fit signals, and concerns you care about for this role and this team. A vague prompt produces a vague extraction; a precise one produces something you can act on.
• Extract for comparison, not just for one candidate. The real payoff comes from running the same structure across several candidates and asking for a side-by-side comparison with evidence. That artifact reorients debriefs away from resume gut-feel and toward what was actually observed.
• Weight what candidates demonstrate over what they claim. Mark each finding as "claimed" or "demonstrated." Behavior shown under interview conditions is a stronger signal than a self-description, and the distinction keeps you from over-rewarding a polished pitch.
• Always cite the evidence. "Strong communicator" is a claim; "strong communicator: explained the rate-limiter trade-offs without jargon" is evidence. An extraction you cannot audit launders a vague impression into false rigor - require the supporting example behind every claim.
• Do not extract everything. Extraction should simplify. If the output is as long and dense as the source notes, your prompt is too broad. Focus on the dozen facts that actually drive the decision and let the rest fall away.