Google Systems, OS & Memory Safety interview questions

Most candidates say 'rings' and stop. The interviewer is listening for who enforces the boundary, where the kernel must distrust its caller, and why one kernel bug undoes every process boundary at once.

Isolation is enforced by page tables and credentials, then deliberately punched through by debuggers, shared memory and IPC. A strong answer names both the wall and the doors.

Reading rwx bits is the easy half. Interviewers check whether you know what execute means on a directory, why setuid binaries are an attack surface, and what the sticky bit does and does not protect.

The definition takes one sentence. The interview is about the four ways privilege actually moves, and why most escalations are misconfigurations rather than exploits.

The username tells you almost nothing. The interviewer wants the list of privilege transitions reachable from that process, and which of them you would have closed in advance.

Capabilities split root into pieces, but some pieces are nearly the whole thing. A strong answer knows the sets, the dangerous capabilities, and why 'drop all, add one' is the only defensible default.

Everyone knows MAC is 'stricter'. The scored part is why a compromised root process can still be confined, how labels differ from paths, and what you do when the policy blocks production at 2am.

Check, then use: two system calls, and an attacker in between. The answer interviewers want replaces names with handles and checks with atomic operations, and can show it in code.

OpenSSH's design is the model answer, but interviewers want you to derive it: what the parser must never hold, how small the privileged half can get, and the three mistakes that make a privilege drop reversible.

A checklist recital scores 'weak'. The strong answer orders controls by the attacker they stop, treats the baseline as code, and explains how you would notice when someone drifts from it.

Programs rarely name the file they run or load; they search for it. Whoever can write earlier in the search order chooses the code. The answer covers both platforms and the one rule that fixes both.

Linux candidates often freeze here. The model is learnable in five nouns, and interviewers reward the one insight that matters: privileges in a token can matter more than group membership.

Kernel exploits make headlines; misconfigured services, impersonation and stored credentials do the work. The scored answer groups escalation into classes and attaches a control and a detection to each.

Interviewers ask for the protocol first because every AD attack is a protocol property used against you. The strong answer derives each attack from a step in the ticket flow, then attaches the control that breaks it.

You cannot stop every laptop being compromised. You can decide what that laptop holds. The strong answer is about which credentials live where, and making stolen ones useless elsewhere.

Interviewers listen for precision: an overflow is an out-of-bounds write, an over-read is a different bug, and a use-after-free is about lifetime, not bounds. Getting the taxonomy right is most of the easy question.

Reciting the acronyms is the easy part. The scored answer pairs each mitigation with the exploitation step it blocks and the precondition that defeats it, which is why they only work together.

Once data could not run as code, attackers stopped bringing code. The interview checks that you understand code reuse as an idea, and what forward-edge and backward-edge protections each enforce.

'It's just a crash' and 'mitigations are on' are the two answers that get candidates marked down. The scored answer separates the primitive, the reachability and the privilege, and treats a read bug as half of an exploit.

'Rewrite it in Rust' is a slogan, not a plan. The staff answer ranks components by exposure, stops new bugs at the boundary first, and keeps the old code contained while the language mix shifts.

Random input finds shallow bugs. Coverage feedback, sanitizers and a harness that reaches the parser are what make fuzzing find the deep ones. The interview checks all three, plus what happens after the crash.

Tool names are not the answer. Interviewers want to know what each view can and cannot tell you, and why a decompiler's output is a hypothesis to be checked at runtime.

Interviewers give an unfamiliar binary to see method, not stamina. Start from the question, find the code that touches the secret through imports and strings, confirm at runtime, and report what you proved and what you did not.

A bypass screenshot is not a finding. Interviewers look for whether you can separate 'I changed my own copy of the program' from 'I can now do something the server should have stopped'.

The CPU does work it later throws away, but the cache remembers. The strong answer explains that one sentence precisely, then turns it into isolation decisions for shared infrastructure.

Assume the parser will be exploited, then decide what the exploit gets. The scored design has a disposable worker with nothing worth stealing, no way out, and a narrow, validated return path.

Secure Boot refuses to run unsigned code; measured boot records what did run; a TPM lets someone else check that record. Candidates who blur the three cannot reason about attestation at all.

Every obfuscation must still run on the CPU in a form the CPU understands. That single fact tells you how each one is undone, and why obfuscation buys time rather than secrecy.

A single check is a single patch. The design question is how to make removing protection expensive, detectable at scale, and pointless because the server holds the real decisions.

EDR products, profilers, game cheats and banking trojans all use the same trick: make a call to function A run your code first. Knowing the mechanics tells you both how to detect it and why user-mode hooks are a weak place for security controls.

The algorithm is correct and the key never leaves the chip. The attacker reads it anyway from how long, how loud or how hot the computation is, or breaks it by making the chip skip one instruction.

All three face the same impossible brief: let the user's device use a secret without letting the user have it. The good designs change the brief instead of pretending to meet it.

Most Mac compromises do not break these controls. They persuade the user to step around them, or borrow the permissions of an app that already has them.

'It's signed' means different things depending on when the signature is checked: once at install, every time the binary loads, or on every page of memory as it executes.

sudo is a policy engine that runs as root and parses user input. Grant it carelessly and 'run this one command' becomes 'run anything'.

A seccomp filter decides on a system call number and six integers. It cannot read the file path a pointer refers to, and that one limitation shapes every good policy.

Secure Boot checks signatures until the kernel is running. What keeps root from loading unsigned code into the kernel after that is a different set of controls, and interviewers check you know both.

NTLM proves you can answer a challenge. It never proves which server you meant to answer, so whoever sits in the middle can pass your answer to a server you never chose.

Once an attacker is admin on one machine, the credentials cached there decide whether they stop at one machine or reach the domain. Every control in this answer is about that step.

Browsers assume the JavaScript engine will be exploited. The architecture is built so that one bug buys an attacker a locked room, and they need a second, different bug to leave it.

W^X says memory is writable or executable, never both. A JIT compiler's whole job is writing code and then running it. How a runtime squares that circle decides how much an attacker gains from a memory bug.

Typing a command sets off a chain: a system call, a permission check, a loader, dynamic linking and memory protections. Every step is a place security is enforced, and a place it can be bypassed.

On macOS, root is not enough to read a user's documents or watch the screen. TCC decides that, and XPC is how privileged helpers talk, so both are prime targets.

A vulnerability is a gap between what the code assumes and what an attacker can make true. Nearly every one falls into a handful of root causes, and each has a matching way to find and prevent it.

A crash is not an exploit. Turning one into the other takes several steps, and every modern mitigation is designed to break one of them.

The kernel is the single shared authority on a machine. A bug there means any process can rewrite who it is.

Two things make Windows compromise spread: services that run with powerful identities, and a process that holds the credentials of everyone logged on.

Every platform that runs someone else's code (plugins, notebooks, AI agents, serverless) must pick a boundary. The right one depends on what the code may do and what a single bug in the boundary costs.

Both tools read logs and ban addresses after the fact. Knowing what that design can and cannot see is the whole answer, and most candidates call it an authentication control.

Turning off passwords is the easy half. The interview is about the other half: how keys are issued, how long they live, how a host proves itself, and how you cut someone off at 5pm on a Friday.

A patch is a map to the bug it fixes. The interview question is what that means for disclosure timing, open-source fixes and your own patch deadlines.

An agent that renames 4,000 functions overnight is a real gain. An agent that confidently explains what a function does without checking is a liability. Interviewers want both halves and the controls in between.

Default-deny execution is one of the strongest endpoint controls there is, and one of the least deployed. The scored answer explains the rule types, the bypass classes and how to roll it out without a revolt.