A useful pile of prompts, not a textbook
DevOps Interview Guide collects reports of questions asked in DevOps, SRE, cloud, release engineering, and adjacent interviews. The README says it contains 151 interview write-ups from 85 named companies, plus an Others folder for reports without a company. Each Markdown file represents one interview rather than a merged topic page. Multiple submissions for the same employer stay separate.
That organization is the best part of the project. A candidate interviewing at Accenture can open that folder and see prompts about AWS account access, EKS permissions, private subnets, Terraform across regions, and Secrets Manager. An Amazon consultant report asks about Kubernetes node upgrades, IAM permission boundaries, CI image creation, CNI, autoscaling, and log automation. These are better rehearsal prompts than another list of definitions because many require an operational explanation.
The collection also preserves differences between roles. A Principal SRE file for Commonwealth Bank focuses on observability architecture, DNS resolution, traces, service indicators, and explaining service objectives from a business perspective. An unnamed DevOps report moves across Git, Ansible, Terraform state, Airflow debugging, server performance, Kubernetes pending pods, and Linux filesystems. Browsing several files gives a quick picture of how wide an interview can become.
How to use it without fooling yourself
Reading a question and thinking I know that is weak preparation. Pick a file, set a timer, and answer aloud as if an interviewer can interrupt. For a scenario question, state what you would inspect first, which evidence changes your next step, and how you would limit risk. For a design prompt, make assumptions explicit and explain the tradeoff behind each service.
The repository supplies no model answers. That is inconvenient for beginners, but useful for experienced engineers who want rehearsal without being anchored to one response. After answering, check commands and provider behavior against current vendor documentation. Cloud services, defaults, and recommended practices change. A crowd-submitted question may also use imprecise wording, so part of the exercise is asking for clarification rather than guessing what the interviewer meant.
Company names should be treated as context rather than a forecast. Interview loops change by team, level, geography, and interviewer. The files do not include enough provenance to determine how representative a report is. Preparing only the listed answers would overfit to a small sample. Use the folder as a starting point, then practice the same subjects as open-ended troubleshooting and design work.
Editing and trust need work
The README promises exact questions with no paraphrasing, but the project does not document how submissions are verified. Files generally provide a company heading, sometimes a role or experience level, followed by questions. They do not show interview dates, source evidence, review status, or whether a maintainer corrected technical mistakes. Readers have to regard each entry as an unverified recollection.
Editorial quality varies. The samples include misspellings, missing words, inconsistent punctuation, and labels such as Exp-9years. Some questions contain an answer hint after an arrow, while most do not. This does not erase the value of the scenario, though it can make a technical distinction unclear. A light contribution template and review checklist would make new reports easier to compare.
The missing license is a bigger concern. GitHub reports no license for the repository, and the README does not grant reuse rights. Reading and linking to the files is straightforward. Copying the collection into a course, application, or commercial question bank is not something a developer should assume is permitted. Contributors also need to consider whether sharing a company's interview questions conflicts with agreements they accepted. The project offers no policy on that point.
What happened when we ran it
We did not execute DevOps Interview Guide at commit bbe0c45. The repository has no detected programming-language ecosystem and no Dockerfile, so our sandbox had no supported install, build, or test path. That is expected for a Markdown collection rather than evidence of broken software.
There is still room for automated quality checks. A Markdown linter could catch malformed lists and spacing. A link checker could detect dead references if sources are added later. A small schema for company, role, experience, interview date, and submission status would make the directory searchable without changing its simple reading experience. None of that exists in the measured checkout, so consumers should expect raw community notes.
Activity is current, governance is thin
The repository was pushed on 2026-08-16. A contribution for Accellor opened on 2026-08-19, and another open pull request for Razorpay was updated the same day. GitHub reported six open issues and pull requests combined; the current open list consists of pull requests adding or updating interview material. This is active collection work, even though some submissions have waited longer than others.
There are no GitHub releases. That is reasonable for a reading repository, but it means there is no stable snapshot or change summary for candidates and downstream users. The README explains the folder convention and contribution process in a few paragraphs. It does not describe editorial ownership, acceptance criteria, dispute handling, or removal requests.
DevOps Interview Guide is best used late in preparation. Learn with a structured resource, practice in a real shell or cloud lab, then use these files to expose gaps under interview-style questioning. The repository is quick to browse and unusually specific by employer, but its rawness is both the point and the limitation.