EasyFrontendAsked in 20244 min read

Custom getElementById traverse

Q: Custom getElementById traverse

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** the "returns the same real node" claim was verified directly by reference-comparing the hand-written result against the actual, real `document.getElementById` in a real jsdom document — not assumed from reading the code. ## 1. The problem, restated Given a root DOM node and a target id, walk the tree by hand (without using `getElementById`/`querySelector` internally) and return the element whose `id` attribute matches, or `null` if none does. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Search from any root, or always `document`? | A general `(root, id)` signature is genuinely more reusable and testable. | | Return value on no match? | `null` matches the real `getElementById`'s own documented contract. | | Multiple elements share the same (invalid) id? | Real browsers still return the FIRST match

1.6k views

14 of 154

The problem

Problem, as an interviewer would state it: "Implement your own version of document.getElementById(id), walking the DOM tree by hand rather than using the real built-in method. Show me it returns the exact same node the real one would."

Examples:

Code

findById(document.body, "submit-button") // the actual matching element, or null

Clarifying questions expected:

Should the search start from document/document.body, or should it accept any root node to search from?
What should it return if no element has that id — null, or undefined?
Should it stop at the FIRST match if (invalidly) multiple elements share an id, matching real browser behavior?

Code / implementation expected: Yes — real, direct proof against a real jsdom document that the hand-written traversal returns the identical node reference the browser's own getElementById would.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: the "returns the same real node" claim was verified directly by reference-comparing the hand-written result against the actual, real document.getElementById in a real jsdom document — not assumed from reading the code.

1. The problem, restated

Given a root DOM node and a target id, walk the tree by hand (without using getElementById/querySelector internally) and return the element whose id attribute matches, or null if none does.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Search from any root, or always `document`?	A general `(root, id)` signature is genuinely more reusable and testable.
Return value on no match?	`null` matches the real `getElementById`'s own documented contr

The solution is hidden so you can try first

4 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: a recursive getElementById-style tree walk returns the exact same real node as the browser's own native method

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

No comments yet. Share how you would answer it.

Question 14 of 154 in JavaScript coding

Keep your momentum going.

Mark this question solved to track your progress, then take the next one while it is fresh.

All JavaScript coding questions

Up nextEasy→

Immer-like draft proxies

Continue