JavaScript & TypeScript interview questions and answers

Question 1

What is the difference between == and === in JavaScript?

Accepted Answer

Answer: === checks value and type, with no conversion. == converts the two sides to the same type first, then compares. So 1 === "1" is false (number vs string), but 1 == "1" is true (the string is converted to a number). The == rules are full of surprises (null == undefined is true, "" == 0 is true, [] == false is true). Almost everyone uses === everywhere and only uses == for one thing: x == null, which is a neat check for 'null or undefined'. Analogy: === is a strict bouncer: your ID must match exactly. == is a lenient one who will 'interpret' your ID until it matches, which leads to some very odd guests getting in. In an interview: === compares value and type with no conversion. == converts types first and has many surprising cases. Use === everywhere; the only common == is x == null to catch both null and undefined.

Question 2

What is the difference between var, let, and const?

Accepted Answer

Answer: var: function-scoped, hoisted (usable before its line, as undefined), can be redeclared. Legacy, avoid it. let: block-scoped (only visible inside the { } it is declared in), not usable before its line, can be reassigned. const: block-scoped like let, but cannot be reassigned. Note: for an object or array, const stops you swapping the whole value, but you can still change its contents. Modern practice: use const by default, let when you need to reassign, never var. Analogy: var is a note stuck anywhere in the whole room. let and const are notes that only exist inside the box you wrote them in. const means you cannot swap the note for a new one, but if the note points at a whiteboard you can still edit the whiteboard. In an interview: var is function-scoped and hoisted, avoid it. let and const are block-scoped. const cannot be reassigned but its contents can still change. Default to const, use let when you must reassign.

Question 3

What are the primitive types, and what is the difference between null and undefined?

Accepted Answer

Answer: JavaScript has 7 primitives: string, number, boolean, null, undefined, symbol, and bigint. Everything else (objects, arrays, functions) is an object. undefined means 'no value has been assigned'. It is what you get from an unset variable, a missing object property, or a function with no return. null means 'intentionally empty'. You assign it yourself to say 'this is deliberately nothing'. A quirk: typeof null is "object" (an old bug that can never be fixed), while typeof undefined is "undefined". Analogy: undefined is a form field nobody has filled in yet. null is a field someone deliberately crossed out. In an interview: 7 primitives: string, number, boolean, null, undefined, symbol, bigint. undefined is 'not assigned yet', null is 'deliberately empty'. typeof null is the well-known bug that returns 'object'.

Question 4

What does "use strict" do?

Accepted Answer

Answer: Putting "use strict"; at the top of a file or function turns on strict mode, which makes JavaScript throw errors for things it used to silently ignore, and disables some unsafe features. It stops you creating a global variable by forgetting var/let, makes assignments to read-only properties throw instead of failing quietly, forbids duplicate parameter names, and makes 'this' inside a plain function call be undefined instead of the global object. You rarely write it now: ES modules and class bodies are always in strict mode automatically. Analogy: switching your editor from 'ignore all warnings' to 'treat warnings as errors'. It catches sloppy code early instead of letting it bite you later. In an interview: Strict mode makes silent mistakes throw: accidental globals, writes to read-only properties, duplicate parameters, and 'this' being the global object in plain function calls. Modules and classes are always strict, so you seldom type it now.

Question 5

What is type coercion, and what are the falsy values?

Accepted Answer

Answer: Coercion is JavaScript automatically converting a value from one type to another, for example when you use + with a string and a number, or put a non-boolean in an if. The falsy values, the ones that act like false in a condition, are exactly: false, 0, -0, 0n, "" (empty string), null, undefined, and NaN. Everything else is truthy, including "0", "false", [], and {}. The classic gotcha: "" + 1 is "1" (number becomes string), but "" - 1 is -1 (string becomes number), because + means concatenation with strings while - is always numeric. Analogy: JavaScript really wants your code to run, so it guesses what conversion you meant. Knowing the falsy list and the +/- rule covers most of the surprises. In an interview: Coercion is automatic type conversion. The falsy values are false, 0, -0, 0n, empty string, null, undefined, NaN; everything else is truthy. + concatenates when a string is involved, - always converts to numbers.

