Site Reliability Engineer Interview Questions & Answers

Site Reliability Engineering interviews test more than just your technical knowledge—they assess your ability to think critically about complex systems, manage incidents under pressure, and balance innovation with stability. Whether you’re preparing for your first SRE role or leveling up in your career, understanding what interviewers are looking for and how to articulate your experience is essential.

This guide walks you through the most common site reliability engineer interview questions, provides realistic sample answers you can adapt to your experience, and gives you frameworks for tackling unexpected challenges. You’ll also find behavioral and technical deep-dives, plus strategic questions to ask your interviewer to evaluate if the role is right for you.

Common Site Reliability Engineer Interview Questions

How do you approach designing a highly available system?

Why they ask: This question reveals your understanding of core SRE principles. Interviewers want to see that you think about redundancy, failover mechanisms, monitoring, and graceful degradation—not just building something that “works.”

Sample answer:

“When I design for high availability, I start by defining what ‘available’ actually means for that service—what’s our uptime target? Then I work backward from there. I implement multi-region or multi-zone deployments so no single point of failure brings everything down. I use load balancers to distribute traffic and automated failover to handle regional outages. For stateful services, I ensure data replication across regions with eventual consistency in mind. I pair this with comprehensive monitoring—Prometheus for metrics, structured logging, and distributed tracing—so we catch issues before users do. And I always design runbooks for common failure scenarios. In my last role, we implemented this for our payment processing service and reduced our mean time to recovery from 45 minutes to under 5 minutes.”

Tip for personalizing: Replace the payment processing service example with a system you’ve actually worked on. Include the specific tools your target company uses—if they mention using Datadog, talk about Datadog specifically.

Tell me about a time you responded to a major production incident.

Why they ask: This is where theory meets reality. They want to understand your incident response process, how you communicate under pressure, and most importantly, how you learn from failures.

Sample answer:

“Last year, we had a database connection pool exhaustion during a traffic spike on Black Friday. Our service started returning 503 errors. I was on-call, and my first move was to page the on-call database engineer and open a war room Slack channel to communicate with stakeholders. While they investigated the database side, I started looking at our metrics—I could see CPU and memory were normal, but connection count was maxed out. I implemented a temporary fix by increasing the timeout on database connections to force recycling, which bought us 20 minutes while we worked on the root cause. The database team discovered that a recent code change had removed connection pooling in one of our services. We reverted that change and gradually brought traffic back. What impressed me most was how the team handled the post-mortem—no blame, just data. We implemented automated alerts for connection pool saturation and improved our deployment process to catch connection pool changes during code review.”

Tip for personalizing: Use a real incident you’ve managed. Include the specific metrics you monitored and the tools you used. Don’t minimize the incident—explain what went wrong and what you learned.

How do you define and track SLOs?

Why they ask: SLOs (Service Level Objectives) are fundamental to SRE. This question tests whether you understand how to balance reliability with development velocity and if you can translate business needs into technical metrics.

Sample answer:

“SLOs need to come from understanding what matters to your users and your business. We start by defining SLIs—the actual measurements—like request latency and error rate. For our user-facing API, we decided on a 99.9% availability SLO, which translates to about 43 minutes of acceptable downtime per month. We track this with a 30-day rolling window using Prometheus. The key part is the error budget: if we have 0.1% error budget and we’ve already burned through 0.08% handling an incident, the team knows we need to be more conservative with deployments. This forces an interesting conversation—do we deploy that new feature or do we focus on stability? In practice, it means we’ve had to say ‘no’ to shipping features until we improved reliability, which actually led to fixing some serious underlying issues we’d been ignoring.”

Tip for personalizing: Explain the SLO for a specific service you’ve worked with. Mention the actual percentages and time windows your company uses. If you haven’t defined SLOs before, talk about how you’d approach building that framework.

What’s your experience with infrastructure as code?

Why they ask: IaC is essential for modern SRE work. They’re assessing whether you can automate infrastructure provisioning, manage configuration drift, and enable repeatable deployments.

Sample answer:

