Airbnb DevOps Engineer Interview Questions

To enhance the performance of serving frequently accessed API responses on Airbnb's platform, an LRU (Least Recently Used) cache can help store the most relevant data while evicting the least needed data efficiently.
Problem statement: Implement an LRUCache class that provides an API for setting and getting values while maintaining the least recently used order.
- def __init__(self, capacity: int) -> None: Initializes the cache with a given capacity.
- def get(self, key: int) -> int: Retrieves the value associated with key, returning -1 if it does not exist.
- def put(self, key: int, value: int) -> None: Updates or inserts the value for key and makes it the most recently used item.
Example 1:
Input: capacity = 2, commands = [(put, 1, 1), (put, 2, 2), (get, 1), (put, 3, 3), (get, 2), (put, 4, 4), (get, 1), (get, 3), (get, 4)]
Output: [None, None, 1, None, -1, None, -1, 3, 4]
Explanation: Accessing keys makes them recent. Therefore, the evicted key was 2 after adding 3.
Constraints:
- The cache capacity will be between 1 and 1000.
- The all keys will be positive integers.

Monitoring service health is essential for Airbnb to ensure that we maintain a reliable platform for our users. An effective health monitor can proactively identify issues before they impact user experience.
Problem statement: Design a class HealthMonitor that maintains a binary tree structure of services, allowing traversal and health-checking of each service node based on different conditions.
- def __init__(self, service_id: str) -> None: Initializes a service with the given ID.
- def add_service(self, service_id: str, parent_id: str) -> None: Adds a child service under a specified parent service.
- def check_health(self) -> List[str]: Returns a list of service IDs that are unhealthy based on some predefined health criteria.
Example 1:
Input: Service Structure: A -> B -> C (A as root)
Output: ['B', 'C']
Explanation: Assuming B and C report unhealthy status during the health check process.
Constraints:
- Each node can have multiple children, but no more than 10.
- All service IDs are unique strings.

Airbnb employs a complex microservice architecture, and it's critical that our images are efficient and quick to build and deploy. Large image sizes can significantly slow down deployment and lead to wasted resources.
Problem statement: Given a base Dockerfile, optimize it for a microservice to improve build times and reduce image size. Your submission should include various best practices for Dockerfile optimization such as layering, caching, and minimizing unnecessary files.
- FROM: defines the base image.
- RUN: optimizes the build process by managing layers.
- COPY: only copies necessary files into the image.
Example 1:
Input: Dockerfile content with multiple unnecessary layers
Output: Optimized Dockerfile structure with minimal layers and required dependencies
Explanation: The optimized structure combines layers and properly adds only the necessary packages to reduce the final image size.
Constraints:
- Dockerfile must comply with best practices for microservices.
- Output must highlight trade-offs between simplicity and efficiency.

In order to protect our backend services from being overwhelmed by high traffic and ensure fair usage among our users, we need to implement a rate limiter. The rate limiter should allow only a certain number of requests within a defined time window.
Problem statement: Create a class RateLimiter that implements a sliding window mechanism to track requests per user and allows or denies requests based on the predefined limits.
- def __init__(self, limit: int, window: int) -> None: Initializes the rate limiter with a request limit of limit within a time window of window seconds.
- def allow_request(self, user_id: str, timestamp: int) -> bool: Returns True if the request from user_id at timestamp is allowed; otherwise returns False.
Example 1:
Input: limit = 5, window = 60, user_id = 'user1', Requests = [(1, 'user1'), (2, 'user1'), (3, 'user1'), (4, 'user1'), (5, 'user1'), (61, 'user1')]
Output: [True, True, True, True, True, False]
Explanation: The first five requests are allowed, but the sixth request is beyond the limit within the same time window.
Constraints:
- 1 <= limit <= 100
- 1 <= window <= 3600
- 1 <= timestamp <= 10^9