JavaScriptinterview questions & answers

Think of variables as labelled boxes where you store things. But there are three kinds of boxes with different rules: one you can empty and refill AND replace, one you can only refill, and one that is sealed forever once packed.

In JavaScript those three boxes are var, let, and const.

• var — the old box. It is function-scoped (it leaks out of { } blocks like if/for), can be re-declared and reassigned, and is hoisted — created early and pre-filled with undefined.
• let — the modern refillable box. It is block-scoped (lives only inside the nearest { }), can be reassigned but not re-declared in the same scope.
• const — the sealed box. Block-scoped, and its binding cannot be reassigned. You must give it a value at declaration.

Scope = where a variable is visible. Global scope = everywhere. Function scope = only inside that function. Block scope = only inside the { } (works for let/const, NOT var).

🌍 Real-world example: A for loop with let i gives each iteration its OWN i, so 3 click-handlers remember 0, 1, 2. With var i all three share ONE i and log the final value (3) — the classic interview bug.

💡 Hoisting = JavaScript moves declarations to the top of their scope before running the code.

💡 Temporal Dead Zone (TDZ) = the gap from the start of the block until a let/const is declared. let/const ARE hoisted but stay uninitialised in this zone — touching them throws a ReferenceError. (var gives undefined instead, no error.)

💡 The const gotcha = const locks the BINDING, not the value. A const object or array is still mutable — you can change its properties or push to it; you just can't point the name at a whole new object.

Rules cheat-sheet: var → re-declare ✔ reassign ✔. let → re-declare ✘ reassign ✔. const → re-declare ✘ reassign ✘ (but object contents mutable ✔).

Standard definition: In JavaScript, var is function-scoped and hoisted as undefined, while let and const are block-scoped and hoisted into the Temporal Dead Zone; const additionally prevents reassignment of the binding but not mutation of the referenced object.

if (true) {
  var a = 1;
  let b = 2;
}
console.log(a); // 1  (var leaked out)
// console.log(b); // ReferenceError: b is not defined

const user = { name: 'Aisha' };
user.name = 'Bilal';   // allowed: object is mutable
console.log(user.name);
// user = {};           // TypeError: Assignment to constant variable.

Think of a printed page in a book versus a library card. If I photocopy a page and hand it to you, you scribble on your copy and my page stays clean — two separate things. But if I hand you a library card that points to shelf B-42, and you go move that book, then when I walk to B-42 the book is moved for me too — we shared one thing, not two.

In JavaScript, values come in two families. Primitives behave like the photocopy: copy-by-value. Objects behave like the library card: copy-by-reference (you copy the address, not the book).

There are 7 primitive types: string, number, boolean, null, undefined, symbol, bigint. Everything else — arrays, functions, dates, plain {} — is an object.

typeof tells you the type: typeof "hi" → "string", typeof 42 → "number", typeof true → "boolean", typeof undefined → "undefined", typeof 10n → "bigint", typeof Symbol() → "symbol". But watch the famous bug: typeof null === "object" — this is a historic JS mistake that can never be fixed for backward compatibility. And typeof function(){} → "function" (a special sub-case of object).

🌍 Real-world example: You copy a user object to "back it up" before editing (const backup = user), change user.name, and are shocked that backup.name changed too. They were never two objects — both variables held the same address. That single misunderstanding causes a huge share of real-world bugs.

💡 primitive = a simple, single, immutable value (a plain fact like 5 or "cat"). 💡 reference = an address pointing to an object in memory, not the object itself.

null vs undefined: undefined = JS's default "nothing here yet" — a variable declared but not assigned, or a missing property. null = you deliberately set "intentionally empty". Rule of thumb: undefined is the engine's absence, null is your absence.

NaN = "Not a Number", the number you get from broken math like 0/0 or Number("abc"). Gotcha: typeof NaN → "number" (it lives in the number type), and NaN === NaN → false (it is not equal to anything, even itself). Use Number.isNaN(x) to test for it.

Standard definition: JavaScript has 7 primitive types (string, number, boolean, null, undefined, symbol, bigint) that are copied by value and are immutable, and objects (including arrays and functions) that are copied by reference; typeof identifies a value's type, with the historic quirk that typeof null returns "object".

