Reverse Interviewing Questions: What to Ask About On-Call and Team Health

You accept a job based on the title and the salary, then learn the real working conditions after you join. By then you have resigned, served your notice and lost your bargaining power.

Most interview prep, including most of the SevyDevy library, trains you to answer questions. Reverse interviewing questions train you to ask them back, so you can tell a healthy team from a tired one before you sign.

Picture a common setup. A backend engineer in Bengaluru with three years of experience reaches the last round at a product company. The interviewer says they have five minutes left and asks if there are any questions. The engineer asks about the tech stack, hears a good answer and accepts the offer. The setup is made up, but the gap in it is real.

In the first month, the engineer learns three things nobody mentioned. Four people share a night pager, with a primary and a backup on call each week. A one-line fix needs approval from two managers in another city. And the last outage ended with one engineer named in a team email. Each of these could have surfaced with one question.

Seven words come up again and again in this guide. Each is explained once here, in plain words.

• On-call: a duty where you must respond to production problems outside normal work, for a fixed shift such as one week.
• Page: an automatic alert that calls or messages the on-call person, often on their phone, because something is broken.
• Rotation: the list of people who take turns being on call. A bigger rotation means each person is on call less often.
• Incident: an event where a live service breaks or slows down enough that someone must act.
• Postmortem: a written review after an incident that explains what happened and what will change. Blameless means it looks for causes, not someone to punish.
• Toil: repeated manual work that keeps a service running but leaves nothing lasting, like restarting the same job by hand every week.
• Red flag: an answer that suggests a problem worth checking further. One red flag is a reason to ask more, not a verdict.

Reverse interviewing questions are questions you ask the interviewer to test what the job is really like. You ask them in the time most interviews leave at the end, and in any extra call you request after an offer.

They differ from polite questions such as asking about the tech stack. A polite question gets information the company is happy to share. A reverse interviewing question gets evidence about the parts that are hard to see from outside: night pages, slow approvals and how people are treated after mistakes.

Different rounds suit different questions. A future teammate knows the pager. A hiring manager knows how decisions are made. A senior leader knows where the team is headed. The table below is our suggested split, not a rule any company follows.

If the interview loop, the full set of rounds, has no peer round, it is reasonable to ask for a short call with someone on the team after the offer. How a company responds to that request is itself useful evidence.

Because a general question invites a general, practised answer. Ask how the work-life balance is and the easy answer is that it is good, often honestly, because the interviewer is describing their own average week.

The naive version looks like this. How is the on-call? How is the culture? Do you have good work-life balance? Each one can be answered with one comfortable word, and you learn almost nothing.

The better version asks for the most recent specific event. When were you last paged at night, and what was it? What happened after the last outage? Walk me through the last change you shipped. A recent event has details: a day, a cause, a person, a follow-up. In our view, details are much harder to polish than opinions.

An everyday picture helps. A doctor does not ask whether you feel healthy. They ask when the pain started, where it hurts and what you ate last night. The symptoms are the recent events, and the diagnosis is your judgement afterwards.

Where the picture breaks: a patient wants to be diagnosed, but an interviewer is also selling the job. So ask the same question to two different people and compare the details.

Questions about the rotation size, the number of pages and the last bad night reveal it best. Together they tell you how often you will be on call and how hard those shifts are.

• How many people share the on-call rotation, and how long is one shift?
• Is there a primary and a backup person, and do both count as on call?
• When were you last paged outside working hours, and what caused it?
• Roughly how many pages does a typical week bring, and how many need real action?
• If I get stuck at 3 a.m., who can I call, and is that written down?
• What does the team get for on-call: extra pay, time off, or nothing formal?
• What was the last alert the team deleted or fixed because it was noisy?

The last question is a quiet test. The on-call chapter of the Google SRE book, covered next, says every paging alert should be actionable, and this shows whether the team acts on that idea.

A yardstick from the Google SRE book

