What a Site Reliability Engineer Interview Actually Tests

A Site Reliability Engineer interview tests whether you can build and operate reliable production systems using software-engineering principles.

SREs work across software development, systems engineering, cloud infrastructure, networking, observability, incident response, capacity planning, and automation. The role is not simply monitoring dashboards or restarting failed services. Strong SREs identify why systems fail, automate repetitive operational work, improve architecture, and help teams balance reliability with development speed.

Google describes Site Reliability Engineering as treating operations as a software problem. The goal is to maintain appropriate availability, latency, performance, and capacity while allowing systems to continue changing.

Quick Stats

* Typical process: Around 4 to 6 stages

* Typical timeline: Approximately 3 to 6 weeks

* Common stages: Recruiter screen, coding or scripting, Linux and networking, troubleshooting, system design, and behavioral interview

* Core focus: Production engineering, automation, observability, incident response, scalability, and reliability

* Coding expectations: Usually meaningful, especially in Python, Go, Java, C++, or another general-purpose language

* Main differentiator: Diagnosing production problems methodically while designing long-term fixes instead of repeated manual work

The Five Core Areas

1. Coding and Automation

SREs write software to automate deployment, monitoring, remediation, capacity management, configuration, and operational workflows.

Interviewers may ask traditional coding questions, practical scripting tasks, API exercises, or problems involving logs, events, retries, and distributed workers.

2. Linux and Systems Fundamentals

You may be asked about processes, threads, memory, filesystems, permissions, system calls, signals, CPU usage, disk I/O, and system logs.

The interviewer wants to know whether you can investigate a host rather than simply list commands.

3. Networking

SRE interviews frequently cover DNS, TCP, HTTP, TLS, routing, load balancing, ports, proxies, packet loss, latency, and connection failures.

A common question is to explain everything that happens after a user enters a URL in a browser.

4. Reliability and Distributed Systems

Important concepts include redundancy, replication, consistency, queues, retries, idempotency, backpressure, caching, leader election, regional failure, and graceful degradation.

5. Incident Response and Operational Judgment

Interviewers evaluate how you respond when production is failing. Strong candidates establish impact, mitigate safely, communicate clearly, collect evidence, and separate immediate recovery from long-term prevention.

Core SRE Concepts

Service Level Indicator

A measurable signal representing user experience, such as availability, request latency, successful transaction rate, or data freshness.

Service Level Objective

A target for an SLI over a defined period.

Service Level Agreement

A formal commitment that may include business or financial consequences if reliability targets are not met.

Error Budget

The amount of unreliability permitted by the SLO. Teams can use the remaining budget to balance product velocity against reliability risk.

Toil

Manual, repetitive, automatable operational work that scales with service growth and creates little lasting value.

What Strong SRE Candidates Do

* Investigate evidence before making changes

* Explain systems from the user request down to the operating system

* Write readable and testable automation

* Design around failure rather than assuming components stay healthy

* Connect monitoring to user impact

* Distinguish mitigation from root-cause correction

* Use SLOs to prioritize reliability work

* Create long-term fixes that reduce future operational effort

Use Nora AI's Technical Mode to practice Linux, networking, coding, troubleshooting, and architecture questions. Use Behavioral Mode for outages, on-call pressure, mistakes, disagreement, and postmortem stories.

Typical Site Reliability Engineer Interview Process

The exact process depends on the company and role. Some SRE positions are close to Software Engineering, while others emphasize infrastructure, production operations, cloud platforms, or customer reliability.

Stage 1: Recruiter Screen (20 to 35 minutes)

What to Expect

The recruiter reviews your engineering background, production experience, programming languages, cloud knowledge, on-call experience, location, and compensation expectations.

You may also be asked why you want SRE instead of Software Engineering, DevOps, infrastructure engineering, or systems administration.

Example or Reported Questions

* "Walk me through your technical background."

* "Why Site Reliability Engineering?"

* "Which production systems have you supported?"

* "How much coding do you do in your current role?"

* "Which cloud platforms have you used?"

