Most advice about applying for jobs is about the CV file. But when a recruiter opens a requisition in an applicant tracking system, the CV is usually not the first thing they see. They see a list, then a record, and the record is built from data the system extracted, the answers you typed into the form, and notes other people left about you.
Here is what that record typically contains, how it gets filled, and which parts of it you control.
The list view: you are one row
Open almost any requisition in a modern ATS and the starting point is a list of candidates. In many systems each row shows a handful of fields: your name, your current or most recent job title, your current employer, location, the source of the application, the date you applied, and the stage you are in. Whatever the exact layout, the point is the same: before anyone reads a word of your CV, you are a single line of text competing with every other line on the page.
That line decides whether you get clicked. A recruiter scanning a list for a "Senior Data Analyst" role is reading job titles and employers, fast. If your row says "Analyst II" because that is the internal grade your last employer used, or shows an employer field that is blank, the row looks weaker than the person behind it. A list of two hundred rows forces a decision on very little information.
A few things typically make a row stand out in a good way:
- A current title that matches, or clearly sits next to, the role being filled
- An employer name that is recognisable, or at least present
- A location that fits the job, or a clear note that you are relocating or remote
- A recent application date, since many recruiters sort by newest first
The parsed summary card
Click a row and, in many systems, a candidate record opens. Near the top there is usually a summary card or profile panel that the ATS filled by parsing your CV: contact details, current title, current employer, a work history with dates, education, and sometimes a skills list. The CV file itself is often one click further.
That ordering matters more than people expect. A recruiter can form an impression from the summary card before they open the attachment, and some will only open the attachment if the card looks promising. So the parse is not a technical detail. It is the first version of you that a human reads.
What a bad parse does
Parsers read your document and guess which text is a job title, which is an employer and which is a date. When the guess goes wrong, the card goes wrong with it. Typical failures look like this:
- Wrong current title. The parser grabs your headline, a project name, or the title from your second job and promotes it to "current title".
- Missing employer. The company name sat in a header, a text box or a second column, and the parser skipped it.
- Garbled dates. "2021 to present" becomes a single date, or two roles merge into one entry with a strange duration.
- Skills in the wrong place. A skills sidebar gets read as part of a job description, or vanishes.
None of this is visible to you after you click submit. The recruiter sees a record that looks slightly off and has no way of knowing whether the mess is the parser's fault or yours.
Screening answers sit right next to it
If the application form asked knockout or screening questions, the answers are typically stored on the same record and shown near the summary. Work authorisation, notice period, salary expectations, willingness to relocate, years of experience with a given tool: these are structured fields, which makes them easy to read, filter on and compare across candidates.
This is where a lot of applications quietly lose ground. People rush the form, then answer "years of experience" with a number that contradicts the dates on the parsed card, or leave an optional free-text box empty. When the screening answers and the parsed history disagree, the recruiter sees two different stories side by side on one screen.
The form is not a formality. In many systems, what you type into it is the most structured, most readable part of your record.
What gets attached to you that you never see
A candidate record is not static. Once you are in the system, people start adding to it, and none of it is visible from the candidate side.
Tags, ratings and scorecards
Recruiters often tag candidates so they can find them later: by skill, by language, by "strong backup for the London role", by whatever taxonomy the team uses. Hiring managers and interviewers may fill in scorecards or ratings after a screen or an interview. In systems like Greenhouse or Lever, structured interview feedback is a well-known part of the workflow, though how it is displayed varies from one setup to the next.
Internal notes
Free-text notes are the most human part of the record. A recruiter might write that you were sharp on the phone, that your salary expectation is above band, or that you asked to be considered for a different team. These notes stay with the record. If you apply again later, whoever opens your record may see them.
Every interaction with a hiring team can end up written down somewhere you will never read. Being polite and consistent is part of your file.
Source attribution and why it matters
Most ATS record where an application came from: a job board, the company careers site, an employee referral, an agency, a sourcer who found you on LinkedIn. That source usually appears on the list view and on the record.
Source affects how a record is treated. A referral is often handled with more care, because an employee vouched for you and is waiting to hear back. An agency submission may come with fee terms attached, which means some companies look harder at agency candidates or check whether you were already in the system before the agency sent you.
You do not always choose the source, but you can avoid muddying it. If a friend is referring you, let the referral go in first instead of applying through the careers page the same day. How duplicate records are created and merged is a topic of its own; here the point is just that the source field is visible and people read it.
Your history follows you
Many systems keep an activity timeline on the record: previous applications, stages reached, emails sent, interviews scheduled, rejection reasons. When you apply to the same company a second time, the recruiter can typically see that you applied before, for which role, and how far you got.
That cuts both ways. Reaching a final round last year is useful context and often a reason to look at you again. Applying to eight unrelated roles in a month can read as unfocused. A rejection reason coded as "salary" may be outdated, but it stays there until someone updates it.
What you actually control
You cannot see your record, and you cannot edit the notes or tags. But a good part of what the recruiter reads first comes directly from you. Focus there.
- The fields you type into the form. Fill in current title, employer and location by hand, even if the form offers to autofill from your CV. Check them before you submit. Answer screening questions so they match your CV dates exactly.
- A title that matches the market. If your internal title is obscure, use the recognisable equivalent on your CV and in the form, and keep it the same everywhere, including LinkedIn. Consistency between the form, the CV and your profile is what makes a record look trustworthy.
- A clean parse. Use a single-column layout, put the job title, employer and dates on consistent lines for each role, keep contact details out of headers and footers, and export a text-based PDF or DOCX. If a tool like Postulit builds your CV from your LinkedIn profile, check that the titles and dates come through the way you expect.
- The first lines of the CV. Your most recent role is what the parser is most likely to promote to the summary card. Make sure its title, employer and dates are correct and easy to read.
Before your next application, take your CV and paste it into a plain text editor. If the first ten lines do not clearly show your current title, your current employer and the dates, the parser is going to struggle, and the recruiter will see that struggle in your row.