DSA for Frontend Certification

Syllabus

Every paper is drawn to this mix, so the weights are a promise rather than a guide. The bars show each area's share of the 50 questions.

• Big-O reasoning for frontend code

  3 Q·6%

  Growth rate versus absolute speed, spotting a linear method called inside a loop, and why the same Big-O can still matter differently depending on real-world n.

• Time complexity, amortized cost, and space complexity

  4 Q·8%

  Deriving complexity by counting operations, why array.push() is amortized O(1), auxiliary space versus input size, and the call stack as real memory.

• Two pointers and sliding window

  3 Q·6%

  Opposite-ends and same-direction two pointers, fixed- and variable-size sliding windows, and why both stay linear despite looking nested.

• In-place manipulation, prefix sums, and string parsing

  3 Q·6%

  Read/write pointer compaction, the splice-while-iterating bug, prefix sums for O(1) range queries, and stacks for balanced-bracket and tokenizing problems.

• Hash maps and sets for O(1) lookup

  4 Q·8%

  Why Set.has() beats Array.includes() inside a loop, average versus worst-case hashing, and the reference-versus-value gotcha with object keys.

• Frequency counting, two sum, and grouping with maps

  4 Q·8%

  One-pass frequency counting, the two-sum complement pattern, and map-based grouping and deduplication by a chosen key.

• Recursion and the call stack

  4 Q·8%

  Base cases and recursive cases, tracing frames by hand, and why a recursive result resolves from the base case outward as the stack unwinds.

• Recursion vs. iteration, memoization, and divide and conquer

  3 Q·6%

  Stack overflow risk on real nested data, the tail-call-optimization myth in non-Safari engines, memoization turning exponential into linear, and merge sort's divide-and-conquer proof.

• Binary trees and traversal (BFS/DFS)

  4 Q·8%

  Tree vocabulary, the binary search tree ordering property and its balance-dependent O(log n) promise, and choosing between BFS and DFS.

• The DOM as a tree and real frontend tree problems

  4 Q·8%

  querySelectorAll and closest() as named traversals with real complexity, flattening nested comments, building a file tree, and searching a component tree.

• Linked lists, stacks, and queues

  3 Q·6%

  O(1) insertion trade-offs versus arrays, undo/redo as a stack, browser navigation as two stacks, and the shift() gotcha in a naive queue.

• The LRU cache

  2 Q·4%

  Combining a map and a doubly linked list to get get/put/evict all to genuine O(1), and why neither structure alone achieves it.

• Graphs, lightly

  3 Q·6%

  Adjacency lists versus matrices, the visited set graphs need that trees don't, cycle detection with three-color DFS, and topological sort.

• Sorting and binary search

  3 Q·6%

  Array.prototype.sort's real complexity and stability, the no-comparator numeric-sort bug, binary search's proof, and the search-on-answer pattern.

• Applying DSA to real frontend problems

  3 Q·6%

  Debounce and throttle as sliding-window shapes, and list virtualization as a complexity mismatch solved with prefix sums and binary search together.

Three questions from the bank

Representative of the mix and difficulty — answer visible, shown here to calibrate expectations rather than test you.

1. Sample 1·Big-O reasoning for frontend code

   A component renders a list of n tags, and for each tag calls otherTags.includes(tag) where otherTags also has roughly n entries. What is the overall time complexity?

   • O(n²), because a linear .includes() call runs inside a loop over n items
   • BO(n), because .includes() is a fast native method
   • CO(n log n)
   • DO(1), because array methods don't count toward complexity

   Why: includes() scans linearly. Calling it once per item in an n-length loop multiplies n by n, giving O(n²) — the single most common accidental-quadratic shape in real frontend code.

2. Sample 2·Time complexity, amortized cost, and space complexity

   function pairs(arr) { let c = 0; for (let i = 0; i < arr.length; i++) { for (let j = i + 1; j < arr.length; j++) { c++; } } return c; } — what is the time complexity in terms of n = arr.length?

   • AO(n)
   • O(n²)
   • CO(n log n)
   • DO(2n)

   Why: The inner loop's total iterations across all i sum to n(n-1)/2. Dropping the constant and the lower-order term leaves n², the dominant term — O(n²).

3. Sample 3·Two pointers and sliding window

   Why does the opposite-ends two-pointer technique reverse an array in O(1) auxiliary space?

   • AIt builds a new reversed array and returns that instead
   • It swaps elements within the existing array using two index variables and a temp value for the swap — no second array is allocated
   • CIt uses recursion, which is always O(1) space
   • DJavaScript arrays cannot be reversed with extra space regardless of technique

   Why: In-place reversal only ever reads and writes within the original array's slots — the extra memory used (two pointers, one temp variable) is constant regardless of array size.

What sitting it is like