“I’ve primarily worked with Terraform and Ansible. In my current role, we migrated from a mix of manual AWS console clicks and shell scripts to Terraform-managed infrastructure. It was a painful process at first—about three months of work—but it was worth it. Now every infrastructure change goes through version control, gets peer-reviewed, and can be applied consistently. We reduced manual provisioning errors by probably 90%. Ansible handles the configuration management on top of that—we use it for deploying security patches and managing log rotation across our fleet. The biggest win was being able to spin up entire test environments with a single command. Before, it took hours and manual steps. Now it’s automated, which means we can actually afford to test disaster recovery scenarios regularly. We also reduced our on-call wake-ups by at least 30% because we eliminated a lot of manual configuration drift issues.”

Tip for personalizing: Mention the specific IaC tools you know. Talk about the actual impact you’ve had—reduced errors, faster deployments, fewer incidents. If you haven’t used IaC extensively, explain how you’d start learning or what you’ve done with configuration management tools.

How do you approach monitoring and observability?

Why they ask: You can’t manage what you don’t measure. This tests whether you understand the difference between monitoring and observability, and if you can set up meaningful alerts.

Sample answer:

“There’s a difference between monitoring—‘is the system up?’—and observability—‘why is it behaving this way?’ We use the RED method for application metrics: Rate, Errors, Duration. Prometheus scrapes metrics from our applications every 30 seconds. For infrastructure, we track CPU, memory, disk, and network. But the real power is in observability. We use structured logging with JSON payloads so we can actually query logs meaningfully, and we have distributed tracing with Jaeger to follow requests through multiple services. What changed our game was moving away from alerting on every metric to alerting on symptoms of user-impacting problems. Instead of alerting on ‘CPU above 80%,’ we alert on ‘latency above 1 second’ or ‘error rate above 0.5%.’ We still ended up with too many false positives, so we implemented alert fatigue rules—we don’t page the on-call engineer unless it’s truly urgent. That reduced false alerts by 60% and made on-call actually bearable.”

Tip for personalizing: Explain the monitoring stack you’ve actually used. Give specific metrics and thresholds. Mention how you’ve tackled alert fatigue—this shows maturity.

Describe your experience with containerization and orchestration.

Why they asks: Modern SRE roles almost always involve containers and Kubernetes. They want to know if you can deploy, scale, and troubleshoot containerized applications.

Sample answer:

“We use Docker for containerization and Kubernetes for orchestration. I’m comfortable writing Dockerfiles, managing image registries, and setting up CI/CD pipelines that build and push images. In Kubernetes, I’ve worked with deployments, stateful sets, and daemonsets. We use Helm for templating configurations across environments. On the troubleshooting side, I can diagnose issues with pod scheduling, resource constraints, and networking. We had an incident where pods kept getting evicted, and I traced it to memory requests being set too conservatively—we were over-subscribing nodes. I updated the resource requests across our services, and the evictions stopped. I’ve also implemented resource quotas per namespace to prevent one team’s runaway deployment from taking down another team’s services. The biggest challenge we’ve faced is managing persistent state in Kubernetes—we eventually moved stateful services like databases to managed services rather than fighting Kubernetes.”

Tip for personalizing: Be specific about which tools and practices you’ve actually used. If you’re newer to Kubernetes, talk about specific problems you’ve solved or learned from. Mention a real incident and how you debugged it.

What’s your approach to on-call rotations and managing toil?

Why they ask: SREs spend time on-call and doing repetitive work. They want to know if you have a philosophy about managing this and if you actively work to reduce toil.

Sample answer:

“On-call rotations need to be sustainable or you’ll burn out your team. In my current role, we do weekly rotations with a primary and secondary on-call. We time-box alerts—if you’re getting paged every 15 minutes, that’s a signal to fix the system, not a sign you’re doing your job well. We also have escalation policies, so not every alert goes straight to on-call. Toil—that’s the manual, repetitive work that doesn’t add lasting value—is what I focus on eliminating. I track it: last quarter, we spent probably 40 hours per person per month on manual tasks. We identified the top toil items and automated them. Patching servers manually used to take 8 hours a month per person. I wrote Ansible playbooks for it, and now it’s automated and takes maybe 20 minutes of oversight. Same with database backups and log rotation. The 50/50 rule—dedicating 50% of your time to projects and 50% to operations—really helps keep focus. When I see developers coming on-call for the first time, I make sure they understand what’s expected and give them good runbooks. That reduces MTTR significantly because they’re not guessing.”

