Intel Interview Questions (2026): Most Asked, With Answers

Most candidates report a recruiter phone screen first, roughly 30 minutes, checking basic fit and logistics rather than technical depth. That's followed by one or two technical rounds specific to the role, a coding round for software positions, an architecture or circuits round for hardware roles, a process or equipment round for manufacturing and process engineering positions. A behavioral round, sometimes called the "values" or hiring-manager round, usually comes near the end and is where culture-fit and past-project questions concentrate.

For senior and staff-level roles, expect the on-site (often virtual now) to stretch across three to five separate 45-60 minute sessions in a single day rather than being spread across weeks. Entry-level and new-grad loops tend to be shorter and lean more heavily on fundamentals than on open-ended design questions.

A hardware or silicon design role (RTL design, verification, physical design, circuit design) tests digital logic, timing, and often a specific hardware description language, Verilog or SystemVerilog most commonly. Expect questions on setup and hold time, clock domain crossing, and how you'd debug a timing violation, alongside whiteboard logic design.

A software role at Intel, whether it's driver development, firmware, compiler work, or a more conventional backend or tools position, looks closer to a standard software loop: data structures, algorithms, and system design, but with a real chance the interviewer pushes into memory layout, concurrency, or performance the moment your answer touches anything that runs close to hardware. The two loops rarely overlap much beyond the behavioral round.

Pipelining splits instruction execution into stages, fetch, decode, execute, memory access, write-back is the classic five-stage breakdown, and overlaps those stages across multiple instructions instead of finishing one instruction completely before starting the next. While instruction A is in its execute stage, instruction B can already be in decode, and instruction C can already be fetching.

The speedup comes from throughput, not from making any single instruction faster. A five-stage pipeline doesn't cut an instruction's latency by five, it lets the CPU work on five instructions at once instead of one. The catch is that a pipeline stall, from a data dependency or a branch misprediction, costs more the deeper the pipeline runs, since more in-flight instructions have to be flushed or held up.

All three sit between the CPU core and main memory, and the tradeoff going from L1 to L3 is the same tradeoff every level of a memory hierarchy makes: smaller and faster versus larger and slower. L1 is typically 32-64 KB, split into separate instruction and data caches, private to each core, and reachable in a few cycles. L2 is larger, often 256 KB to 2 MB, still usually private per core on modern Intel designs, and a bit slower to reach. L3, sometimes tens of megabytes, is shared across all the cores on the chip and acts as a last stop before a request has to go out to DRAM, which costs an order of magnitude more cycles than any on-chip cache.

A pointer is a variable that holds a memory address, can be reassigned to point somewhere else, can be null, and requires explicit dereferencing with * to access the value it points to. A reference is an alias for an existing variable, has to be initialized when it's declared, can never be reassigned to refer to something else, and can't be null (a reference to a dereferenced null pointer is undefined behavior, not a valid null reference).

int x = 5;
int* p = &x;  // pointer, can be reassigned, can be nullptr
int& r = x;  // reference, permanently bound to x, no null state

p = nullptr;  // fine
// r = nullptr; // doesn't compile, r isn't a pointer

Stack allocation is automatic, tied to a function's scope, and effectively free, incrementing and decrementing a stack pointer. It's limited in size (often a few megabytes per thread by default) and everything on it disappears the moment the function returns. Heap allocation, through malloc/new, gives you memory that outlives the function that allocated it and can be sized dynamically at runtime, but it costs more per allocation and has to be explicitly freed, or wrapped in something that frees it for you.

Rule of thumb: stack for anything with a known size that doesn't need to outlive its scope, heap for anything whose size isn't known until runtime or that needs to survive past the function that created it. In firmware and driver code specifically, heap allocation is often avoided altogether after boot, since a fragmented or exhausted heap on a device with no operating system to recover it is a much worse failure mode than it would be on a general-purpose machine.

Walk the list once, keeping track of the previous node, the current node, and the next node before you overwrite the current node's pointer, since once you flip current->next you lose the only reference to what used to come after it.

struct Node { int val; struct Node* next; };