let a = 10;
let b = a;   // copy-by-value
b++;
console.log(a, b); // 10 11 — independent

let user = { name: "Aman" };
let backup = user; // copy-by-REFERENCE (same address)
backup.name = "Riya";
console.log(user.name); // "Riya" — shared object mutated

console.log(typeof null, NaN === NaN); // object false

What we're building: A Todo app in pure vanilla JavaScript — no React, no framework, no libraries. Just an input, an Add button, and a list where you can add items, tick them done, and delete them. It's small, but it drills the single most important pattern in all of UI programming: keep your data in one place (state), and draw the screen FROM that data. Master this and React later will feel obvious — because React is just this pattern automated.

Concepts it teaches: state as a plain array, the render()-from-state pattern, addEventListener, reading input values, event delegation (one listener for the whole list), immutable-ish updates (map/filter), and safe id generation.

---

Step 0 — The mental model (read this first, 60 seconds)

Here's the trap almost every beginner falls into: they add a todo by manually building an <li> and appending it, then to delete they manually find that <li> and remove it, then to toggle they manually flip a class on that <li>. Three different places all poking the DOM by hand. It works for five minutes, then the DOM and your data drift apart and everything breaks.

We do it the disciplined way instead — one direction only:

State is the single source of truth. The screen is just a picture OF the state.

We keep an array called todos. That array IS the truth. There is one function, render(), whose only job is: look at the todos array and rebuild the list on screen to match it. We never edit the DOM directly to add/remove/toggle. Instead we do two clean steps every single time:

1. Change the data (push / map / filter the todos array).
2. Call render() — it wipes the list and redraws it fresh from the array.

💡 State = the data your UI is built from. Here it's the todos array.

💡 render() = a function that reads state and produces the DOM to match it. The DOM is an output of state, never an independent thing you edit.

Every feature below is just "change the array, then render." Keep that picture in your head. Now let's build.

---

Step 1 — The HTML skeleton

First the bare page. Three things: a text box, an Add button, and an empty <ul> for the list.

<input id="todo-input" type="text" placeholder="What needs doing?" />
<button id="add-btn">Add</button>
<ul id="list"></ul>

<script src="app.js"></script>

What's happening: The <ul id="list"> starts empty — we do NOT hand-write any <li>s in the HTML. Every <li> you'll ever see gets created by JavaScript from the todos array. The three ids (todo-input, add-btn, list) are the hooks our JS will grab onto. That's the whole HTML — it never changes again. All the life is in app.js.

💡 We load the script at the bottom (after the elements) so the elements already exist in the DOM when the script runs and document.getElementById can find them.

---

Step 2 — State + a render() that draws from it

Now the heart of the app. Two things: the state array, and the function that turns it into DOM.

const input = document.getElementById('todo-input');
const addBtn = document.getElementById('add-btn');
const list = document.getElementById('list');

// STATE — the single source of truth
let todos = [];

// render() — read state, rebuild the <ul> to match it
function render() {
  list.innerHTML = '';                     // 1. wipe whatever is there
  for (const todo of todos) {              // 2. one <li> per item in state
    const li = document.createElement('li');
    li.dataset.id = todo.id;               // stamp the id onto the element
    li.className = todo.done ? 'done' : '';
    li.textContent = todo.text;

    const del = document.createElement('button');
    del.textContent = 'x';
    del.className = 'delete';
    li.appendChild(del);

    list.appendChild(li);                  // 3. put it in the page
  }
}

render();   // draw once on load (empty list for now)

What's happening — trace it:

1. We grab our three elements once, up top, and store them in variables so we don't re-query every time.
2. todos = [] — state starts empty.
3. render() does three moves: (a) list.innerHTML = '' blanks the whole list, (b) loops over todos and builds one <li> per item, (c) appends each <li> to the <ul>.

The critical habit: render() rebuilds the list from scratch every time — it never tries to "just add the new one" or "just remove one." It throws the old list away and redraws the current truth. That's what keeps DOM and state perfectly in sync — they can't drift, because the DOM is regenerated from the array on every render.

💡 li.dataset.id = todo.id writes a data-id attribute onto the <li>. We'll read it back later (in Step 4) to know which todo a clicked button belongs to. This is how we connect a DOM element back to its item in the array.

