Mock Interview Questions for NRE Job Roles | SPOTO

An inode is a data structure in Unix/Linux that contains metadata about a file. Some of the items contained in an inode are: - mode - owner (UID, GID) - size - atime, ctime, mtime - acl's - a blocks list of where the data is The filename is present in the parent directory's inode structure.

Stateful applications in a containerized environment are managed using StatefulSets in Kubernetes, which provide stable network identities, persistent storage, and ordered deployment and scaling for stateful applications.

Chaos engineering is testing the candidacy of a system in failure by purposefully injecting faults to stress its resilience during a failure, thus checking for weaknesses and failures and improving the systems to act against unexpected behaviour. Teams make their systems even more robust, simulating how the system should behave in a whole system outage.

Chaos engineering involves intentionally introducing failures into a system to test its resilience. This practice ensures that systems can handle unexpected events and recover gracefully.

I've worked as a site reliability engineer for around five years, primarily in the e-commerce sector. My role involved ensuring the reliability and scalability of high-traffic web applications. I've gained extensive experience in designing, building, and maintaining the infrastructures of these applications, primarily using cloud platforms like AWS and Azure. A vital part of my work also included crafting effective alerting systems to minimize downtime, and automating repetitive tasks to improve system efficiency. Additionally, I've had the responsibility of orchestrating collaborative responses to incidents, performing postmortems, and implementing problem-solving strategies to prevent recurrence.

- Identify the culprit process using monitoring tools or top. - Scale up or out by adding more resources. - Investigate potential memory leaks or inefficient queries and optimize code. - Implement auto-scaling to prevent future occurrences.

Sensitive data can be stored safely and managed, ensuring it's encrypted both in transit and at rest, through tools like HashiCorp Vault or AWS Secrets Manager. Least privilege access principles are used to restrict access to retrieving the necessary secrets for their operation only to those services or users authorized to have them.

Site Reliability Engineering (SRE) is a discipline that incorporates software engineering principles to solve infrastructure and operations challenges. Unlike traditional operations, SRE emphasizes automation, reliability, and scalability, proactively managing incidents and continuously improving systems.

At Siemens, I noticed that our application was experiencing downtime due to database connection limits. I led a team to analyze our usage patterns and implemented a connection pooling solution. This reduced downtime by 60% and improved overall system performance. This project taught me the importance of proactive monitoring and cross-team collaboration.

Common causes include network latency or congestion between services, resource contention (CPU/memory) on overloaded servers, inefficient database queries, blocking I/O operations, serialization/deserialization overhead, or slow dependencies between microservices.

Simple: What happens when you type in 'www.cnn.com' in your browser?

The circuit breaker pattern is a fault-tolerance mechanism that stops requests from reaching a service when it's detected to be failing. - Closed State: The circuit allows requests as normal. - Open State: Requests are blocked, and the system immediately returns an error, preventing cascading failures. - Half-Open State: Allows a limited number of requests to check if the service has recovered. This pattern improves reliability by preventing downstream failures from overwhelming upstream services and helps avoid performance degradation.

Active-active failover involves multiple systems actively serving traffic, providing higher availability and load balancing. Active-passive failover has a primary active system with a standby passive system that takes over only if the primary fails, providing a backup.

- Use a centralized logging solution like the ELK Stack (Elasticsearch, Logstash, Kibana), Graylog, or Fluentd to collect logs from distributed systems. - Implement log forwarding agents on each node to send logs to the centralized platform. - Apply log rotation and retention policies to manage the storage of logs and avoid running out of disk space. - Use log analytics tools to search, filter, and visualize logs to identify and troubleshoot issues. - Tag logs with metadata (e.g., service name, instance ID) to easily identify the source of issues in complex, distributed environments.

This question evaluates the candidate's approach to performance management. They should discuss using performance metrics, setting up alerts for threshold breaches, and tools or practices for performance tuning and optimization.

- Synchronous Communication: Services communicate in real time (e.g., REST APIs). It introduces latency and increases the risk of cascading failures. - Asynchronous Communication: Services send messages without waiting for a response (e.g., message queues like RabbitMQ or Kafka). This decouples services, improving reliability and availability.

To create a simple REST API in Node.js that returns a list of users, I would use Express to set up the server and define a route that handles GET requests. Here's a basic example: const express = require('express'); const app = express(); const users = [{ id: 1, name: 'John Doe' }, { id: 2, name: 'Jane Doe' }]; app.get('/users', (req, res) => { res.json(users); }); app.listen(3000, () => { console.log('Server is running on port 3000'); });

High availability is ensured through redundancy, failover mechanisms, load balancing, and designing systems to avoid single points of failure.

The two forms of file system links that used to distribute files between directories are hardlinks and softlinks. Soft links generate a single reference to the position of a file in one location, whereas hard links provide a single reference to a file in two different locations. Each hardlink you make has the exact same length as the original.

Under /proc, there are three subdirectories: (The answer is not explicitly provided in the text, but the question is asked. The text states: 'Under /proc, there are three subdirectories:' without listing them. The answer field is left as is based on the available content.)

I actively participate in reliability engineering conferences and webinars, which keeps me informed about the latest trends. I also establish a monthly knowledge-sharing session within my team where we discuss new tools and best practices. Recently, we adopted a new monitoring tool that improved our incident response time by 30%, demonstrating the value of ongoing learning.

A failover system automatically switches to a backup system or component when the primary one fails, ensuring continuous availability.

In my previous role, we had a product with a higher than expected failure rate. After performing an FMEA, I identified that a specific component was causing the problem. I recommended a design change which was implemented and led to a 20% increase in product reliability.

