Can you see what an ATS knows about you?

What did the Amazon inference page story actually reveal?

In early October 2026, shoppers found a page inside their Amazon accounts listing the characteristics the company had inferred about them from their purchase history — and the assumptions were oddly personal. One shopper posted on Threads that they were "literally speechless" after discovering the page, which surfaced inferred physical traits and preferences nobody had ever typed in. The page itself wasn't new or secret; it exists because privacy rules in several jurisdictions require companies to show people the data they hold. What made it go viral was the gap between what shoppers thought they'd shared and what the algorithm had quietly concluded.

That gap is the whole story, and it's not limited to shopping. Any system that ingests your behaviour builds a model of you that goes well beyond what you submitted. Buy a particular pair of jeans and a retail algorithm guesses your body shape. Upload a CV and an applicant tracking system guesses your seniority, your salary band, your industry, your years of experience, your willingness to relocate and whether you're a "job hopper". None of those are things you wrote. All of them can decide whether a human ever opens your file.

The uncomfortable part for job seekers is the asymmetry. Amazon's page is a consumer-facing feature you can click through in a minute. The equivalent profile inside a hiring system sits behind an employer's account, governed by their data retention policy, and you only glimpse it if you formally ask — or if you reverse-engineer what the parser saw by checking your own CV first. That's the bridge this article walks: what the hidden hiring profile contains, how to demand a copy where the law allows it, and how to control the inputs when it doesn't.

What data does an ATS actually store about you?

An ATS stores far more than the PDF you uploaded. A typical candidate record holds your parsed CV broken into structured fields — name, contact details, each job title with start and end dates, each employer, education, skills — plus the original file, your application form answers, knockout question responses, source (job board, referral, careers page), every role you've ever applied to at that company, email and message history, interview feedback, recruiter notes and tags, and in many configurations an automated ranking or match indicator produced when your CV was compared against the requisition.

Then come the derived fields, which is where it gets interesting. Parsers compute totals you never stated: cumulative years of experience, average tenure per role, gaps between end and start dates, a seniority classification inferred from your titles, and a skills list extracted from your bullet points rather than your skills section. Some systems normalise your job titles to an internal taxonomy, so "Growth Lead" becomes "Marketing Manager II" and your actual scope disappears. Others geocode your address to filter by commute distance. You didn't write any of these values, but they're what gets filtered and sorted.

Retention matters as much as content. Employers typically keep rejected-candidate records for six months to two years, and many large organisations keep them longer in a talent pool so recruiters can resurface you for future roles. That means the profile built from the CV you sent in 2023 — including whatever the parser got wrong about your dates — may still be the first thing a recruiter at that company sees in 2026. Inaccurate derived data doesn't quietly expire. It compounds, which is exactly why the first fix is the file itself.

Can you legally request your ATS candidate profile?

Yes — if you're in the UK or EU, or you applied to a company covered by California's privacy law. Under the UK and EU GDPR you have a right of access: you can ask any employer that processed your application for a copy of the personal data they hold on you, and they must respond within one month, extendable to three for complex requests. California's regime gives applicants a similar right to know what categories of personal information a business collected and to request the specific pieces. Job applicants are explicitly covered — recruitment data isn't carved out.

What you can expect back is a mix of neat and messy. Well-run employers export the candidate record from their hiring system and send a structured file: your parsed fields, application timeline, assessment results, and in many cases the recruiter notes and internal comments attached to your profile. Notes about you are your personal data, and the fact that a recruiter found them awkward to write isn't a lawful reason to withhold them. Employers can redact information that identifies a third party, and in the UK they can withhold confidential references, but blanket "it's internal" refusals don't hold up.

Scores are the contested ground. Where a system produced an automated ranking or a knockout decision, GDPR also gives you a right to meaningful information about the logic involved in automated decision-making, and a right not to be subject to a purely automated decision with significant effects without human involvement. In practice employers often argue a human reviewed the shortlist, which takes the decision outside the strictest protections — but you can still ask what factors the ranking used. Outside these jurisdictions, including most of the US and Israel, you generally have no equivalent right and asking politely is your only lever.

How do you actually file a data access request to an employer?