You need something to compare the answers with. The free online Google SRE book has a chapter on being on call that states the limits Google's site reliability engineering teams set when the book was written.

• Time: at least half of an engineer's time goes to engineering projects, and no more than a quarter is spent on call.
• Rotation size: with two people always on call, a primary and a secondary, on week-long shifts, a single-site team needs at least eight engineers. A team split across two sites needs at least six per site.
• Load: handling one incident, including the root-cause work, the fix and the postmortem, takes about six hours on average. So the chapter sets a maximum of two incidents per 12-hour shift.
• Support: the chapter lists clear escalation paths, defined incident procedures and a blameless postmortem culture as what makes on call less daunting.
• Pay: the chapter says Google offers time off in lieu or cash for on-call work, capped at some share of salary.

Treat these as one company's published practice from its book, not a law, and ask each company for its own policy. Your future team may run smaller services with fewer pages. Still, the numbers turn a vague worry into a concrete comparison.

Ask them to trace the last real change from idea to production, with rough times at each step. In our view, decision speed hides in the waiting between steps more than in the coding.

DORA, a research programme on software delivery, measures this with plain metrics. As of 29 October 2026, its guide lists five, and two matter most here. Change lead time is the time from a change being committed to it running in production. Deployment frequency is how often a team deploys.

DORA's own guide warns against turning these into targets or comparing very different teams. So do not ask for their lead time number as if it were a score. Ask for the story, and listen for where it stops.

• Walk me through the last change you shipped. How long from merge to production?
• Who has to approve a production change, and how long does that usually take?
• What was the last decision that took longer than you expected, and what held it up?
• When two senior engineers disagree on a design, how is it settled, and who has the final say?
• When a deploy goes wrong, how do you roll it back, and how long did the last rollback take?
• What would I be able to ship in my first two weeks?

In the running example, the engineer would have asked the second question. A specific answer, such as two managers in another city signing off on every release, would have shown the approval wait before joining.

Slow is not always bad. A payments or banking team may wait for approvals because a mistake moves real money. The red flag is waiting that nobody can explain, or that nobody is trying to shorten.

Questions about bad news reveal it best: what happened after the last outage, the last missed deadline and the last disagreement with a manager. A team shows its culture most clearly when something goes wrong.

DORA uses a model from the sociologist Ron Westrum that sorts organisations into three cultures. Pathological cultures are power oriented, bureaucratic ones are rule oriented and generative ones are performance oriented. DORA's research says a high-trust, generative culture predicts better software delivery and organisational performance.

The Google SRE book's postmortem chapter makes a similar point about failure. It says a blameless postmortem looks for contributing causes without blaming any person or team. Where finger pointing wins, people stop bringing problems to light.

A Google study, written up on its re:Work site, looked at 180 Google teams to learn what made them effective. It ranked psychological safety first. The re:Work page quotes researcher Amy Edmondson's definition: a shared belief that the team is safe for interpersonal risk taking. In daily work, that looks like admitting a mistake or asking a basic question without fear.

A few more questions work well here. Why is this role open? What did the last person in this seat move on to? What is one thing about the team you would change if you could?

Any honest answer to the last one is a good sign. An interviewer who says nothing would change is either very lucky or not comfortable telling you.

A red flag is a pattern in how they answer, more than any single fact. The list below is our advice from the questions above, not a checklist from any study.

Green flags matter just as much. Listen for exact numbers given without being pushed and an interviewer admitting a weakness. Also listen for stories that end with a system fix, not a warning to a person.

Keep one more thing in mind. The interviewer is often a tired engineer doing this between other work. A short answer may only mean they are busy, so give them one clear, specific question rather than five.

You ask about different risks. At a service company that builds software for clients, the big unknown is which project you land on. At a product company that builds its own software, it is usually on-call and ownership.

Questions for service companies

• Is the project or client I will join decided before my joining date, or after?
• What are the working hours for this client, and do they follow a time zone abroad?
• Does this project have production support or weekend support shifts, and how are they shared?
• If the project ends, what happens next, and how long does that usually take?

