Meta Production Engineer interview questions (2026 guide)

This is the most repeated scripting question. One file holds each dinosaur's name, leg length, and diet. The other holds its name, stride length, and stance. Speed is ((stride / leg) - 1) * sqrt(leg * g), with g equal to 9.8. Print the names of the bipedal dinosaurs, fastest first.

import csv
import math

G = 9.8  # metres per second squared


def bipedal_by_speed(legs_path, strides_path):
    leg_length = {}
    with open(legs_path, newline="") as f:
        for row in csv.DictReader(f):
            leg_length[row["NAME"]] = float(row["LEG_LENGTH"])

    speeds = []
    with open(strides_path, newline="") as f:
        for row in csv.DictReader(f):
            if row["STANCE"].strip().lower() != "bipedal":
                continue
            leg = leg_length.get(row["NAME"])
            if leg is None:  # listed in one file but not the other
                continue
            stride = float(row["STRIDE_LENGTH"])
            speed = (stride / leg - 1) * math.sqrt(leg * G)
            speeds.append((speed, row["NAME"]))

    return [name for speed, name in sorted(speeds, reverse=True)]

The question is a join on the name column. Load the first file into a dictionary, then read the second file once.

The data has traps. One name is misspelled, and one dinosaur appears in only one file. Say what you will do with a row that has no match. This code skips it.

If the first file does not fit in memory, sort both files by name and merge them in one streaming pass.

The interviewer is checking whether you plan for slow and broken hosts. A loop that works on three healthy machines can hang for hours on a real fleet.

import shlex
import subprocess
from concurrent.futures import ThreadPoolExecutor


def check(host, process):
    cmd = ["ssh", "-o", "BatchMode=yes", "-o", "ConnectTimeout=5",
           host, f"pgrep -x {shlex.quote(process)}"]
    try:
        result = subprocess.run(cmd, capture_output=True, timeout=15,
                                stdin=subprocess.DEVNULL)
    except subprocess.TimeoutExpired:
        return host, "timed out"
    if result.returncode == 0:
        return host, "running"
    if result.returncode == 1:
        return host, "not running"
    if result.returncode == 255:  # ssh itself failed: network, key, or host key
        return host, "ssh failed"
    return host, f"error {result.returncode}"


def report(hosts, process):
    with ThreadPoolExecutor(max_workers=20) as pool:
        results = list(pool.map(lambda host: check(host, process), hosts))
    lines = [f"{host}: {status}" for host, status in sorted(results)]
    healthy = sum(status == "running" for _, status in results)
    return f"{process} is running on {healthy} of {len(hosts)} hosts\n\n" + "\n".join(lines)

1. Run the checks in parallel, with a limit. Twenty workers finish 100 hosts quickly without opening 100 connections at once.
2. Set two timeouts. ConnectTimeout covers a host that never answers. The timeout argument covers a host that connects and then hangs.
3. Keep the failures apart. pgrep exits with 1 when nothing matches. ssh exits with 255 for any error of its own, such as a refused connection or a rejected key.
4. Never wait for input. BatchMode=yes makes ssh fail at once when a key is missing, and closing standard input stops 20 ssh processes competing for the terminal.

pgrep -x compares against the kernel's process name, which is cut to 15 characters. For a longer name, or a script run by an interpreter, use pgrep -f or systemctl is-active.

To send the report, pass an EmailMessage to smtplib.SMTP. At 10,000 hosts, stop opening SSH sessions and read the answer from an agent that already runs on every machine.

Follow the command through the shell, the system calls, and the kernel.

1. The shell finds the program. It splits the line into ls and -l, then searches each directory in PATH until it finds /usr/bin/ls.
2. The shell creates a child process. It calls clone(), the system call behind fork(), and waits for the child with wait4().
3. The child becomes ls. It calls execve("/usr/bin/ls", ...). The kernel replaces the child's memory with the ls program, and the dynamic loader maps its shared libraries.
4. ls reads the directory. It opens the directory with openat() and reads the entries with getdents64(). An entry holds a name, an inode number, and a file-type hint. It does not hold permissions, owner, size, or times.
5. ls reads each file's metadata. The -l flag needs permissions, owner, size, and time, so ls calls statx() once for every entry. The kernel answers from the file's inode.
6. ls turns numbers into names. The inode stores numeric user and group IDs. ls reads /etc/nsswitch.conf, then /etc/passwd and /etc/group, the first time it meets an ID.
7. ls prints and exits. It sorts the entries, calls write() on standard output, and calls exit_group(0).
8. The shell collects the result. The kernel sends SIGCHLD to the shell, wait4() returns the exit status, and the shell stores it in $?.

