Explain the difference between Kubernetes `requests` and `limits` for both CPU (`cpu.weight` vs `cpu.max` CFS quota) and Memory (`memory.min/low` +.

A strong answer

A strong candidate frames Explain the difference between Kubernetes requests and limits for both CPU (cpu.weight vs cpu.max CFS quota) and Memory (memory.min/low +. around the exact memory layout, compiler semantics, and hardware execution model covered in [Control Groups (cgroups v2), CFS Quota CPU Throttling, Page-Cache OOMKills (exit 137), and OverlayFS Copy-on-Write]. Contrast compressible CPU (throttled via CFS cpu.max every 100 ms) with incompressible Memory (killed with SIGKILL 137 on memory.max), trace why old runtimes read /proc/cpuinfo (64 host cores) instead of cgroup limits, and explain Kubernetes QoS classes (Guaranteed, Burstable, BestEffort).

You deploy an 8-thread Go/Java/Node microservice on a 32-core Kubernetes node with resources.limits.cpu: "500m" (0.5 cores) and limits.memory: "512Mi". Two baffling incidents happen: (1) Even though the 32-core host node is 85% idle, your pod's P99 latency spikes from 5 ms to 195 ms! (2) A cron container inside the pod writes a 400 MB CSV file to /tmp/report.csv while its heap RAM is only 150 MB—and the Linux kernel OOM-kills the container (exit code 137)! Why did writing a file to disk cause an Out-Of-Memory kill, and why did limits.cpu: 500m stall your pod for 93 ms out of every 100 ms?

When engineers encounter this bottleneck in production, a surface-level API description rarely explains what went wrong. In real workloads, every line of code executes against concrete hardware constraints: fixed-width memory cells, CPU cache lines, kernel descriptor tables, network socket buffers, or accelerator memory buses. Without a clear mental model of Linux cgroups v2 (cpu.max CFS Bandwidth Control & memory.max), OOM Killer (exit 137), and OverlayFS, debugging degrades into guesswork—tuning timeouts, adding retries, or scaling instances blindly while the underlying architectural flaw remains untouched.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Calculate CFS Bandwidth Control (cpu.max) throttling stalls when multi-threaded workloads run inside tight CPU limits.
• Mastery of core invariant: Diagnose Exit Code 137 (OOMKilled) across heap, tmpfs, and cgroups v2 Page Cache and tune GOMEMLIMIT / -Xmx to 80% of memory.max.
• Mastery of core invariant: Trace OverlayFS lowerdir/upperdir copy_up and whiteout files to optimize Dockerfile layer sizes and runtime I/O.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.