Expert JavaScript Interview Questions and Answers

V8 Internals V8 (Chrome/Node.js engine) compiles JavaScript to native machine code using a multi-tier JIT system. It does not interpret bytecode line-by-line — it compiles and optimises hot code paths.

V8 pipeline:

• Parser — produces an AST from source
• Ignition — bytecode interpreter, fast startup, generates type feedback
• Maglev — mid-tier JIT (V8 v11+), compiles hot functions quickly
• TurboFan — optimising JIT, generates highly optimised native code using type feedback from Ignition
• Deoptimisation — if assumptions break (e.g., argument type changes), TurboFan deoptimises back to Ignition

// Type feedback -- V8 tracks what types flow through each operation
function add(a, b) { return a + b; }

add(1, 2);       // V8 learns: a=int, b=int → compiles fast integer add
add(1, 2);
add(1, 2);       // now "hot" → TurboFan compiles it with int assumption
add("1", "2");   // DEOPT! string instead of int → back to interpreted mode

// This is why type stability matters for performance:
// Consistent types → JIT produces fast code
// Inconsistent types → JIT deoptimises repeatedly

// Check optimisation status (Node.js)
function myFn(x) { return x * 2; }
// Call multiple times to trigger JIT
for (let i = 0; i < 1000; i++) myFn(i);
// --allow-natives-syntax flag:
// %OptimizeFunctionOnNextCall(myFn)
// myFn(42)
// console.log(%GetOptimizationStatus(myFn)) // 1 = optimised

// Inline caches (ICs) -- V8 caches property access paths
const point = { x: 1, y: 2 };
point.x; // IC miss: look up 'x' in the object's hidden class → cache the path
point.x; // IC hit: use cached offset directly (fast!)
point.x; // IC hit again

V8 Internals V8 uses hidden classes (called “Shapes” or “Maps” internally) to enable efficient property access. Objects with the same structure share a hidden class, allowing V8 to compile property accesses to simple memory offsets.

// Hidden class transition diagram
const p1 = {};           // HC_empty
p1.x = 1;               // HC_x (new hidden class created)
p1.y = 2;               // HC_x_y (another transition)

const p2 = {};           // HC_empty
p2.x = 3;               // HC_x (same as p1 -- shared!)
p2.y = 4;               // HC_x_y (same as p1 -- shared!)
// p1 and p2 share the same hidden class → V8 compiles access once for both

// ❌ Different property addition order = different hidden classes
const a = {}; a.x = 1; a.y = 2;  // HC: {} → {x} → {x,y}
const b = {}; b.y = 1; b.x = 2;  // HC: {} → {y} → {y,x}   DIFFERENT!
// V8 cannot share the inline cache for a and b

// ✅ Always add properties in the same order
// ✅ Better: initialise all properties in the constructor
class Point {
  constructor(x, y) {
    this.x = x;  // always same order → same hidden class
    this.y = y;
  }
}

// ❌ Adding properties conditionally changes the hidden class
function createPoint(hasZ) {
  const p = { x: 1, y: 2 };
  if (hasZ) p.z = 0;  // some points get HC_x_y, some get HC_x_y_z
  return p;
}

// ❌ delete disrupts hidden classes (property is removed = new HC)
delete point.x;  // creates a new hidden class, loses optimisation

// Object.create(null) -- prototype-less object (faster property lookup)
const dict = Object.create(null);  // no prototype chain to walk

// Monomorphic, polymorphic, megamorphic inline caches
// Monomorphic: one shape → fastest (single IC hit)
// Polymorphic: 2-4 shapes → fast (IC with type check)
// Megamorphic: 5+ shapes → slow (falls back to hash table lookup)

Binary Data ArrayBuffer is a fixed-length raw binary data buffer in memory. TypedArray views provide a typed interface to read and write the buffer — with zero-overhead numerical access (no boxing).

// ArrayBuffer -- raw memory (16 bytes here)
const buf = new ArrayBuffer(16);

// TypedArray views -- different interpretations of the same buffer
const int8   = new Int8Array(buf);     // 16 signed 8-bit integers
const uint16 = new Uint16Array(buf);   //  8 unsigned 16-bit integers
const float32 = new Float32Array(buf); //  4 32-bit floats
const float64 = new Float64Array(buf); //  2 64-bit floats

// Write with one view
float32[0] = 3.14;

// DataView -- precise control over byte order (endianness)
const view = new DataView(buf);
view.setInt32(0, 0x12345678, true);   // little-endian
view.getInt32(0, false);              // read as big-endian

// TypedArrays are used for:
// WebGL (GPU buffer data)
const vertices = new Float32Array([
  -0.5, -0.5, 0.0,
   0.5, -0.5, 0.0,
   0.0,  0.5, 0.0
]);
gl.bufferData(gl.ARRAY_BUFFER, vertices, gl.STATIC_DRAW);

