In this lesson you'll do two things: set up privacy — three minutes — and take a working prompt that turns "take a look at this resume" into a structured brief with evidence. Then the interesting part begins: how to tell where that brief is lying.
A resume is the personal data of a person who trusted it to you for a specific job. The responsibility for it lies not with the service but with whoever collected it (in the law — the data "controller"): you, the agency, or the client who gave you the job. Whatever you do with AI, three things don't change: share the minimum of data, work only in a tool your employer or client has approved, and make the decision about the person yourself. That is exactly why the exercises in this lesson use synthetic resumes — so you can learn without practicing on real people.
By default, the consumer plans of all three systems may use your conversations to train their models. Checked by us, August 2026: on a freshly created free Claude account this toggle was on. It's not a conspiracy — just a default setting, and it takes three minutes to change. Look there again every few months: interfaces and toggle names change, and a new plan doesn't inherit your settings.
| System | Toggle | Where |
|---|---|---|
| Claude | "Help improve our AI models" | Settings → Privacy → turn off |
| ChatGPT | "Improve the model for everyone" | Settings → Data Controls → turn off |
| Gemini | "Keep Activity" | Activity → turn off + delete history |
One honest correction: this is not the same as "the data isn't stored anywhere". The service still processes it and keeps it for a while: Claude — 30 days after you delete a chat, ChatGPT — also up to 30 days, Gemini — 72 hours even with activity turned off, and anything that went to human review stays longer and can't be deleted with your button. So it's better to practice on synthetic resumes (they're below, take them), and before working with real CVs, check the rules of your employer or client: some companies have their own list of approved tools.
Two nuances: a paid "single-user" plan doesn't turn the toggle off by itself, and it only applies going forward. If you work with an agency's client data — a consumer plan isn't enough, and your own "team plan" doesn't settle the question on its own either. You need two things: a business plan with a signed data processing agreement (also called a DPA) — and the client's permission for this specific service. The client who gave you the job is responsible for their candidates' data and has the right to know which tools it passes through. Check both points before your first real resume — it's one short email exchange, not a project. We keep the current paths in the "Market snapshot" — it's part of Module 1.
Most people phrase the task in one sentence: "take a look at this resume for the job". The answer comes back confident — and sounds just as confident regardless of whether the system had enough data for a conclusion. Tidy text and true text are different things, and you can't tell them apart by eye.
Instead of one sentence, we give a structure of six blocks: role — who the system works as; context — what we feed in; task — one specific action; success criteria — what a good answer looks like; format and constraints — what to do when data is missing. The most valuable are the last two: they catch fabrications before they even appear.
Paste it into any system, put your job posting and the candidate's resume in the square brackets — and you'll get a structured brief instead of a retelling.
Role: you are a recruiting assistant who prepares an analytical brief on a candidate for
a recruiter, not a final hiring decision.
Context:
Job posting: [paste the full text of the job posting].
Candidate: [paste the resume — without full name and contacts, companies as "industry + size",
the school as a category].
Task: analyze how well the candidate fits the job posting.
Success criteria for the answer:
1. Assess the fit for each requirement of the job posting separately (stack/skills, years
of experience, seniority level).
2. Highlight the candidate's strengths, each with a reference to a specific fact from the resume.
Evidence means a described action: a completed task, an achieved result or
a measurable metric. A list of skills and a job title are not evidence.
Claims about change — "N times", "by N percent",
"significantly", "substantially" — without before and after values are not evidence: mark
them as needing verification. This applies to change specifically; absolute
numbers ("~600 scenarios", "40 DAGs") are checked with a question, not with this
rule.
If a result is described with "we" — "we reduced", "we moved to", "we
managed to" — don't count it as a strength: the text doesn't show what this
particular candidate did. Put it under "Risks" with the note "candidate's contribution
not visible". This is not a minus for the candidate: the numbers may be true; only
their role in them is unknown.
The reverse is also a rule. If the candidate writes about themselves with "I" ("I built",
"I extracted", "I set up"), don't question authorship: the question "did they do it
themselves" is asked when the resume text points to it, not when the
result seems too big for this candidate.
3. Highlight risks and gaps (job requirements without confirmation, level
mismatch, outdated skills) — also with a reference to a specific fact from the resume.
4. Do not recommend or reject the candidate. Instead of a conclusion, give one hypothesis
to verify: what exactly needs to be confirmed or refuted at the screening so that
the recruiter can make the decision.
Output format: subheadings "Fit", "Strengths", "Risks",
"Hypothesis to verify". Maximum 250 words.
Constraints: do not assess the candidate on characteristics that are not in the job requirements:
age, gender, photo, university name, citizenship, marital status, military service
status, immigration or refugee status, career gaps. Do not invent facts that are not in the resume
(employers, dates, positions, skills). If there isn't enough information for a conclusion — say directly what exactly is missing,
instead of filling it in. Mark each assumption separately with the word "assumption:".
We ran the prompt through Claude, ChatGPT and Gemini on a synthetic resume that had one innocent phrase: "optimized system performance by 10x". No metric. No baseline for comparison. No way to check.
Why this happens — and will keep happening with any future version of the models. The system doesn't check facts: it continues text. "Optimized by 10x" is written in the same grammatical form as "cut response time from 2.4 s to 180 ms" — both look like a description of a completed action. The difference between them isn't linguistic but factual: the second has a baseline for comparison, the first doesn't. A language model works with form, so it treats them as equal. Hence a rule that always works: a number without a baseline is not evidence but a claim that needs to be checked by voice.
So as not to take even our own word for it, we took a different synthetic resume — with the phrase "cut the number of incidents threefold", also without any before and after numbers — and ran the same prompt twice: with the line about claims of change and without it.
Claude (Opus 5), August 18, 2026. The resume is new and isn't mentioned anywhere else in this lesson — so the system couldn't peek at the answer in the task itself. Absolute numbers from the same resume ("~800 requests/min", "240 automated tests") were counted as evidence in both runs: the rule targets change specifically, not any number.
Now look at the brief you just got on your candidate. It also has confident wording. The question is no longer whether the prompt worked — it did. The question is which of these claims you can check, and which just sound good.
Analyzing one candidate is half the job. The other half begins when five applications come in for the job and you need to decide whom to call. Below is the lesson's second prompt: the input is the job posting and several resumes, the output is one table where every assessment is backed by a quote from the resume.
One "but", and it's not about paranoia. The resume file brings everything with it: full name, phone, email, sometimes a photo and date of birth. This is another person's personal data — and the responsibility for it lies not with the service but with whoever collected it: you, your agency or the client.
Turning off training doesn't remove this responsibility. It closes one thing: your chats won't go into model training. But it doesn't make handing the resume to a third-party service legitimate — for that you need a data processing agreement, and consumer plans (Free, Pro "for one person") don't provide one. So the order is:
What not to upload to a chat at all: medical certificates and anything about health, military service status and exemptions, immigration or refugee status, scans of a passport, national ID or tax number. You don't need any of this to assess a candidate for a job, and such data requires stricter protection.
Role: you are a recruiting assistant who prepares a comparison table of candidates for one
job posting for a recruiter. A person makes the hiring decision, not you.
Context:
Job posting: [paste the full text of the job posting].
Candidates: [paste 3–7 resumes one after another, each starting with the line "=== Candidate-001 ==="
— or attach the resume files to this message. Remove full names and contacts
before pasting or before uploading the file: in the prompt it no longer works, the data
travels together with the file].
If full names, contacts, photo, age or gender are still left in the resumes — do not
use them in the comparison and do not mention them in the answer. In your columns,
write about candidates without gendered pronouns: "the resume…", "clarify at screening…",
"the candidate will name…".
Task: build one comparison table of the candidates against the requirements of this job posting.
Success criteria for the answer:
1. One row — one candidate. Columns — the key requirements of the job posting plus the columns
"Risks and screening questions" and "Hypothesis to verify": what exactly needs to be
confirmed or refuted at the screening.
One requirement — one column. Do not merge several requirements into one ("Git + CI/CD"):
that way you can't see which of them is met. If there are more than eight requirements, take the eight
most important and list the rest in a line under the table. Merging to
fit within the limit is not allowed: fewer columns are better than glued ones.
2. Check the requirements in the order in which they are listed in the job posting, and do not
change this order from candidate to candidate.
3. The format of each requirement cell — an assessment, a vertical bar, a verbatim quote
from the resume in quotation marks; if needed, a note as the third element (see below):
assessment | "verbatim quote from the resume in quotation marks" | note
If there is no quote, distinguish two cases and write them differently:
"no quote — the resume is silent on this" — this is "no data";
for "no" a quote is mandatory: give exactly the sign because of which the requirement is not
met (e.g., no | "stack .NET 8, ASP.NET Core"). "No" without a quote is impossible —
if there is nothing to quote, it's "no data", not "no".
A retelling in your own words ("confirmed by experience", "listed in skills") is not
accepted: it is not a quote.
A note is a short annotation of what the assessment rests on or why it is not
higher: "from the skills list" (a word in a list looks like evidence, but isn't),
"needs verification" (for claims of change without before and after values),
"candidate's contribution not visible" (the result is described without the candidate as
the one who did it), "indirect" (the requirement is not named, but what is named
can't exist without it), "self-declared" (a language level stated by the candidate themselves). If
there is nothing to add, leave two elements.
4. First determine the type of the requirement, then apply the scale for that type. The scale is the same
for all candidates. Mark the type in the column header: "English B1 or higher
(formal)".
A formal requirement is met by the fact itself and does not need a description of an action: years
of experience, seniority level, degree, location, language level.
A substantive requirement is about a skill: stack, tool, practice, type of tasks.
For a formal requirement:
yes — the fact is in the resume and matches the dates;
no — the fact is there and falls short of the requirement;
no data — the fact is not in the resume.
Do not use "partially" for a formal requirement: four years when the requirement is
three is "yes". The candidate declares their language level themselves; this is also "yes", and
the note "self-declared" goes as the third element. A level named
outside the CEFR scale ("intermediate", "fluent") or with a caveat
("I speak worse") is likewise "yes | self-declared"; the language check
at screening is the same for everyone who has this note.
For a substantive requirement:
yes — an action of the candidate is described: a completed task, an achieved result or
a measurable metric, and the quote names the subject of this specific requirement — this
tool, this database, this practice. "Improved work with the database" without naming the DB
does not prove PostgreSQL. A quote that you marked in another column or note
as needing verification cannot be evidence for "yes" — for it the
maximum is "partially | needs verification";
partially — only a list of skills, a pet project or indirect confirmation.
Indirect confirmation is a mention of a tool or practice that can't exist without this
requirement: there's no Helm without Kubernetes, no GitHub Actions without Git.
That is "partially" with the note "indirect". An adjacent technology of the same
category that the job posting does not name (MariaDB when the requirement is only
PostgreSQL) is also "partially";
no — the resume contains a sign that the requirement is not met: it says directly "did not work with"
or a different stack without any mention of the language or area of the requirement. If the candidate
mentions this language in pet projects or training, it's "partially" or "no
data", not "no";
no data — the resume is simply silent on this. Silence is "no data",
not "no": the difference between "can't do it" and "didn't write it" is settled at screening.
Years of work and a job title do not meet a substantive requirement: experience in Python
does not mean the person wrote web services. For a substantive requirement this is the
maximum "partially".
5. After the table — a separate block "What the resume doesn't show": what exactly will have to
be clarified by voice for each candidate.
6. After the table — a list of questions that will close the gaps. The order of the questions is
by the order of the requirements in the job posting, not by candidate: otherwise the list
turns into a ranking of resume weakness.
Output format: one table, two blocks under it. No introduction and no closing
praise.
Constraints:
— Do not rank the candidates and do not recommend whom to call. Your task is to lay out
the evidence and the gaps by the same criteria; the recruiter compares and decides.
— Give quotes in the original language of the resume, do not translate them: a translated quote
can't be found by searching the resume itself.
— Do not invent facts that are not in the resume: technologies, dates, positions, companies.
— Do not level the candidates against each other. If a resume is empty on a requirement, say
so, even if all the other cells are filled.
— Do not compare on characteristics that are not in the job requirements: age, gender, photo,
university name, citizenship, marital status, appearance, military service status,
immigration or refugee status. Do not call a career gap a risk: behind it may be
caregiving, parental leave, illness, relocation, military service, layoffs — not the quality of the professional.
— Claims about change — "N times", "by N percent",
"significantly", "substantially" — without before and after values do not count as evidence: mark
them as needing verification. Absolute numbers ("~600 scenarios")
do not fall under this rule.
— Put the note "candidate's contribution not visible" and the authorship question only where
the resume text does not name the candidate as the one who did it: "we", "the team",
"we managed to", "our team" — or a result without an actor
("reduced from … to …", "was implemented"). The numbers may be true, but
the person's role in them may not be; this is a screening question, not an assessment. If the candidate
writes about themselves with "I" — "I built", "I set up", "I designed" — do not
question authorship. And the other way round: if there is a basis, put the note on everyone
who has it. The authorship question can't go to one candidate and
skip another with the same wording. This also applies to the column
"Hypothesis to verify": a hypothesis about authorship is made only on a
textual basis, not because the result looks too big for this
candidate.
— If a resume is unreadable or data is missing, say so directly instead of
filling it in.
Here is what this prompt returned on five synthetic resumes for the Middle Python Developer job posting. This is an excerpt: the full table has eight requirement columns — experience, Django/FastAPI, databases, indexes, Git, CI/CD, Docker, English — plus risks and hypothesis. Shown here are the two columns that best show the difference between a fact and words.
| Candidate | Django / FastAPI | Indexes and query optimization | Hypothesis to verify |
|---|---|---|---|
| Candidate-009 | yes | "Product search and filtering service on FastAPI: extracted it from the monolith" | yes | "Analyzed slow PostgreSQL queries with EXPLAIN ANALYZE" | Confirm or refute: the index and the N+1 removal on the catalog page, as well as the growth in test coverage, are the candidate's own work, and Docker is used in daily work rather than just listed in the skills |
| Candidate-002 | partially | "Python, Django, Flask" | from the skills list | no data | no quote — the resume is silent on this | Confirm or refute: at both jobs the backend was written specifically in Django (not Flask), with a specific relational database, and the candidate will name an example of an optimized query or index |
| Candidate-007 | yes | "Development and maintenance of services in Django and FastAPI" | partially | "Optimized system performance by 10x by reworking database queries" | needs verification | Confirm or refute: in the current position the candidate works with PostgreSQL or MySQL and will name specific before and after values for the query optimization and what exactly was changed (indexes, rewritten queries) |
| Candidate-010 | partially | "Django — pet-project level" | no data | no quote — the resume is silent on this | Confirm or refute: the candidate wrote queries specifically to PostgreSQL and understands indexes and query plans in a transactional database, and their Django knowledge is enough for a commercial web service |
| Candidate-003 | no data | no quote — the resume is silent on this | no data | no quote — the resume is silent on this | Confirm or refute: the candidate's Python pet projects include a web service on Django or FastAPI with a relational database, and the work with PostgreSQL in the payment orchestrator included query optimization done personally |
The job posting and all five resumes this run was done on are on a separate page — with copy buttons: run materials. All names, companies and dates are made up: this is a synthetic practice pack, there are no real people in it.
You have the prompt, and the data too — on the materials page. Run prompt 2 on the five candidates in your system and check not the answer but three specific places. This is the skill of the lesson: not "get a table" but know where it's weak.
The prompt covers half the task. The other half is the procedure for checking what the system returned. That's what we build next:
The prompts are already yours, no need to come back for them. And when the next module of the course comes out, we'll write to you. No weekly newsletter.