I can recall a significant outage we experienced with our main e-commerce platform's search service about a year ago. It was a Saturday morning, peak shopping hours, when suddenly search results stopped appearing for customers. Users were getting empty pages or timeout errors whenever they tried to search for products. Our monitoring immediately flagged a critical alert for the search service's API endpoints returning 5xx errors, and the request latency had shot up dramatically. As the on-call Site Reliability Engineer, I received the page and immediately jumped into action. My first step was to acknowledge the alert and confirm the scope of the problem. I checked our main dashboards for the search service, confirming that almost all requests were failing and the service wasn't processing any queries. I also quickly looked at dependent services, like the product catalog, to ensure they were healthy, which they were. This helped narrow down the problem to the search service itself. I then joined our incident bridge and started coordinating with other team members who had been paged. My initial hypothesis was a resource saturation issue or a recent deployment problem. I checked recent deployments first, but there hadn't been any changes to the search service in the last 24 hours. Next, I looked at resource utilization metrics for the service's Kubernetes pods: CPU, memory, and network I/O. Everything looked normal there, which was perplexing. The service was failing, but its underlying infrastructure resources seemed fine. Diving into the service logs, I started seeing a flood of "connection refused" errors pointing to our Elasticsearch cluster, which was the backend for the search service. This was the critical clue. I pivoted to checking the Elasticsearch cluster metrics. That's when I saw the problem: one of the Elasticsearch data nodes had completely gone offline. It wasn't just unhealthy; it was completely unresponsive and unregistered from the cluster. The remaining nodes were struggling to handle the increased load and shard rebalancing, leading to timeouts and eventual connection refusals from the search service. My immediate mitigation strategy was to bring the dead Elasticsearch node back online. I tried a simple restart of the instance hosting it, but that failed. It appeared the underlying disk had failed. Since our Elasticsearch cluster was configured with replication, the data was still safe on other nodes. I initiated a process to provision a new instance, attach it to the cluster, and let Elasticsearch handle the data replication and rebalancing. While the new node was spinning up, I also scaled up the search service itself temporarily, hoping to distribute some of the load and prevent a full collapse, even though it wouldn't solve the root cause. This provided some minor relief, but the core problem persisted until the new Elasticsearch node was fully integrated. It took about 45 minutes from the initial alert to get the new Elasticsearch node fully operational and for the cluster to stabilize and regain full health. Once the new node was part of the cluster and shards were rebalanced, the "connection refused" errors stopped, and the search service immediately recovered, returning to normal operation. We monitored it closely for another hour to ensure stability. The key learning from this outage was multi-faceted. First, our monitoring for the Elasticsearch cluster itself wasn't granular enough. We had alerts for overall cluster health, but a single data node going completely offline wasn't immediately triggering a critical PagerDuty alert; it was masked by the overall cluster health metric initially, which only degraded severely once other nodes started struggling. We needed more specific alerts for individual node health and disk status. Second, our runbook for Elasticsearch node failures was reactive. We improved it to include automated provisioning of new nodes in case of unrecoverable hardware failure, rather than relying on manual intervention. Third, we didn't have a clear "blast radius" understanding for a single node failure. We assumed our replication factor was enough to absorb a single node loss seamlessly, but the rebalancing process itself caused significant performance degradation. We decided to increase our cluster size by adding more nodes, distributing the load more widely and providing greater fault tolerance for individual node failures. Finally, it reinforced the importance of quick, calm, and systematic troubleshooting, starting broad and then narrowing down to the specific component failure based on logs and metrics. We also held a blameless post-mortem, focusing on system improvements rather than individual mistakes, which was crucial for fostering a culture of continuous learning.

Sharding is a very important concept that helps the system to keep data in different resources according to the sharding process. The word “Shard” means “a small part of a whole“. Hence Sharding means dividing a larger part into smaller parts. In DBMS, Sharding is a type of database partitioning in which a large database is divided or partitioned into smaller data and different nodes. These shards are not only smaller, but also faster and hence easily manageable.

The Four Golden Signals are metrics used to measure the health of a system: - Latency: Time taken to serve a request. - Traffic: The demand placed on your system (e.g., requests per second). - Errors: The rate of failed requests. - Saturation: How close the system is to its full capacity.

An error budget is a way of tracking how much downtime or errors a service can have before it is no longer meeting its Service Level Agreement (SLA). By using error budgets, SRE teams can ensure the reliability of services while still allowing innovation. In SRE, error budgets are used to: - Set expectations: Error budgets help stakeholders set expectations about downtime or errors acceptable. This can help avoid surprises when a service experiences an outage. - Make decisions: Error budgets can be used to decide whether to release new features or take on new projects. If a service is close to its error budget, it may be a wise idea to pause new development work to focus on improving reliability. - Measure progress: Error budgets can be used to measure progress over time. For example, if a service has a 99.9% uptime SLA, its error budget would be 0.1%. If the service's error rate is currently 0.05%, it is on track to meet its SLA.

A service mesh (e.g., Istio, Linkerd) is an infrastructure layer that manages communication between microservices. It provides the following features: - Traffic management: Handles routing, load balancing, and retries. - Security: Offers mutual TLS (mTLS) for secure communication between services. - Observability: Provides metrics, logs, and distributed tracing for monitoring. - Resilience: Supports circuit breakers, rate-limiting, and failovers. It helps by abstracting the complexity of inter-service communication, allowing developers to focus on business logic while the mesh handles service-to-service interactions.

Anything that can be accurately monitored and used to help you think through, define, and assess whether you are meeting SLOs and SLAs is referred to as a service-level indicator (SLI). They are frequently expressed as the proportion of exceptional occurrences to all events. The ratio of the total amount of HTTP inquiries to the number of HTTP requests that were successful is a straightforward example.

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.

Proper documentation is a critical aspect of software development and system management, and I utilize a mix of methods to document my work. For coding, I'm a huge proponent of code being self-documenting as far as possible. I use meaningful variable and function names, and keep functions and classes compact and focused on doing one thing. When necessary, I add comments to explain complex logic or algorithms that can't be expressed clearly through just code. For code or software documentation, I use tools like Doxygen or JavaDoc. They create comprehensive documentation based on specially-formatted comments in source code, describing the functionality of classes, methods, and variables. As for documenting system configurations, I prefer to have configuration files stored in a version control system like Git. This provides an implicit documentation of changes made over time, who made them, and why. For complex system-level changes, I write separate documentation which provides an overview of the system, important configurations, and step-by-step procedures for performing common tasks. The aim is always to ensure that anyone with sufficient access can understand and manage the system without needing to figure things out from scratch. I also make use of README files in our Git repositories, and on more significant projects, we have employed wiki-style tools like Confluence to document architectures, workflows and decisions at a more macro level. GitHub's wiki feature is also handy for this.

My first step to troubleshoot a service outage is to acknowledge the issue and gather as much information as possible. I'd look into our monitoring and logging system to understand what triggered the incident. Next, I'd engage the right team members to dive deeper into the issue, as often, expertise from different domains may be required to identify the root cause.

Security is ensured through regular vulnerability assessments, implementing best practices like least privilege access, encryption, and monitoring for suspicious activities.

The SLO stands for Service Level Objective, which is the agreement within the SLA about a specific metric, such as uptime or response time. They are agreed-upon targets within an SLA, which might be achieved for each activity, function and process to provide the best opportunity for consumer success. It also includes business matrices like conversion rates, uptime and availability.

