"SRE" and "DevOps" get used interchangeably, but they answer different questions. DevOps is a culture — the idea that the people who build software should also run it, tearing down the wall between dev and ops. SRE (Site Reliability Engineering) is a specific implementation of that idea, with concrete practices and metrics. The line people quote: "SRE is what happens when you ask a software engineer to design an operations function."
DevOps: the philosophy
DevOps is about flow and ownership — automate the pipeline, ship small and often, and make the team that writes the code responsible for its uptime. It deliberately doesn't prescribe tools or job titles; it's a set of values (collaboration, automation, fast feedback) more than a rulebook.
SRE: the prescriptive version
SRE takes those values and adds hard numbers. The defining tools are SLIs/SLOs (you measure reliability as a target, e.g. 99.9% of requests succeed) and the error budget — the small amount of failure that target permits. Burn the budget and feature work pauses to fix reliability; stay under it and you're free to ship. SRE also caps "toil" (manual, repetitive ops work) so engineers spend time automating instead of firefighting.
So which does a job posting mean?
In practice most "DevOps Engineer" and "SRE" roles share the same day job: build CI/CD, manage infrastructure as code, run on-call, and debug production. SRE postings lean harder on reliability metrics, distributed-systems depth, and incident response; DevOps postings lean toward pipelines and tooling. Both expect you to be calm and fast in a real terminal when something is on fire.
Build the shared skill
Whatever the title, the interview will test whether you can actually fix a live system. Practise that core skill with a full incident response shift, sharpen your fundamentals with Linux troubleshooting, and rehearse the format itself with SRE interview practice.