Tip for personalizing: Talk about toil you’ve actually eliminated. Give specific numbers—hours saved, frequency of tasks reduced. Explain your philosophy on sustainable on-call.

How do you handle a situation where reliability work competes with feature development?

Why they ask: This gets at cultural and political dimensions of SRE. They want to see if you can advocate for reliability while respecting business needs.

Sample answer:

“This is a real tension, and I think the honest answer is that it’s not always clear-cut. When a critical system has high error rates, that’s an obvious ‘reliability first’ decision. But when a development team wants to ship a feature and you want to refactor the deployment pipeline, that’s trickier. I’ve found that making the business impact visible really helps. When we had a 20-minute deployment window, developers couldn’t iterate quickly and took shortcuts in testing. I quantified it: we were losing about 3 hours per developer per week. When I showed the leadership team that refactoring our CD pipeline would save us 6 hours per developer per week, they funded it. It wasn’t a preachy ‘reliability is important’ conversation—it was about enabling developers to move faster while reducing incident risk. Error budgets actually help here too. If we have error budget left, we can take calculated risks with feature deployments. If we’re over budget, we collectively agree to focus on stability. That makes the tradeoff explicit.”

Tip for personalizing: Show that you understand both perspectives. Give an example where you made a business case for reliability work. Demonstrate that you can communicate in terms leadership understands—time, money, risk.

What’s your experience with disaster recovery and testing?

Why they ask: When everything breaks, does your team have a plan? They want to know if you’ve thought through worst-case scenarios and actually tested your recovery procedures.

Sample answer:

“Disaster recovery planning is one of those things that feels abstract until you actually need it. We have a documented DR plan for each critical service—what to do if a region goes down, if the database is corrupted, if we get hacked. But the real test is game days. We run one or two per year where we actually simulate failures and practice our response. Last year, we simulated losing an entire region, and it exposed some gaps: our DNS failover wasn’t automatic, and we had 20 minutes of downtime before we switched. We implemented automatic failover for DNS and reduced that to under 2 minutes. We also tested our backup restore process and found it took 6 hours—way too long for a critical service. We rearchitected our backup strategy and got it down to 30 minutes. The most important part of DR testing is that it’s blameless. We don’t use it to blame people who missed steps; we use it to improve our systems and documentation. It’s also exposed that we need better communication protocols with external teams when a real disaster happens.”

Tip for personalizing: Talk about an actual game day or DR test you’ve run. Be specific about what failed and what you learned. If you haven’t done this, talk about how you’d approach building a DR program.

How do you stay current with new tools and technologies?

Why they ask: SRE is a rapidly evolving field. They want to know if you’re genuinely curious and invested in learning, or if you’re coasting.

Sample answer:

“I spend time reading—I follow several SRE and infrastructure blogs, and I read one technical book every quarter or so. The SRE Book from Google is required reading in this field. But honestly, the best learning comes from actually breaking things and fixing them. We use a lab environment where we experiment with new tools before bringing them to production. We just evaluated three different service mesh tools because our microservices architecture was getting complicated. I spent a week setting up Istio and Linkerd in our lab, ran some load tests, and reported back to the team. We ended up not adopting either one—we realized we didn’t have the operational maturity for a service mesh yet—but I learned a ton. I also attend a few conferences per year. I’m selective—I go to talks on topics I actually need to learn, not just for the networking. And honestly, I learn a lot from my team. When someone solves a problem I haven’t encountered, I ask them to walk me through it.”

Tip for personalizing: Give specific examples of tools or technologies you’ve learned recently. Mention resources you actually use. Show genuine curiosity, not just resume padding.

Tell me about a time you had to debug a complex system issue.

Why they ask: This tests your troubleshooting methodology and whether you can think systematically through problems rather than randomly trying things.

Sample answer:

“We had an issue where a specific customer’s API requests were consistently timing out, but only during certain times of day. Other customers weren’t affected. That was weird—it suggested something about their specific request patterns. I started by looking at traces for that customer’s requests. I noticed that their requests were hitting a specific downstream service that was taking 5 seconds instead of the normal 50 milliseconds. That downstream service’s metrics looked fine—CPU, memory, latency for other callers were all normal. Then I noticed the pattern: it was happening during their evening peak time when they were hitting us with lots of requests. I looked at the connection pool for that downstream service and saw it was getting exhausted during their traffic spikes. Their requests were queuing up waiting for a connection. We increased the connection pool size for that downstream dependency, and the timeout went away. But the real lesson was that the underlying issue was that downstream service wasn’t scaled for their traffic. We implemented autoscaling based on connection pool utilization, which fixed it permanently.”