Run strace -f on ls -l before your interview. The trace is short enough to read in ten minutes.

Follow-up: how does a system call enter the kernel? On x86-64 the program puts the call number in the rax register, puts the arguments in other registers, and executes the syscall instruction. The processor switches to kernel mode and jumps to the kernel's entry point. The kernel looks up the handler in its system call table, runs it, and returns to user mode. For a file call, the handler goes through the VFS layer, which checks the directory entry and inode caches before it asks the filesystem to read the disk.

Follow-up: how does strace work? It uses the ptrace() system call to stop the traced process at the entry and exit of every system call, then reads the registers to print the arguments and the result. Two stops for every call make the process much slower, so use it with care on a busy production service.

The request may fail at once or succeed, depending on one kernel setting.

A large malloc() calls mmap(), which asks the kernel for virtual address space. No physical memory changes hands yet. A process on x86-64 Linux normally has 128 TB of user address space, so 1 TB fits easily.

The kernel then decides whether to grant the request, using vm.overcommit_memory:

• 0, the default. The kernel refuses a single request larger than RAM plus swap. The 1 TB request fails, and malloc() returns NULL.
• 1, always. The request succeeds.
• 2, strict. The kernel caps the total it will promise at swap plus a share of RAM, 50% by default. The request fails.

When the request succeeds, memory arrives one page at a time. The first write to each 4 KB page causes a page fault, and the kernel maps a physical page at that moment.

The trouble starts when the process writes to more pages than the machine has. The kernel reclaims file cache and swaps pages out. When that is not enough, the out-of-memory killer picks the process with the highest oom_score, roughly the one using the most memory, and sends it SIGKILL. dmesg shows the kill.

We tested this on a machine with 8 GB of RAM and the default setting. A single 1 TB request failed with ENOMEM. The same terabyte requested in 7 GB pieces succeeded and used 9 MB of real memory, because the default check looks at each request by itself.

A zombie is a process that has exited but whose parent has not yet collected its exit status. It has released its memory and uses no CPU. Only its entry in the process table remains, shown as state Z in ps.

You cannot kill a zombie, because it is already dead. There are two ways to clear one:

• Make the parent collect it. The kernel sent the parent SIGCHLD when the child exited, and a correct parent responds by calling wait().
• End the parent. The zombie is then adopted by process 1, usually systemd, or by the nearest subreaper, which collects it.

A few zombies are harmless. Thousands point to a bug in the parent, and they can use up the process ID space so that nothing new can start.

Work from the cheapest evidence to the most expensive, and say what each step rules out.

1. Ask what changed. A deployment, a configuration change, or a restart.
2. Read what the service manager saw. systemctl status myapp shows the exit code, and journalctl -u myapp -n 50 shows the last log lines.
3. Start it by hand as the service user. The error message is often the whole answer.
4. Check what it needs to run. A missing library (ldd), a configuration file with a syntax error, or wrong file permissions.
5. Check what it needs to claim. A port that is already in use (ss -ltnp), a full disk (df -h and df -i), a memory limit, or a limit on open files.
6. Check what it depends on. DNS, the database, and any service it calls during start-up.
7. Trace it. strace -f shows the last system call that failed. ENOENT means a missing file, EACCES means a permission problem, and EADDRINUSE means the port is taken.

Expect to be asked for a temporary fix and a long-term fix. The temporary fix is usually to roll back to the last version that worked. The long-term fix is a check that would have caught the fault before release. Our lessons on investigating without guessing and rolling back safely practise both.

A CPU-bound process spends its time computing. An I/O-bound process spends its time waiting.

A process waiting on the network looks different again: state S, low CPU, low wa, and quiet disks.

For a CPU-bound process, perf top shows which functions use the time. For a waiting one, strace -c -w -p followed by the process ID totals the wall-clock time spent in each system call. Without -w, the time column counts CPU time only, so a blocked read() looks free.

Give the six steps in order, then go deeper wherever the interviewer stops you.

