Screen the claim, not the keyword. For every infrastructure claim on a DevOps or SRE resume, look for four things: a baseline, the change, the candidate's own part, and some way to check it. Most of this work lives in private repositories and internal systems, so a public GitHub profile will rarely prove it. The proof has to come from how the resume is written and from first-call questions that make the candidate reconstruct their own decisions. A resume that states numbers with a baseline, a scope and a personal role earns an interview. A resume that lists tools and adjectives has not yet produced evidence. If you screen with HyreTech, write those four tests into the role's scoring criteria: the score ranks every resume against them, and a person still checks the claims on the call.
This guide is for HR teams and recruiting agencies in Singapore, Indonesia, Australia and New Zealand who hire DevOps and SRE engineers but do not write infrastructure code themselves. It covers how to read resume claims and what to ask on a first call. It does not replace a technical interview, and it does not tell you how to weight a rubric.
For weighting, see how the match score is built. For what a GitHub profile can and cannot show, see our guide to AI analysis of GitHub profiles.
Titles also vary. One company's DevOps engineer does the work another company calls SRE, so we say "DevOps and SRE" together throughout and focus on what the person did rather than what the title says.
The example resume lines below are invented for illustration. They are not benchmarks. We checked the DORA and Google SRE sources cited here on 18 October 2026.
Why Public Code Rarely Proves Infrastructure Work
Infrastructure work leaves different traces from application work. The artifacts are pipeline definitions, cloud account configuration, alert rules, dashboards and runbooks. Nearly all of it sits in private organisation repositories or inside vendor consoles that nobody outside the company can open. The outputs are also outcomes rather than code: a deploy that takes less time, a service that stayed up, an incident that did not repeat. Very little of that would ever be open sourced.
This is true of software work in general. GitHub's Octoverse 2025 report counted about 81.5% of contributions on GitHub in private repositories, which is why a thin public profile is neutral, not negative.
For DevOps and SRE roles the logic applies even more strongly, because the pipeline and infrastructure code that would prove the work is exactly what a company keeps private. Public work still counts when it exists. A recent, original Terraform module, Helm chart or contribution to an open-source operations tool is a strong signal. Its absence tells you nothing.
That shifts the burden to the resume text and the first conversation, which is where the rest of this article focuses.
What Counts as Evidence on a DevOps or SRE Resume
We suggest a four-part test for every infrastructure claim:
- Baseline. Where did things stand before the work?
- Change. What exactly was done?
- Own part. Did the candidate lead it, build it or contribute to it?
- Checkability. Is there a number, a measured system or a story the candidate can walk through?
Here is the difference in practice, using invented lines:
- Weak: "Improved CI/CD pipeline and reduced deployment time using Jenkins, Docker and Kubernetes."
- Stronger: "Cut median pipeline time for the payments API from 38 to 14 minutes by caching builds and splitting test stages. Team of six, I owned the redesign."
The weak line names tools and claims an improvement. The stronger line gives a baseline, a result, a scope and a personal role. It may still be exaggerated, but it can be checked in a conversation. That is the standard to apply.
Numbers also need context. DORA, a research program run by Google Cloud, identifies five software delivery performance metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
DORA says the metrics are best suited to measuring one application or service at a time, and that comparing very different applications or blending teams together can mislead. So a resume line like "improved our DORA metrics" is incomplete until it says which service, which metric, and what the candidate personally did. These are team outcomes.
Two more points from DORA help a non-engineer reader. DORA's research finds that speed and stability are not trade-offs, and the metrics tend to move together.
A claim about shipping faster with no mention of stability is therefore incomplete rather than suspicious, and a good question to ask is what happened to failures. DORA also warns that setting the metrics as targets invites gaming, so a number alone proves little. Ask how it was measured and by whom.
Claim, Evidence and Question: a Reading Table
This table is our suggested practice, built on the DORA and SRE vocabulary used in this article. It is not a standard. Use it to read each line of a resume and to pick one question for the first call.
| Resume claim | What a credible version includes | Red flag | One question for the first call |
|---|---|---|---|
| Faster deployments or an improved CI/CD pipeline | A baseline and a result for change lead time or deployment frequency, the scope (one service or many), and what changed | A speed claim with no stability figure, or pipeline tools listed with no outcome | "What was lead time before and after, and what kept failed deployments from rising?" |
| High uptime or reliability, such as "99.9%" | The indicator being measured, the target set for it, and who chose it | An availability figure with no definition of what was measured | "What was the SLI behind that number, and how did the team pick the SLO?" |
| Fewer incidents or faster recovery | Before and after figures over a stated period, plus the specific fix | "Zero incidents" or a drop with no cause | "Which incident changed how the team worked, and what changed afterward?" |
| Led a migration (cloud, Kubernetes, data centre) | Number of services or environments, duration, rollback plan, what was retired, and the candidate's exact role | "Participated in" rewritten as "led", or tool names with no scale | "When a migration step failed, did you roll back? What did you do?" |
| Built monitoring and alerting | What it alerted on, how noisy alerts were tuned, and which incidents it caught | A count of dashboards with no decision they supported | "Which alert paged you most, and what did you do about it?" |
| On-call and incident response | Rotation size, hours covered, role (responder or incident lead), postmortems written | "On-call experience" with no description | "Walk me through your last page. Did it get a written postmortem?" |
| Infrastructure as code ownership | What was managed in code, how changes were reviewed, how a bad change was undone | A tool name on its own | "How does a change reach production, who reviews it, and how do you undo one?" |
| Cost reduction | Baseline spend, scope, and what reliability or speed was traded for it | A percentage saving with no baseline | "What did you give up to get that saving?" |
DevOps and SRE are Not The Same Resume
Titles overlap, so read the verbs. Words like built, configured and migrated usually describe delivery work. Words like operated, responded, owned a target and wrote postmortems describe operations work. Strong candidates often show both, but the balance tells you what the person has actually done.
SRE resumes have a vocabulary you can test. Google's SRE book defines a service level indicator (SLI) as a carefully defined quantitative measure of some aspect of the level of service, and a service level objective (SLO) as a target value or range for a service level measured by an SLI.
A service level agreement (SLA) is the contract with users that sets consequences for meeting or missing those objectives. The same chapter says choosing targets is not a purely technical decision, and that insisting on meeting an SLO 100% of the time is unrealistic. A candidate who writes "99.99% uptime" should be able to say which indicator sat behind it and who set the target. If the answer is vague, treat the number as unverified. A claim of 100% uptime deserves the same question.
If the role covers teams across Singapore, Indonesia, Australia and New Zealand, ask about hours covered and handover too. Jakarta (UTC+7) and Auckland (UTC+12, or UTC+13 in the New Zealand summer) are only five to six hours apart. A team spread across the region gets a longer working day, not true follow-the-sun cover, so someone still takes the night pages. A candidate who handed over cleanly between Jakarta and Sydney every day has a different profile from one who carried the pager alone.
A Ten-Minute First Call for Recruiters Who do not Write Infrastructure Code
You do not need to judge technical depth on this call. You are listening for structure: does the story have a baseline, an order of events and a personal role? Five questions cover most of it:
- "Describe the last time you were paged. What was the impact, and what did you do first?" A usable answer states who or what was affected and the first action, in order.
- "Did it get a written postmortem? Which action items were yours, and did they ship?" Google's SRE book describes a postmortem as a written record of an incident, its impact, the actions taken, the root causes and the follow-up actions. A usable answer names a concrete follow-up and describes causes without blaming a person.
- "Pick one number on your resume. What was it measured against, and who measured it?" A usable answer names a baseline and a source such as monitoring, the pipeline or an incident tracker.
- "What did you do personally, and what did the team do?" A usable answer separates the two without difficulty.
- "What would you do differently?" A usable answer is concrete. "Nothing" is not.
Some things are not red flags. A candidate may be unable to name internal systems or clients because of confidentiality, so listen for structure rather than secrets. A thin public GitHub is neutral. A candidate who describes many postmortems is not a problem either, since the SRE book says frequent postmortems from a person or team should not be stigmatised. The warning signs are stories where "we" never becomes "I" and numbers with no source.
If the call goes well, the next step is a technical interview, which we cover in our guide to structured technical interviews. Contract stints are common in infrastructure careers, so see overlapping jobs on a resume when dates look odd.
Where Screening Software Helps and Where it Stops
Software can only read what is written. In HyreTech, a role's scoring criteria are drafted from your job description, and you can rewrite, add, delete or reweight them at no cost. Each criterion gets its own score and a written reason, and the match score is their weighted average (see how weights become a score).
HyreTech labels each applicant Shortlist, Consider or Reject from that score, but it never changes a candidate's status or sends a rejection on its own. A person on your team moves every candidate.
For DevOps and SRE roles, write the criteria as evidence tests rather than tool keywords. Put the whole test in the criterion's name, because the name and its weight are what the scorer reads. The optional description is a note for your team and is not scored. For example:
- States a baseline and a result for at least one infrastructure change
- Describes personal ownership of on-call or incident response
- Names the scale of systems operated, such as services, environments or traffic
- Shows infrastructure as code ownership beyond naming the tool
Set the criteria before the first batch. Edits apply to resumes analysed afterwards, and re-analysing a resume that was already scored costs one credit.
When a resume links a GitHub profile, HyreTech reads up to 50 of its public repositories (language, stars, topics and when each was last updated) and the pull requests merged into other people's projects, and gives that summary to the scorer as supporting evidence (see how that enrichment works). It does not read code or private repositories, and a missing profile is not held against anyone. For infrastructure roles, expect it to add little, which is the point of this article.
The limit matters. A score cannot verify that a number is true, and a polished resume can score well. The trust score, on Growth and above, checks timelines and consistency, such as a technology listed before it existed or a resume that contradicts the same candidate's other applications in your workspace. Nothing in it flags an inflated figure, and specific, numbered achievements count in a resume's favour. The first call and the technical interview do the verifying.
Put The Evidence Test Into Your Next Role Brief
The simplest change is upstream. Before you open the next DevOps or SRE role, write the four-part test into the brief and turn the reading table into your criteria. Then every resume gets read against the same questions, and your first calls start from the same place.
To run it on a live role: start free. The free plan includes one active role and a one-time grant of 20 credits, and one credit analyses one resume.
If you place infrastructure engineers across Singapore, Indonesia, Australia and New Zealand and want help setting up the criteria: book a demo and we will walk through it on one of your open roles.
FAQ
How can an HR team that cannot read Terraform or Kubernetes screen DevOps resumes?
Turn each requirement into an evidence test instead of a tool keyword: a stated baseline and result, personal ownership of on-call, and the scale of the systems operated. Read the strongest claims against a claim-and-question table and pick one question per claim for the first call. In an AI screening tool such as HyreTech, put each test in a criterion's name so every resume is scored against it. A person still decides who moves forward.
Is a DevOps engineer with no public GitHub a weaker candidate?
No. Pipeline definitions, infrastructure code and alert rules almost always live in a company's private repositories, so a thin public profile is neutral. A recent, original Terraform module or Helm chart is a positive signal when it exists, but its absence should not lower a candidate's standing.
What is the difference between a DevOps and an SRE resume?
Titles overlap between companies, so read the verbs. Delivery verbs such as built, configured and migrated point to DevOps-style work. Operations verbs such as operated, responded and wrote postmortems point to SRE-style work. An SRE resume should also be able to explain the indicator and target behind any uptime figure.
What numbers should a DevOps or SRE resume include?
A baseline, a result, a scope and a period. DORA's five delivery metrics (change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate) are useful vocabulary, but none is mandatory. A line like "cut pipeline time from 38 to 14 minutes on one service" is more useful than a vague percentage.
Can a candidate share incident details without breaking confidentiality?
Yes. They can describe the structure of an incident without naming clients or internal systems, and a good recruiter listens for impact, order of events, personal role and follow-up actions rather than secrets. Do not read a high number of postmortems as a negative, since Google's SRE book says frequent postmortems should not be stigmatised.
Can resume screening tell a strong SRE from someone who writes a good resume?
Not by itself. Screening, including ours, reads what is written, so a well-written resume can score well even if the claims are exaggerated. Its value is making sure every resume is read against the same evidence criteria. The first call, a technical interview and reference checks are what verify the work.