The last five minutes matter
"Any questions for us?" is usually treated as a formality. It is the highest-information part of the interview, because you choose what gets discussed.
Six questions worth spending it on.
"Walk me through what happens between a merged pull request and production."
You learn the deploy frequency, the amount of manual work, and whether anyone is afraid. A team that answers in one sentence has invested in this. A team that says "it depends" has not.
"What broke most recently, and what changed afterwards?"
Every team has incidents. What differs is whether anything changes. Listen for whether the answer is about a system or about a person — "we added a check" versus "he was being careless" tells you almost everything about the culture.
"How much of my first month would be spent on someone else's unfinished work?"
Some is normal and healthy. All of it means you were hired to absorb a backlog, which is a different job from the one advertised.
"Who decides what gets built, and how does an engineer disagree with that?"
The second half is the real question. Every organisation has a process for deciding. Not all of them have a route for an engineer to say "this is the wrong thing" and be heard.
"What is the oldest system I would be expected to touch, and who understands it?"
If the answer is "one person, and they are leaving", you now know what your first six months look like. That might still be a good job — but you should choose it knowingly.
"What would make you regret hiring me in six months?"
The most revealing question on the list. A team that has thought about the role gives a specific answer. A vague one usually means the role is not clearly defined, which will become your problem.
Reading the answers
Notice whether people look at each other before answering, whether the manager and the engineer give compatible accounts, and whether anyone volunteers a genuine weakness.
A team confident enough to describe its own problems is usually a team that is fixing them.