Question 1

How would you design a high-performance web server at the OS level?

Accepted Answer

Non-blocking I/O with epoll (Linux) / kqueue (BSD), SO_REUSEPORT for multi-process accept(), sendfile() for zero-copy static file serving, TCP buffer tuning, and CPU affinity to reduce context switching. nginx architecture: master + N workers (one per CPU), each using epoll. SO_REUSEPORT: kernel load-balances accept() across workers — no thundering herd. sendfile: serves files with zero user-space copies. TCP_NODELAY: disables Nagle for low-latency. net.core.somaxconn: increase listen backlog.

Question 2

What is eBPF and what capabilities does it bring to Linux systems?

Accepted Answer

eBPF allows safe, sandboxed programs to run in the kernel for observability (tracing), networking (XDP), and security (seccomp) — without writing kernel modules, eliminating recompilation and reboot. eBPF programs are verified by the kernel (no crashes, no infinite loops) then JIT-compiled. Use cases: Cilium (Kubernetes networking + security via eBPF), Datadog (zero-overhead tracing), Cloudflare (DDoS mitigation at XDP layer). bpftrace lets you write tracing scripts without kernel code.

Question 3

How do containers differ from virtual machines at the OS level?

Accepted Answer

Containers use kernel namespaces and cgroups for isolation while sharing the host kernel — lightweight and fast to start; VMs emulate hardware and run completely separate kernels — stronger isolation, higher overhead. Container: same kernel, isolated via pid/net/mnt/user namespaces + cgroup resource limits. Start in milliseconds, ~MB overhead. VM: hypervisor (Type 1: VMware ESXi, KVM; Type 2: VirtualBox) virtualizes hardware, each runs its own OS. ~GB overhead, seconds to start. Containers are preferred for microservices; VMs for stronger security boundaries.

Question 4

What are Linux cgroups and how does Kubernetes use them to enforce resource limits?

Accepted Answer

cgroups (control groups) are a kernel mechanism that limits and accounts for CPU, memory, I/O, and network resources for groups of processes — Kubernetes uses them to enforce pod resource requests (guaranteed) and limits (maximum). Pod with resources.limits.memory: 256Mi → kubelet sets cgroup memory.limit_in_bytes=268435456. Exceeding this → OOMKilled. CPU limit → CPU throttling via cpu.cfs_quota_us. cgroups v2 unified hierarchy improves accuracy. The kubelet, container runtime (containerd), and kernel work together through this mechanism.

Question 5

How would you design a system to achieve consistent sub-millisecond tail latency at the OS level?

Accepted Answer

Use SCHED_FIFO real-time scheduling for critical threads, isolate CPU cores (isolcpus), disable THP, pin IRQs to specific CPUs, use huge pages for TLB efficiency, and disable CPU frequency scaling (performance governor). SCHED_FIFO: preempts all normal threads. isolcpus: dedicate cores exclusively to your process — no scheduler interference. IRQ affinity: route interrupts away from latency-critical CPUs. Performance governor: no frequency scaling. This is standard for HFT (high-frequency trading) and real-time audio systems.

Operating Systems — Tech Lead Interview Questions

More Tech Lead Topics

Operating Systems at Other Levels