Question 6

What is a closure?

Accepted Answer

Answer: A closure is a function that remembers the variables from the scope where it was created, even after that outer function has finished running. When you return a function from another function, the returned function keeps a live link to the outer function's variables. Each call to the outer function creates a fresh set. Closures are how you get private state in JavaScript (a counter nobody can reach except through the functions you return), and they are why callbacks can use variables from where they were defined. Analogy: a backpack. When a function is created, it packs the variables it can see into a backpack and carries them everywhere, even after it leaves the room where they were made. In an interview: A closure is a function bundled with the variables from where it was defined, still accessible after the outer function returns. It gives private state and lets callbacks use their defining scope.

Question 7

What is hoisting?

Accepted Answer

Answer: Before running your code, JavaScript 'moves' declarations to the top of their scope. Function declarations are fully hoisted, so you can call them before they appear in the file. var declarations are hoisted but not their value, so the variable exists as undefined until the assignment line runs. let and const are hoisted too, but you cannot use them before their line. That gap is called the 'temporal dead zone' and using them there throws a ReferenceError. Practical takeaway: declare things before you use them, and hoisting stops mattering. Analogy: JavaScript reads the whole script once to note down every name that will exist, then runs it top to bottom. var names are noted but empty; let/const names are noted but locked until their line. In an interview: Declarations are processed before execution. Function declarations are callable early; var is undefined until assigned; let and const exist but throw if used before their line (the temporal dead zone). Declare before use and it is a non-issue.

Question 8

What is the difference between a regular function and an arrow function?

Accepted Answer

Answer: The big one is 'this'. A regular function gets its own 'this' depending on how it is called. An arrow function has no own 'this'; it uses the 'this' from where it was defined. This makes arrow functions ideal for callbacks inside a method, where you want to keep the outer 'this'. Other differences: arrow functions have no 'arguments' object (use rest parameters), cannot be used as constructors (no 'new'), and have no 'prototype'. They are also shorter to write and implicitly return a single expression. Analogy: a regular function is a chameleon: its 'this' changes with its surroundings (the call). An arrow function is loyal: its 'this' is fixed to wherever it was born. In an interview: An arrow function has no own 'this', 'arguments', or 'prototype' and cannot be a constructor. It captures 'this' from where it was defined, which is why it is the right choice for callbacks inside methods.

Question 9

What is the difference between a function declaration and a function expression?

Accepted Answer

Answer: A declaration is function foo() {} written as a statement. It is fully hoisted, so you can call it above where it is written. An expression is a function assigned to something: const foo = function () {} or const foo = () => {}. Only the variable is hoisted (as undefined for var, or in the dead zone for let/const), so calling it before its line fails. Expressions can be anonymous, passed straight as arguments, and returned from other functions. Most modern code uses expressions (usually arrow functions) except for top-level named helpers. Analogy: a declaration is a name announced to the whole room in advance. An expression is a function handed to one person; nobody else knows about it until that moment. In an interview: A declaration (function foo(){}) is fully hoisted and callable earlier. An expression (const foo = ...) hoists only the variable, so it must be defined before use. Expressions can be anonymous and passed around.

Question 10

A variable captured by a closure keeps returning an outdated value. Why does this happen?

Accepted Answer

Answer: This is a stale closure. A function captures the variables from where it was defined, at the moment it was defined. If you create the function once but the variable it closed over gets a new value later (for example on a re-render, or in a new loop iteration), the old function is still looking at the OLD binding. Classic case: an event handler or a setInterval callback created once, that reads a variable which has changed since. It still sees the value from when it was created. Fixes: recreate the function when the value changes (in React, add the value to the dependency array), read the latest value from a ref or a variable outside the closure, or use the updater form (setCount(c => c + 1)) so you do not depend on the captured value at all. This is different from a closure holding memory unnecessarily. That is a memory leak (a closure keeps a big object alive). A stale closure is a correctness bug about which version of a value you see. Analogy: the closure took a photo of the variable when it was born. Later the real variable changes, but the closure keeps showing its old photo. In an interview: A stale closure captures a variable's value at creation time and never sees later updates, common with callbacks created once. Fix by recreating the function when the value changes, reading from a ref, or using the updater form so you do not rely on the captured value. It is a correctness bug, not the memory-leak sense of a closure holding data.