Tip for personalizing: Walk through your actual debugging process. Mention the tools you used. Show how you formed hypotheses and tested them. Demonstrate systems thinking—understanding how components interact.

What metrics do you prioritize when evaluating system health?

Why they ask: You can’t track everything. This tests your judgment about what actually matters and reveals your understanding of user impact.

Sample answer:

“I use the RED method: Rate, Errors, Duration. For Rate, I track requests per second because traffic patterns often precede issues. Errors are critical—I care about error count and error rate. Duration is latency—both p50 and p99, because p99 tells you about your worst users’ experience. We also track saturation: CPU, memory, disk I/O, and connection pool utilization. These are early warning signs that we’re about to have problems. For specific services, I add business metrics. For our payment service, I care about transaction success rate. For our search service, I care about results accuracy. The mistake I see people make is treating all metrics equally. We have hundreds of metrics, but I set up dashboards focused on the maybe 12 that actually tell me if the service is healthy. If those are green, we’re good. If anything is red, I investigate. I also spend time understanding the baseline for each metric. A p99 latency of 2 seconds might be normal if we’re doing complex queries, but it’s a disaster if we should be responding in milliseconds.”

Tip for personalizing: Explain the specific metrics you monitor for your service. Give thresholds that matter. Show that you’ve thought about what healthy looks like.

How would you improve a system with high on-call alert fatigue?

Why they ask: Alert fatigue is a widespread problem. They want to see if you can diagnose the root cause and implement a solution that actually works.

Sample answer:

“Alert fatigue usually means you’re alerting on symptoms that aren’t actually user-impacting, or you’re not setting appropriate thresholds. My approach is to audit the alerts. For each alert that’s firing frequently, I ask: if this fires right now, would I wake up? If the answer is no, it shouldn’t page the on-call engineer. It should go to a dashboard that on-call reviews during business hours. We had an alert for ‘latency above 500ms’ that was firing constantly. But when we looked at actual user impact, we weren’t losing requests until latency hit 2 seconds. We also implemented alert suppression rules—during deployments, certain alerts get suppressed because we expect things to be in flux. We set up alert grouping so that if the same root cause triggers 50 alerts, on-call gets one notification instead of 50 pages. We also fixed some fundamental issues—our database was getting slow during backup windows, which triggered dozens of alerts. We moved to incremental backups and the problem went away. I also implemented an SLA for on-call: we shouldn’t be paging more than once per shift on average. When we hit more than that, it’s an organizational priority to fix it. Within six months, we cut false alerts by 80%.”

Tip for personalizing: Talk about alert fatigue you’ve actually addressed. Give specific numbers. Show both tactical fixes (better thresholds) and strategic fixes (actually improving the system).

Describe your experience with security in an SRE context.

Why they ask: Security and reliability are intertwined. They want to know if you think about security as part of your infrastructure work.

Sample answer:

“Security is everyone’s job, but SREs play a particular role because we control access and deployments. We implement least privilege access—developers don’t have production SSH access. We use role-based access control and audit every production access. For patch management, we automate security patches through Ansible to ensure they get applied consistently and quickly. We’ve had zero-day situations where we’ve had a few hours to patch thousands of servers. Automation makes that possible. We also do regular security audits of our infrastructure—checking for misconfigured security groups, exposed databases, things like that. We had an incident where a developer accidentally left a temporary RDS instance with public access enabled. Our auditing tool caught it. I also make sure disaster recovery processes include security considerations. If we’re restoring from backup, we need to ensure we’re not restoring credentials or sensitive data to the wrong place. And we have an incident response plan specifically for security incidents—different from operational incidents because you need different communication protocols and evidence preservation.”

Tip for personalizing: Talk about security practices you’ve implemented. Mention specific tools or processes. Show that you think about security proactively, not just reactively.

What’s your philosophy on technical debt and how do you balance it with new work?