This tests whether candidates recognize that the hardest part of real incidents is quickly stitching together identity, network reachability, and workload context to understand blast radius.

To back up a directory to a remote server, you can use a Bash script with rsync for efficient file transfer. Here's a simple example: rsync -avz /local/directory user@remote:/remote/directory

Load shedding involves intentionally dropping or refusing to process some requests when a system is overloaded to protect its core functionality and prevent complete failure. This can be done by prioritizing critical requests and shedding less critical load.

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.

Most site reliability engineer interviews at top companies follow a predictable 4-round structure: 1. Online Assessment (OA) - Timed coding problems testing algorithms, data structures, and problem-solving skills under pressure. 2. Technical Phone Screen - One-on-one interview focused on linux and networking. Expect live problem-solving. 3. Virtual Onsite — Technical - Deep dive into observability, incident-management, system-design, automation. Multiple back-to-back rounds. 4. Behavioral & Hiring Manager - STAR method behavioral questions, cultural fit assessment, and team matching discussions.

An SLI is a measurement of a service's performance, such as latency or error rate. An error budget is the amount of unreliability a service can tolerate over a period, calculated as 1 minus the SLO. SREs use error budgets to decide when to prioritize reliability over new features.

Site Reliability Engineering (SRE) is in charge of putting the product that the Core Development team made into action. The main goal of SREs is to implement and automate DevOps practices to reduce the number of problems and make the system more reliable and able to grow.

Address Resolution Protocol is referred to as ARP. ARP is a protocol that permits device communication on local networks. It makes it possible for devices connected to the same network to discover each other's MAC address, IP address, as well as other network details. In order for network devices to communicate with one another, it is used to dynamically assign An ip address to those devices. There are three basic stages to this process: ARP packets search for any devices with an IP address attached to them by putting out a request. The device that receives the packet will respond with a list of Email accounts and other data unique to that device. To be able to identify IP addresses when necessary, each device keeps a table of recognized addresses.

Distributed tracing allows you to track requests across multiple microservices, providing visibility into how requests flow through the system. To implement: - Instrumentation: Use tracing libraries like OpenTelemetry, Jaeger, or Zipkin to instrument services. - Propagate trace context: Ensure trace IDs are passed between services in headers (e.g., X-B3-TraceId). - Aggregation tools: Use a central platform like Jaeger or AWS X-Ray to collect and visualize traces, helping to pinpoint bottlenecks or failures. - Tagging and logging: Add key metadata (e.g., service name, request IDs) to each trace span for detailed analysis. - Monitor latency and errors: Track SLIs like service latency, request counts, and error rates at each hop in the system. Distributed tracing is critical for identifying performance bottlenecks and understanding dependencies in a microservices environment.

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.

Activities that can reduce the toil are creating external automation, creating internal automation, and enhancing the service so that it does not require maintenance intervention.

Test-Driven Development (TDD) has been a key part of the agile development process in several of my previous roles. The principle behind TDD is that you write the tests for the function or feature before you write the code. It's a strategy that I found particularly powerful for ensuring reliability of code and preventing bugs from getting into production. In one of my previous roles, we enforced TDD rigidly. Each new feature or function had a corresponding set of tests written before the actual implementation was done. These tests served as both the developer's guide for what the code needed to do, and as verification that the implementation was correct once it was done. More importantly, these tests added to our growing test suite that would be run in our Continuous Integration pipeline every time a change was pushed. If the change broke something elsewhere in the system, we would discover it early thanks to these tests, which significantly improved the stability of our system. Thus, TDD, in my experience, not only helps produce better code, it also speeds up the development process overall, as fewer bugs means less time spent debugging and more time spent building new functionality.

The candidate should explain how they forecast and plan for future capacity needs. Discussing monitoring resource usage trends, setting thresholds, and scaling infrastructure proactively to meet demand is crucial.

Skilled applicants will be proficient in containerization technologies like Docker and orchestration tools like Kubernetes, Docker Swarm, or Amazon ECS. Look for examples where candidates have successfully used these tools to improve deployment speed, reliability, and scalability. Candidates might also talk about container registries, continuous integration and continuous deployment (CI/CD), and managing containerized workloads at scale.

Monitoring is the process of collecting and tracking system metrics, logs, and events to understand system health. Alerting is the mechanism that notifies teams when predefined conditions are met, indicating a potential issue. Observability is a broader concept that allows teams to understand the internal state of a system from its external outputs, enabling them to ask arbitrary questions and debug issues without predefined dashboards.

- Incident Response: Acknowledge, diagnose, resolve, and document the incident. Communication and coordination are key during incidents. - Postmortems: Conduct blameless postmortems to identify root causes and implement preventative measures.

In one of my previous roles, I was part of a team managing an e-commerce platform. With the user base growing rapidly, the infrastructure costs were escalating due to the processing power needed for some computationally intensive tasks. We identified a process that was reading from the database, performing some transformations, and writing back to the database. The issue was that this process was running for every user action, even when there was no update, leading to an unnecessary load. To address this, we implemented a caching system and stored the results of the process. So, the next time the same user action occurred, instead of initiating the whole process again, the system would first check the cache for results. If the results were already there, the system would retrieve them from the cache, significantly reducing the number of reads and writes to the database. By introducing caching, we maintained the functionality and improved performance, all while reducing the strain on our database servers. This ultimately led to a smaller resource footprint and a noticeable reduction in our infrastructure costs.

In a project involving a data center, I performed a system availability analysis. This involved calculating the Mean Time To Failure (MTTF) and Mean Time To Repair (MTTR) for different components of the system. The analysis helped us identify areas for improvement to maximize the data center's availability.

The popular tools currently in use for real-time monitoring and visualization with deep metrics in system performance are Prometheus and Grafana. To use logging with logs, perhaps ELK Stack (Elasticsearch, Logstash, Kibana) and Splunk are best for analyzing logs, looking at patterns, and troubleshooting issues with enhanced overhead visibility and quick solutions. It also helps the team to reduce SRE challenges.

In my previous role, I recognized that a significant amount of time was being dedicated to repetitive manual tasks, such as deploying updates, system monitoring, database backups, and writing incident reports. I saw this as an opportunity to implement automation, saving the team time and reducing the chances of human error. I introduced DevOps tools like Jenkins and Ansible into our workflow. Jenkins was used to implement Continuous Integration/Continuous Delivery (CI/CD), which automated our code deployment processes, while Ansible allowed us to automate various server configuration tasks. To automate system monitoring, I set up automated alerts using Grafana and Prometheus. This helped us to get real-time notifications about any system performance fluctuations which might need our attention. For database backups and incident reports, I wrote custom scripts using Python. These scripts automated regular database backups and the generation of basic incident reports whenever a service disruption occurred, allowing us to focus on troubleshooting rather than spending time on documenting the issues. The end result was a considerable reduction in repetitive manual work, increasing our team's efficiency and productivity.

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.