* "Have you participated in an on-call rotation?"

* "What was the largest system you supported?"

* "Why are you interested in this company?"

Tips

Explain how your work combines engineering and operations. Prepare one example where you automated a recurring problem or improved the reliability of a production system.

Use Nora AI's Standard Mode to rehearse your introduction, motivation, and project overview.

Stage 2: Coding or Scripting Interview (45 to 60 minutes)

What to Expect

You may receive an algorithm problem, practical automation task, log-processing exercise, or backend implementation question.

Google SRE candidates report coding and scripting screens in addition to Linux and troubleshooting rounds. The coding bar can resemble a Software Engineer interview, particularly for software-focused SRE positions.

Example or Reported Questions

* "Process a stream of log events and return the most common errors."

* "Implement a rate limiter."

* "Find duplicate events arriving from several servers."

* "Write a script that checks service health."

* "Design a worker that retries failed jobs safely."

* "Parse a large file without loading it fully into memory."

* "Implement an expiring cache."

* "How would you test this automation?"

* "What happens if the process crashes halfway through?"

* "What is the time and space complexity?"

Tips

Clarify failure behavior, scale, and inputs before coding. In SRE interviews, discuss observability, retries, idempotency, and safe execution when relevant.

Use Nora AI's Technical Mode to practice explaining your solution and responding to production-oriented follow-ups.

Stage 3: Linux, Operating Systems, and Networking (45 to 60 minutes)

What to Expect

This round tests whether you can reason about what happens inside a machine and across a network.

You may be given a slow server, failed process, unreachable endpoint, high memory usage, or DNS issue and asked how you would investigate it.

Example or Reported Questions

* "What happens when you type a command into a Linux shell?"

* "What is the difference between a process and a thread?"

* "How would you investigate high CPU usage?"

* "What causes a process to become a zombie?"

* "How would you determine what is using disk space?"

* "What happens when you enter a URL into a browser?"

* "Explain the TCP handshake."

* "How does DNS resolution work?"

* "What causes packet loss?"

* "How would you troubleshoot intermittent network latency?"

* "What happens during TLS negotiation?"

* "How does a load balancer distribute traffic?"

A recent reported Google SRE interview asked a candidate to explain the full path after entering a URL, including DNS, system calls, sockets, and lower-level operating-system behavior.

Tips

Do not list commands without explaining what each check proves. Move methodically through application, network, host, and infrastructure layers.

Use Nora AI's Technical Mode for end-to-end systems explanations and troubleshooting follow-ups.

Stage 4: Troubleshooting and Incident Response (45 to 60 minutes)

What to Expect

You may receive a production incident involving rising latency, failed requests, missing data, unhealthy hosts, or a recent deployment.

The interviewer wants to see whether you can establish impact, collect evidence, mitigate safely, communicate, and prevent recurrence.

Example or Reported Questions

* "Error rates doubled immediately after a deployment. What do you do?"

* "Users in one region cannot access the service."

* "CPU usage is normal, but latency is increasing."

* "The database is receiving far more traffic than usual."

* "A service is repeatedly restarting."

* "Disk usage is approaching 100 percent."

* "Monitoring shows conflicting signals."

* "The primary on-call engineer cannot identify the cause."

* "How would you decide whether to roll back?"

* "What should happen after the incident?"

A Strong Incident Structure

1) Confirm the symptoms and user impact.

2) Establish when the problem began.

3) Check recent changes.

4) Identify the blast radius.

5) Review high-value metrics, logs, and traces.

6) Mitigate the immediate impact.

7) Communicate status and ownership.

8) Investigate the root cause.

9) create preventive actions.

Tips

Prioritize service restoration over proving a complex theory during the incident. Make reversible changes when possible and communicate uncertainty clearly.

Use Nora AI's Technical Mode for live incidents and Behavioral Mode for ownership, communication, and postmortem questions.

Stage 5: System Design and Reliability Design (45 to 75 minutes)

What to Expect