Email the employer's data protection officer or privacy address — usually privacy@ or dpo@ the company domain, and listed in the privacy notice at the bottom of their careers page. Write one short paragraph: state that you're making a subject access request under the UK or EU GDPR (or a request to know under California law), give the email address and name you applied with, list the roles and approximate dates, and ask for the full candidate record held in their applicant tracking system. Keep it factual. You don't need to explain why you want it, and you shouldn't — a reason gives them something to argue with.

Be specific about what you want included, because vague requests get vague answers. Ask for: the parsed data fields extracted from your CV; all application and stage history including rejection reason codes; any automated score, ranking, matching output or knockout result; all recruiter notes, tags and interview feedback associated with your profile; the identity of any third-party assessment or screening provider involved; and the retention period applied to your record. Request it in a readable electronic format. If a month passes with no response, send one chaser referencing the deadline, then escalate to the relevant data protection regulator — complaints are free and employers take them seriously.

Set expectations honestly: this is forensic, not tactical. By the time the export lands you've long since been rejected for that role, and the response won't reopen it. Where a request genuinely pays off is diagnosis — seeing that a system recorded your eight years of experience as three, or that it pulled the wrong job title, tells you your CV's structure is failing before anyone reads it. That's a problem you can fix once and benefit from on every future application. Many people file one request in their career, learn one structural lesson, and never need another.

How does an ATS parse your CV, and what does it get wrong?

A parser reads your file as a stream of text with coordinates, then uses pattern matching and trained models to decide which chunk is a job title, which is an employer, which is a date range, and which is a skill. It never sees your layout the way you do. Reading order is determined by how the text is encoded in the file, not by visual columns, so a two-column CV frequently interleaves your sidebar skills with your work history. Text inside images, icons, text boxes, headers and footers is often skipped entirely — which is how people lose their phone number without knowing it.

The failures are predictable and boring. Dates written as "Mar '22 – Present" or with en dashes in unusual encodings get misread, which corrupts every tenure and gap calculation downstream. Job titles stacked on the same line as a company name confuse field assignment. Non-standard section headings like "Where I've Made an Impact" mean the parser can't find your experience block at all. Skills buried only in prose sometimes get extracted and sometimes don't. Right-to-left Hebrew CVs add their own layer: if the PDF's text extraction reverses character order or mangles the file, the whole document can arrive as unusable noise.

The fix is unglamorous and reliable: one column, standard headings — Experience, Education, Skills — consistent full-month-and-year dates, no tables for layout, real text rather than graphics, and a file saved as a text-based PDF rather than an exported image. If you want to see what a parser pulls from your current file before an employer does, upload it for a free CV check and read the ATS compatibility score and layout analysis. If your CV is a designed template, the specific traps in two-column and graphic layouts are worth reading in full.

What can you control before the system builds a profile on you?

You control the inputs, and the inputs determine almost every inference. Write the numbers you want calculated rather than leaving them to be derived: if your experience totals nine years across contracts and freelance work, say "9 years" in your summary instead of hoping a parser adds it up correctly. Spell out the job titles you want recognised, using the language of the job ad rather than an internal company label — "Senior Backend Engineer" survives screening; "Technical Owl, Tier 3" doesn't. Where a gap exists, label it plainly with dates, because an unexplained gap gets inferred less generously than a stated one.

Tailor the keywords to each requisition, but tailor honestly. Recruiters search their candidate database using the terms in the job description, so a skill you genuinely have but phrased differently — "PostgreSQL" versus "Postgres", "SIEM" versus the product name — can make you invisible. Paste the job ad into an analysis and look at what's flagged as missing; then add only what's true, in the ad's wording, in context. Keyword stuffing in white text or a hidden block is the one tactic worth avoiding outright: it's trivially visible in the extracted text, and it reads as deceptive the moment a human looks.

Then verify before you send, not after. A free HRLens analysis gives you a score out of 100, five category scores including ATS compatibility, your strengths and a visual layout analysis, so you can see how automated screening reads the file. The $3.99 Full Analysis adds the fix list, the blind spots, "why you might be rejected", a hiring-probability estimate and a salary estimate; every analysis also produces ATS-friendly rewrites in six templates that mirror the job's keywords. If you'd rather rebuild from scratch, the chat-based CV builder writes Hebrew CVs in Hebrew and exports them right-to-left.

Frequently asked questions