Site Reliability Engineer interviews cover a wide range of topics including Linux, observability, incident management, system design, and automation. Focus your preparation on these areas and practice answering real interview questions with structured responses.

A runbook is a detailed guide that outlines the steps required to perform specific operational tasks or handle incidents. It serves as a reference for engineers during troubleshooting.

Zero downtime deployments can be achieved through techniques like blue-green deployments, canary releases, rolling updates, and using feature toggles.

Infrastructure as Code (IaC) is a practice where the infrastructure management process is automated and treated just like any other code. Rather than manually configuring and managing infrastructure, we define the desired state of the system using machine-readable definition files or scripts, which are used by automation tools to set up and maintain the infrastructure. In one of my past jobs, we used Terraform for implementing IaC in our AWS environment. With Terraform scripts, we could not only set up our compute, networking, and storage resources but also handle their versioning and maintain them efficiently. Every change in the infrastructure was reviewed and applied using these scripts, keeping the whole process consistent and repeatable. Implementing IaC offered us multiple benefits. Notably, it allowed us to keep our infrastructure setup in version control alongside our application code, which greatly eased tracking changes and rolling back if there were errors. It also streamlined the process of setting up identical development, testing, and production environments, and brought in a high level of efficiency and consistency to our operations.

SRE's full form is Site Reliability Engineer. A Site Reliability Engineer is a software engineer who specializes in building and maintaining a reliable system that can handle unexpected changes in the environment. They typically work on large web applications, but they also work with other types of software systems. They are responsible for making sure that their system is able to handle all of the possible variations that might occur in the world. For example, if one server goes down, they need to make sure that their system can continue running without any problems. They also need to make sure that the site is secure against hackers and other attackers. Many sites are built using a combination of technologies, such as web apps, databases, and other systems. A Site Reliability Engineer needs to be familiar with all of these different components so that they can make sure that everything is working properly together. There are also DevOps engineers that sound similar to the work of site reliability engineers. But still, there are differences between them. So let's understand the first DevOps and then we will understand the difference between these two in the follow-up questions. Responsibilities of Site Reliability Engineer - Site reliability engineers collaborate with other engineers, product owners, and customers to develop goals and metrics. This assists them in ensuring system availability. Once everyone has agreed on a system's uptime and availability, it is simple to determine the best moment to act. - Site Reliability Engineer implements error budgets to assess risk, balance availability, and drive feature development. When there are no unreasonable reliability expectations, a team has the freedom to make system upgrades and changes. - SRE is committed to decreasing labour. As a consequence, jobs that require a human operator to operate manually are automated. - A site reliability engineer should be well-versed in the systems and their interconnections. - The objective of site reliability engineers is to detect problems early in order to decrease the cost of failure.

Monitoring involves collecting metrics (like CPU usage, latency, error rates), logs, and traces. Key tools include Prometheus for metrics, Grafana for dashboards, and ELK stack for log analysis. SREs set up alerts based on SLOs and use dashboards to visualize system health in real time.

Schema migrations in a distributed database are handled using migration tools (like Flyway or Liquibase), versioning schemas, implementing backward-compatible changes, and coordinating deployments to ensure data consistency and minimal downtime.

This question tests the candidate's knowledge of SLAs. They should define SLAs, explain their importance, and describe methods for monitoring compliance, such as tracking uptime, response time, and error rates.

This question assesses the candidate's understanding of SRE and its principles. An ideal answer would define SRE as a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. It ensures reliability, performance, and scalability of systems.

During a performance review, my manager pointed out that my patient whiteboards were occasionally incomplete. I took this feedback seriously and acknowledged that I had been prioritizing patient care over updating the whiteboard. I came up with a plan to update my whiteboards during shift change, and since then I've received positive feedback.

Depending on what they say, we'll be talking about this for a while and will probably create a lot of other questions.

A playbook is a collection of standardized procedures and protocols that guide engineers in handling various operational tasks and incidents.

Toil being manual and repetitious activities is what you'd want to minimize through automation in SRE. System reliability and efficiency may be enhanced through deploying, scaling, and monitoring through automation by SRE. Enables the guys to get busy innovating and tackling tough problems instead of wasting time doing routine operations.

Tools like Jaeger, Zipkin, or OpenTelemetry are used for distributed tracing. Tracing is important because it allows you to track the flow of requests across multiple services, helping to identify performance bottlenecks and failure points in complex architectures.

A Service Level Objective (SLO), which is typically represented as a percentage, is a gauge of how excellent or terrible the service quality is. It demonstrates how well the service level's actual performance matches expectations. The client normally establishes an SLO, but management may also do so to track performance.

This assesses the candidate's familiarity with Docker, Kubernetes, and other containerization technologies. Look for explanations of how they've used these tools to deploy, manage, and scale applications in a containerized environment.

I have experience working with a range of monitoring and management tools, such as Prometheus, Grafana, New Relic, and ELK (Elasticsearch, Logstash, Kibana) stack. These tools provide comprehensive monitoring, alerting, and log analysis capabilities. Additionally, I recommend utilizing infrastructure-as-code (IaC) tools like Terraform or Ansible to enable reproducibility and scalability, and version control systems like Git for tracking changes in configuration and code.

- Use APM tools like New Relic, Datadog, or Jaeger to monitor performance metrics such as latency, throughput, and error rates. - Implement caching layers (e.g., Redis, Memcached) to reduce database load. - Optimize algorithms and code paths by profiling them for bottlenecks. - Horizontal scaling: Add more instances or nodes to handle increased load. - Perform load testing and benchmarking with tools like Apache JMeter or Gatling.

The Dynamic Host Configuration Protocol is known as DHCP. It is a technique that enables networks to assign IP addresses to network hosts on a dynamic basis. Devices like PCs and routers are given IP addresses through the use of DHCP. An IP address may be required for a device to connect to The internet after installation. Therefore, when a new system is placed, DHCP will provide it an IP address so that it may access the network. In order to talk with some other hosts on a network, a device must first obtain an IP address when it joins a network. Additionally, since most networks only assign one IP address to each device, a system for dynamically allocating IP addresses must exist.