// Web Audio (audio processing)
const audioBuffer = context.createBuffer(2, sampleRate, sampleRate);
const channelData = audioBuffer.getChannelData(0); // Float32Array

// File/network binary parsing (e.g., PNG header)
async function parsePngHeader(file) {
  const buf = await file.arrayBuffer();
  const view = new DataView(buf);
  const sig = [137, 80, 78, 71, 13, 10, 26, 10];
  return sig.every((byte, i) => view.getUint8(i) === byte);
}

// SharedArrayBuffer -- shared between main thread and workers
const shared = new SharedArrayBuffer(4 * 1024); // 4KB shared
const arr = new Int32Array(shared);
Atomics.add(arr, 0, 1); // thread-safe increment

WebAssembly WebAssembly (Wasm) is a binary instruction format that runs at near-native speed in the browser. JavaScript and Wasm can interoperate — JS calls Wasm functions and vice versa.

// Compile and instantiate a Wasm module
const response = await fetch("module.wasm");
const buffer   = await response.arrayBuffer();

const { instance } = await WebAssembly.instantiate(buffer, {
  // Import object -- functions Wasm can call in JS
  env: {
    memory: new WebAssembly.Memory({ initial: 1 }),  // 64KB page
    log: (value) => console.log("Wasm log:", value),
    now: () => performance.now()
  }
});

// Call Wasm exports
const { add, fibonacci, malloc, free } = instance.exports;
add(1, 2);              // 3 (fast native code)
fibonacci(40);          // very fast compared to JS

// Passing strings to Wasm (Wasm only understands numbers)
// Use the shared memory to pass byte arrays
const memory  = instance.exports.memory;
const encoder = new TextEncoder();

function callWasmWithString(fn, str) {
  const bytes   = encoder.encode(str);
  const ptr     = malloc(bytes.length + 1);
  const memView = new Uint8Array(memory.buffer, ptr, bytes.length + 1);
  memView.set(bytes);
  memView[bytes.length] = 0;  // null terminator
  const result = fn(ptr, bytes.length);
  free(ptr);
  return result;
}

// Compile C/C++/Rust → Wasm
// C via Emscripten: emcc hello.c -o hello.js -s WASM=1
// Rust via wasm-pack: wasm-pack build --target web
// AssemblyScript: TypeScript-like syntax that compiles to Wasm

// Use cases: image/video processing, audio codecs, physics engines,
// cryptography, scientific computing, game engines (Doom3, Unity)

// Wasm limitations: no direct DOM access, no GC (heap managed by Wasm)
// WasmGC proposal (shipping in Chrome 119): garbage-collected Wasm objects

TC39 Proposal The Temporal API (TC39 Stage 3, shipping in browsers 2024-2025) is a modern replacement for the notoriously broken Date object. It is immutable, has explicit timezone support, and separates calendar date, wall-clock time, and instants.

TC39 Proposal The TC39 Pattern Matching proposal (Stage 2) brings match expressions to JavaScript — similar to Rust’s match or Haskell’s case expressions — enabling powerful, exhaustive data-driven branching without long if/else chains or switch statements.

Performance

Security CSP is a browser security mechanism that restricts which resources can load and execute, mitigating XSS attacks.

V8 Internals V8 uses a generational garbage collector: the heap is split into the young generation (short-lived objects) and old generation (long-lived). This matches the generational hypothesis — most objects die young.

V8 Internals

Engine Proper Tail Call (PTC) optimisation — when the last operation in a function is a recursive call — allows the engine to reuse the current stack frame instead of creating a new one, preventing stack overflow in deep recursion.

Spec The ECMA-262 specification defines Abstract Operations — internal algorithms that implement JavaScript’s type coercion rules. Understanding them explains all the “weird” JS behaviour.

Browser APIs Service Workers are background scripts that run separately from the page. They act as a network proxy — intercepting requests and serving cached responses — enabling offline functionality and performance optimisation.

Architecture

TC39 Proposal

Performance

Browser APIs CSS Houdini exposes browser rendering engine hooks to JavaScript, allowing custom paint, layout, and animation behaviours that are composited off the main thread.

TC39 Proposal JavaScript decorators (TC39 Stage 3, shipping in V8 130+) allow annotating classes and class members with functions that can add behaviour, replace methods, or register them.

Web Standards Web Components are a suite of browser APIs for creating reusable custom HTML elements with encapsulated behaviour and styling — no framework required.

Browser APIs WebGPU (shipping in Chrome 113, Safari TP) is the modern GPU API for the web — direct access to GPU for both rendering and compute workloads. It is the successor to WebGL with a modern, low-level API matching Metal/Vulkan/DirectX 12.

Architecture