Why they ask: SREs often inherit legacy systems. They want to see if you have a mature approach to managing technical debt rather than ignoring it or spending all your time on it.

Sample answer:

“Technical debt is real, and ignoring it usually costs more than paying it down. I think about it in layers. First, there’s critical debt—systems that are unreliable or pose security risks. That has to be addressed. Second, there’s efficiency debt—systems that work but are inefficient and slow down development. Third, there’s knowledge debt—systems no longer understood by anyone. I prioritize in that order. In my current role, we had a deployment tool that nobody understood anymore and it was causing frequent deployment failures. We rebuilt it, and deployment success rate went from 92% to 99%. That was worth the time. The mistake I see is treating all technical debt equally or ignoring it entirely. I also try to be opportunistic—if we’re working on a system anyway, we address debt in that area. And I always budget for debt reduction. If 100% of your time goes to new features, your systems will slowly degrade. We aim for 20-30% of capacity going to infrastructure improvements and debt reduction. I also make it visible to leadership. When deployment takes 45 minutes and we could get it down to 10 minutes by spending two weeks, I show the cost of the delay and make the business case.”

Tip for personalizing: Give a concrete example of technical debt you’ve addressed. Explain the impact. Show that you think strategically, not just tactically.

Behavioral Interview Questions for Site Reliability Engineers

Behavioral questions assess your soft skills, decision-making processes, and how you work with others. Use the STAR method: Situation, Task, Action, Result.

Tell me about a time you had to communicate a complex technical issue to non-technical stakeholders.

Why they ask: SREs bridge technical and business teams. Communication skills are critical, especially during incidents when leadership needs to understand impact and timeline.

STAR framework:

• Situation: Describe the technical issue in specific terms. “We had a database performance degradation affecting our checkout service.”
• Task: Explain what you needed to communicate and to whom. “I needed to update the business team on impact, timeline, and how this affected revenue.”
• Action: Walk through how you explained it simply. “Rather than diving into query optimization, I said: ‘Customers are experiencing 30-second checkout delays. This is affecting conversion. We’ll have it fixed in 2 hours.’ I provided hourly updates.”
• Result: Share the outcome. “Leadership stayed informed without panic, and we successfully resolved it. They later used my updates as a template for incident communication.”

How to personalize: Replace the specific service with one you’ve worked on. Explain what jargon you avoided and how you framed things in business terms. Show that you understand what leadership actually cares about—impact and timeline.

Describe a situation where you disagreed with a team member about the right approach and how you handled it.

Why they ask: SRE work often involves tough calls about reliability vs. velocity. They want to see if you can disagree respectfully and find solutions rather than digging in.

STAR framework:

• Situation: Set up the conflict. “A developer wanted to deploy a major feature change without a canary deployment. Our latency was already high, and I was concerned about customer impact.”
• Task: Explain your position. “I needed to either convince them to canary or understand why they felt confident in a full rollout.”
• Action: Show how you approached it professionally. “I asked questions rather than saying no: ‘Walk me through your testing. What’s our rollback plan? What’s the risk if this causes a 10% latency increase?’ We looked at error budget—we didn’t have much margin. We compromised: 10% canary for 30 minutes, then gradual rollout if metrics looked good.”
• Result: Demonstrate what you learned. “We caught a subtle performance regression in the canary that wouldn’t have been caught in testing. It reinforced why we have these processes. The developer respected the rigor after seeing it work.”

How to personalize: Use a real disagreement you’ve had. Be honest about whether you were right or wrong. Show growth in how you handle disagreements.

Tell me about a time you made a mistake. How did you handle it and what did you learn?

Why they ask: This tests your accountability and growth mindset. SRE is too complex to never make mistakes—they want to see how you handle them.

STAR framework:

• Situation: Be specific about the mistake. “I accidentally deployed an incomplete database migration to production during a Friday afternoon.”
• Task: Explain the stakes. “This broke a critical data pipeline affecting our data team’s weekend analysis.”
• Action: Show your response. “I immediately notified my manager and the affected team, started a war room, and worked on rolling back safely. Rollback itself took 30 minutes. I stayed on-call through the weekend to monitor for issues. We did a blameless post-mortem and identified that our deployment checklist didn’t require verification that migrations were complete.”
• Result: Show what you learned and changed. “We now have a pre-deployment verification step, and I’m more cautious about Friday deployments. I also learned to ask for code review from someone senior when I’m tired or stressed, not to push through.”