At my previous job, I led an FMEA exercise for a new electric vehicle project. We brainstormed possible failure modes, estimated the severity, occurrence, and detection levels, and assigned Risk Priority Numbers. Based on this, we prioritized the problems that needed immediate attention, which significantly reduced potential risks and improved the product's reliability.

I have experience with Prometheus and Grafana for time-series monitoring and visualization, Datadog for unified monitoring, and the ELK stack for log aggregation and analysis. I've configured alerts in these systems based on critical metrics.

- Use cloud-agnostic monitoring tools like Datadog or Prometheus to collect metrics from different cloud providers. - Implement Infrastructure as Code (IaC) tools such as Terraform to manage resources across clouds consistently. - Use multi-cloud dashboards to view consolidated metrics and alerts across clouds. - Ensure network connectivity and security policies are uniformly applied across different cloud providers.

A service-level objective (SLO) defines the target availability (uptime) we want for a system or service. We define reliability as meeting our SLOs. Follow up: What is an SLA? An SLI? A service-level agreement (SLA) is the uptime promise that we make to a customer. These are often legally-defined with penalties for missing the target availability. For this reason, SLAs are generally set using figures that are easier to meet than SLOs. A service-level indicator (SLI) is something you can measure with precision to help you think about, define, and determine whether you are meeting SLOs and SLAs. They are generally reported as the ratio between the number of good events divided by the total number of events. A simple example would be the number of successful HTTP requests / total HTTP requests. SLIs are frequently reported as a percentage with 0% meaning everything is broken and 100% meaning everything is working perfectly.

A container orchestration system, like Kubernetes, automates the deployment, scaling, and management of containerized applications.

One of the most challenging problems I had to solve involved a persistent memory leak in a critical service of our system. The service would run fine for a few days but would eventually run out of memory and crash, causing disruptions. Initial efforts to isolate the issue using regular debugging methods were not successful because the issue took days to manifest and was not easily reproducible in a non-production environment. To tackle this, I first ensured we had good monitoring and alerting set up for memory usage on this service, to give us immediate feedback on our efforts. We also arranged for temporary measures to restart the service automatically when memory usage approached dangerous levels, to minimize disruptions to our users. Next, I wrote custom scripts to regularly capture and store detailed memory usage data of the service in operation. After we had collected a few weeks worth of data, I started analysing the data patterns in depth. Upon combining this analysis with code review of the service, we managed to narrow it down to a specific area of the code where objects were being created but not released after use. After identifying the issue, we updated the code to ensure proper memory management and monitored the service closely. With the fix, the service ran smoothly and memory usage remained stable over time. It was a challenging and prolonged problem to solve but it was rewarding in the end, and it significantly improved the stability of our system.

Situation: We were under deadline to ship a major feature, and I recommended we delay because our testing infrastructure wasn't reliable enough. Task: I knew delaying would be unpopular with leadership and the product team, but I believed it was the right call. Action: 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: 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.

Hard question. The wrong answer is “I've never disagreed.” Nobody believes that. The right answer describes a specific moment where you pushed back on a mitigation decision during a live incident, did it constructively enough that the IC didn't lose coordination authority, and then brought the structural concern to the post-mortem where the team could actually discuss it without the pressure of a running outage. That sequence matters. Companies running SRE at scale have seen what happens when an engineer overrides the IC mid-incident. It's worse than the original outage in terms of coordination damage.

Align your response with: - Continued patient impact - Professional development - Evolving responsibilities

Observability is the term used to describe the ability of an organization to track real-time events and metrics within a system. Systems that are more Observable are able to capture data from devices within the organization, such as smartphones and tablets. This data can then be used to track activities within the organization, such as the number of employees who log into work each day. There are many different types of observability within an organization, including: - Real-time monitoring: This type of observability allows users in the organization to monitor what is happening in real time. This includes things like the number of people who visit a website on their phone or tablet. - Historical monitoring: This type of observability allows users in the organization to view data from previous periods. This type of observability may be most useful when tracking financial transactions, such as how much money has been spent over time. - System-wide monitoring: This type of observability can be used across all devices in an organization, including phones and computers. System-wide monitoring allows users in the organization to view data across all devices within the organization. We can increase the observability of the organization by - - Recognize the sorts of data that flow from an environment and which of those data types are relevant and valuable to your observability goals. - Determine how your strategy is making sense of data by distilling, filtering, and translating it into actionable insights regarding the performance of your systems. Observability can provide helpful information about an organization's DevOps maturity level.

You are looking for their thinking process, their organization, and how methodical they are in finding problem sources. You are also looking for how creative they can be in solving them.

- DevOps and Site Reliability Engineer are the two terms used to describe a person who specializes in improving applications and services while they are being used. - DevOps and Site reliability engineering are both important roles in modern IT organizations. However, there is a big difference between them. Those are - | DevOps | SRE | |---|---| | DevOps involves the development of software that can be updated and modified while it is running. | Site reliability engineer, on the other hand, focuses on keeping an application or service up and running. | | DevOps teams often use automation tools to improve their workflow. | Site reliability engineers, on the other hand, work with both automation tools and humans to ensure service continues to operate smoothly. | | DevOps deals with when and how software is built. | The site reliability engineer focuses on what happens once it's built | Refer to this blog for a more detailed understanding of the difference between SRE and DevOps.

- Implement database replication (e.g., MySQL replication, PostgreSQL streaming replication) across multiple availability zones or regions. - Use automatic failover with tools like Patroni or AWS RDS Multi-AZ. - Employ load balancers to distribute read requests to read replicas while write requests go to the primary database. - Regularly perform database backups and test disaster recovery plans. - Use sharding to distribute large datasets across multiple servers to ensure scalability.

- Hardlinks and soft links are two different types of file system links used to share files between directories. - Hardlinks create a single link to a file in two different locations, while soft links create a single pointer to the location of a file in one location. - When you create hardlinks, each link is the same size as the original file. Soft links, on the other hand, can be created with or without the original file and can be of variable sizes. - To create a hardlink, you must have the “write” permission for both the original and target file. To create a softlink, you must have the “write” permission for only the target file. If you try to write to the original file while you have the write permission for only one of the files, your attempt will fail and generate an error message. If you try to delete just one of the files while you have the write permission for both, it will also fail and generate an error message.

A playbook is a comprehensive set of procedures and protocols for handling specific operational tasks and incidents. It provides detailed steps for troubleshooting, incident resolution, and routine maintenance, ensuring consistency and efficiency.