Questions for product companies and startups

• Which services would I own, and who is on call for them today?
• How many engineers are on this team now, and how many joined in the last year?
• What happened to the team's plans in the last reorganisation or funding change?

Questions about notice periods and offers

Many Indian engineers must serve a notice period before joining, and its length is written in your current appointment letter or contract. Ask the recruiter whether the offer holds for your full notice period, and get the joining date written in the offer letter.

This matters for reverse interviewing because you lose bargaining power once you resign. Ask for the extra team call before you resign, not during your notice period. The SevyDevy guide on salary negotiation covers the money side of the same moment.

Partly. The Joel Test is a list of 12 yes or no questions that Joel Spolsky published on 9 August 2000 to rate the quality of a software team. Several of its ideas still make good reverse interviewing questions.

The article scores one point for each yes. It calls 12 perfect, 11 tolerable and 10 or lower serious problems. It was written to rate a software team, not as advice for job seekers, so using it as a candidate is our suggestion.

Some items read as dated to us. A team that builds and tests on every merge has passed the daily-builds question in spirit. Use the test for that spirit, a quick yes or no check, rather than its exact wording.

Divide the number of people on call at the same time by the size of the rotation. That gives the share of weeks each person spends on call, if shifts are shared evenly.

The SRE book's eight-person minimum comes from exactly this sum: two people on call at once, week-long shifts and no more than a quarter of the time on call. This short script repeats it for a few team sizes.

def on_call_share(team_size, on_call_at_once=2):
    """Fraction of weeks each engineer spends on call, if shifts are shared evenly."""
    return on_call_at_once / team_size

for team in (4, 6, 8, 12):
    share = on_call_share(team)
    print(f"{team} engineers, primary plus secondary: {share:.0%} of weeks on call")

On Python 3.13.18 it printed 50% of weeks for four engineers, 33% for six, 25% for eight and 17% for twelve. Change on_call_at_once to 1 if the team has no secondary.

What just happened? In the running example, four people shared one pager. With a primary and a backup, each person is on call every other week, double the quarter the SRE chapter aims for.

Then check the load side. Ask for pages per shift that needed real action. The chapter's limit of two incidents per 12-hour shift assumes about six hours of work per incident, so a shift near that limit leaves little room for anything else.

Write each answer down soon after the call and mark it as specific, vague or missing. Then compare across interviewers. Details fade after a long day of rounds, and one warm conversation can hide three vague answers.

1. 1

   Write it down within the hour

   Note each question and the answer in the interviewer's own words, with any numbers they gave.

2. 2

   Mark each answer

   Specific means a recent event with a day, a cause and a follow-up. Vague means opinion only. Missing means they changed the subject.

3. 3

   Run the on-call sum

   Divide people on call at once by rotation size. Compare it with the SRE chapter's quarter, and note pages per shift.

4. 4

   Compare interviewers

   Put two answers to the same question side by side. Matching details build trust; opposite stories are worth one more question.

5. 5

   Weigh against your situation

   A heavy rotation may be fine for a big learning jump and not fine with a long commute. Decide what you can live with before you see the offer.

6. 6

   Ask one follow-up before you resign

   Send the hiring manager your one or two open questions in writing, or ask for a short team call.

Tie your question to the design you just discussed. It shows you think like an owner, and it gets you a real answer about how the team runs similar systems.

1. 1

   Pick one failure from your design

   Choose a failure you discussed, such as a queue backing up or a cache going cold.

2. 2

   Ask who gets paged for it in real life

   For example: in your team, who would get paged if this queue backed up, and when did that last happen?

3. 3

   Ask what changed after

   Follow with: what did the team change after that incident? Listen for a system fix, not a person.

4. 4

   Ask about shipping the fix

   Then: how long would a fix like that take to reach production here? That gives you decision speed.

5. 5

   Close politely

   Thank them and note the answer. Two good questions in five minutes beat six rushed ones.