LinkedIn Site Reliability Engineer Interview Questions (2026)

1. Q1

   How would you build a capacity forecast for this service?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: professional graph API traffic is growing steadily and leadership asks when capacity will become unsafe.

   How to answer: A strong capacity forecast begins by identifying key resource metrics (CPU, memory, disk I/O, network bandwidth) and their primary drivers (e.g., QPS, active users, data volume). Historical data for these metrics and drivers should be collected and cleaned. Various forecasting models, such as time series analysis (ARIMA, Prophet) or regression models, can then be applied, considering seasonality and growth trends. Finally, the forecast should incorporate a safety margin and be regularly validated against actual usage to refine the models and assumptions.

2. Q2

   How would you prepare capacity for a known peak?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: LinkedIn expects a major traffic spike for professional graph API during a launch, holiday, or media event.

   How to answer: A strong answer outlines a proactive, data-driven approach. It starts with analyzing historical data to understand the peak's magnitude, duration, and growth trends, considering both application and infrastructure metrics. Then, it involves stress testing and load testing key services and dependencies to identify bottlenecks and validate scaling strategies. Finally, it details the execution plan, including pre-provisioning resources, configuring auto-scaling policies, and establishing a robust monitoring and rollback plan.

3. Q3

   How would you identify the true capacity bottleneck?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: professional graph API scales unevenly: CPU is fine, but database connections, network egress, or disk IOPS saturate first.

   How to answer: To identify the true capacity bottleneck, one must start with comprehensive monitoring across all layers (application, infrastructure, network, database) to gather performance metrics. Next, conduct load testing and stress testing scenarios, gradually increasing load until a saturation point is reached, while observing resource utilization and latency. Analyze the collected data to pinpoint the resource (CPU, memory, I/O, network bandwidth, database connections, specific service limits) that first hits its saturation threshold or experiences a significant degradation in performance. Finally, validate the identified bottleneck through targeted experiments or by isolating the component to confirm it is indeed the limiting factor.

4. Q4

   How would you plan cluster capacity beyond average CPU and memory?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: Kubernetes clusters hosting jobs recommendation and notification pipeline show low average utilization but frequent pod scheduling failures.

   How to answer: A strong candidate would discuss accounting for peak usage, not just averages, by analyzing historical data and growth trends. They should mention considering resource limits (requests/limits) and their impact on scheduling and overcommitment. Furthermore, they would bring up non-CPU/memory resources like network bandwidth, disk I/O (IOPS/throughput), and inode usage. Finally, they should touch upon specialized hardware (GPUs, FPGAs) and the need for buffer capacity for reliability and unexpected spikes.

5. Q5

   How would you decide where capacity can be safely reduced?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: Finance asks LinkedIn to reduce infrastructure spend for professional graph API without violating SLOs.

   How to answer: A strong answer would begin by emphasizing a data-driven approach, focusing on identifying underutilized resources and services with high confidence in their current headroom. This involves analyzing historical utilization metrics (CPU, memory, network, disk I/O) against peak loads and service-level objectives (SLOs). Key considerations include understanding workload patterns (daily, weekly, yearly cycles), identifying non-critical services or environments (e.g., dev/test), and assessing the blast radius and rollback strategy for any proposed reductions. Finally, a phased approach with continuous monitoring and A/B testing would be crucial to validate the safety of reductions.

6. Q6

   How would you define healthy headroom for normal and failure conditions?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: professional graph API runs at 65% CPU most days but incidents occur when a zone fails and traffic shifts.

   How to answer: Healthy headroom for normal conditions is typically 20-30% of current capacity, allowing for organic growth and minor traffic spikes without immediate scaling. This buffer should be regularly reviewed and adjusted based on growth trends and seasonality. For failure conditions, headroom needs to account for the loss of a significant portion of infrastructure (e.g., a rack, an availability zone, or 'N' servers) while still maintaining service levels. This often means having 50-100% additional capacity beyond normal operational needs, depending on the blast radius and recovery objectives. The specific percentages are derived from risk assessment, historical data, and business criticality.

7. Q7

   How would you design a realistic load test?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: A new version of professional graph API needs capacity validation before large daily peaks around workday usage.

   How to answer: A realistic load test design involves first defining clear objectives and identifying critical user journeys. Next, analyze production traffic patterns (e.g., QPS, concurrency, request mix) and resource utilization to establish a baseline. Then, create a representative workload model, including data variability and user behavior, and select appropriate load testing tools. Finally, execute tests with gradual ramp-up, monitor key metrics (latency, error rates, resource usage), and iterate based on results, ensuring post-test analysis and reporting.

8. Q8

   How would you plan regional capacity and traffic shifting?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: stateful and stateless service mix across data centers must serve traffic even if one region or edge location fails.

   How to answer: A strong answer would begin by outlining the need for a multi-region strategy, considering disaster recovery, latency, and cost. It would then detail the capacity planning process, including forecasting demand, understanding service dependencies, and buffer allocation. For traffic shifting, the candidate should discuss mechanisms like DNS-based routing (e.g., weighted round robin, latency-based), load balancers, and application-level routing, emphasizing gradual shifts and rollback plans. Finally, it should touch upon continuous monitoring, testing (e.g., chaos engineering), and automation for both capacity and traffic management.