💡 textContent (not innerHTML) puts the user's text in as plain text — so if someone types <script> it shows as literal characters, not runnable HTML. Small habit, big security win.

---

Step 3 — Add a todo (change the array, then render)

Now make the Add button work. This is the full loop for the first time.

let nextId = 1;   // simple incrementing id counter

function addTodo() {
  const text = input.value.trim();
  if (text === '') return;                 // ignore empty input

  todos.push({ id: nextId++, text: text, done: false });  // 1. change state
  input.value = '';                        // clear the box
  render();                                // 2. redraw from state
}

addBtn.addEventListener('click', addTodo);
input.addEventListener('keydown', (e) => {
  if (e.key === 'Enter') addTodo();        // Enter also adds
});

What's happening — trace the whole trigger, click by click:

1. You type "Buy milk" and click Add (or press Enter).
2. addTodo() runs. input.value.trim() reads what you typed and trims stray spaces. If it's empty, we bail early so you can't add blank rows.
3. todos.push({ id: nextId++, text, done: false }) — we add a new object to the state array. Each todo is { id, text, done }: a unique id, the text, and a done flag starting false.
4. We clear the input box so it's ready for the next entry.
5. render() runs — wipes the <ul>, loops the now-1-item array, builds one <li>, appends it. The new item appears on screen.

That's the pattern in full: push to array → render() rebuilds the <ul> → DOM updates. We did NOT create an <li> here and stick it in the list ourselves. We only touched the data; render() did the drawing.

💡 Why id: nextId++ and not Math.random()? Ids must be unique — we use them to find the right todo when you click delete. Math.random() can (rarely) produce the same number twice → two todos share an id → deleting one deletes the wrong item, a nasty intermittent bug. A counter (1, 2, 3, …) or crypto.randomUUID() (a guaranteed-unique string) never collides. Use one of those, never random.

---

Step 4 — Event delegation (the pro move)

Here's the interesting problem. Each <li> has a delete button, and clicking the text should toggle done. But the <li>s don't exist yet when the page loads — they're created later, and re-created on every render(). So we can't attach listeners to them up front.

The naive fix is to attach a listener to each button inside render(), every time we redraw. That works but it's wasteful and error-prone: you re-wire dozens of listeners on every keystroke-worth of change. The clean solution is event delegation.

// ONE listener on the <ul> — handles clicks for ALL items, present and future
list.addEventListener('click', (e) => {
  const li = e.target.closest('li');
  if (!li) return;                         // clicked empty space? ignore
  const id = Number(li.dataset.id);        // which todo? read the stamped id

  if (e.target.classList.contains('delete')) {
    deleteTodo(id);                        // clicked the x → delete
  } else {
    toggleTodo(id);                        // clicked the row → toggle done
  }
});

What's happening — why this is the whole trick:

Clicks bubble: a click on the delete button bubbles up through its <li> up to the <ul>. So instead of a listener on every button, we put one listener on the parent <ul> and let every child's click float up to it.

• e.target is the exact element you clicked (the button, or the <li> text).
• e.target.closest('li') walks up from whatever you clicked to find the enclosing <li> — that's the row.
• li.dataset.id reads back the data-id we stamped in render(), telling us which todo in the array this row is.
• Then we branch: was the click on something with class delete? Delete it. Otherwise, toggle it.

💡 Event delegation = attach ONE listener to a parent, and use event.target to figure out which child was clicked. Because the parent (<ul>) is permanent, it automatically covers items added later — no re-wiring on every render. This is the reason delegation beats per-item listeners.

💡 Number(li.dataset.id) — dataset values are always strings ("3"), but our array ids are numbers (3). We convert so the === comparison inside find/filter matches. Forgetting this is a classic "why won't it delete" bug.

---

Step 5 — Toggle and delete (map / filter, then render)

Now the two handlers the delegation calls. Both follow the exact same discipline: produce a new array, reassign todos, then render().

function toggleTodo(id) {
  todos = todos.map(t =>
    t.id === id ? { ...t, done: !t.done } : t   // flip done on the matching one
  );
  render();
}

function deleteTodo(id) {
  todos = todos.filter(t => t.id !== id);        // keep everyone EXCEPT this id
  render();
}

