Meta Systems, OS & Memory Safety interview questions

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.

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.

'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.

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'.

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.

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.

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.

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.

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.