I conducted a maintainability analysis for a high-end industrial machinery product line. I factored in aspects like repair time, availability of spare parts, and ease of access for maintenance work. Based on the analysis, we redesigned some components to make them more accessible, thereby improving the product's overall maintainability.

Idempotency means that performing an operation multiple times produces the same result as doing it once. For example, a script that ensures a package is installed will not cause errors if run repeatedly. Idempotency is critical for reliable automation.

Hard IDE Site Reliability Engineer Data Structures & Algorithms +6 more +26 Site Reliability Engineer Data Structures & Algorithms +6 more - Asked at Google • Site Reliability Engineer Debugging +1 more Site Reliability Engineer Debugging +1 more

A collection of guidelines called data structures is used by computers to organize and store data. Data structures are employed to manage memory, structure databases, and organize data. Data structures make it simple to organize data, make it simple to get data, and make good use of resources. Physical data objects can indeed be linked lists and arrays. Since the information residing in the real physiological memory is based on these two, we can refer to them as physical data structures. A group of adjacent data items from the same type is referred to as an array. The linked list, which still might not be consecutive in memory, is likewise a collection of data components. All data objects that are built utilizing the different physical data structures are referred to as logical data structures. Stack, queue, tree, graph, and other logical data structures are examples. These data structures only contain logic, which defines a property and stores the data in memory using matrices and linked lists.

These questions are incredibly important to me. It could both surface fun red flags for you to discuss with your interviewer and see how receptive they are to your opinions and give you an idea of things you might be working on for them.

On-call responsibilities involve the readiness to react to an incident within a certain time. I make sure I have monitoring tools available and am aware of the escalation paths. While on call, I maintain concentration on finding the root cause of the problem, resolving it in the shortest time possible, and ensuring a seamless handover to the next team member when required.

Once, I gave my patient all his medications in a cup. He threw one on the floor but swallowed the rest; I didn't know which one was missed. I had to speak with my charge nurse, doctor and pharmacist to identify the missing medication. Since then, I always give medications one at a time.

A palindrome is a string that reads the same forward and backward. Here's a Python function to check if a given string is a palindrome: def is_palindrome(s): return s == s[::-1]

This is an excellent technical question to determine how you've set up monitoring and alerting tools and how you've helped define the "healthy" state of a system in the past. If you want to join an SRE team, you'll need to understand how you can leverage both internal and external outputs to determine overall system health. Then, you should be able to translate that information into insights and action for IT and engineering teams.

Blast radius refers to the potential impact or damage that a single failure, change, or incident can have on a system. SREs aim to minimize the blast radius by using techniques like microservices, circuit breakers, and redundancy to contain failures and prevent them from cascading across the entire infrastructure.

Situation: 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: I needed to either convince them to canary or understand why they felt confident in a full rollout. Action: 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: 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.

Configuration management ensures that systems are configured consistently and correctly. It involves maintaining and versioning configuration files, automating configuration changes, and using tools like Ansible, Puppet, or Chef to manage configurations across environments.

During a project, the development team noticed that our service's uptime was below the agreed SLO. I worked with them to identify the root causes, such as poor error handling and insufficient retries on external API calls. Approach: - We reviewed and improved the error handling in the codebase. - Introduced retries with exponential backoff for external API requests. - Added better monitoring and logging to detect failures early. - Collaboratively improved the CI/CD pipeline to automate testing and catch reliability issues before production releases.

Toil refers to repetitive, manual tasks that are necessary but do not add enduring value to the system. To reduce toil: - Automate manual tasks using scripting or orchestration tools like Ansible, Chef, or Kubernetes. - Improve self-healing mechanisms to handle common issues automatically. - Ensure efficient use of monitoring tools to automate alerts and responses, reducing the need for manual interventions.

Designing for high availability involves eliminating single points of failure through redundancy, using failover mechanisms, replicating data across multiple locations, distributing services across nodes or regions, and implementing automated health checks with self-healing capabilities.

Chaos Engineering involves deliberately introducing failures into a system to test its resilience and identify weaknesses before they cause real problems.

Chaos engineering is the practice of intentionally injecting failures into a system in production to test its resilience and uncover weaknesses before they cause outages. While I haven't personally run chaos experiments, I understand its value and know tools like Chaos Monkey.

The candidate should discuss their approach to automation, mentioning scripting languages (e.g., Python, Bash), automation tools (e.g., Jenkins, Ansible), and examples of tasks they've automated to save time and reduce errors.

During a high-severity incident, I follow established procedures: first, acknowledge and assess the impact; second, identify and isolate the root cause; third, implement mitigations; fourth, communicate updates clearly; fifth, conduct a root cause analysis; and finally, perform a blameless postmortem.

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.

When I encounter incomplete or ambiguous requirements, my first step is to initiate a detailed discussion with the relevant stakeholders. The goal is to clarify expectations, articulate the needs better, and make sure everyone is on the same page. For technical requirements, I often ask for use-cases or scenarios that help me understand what the stakeholder is trying to achieve. At times, I might present prototypes or sketches to illustrate the proposed implementation and that, in turn, prompts more detailed feedback. Also, it's beneficial to keep an open mind during these dialogues as sometimes the solution the stakeholder initially proposed may not be the best way to address their actual need. For example, in my previous role, a product manager once requested a feature that, on the surface, seemed straightforward. But it wasn't clear how this feature would affect existing systems and workflows. Rather than making assumptions or taking the request at face value, I initiated several meetings with the product manager to understand their vision, presented some mock-ups, and proposed alternate solutions that would achieve their goal with lesser system impact. In conclusion, clear communication, initiative to probe deeper, and presenting your understanding or solutions as visual feedback are key in dealing with incomplete or ambiguous requirements.

This question seeks to understand the candidate's problem-solving skills and resilience under pressure. Look for detailed descriptions of the incident, steps taken to diagnose and resolve the issue, and any lessons learned.

- Indexing: Add indexes to speed up query lookups. - Query Optimization: Use EXPLAIN plans to analyze and optimize slow queries. - Partitioning: Divide large tables into smaller partitions. - Caching: Use in-memory caches like Redis or Memcached to reduce load on the database. - Connection Pooling: Reuse database connections to avoid the overhead of repeatedly opening/closing them.

An alerting system notifies engineers of issues in real-time, enabling quick response to incidents. It is configured to trigger alerts based on predefined thresholds for critical metrics, helping in proactive monitoring and incident management.

Strong candidates emphasize systemic improvements over individual blame and can describe how blameless culture encourages honest incident reporting.