You may be asked to design a service and then make it reliable. The interviewer may introduce failures, traffic growth, regional outages, or operational constraints.

Example or Reported Questions

* "Design a highly available URL-shortening service."

* "Design a monitoring and alerting platform."

* "Design a distributed job scheduler."

* "Design a multi-region API."

* "Design a log-ingestion system."

* "How would the system survive a database failure?"

* "How would you perform deployments without downtime?"

* "How would you define SLOs for this service?"

* "What should trigger an alert?"

* "How would you test disaster recovery?"

A Strong Design Structure

Begin with users, requirements, scale, and reliability targets.

Then cover architecture, storage, networking, redundancy, failure isolation, observability, deployment, capacity, security, and recovery.

Explain which failures you are designing for and which risks remain.

Tips

Do not simply add replicas to every component. Explain failure domains, consistency requirements, operational complexity, and cost.

Use Nora AI's Technical Mode to practice design follow-ups involving outages, overload, regional failure, and deployment risk.

Stage 6: Behavioral and On-Call Interview (30 to 60 minutes)

What to Expect

This stage evaluates production ownership, teamwork, communication, learning, and judgment under pressure.

Example or Reported Questions

* "Tell me about your most serious production incident."

* "Describe a time your change caused an outage."

* "Tell me about a recurring problem you automated."

* "Describe a disagreement about reliability."

* "Tell me about a time you were paged without enough information."

* "How do you handle on-call fatigue?"

* "Describe a postmortem you contributed to."

* "Tell me about a time you pushed back on a risky launch."

* "How have you reduced operational toil?"

* "Describe a reliability improvement that had measurable impact."

Tips

Prepare stories involving incidents, automation, mistakes, launch risk, unclear ownership, and collaboration with development teams.

Use Nora AI's Behavioral Mode to keep the answers accountable, technically specific, and focused on what changed afterward.

Site Reliability Engineer Interview Questions

SRE interviews combine Software Engineering, operating systems, networking, distributed systems, cloud infrastructure, and incident-management questions.

Linux and Operating Systems

* "What happens when a Linux process starts?"

* "What is a system call?"

* "What is the difference between user space and kernel space?"

* "How do processes communicate?"

* "What is virtual memory?"

* "What causes swapping?"

* "What is a file descriptor?"

* "How would you inspect open network connections?"

* "How do you investigate high load average?"

* "How would you identify a memory leak?"

* "What happens when disk space reaches zero?"

* "How do signals work?"

* "What is an inode?"

* "How would you inspect system logs?"

Useful commands may include ps, top, free, vmstat, iostat, df, du, lsof, ss, ip, journalctl, dmesg, strace, and tcpdump.

Explain the diagnostic purpose of each command rather than merely naming it.

Networking

* "Explain DNS resolution."

* "Explain the TCP three-way handshake."

* "What is the difference between TCP and UDP?"

* "What causes connection timeouts?"

* "What is a subnet?"

* "What is NAT?"

* "How does a reverse proxy work?"

* "What is the difference between a Layer 4 and Layer 7 load balancer?"

* "What happens during TLS negotiation?"

* "How would you investigate packet loss?"

* "What causes intermittent latency?"

* "What is connection pooling?"

* "How does HTTP keep-alive work?"

* "What happens when DNS is unavailable?"

A strong answer moves through the full request path and identifies which evidence would isolate each layer.

Coding and Automation

* "Implement an expiring cache."

* "Process a large log file efficiently."

* "Deduplicate events."

* "Write a health-check service."

* "Implement exponential backoff."

* "Build a worker queue."

* "Limit concurrent requests."

* "Aggregate metrics by time window."

* "Detect failing hosts from monitoring events."

* "How would you make the script safe to rerun?"

Production automation should be observable, testable, idempotent, and safe during partial failure.

Observability

* "What is the difference between metrics, logs, and traces?"

* "What makes a useful alert?"

* "Why are high-cardinality metrics risky?"

* "How do you monitor a distributed service?"

* "What is the difference between symptoms and causes?"