Question 11

How does 'this' work in JavaScript?

Accepted Answer

Answer: In a regular function, 'this' is decided by how the function is called, not where it is defined: - Called as obj.method(): 'this' is obj. - Called as a plain function foo(): 'this' is undefined in strict mode (the global object otherwise). - Called with new Foo(): 'this' is the new object. - Called with foo.call(x) / foo.apply(x) / foo.bind(x): 'this' is x. Arrow functions ignore all of that and take 'this' from the surrounding scope. The usual bug: passing obj.method as a callback loses the obj binding. Fix with an arrow wrapper or .bind(obj). Analogy: 'this' is 'who is speaking right now', and it is set at the moment of the call, like answering 'who is calling?' by looking at the phone, not at the phone book. In an interview: In a regular function 'this' depends on the call site: the object before the dot, undefined for a plain call, the new instance with 'new', or whatever call/apply/bind set. Arrow functions inherit 'this' from their surroundings.

Question 12

What is prototypal inheritance?

Accepted Answer

Answer: Every JavaScript object has a hidden link to another object called its prototype. When you read a property that the object does not have, JavaScript follows that link to the prototype, then the prototype's prototype, and so on. This chain is how objects share behaviour. When you write a class, its methods are stored on the prototype, and every instance links to it. So all instances share one copy of each method rather than each having their own. This is different from Java-style class inheritance: there are no classes underneath, just objects linked to objects. 'class' is syntax sugar over this. Analogy: a chain of fallback dictionaries. If your dictionary does not have a word, you check the one it points to, then the next, until you find it or run out. In an interview: Objects link to a prototype object, and property lookups walk that chain until found. Class methods live on the prototype so instances share them. 'class' is sugar over object-to-object linking, not real classes.

Question 13

What is the difference between a shallow copy and a deep copy of an object?

Accepted Answer

Answer: A shallow copy copies the top-level properties. If a property is itself an object or array, the copy and the original share that same nested object. Changing the nested object through one affects the other. { ...obj } and Object.assign do shallow copies. A deep copy duplicates everything, all the way down, so the two are fully independent. structuredClone(obj) does this in modern environments. The old trick JSON.parse(JSON.stringify(obj)) works but loses functions, dates, undefined, and cannot handle cycles. Analogy: a shallow copy of a folder photocopies the cover sheet but staples the same attachments to both copies. A deep copy photocopies the attachments too. In an interview: Shallow copy duplicates the top level but shares nested objects (spread, Object.assign). Deep copy duplicates everything (structuredClone). JSON round-tripping is the old deep-copy hack but drops functions, dates, and cycles.

Question 14

What is the difference between a Map and a plain object?

Accepted Answer

Answer: Use a Map when the keys are dynamic data; use a plain object for fixed, known structure. Map: keys can be any type (objects, functions, numbers), remembers insertion order, has a .size, and is iterable directly. It has no prototype keys to clash with, and it is faster for frequent adds and deletes. Plain object: keys are strings or symbols only, has an inherited prototype (so 'toString' etc. are 'present'), and you check size with Object.keys(o).length. It has the nicest syntax (o.name) and works with JSON directly. Analogy: a plain object is a form with fixed labelled fields. A Map is a dynamic lookup table where the labels themselves are data you add and remove at runtime. In an interview: Map for dynamic keys of any type: ordered, has .size, directly iterable, no prototype clashes, faster for churn. Plain object for fixed known shape, string keys, nice dot syntax, and JSON support.

Question 15

What is the event loop, and why is JavaScript single-threaded but not blocking?

Accepted Answer