struct Node* reverse(struct Node* head) {
  struct Node* prev = NULL;
  struct Node* curr = head;
  while (curr != NULL) {
    struct Node* next = curr->next; // save before overwriting
    curr->next = prev;
    prev = curr;
    curr = next;
  }
  return prev; // new head
}

A process has its own isolated address space, its own memory, file descriptors, and resources, and one process crashing doesn't directly corrupt another's memory. A thread lives inside a process and shares that process's address space and most of its resources with every other thread in the same process, so threads can communicate through shared memory directly, but they can also corrupt each other's data if they're not synchronized correctly.

Creating a new process is more expensive than creating a new thread, since the OS has to set up a full separate address space, which is part of why thread pools are so common for handling many concurrent, short-lived units of work.

A context switch is the OS saving the full register state, program counter, and other execution context of the currently running thread, and loading the saved state of a different thread so it can run instead. It's expensive for two reasons: the direct cost of saving and restoring all that state, and the indirect cost of losing whatever data the outgoing thread had warm in the CPU's caches and TLB, which the incoming thread then has to reload from scratch as it runs.

Moore's Law is Gordon Moore's 1965 observation, later refined, that the number of transistors that could economically fit on a chip roughly doubled every two years. It was never a law of physics, it was an observation about the economics and pace of semiconductor manufacturing improvements, which is exactly why it's been able to slow down without the industry hitting a hard wall.

The honest answer in 2026 is that pure transistor doubling at the old cadence has slowed, but the industry keeps finding other ways to grow performance, advanced packaging, chiplets, specialized accelerators, that don't rely purely on shrinking a single monolithic die. A good interview answer acknowledges the slowdown instead of reciting the doubling claim as if it's still literally true.

It starts with a thin, pure silicon wafer, and builds up transistor layers on it through hundreds of repeated steps: depositing thin films of material, patterning them with photolithography, etching away everything outside the pattern, then implanting or diffusing dopants to control how each region conducts. Layers stack on top of each other, each one aligned with extreme precision to the layers below, until the full transistor and interconnect structure is complete.

After all the layers are done, the wafer gets tested (probed) while individual chips are still attached to it, cut apart (diced) into individual dies, and the working ones get packaged, wire-bonded or bump-bonded into the casing that eventually plugs into a motherboard or device. A single modern fab process can involve hundreds of individual steps and take weeks from a bare wafer to a finished, tested chip.

A transistor is, at its simplest, an electrically controlled switch. In the MOSFET design used in modern chips, a voltage applied to the gate terminal controls whether current can flow between the source and drain terminals, on or off. Billions of these switches, wired together in specific patterns, form the logic gates (AND, OR, NOT, and combinations of them) that add up to everything a CPU does, arithmetic, memory storage, control logic, all of it built from switches turning on and off.

The standard answer combines a hash map for O(1) lookup with a doubly linked list to track recency order. The hash map maps each key to its node in the linked list, so you can jump straight to any entry instead of scanning for it. On every access, move that node to the front of the list (most recently used). When the cache is full and a new key needs to be inserted, evict the node at the back of the list (least recently used) and remove it from the map too.

class LRUCache {
  int capacity;
  std::list<std::pair<int,int>> items; // front = most recent
  std::unordered_map<int, std::list<std::pair<int,int>>::iterator> lookup;
public:
  LRUCache(int cap) : capacity(cap) {}
  int get(int key) {
    if (lookup.find(key) == lookup.end()) return -1;
    items.splice(items.begin(), items, lookup[key]); // move to front
    return lookup[key]->second;
  }
  void put(int key, int value) {
    if (lookup.count(key)) {
      items.erase(lookup[key]);
    } else if (items.size() >= capacity) {
      lookup.erase(items.back().first);
      items.pop_back();
    }
    items.push_front({key, value});
    lookup[key] = items.begin();
  }
};

Pick an example where you actually said something, not one where you privately disagreed and went along quietly. Walk through what you did to raise it, whether you brought data or a concrete alternative rather than just an objection, and what happened afterward, including if the team ultimately went a different direction than you wanted. An answer that ends with "and I was right" reads worse than one that's honest about a case where you were overruled and it turned out fine, or even a case where you were wrong.