* "What would you include in a service dashboard?"

* "How do you reduce alert fatigue?"

* "What is a burn-rate alert?"

* "How would you detect a partial outage?"

* "How do you monitor a background job?"

Good monitoring reflects user experience and supports investigation. Avoid alerts that fire for conditions requiring no action.

SLOs and Error Budgets

* "What is an SLI?"

* "How do SLOs differ from SLAs?"

* "What is an error budget?"

* "How would you define an availability SLO?"

* "Which latency percentile would you measure?"

* "How do you choose an appropriate target?"

* "What should happen when the error budget is exhausted?"

* "How do SLOs influence release decisions?"

* "Can a service be too reliable?"

* "How would you measure reliability for a batch system?"

An SLO should represent an important user experience rather than an internal metric selected because it is easy to collect.

Distributed Systems

* "What is eventual consistency?"

* "How do you handle duplicate messages?"

* "What makes an operation idempotent?"

* "How would you design retries?"

* "What is backpressure?"

* "How do circuit breakers help?"

* "What happens during a network partition?"

* "How do you prevent cascading failure?"

* "What is leader election?"

* "How would you handle a regional outage?"

* "What is the thundering-herd problem?"

* "How do you prevent retry storms?"

* "How would you design graceful degradation?"

* "What delivery guarantee would you choose?"

Strong answers discuss trade-offs, failure modes, and operational consequences.

Cloud and Containers

* "How do containers differ from virtual machines?"

* "What happens when a Kubernetes pod fails?"

* "How do readiness and liveness probes differ?"

* "What is a Kubernetes deployment?"

* "How would you investigate a pod that repeatedly restarts?"

* "How should secrets be managed?"

* "What is infrastructure as code?"

* "How do autoscaling systems make decisions?"

* "What can cause autoscaling to fail?"

* "How would you deploy safely across regions?"

* "What is the purpose of a service mesh?"

* "How do you prevent configuration drift?"

Do not rely entirely on platform terminology. Explain the underlying systems and reliability implications.

Incident Response

* "How do you establish incident severity?"

* "Who should lead an incident?"

* "What is the difference between mitigation and resolution?"

* "When should you roll back?"

* "How often should status updates be sent?"

* "What belongs in an incident timeline?"

* "What makes a useful postmortem?"

* "What does blameless mean?"

* "How do you prioritize corrective actions?"

* "How do you prevent the same incident from recurring?"

* "When should an incident be escalated?"

* "How do you handle several simultaneous alerts?"

The goal is rapid, safe restoration followed by learning and lasting improvement.

Capacity and Performance

* "How would you predict future capacity?"

* "What causes tail latency?"

* "How would you load-test a service?"

* "How do you identify a bottleneck?"

* "What happens when a queue grows without limit?"

* "How would you manage sudden traffic spikes?"

* "How do caching and batching affect performance?"

* "How much spare capacity should a service maintain?"

* "How would you diagnose database saturation?"

* "What signals indicate that scaling is required?"

Capacity planning should account for growth, failure, deployment, seasonal traffic, and recovery requirements.

Behavioral Questions

* "Tell me about a major outage."

* "Describe a production change that failed."

* "Tell me about a manual process you automated."

* "Describe a time you reduced alert noise."

* "Tell me about a difficult on-call shift."

* "Describe a disagreement with a development team."

* "Tell me about a risky release you challenged."

* "Describe a postmortem action you completed."

* "Tell me about a reliability investment you had to justify."

* "Describe a time you made a system simpler."

Use Nora AI's Behavioral Mode to ensure every story explains impact, technical reasoning, communication, and the long-term change.

How to Answer SRE Troubleshooting Questions

Troubleshooting questions evaluate how you think with incomplete information. The best answer is rarely a random list of commands.

1. Establish User Impact

Determine:

* Which users are affected

* Which functions are failing

* Whether the issue is complete or partial

* Which regions or environments are involved

* When the failure began

* Whether the SLO is being violated

Start with symptoms visible to users.

2. Check Recent Changes