Answer: JavaScript runs your code on one thread, so only one piece of code runs at a time. It does not block on slow things (a network call, a timer, reading a file) because it hands those off to the environment (the browser or Node), which does them in the background. When a background task finishes, its callback is put in a queue. The event loop is a simple loop: when the current code finishes and the call stack is empty, it takes the next callback from the queue and runs it. So the single thread is never stuck waiting. It just keeps picking up finished work. The catch: if your own code runs a long loop, nothing else can happen until it ends. Analogy: one chef (the thread) in a kitchen. Instead of standing at the oven waiting, the chef sets a timer and moves on. When a timer dings, the chef finishes that dish next. One chef, but never idle. In an interview: One thread runs the code; slow operations are offloaded to the environment, which queues their callbacks. The event loop runs queued callbacks whenever the stack is empty, so the thread never waits, unless your own code hogs it with a long synchronous task.

Question 16

What is a Promise, and how do async/await relate to it?

Accepted Answer

Answer: A Promise is an object representing a value that is not ready yet. It is in one of three states: pending, fulfilled (succeeded, with a value), or rejected (failed, with an error). You attach .then() for success and .catch() for failure. async/await is nicer syntax for the same thing. An async function always returns a Promise. Inside it, await pauses the function until a Promise settles, then gives you the value (or throws the error, which you catch with try/catch). The code reads top to bottom like synchronous code, but it does not block the thread. Analogy: a Promise is a collection ticket for a coffee order: you get the ticket now, the coffee later. await is standing at the counter until your number is called, without holding up the whole shop. In an interview: A Promise is a placeholder for a future value, in a pending, fulfilled, or rejected state, handled with then/catch. async/await is sugar over it: an async function returns a Promise, await unwraps one and reads like synchronous code without blocking.

Question 17

What is the difference between synchronous and asynchronous code, and why does async matter?

Accepted Answer

Answer: Synchronous code runs line by line, and each line finishes before the next starts. If a line is slow, everything after it waits. Asynchronous code starts a slow operation and moves on; the result is handled later by a callback, Promise, or await. It matters because JavaScript has one thread. In the browser, a slow synchronous call would freeze the whole page (no clicks, no scrolling). In Node, it would stop the server from handling any other request. Async lets the one thread stay responsive by working on other things while slow I/O happens in the background. Analogy: synchronous is a single checkout where everyone waits behind the person with 50 items. Asynchronous is the cashier starting your card payment, then serving the next person while it processes. In an interview: Synchronous code blocks the single thread until each step finishes; asynchronous code offloads slow work and continues. Async keeps the UI responsive in the browser and lets a Node server handle many requests on one thread.

Question 18

What is the difference between the microtask queue and the macrotask queue?

Accepted Answer

Answer: There are two queues of pending callbacks, and the event loop treats them differently. Microtasks: Promise callbacks (.then, await continuations) and queueMicrotask. After each piece of code finishes, the event loop drains the ENTIRE microtask queue before doing anything else. Macrotasks: setTimeout, setInterval, I/O callbacks, UI events. The event loop runs just ONE of these, then again drains all microtasks, then (in the browser) may render, then takes the next macrotask. This is why a Promise callback always runs before a setTimeout(fn, 0) scheduled at the same time. Analogy: microtasks are 'finish everything on your immediate to-do list before leaving the desk'. Macrotasks are 'then take one item from the inbox, and repeat'. In an interview: Microtasks (Promise callbacks) are fully drained after every task. Macrotasks (timers, I/O) are taken one at a time, with a full microtask drain between each. So a resolved Promise beats setTimeout(fn, 0).

Question 19

Predict the output: console.log("Start"); then Promise.all of three resolved promises where the third resolves inside setTimeout(..., 0); then .then logs the result; then console.log("End").

Accepted Answer

Answer: Start, End, ["A", "B", "C"]. Why in that order: 1. console.log("Start") runs immediately (synchronous). 2. Promise.all is set up. Two of its promises are already resolved, but the third only resolves after a setTimeout(0), which is a macrotask scheduled for later. 3. console.log("End") runs, because it is still synchronous code. 4. The synchronous code is done. The event loop now runs the setTimeout callback, which resolves the third promise. 5. Promise.all now has all three values, so its .then microtask runs and logs the array in the original order ["A", "B", "C"] (Promise.all keeps input order, not finish order). Analogy: synchronous lines first, then anything waiting on a timer runs after them, and only once every promise in Promise.all has settled does its .then fire. In an interview: Start and End print first as synchronous code. The third promise waits on a setTimeout macrotask, so Promise.all cannot resolve until that fires. Then its .then logs the array, and Promise.all preserves input order, not resolve order.

