# Crushing JS Algorithms: Real Examples, Not Theory You've probably just opened another [LeetCode](/en/compare/preplyer-vs-leetcode) problem, stared at it for five minutes, then switched tabs to Reddit. I get it. Interview prep, especially for algorithms, feels like a necessary evil, a hurdle designed to make you question your life choices. But for JS/TS folks, it's a specific kind of pain. We spend our days mapping, filtering, reducing, and then suddenly we're asked to implement Dijkstra's from scratch using a min-priority queue on a whiteboard. The disconnect is real. This isn't about memorizing solutions; it's about understanding patterns and translating them into JavaScript or TypeScript that doesn't just pass tests but also makes sense to a human. ## Why Bother with Algorithms in JavaScript? Let's be blunt: most day-to-day front-end or even many back-end JS jobs won't require you to implement a red-black tree. Your `npm install` handles sorted data structures for you. So why do FAANG and other top companies hammer on algorithms? It's not to trick you. They're looking for problem-solving muscle, the ability to break down a complex task, think about edge cases, and write correct, performant code. It's about demonstrating fundamental computer science understanding, something that separates a good developer from an exceptional one. Plus, if you ever work on low-latency systems, large-scale data processing, or anything touching graphics, performance bottlenecks often boil down to algorithmic choices. Knowing the difference between O(n) and O(n log n) isn't academic then; it's dollars and user experience. ## Setting Up Your Battle Station: Tools and Mindset Before you even touch a problem, get your environment right. You'll use VS Code, of course. Install Node.js if you haven't already. For practicing, a simple `console.log` is often enough, but for more structured testing, Jest is your friend. Create a `tests` folder, write a few `describe`/`it` blocks. It forces you to think about inputs and expected outputs, which is half the battle. Don't just jump straight to coding. Read the problem statement twice. Seriously. Identify inputs, outputs, constraints, and any implicit assumptions. Draw examples, trace them manually. This "human compiler" step catches more errors than any linter. When you're practicing, stick to a time limit for each problem, maybe 30-45 minutes for medium, 60-75 for hard. If you can't get it, look at the solution, but don't just copy-paste. Understand *why* that approach works. Then, try to re-implement it from memory a day or two later. Spaced repetition is key here. ## The Core Data Structures: Your Building Blocks You don't need to implement a full `Map` or `Set` in JavaScript; they're built-in and highly optimized. But you do need to understand their underlying concepts and performance characteristics. * **Arrays (`[]`):** Your bread and butter. Fast reads by index (O(1)), but insertions/deletions in the middle can be slow (O(n)). Iteration is O(n). * *Real-world JS Example:* Storing a list of user IDs, processing a batch of API responses. * **Objects (`{}`):** In JS, these often act as hash maps. Nearly O(1) average time for reads, writes, and deletions by key. Collisions can degrade performance to O(n) in worst cases, but modern JS engines handle this well. * *Real-world JS Example:* Caching API data by ID, storing configuration settings, creating frequency counters. * **Maps (`new Map()`):** Similar to objects but can use any value (not just strings/symbols) as keys. Maintains insertion order. Also nearly O(1) average. * *Real-world JS Example:* Memoization, associating DOM elements with data. * **Sets (`new Set()`):** Store unique values. O(1) average for add, delete, has. * *Real-world JS Example:* Removing duplicates from an array, checking for existence of an item efficiently. Beyond these, understand the *concept* of: * **Linked Lists:** You'll rarely implement one from scratch in production JS, but understanding how they work helps with problems involving pointers or sequential data manipulation without array re-indexing costs. * **Trees (Binary Trees, BSTs):** Critical for understanding hierarchical data and efficient searching. Think about the DOM, file systems, or even certain UI components. * **Graphs:** Representing relationships between entities. Think social networks, routing algorithms, dependency graphs in build systems. For these more complex structures, you'll often represent them using arrays or objects. A tree node might be an object `{ value: 5, left: null, right: null }`. A graph might be an adjacency list: `{ 'A': ['B', 'C'], 'B': ['A', 'D'] }`. ## Algorithms: Patterns, Not Puzzles Thinking of algorithms as discrete puzzles you solve once and forget is the wrong approach. They're patterns. Once you recognize the pattern, the solution often falls into place. ### Two Pointers: Simplicity That Scales This is a workhorse, especially for arrays or strings. You use two pointers (indices) to iterate, often from opposite ends or at different speeds. It frequently reduces a O(n^2) problem to O(n). ```javascript /** * Given a sorted array of numbers and a target sum, * find two numbers in the array that add up to the target. * Return their indices. Assume exactly one solution. */ function twoSumSorted(nums: number[], target: number): number[] { let left = 0; let right = nums.length - 1; while (left < right) { const sum = nums[left] + nums[right]; if (sum === target) { return [left, right]; } else if (sum < target) { left++; // Need a larger sum } else { right--; // Need a smaller sum } } // Should not reach here given problem constraints return []; } // Example usage: console.log(twoSumSorted([2, 7, 11, 15], 9)); // [0, 1] console.log(twoSumSorted([1, 2, 3, 4, 5], 9)); // [3, 4] ``` This pattern is also great for reversing an array in place, checking for palindromes, or finding the middle of a linked list (fast/slow pointers). ### Frequency Counter / Hash Map: Counting and Comparing When you need to count occurrences, check for anagrams, or determine if two arrays have the same elements (just in different order), a frequency counter (using a JavaScript object or `Map`) is often the most efficient approach. ```javascript /** * Given two strings, write a function to determine if the second string * is an anagram of the first. * (e.g., "cinema" is an anagram of "iceman") */ function validAnagram(str1: string, str2: string): boolean { if (str1.length !== str2.length) { return false; } const charCount: { [key: string]: number } = {}; // Populate charCount for str1 for (const char of str1) { charCount[char] = (charCount[char] || 0) + 1; } // Decrement count for str2 for (const char of str2) { // If character doesn't exist or its count is zero, it's not an anagram if (!charCount[char]) { return false; } charCount[char]--; } // If we reach here, all characters matched return true; } console.log(validAnagram("anagram", "nagaram")); // true console.log(validAnagram("rat", "car")); // false ``` The key here is converting potentially O(N log N) sorting comparisons to O(N) map operations. ### Sliding Window: Subarrays and Substrings When you need to find the maximum/minimum sum of a subarray of a fixed size, or the longest substring with unique characters, the sliding window pattern is your go-to. It avoids recalculating sums/counts for each new window. ```javascript /** * Given an array of integers and a number 'k', * find the maximum sum of a subarray with the length 'k'. */ function maxSubarraySum(arr: number[], k: number): number | null { if (k > arr.length) { return null; // Window size larger than array } let maxSum = 0; let windowSum = 0; // Calculate sum of the first window for (let i = 0; i < k; i++) { windowSum += arr[i]; } maxSum = windowSum; // Slide the window for (let i = k; i < arr.length; i++) { windowSum = windowSum - arr[i - k] + arr[i]; // Subtract old, add new maxSum = Math.max(maxSum, windowSum); } return maxSum; } console.log(maxSubarraySum([2, 6, 9, 2, 1, 8, 5, 6, 3], 3)); // 19 (from [2,1,8]) console.log(maxSubarraySum([1, 2, 3], 4)); // null ``` This pattern is incredibly versatile. It's not just for sums; you can use it for counts, averages, or any property you need to evaluate over a contiguous subarray or substring. ### Recursion & Backtracking: Exploring Possibilities This is where things get interesting and often harder. Recursion is when a function calls itself. Backtracking is a refinement, often used in conjunction with recursion, to explore all potential solutions by systematically trying and abandoning paths. Think of mazes, permutations, combinations, N-Queens problem. ```typescript /** * Given a set of distinct integers, nums, return all possible subsets (the power set). * The solution set must not contain duplicate subsets. */ function subsets(nums: number[]): number[][] { const result: number[][] = []; const currentSubset: number[] = []; /** * Helper function to build subsets recursively. * @param index The current starting index for elements to consider. */ function backtrack(index: number) { // Add the current subset to the result list result.push([...currentSubset]); // Push a copy! // Explore choices for (let i = index; i < nums.length; i++) { currentSubset.push(nums[i]); // Choose backtrack(i + 1); // Explore currentSubset.pop(); // Unchoose (backtrack) } } backtrack(0); return result; } console.log(subsets([1, 2, 3])); /* Expected: [ [], [1], [1, 2], [1, 2, 3], [1, 3], [2], [2, 3], [3] ] */ ``` The `currentSubset.pop()` is the "backtrack" step. It removes the last added element, allowing the recursion to explore other branches of the decision tree. This pattern is fundamental for any problem where you're building up a solution piece by piece and need to try all combinations. ### Dynamic Programming: Memoization and Tabulation DP is intimidating, but it's just optimized recursion. When you see overlapping subproblems and optimal substructure, think DP. You have two main approaches: 1. **Memoization (Top-Down):** Start with the recursive solution, then store results of expensive function calls in a cache (e.g., an array or `Map`) to avoid recomputing them. 2. **Tabulation (Bottom-Up):** Build up the solution iteratively, usually filling a table (array) from base cases. Let's look at the classic Fibonacci sequence: ```typescript // Memoization (Top-Down) function fibMemo(n: number, memo: { [key: number]: number } = {}): number { if (n in memo) return memo[n]; if (n <= 2) return 1; memo[n] = fibMemo(n - 1, memo) + fibMemo(n - 2, memo); return memo[n]; } console.log(`Fibonacci (memoized) of 10: ${fibMemo(10)}`); // 55 // Tabulation (Bottom-Up) function fibTab(n: number): number { if (n <= 2) return 1; const fibNums: number[] = [0, 1, 1]; // fibNums[0] is dummy, fibNums[1]=1, fibNums[2]=1 for (let i = 3; i <= n; i++) { fibNums[i] = fibNums[i - 1] + fibNums[i - 2]; } return fibNums[n]; } console.log(`Fibonacci (tabulated) of 10: ${fibTab(10)}`); // 55 ``` For interview settings, memoization is often easier to transition to from a naive recursive solution. Tabulation usually requires a bit more foresight but can be more performant as it avoids recursion overhead. ## Time and Space Complexity: The Silent Interviewer You'll always be asked about this. Always. Get comfortable with Big O notation. * **O(1):** Constant time. Accessing an array element by index. * **O(log n):** Logarithmic. Binary search. You cut the problem size in half each step. * **O(n):** Linear. Iterating through an array once. * **O(n log n):** Linearithmic. Efficient sorting algorithms like merge sort, quick sort. * **O(n^2):** Quadratic. Nested loops where inner loop depends on outer. * **O(2^n):** Exponential. Brute-force recursive solutions without memoization (like naive Fibonacci). For space complexity, it's about auxiliary space. Do you create new arrays, objects, or Maps that scale with input size? The call stack for recursion also counts. Be able to justify your choices. Sometimes, a slightly higher time complexity is acceptable for significantly better space complexity, or vice-versa. It depends on the problem constraints and what they're optimizing for. ## TypeScript Specifics: Typing Your Way to Clarity Using TypeScript in algorithm interviews isn't just about type safety; it's about clarity. It forces you to explicitly define your function signatures, inputs, and outputs. This helps prevent common off-by-one errors or misinterpretations of data types. For example, when dealing with tree nodes, define an interface: ```typescript interface TreeNode { val: number; left: TreeNode | null; right: TreeNode | null; } // Then your function signature is clear: function isValidBST(root: TreeNode | null): boolean { // ... implementation } ``` This immediately tells the interviewer (and yourself) what `root` looks like. It also catches errors during development. Don't go overboard with overly complex types that distract from the algorithm itself, but use them to define the core data structures involved. ## Common Pitfalls and How to Avoid Them 1. **Ignoring Edge Cases:** What if the input array is empty? What if `k` is larger than the array length? What if strings are null or contain special characters? Always ask these questions. Write down edge cases before you code. 2. **Off-by-One Errors:** The classic `i <= arr.length` instead of `i < arr.length`. Trace your loops with small inputs. 3. **Mutable Global State:** In recursive or iterative problems, accidentally modifying a shared state can lead to tricky bugs. Pass copies (`[...arr]`) or new objects when necessary. 4. **Inefficient Data Structures:** Using an array for constant-time lookups when a `Map` would be O(1) can kill your performance. Choose wisely. 5. **Forgetting to Return:** Happens more often than you'd think in complex recursive functions. 6. **Not Communicating:** Interviewers aren't mind readers. Talk through your thought process. Explain your initial brute-force idea, then how you optimize it. Discuss trade-offs. ## When to Bail and When to Push Through This depends on your situation. If you're interviewing for a junior front-end role at a smaller company primarily focused on UI, they might gauge your problem-solving with simpler array manipulations or string problems. They're probably not expecting you to implement a graph traversal from scratch. For those roles, focus on the fundamentals: arrays, objects, basic loops, and perhaps recursion. However, if you're aiming for a senior staff engineer position at a FAANG or a company with complex distributed systems, they will absolutely expect proficiency in all the patterns mentioned here, including advanced graph algorithms, dynamic programming, and potentially [system design](/en/interview-prep/system-design). Don't try to cram for every single algorithm type if your target role doesn't demand it. That's a recipe for burnout. Assess the companies and roles you're applying for, and tailor your prep accordingly. A good rule of thumb: if the company uses "LeetCode Hard" as a filter, you better be ready for it. If they focus on "practical coding challenges," then your real-world JS skills and problem-solving approach will likely shine more than optimal DP solutions. ## Ready to Ace Your Next Interview? Practice with AI-powered [mock interview](/en/interview-prep)s tailored to your target role and company. [Start Practicing for Free](/sign-up) | [Explore Interview Prep](/en/interview-prep)