Review deployments, configuration changes, infrastructure work, feature flags, traffic shifts, certificate updates, and dependency changes.

A recent change is not automatically the cause, but it is often the fastest hypothesis to evaluate.

3. Examine High-Level Signals

Check:

* Request rate

* Error rate

* Latency

* Saturation

* Dependency health

* Resource usage

* Queue depth

* Regional differences

Use dashboards to narrow the affected layer before inspecting individual hosts.

4. Form and Test Hypotheses

State what you currently believe and what evidence would confirm or reject it.

For example:

"The errors began after the deployment and affect only the new version. I would compare error rates by version and inspect logs for the failing request path."

This is stronger than listing every tool you know.

5. Mitigate Safely

Possible mitigations include:

* Roll back

* Disable a feature flag

* Shift traffic

* Add capacity

* Rate-limit requests

* Remove an unhealthy dependency

* Restore a previous configuration

* Fail over to another region

* Reduce optional functionality

Prefer reversible actions with understood consequences.

6. Communicate

State who owns the incident, current impact, mitigation status, remaining risk, and timing of the next update.

Technical investigation and communication should happen in parallel.

7. Investigate Root Cause

After stability is restored, determine why the failure occurred and why existing safeguards did not prevent or detect it sooner.

8. Prevent Recurrence

Corrective actions may involve:

* Code changes

* Better tests

* Safer deployment

* Improved alerts

* Capacity changes

* Dependency isolation

* Runbook updates

* Automation

* Architecture improvement

* Clearer ownership

Scenario: Latency Is Rising but CPU Is Normal

Do not conclude that capacity is healthy merely because CPU is low.

Investigate:

* Database latency

* Dependency response times

* Thread or connection pools

* Lock contention

* Disk I/O

* Network latency

* Queue depth

* Garbage collection

* Request distribution

* Cache hit rate

* Timeout and retry behavior

The bottleneck may exist outside the application CPU.

Scenario: Error Rates Increase After Deployment

Compare the new and previous versions, inspect error types, determine the blast radius, and decide whether rollback is safe.

If rollback is the fastest reliable mitigation, restore service first. Investigate the specific defect afterward.

Scenario: One Region Is Failing

Determine whether the issue affects application instances, networking, DNS, storage, dependencies, or regional infrastructure.

Consider shifting traffic only after confirming that healthy regions have enough capacity to absorb it.

Scenario: Disk Usage Is Nearly Full

Identify which filesystem and files are growing. Check logs, temporary files, deleted-but-open files, database growth, and retention changes.

Avoid deleting files blindly. Free space safely, protect important data, and correct the underlying growth or retention issue.

Common Troubleshooting Mistakes

* Starting with a preferred theory

* Investigating one host before understanding the blast radius

* Making several changes simultaneously

* Ignoring recent deployments

* Treating dashboards as proof rather than evidence

* Restarting services without understanding the impact

* Forgetting dependency failures

* Allowing retries to worsen overload

* Focusing on root cause before restoring service

* Ending without preventive actions

How Nora AI Helps

Use Nora AI's Technical Mode for outage scenarios involving latency, networking, Linux, databases, Kubernetes, and distributed systems.

Ask Nora to add changing conditions, such as a failed rollback, overloaded backup region, or unreliable monitoring. Use Behavioral Mode for communication, ownership, and postmortem questions.

How Site Reliability Engineer Interviews Differ

SRE titles are not standardized. Some roles are highly software-focused, while others resemble production engineering, platform engineering, DevOps, or cloud operations.

Google

Google originated the SRE discipline and describes it as combining software and systems engineering to run large-scale, fault-tolerant systems.

Google SRE interviews commonly emphasize:

* Coding or scripting

* Linux and operating systems

* Networking

* Troubleshooting

* Distributed systems

* System design

* Behavioral judgment

Reported candidates describe specialized loops containing coding, Linux-heavy technical rounds, troubleshooting, and behavioral interviews.

Google also distinguishes between software-oriented and systems-oriented SRE backgrounds, although both require strong production reasoning.