What's happening:

• toggle: map walks every todo. For the one whose id matches, we return a new object { ...t, done: !t.done } — a copy with done flipped. Everyone else is returned unchanged. map hands back a brand-new array, we reassign todos, then render() redraws — the matched row now gets class="done" (Step 2 checks todo.done), so CSS can strike it through.
• delete: filter keeps every todo whose id is not the one clicked — dropping exactly the clicked item. New array, reassign, render(). The row vanishes because it's no longer in the array render() draws from.

Notice both use map/filter, which return new arrays rather than mutating in place. We could splice instead, but building a fresh array is the same mindset React will later demand ("don't mutate state") — good habit to start now.

💡 { ...t, done: !t.done } — the spread ...t copies all of t's fields, then done: !t.done overrides just that one. Result: same todo, done flipped, as a new object.

---

🔎 The full flow (recap the wiring)

Here's every trigger, end to end:

1. Page loads → variables grabbed → todos = [] → render() draws an empty list.
2. Type "Buy milk" + click Add → addTodo() → todos.push({id, text, done:false}) (state changes) → render() rebuilds the <ul> → the item appears.
3. Click the row text → click bubbles to the <ul>'s ONE listener → e.target.closest('li') finds the row → read id → not a delete button → toggleTodo(id) → map flips done → render() → row shows as done (strikethrough).
4. Click the x → bubbles to the same listener → e.target has class delete → deleteTodo(id) → filter drops it → render() → row disappears.

Every single feature is the same two beats: change the todos array → call render(). You never surgically edited the DOM. The array is the truth; the screen is its reflection. That is exactly the discipline that makes big apps (and React) manageable.

---

✅ What you just learned

• State as a plain array — todos is the single source of truth; every todo is { id, text, done }.
• The render()-from-state pattern — one function wipes and rebuilds the DOM from state; you never edit the DOM piecemeal.
• The universal loop — change the data → call render(). Every feature (add, toggle, delete) is just this.
• Event delegation — ONE listener on the parent <ul>, use event.target (+ closest) to find which child was clicked; automatically covers items added later, so no re-wiring on every render.
• map / filter for updates — filter to delete, map (with spread) to toggle — return new arrays instead of mutating.
• Safe ids — an incrementing counter or crypto.randomUUID(), never Math.random() (collisions break delete/toggle).
• dataset to link DOM ↔ data — stamp data-id on each <li>, read it back on click to know which array item you're acting on (remember Number(...) — dataset is always strings).

// --- HTML ---
// <input id="todo-input" type="text" placeholder="What needs doing?" />
// <button id="add-btn">Add</button>
// <ul id="list"></ul>

// --- app.js ---
const input = document.getElementById('todo-input');
const addBtn = document.getElementById('add-btn');
const list = document.getElementById('list');

let todos = [];        // STATE — single source of truth
let nextId = 1;        // safe, collision-free ids (not Math.random!)

function render() {
  list.innerHTML = '';                       // wipe
  for (const todo of todos) {                // rebuild from state
    const li = document.createElement('li');
    li.dataset.id = todo.id;
    li.className = todo.done ? 'done' : '';
    li.textContent = todo.text;

    const del = document.createElement('button');
    del.textContent = 'x';
    del.className = 'delete';
    li.appendChild(del);

    list.appendChild(li);
  }
}

function addTodo() {
  const text = input.value.trim();
  if (text === '') return;
  todos.push({ id: nextId++, text, done: false });  // change state
  input.value = '';
  render();                                          // redraw
}

function toggleTodo(id) {
  todos = todos.map(t => t.id === id ? { ...t, done: !t.done } : t);
  render();
}

function deleteTodo(id) {
  todos = todos.filter(t => t.id !== id);
  render();
}

addBtn.addEventListener('click', addTodo);
input.addEventListener('keydown', (e) => { if (e.key === 'Enter') addTodo(); });

// EVENT DELEGATION — one listener for the whole list
list.addEventListener('click', (e) => {
  const li = e.target.closest('li');
  if (!li) return;
  const id = Number(li.dataset.id);
  if (e.target.classList.contains('delete')) deleteTodo(id);
  else toggleTodo(id);
});

render();