What recruiters actually look at in a DevOps candidate profile

Most DevOps candidates optimise their CV, GitHub, and LinkedIn for an audience that does not exist. They picture a thoughtful reader working through every bullet, cross-referencing their AWS badges, appreciating the nuance of the three-year tenure at a mid-market fintech. That reader is not coming.

What is coming is a recruiter with fifty other profiles in the queue, an applicant tracking system trained on keywords, and - if you make it through the first cut - a hiring manager with twenty minutes before their next meeting. Each of them looks for different things. None of them reads what you think they read.

This post is a reality-check on how a DevOps or SRE profile is actually screened, where the six seconds go, and what senior hiring managers say they look for when they are honest about it. If you only have two hours to spend on your profile this month, it will tell you where those two hours are worth spending and where they are not.

The six-to-eight-second first pass

The most-cited recruiter figure in the last decade is TheLadders' eye-tracking study: six seconds on a CV. A follow-up put it closer to seven or eight. Debate the exact number if you want - it does not change the conclusion. A first-round recruiter is not reading your CV. They are scanning it.

In those seconds, they are checking, roughly in order:

1. Your current or most recent title.
2. The name of your current or most recent employer.
3. How long you have been there.
4. Whether a keyword from the job description appears near the top.
5. Whether anything disqualifying jumps out - a three-year gap with no explanation, a typo in the first line, a title that does not match the role.

That is the first pass. If you survive it, you get a second pass of thirty to sixty seconds where more bullets get read. If you survive that, you get a call.

The uncomfortable implication: the bottom two-thirds of your CV is rarely read in the first pass. The "Interests" section is never read. The second page is almost never read. The paragraph at the top of your LinkedIn profile that starts "passionate about cloud-native technologies" is ignored by every human who has ever seen it.

If you design your profile around the six seconds, you design it differently.

What gets scanned versus what gets ignored

Stop writing for the reader who is not coming. Write for the one who is.

Scanned:

• The top inch of your CV. Role, company, dates.
• The first bullet under each role.
• Keywords the ATS was told to look for (usually from the JD).
• The name of any tool or platform in a bold font, a section header, or a skills block.
• The URL of your GitHub, if it is a link (they click maybe one in ten, but they check for a pulse).
• Whether your LinkedIn headline says what you do or says "DevOps Engineer | Cloud Enthusiast | Lifelong Learner."

Ignored by the first-pass recruiter:

• The objective statement.
• The "soft skills" bullets (communication, teamwork, leadership, problem-solving - everyone claims all of them).
• Years listed in a skill bar. Nobody believes the bar. Nobody benchmarks "4 years of Docker" against "6 years of Docker."
• Self-rated proficiency (Expert, Advanced, Intermediate). These are meaningless without a test behind them.
• Certifications that are not on the JD. The recruiter does not know what a Terraform Associate is unless someone told them to look for it.
• The hobbies section. Really.

The recruiter is not being lazy. They are rational. They have forty-nine more profiles after yours, a shortlist due by end of day, and no way to verify any claim you make. They optimise for low-cost signals that a human in a hurry can read.

The signal gap

Most DevOps candidates spend their profile-improvement effort on things that do not move the needle:

• Adding more bullets to old roles.
• Rewording the objective.
• Inflating years of experience by half a year here, half a year there.
• Listing every tool they have ever touched, including ones they used once in a bootcamp.
• Adding another unverified certification to the pile.

None of these change the outcome. The ATS already knows you have "Kubernetes" on your CV because you put it in a skills block. Adding it three more times does not make the filter more confident. Adding a tool you do not actually know gets you into an interview you will fail.

The gap is between what candidates think distinguishes them (prestige, tenure, breadth) and what a hiring manager actually distinguishes on (depth, specificity, ownership).

A four-year tenure at a name-brand company with vague bullets beats a one-year tenure at an unknown company with vague bullets for the first-pass recruiter. It does not beat a one-year tenure with specific, dated, traceable work for the hiring manager. The hiring manager is the person who signs off. The recruiter just moves the pile.

The question is not "how do I impress the recruiter." It is "how do I give the recruiter a reason to forward me to the hiring manager, and give the hiring manager a reason to say yes."

What senior hiring managers actually look for