Meta Production Engineering

Meta commonly uses the title Production Engineer rather than SRE.

The work overlaps in areas such as:

* Linux

* Networking

* Coding

* Distributed systems

* Capacity

* Performance

* Incident response

* Production automation

Production Engineering interviews may emphasize deep systems knowledge and coding alongside large-scale operational judgment.

Cloud Providers

AWS, Microsoft Azure, and Google Cloud reliability roles may focus on:

* Cloud infrastructure

* Distributed services

* Networking

* Containers

* Automation

* Incident response

* Customer impact

* Regional reliability

* Capacity

* Security

Some roles operate the provider's own services, while others support customer-facing reliability. Read the posting carefully.

Developer and Infrastructure Companies

Databases, observability platforms, developer tools, and infrastructure startups may expect deeper knowledge of the product domain.

For example:

* Database SRE: replication, storage, transactions, backups, and query performance

* Kubernetes SRE: containers, orchestration, networking, scheduling, and cluster operations

* Security SRE: identity, secrets, access control, incident response, and secure infrastructure

* AI infrastructure SRE: accelerators, distributed training, model serving, capacity, and data pipelines

Startup SRE Roles

At startups, the SRE may own cloud infrastructure, CI/CD, Kubernetes, monitoring, security, databases, incident response, and cost management.

Interviews may be more practical and broad. You may be asked to review the company's architecture, debug a deployment, or design the first reliability program.

Avoid proposing highly complex infrastructure that the team cannot operate.

SRE vs. DevOps Engineer

DevOps is commonly used to describe development and operations practices, collaboration, automation, and delivery.

SRE applies specific reliability practices such as SLOs, error budgets, toil reduction, monitoring, incident response, and software-driven operations.

In real organizations, the roles often overlap.

SRE vs. Platform Engineer

Platform Engineers commonly build internal tools and infrastructure that make development easier.

SREs more directly own or influence production reliability, incident response, service health, and reliability objectives.

A platform team can use SRE principles, and an SRE team may build platform capabilities.

Junior SREs

Entry-level interviews may emphasize:

* Linux fundamentals

* Basic networking

* Scripting

* Cloud concepts

* Monitoring

* Troubleshooting

* Learning ability

* Safe escalation

Interviewers may not expect extensive incident leadership, but they want structured reasoning and solid fundamentals.

Senior SREs

Senior candidates may be evaluated on:

* Multi-region architecture

* SLO strategy

* Major incidents

* Capacity planning

* Reliability roadmaps

* Cross-team influence

* Reducing organizational toil

* Mentoring

* Production risk

* Long-term system improvement

Senior answers should show impact across services or teams rather than only resolving individual tickets.

Frequently Asked Questions (FAQ)

1) How many rounds are in an SRE interview?

Most processes include approximately 4 to 6 stages:

* Recruiter screen

* Coding or scripting interview

* Linux and networking round

* Troubleshooting interview

* System-design interview

* Behavioral or hiring-manager conversation

Some companies combine Linux, networking, and troubleshooting into one or two rounds.

2) Do SRE interviews include coding?

Usually, yes.

The role applies software engineering to operational problems, so companies commonly expect proficiency in at least one programming language.

Coding may involve algorithms, scripting, APIs, automation, log processing, concurrency, or practical backend tasks.

3) How much Linux should I know?

You should understand processes, threads, memory, filesystems, permissions, networking, logs, system calls, CPU usage, disk I/O, and service management.

More importantly, you should be able to use those concepts to investigate an unfamiliar problem.

4) How much networking should I study?

Study:

* DNS

* TCP and UDP

* HTTP and HTTPS

* TLS

* IP addressing

* Subnets

* Routing

* NAT

* Load balancing

* Proxies

* Packet loss

* Latency

* Connection states

* Basic packet analysis

Practice explaining a request from browser to server and back.

5) What is the difference between an SLI, SLO, and SLA?

An SLI is a measurement of service behavior.

An SLO is the reliability target for that measurement.