Pick a real failure, not a thinly disguised success story. Interviewers can tell the difference between "we shipped two weeks late but it was actually fine" and an actual failure with a real consequence. The part that matters most is what changed afterward, in your own habits or in the team's process, not just an apology or a generic lesson-learned line.

Standard behavioral format, past-tense, specific-example questions rather than hypotheticals: tell me about a time you disagreed with a decision, tell me about a project that slipped, tell me about a conflict with a peer. Intel interviewers commonly ask you to walk through the outcome and what you'd do differently, not just the situation, so an answer that stops at "and then we fixed it" reads as incomplete.

One thing that comes up more at Intel than at a lot of companies: questions about working through disagreement directly rather than escalating it. That traces back to a management practice the company has been associated with for decades, sometimes called "constructive confrontation," the idea that surfacing disagreement openly and quickly beats letting it fester through indirect channels. You don't need to name the concept, but an answer that shows you raised a concern directly with the person involved, rather than going around them, tends to land better here than it might elsewhere.

It varies by team, but live coding and live design rounds are far more common than take-home assignments at Intel, especially for core engineering roles. Some tooling, internal-platform, or newer product teams do use a short take-home for a specific practical skill, and manufacturing/process roles occasionally include a written technical assessment rather than a take-home project.

If you do get a take-home, treat the accompanying write-up as part of the deliverable. A working solution with no explanation of trade-offs reads as weaker than a slightly rougher solution paired with clear reasoning about what you'd do differently with more time.

A modern pipelined CPU can't afford to wait and see which way a branch goes before fetching the next instruction, so it guesses. Branch prediction uses history of how that branch (or similar branches) resolved in the past to predict taken or not-taken, and speculatively fetches and executes instructions down the predicted path before the branch condition is actually known.

A mispredict means every instruction the CPU speculatively started down the wrong path has to be discarded, and the pipeline has to refill from the correct target address. On a deep pipeline that's a real penalty, often ten to twenty cycles thrown away, which is exactly why branch predictors got so sophisticated: even a small improvement in prediction accuracy pays off across billions of branches a second.

In-order execution processes instructions strictly in program order, so if one instruction stalls waiting on a slow memory load, every instruction behind it stalls too, even ones that have nothing to do with that load. Out-of-order execution lets independent instructions further down the stream execute while an earlier one is still waiting, as long as the CPU can guarantee the final results commit in the original program order so the program behaves correctly.

// If load from memory (a cache miss, slow) doesn't block independent work:
int x = slow_load(ptr);  // stalls waiting on memory
int y = a + b;      // independent, can execute while x is still loading
int z = c * d;      // also independent, also doesn't need to wait

The hardware that makes this safe, reorder buffers, reservation stations, register renaming, is a lot of what separates a high-performance core design from a simpler in-order one, and it's a fair thing to be asked to sketch out at a whiteboard level in an architecture interview.

Cache coherence is the guarantee that every core in a multi-core system sees a consistent view of memory, even though each core has its own private cache holding its own copy of shared data. Without a coherence protocol, one core could update a value in its cache while another core keeps reading a stale copy from its own cache indefinitely.

