A DOM Exercise They Love to Ask

This is the classic DOM exercise because it looks trivial and has a dozen small decisions inside it. The interviewer is watching how you build the tree, not whether you can call appendChild.

// A tiny stand-in for the browser DOM, so this example runs in Node.
const element = (tag, attrs = {}) => ({
  tagName: tag.toUpperCase(),
  attributes: attrs,
  children: [],
  textContent: "",
  appendChild(child) { this.children.push(child); return child; },
});

const renderList = (items) => {
  const list = element("ul", { class: "list" });

  for (const item of items) {
    const li = element("li", { "data-id": String(item.id) });
    li.textContent = item.label;
    list.appendChild(li);
  }

  return list;
};

const rendered = renderList([
  { id: 1, label: "Write a spec" },
  { id: 2, label: "Ship it" },
]);

console.log(rendered.tagName);                            // "UL"
console.log(rendered.children.length);                     // 2
console.log(rendered.children.map((li) => li.textContent));
// ["Write a spec", "Ship it"]
console.log(rendered.children[0].attributes["data-id"]);   // "1"

The decisions that matter. You build the whole tree before you attach it, so the browser does the layout work once rather than once per node. You set the text through the textContent property rather than through innerHTML, which is safe with any content and does not parse markup. And you put the identifier in a data attribute, so a click handler can find out which row was clicked without you having to search the text.

What an interviewer will ask next. What happens with an empty list, and the answer is that you either render an empty state message or leave the list empty, and you decide which. How you would update it when the data changes, and the answer is that you re-render and replace the children, or you diff them if the list is long. And how you would test it, which is where a function that takes data and returns an element rather than one that reaches into the document is much easier to test.

The follow-up exercise. The filtering logic is easy, and the interviewer is really asking whether you know about debouncing and about not rebuilding the whole page on every keystroke.

// A tiny stand-in for the browser DOM.
const element = (tag) => ({
  tagName: tag.toUpperCase(),
  children: [],
  textContent: "",
  appendChild(child) { this.children.push(child); return child; },
  setText(value) { this.textContent = value; return this; },
});

const renderFiltered = (items, query) => {
  const list = element("ul");
  const needle = query.trim().toLowerCase();

  for (const item of items) {
    if (!item.label.toLowerCase().includes(needle)) continue;
    const li = element("li");
    li.setText(item.label);
    list.appendChild(li);
  }

  return list;
};

const items = [
  { id: 1, label: "Write a spec" },
  { id: 2, label: "Ship it" },
  { id: 3, label: "Write the tests" },
];

const filtered = renderFiltered(items, "wr");
console.log(filtered.children.map((li) => li.textContent));
// ["Write a spec", "Write the tests"]

Three details in the implementation. The query is trimmed and lowercased once, outside the loop, and the labels are lowercased as they are compared, so the search is case-insensitive without allocating a new string for the needle on every item. The filter uses continue, so a non-matching item skips straight to the next one. And the same function shape as the first exercise is used, which is the point: render a tree from data, and both features share it.

The things to say out loud in the interview. The search should be debounced, because re-rendering on every keystroke is wasteful and makes the list flicker. The list should be replaced rather than appended to, otherwise the results accumulate. And for a long list you would not re-render at all, you would hide and show the existing rows, because that avoids destroying and recreating the DOM nodes and keeps any focus or selection intact.

One last point that shows judgement. If the search needs to match on more than the label, such as a description or a tag, the matching belongs in a separate pure function that takes an item and the query and returns a boolean. That keeps it testable and it keeps the rendering function about rendering.