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: Cookies are small (about 4 KB each), and the browser sends them automatically with matching HTTP requests; the server can make a cookie HttpOnly (invisible to JS), Secure, and SameSite and set its lifetime — which is why they're used for sessions. localStorage is about 5 MB per origin, lives until cleared, is shared by all tabs of the origin, and has a synchronous strings-only API. sessionStorage is the same but per tab: it survives a reload and disappears when the tab closes. IndexedDB is an asynchronous database for large structured data (objects, Blobs), available in workers too.

In depth:

	Cookie	localStorage	sessionStorage	IndexedDB
Lifetime	Expires/Max-Age or session	until cleared	until the tab closes	until cleared
Size	~4 KB per cookie	~5 MB	~5 MB	quota-based, large
Sent to server	yes, automatically	no	no	no
Scope	domain + path	origin, all tabs	origin, one tab	origin
API	headers / document.cookie	synchronous, strings	synchronous, strings	asynchronous, objects

1. Tokens — any XSS script can read localStorage; a session is safer in an HttpOnly; Secure; SameSite cookie.
2. Syncing tabs — the storage event fires in other tabs of the same origin.
3. Not a guarantee — the browser may evict data under storage pressure, and Safari deletes a site's script-written storage after 7 days without user interaction.

localStorage.setItem("prefs", JSON.stringify({ theme: "dark" })); // strings only
const prefs = JSON.parse(localStorage.getItem("prefs") ?? "{}");

sessionStorage.setItem("wizardStep", "2");  // this tab, survives a reload

window.addEventListener("storage", (e) => { // fires in OTHER tabs
  if (e.key === "prefs") applyPrefs(e.newValue);
});
// The session cookie is set by the server and invisible to JS:
// Set-Cookie: sid=…; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

⚠️ Common mistake: storing an object directly: localStorage.setItem("u", { a: 1 }) saves the string "[object Object]". Serialize with JSON.stringify.

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