MESI names the four states a cache line can be in: Modified (dirty, only this cache has it), Exclusive (clean, only this cache has it), Shared (clean, possibly cached by other cores too), and Invalid (this cache's copy is no longer valid). When one core writes to a line, other cores holding that line in Shared or Exclusive state get invalidated, forcing them to fetch the updated value the next time they need it. It's a protocol built on cores talking to each other, or to a shared directory, every time a cache line's ownership changes.

Virtual memory means every program address a CPU sees has to be translated to a physical memory address through page tables, and walking a multi-level page table on every single memory access would be far too slow. A translation lookaside buffer, TLB, caches recent virtual-to-physical translations so most memory accesses skip the page-table walk entirely.

On a TLB miss, the CPU has to walk the page table structure in memory to find the mapping, fill the TLB with the result, and only then complete the original memory access, a real latency hit compared to a TLB hit. That's part of why workloads that jump around a huge address space unpredictably (rather than staying within a small working set) tend to run slower: they thrash the TLB the same way a working set larger than cache thrashes a data cache.

Undefined behavior is anything the C standard explicitly places no requirements on. The compiler is free to do literally anything, crash, produce a nonsensical result, or optimize based on the assumption that the undefined case never happens at all, which is the part that surprises people most.

int foo(int x) {
  return x + 1 > x; // signed overflow is UB
}
// A compiler is allowed to assume x + 1 > x is always true (since overflow
// "can't happen"), and optimize the whole function down to `return 1;`
// even for INT_MAX, where the mathematically correct answer would be false.

Signed integer overflow, dereferencing a null or dangling pointer, and reading an uninitialized variable are the three that come up constantly in interviews and in real bug reports. The dangerous part isn't that the program crashes reliably, it's that it often doesn't, right up until a different compiler version or optimization level changes what the undefined case actually does.

Brian Kernighan's trick is the answer most interviewers want to see: n & (n - 1) clears the lowest set bit, so counting how many times you can do that before n hits zero gives you the popcount, in a number of iterations equal to the number of set bits rather than the number of total bits.

int count_set_bits(unsigned int n) {
  int count = 0;
  while (n) {
    n &= (n - 1); // clears the lowest set bit
    count++;
  }
  return count;
}

Worth mentioning that many modern x86 CPUs have a dedicated POPCNT instruction that does this in hardware in a single cycle, which is the answer a systems-minded interviewer is often fishing for as a follow-up: know the software algorithm, but also know when the hardware already solved the problem for you.

A race condition happens when two or more threads access shared data at the same time, at least one of them writing, without synchronization, so the outcome depends on the exact timing of how their operations interleave. Even something that looks like a single operation, counter++, is actually a read, an increment, and a write, and two threads doing that concurrently can lose an increment.

std::mutex m;
int counter = 0;

void increment() {
  std::lock_guard<std::mutex> lock(m); // held for the scope of this block
  counter++;
}

std::lock_guard acquires the mutex on construction and releases it automatically on destruction, which matters because it releases correctly even if an exception is thrown partway through the critical section, something manual lock/unlock calls get wrong constantly.

A memory leak is heap memory that's allocated and never freed, because every pointer that referenced it went out of scope or got overwritten before anyone called delete on it. In a long-running process like a driver or a service, a small per-request leak eventually exhausts available memory and takes the whole process down.

void leaky() {
  int* p = new int[1000];
  if (some_condition) {
    return; // early return, never reaches delete[], p leaks
  }
  delete[] p;
}

void safe() {
  auto p = std::make_unique<int[]>(1000);
  if (some_condition) {
    return; // unique_ptr's destructor still runs, memory freed automatically
  }
} // freed here too

unique_ptr and shared_ptr tie the lifetime of heap memory to a stack-allocated object's destructor, so the memory gets freed on every exit path, including early returns and thrown exceptions, without the programmer having to remember every single one by hand.

Deadlock is a set of threads each waiting on a resource held by another thread in the same set, so none of them can ever proceed. The four Coffman conditions all have to hold simultaneously: mutual exclusion (a resource can only be held by one thread at a time), hold and wait (a thread holds one resource while waiting for another), no preemption (a resource can't be forcibly taken from the thread holding it), and circular wait (a cycle exists in the graph of who's waiting on whom).

// Classic two-mutex deadlock
// Thread A: lock(mutex1); lock(mutex2);
// Thread B: lock(mutex2); lock(mutex1);
// If A holds mutex1 and B holds mutex2 at the same instant, both wait forever.
// Fix: always acquire locks in the same global order (e.g., always mutex1 first).

Breaking any single one of the four conditions is enough to prevent deadlock, and the most common fix in practice, always acquiring locks in a fixed global order, works by eliminating circular wait.

A page fault happens when a program accesses a virtual memory address that isn't currently mapped to physical memory, and the CPU traps into the OS to resolve it rather than crashing outright. A minor page fault means the data is already in physical RAM somewhere, just not mapped into this process's page table yet, so the OS updates the mapping and execution continues quickly. A major page fault means the data actually has to be read from disk (or a backing store), which is orders of magnitude slower.

Heavy major-fault activity, sometimes called thrashing, is the classic symptom of a system running with too little physical memory for its working set, constantly swapping pages in and out.

Producer-consumer describes one or more threads generating data (producers) and one or more threads consuming it (consumers), coordinating through a shared queue. The core problems are avoiding a race on the queue itself, blocking producers when the queue is full, and blocking consumers when it's empty, all without busy-waiting and burning CPU.

std::mutex m;
std::condition_variable notFull, notEmpty;
std::queue<int> q;
const size_t maxSize = 100;

void produce(int item) {
  std::unique_lock<std::mutex> lock(m);
  notFull.wait(lock, [] { return q.size() < maxSize; });
  q.push(item);
  notEmpty.notify_one();
}

int consume() {
  std::unique_lock<std::mutex> lock(m);
  notEmpty.wait(lock, [] { return !q.empty(); });
  int item = q.front();
  q.pop();
  notFull.notify_one();
  return item;
}

Condition variables are the piece candidates most often forget, they let a thread sleep until a specific condition becomes true instead of spinning in a loop checking a flag over and over, which wastes CPU cycles for no benefit.

A CPU and compiler are both allowed to reorder memory operations for performance, as long as the reordering doesn't change the outcome from the perspective of a single thread running alone. On a single core that guarantee is enough. Across multiple cores it isn't, because one core's reordered writes can become visible to another core in a different order than the first core issued them.

A memory barrier (fence) forces ordering at a specific point, telling the CPU that everything before the barrier has to become visible to other cores before anything after it does. This matters constantly in lock-free code and in driver code writing to memory-mapped hardware registers, where the order two writes actually reach the device in can change whether the hardware does the right thing at all.

Photolithography is the process of transferring a circuit pattern onto a wafer using light: a mask defines the pattern, light shines through it onto a light-sensitive coating on the wafer, and the exposed (or unexposed, depending on the resist type) areas get chemically developed away, leaving the pattern behind to guide the next etching step.

The physical limit on how small a feature you can pattern is tied to the wavelength of light used, smaller features need shorter wavelengths. Extreme ultraviolet (EUV) lithography, using a wavelength around 13.5 nanometers, became necessary because older deep ultraviolet techniques (193nm light, with multiple-patterning tricks to squeeze out smaller features) were running out of room for the feature sizes leading-edge chips now need. EUV is enormously expensive and mechanically difficult, the light is absorbed by essentially everything including air, which is a big part of why leading-edge fabs cost billions of dollars to build.

Yield is the percentage of chips on a wafer that come out fully functional after manufacturing and testing, out of the total number of chip sites on that wafer. A wafer costs roughly the same to process whether it ends up with 95 percent good chips or 60 percent good chips, so yield directly determines the effective cost per working chip, low yield means every good chip has to absorb the cost of all the bad ones on the same wafer.

New, smaller process nodes almost always start with lower yield than a mature node, since more can go wrong at smaller feature sizes, and a huge share of the engineering effort in the first year or two of a new node is specifically about closing that yield gap, finding and fixing the defect mechanisms that are killing otherwise-good chips.

Instead of building an entire chip as one large, monolithic piece of silicon, advanced packaging connects multiple smaller dies, chiplets, together inside a single package, sometimes stacked vertically (Intel's Foveros technology) rather than laid out side by side. Each chiplet can even be manufactured on a different process node optimized for what that piece actually does, a compute-heavy chiplet on the leading-edge node, an I/O chiplet on an older, cheaper one.

The motivation is largely yield and cost. A single giant monolithic die has a much higher chance of containing at least one defect than several small dies do, since defect probability scales with area, and a defect anywhere on a monolithic die can ruin the whole thing. Splitting a design into smaller chiplets means one bad chiplet only wastes that chiplet, not an entire large die, and it lets each piece use whichever process node makes the most economic sense for its job.

This comes up a lot at Intel because cross-team dependencies are constant, a driver team needs a firmware team to change something, a design team needs validation to prioritize a specific test. A strong answer shows you understood the other person's actual incentives and constraints, not just that you asked nicely or escalated to a manager. Escalating immediately, without first trying to make the case directly, tends to read as a weaker answer here than it might at a smaller company.

A generic "I love hardware" answer falls flat here. A better answer connects something specific, the product line you'd actually be working on, the shift toward Intel Foundry serving external customers, a technical challenge unique to the group you're interviewing for, to your own background and what you actually want to work on next. If you genuinely don't know much about the specific group yet, it's fine to say so and ask the interviewer what makes their team's problems interesting, that's a better answer than reciting something generic you found on the company's careers page.

Walk through how you found it, whether it was your own bug or someone else's, how you assessed the severity and decided whether it needed an immediate hotfix versus a normal-priority fix, and how you communicated it, to your team, and if relevant, to whoever owns the customer relationship. In hardware-adjacent roles specifically, this question sometimes carries more weight than it would at a pure software company, since a shipped hardware bug can be far more expensive to fix than a shipped software bug, a firmware patch might be possible, a silicon defect might not be.

CISC (complex instruction set computing) designs pack more work into each individual instruction, variable-length instructions, instructions that can directly operate on memory, at the cost of a more complex decoder. RISC (reduced instruction set computing) uses simpler, fixed-length instructions and pushes more of the work onto the compiler generating longer sequences of simple operations, in exchange for a simpler, faster decode stage.

x86 is architecturally CISC at the instruction set level, that's the interface software actually programs against, but for decades now, internally, x86 CPUs decode those complex CISC instructions into simpler internal micro-operations and execute those with a RISC-like out-of-order execution core underneath. The distinction that used to genuinely separate performance characteristics of CISC versus RISC chips has mostly become an implementation detail invisible to software, which is worth saying explicitly if asked, since a purely textbook CISC-versus-RISC answer misses that x86 has been a hybrid underneath for a very long time.

Intel Foundry, the manufacturing arm that now also fabricates for external customers rather than only Intel's own designs, tends to interview more heavily around process technology, yield, and customer-facing technical support, since the group's whole business model depends on serving outside chip designers as clients, not just building Intel's own products. Expect more questions about process node characteristics, defect density, and how you'd communicate a yield or schedule problem to an external customer.

Product groups like Client Computing (consumer CPUs) or Data Center and AI lean closer to a traditional silicon-company loop: architecture, performance, and product-specific questions about the actual chip line you'd be working on. If you're not sure which side a role sits on, ask the recruiter directly during the screen. It genuinely changes how you should prepare.

A deeper pipeline splits each instruction into more stages to raise clock frequency, but it still only issues one instruction per stage per cycle. Superscalar execution is a separate, orthogonal idea: the CPU has multiple parallel execution units and can issue and complete more than one instruction in the same cycle, as long as those instructions are independent of each other and there's available hardware for each of them.

A modern high-end core combines both, a moderately deep pipeline for frequency, and wide superscalar issue, often four to eight instructions per cycle, for throughput. Confusing the two in an interview is a common tell that a candidate has memorized the vocabulary without understanding what each mechanism is actually solving.

Speculative execution is the broader idea behind branch prediction: the CPU executes instructions before it's certain they should run at all, betting that the bet will usually pay off, and rolling back architectural state if it guessed wrong. The problem discovered in 2018 with Spectre and Meltdown is that "rolling back architectural state" doesn't fully erase every trace of the speculation. Microarchitectural side effects, specifically what ended up cached versus not cached during the speculative window, persisted even after the CPU discarded the wrong-path results.

An attacker could speculatively access memory it shouldn't be allowed to read, and even though the CPU correctly threw away the actual result, it could infer the value of that memory by timing subsequent cache accesses, since data the speculative path touched stayed in cache a little faster to re-read than data it never touched. It's a good example of a bug at the intersection of performance engineering and security, and it's a fair question to expect if you're interviewing for anything close to core architecture at Intel, since Intel's own products were directly affected and the company has published extensively on the mitigations.

A memory pool pre-allocates one large block up front and hands out fixed-size chunks from it instead of calling malloc for every individual allocation. You'd bother because general-purpose allocators have real overhead per call, and in a hot path allocating and freeing thousands of same-sized objects a second, that overhead and the fragmentation it causes over time actually matter.

class MemoryPool {
  std::vector<char> buffer;
  std::vector<void*> freeList;
  size_t chunkSize;
public:
  MemoryPool(size_t chunkSize, size_t count) : chunkSize(chunkSize) {
    buffer.resize(chunkSize * count);
    for (size_t i = 0; i < count; i++) {
      freeList.push_back(buffer.data() + i * chunkSize);
    }
  }
  void* alloc() {
    if (freeList.empty()) return nullptr;
    void* p = freeList.back();
    freeList.pop_back();
    return p;
  }
  void free(void* p) { freeList.push_back(p); }
};

The tradeoff is you give up flexibility, every chunk is the same fixed size, in exchange for allocation and deallocation that's close to O(1) with none of the general allocator's bookkeeping. This pattern shows up a lot in firmware and driver code where allocation latency has to be predictable, not just fast on average.

A lock-free data structure guarantees that the overall system makes progress even if some individual thread gets suspended at an arbitrary point, typically implemented with atomic compare-and-swap operations instead of mutexes. No thread can permanently block the whole system by holding a lock and getting descheduled, since there's no lock to hold in the first place.

It's not the same as wait-free, which is a stronger guarantee that every individual thread finishes its operation in a bounded number of steps, regardless of what other threads are doing. A lock-free structure can still let one specific thread retry its compare-and-swap indefinitely if it keeps losing the race to other threads, the system as a whole is making progress, but that one thread's own progress isn't guaranteed. Wait-free algorithms are rarer and considerably harder to write correctly, which is exactly why interviewers use this distinction to separate candidates who've read about lock-free programming from ones who've actually implemented it.

Process node names used to track a real physical measurement, historically the minimum gate length on a transistor. Over the last couple of process generations across the industry, that direct correspondence broke down. Node names became more of a marketing and generational label, roughly comparable across a company's own history but not a literal nanometer measurement of any single feature, and increasingly not comparable across different manufacturers using different naming conventions for a similar actual density.

That's exactly why an interviewer asking this question isn't testing trivia, it's testing whether you understand that "smaller number equals better chip" is a rough heuristic at best now, and that actual transistor density, power, and performance characteristics matter more than the marketing name of the node itself. Intel's own past node naming has been the subject of real industry scrutiny on this exact point.

This question is specifically fishing for whether you'll actually change your mind when the evidence says you should, versus defending your original position because you'd already committed to it publicly. A strong answer describes a real instance where you initially expected one outcome, ran into data or a test result that said otherwise, and describes what you actually did next, more investigation, changing the approach, or in some cases genuinely disagreeing with the data because you found a flaw in how it was collected, which is also a legitimate answer if you can explain your reasoning clearly.

The weak version of this answer describes noticing contradictory data and doing nothing different because of it. That's the detail interviewers are actually listening for.

Legacy BIOS ran in 16-bit real mode, booted from a fixed, tiny region of a disk (the master boot record), and had no standardized way to verify that the code it was about to hand control to hadn't been tampered with. UEFI (Unified Extensible Firmware Interface) runs in native processor mode from boot, supports much larger and more flexible boot loaders and a real file system on the boot partition, and, critically for security, defines Secure Boot, a mechanism where each stage of the boot chain cryptographically verifies the signature of the next stage before handing off execution to it.

That chain of verification is what prevents a bootkit, malware that infects the boot process itself, from silently inserting itself before the operating system even loads and gaining a foothold that's extremely hard to detect from within the OS afterward, since the OS itself only ever ran after the malicious code already had control. UEFI's larger, more programmable environment is also why firmware security itself became its own serious discipline, more code running before the OS means more surface area to get wrong.

Extensions like SSE and AVX add wider registers and instructions that operate on multiple data elements in a single instruction, SIMD, single instruction, multiple data, so one AVX instruction can, for example, add eight pairs of floating-point numbers at once instead of a scalar loop doing it one pair at a time. That's a large speedup for workloads that are naturally data-parallel, image processing, physics simulation, certain machine learning kernels.

// Without the CPUID check, this crashes with an illegal instruction fault
// on any CPU that doesn't actually support AVX2.
if (__builtin_cpu_supports("avx2")) {
  process_avx2(data);
} else {
  process_scalar(data); // fallback path
}

Not every CPU in the field supports every extension, older chips, and some lower-tier or embedded parts, may lack a given instruction set entirely. Software has to check for support at runtime, typically via the CPUID instruction, before it dares to execute an instruction from that extension, because executing an unsupported instruction doesn't degrade gracefully, it faults immediately. Shipping a binary that assumes AVX-512 support without checking first is a real, recurring category of production bug.

Start by asking what the actual guarantee needs to be, a hard cap per second, a smoother average over a minute, and whether it needs to work across multiple servers or just one process, since that changes the whole design. A token bucket is the answer most interviewers expect by default: tokens refill at a fixed rate up to some maximum, and every request consumes one token, gets rejected or queued if none are available. It naturally allows short bursts up to the bucket size while still enforcing a long-run average rate.

If the limiter has to work across multiple servers rather than a single process, the state (token counts, or a sliding window of recent request timestamps) has to live somewhere shared, typically something like Redis with an atomic increment-and-check operation, since two servers both reading a stale count and both deciding independently to allow a request is exactly the race condition that breaks the whole guarantee.

Start from what the hardware actually exposes: a set of memory-mapped registers for control and status, and usually an interrupt line to signal the CPU when something needs attention, rather than forcing the CPU to poll the device constantly. The driver's job is to translate between the OS's generic device model, whatever standard interface the OS expects for this class of device, and this specific device's actual register layout and quirks.

Key design decisions: how you handle concurrent access from multiple threads calling into the driver at once (usually a lock around the device state), whether you poll or rely on interrupts for completion notification (interrupts are more efficient but add real complexity around handling them safely), and how you structure the interrupt handler itself, since a lot of OSes require interrupt handlers to do minimal work immediately and defer the heavier processing to a separate context, because interrupt handlers run with interrupts disabled and can't safely do things like sleep or allocate memory.

Each machine needs a lightweight local agent that reads hardware and OS performance counters on an interval and batches them before sending, rather than sending every individual data point immediately, since that would overwhelm the network and the ingestion tier with tiny, high-overhead requests. Batching and compressing on the client side is the first lever, before you even get to the server design.

On the ingestion side, a message queue in front of the storage layer absorbs bursts and decouples the rate machines produce data at from the rate the storage tier can actually write it at. Time-series-optimized storage (rather than a general relational database) matters once you're at this scale, since the write pattern, append-only, timestamped, keyed by machine and metric, is exactly what those systems are built for, and a general-purpose database's indexing overhead becomes a real cost at high enough volume.

The two ideas that matter most at that scale are incremental builds and remote caching. Incremental means the system tracks a dependency graph precise enough to know that changing one file only requires rebuilding the targets that actually depend on it, not the entire codebase. Remote caching means if another engineer, or a CI machine, already built a given target from the exact same inputs, you fetch the cached output instead of rebuilding it yourself, which turns a lot of "clean" builds into what's effectively a large download.

Getting this right requires the build to be hermetic, meaning a given set of inputs always produces the same output regardless of which machine or environment built it, since cache correctness completely depends on that guarantee holding. A build that isn't reproducible can't safely be cached at all, because you can't trust that a cached result is actually valid for your current inputs.

The core technique is a dual-bank (A/B) update scheme: the device keeps two copies of its firmware in separate flash regions, always boots from whichever bank is currently marked valid, and writes a new update entirely into the inactive bank while the active bank keeps running normally. Only after the new image is fully written and verified, typically with a checksum or cryptographic signature check, does the device flip a small piece of metadata marking the new bank as the one to boot from next.

Power loss at any point during the write only affects the inactive bank, which was never marked bootable in the first place, so the device just reboots into the still-intact previous version. The one component that absolutely cannot be allowed to fail is the small piece of logic that reads the "which bank is active" flag at boot, so that logic is kept as minimal and bulletproof as possible, often in a separate, unchanging bootloader stage that itself never gets updated by the same mechanism it's protecting.