Frontend Developer interview prep

Short answer: Hoisting is moving declarations to the top of their scope at compile time. var is hoisted and initialized to undefined (function scope), while let/const are hoisted but stay in the TDZ (temporal dead zone) until the declaration line and have block scope.

In depth:

1. var — function scope, readable as undefined before declaration, re-declarable.
2. let — block scope, in the TDZ until declaration, reassignment allowed.
3. const — like let but no reassignment (the object's value itself is still mutable).
4. TDZ — accessing a let/const before declaration throws ReferenceError instead of returning undefined.

console.log(a); // undefined — var hoisted
var a = 1;

console.log(b); // ReferenceError — b in TDZ
let b = 2;

	Scope	Before declaration	Reassign
var	function	undefined	yes
let	block	TDZ → error	yes
const	block	TDZ → error	no

⚠️ Common mistake: believing let/const "aren't hoisted." They are — but accessing them before initialization throws because of the TDZ.

Short answer: TypeScript adds static type checking on top of JS: errors are caught in the editor and at build time instead of at runtime. Its typing is structural — compatibility is decided by an object's shape (its set of fields), not by the type's name or an explicit implements.

In depth:

1. What TS buys you — autocompletion and navigation, safe refactoring, self-documenting contracts, catching typos and undefined before running.
2. Structural vs nominal — in Java/C# types match by name (nominal typing). In TS, if an object has the required fields it fits, even if it was created with no knowledge of the target type.
3. Type erasure — types exist only at compile time; at runtime it is plain JS. You can't instanceof-check an interface.

interface Point { x: number; y: number }

function len(p: Point): number {
  return Math.hypot(p.x, p.y);
}

// the object never declared implements Point, but its shape fits
const v = { x: 3, y: 4, label: "v" };
len(v); // OK — structural typing: the extra label field is fine

⚠️ Common mistake: assuming TS protects you at runtime. Data from an API must be validated (zod, etc.) — the compiler takes your annotations on faith.

Short answer: JSX is syntactic sugar over element-creation calls. A compiler (Babel/SWC) turns it into jsx-runtime calls (or React.createElement in the classic transform) that return plain JS objects describing the UI — not real DOM nodes.

In depth:

1. It's an expression, not HTML — JSX compiles to JavaScript and can go anywhere an expression is allowed.
2. The new JSX transform (React 17+) — imports jsx/jsxs from react/jsx-runtime, so you no longer need import React just for JSX.
3. It returns an element object — shaped like { type, key, props }; real DOM appears only on render.
4. Case matters — a capitalized tag is a component, a lowercase one is a DOM element.

const el = <button className="btn" onClick={fn}>Save</button>;
// the new transform compiles this to:
import { jsx } from "react/jsx-runtime";
const el = jsx("button", { className: "btn", onClick: fn, children: "Save" });

⚠️ Common mistake: treating JSX as a string or HTML. It's JS: you write className, not class, and attributes are camelCase (onClick, tabIndex).

Short answer: The Critical Rendering Path is the browser's sequence from receiving HTML to the first painted pixel: DOM + CSSOM → render tree → layout → paint → composite. Synchronous CSS and blocking JS delay this path.

In depth:

1. DOM — the browser parses HTML into a tree of nodes.
2. CSSOM — the style object model is built in parallel; CSS blocks rendering because styles can't be computed without it.
3. Render tree — DOM and CSSOM merge; display: none nodes are dropped.
4. Layout (reflow) — element geometry and positions are computed.
5. Paint — nodes are rasterized into pixel layers.
6. Composite — layers are assembled on screen (often on the GPU).

HTML ─► DOM ─┐
             ├─► Render Tree ─► Layout ─► Paint ─► Composite ─► screen
CSS  ─► CSSOM┘
  ▲ blocks rendering        ▲ <script> without defer/async

⚠️ Common mistake: assuming JS never interferes with rendering. A synchronous <script> in the <head> halts HTML parsing and DOM construction — use defer or move scripts to the bottom.

Short answer: Accessibility (a11y) means designing products so people with visual, hearing, motor, and cognitive disabilities can use them. It matters for three reasons: ethical (people), business (wider audience), and legal (WCAG, ADA, the European Accessibility Act).

In depth:

1. People — about 15% of the population lives with some disability; temporary (a broken arm) and situational (bright sun, a noisy train) limitations affect everyone.
2. Business — more users, better SEO (semantics = clear structure), fewer drop-offs.
3. Law — WCAG 2.x is the de-facto standard; the US has ADA/Section 508, the EU has the EAA; lawsuits over inaccessible sites are real.

Disability	Barrier	Solution
Vision	can't see the screen	screen reader, contrast, alt
Hearing	can't hear audio	captions, transcripts
Motor	can't use a mouse	keyboard accessibility
Cognitive	complex UI	plain language, clear structure

⚠️ Common mistake: treating accessibility as a 'feature for a minority' — in reality it improves UX for everyone (the curb-cut effect).