Remote site reliability engineer interview questions and how to answer them
SRE interview loops are usually the longest in infrastructure hiring. Expect a coding round in Go or Python, a Linux and troubleshooting round, a design round focused on how systems fail, and an incident role-play where the interviewer pages you with a made-up outage and watches how you respond.
The questions below cover the reliability concepts that come up in almost every loop, plus the on-call and remote questions that matter when the rest of the team is hours away from Lagos.
Updated October 2026 by the WorkRemote careers team
On this page
About the role and your experience
Openers that check you understand the job and have done the work.
What goes into a good postmortem?
Why they ask
Postmortems are how SRE teams learn. They want to know you write them blamelessly and with useful actions.
How to answer
Summary, impact, timeline, contributing causes, what went well and badly, and action items with owners and dates. Blameless: focus on how the system allowed the mistake.
Show a sample answerHide the sample answer
A short summary and the customer impact in numbers: how long, how many users or requests, any money lost. A timeline with detection, response and recovery times. The contributing causes, usually more than one. What went well, like an alert that fired quickly, and what didn't. Then a few action items with an owner and a date, focused on things like better alerts or safer rollouts. It's blameless: if someone ran the wrong command, the question is why the system let one command do that much damage.
Technical questions
What you know and how you'd do the work, often with a live task or test.
What is the difference between an SLI, an SLO and an SLA?
Why they ask
The vocabulary of the job. Mixing them up is an early red flag.
How to answer
SLI is the measurement, SLO is the internal target for it, SLA is the contract with customers that carries consequences. Give one example of each for the same service.
Show a sample answerHide the sample answer
An SLI is a measurement, like the share of checkout requests that return successfully in under 500ms. The SLO is our target for it, say 99.9% over a rolling 30 days. The SLA is what we promise customers in the contract, with penalties like service credits if we miss it. I'd set the SLA looser than the SLO, say 99.5%, so we find out we're in trouble before we owe anyone money.
Our SLO is 99.9% availability over 30 days. How much downtime is that, and what happens when the error budget runs out?
Why they ask
Checks that you can do the maths quickly and understand that the budget drives decisions.
How to answer
0.1% of 30 days is 43.2 minutes. Then explain the policy side: when the budget is spent, the team prioritises reliability over features until the service is back within SLO.
Show a sample answerHide the sample answer
30 days is 43,200 minutes, and 0.1% of that is 43.2 minutes of full downtime, or the equivalent in failed requests. The error budget is 1 minus the SLO. If we burn through it, the usual policy, like the example in Google's SRE workbook, is to freeze feature releases apart from urgent bug and security fixes until we're back within the SLO, and put the team's time into the reliability problems that caused it.
How would you choose SLIs for a public API?
Why they ask
Picking the right thing to measure is harder than setting a number. It shows whether you think from the user's side.
How to answer
Start from what users care about: availability and latency, sometimes correctness or freshness. Define each as good events over valid events, and say where you measure it (load balancer or client side, not the server's own view).
Show a sample answerHide the sample answer
I'd start with what callers experience. Availability: successful responses divided by valid requests, counting 5xx as bad but not 4xx caused by bad input. Latency: the share of requests served under a threshold, like 300ms, rather than an average. I'd measure at the load balancer so it includes problems the app itself can't see. For an API that returns data from a pipeline, I might add freshness: how old the data is.
Why do SREs look at p99 latency rather than the average?
Why they ask
Averages hide the slow requests that real users complain about. Basic but revealing.
How to answer
Averages are pulled around by the bulk of fast requests and hide the long tail. Percentiles show what the slowest users experience, and at scale 1% is a lot of people.
Show a sample answerHide the sample answer
If 98 requests take 50ms and 2 take 5 seconds, the average is about 150ms, which looks fine, but 2% of users waited 5 seconds. The p99 shows that tail. At a million requests a day, 1% is 10,000 slow requests. I'd track p50 for the typical case and p99 for the tail, and set the latency SLO on the share of requests under a threshold.
What should page an engineer at night, and what shouldn't?
Why they ask
Alert fatigue is one of the biggest problems in operations. They want someone who reduces noise.
How to answer
Page on user-facing symptoms that need a human now, ideally SLO burn-rate alerts. Causes like high CPU go to dashboards or tickets. Mention multiwindow burn-rate alerting.
Show a sample answerHide the sample answer
A page should mean users are hurting now and a human has to act. So I'd page on symptoms like error rate or latency against the SLO, not on CPU at 85%, which goes on a dashboard or becomes a ticket. Google's workbook suggests burn-rate alerts: for a 99.9% SLO, page if you're burning budget at 14.4 times the sustainable rate over an hour, which uses 2% of the monthly budget, confirmed by a 5-minute window so it stops paging once the problem ends. Every alert should have a runbook link.
Name the four golden signals and how you'd monitor them for a web service.
Why they ask
A standard monitoring framework from Google's SRE book; it shows you have a structured way to look at a service.
How to answer
Latency, traffic, errors, saturation. Give a concrete metric for each, and mention that latency of failed requests should be tracked separately.
Show a sample answerHide the sample answer
Latency: request duration as a histogram, looking at p50 and p99, with successful and failed requests split, because fast errors can make latency look good. Traffic: requests per second. Errors: rate of 5xx responses, plus requests that returned 200 but with the wrong content if we can detect that. Saturation: how full the most constrained resource is, like CPU, memory, database connections or queue depth.
In Prometheus, what's the difference between a counter and a gauge, and how would you graph request rate and p99 latency?
Why they ask
Prometheus is the default monitoring tool in most SRE job ads, and these are the queries you'll write daily.
How to answer
A counter only goes up (and resets on restart), so you use
rate()on it. A gauge goes up and down. For p99, usehistogram_quantileon the rate of histogram buckets.Show a sample answerHide the sample answer
A counter only increases, like total requests, and resets to zero when the process restarts, so I never graph it raw; I use
rate(http_requests_total[5m])to get per-second requests, andrate()handles the resets. A gauge can go up or down, like memory in use or queue length. For p99 latency from a histogram:histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))).A service's latency has doubled but CPU and memory look normal. How do you investigate?
Why they ask
Real slowdowns rarely show up in the obvious metrics. It tests systematic debugging.
How to answer
Look beyond host metrics: traces to find which span got slower, downstream dependencies, connection pools, locks, garbage collection, DNS, network. Check what changed recently.
Show a sample answerHide the sample answer
First I'd check what changed: deploys, config, traffic pattern, a dependency's release. Then I'd use traces to see which part of the request got slower. If it's a database call, I'd look at slow query logs and whether the connection pool is exhausted, because requests waiting for a connection don't use CPU. Other usual suspects are a slow downstream API, lock contention, garbage collection pauses, or DNS lookups timing out. If there's no tracing, adding it is my first action item.
Your liveness probe calls the database. What could go wrong?
Why they ask
A classic way teams turn a small database blip into a full outage. It shows you think about failure cascades.
How to answer
If the database has a brief problem, every pod fails liveness and gets restarted at once, which makes things worse. Liveness should check only the process itself; dependency checks belong in readiness, and even then carefully.
Show a sample answerHide the sample answer
If the database slows down for 30 seconds, every pod fails its liveness probe and the kubelet restarts all of them at the same time. Now we have a database problem plus cold starts plus a flood of reconnections when they come back. Liveness should only answer "is this process stuck?". Readiness can consider dependencies, but if every pod goes unready together the Service has no endpoints, so I'd usually prefer the app to degrade gracefully and report the problem in metrics.
How do retries cause outages, and how do you make them safe?
Why they ask
Retry storms are behind many cascading failures. Senior SRE interviews always touch on this.
How to answer
Retries multiply load on a service that's already struggling. Make them safe with timeouts, capped retries, exponential backoff with jitter, retry budgets, circuit breakers, and only retrying idempotent requests.
Show a sample answerHide the sample answer
If a service slows down and every client retries three times, it suddenly gets up to four times the traffic just when it can least handle it, and it falls over completely. I'd set timeouts on every call, cap retries, use exponential backoff with jitter so clients don't retry in sync, and add a circuit breaker that stops calling a failing dependency for a while. Only idempotent operations should be retried automatically, or a payment could go through twice.
Behavioural questions
Past situations. Answer with a real example: what happened, what you did, what changed.
What is toil? Give an example you automated.
Why they ask
Reducing toil is a core SRE responsibility. They want a concrete story with a result.
How to answer
Toil is manual, repetitive, automatable work with no lasting value that grows with the service. Google aims to keep it under half of an SRE's time. Then give your story with numbers.
Show a sample answerHide the sample answer
Toil is operational work that's manual, repetitive, could be automated, and doesn't leave the system any better, and it grows as the service grows. At my last job we renewed TLS certificates by hand for about 40 internal services, roughly a day of work every few months and a source of outages when one was missed. I set up cert-manager on our Kubernetes clusters with automatic renewal and an alert if any certificate gets within 14 days of expiry. We haven't had a certificate outage since.
Tell me about an incident you handled and what you learned.
Why they ask
The most important behavioural question for SREs. They want ownership, calm and learning.
How to answer
Situation, your role, what you did in order, how you communicated, the outcome, and what changed afterwards.
Show a sample answerHide the sample answer
At a Lagos payments company, our transaction API started timing out during a salary-day peak. I was on call. I opened an incident channel, saw the database connection pool was maxed out, and we raised the pool size and scaled out read replicas to get through the peak. I posted updates every 20 minutes to support and the business team. In the postmortem we found a new report query was holding connections; we moved reporting to a replica and added an alert on pool usage. The next salary day was quiet.
Tell me about a time you pushed back on a launch because of reliability.
Why they ask
SREs have to say no sometimes. They want to see you do it with data and keep the relationship.
How to answer
Show you used numbers (error budget, load test results), offered a way forward, and reached a joint decision.
Show a sample answerHide the sample answer
A team wanted to launch a feature the week after two incidents had used most of our error budget. I shared the SLO dashboard and proposed launching to 10% of users behind a feature flag instead of everyone. They agreed, we found a memory leak at that 10%, fixed it, and rolled out fully a week later. Nobody had to argue about opinions, because the numbers were on the screen.
Situational questions
Hypotheticals about problems you'd meet in the job.
You're paged at 3am: error rate on the checkout service has jumped to 8%. Talk me through what you do.
Why they ask
The incident role-play. They're watching your order of actions and how you communicate, not whether you guess the cause.
How to answer
Acknowledge, assess impact, declare an incident if it's real, mitigate first (rollback, failover, scale, feature flag), communicate on a schedule, then find the root cause once users are safe.
Show a sample answerHide the sample answer
I'd acknowledge the page so it doesn't escalate, then check the SLO dashboard to confirm it's real and see when it started. If customers are affected, I'd open an incident channel and post what I know. Next I'd look for recent changes: a deploy, a config change, a dependency having problems. If there was a deploy just before the spike, I'd roll it back straight away rather than debug it live. I'd post updates every 15 or 20 minutes, page a second person if I'm not making progress, and once errors are back to normal, write up the timeline while it's fresh.
Remote work questions
How you'll work from Nigeria with a team elsewhere: hours, power, internet, communication.
You'd be on a US on-call rotation from Lagos. How would you make that work?
Why they ask
They need to know you understand what night pages mean and have planned for them.
How to answer
Show you know the time difference, your setup for being reachable at night, and what you'd ask for to keep it sustainable. Suggest follow-the-sun if it fits.
Show a sample answerHide the sample answer
US East is 5 to 6 hours behind Lagos and the West Coast 8 to 9, so their evening problems reach me after midnight. On my on-call weeks I'd have backup power that runs through the night, two internet connections and the paging app set to override silent mode. I'd want a clear escalation path and the option to start late after a bad night. I'd also offer to take the hours that are night-time in the US, because that's my morning, which could take pressure off the US team.
What happens if your power goes out while you're on call?
Why they ask
Employers who've hired in Nigeria know about outages. A missed page is a serious failure for an SRE.
How to answer
Concrete setup, and a fallback plan that means the page still gets answered.
Show a sample answerHide the sample answer
My inverter and batteries run my laptop, router and phone charger for about ten hours, and I top them up with solar. My main connection is fibre with a MiFi on a different network as backup, plus my phone's hotspot. If everything failed during an incident, I'd tell the incident channel from my phone and hand over to the secondary on call, so the page is never left unanswered.
Remote interview tips
Practise the incident role-play out loud. Ask a friend to play the interviewer and give you a made-up outage. Say each step: acknowledge, assess, communicate, mitigate, investigate. The hardest part is remembering to post updates while you think.
Read the core chapters before the loop. The SLO, monitoring, toil and postmortem chapters of Google's free SRE book, and the workbook chapter on alerting on SLOs. Interviewers often use the same language.
Bring numbers to your stories. Minutes to detect, minutes to recover, pages per week before and after, budget burned. SRE interviewers trust stories with measurements.
Confirm time zones in writing. Write both times when you agree an interview ("11am EDT / 4pm WAT"), and double-check around clock changes: the UK and Europe move in March and October, the US in March and November, and Lagos doesn't move at all.
Ask about on-call in every loop. How often, how many pages a week, whether it's paid, and how they handle someone being paged at night. The answers tell you a lot about the team, and asking shows you've done this job before.
Questions people ask
Do SRE interviews include coding?
Yes, usually. Expect at least one coding round in Go or Python, sometimes as hard as a software engineer's, plus scripting or log-parsing tasks. Practise both data-structure problems and practical automation.
What is an SRE incident role-play interview?
The interviewer describes an alert or outage and you talk through what you'd do, asking questions as you go. They're judging your order of actions and communication more than whether you find the cause.
How long is an SRE interview process?
Often four to six rounds over two to five weeks: recruiter screen, coding, troubleshooting, system design, incident scenario and a behavioural call. Some companies add a take-home task.
What SRE concepts should I know before an interview?
SLIs, SLOs and error budgets, the four golden signals, alerting on symptoms and burn rate, blameless postmortems, toil, and failure patterns like retry storms and cascading failures. Google's free SRE book covers all of them.
Updated October 2026 by the WorkRemote careers team
Interview questions for roles close to site reliability engineer
- DevOps Engineer
A DevOps engineer builds and runs the machinery that takes code from a developer's laptop to production: CI/CD pipelines, Docker images, Kubernetes clusters and Terraform-managed infrastructure. It is very doable remotely from Nigeria, but it is rarely a first tech job, because employers are handing you access to production.
- Cloud Engineer
A cloud engineer builds and looks after a company's setup on AWS, Microsoft Azure or Google Cloud: the networks, permissions, servers, databases and storage, and the monthly bill. You can do it remotely from Nigeria, and it's one of the infrastructure roles where a certificate genuinely helps, but you'll still need hands-on projects to get past the technical interview.
- Backend Developer
A backend developer builds the servers, APIs, databases and background jobs that apps run on, typically in Node.js, Python, Go, Java or C#. Nigerian backend developers are hired remotely by foreign companies, especially those with fintech or payments experience, though most remote roles want two or more years of production work.
- Software Engineer
A software engineer designs, writes, tests and maintains the code behind products, and it is one of the remote jobs Nigerians most often get with foreign companies. Entry-level remote roles are rare, so most people get their first two years of experience locally or through freelance work before landing a dollar-paid contract.