A self-healing system automatically detects and recovers from failures without human intervention. Examples include: automatically restarting failed containers (Kubernetes), replacing unhealthy instances (auto-scaling groups), and using circuit breakers to isolate failing components.

This question seeks to understand the candidate's practical experience. Look for specific examples where they identified reliability issues, implemented solutions, and measured the improvements.

Configuration management is done using tools such as Ansible, Puppet, or Chef to automate and manage all consistent configurations for servers and environments. The configuration management tools avoid manual configuration errors and make system deployments and operations easy to scale. It creates consistent repeatability for the management of infrastructure.

How many times a month are you on-call?

Capacity planning involves predicting future resource needs and ensuring that the infrastructure can handle anticipated growth and load without compromising performance.

The term 'SRE' stands for 'Site Reliability Engineer.' A software engineer with a focus on creating and maintaining dependable systems that can withstand unforeseen environmental changes is known as a site reliability engineer. Though they also operate with other kinds of software systems, they generally work on huge online projects. They are in charge of ensuring that their system can accommodate any modifications that might arise in the real world. For instance, they must ensure that the system can function normally even if one of their servers fails. Additionally, they must guarantee that the website is safe from hackers and other intruders.

A special kind of file system with unique access rights is a '/proc' file system. When the kernel wants to run a process or access specific system resources, it is elevated in Linux systems. Information about the system's present condition, such as memory consumption and CPU speed, can be found in the /proc directory.

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.

DNS stands for Domain Name System. It is a system that maps hostnames to IP addresses so that you can find the correct server when you type in a website address in your browser. The DNS system associates each domain name with one or more IP addresses, which are called "resolvers." When you type in a URL (e.g., www.google.com) into your browser, the computer sends a request to the DNS resolver for the IP address associated with that domain name. The DNS resolver then returns an IP address to the browser, which is either the IP address of a local computer or of another server that has been configured to return that particular IP address. Consider the below image for a better understanding - DNS is necessary because hosts on the Internet have only human-readable names like google.com and not machine-readable names like 111.222.333.444. Without DNS, you would need to know how to interpret a URL's human-readable name in order to find it on the Internet, which would be very difficult without a centralized authority like Google to help you out!

Secrets like passwords and API keys should never be hardcoded. Use secret management tools (e.g., HashiCorp Vault, AWS Secrets Manager) to store and inject secrets securely into pipelines. Access is controlled via IAM policies, and secrets are rotated regularly.

I see Site Reliability Engineering as fundamentally about applying software engineering principles to operations problems. It's about designing, building, and maintaining robust, scalable systems through automation, careful monitoring, and a strong focus on reliability metrics. For me, it boils down to two core ideas: making systems more reliable and making operations more efficient, often by eliminating toil. My experience really centers on bridging the gap between development and operations, ensuring our services meet their reliability targets while improving developer velocity. A good example of this was a project where we had a critical microservice handling user authentication. Developers were constantly pushing features, but the service stability was inconsistent, leading to frequent customer-facing errors. We didn't have clear reliability goals defined for it. My first step was to work with the product and development teams to establish clear Service Level Indicators (SLIs) and Service Level Objectives (SLOs). We settled on an availability SLO of 99.9% for successful login attempts and a latency SLO of under 200ms for 95% of requests. This wasn't just an arbitrary number; it was based on historical performance, user expectations, and business impact of downtime. Once we had these SLOs, I instrumented the service more thoroughly using Prometheus, specifically tracking the success rate of login requests and the latency distribution. We also integrated Grafana for dashboards to visualize these metrics in real-time. This gave us a clear, data-driven picture of where we stood against our goals. Initially, we were consistently falling below the availability SLO, particularly during peak load times. I identified that the service was experiencing database connection pool exhaustion under heavy traffic. To address this, I worked with the development team to refactor the database access layer, implementing a more efficient connection pooling strategy and introducing circuit breakers to prevent cascading failures. We also implemented an autoscaling group based on CPU utilization and request queue depth, which helped the service dynamically adjust to varying loads. Furthermore, I developed a suite of synthetic tests that mimicked user login attempts and ran them from various geographical locations, pushing alerts directly to our on-call rotation if these tests failed or if latency spiked beyond our SLO. This proactive monitoring allowed us to catch issues before they impacted a significant number of users. Another key SRE principle I applied was reducing toil. We had a recurring task of manually rotating database credentials every 90 days. It was tedious, prone to human error, and took an engineer almost a full day to complete across all environments. I automated this process entirely using HashiCorp Vault for secret management and a Python script integrated with our CI/CD pipeline. The script would generate new credentials in Vault, update the service configurations, and restart the necessary instances, all without manual intervention. This completely eliminated the toil, freeing up engineering time for more impactful work and significantly reducing the risk of a missed rotation causing an outage. Through these efforts – establishing clear SLOs, improving monitoring, implementing targeted reliability improvements, and automating manual tasks – we significantly improved the authentication service's stability. We consistently met our 99.9% availability SLO, and developer confidence in deploying new features increased because they knew the underlying infrastructure was robust. It wasn't just about keeping the lights on; it was about systematically engineering for reliability and efficiency.

Candidates should explain that: Service Level Indicators (SLIs) are specific, measurable characteristics of the service, such as latency or error rate; Service Level Objectives (SLOs) are the target values for SLIs that the service aims to meet; Service Level Agreements (SLAs) are contractual agreements with customers that include consequences for not meeting SLOs. Skilled SREs will understand how these concepts help to set, measure, and manage the performance and reliability of services.