Question 20

Promises are asynchronous, so how can a long chain of already-resolved promises still freeze the UI?

Accepted Answer

Answer: Because promise callbacks run on the same single thread as everything else, and the browser can only paint the screen when that thread is free. A resolved promise's .then callback is a microtask. After the current task, the event loop drains the ENTIRE microtask queue before it does anything else, including rendering. If you chain hundreds of .then steps, or do heavy work inside them, the thread is busy running microtasks back to back, so the browser never gets a gap to repaint. The page appears frozen even though nothing is 'waiting'. The fix for genuinely heavy work: break it into chunks and yield to the event loop between chunks (setTimeout(fn, 0), or await a macrotask, or a Web Worker for CPU work). Analogy: async does not mean 'on another thread'. It means 'later, on the same thread'. If 'later' is a thousand tasks with no breaks, the one thread is still stuck and the screen cannot update. In an interview: Promise callbacks are microtasks on the one main thread, and the browser only paints when that thread is idle. A huge microtask chain keeps the thread busy, so no repaint happens. Chunk the work and yield with setTimeout, or move CPU work to a Web Worker.

Question 21

An error thrown inside an asynchronous callback escapes the surrounding try/catch. Why, and where should the error be handled?

Accepted Answer

Answer: A try/catch only catches errors that happen while the code inside it is running. An async callback (a setTimeout callback, a .then callback, an event handler) runs LATER, after the try block has already finished and been popped off the stack. By then there is no try/catch around it, so the error propagates as an unhandled error. Where to handle it: - Promises: use .catch() on the chain, or wrap the await in try/catch inside an async function (await makes the error land back in that function's try/catch). - setTimeout / event listeners: put the try/catch INSIDE the callback. - Last resort: window.addEventListener('error') and 'unhandledrejection' for logging. Analogy: the try/catch is a net you hold up for a moment. The async callback jumps later, after you have already put the net away. In an interview: try/catch only wraps code running right now. The async callback runs after the try block has unwound, so it is not covered. Handle it with .catch on the promise, try/catch around the await inside an async function, or a try/catch inside the callback itself.

Question 22

A request for an older search query finishes after the newer one and overwrites the UI. How do you prevent this race condition?

Accepted Answer

Answer: The problem is that responses can come back out of order. You type "ab", then "abc"; the "ab" request is slower and its response arrives last, so it overwrites the "abc" results. Fixes, best first: 1. AbortController: cancel the previous request before starting a new one. The aborted one never resolves. 2. Sequence check: give each request an increasing id, and when a response comes back, ignore it unless it is the latest id you sent. 3. Debounce the input so you fire fewer requests in the first place (helps, but does not fully fix ordering). In React this is also why effects return a cleanup function that sets an 'ignore this response' flag. Analogy: you send two letters, the second correcting the first. If the post office delivers them out of order, the reader ends up with the wrong version. You need a way to say 'ignore anything older than my latest message'. In an interview: It is an out-of-order response race. Cancel the previous request with an AbortController, or tag each request with an increasing id and only apply the response if it matches the latest id. Debouncing reduces how often it happens but does not fix ordering.

Question 23

What is the DOM?

Accepted Answer

Answer: The DOM (Document Object Model) is the browser's live, in-memory representation of the page as a tree of objects. Each HTML element, attribute, and piece of text is a node, and JavaScript can read and change any of them. When you call document.querySelector or element.textContent = "hi", you are reading and writing the DOM, and the browser re-renders to match. The DOM is not the HTML source. It is built from the HTML at load, then changes as scripts and user actions modify it. 'View source' shows the original HTML; the DevTools element inspector shows the current DOM. Analogy: the HTML file is the blueprint. The DOM is the actual building the browser constructed from it, which you can then renovate room by room with JavaScript. In an interview: The DOM is the browser's tree of objects representing the current page. JavaScript reads and mutates nodes through it, and the browser re-renders. It is built from the HTML but then diverges as scripts change it.

Question 24

What is event bubbling, and what is event delegation?

Accepted Answer

Answer: When you click an element, the event fires on that element, then 'bubbles' up to its parent, then that parent's parent, all the way to the document. A click listener on a container therefore also hears clicks on anything inside it. Event delegation uses this on purpose: instead of adding a listener to every button in a list, you add one listener to the list container and check event.target to see which button was actually clicked. Benefits: one listener instead of hundreds, and it automatically covers elements added later. You can stop bubbling with event.stopPropagation(). Analogy: a complaint made at a shop counter travels up: to the supervisor, the manager, head office. Delegation is head office putting one person on the desk to handle every complaint, instead of one per counter. In an interview: Events bubble from the target up through its ancestors, so a parent hears descendant events. Delegation puts one listener on a container and inspects event.target, saving many listeners and automatically handling dynamically added elements.

Question 25

How do you keep state in sync across multiple browser tabs of the same site?

Accepted Answer

Answer: Tabs of the same site are separate JavaScript environments, so a variable in one tab is not shared. To sync them you need a channel between tabs. Options: 1. The storage event: when one tab writes to localStorage, every OTHER tab fires a 'storage' event with the key and new value. Simple and widely supported. The writing tab does not get its own event. 2. BroadcastChannel: a dedicated pub/sub channel between tabs of the same origin. postMessage in one tab, onmessage in the others. Cleaner for real messages, not persisted. 3. A SharedWorker: one worker shared by all tabs, holding the state centrally. Common use: log the user out of every tab at once, or keep a cart or theme in sync. Analogy: each tab is a separate room. localStorage is a shared noticeboard they can all read, and the storage event is a bell that rings in the other rooms when someone pins a new note. In an interview: Tabs do not share memory, so you need a cross-tab channel. The 'storage' event fires in other tabs when localStorage changes, BroadcastChannel is a direct pub/sub between same-origin tabs, and a SharedWorker can hold central state. Typical use is logout-everywhere or syncing theme and cart.

Question 26

A page feels slow even though its API responses are fast. How do you find whether JavaScript execution, layout, paint, or compositing is to blame?

Accepted Answer

Answer: Open the browser DevTools Performance panel, record while you reproduce the slowness, and read the flame chart. The browser does work in stages, and the panel colours them: - Scripting (yellow): your JavaScript running. A long yellow block means a heavy function or too much work on the main thread. - Rendering / Layout (purple): the browser recalculating positions and sizes ('reflow'). Triggered by DOM or style changes, and made worse by reading a layout property right after writing one ('layout thrashing'). - Painting (green): filling in pixels for changed areas. - Compositing: assembling layers on the GPU. Usually cheap; transform and opacity animations stay here. Long yellow means fix the JavaScript. Long purple means reduce layout work or batch DOM reads and writes. Frequent green over a large area means you are repainting too much. Analogy: the browser is a small factory: read the recipe (script), measure and cut (layout), paint (paint), glue the panels together (composite). The Performance panel shows which station the line is stuck at. In an interview: Record in the DevTools Performance panel and read the colours: yellow is your JavaScript, purple is layout/reflow, green is paint, and compositing is the GPU step. Long yellow means optimise the script, long purple means batch DOM reads and writes and reduce style changes, and animating transform or opacity keeps work off layout and paint.

Question 27

How do you find and fix a memory leak in a browser application?

Accepted Answer

Answer: A leak is memory that is no longer needed but still reachable, so the garbage collector cannot free it. Over time the tab uses more and more memory and gets sluggish. Common causes in the browser and in React: - Event listeners, intervals, or subscriptions added but never removed (especially in components that mount and unmount). - Timers (setInterval) that keep running after the component is gone. - Closures or a growing array/Map holding references to large objects or detached DOM nodes. - Caches with no size limit. How to find it: in DevTools Memory panel, take a heap snapshot, do the action that leaks a few times, take another snapshot, and compare. Growing 'Detached HTMLElement' or a growing object count points at what is not being released. Fix: always pair 'add' with 'remove' (in React, return a cleanup function from useEffect), clear timers, unsubscribe, and bound your caches. Analogy: a leak is like a room where people keep leaving but their coats stay on the hooks. The cleaner cannot throw a coat away while a hook still holds it. In an interview: A leak is unneeded memory that is still reachable. The usual causes are listeners, timers, and subscriptions that are never removed, and unbounded caches. Find it by comparing heap snapshots in the DevTools Memory panel and watching for growing detached DOM nodes. Fix it by pairing every add with a remove, which in React means a cleanup function from useEffect.

Question 28

Memoization was added to improve performance, but the application became slower and used more memory. How is that possible?

Accepted Answer

Answer: Memoization (caching a computed result, or React's useMemo / useCallback / React.memo) is not free. It costs: - Memory to store every cached result. An unbounded cache keyed by arguments grows forever. - Time on every call to build the cache key and check the cache. - In React, useMemo and useCallback still run their dependency comparison on every render, and React.memo still shallow-compares all props. If the computation was cheap to begin with, or the inputs change every time (so the cache never hits), or a dependency like an inline object or function is a new reference on every render (so the memo is invalidated every time), you pay all the cost and get none of the benefit. You have added work and memory for nothing. Rule: only memoize a computation that is genuinely expensive and whose inputs are stable, and measure before and after. Analogy: keeping a filing cabinet of past answers only helps if you actually get asked the same questions again and the answers were slow to work out. Otherwise it is just a cabinet taking up space that you still have to search every time. In an interview: Memoization costs memory for the cache and time to build and check keys, and in React it adds comparison work every render. If the computation was cheap, the inputs change every time, or a dependency is a fresh reference each render, you pay the cost and never hit the cache. Only memoize expensive work with stable inputs, and measure.

Question 29

What are lazy loading and code splitting, and how do you do them?

Accepted Answer

Answer: Code splitting means breaking your JavaScript bundle into smaller pieces so the browser only downloads what a page needs, instead of one huge file up front. Lazy loading means fetching one of those pieces only when it is actually needed, for example when the user navigates to a route or opens a modal. How: use a dynamic import(), which the bundler turns into a separate chunk loaded on demand. In React, wrap a lazily imported component in React.lazy and Suspense. Route-based splitting (one chunk per route) is the highest-value place to start. You can also lazy-load images with loading="lazy" and heavy libraries only when a feature is used. Analogy: instead of shipping the customer the entire warehouse, you ship the one box they asked for, and the rest only when they order it. In an interview: Code splitting breaks the bundle into chunks; lazy loading fetches a chunk only when needed. The mechanism is a dynamic import(), which the bundler splits automatically, plus React.lazy and Suspense in React. Splitting per route is the best starting point.

Question 30

What is TypeScript, and what does it add over plain JavaScript?

Accepted Answer

Answer: TypeScript is JavaScript with a static type system bolted on. You write JavaScript plus type annotations, and the TypeScript compiler checks them and then strips them out, producing plain JavaScript that runs anywhere JS runs. What it adds: errors caught at compile time instead of at run time (calling a method that does not exist, passing the wrong argument, a possibly-undefined value), much better editor support (autocomplete, safe rename, go-to-definition), and types that act as always-correct documentation. The cost: a build step, time spent writing and maintaining types, and the types are erased at run time, so they do not validate data coming from an API. It is now the default for most serious JavaScript projects. Analogy: TypeScript is a spell-checker and grammar-checker for your code that runs before you ship. It does not change what the code does, it catches mistakes first. In an interview: TypeScript adds a static type system to JavaScript, checked at compile time then erased. It catches type errors before running, gives strong editor tooling, and documents the code. It costs a build step and type maintenance, and it does not validate runtime data.

Question 31

What is the difference between type and interface in TypeScript?

Accepted Answer

Answer: Both name a shape. For an object shape they are almost interchangeable, and the team should pick one and be consistent. interface: can be extended with extends, and can be 'reopened', declared again to add members (declaration merging), which libraries use to let you augment their types. Only describes object-like shapes. type: an alias for ANY type, not just objects, so it can name a union ("a" | "b"), a tuple, a function signature, a primitive, or a mapped/conditional type. Cannot be reopened. Rule of thumb: use interface for public object shapes and things meant to be extended, use type for unions, tuples, function types, and anything not object-shaped. Analogy: interface is a form template you can add fields to later. type is a label you can stick on absolutely anything, including 'one of these three values'. In an interview: Both describe shapes and are interchangeable for objects. interface supports extends and declaration merging and is object-only. type can alias anything, including unions, tuples, and function types, but cannot be reopened. Use interface for extendable object shapes, type for everything else.

Question 32

What is the difference between any, unknown, and never?

Accepted Answer

Answer: any: turns type checking OFF for that value. You can do anything with it and the compiler will not complain. It spreads: everything touched by an any becomes unchecked. Avoid it. unknown: the safe version of any. It can hold any value, but you cannot USE it until you narrow it (with typeof, instanceof, or a check). Great for values from JSON.parse or an API, where you genuinely do not know the type yet and want to be forced to check. never: the type of a value that can never exist. It is what a function that always throws or never returns is typed as, and what a variable's type becomes when you have narrowed away every possibility. Used to make switch statements exhaustive (a default branch typed never fails to compile if you miss a case). Analogy: any is 'I promise it's fine, stop checking'. unknown is 'I don't know yet, make me check'. never is 'this literally cannot happen'. In an interview: any disables type checking and spreads, so avoid it. unknown holds anything but forces you to narrow before use, which is right for JSON and API data. never is the type of the impossible, used for functions that always throw and for exhaustive switch checks.

Question 33

What is structural typing in TypeScript?

Accepted Answer

Answer: TypeScript checks types by their shape, not by their name. If an object has all the properties a type requires, it IS that type, even if it was never declared as one. This is also called duck typing: 'if it walks like a duck and quacks like a duck, it is a duck'. Contrast with nominal typing (Java, C#), where a value is only a Person if it was explicitly created as a Person. Consequence: a function that wants { name: string } accepts any object with a string name property. Extra properties are usually allowed too (except in object literals passed directly, which get an 'excess property' check). Analogy: TypeScript does not ask for your ID card, it checks whether you can do the job. If you have the right shape, you are accepted. In an interview: TypeScript is structurally typed: a value matches a type if it has the right shape, regardless of how it was declared. This is duck typing, unlike Java's nominal typing. So any object with the required properties is accepted, with an extra check on direct object literals.

Question 34

What are generics in TypeScript?

Accepted Answer

Answer: Generics let a function, class, or type work with a type that is filled in by the caller, while keeping the connection between inputs and outputs. Without generics you would either lock a function to one type, or use any and lose all safety. With a type parameter , the function stays fully typed for whatever the caller passes. Example: identity(x: T): T returns exactly the type it received. Array, Promise, and Map are generics. You can constrain a type parameter with extends () to require certain properties. Analogy: a generic is a labelled box with a blank on the label. You write in what it holds when you use it, and the box remembers, so 'take one out' gives back the right type. In an interview: Generics are type parameters that the caller fills in, keeping the link between input and output types instead of falling back to any. Array, Promise, and Map are generic. You constrain a parameter with 'extends' to require certain properties.

Question 35

What is type narrowing in TypeScript?

Accepted Answer

Answer: Narrowing is TypeScript working out a more specific type inside a block, based on a check you wrote. If a value is string | number and you write if (typeof x === "string"), then inside that if TypeScript knows x is a string and lets you call string methods. Ways to narrow: - typeof for primitives. - instanceof for classes. - an 'in' check for a property (if ("wheels" in vehicle)). - comparing against a literal (if (status === "error")). - a truthiness check removes null and undefined. - a user-defined type guard: a function returning value is Fish. This is what makes union types practical: you take a broad type and let the checks tell the compiler which case you are in. Analogy: you start with 'it is one of these types'. Each check you write crosses possibilities off the list, and TypeScript keeps track of what is left. In an interview: Narrowing is TypeScript inferring a more specific type inside a block from a check like typeof, instanceof, an 'in' test, a literal comparison, or a custom type guard. It is what makes union types usable: the checks tell the compiler which case you are handling.

JavaScript & TypeScript interview preparation

Language basics

Functions and scope

Objects and this

Asynchronous JavaScript

The browser

Performance

TypeScript