9. Q9

   How would you plan and operate shard capacity?

   Capacity PlanningLinkedIn-specific

   Context: Production scenario: A shard for professional graph API becomes hot while overall fleet utilization is moderate.

   How to answer: A strong answer outlines a multi-faceted approach to shard capacity planning, starting with defining key metrics (e.g., QPS, latency, storage, CPU, memory) and establishing buffer policies (e.g., 20-30% headroom). It details a proactive monitoring strategy for these metrics at the shard level, coupled with regular capacity reviews and forecasting based on historical trends and anticipated growth. The plan should also include strategies for dynamic scaling (e.g., rebalancing, adding shards) and a robust incident response for shard-level capacity breaches.

10. Q10

    How would you capacity-plan connection pools and downstream concurrency?

    Capacity PlanningLinkedIn-specific

    Context: Production scenario: professional graph API has enough compute, but database connection limits are exhausted during spikes.

    How to answer: Capacity planning for connection pools involves understanding application request rates, average connection usage time, and target latency/throughput. Key metrics include QPS, average transaction time, and error rates to determine optimal pool size (min/max). Downstream concurrency planning then extends this by considering the number of concurrent requests the downstream service can handle, its latency characteristics, and potential for backpressure. This often involves load testing, modeling, and iterative adjustments based on production monitoring.

11. Q11

    How would you plan cache capacity and eviction policy?

    Capacity PlanningLinkedIn-specific

    Context: Production scenario: Cache eviction rate for professional graph API rises, causing origin saturation and higher latency.

    How to answer: A strong candidate would first define key metrics like QPS, hit rate, object size distribution, and acceptable latency, then analyze historical data and projected growth to estimate total cache size requirements. For eviction policy, they would discuss common strategies like LRU, LFU, or FIFO, and explain how to choose based on access patterns (e.g., LRU for temporal locality, LFU for frequency). They would also mention the importance of canary deployments, A/B testing, and continuous monitoring (e.g., cache hit ratio, eviction rate, latency) to validate and fine-tune both capacity and policy post-deployment. Finally, they would touch upon tiered caching and data consistency considerations.

12. Q12

    How would you calculate whether the system can drain backlog before violating freshness targets?

    Capacity PlanningLinkedIn-specific

    Context: Production scenario: jobs recommendation and notification pipeline accumulates a large queue backlog during a partial outage.

    How to answer: To calculate backlog drain, first determine the current backlog size (items/data points) and the freshness target (time limit). Next, identify the system's current processing rate (items/second) and its maximum sustainable processing rate. Compare the time required to process the current backlog at the current rate versus the freshness target. If the current rate is insufficient, assess if the maximum rate can clear the backlog within the target, factoring in any potential for increased ingestion during the drain period. The calculation is `Time_to_drain = Backlog_Size / (Processing_Rate - Ingestion_Rate)`.

13. Q13

    How would you capacity-plan edge or CDN infrastructure?

    Capacity PlanningLinkedIn-specific

    Context: Production scenario: front-door APIs and feed-serving tier must absorb a sudden regional traffic shift while keeping professional graph API latency low.

    How to answer: Capacity planning for edge/CDN infrastructure involves understanding traffic patterns, content types, and geographic distribution. Key metrics include requests per second (RPS), bandwidth (ingress/egress), and connection counts, often broken down by PoP. It's crucial to account for peak loads, regional variations, and potential for traffic shifts (e.g., due to failover or new content launches). Modeling should incorporate hardware limitations (CPU, memory, disk I/O, network interface capacity) and software overhead, along with a buffer for unforeseen spikes and maintenance. Regular review of actual utilization against forecasts, coupled with stress testing and load balancing strategy, is essential for proactive scaling.

14. Q14

    How would you capacity-plan bandwidth and protect critical traffic?

    Capacity PlanningLinkedIn-specific

    Context: Production scenario: Replication, logs, and customer traffic share network links for professional graph API.

    How to answer: A strong answer would start by defining critical traffic and identifying key metrics (e.g., Mbps, packets/sec, latency, error rates). It would then detail a multi-pronged approach for capacity planning, including historical data analysis, forecasting (growth models, peak-hour analysis), and stress testing. For protection, the candidate should discuss QoS/traffic shaping, dedicated bandwidth, redundant paths, and circuit breakers/rate limiting. Finally, they should emphasize continuous monitoring and iterative refinement of the plan.

15. Q15

    How would you plan storage capacity and retention?

    Capacity PlanningLinkedIn-specific

    Context: Production scenario: Storage for professional graph API grows faster than forecast because retention and indexing changed.

    How to answer: A strong answer outlines a data-driven approach, starting with identifying key metrics like current usage, growth rate (daily/weekly/monthly), and data types. It then details forecasting methodologies (e.g., linear regression, exponential smoothing) and considers factors like seasonality, new feature launches, and data retention policies. The plan should include buffer capacity, regular review cycles, and a strategy for data lifecycle management (archiving/deletion) to optimize costs and performance.

Practice these with instant AI feedback in a live mock interview → Start a LinkedIn Site Reliability Engineer mock

Focus your prep on the topics above, rehearse structured answers out loud, and do at least one full mock loop before the real thing.

Indicative Site Reliability Engineer pay in India: ~₹12–52 LPA (role-level range, not a LinkedIn-specific figure).

Site Reliability Engineer interviews at other companies