When you get past the first two filters, the person on the call is usually a staff engineer, engineering manager, or head of platform. They ignore most of what the recruiter scanned. They are reading for evidence of four things:

1. Specificity. Can you name a system, a problem, a decision, a number? "Reduced deploy time by 40%" is specific. "Improved CI/CD pipelines" is wallpaper.
2. Ownership. Did you drive a change or were you standing next to one? Post-mortems you wrote, incidents you led, tools you introduced, architectures you chose - these all signal ownership. "Part of a team that..." does not.
3. Judgement. Can you articulate a tradeoff? When did you pick the boring answer? What did you reject and why? Candidates who cannot answer "what would you not use Kubernetes for" have usually only used Kubernetes.
4. Honesty about failure. What did you get wrong? What did you ship that did not work? Every senior engineer has a list. Candidates who do not have one have either not shipped much or are not being honest.

Notice what is not on that list: your title, your employer, your certifications, your years of experience. None of those are irrelevant, but they are table stakes - they get you to the interview, not through it.

The ATS gap

The ATS is not the hiring manager. This is obvious, but most candidate advice blurs the two.

The ATS is a keyword-matching engine with a confidence threshold. It is the reason your CV needs "Kubernetes" written out as a word (not just a logo), "AWS" in the skills section (not just "cloud"), and "Terraform" spelled the way the JD spells it. It is why candidates with identical skills can have wildly different pass-through rates depending on whose profile mirrors the JD vocabulary.

Optimising for the ATS is necessary. It is also not sufficient. Candidates who only optimise for the ATS end up in the interview and have nothing specific to say, because the specific things were cut to make room for the keywords. The right approach is a CV that passes the ATS and gives the hiring manager something to read. That usually means fewer bullets, denser ones, with a keyword per bullet rather than a keyword per line.

If your bullet reads "Deployed containerised microservices to a managed Kubernetes platform using a CI/CD pipeline," you have keywords and no content. If it reads "Moved 14 services from EC2 to EKS over 9 months, cutting deploy time from 22 to 4 minutes and reducing monthly AWS spend by £6k," you have both.

Practical implications

For a DevOps or SRE candidate looking at their profile on a Sunday evening, here is where the hours go:

CV (one page, ideally).

• Top third: current role, clear title, employer, dates. No objective.
• Every bullet has a verb, an object, a number, and - ideally - a tool. If any of those is missing, rewrite it.
• Skills block is a flat list of tools you can be asked about on a call. Not a bar chart. Not a rating.
• Remove anything you do not want to be asked about in an interview. If it is on the CV, it is fair game.

GitHub.

• Pin three to five repositories that show real work. Homelab setups, personal Kubernetes clusters, infra repos, tool contributions.
• Commit messages are read. Make them readable.
• A short README on each pinned repo with the "why" and the "what I learned." Not a tutorial.
• Contributions to tools you actually use - docs fixes, small bug fixes - are worth more than another side project.

LinkedIn.

• Headline says what you do. "Platform Engineer at X, focused on Kubernetes and developer experience" beats "DevOps | SRE | Cloud | Kubernetes | AWS | Azure | GCP | Terraform | Ansible | Python."
• The About section is one paragraph, not five. It says what you work on, what you have shipped, and what you are looking for.
• Experience bullets match the CV. Recruiters cross-reference.
• Skip the endorsements count. Nobody looks at it.

SkillBricks wall.

• A wall is the evidence layer behind the CV. It condenses what a hiring manager would otherwise have to piece together from your GitHub, your blog, and your references into a single verified record of real-environment work. Recruiters see a tier, a process signal, and the brick history; candidates stay anonymous until they decide otherwise.
• It is free for candidates forever. That is not a sales line - it is the model.

The boring meta-point

Most candidate advice optimises for the thing the candidate wishes were true: that a thoughtful reader is studying the profile, weighing every bullet, appreciating the arc of the career. They are not. The recruiter has six seconds. The ATS has a keyword list. The hiring manager has twenty minutes and is reading for four specific things.

Design for that, not for the reader who is not coming.

If you want to see how SkillBricks fits into this picture, the how it works page is the short version. If you would rather read more on hiring, the rest of the blog is one click back. Either way, the Sunday-evening rewrite is still worth doing.