How to personalize: Choose a mistake that taught you something real. Don’t make it too catastrophic—you want to show growth, not recklessness. Be humble and show what specifically changed because of it.

Tell me about your experience working in a cross-functional team or during a critical incident.

Why they ask: SREs work with developers, database teams, network engineers, and leadership. They want to see if you can collaborate effectively under pressure.

STAR framework:

• Situation: Set the scene with high stakes. “During a complete database failure at 2 AM on a Tuesday, I was working with database engineers, backend developers, and infrastructure team.”
• Task: Explain your specific role. “I was coordinating between teams—making sure everyone understood what was being tried, communicating with leadership, and documenting decisions for our post-mortem.”
• Action: Show how you enabled collaboration. “I opened a Slack war room and established a ‘single source of truth’ channel where decisions were logged. I asked clarifying questions to make sure the database team and backend team understood each other’s constraints. When someone proposed an aggressive recovery method, I asked about rollback risk. We chose a more conservative approach.”
• Result: Explain the outcome and team dynamics. “We recovered in 90 minutes with no further data loss. More importantly, the team told me afterward that having clear communication made a stressful situation manageable. It reinforced for me how much incident management is about coordination, not just technical skill.”

How to personalize: Talk about a real incident you were part of. Explain your specific contribution to resolution. Show that you enabled others to work more effectively.

Tell me about a time you had to learn something new quickly on the job.

Why they asks: Technology changes fast. They want to see if you’re a self-directed learner and if you can pick up new skills under pressure.

STAR framework:

• Situation: Describe the gap. “My company decided to migrate from on-premises infrastructure to Kubernetes, and I had no Kubernetes experience.”
• Task: Explain what you needed to learn. “We had six weeks before the migration, and I needed to be proficient enough to troubleshoot issues and make architecture decisions.”
• Action: Walk through your learning process. “I took an online course, read the official Kubernetes documentation, and set up a test cluster. I also paired with a senior engineer who knew Kubernetes to review my decisions and help me understand the operational model. I focused on the 20% of concepts that applied to our use case rather than trying to learn everything.”
• Result: Show the outcome. “By migration day, I could handle basic troubleshooting and we caught several architectural issues in our planning. Six months in, I’m confident enough to mentor new team members on Kubernetes basics. The key was being intentional about learning—focusing on what mattered to our specific situation.”

How to personalize: Use a technology you’ve actually learned on the job. Explain your learning strategy—what resources worked for you. Show that you balance learning with shipping.

Describe a time you had to advocate for an unpopular but necessary decision.

Why they ask: SREs often need to say “no” to deployments or demand reliability work that seems costly. They want to see if you can make a case and stick to it respectfully.

STAR framework:

• Situation: Describe the pressure. “We were under deadline to ship a major feature, and I recommended we delay because our testing infrastructure wasn’t reliable enough.”
• Task: Explain your dilemma. “I knew delaying would be unpopular with leadership and the product team, but I believed it was the right call.”
• Action: Show how you made your case. “I presented data: we had failed to catch issues in testing 40% of the time over the past quarter. When those issues reached production, we had to deal with emergency patches. I showed the cost of an hour of production outage versus one week of delay. I also offered to help fix the testing infrastructure and gave a realistic timeline. I wasn’t saying ‘no’—I was saying ‘not yet, here’s why, here’s how we fix it.’”
• Result: Demonstrate respect for the decision. “Leadership agreed to delay two weeks. We made improvements to testing, and we caught issues in the new feature before it went live. But I’ve also had situations where I made the case and leadership decided differently. I respected that decision—ultimately, it’s not my call to make alone.”

How to personalize: Talk about a decision you advocated for that was ultimately right or wrong. Show that you make evidence-based arguments, not just gut feelings. Demonstrate that you respect organizational decision-making even when you disagree.

Technical Interview Questions for Site Reliability Engineers

These questions dig deeper into technical concepts specific to SRE work.

Design a monitoring and alerting strategy for a microservices-based e-commerce platform.

