Company folders give practice a starting point
DevOps-Interview-Guide helps candidates choose a reported interview and practise explaining their answers. The README describes questions collected from DevOps, SRE and cloud engineering interviews in 2025 and 2026. It claims 151 interview write-ups across 85 companies, plus an Others folder. Those are README counts, not counts independently verified by our run.
The organization matters more than the total. Each file represents one interview experience. Separate reports from the same company remain separate, and role names appear in filenames when the original submission specifies them. A default DevOps_Engineer filename therefore does not establish the candidate's exact role.
The README calls the questions exact recollections without paraphrasing. That is the project's claim. Neither the README nor the two supplied interview extracts independently verifies the underlying interviews or establishes how representative each report is.
What the inspected questions cover
The Accenture file labels the candidate's experience as six years. Its questions include IAM access to EKS, access across multiple AWS accounts, Terraform initialization and regions, private-subnet application access, Secrets Manager and RBAC. These prompts let an interview partner ask for an operational explanation rather than a definition alone.
The Commonwealth Bank file labels the role Principal SRE and experience as four to five years. It asks about observability architecture, DNS, monitoring, traces and service indicators. One question explicitly asks for a business explanation of SLA and SLO rather than a formula.
Both supplied files contain questions without worked solutions. Some wording needs interpretation. For example, the Commonwealth Bank prompt asks, "When we have logs, why we need trace?" Practise clarifying the intended distinction before answering. These two files support an assessment of the sampled prompts, not a claim that every file has the same format or quality.
A practical rehearsal method
Choose a company folder, then select a report whose stated role and experience are relevant to you. Answer each question aloud before looking up the subject. For an access question, explain the identities, permissions and trust relationships you would inspect. For a troubleshooting question, describe the evidence you would collect and how it would change your next step.
Record the parts you cannot explain clearly, then check them against current vendor documentation or a suitable practice environment. This is a suggested preparation method; we did not measure whether it improves interview results. Use reports from several folders to avoid treating one candidate's account as a complete syllabus.
What our recorded run establishes
In our recorded run on 2026-10-10 at 03:09:59.274 UTC, the checkout was commit 997841324f307d10563ad295213da55b9bb19138 (9978413). Its recorded commit date is 2026-09-29T08:34:23+05:30. The harness reported no supported ecosystem and no Dockerfile, with an empty execution-step record.
No installation, dependency download, build, test, audit, installed-binary check or workload was executed. Tests were not recorded as failed. The not_runnable classification means the harness found no supported execution path; it does not establish a defect in a Markdown reading resource.
The stored repository metrics are 154 files, 0 code LOC and 0.2 MB. The zero code-LOC figure is a parser metric, not a claim that the repository contains no text. The detector recorded no CI configuration or tests directory, and the license signal was null. These observations do not establish the absence of every possible editorial check or resolve reuse rights. No new execution was performed for this correction.
Contribution evidence and limits
The supplied pull-request snapshot lists eight open and eight closed pull requests. Open entries include a consolidated PDF proposal dated October 10, 2026, a September file update and an Accellor submission opened August 19. This shows submitted contribution activity in that snapshot. It does not establish response times, acceptance quality, adoption or a regular maintenance schedule.
The README explains how to add one interview per file and asks contributors to include role and experience when possible. The supplied material does not establish a verification process for submissions. Treat the files as contributor reports, and establish reuse permission separately before redistributing them.
How the ratings work
These are editorial suitability ratings for an interview-question collection, not benchmark results. On the five-point scale, 1 means little usable support is established, 2 means limited support with substantial uncertainty, 3 means useful support with clear gaps, 4 means strong support for the stated task, and 5 means that task is directly supported with minimal friction. Unknown adoption or compatibility does not earn a high score.
Setup earns 5 for the documented reading task: search for a company and open a file. Docs earns 3 because the folder convention is explained, while the inspected questions lack worked answers. Community earns 2 because the pull-request snapshot establishes participation but not review responsiveness or quality. Maturity earns 2 because the collection has a clear contribution format, while verification and reuse permission remain unresolved in the supplied evidence.
When to choose another resource
DevOps Exercises is a better fit for subject-based questions and exercises. The supplied networking section includes answers, and its README explicitly warns that most questions and exercises do not represent an actual interview.
90DaysOfDevOps describes a structured way to learn DevOps foundations, principles, processes and tooling. Choose it when you need to learn the subjects before attempting interview reports. Its README also states that it will not cover everything in DevOps.
For candidates ready to rehearse, the next step is simple: open one relevant DevOps-Interview-Guide report, answer it without notes, and turn the gaps into a study list.