TL;DR: The job is making it safe and fast for other engineers to ship and operate their services: building the paths they use, running the platform underneath, and carrying a pager for it. Answer in terms of who you serve and what you own, then mention tools as the means.
How to approach it
Understand what is being screened. An interviewer asking this is separating people who understand the role from people who have read a tools list, and the tell is whether your answer contains a customer. Describe a realistic week rather than a philosophy, and be honest that plenty of it is unglamorous.
A strong answer
The clearest framing: your users are other engineers, and your product is the path from their laptop to production and the platform their code runs on. Everything else follows from that.
A realistic week has four kinds of work.
Building and maintaining the delivery path. Pipelines, build tooling, deployment mechanics, environments. Not writing a pipeline once, but keeping forty of them working when a base image changes, a dependency moves, or a certificate expires. A large part of this is removing a step somebody currently does by hand.
Infrastructure as code. Provisioning and changing cloud resources through Terraform or its equivalent, reviewing other people's plans, and dealing with the estate that predates the code. This is more review and more archaeology than greenfield authoring.
Operating and improving reliability. Being on call for the platform, running incidents, writing the postmortem, fixing the alert that fired at 3am for something nobody can act on. If the role has a pager, this is the part that shapes the week most, and it is the part candidates ask about least.
Supporting other teams. Answering "why is my pod not starting", helping a team set up their monitoring, explaining why the pipeline failed. This is a bigger share of the job than most job descriptions suggest, and treating it as an interruption rather than as the work is a common way people are unhappy in the role.
Then say what it is not, briefly, because that also demonstrates understanding. It is not a separate team that deploys other people's code, which is the old release-engineering model the whole idea was a reaction to. It is not only automation; a lot of the value is in standards, defaults and making the safe path the easy one. And the title covers quite different jobs: at one company it is cloud infrastructure, at another it is CI/CD tooling, at another it is what an SRE does. Asking which of those this role is, is a good question to ask back.
On culture, if you want to say something about it, keep it grounded: the point is that the people who build a service are involved in running it, so the feedback from operating it reaches the people who can change it. That is what shared ownership means practically, and it is more useful than reciting a three-letter acronym.
If you have done the work, anchor the answer in it. "In my current role that means about half my week on our Jenkins and Terraform, a quarter on call and incidents, and the rest helping the application teams, mostly with Kubernetes questions." A concrete breakdown is more convincing than any definition.
What interviewers probe next
"What is the difference between DevOps and SRE?" SRE is a specific implementation with defined mechanisms: SLOs, error budgets, a cap on toil. DevOps is the broader idea about shared ownership between building and running. In practice the job titles overlap heavily and the useful distinction is whether the team has error budgets that actually stop releases.
"What part of it do you like least?" Answer honestly. Interrupt-driven support work, or being on call, are normal answers, and what matters is what you do about it: batching support into a rotation, or fixing the alerts that cause the pages.
"Where do you think you would struggle here?" Name something real and say how you would close it. A career changer who says the scale is larger than they have operated, and then describes how they would ramp, is more credible than one with no gaps.
Common mistakes
Answering with a tools list, which is the response this question exists to filter.
Describing it as a team that deploys code for developers, which is the model DevOps was a reaction against.
Reciting culture slogans with nothing operational attached.
Leaving out on-call and support, which is most of the week in many of these roles and the part you are consenting to.