When I'm faced with a complex distributed system problem where the root cause isn't immediately obvious, I typically follow a structured, hypothesis-driven approach, moving from high-level observation down to granular detail. My primary goal is to quickly narrow down the scope of the problem and isolate the failing component or interaction. I start by validating the problem from the user's perspective. What are they experiencing? Is it slow responses, errors, or complete unavailability? This helps set the severity and target for the investigation. For example, if users report slow responses on our customer portal, I'll first confirm this by trying to access it myself and checking synthetic monitoring dashboards. This also helps confirm the blast radius – is it affecting all users or just a subset? Next, I immediately check my golden signals for the affected service: latency, traffic, errors, and saturation. These provide a quick overview of the service's health. For instance, if traffic dropped significantly but latency and errors spiked, that's a different problem than if traffic is normal but errors are high. I'd use Grafana dashboards linked to Prometheus metrics for this. If the customer portal is slow, I'd look at its front-end service metrics first. If latency is high, I'd check its upstream dependencies. If the golden signals point to a specific service, I'll then start drilling down. I'll examine the logs for that service for any unusual error patterns, warnings, or exceptions. I'm looking for anomalies around the time the issue started. Tools like Splunk or Datadog are invaluable here for aggregated log analysis. For example, in a recent incident where our API gateway was reporting high latency, I checked its logs and saw a recurring "connection refused" error to a specific backend microservice, order-processor-service. This immediately shifts my focus. Now I'm troubleshooting order-processor-service. I'll go back to the golden signals for order-processor-service. Is its CPU saturated? Is memory high? Are its database connections maxed out? Does it have a high error rate to its dependencies? In the order-processor-service example, I found its CPU utilization was unexpectedly low, but its error rate was 100%, and its database connection pool was entirely exhausted. This indicated a problem with its database. Then I'd pivot to the database metrics. Is the database itself overloaded? Are there long-running queries? High transaction locks? In this specific case, I checked the database for order-processor-service and found a single, very complex analytics query running that was consuming nearly all the database's CPU and I/O resources, causing a cascading failure where order-processor-service couldn't get connections. This query had been deployed by the analytics team a few hours prior, unknowingly impacting our production database. Once I identified the rogue query, my immediate mitigation was to kill the query process and block it from running again. This instantly freed up database resources, allowing order-processor-service to reconnect and resume processing requests, restoring the API gateway and customer portal functionality. Throughout this process, I communicate continuously on an incident bridge. I state my observations, my hypotheses, and what steps I'm taking. This transparency helps other engineers understand the situation and offers opportunities for them to contribute if they have relevant context. I also use strace, tcpdump, and other Linux utilities if I need to dig deeper into kernel-level behavior or network packets, but that's usually a later step after exhausting application and infrastructure metrics. The key is to start broad, use monitoring and logging to quickly narrow the scope, formulate and test hypotheses, and isolate the root cause systematically. And always, always prioritize quick mitigation to restore service, even if the permanent fix comes later.

- Emphasizing the reliability of systems and services - Implementing automation to minimize manual toil and human error - Using data-driven decision-making to continuously improve system performance - Sharing ownership and responsibilities between development and operations teams - Building scalable and efficient systems that can handle increased traffic and user demand

We can solve this problem recursively by traversing to the last row and returning the leftmost node value. And because we are not aware of the final row of each sub-tree, so we can have a count of height that helps in obtaining the answer from the tree. So the code of this approach will be - class Solution { int maxHeight, ans; private void solution(TreeNode root, int height){ //Checking if it is the leaf node and also if it is the last row. //We are checking the last row based on the height of the tree. if(root.left == null && root.right == null){ if(height > maxHeight){ maxHeight = height; ans = root.val; } return; } //Recursively traversing for the final row if child exists. if(root.left != null) solution(root.left, height+1); if(root.right != null) solution(root.right, height+1); } public int findBottomLeftValue(TreeNode root) { maxHeight = -1; //Calling helper method that finds the leftmost node in the tree. solution(root, 0); return ans; } } The Time complexity for the above approach is O(n) because we are traversing each node only once. And the space complexity can be O(n) because of the recursion.

There are several options. We want at least one or something just as good. Perhaps follow up with a question about when/why their answer might be suitable and when a different option would be better. - If no process has the filehandle open, you can delete the file. - If a process has the filehandle open, it is better if you do not delete the file, instead you can cp /dev/null on the file, which will reduce it's size to 0. - A filesystem has a reserve, you can reduce the size of this reserve to create more space using tunefs.

This assesses the candidate's familiarity with popular monitoring and alerting tools. Ideal answers might include tools like Prometheus, Grafana, Nagios, Splunk, Datadog, or New Relic, and the candidate should explain how they use these tools to monitor system health and performance.

Kubernetes automates the deployment, scaling, and management of containerized applications. It handles scheduling, load balancing, self-healing, and rolling updates. SREs use Kubernetes to run reliable, scalable services in production.

Capacity planning involves analyzing current usage patterns, forecasting future needs, and ensuring that infrastructure can handle anticipated growth.

This assesses the candidate's experience with cloud providers like AWS, Google Cloud, or Azure. Look for familiarity with cloud services, architecture, and best practices for deploying and managing applications in the cloud.

Skilled candidates will talk about strategies such as using virtual environments, containerization, or specific tools (like npm for Node.js or pip for Python) to manage packages. They should emphasize the importance of testing updates in a development or staging environment before applying them to production to avoid unexpected downtime.

Dividing a large block of addresses into several contiguous sub-blocks and assigning these sub-blocks to different smaller networks is called subnetting. It is a practice that is widely used when classless addressing is done. A subnet or subnetwork is a network inside a network. Subnets make networks more efficient. Through subnetting, network traffic can travel a shorter distance without passing through unnecessary routers to reach its destination.

Effective answers show understanding of how error budgets create shared accountability between SRE and development teams when making tradeoffs between velocity and stability.

To minimize downtime during deployments, I advocate for strategies like blue/green deployments or canary releases to gradually expose new versions. Using feature flags allows decoupling deployment from release. Automated rollback plans are essential safeguards.

When a domain is requested: - It checks the local DNS cache. - If not found, it queries the recursive DNS server. - Recursive server queries the root, TLD, and authoritative servers.

- Implementing redundancy and replication across different data centers or availability zones. - Designing systems with fault tolerance in mind, using systems like load balancing, clustering, and failover mechanisms. - Performing regular monitoring and failover testing to ensure high availability. - Using distributed data storage systems with built-in replication and consistency mechanisms. - Implementing automated monitoring and alerting systems to detect and respond to failures quickly.

This may be a controversial one, but if the title is "SRE" I ask why the title is "SRE" and not something else (same for "DevOps"). I'm looking to see if they're being thoughtful about what the term means and how they are defining "resilience" for their systems.

The answer that passes explains what you're measuring and why. The four golden signals from Google's SRE practices: latency, traffic, errors, saturation. Not as a list. As a diagnostic framework. “I'd instrument latency at p50, p95, and p99 because p50 tells you the common case and p99 tells you about the tail that generates support tickets. I'd alert on p99 crossing the SLO threshold, not on p50, because p50 alerts generate noise that trains people to ignore pages.” That reasoning. The tooling is secondary.

- Conducting load testing to simulate heavy traffic and identify bottlenecks. - Optimizing resource allocation and capacity planning to handle increasing demand. - Implementing caching mechanisms to reduce the load on underlying systems. - Horizontal scaling by adding more servers or instances as needed. - Monitoring system metrics and using scaling policies to automatically adjust resources.