An SLA is a formal commitment that may include consequences when the service fails to meet an agreed target.

6) What is an error budget?

An error budget is the amount of unreliability allowed by an SLO.

If a service has a 99.9 percent availability objective, the remaining 0.1 percent represents the permitted failure budget during the measurement window.

Teams can use error-budget consumption to make release and reliability decisions.

7) What is toil?

Toil is repetitive, manual, automatable operational work that grows with the service and produces little lasting value.

Examples include repeated restarts, manual deployments, routine account changes, and recurring ticket work.

An SRE should automate or eliminate toil when the long-term benefit justifies the effort.

8) How should I answer an incident question?

Use this sequence:

1) Confirm user impact.

2) Establish timeline and blast radius.

3) Check recent changes.

4) Review high-value signals.

5) Form and test hypotheses.

6) Mitigate safely.

7) Communicate status.

8) Find the root cause.

9) Prevent recurrence.

Do not jump immediately to one command or one suspected cause.

9) What system-design topics should I study?

Focus on:

* Load balancing

* Caching

* Databases

* Replication

* Queues

* Multi-region systems

* Failure isolation

* Rate limiting

* Backpressure

* Deployment strategies

* Monitoring

* Disaster recovery

* Capacity planning

* Graceful degradation

Always connect design choices to reliability requirements.

10) Do I need Kubernetes experience?

Not every SRE role requires Kubernetes, but many modern infrastructure positions use it.

Know the fundamentals of pods, deployments, services, scheduling, probes, resource limits, autoscaling, logs, networking, and rollout behavior when the target role mentions Kubernetes.

11) What behavioral stories should I prepare?

Prepare examples involving:

* A production outage

* A failed deployment

* An operational mistake

* Automation

* Toil reduction

* Alert fatigue

* On-call pressure

* Reliability disagreement

* A risky launch

* A postmortem

* Capacity failure

* Cross-team influence

Use Nora AI's Behavioral Mode to make the stories technically clear and accountable.

12) What should I ask the interviewer?

Useful questions include:

* "How are SLOs defined and reviewed?"

* "How much time is spent on coding versus operational work?"

* "What is the on-call rotation?"

* "How frequently are engineers paged?"

* "How does the team measure and reduce toil?"

* "Who owns incident command?"

* "How are postmortem actions tracked?"

* "How does SRE work with product engineering?"

* "What are the largest reliability risks today?"

* "What would success look like in the first six months?"

These questions help reveal whether the role follows genuine SRE practices or is primarily reactive operations.

13) Which Nora AI mode should I use?

Use:

* Technical Mode: Coding, Linux, networking, distributed systems, observability, system design, and troubleshooting

* Behavioral Mode: Outages, mistakes, on-call pressure, disagreement, postmortems, and reliability leadership

* Standard Mode: A realistic mixed SRE interview combining background, technical questions, incidents, and project experience

* Salary Negotiation Mode: Base salary, equity, on-call compensation, level, signing bonus, and benefits

A useful sequence is:

* Session 1: Technical Mode for Linux and networking

* Session 2: Technical Mode for coding and automation

* Session 3: Technical Mode for troubleshooting

* Session 4: Technical Mode for reliability system design

* Session 5: Behavioral Mode for incident stories

* Session 6: Standard Mode for a complete mixed loop

14) What is the best way to practice?

Combine technical study with spoken troubleshooting.

Practice:

* Explaining a browser request end to end

* Debugging a slow service

* Investigating high memory or disk usage

* Designing alerts

* Defining SLOs

* Responding to an outage

* Designing for regional failure

* Writing safe automation

* Explaining a major incident

* Identifying and reducing toil

Use Nora AI's Technical Mode to defend your diagnosis and architecture while Nora adds changing conditions. Use Behavioral Mode for outage and ownership stories, then Standard Mode for a complete SRE interview.

Nora provides immediate feedback on technical clarity, troubleshooting structure, production judgment, communication, and whether your answer addresses both immediate recovery and long-term reliability.