1. DNS turns the name into an address. The browser checks its own cache, then the operating system's cache and /etc/hosts, then asks the configured resolver. On a miss, the resolver asks a root server, which refers it to the .com servers, which refer it to Facebook's own name servers. Each answer is cached for its time to live.
2. A connection opens. The operating system picks a route, normally the default gateway, and uses ARP to learn the gateway's hardware address. Routers then forward each packet by the longest matching prefix in their routing tables. Over TCP, the connection starts with the three-way handshake to port 443: SYN, SYN-ACK, ACK. Over QUIC, which runs on UDP, the connection and encryption handshakes happen together in one round trip.
3. TLS secures it. The browser sends the server name and a key share. The server replies with its certificate and its own key share. The browser checks the certificate against its trusted roots, and both sides derive the same keys. TLS 1.3 needs one round trip.
4. The browser sends the HTTP request. A GET / with headers and cookies, over HTTP/2 or HTTP/3.
5. Meta's servers answer. The connection from step 2 ended at a nearby point of presence, where a layer 4 load balancer picked a proxy. That proxy holds the TLS session and forwards the request to a web server, which builds the page from caches and databases.
6. The browser renders. It parses the HTML, fetches the CSS, JavaScript, and images it finds, runs the scripts, and paints the page.

Two details show you know Meta's own network. More than 75% of its internet traffic was already on QUIC and HTTP/3 in 2020. Its layer 4 load balancer, Katran, is open source.

Mention DNS and expect "what are the layers of DNS caching?" Prepare one level of extra depth for every step.

• Can HTTP run over UDP? Yes. HTTP/3 does. QUIC adds the reliability and ordering that UDP lacks, one stream at a time.
• What changed in TLS 1.3? The handshake takes one round trip instead of two. Older key exchanges and ciphers were removed, so every full handshake has forward secrecy. More of the handshake is encrypted, including the certificate.
• Why is TCP congestion control a problem? Classic TCP treats every lost packet as a sign of congestion and slows down. On a wireless link, loss often has nothing to do with congestion. A new connection also needs several round trips to reach full speed. TCP lives in the kernel, so improvements reach users slowly. QUIC moves congestion control into the application.
• Why does a root server refer you elsewhere? The root zone only lists the name servers for top-level domains such as .com. Delegation keeps each zone's records with its owner, spreads the load, and lets resolvers cache each level separately.
• Which causes make a database slow? On the machine: a saturated disk, swapping, CPU saturation, or lock contention from slow queries. On the network: packet loss and retransmits, a slow DNS lookup on every new connection, or a client pool that has run out of connections. Ask first whether every query is slow or only some.

The usual way to fail this question is to run out of time. Reach a simple, complete design in the first 25 minutes, then deepen it.

Clarify first. How many pages? Is "never twice" a hard rule or a goal? How often do machines fail? How small is a low-end machine?

Put numbers on it. Assume 1 billion pages and 10 fetches a second on each machine. The fleet then fetches 100,000 pages a second, and the crawl takes 10,000 seconds, a little under three hours. That is the best case. Per-site rate limits stretch the real crawl. A list of every seen page, stored as an 8-byte fingerprint of each URL, takes 8 GB in total, or under 1 MB on each machine. Memory is not the hard part. Coordination is.

Give every URL one owner. Hash the site name of each URL to pick the machine that owns it. Only the owner may fetch that URL, and the owner keeps the list of what it has already seen. A machine that finds a link it does not own sends the link to the owner. Hashing by site also lets one machine limit how fast it requests pages from that site. A very large site needs several owners.

Decide what happens when a machine dies. Use consistent hashing so that a dead machine's sites move to a neighbour and nothing else moves. The seen list must survive the failure, so write each fingerprint to a replicated log.

State the trade-off. If a machine records a URL before fetching it and then dies, the page is never fetched. If it fetches first and dies before recording, the page is fetched twice. With failures you cannot rule out both. "Never twice" as a hard rule means recording first and accepting that a page is lost when its fetcher dies. A later repair pass can recover those pages, but it will fetch again any page that was fetched and not yet stored. Ask the interviewer which they want: at most once with gaps, or full coverage with rare repeats.

Run it. Watch pages fetched each second, queue length on each machine, errors for each site, and a counter of duplicate fetches that should stay near zero. Release new crawler code to a few machines before the rest.

The interview capstone practises the same order on a different problem.