Why they ask: Monitoring is fundamental to SRE. This tests your ability to think through an entire observability strategy, not just install a tool.

Framework for answering:

1. Clarify the system: Ask about scale (QPS, regions, services), current tools, and pain points.
2. Define SLOs first: “If we’re building monitoring for an e-commerce platform, we first need to ask: what’s our availability SLO? Our latency SLO? These drive what we need to monitor.”
3. Implement the RED method: Rate of requests, Error rate, Duration (latency). “For each microservice, we’d instrument these metrics.”
4. Add infrastructure metrics: CPU, memory, disk I/O, network saturation per instance.
5. Distributed tracing: “Since it’s microservices, a single user request touches multiple services. We need distributed tracing (Jaeger, Zipkin) to trace requests end-to-end.”
6. Structured logging: “We’d standardize on JSON logs so we can query them—search by customer ID, trace ID, or error type.”
7. Alerting rules: “We’d alert on symptoms, not metrics. Instead of ‘CPU above 80%,’ we alert on ‘latency above SLO threshold’ or ‘error rate above X%.’ We’d need alert grouping to avoid alert fatigue.”
8. Dashboards: “We’d have a ‘health dashboard’ with the 10-15 metrics that actually matter for on-call engineers.”

Sample answer:

“I’d start by understanding the SLOs for the platform, because monitoring flows from those. For an e-commerce platform, uptime and checkout latency are critical. I’d instrument RED metrics for each service—Prometheus is a good choice here. We’d ship metrics from every service into a central Prometheus, plus use distributed tracing for understanding cross-service latency. For alerting, I’d avoid alerting on infrastructure metrics alone. Instead, I’d alert on user-impacting issues: checkout latency above 1 second, error rate above 0.5%, or availability below SLO. I’d set up alert grouping by root cause so that if a single issue triggers 50 alerts, on-call gets one. For the on-call dashboard, I’d focus on the 12 metrics that actually tell you if the system is healthy. Everything else lives in detailed dashboards for root cause analysis, not on-call visibility.”

Tip for personalizing: Mention monitoring tools you’ve actually used. Go deeper on tools your target company uses—if they mention they use DataDog, explain how you’d set it up in DataDog specifically.

Walk me through how you’d troubleshoot a memory leak in a production service.

Why they ask: This tests your troubleshooting methodology and your understanding of how systems actually behave.

Framework for answering:

1. Define the problem: Is memory growing linearly? Exponentially? “I’d pull metrics to see if it’s a gradual leak or sudden increase.”
2. Rule out obvious causes: “Is this expected behavior? Is the service just starting up and loading data? Are we caching things that should be expired?”
3. Check GC behavior: “If it’s a JVM service, I’d look at garbage collection metrics. A memory leak might show as increasing ‘old generation’ usage if garbage collection isn’t reclaiming memory.”
4. Use profiling tools: “I’d enable memory profiling—JVM profiler, Go pprof, Python memory_profiler—to identify which code path is allocating memory.”
5. Compare versions: “If this is a new problem, compare it to previous versions. If it was recent code, we look at code changes.”
6. Implement a fix: “Once we identify the cause—maybe a cache that’s not evicting, or event listeners not being removed—we’d deploy a fix and monitor it.”
7. Prevent recurrence: “We’d add monitoring for memory growth rate so this would be caught earlier next time.”

Sample answer:

“First, I’d pull memory metrics over time to confirm it’s actually growing. Sometimes what looks like a leak is just seasonal traffic patterns. Assuming it’s real, I’d check garbage collection behavior—if the old generation is growing, that suggests memory that’s not being reclaimed. I’d enable memory profiling for the service, which gives me a breakdown of which objects are consuming memory. Usually, it’s a cache that’s not bounded, event listeners not being cleaned up, or something holding references to data that should be garbage collected. Once I identify the cause, we’d implement a fix—maybe add an eviction policy to the cache or fix the listener cleanup. We’d deploy it to a single instance first, monitor it, then roll it out. To prevent this, we’d add monitoring for memory growth rate as a metric we track—if memory is growing 10% per hour, that’s worth investigating before it brings down the service.”

Tip for personalizing: Mention tools you’ve used for profiling and memory analysis. Talk about actual memory leaks you’ve debugged. Explain your thought process—how