DSA Interview Questions

Big O describes how an algorithm's running time or memory usage grows as the input size grows, focusing on the dominant term and ignoring constant factors. It's not a measure of actual speed in seconds. It's a way of comparing how two algorithms would scale relative to each other as input size gets large.

Time complexity measures how the running time of an algorithm grows with input size. Space complexity measures how the memory it uses grows with input size. An algorithm can trade one for the other, using more memory to run faster, or using less memory at the cost of running slower, and neither is universally better without knowing the actual constraint you're optimizing for.

An O(n) algorithm's work grows linearly with input size, doubling the input roughly doubles the work. An O(n^2) algorithm's work grows with the square of the input size, so doubling the input roughly quadruples the work. That gap becomes enormous at scale, which is exactly why an O(n^2) solution that works fine on a small test case can time out completely on a large real-world input.

Best case describes the most favorable input for an algorithm, average case describes typical or random input, and worst case describes the most unfavorable input possible. Interviewers usually care most about worst case, since that's the guarantee an algorithm actually provides, and a system that only performs well on the average case can still fail badly on a specific bad input.

Big O ignores constant factors and lower-order terms, but for small or moderate input sizes, an algorithm with a technically worse Big O complexity but a much smaller constant factor can genuinely outperform one with better asymptotic complexity. This is exactly why some sorting algorithms switch to a simpler method like insertion sort for small subarrays, even inside an otherwise more sophisticated sort.

An array stores elements in contiguous memory, giving constant-time access to any element by its index. Its main limitation is that inserting or removing an element in the middle requires shifting every subsequent element, making that operation linear time, and in many languages an array's size is fixed once created, requiring a whole new array to grow it.

A single pass through the array, tracking the current max and min as you go and updating them whenever you find a larger or smaller value, solves this in O(n) time with O(1) extra space. Sorting the array first would also work, but at O(n log n), which is strictly worse for this specific problem than the single linear pass.

Use two pointers, one starting at the beginning and one at the end, swapping the elements they point to and moving both pointers toward the middle until they meet or cross. This reverses the array in O(n) time using O(1) extra space, without needing a second array to hold the result.

Use two pointers, one starting at each end of the string, comparing characters and moving inward, and returning false the moment a pair doesn't match. This runs in O(n) time and needs no extra space beyond the two pointers themselves.

A hash map counting each character's frequency in one pass, followed by a second pass through the string checking each character's count in that map, finds the first character with a count of exactly one in O(n) time overall, using O(1) extra space if the character set is fixed and small, like standard ASCII.

The two-pointer technique typically moves two pointers toward each other, or independently, to solve a problem in one pass, common for problems like checking a palindrome or finding a pair summing to a target. The sliding window technique maintains a contiguous range that expands and contracts as it moves through the array, common for problems asking about a subarray or substring satisfying some condition.

A linked list stores elements as separate nodes, each holding its data and a reference to the next node, rather than in one contiguous block of memory like an array. This makes insertion and deletion at a known position fast, since it just involves changing a couple of references, but accessing an element by position requires walking the list from the start, unlike an array's constant-time indexed access.

A singly linked list's nodes each point only to the next node, so traversal only moves forward. A doubly linked list's nodes point to both the next and the previous node, allowing traversal in either direction, at the cost of extra memory per node to store that second reference.

Walk through the list once, and at each node, redirect its next pointer to point to the previous node instead of the next one, keeping track of the previous, current, and next nodes as you go so you don't lose your place. This reverses the list in O(n) time using O(1) extra space.

Floyd's cycle detection, using two pointers moving at different speeds, a slow pointer moving one node at a time and a fast pointer moving two, detects a cycle if the fast pointer ever catches up to and equals the slow pointer. If there's no cycle, the fast pointer simply reaches the end of the list first, running in O(n) time with O(1) extra space.

The same slow-and-fast pointer idea used for cycle detection works here too. Move a slow pointer one node at a time and a fast pointer two nodes at a time, and when the fast pointer reaches the end, the slow pointer is sitting at the middle, all in a single pass with O(1) extra space.

An array wins when you need fast, random access by index and know the size upfront, or close to it. A linked list wins when you need frequent insertion or deletion at arbitrary positions and don't need fast indexed access. Most real-world code defaults to an array-based structure (like a dynamic array) unless there's a specific reason a linked list's insertion behavior is genuinely needed.

A stack follows Last In, First Out (LIFO) ordering, meaning the most recently added element is the first one removed. Its two main operations are push (add to the top) and pop (remove from the top), both running in constant time.

A queue follows First In, First Out (FIFO) ordering, meaning the first element added is the first one removed, unlike a stack's LIFO behavior. Its two main operations are enqueue (add to the back) and dequeue (remove from the front).

Checking whether parentheses in an expression are balanced is a classic example. Push an opening bracket onto the stack, and when you hit a closing bracket, check that it matches whatever's on top of the stack, popping it if it does. A browser's back button, and the call stack an actual program uses to track function calls, are both real-world stacks too.

Processing tasks in the order they arrive, like a print queue or a customer service ticket system, is a natural fit for a queue's first-in-first-out behavior. Breadth-first search on a graph or tree also relies on a queue internally to visit nodes level by level, in the order they were discovered.

Use one stack for incoming elements (enqueue) and a second stack for outgoing elements (dequeue). When the outgoing stack is empty and a dequeue is requested, pop every element off the incoming stack and push it onto the outgoing stack, which reverses their order into the correct queue order, then pop from the outgoing stack as normal.

A deque allows insertion and removal from both ends, the front and the back, whereas a regular queue only allows insertion at the back and removal from the front. This flexibility makes a deque useful for a wider range of problems, like implementing a sliding window maximum, where elements sometimes need to be removed from either end depending on the current window's contents.

Recursion is a function calling itself to solve a smaller version of the same problem. Every correct recursive solution needs a base case, the condition where it stops calling itself and returns directly, and a recursive case that makes real progress toward that base case with each call, otherwise the recursion never terminates.

The base case is the simplest version of the problem, small enough to answer directly without any further recursive calls. Forgetting a base case, or writing one that's never actually reached, causes infinite recursion, which eventually crashes the program with a stack overflow once the call stack runs out of space.

factorial(n) returns 1 if n is 0 (the base case), otherwise returns n times factorial(n - 1). Each call reduces the problem to a smaller version of itself, n minus one, until it reaches the base case, then the results combine back up through each level of the call stack.

The call stack tracks each active function call, including a recursive one, storing its local variables and where to return to once it finishes. Each recursive call adds a new frame to the stack, which is exactly why deep, unbounded recursion can exhaust the stack and crash with a stack overflow error, since each level of recursion consumes real memory on that stack.

Recursion expresses a solution in terms of smaller instances of the same problem, often reading closer to a direct restatement of the problem itself, especially for naturally recursive structures like a tree. Iteration uses a loop instead, generally using less memory since it avoids the overhead of the call stack, and it's often the more practical choice once recursion depth could get large enough to risk a stack overflow.

Linear search checks each element one at a time until it finds the target or reaches the end of the list, running in O(n) time in the worst case. It works on an unsorted list, but it doesn't take advantage of any structure the data might have, unlike binary search.

Binary search repeatedly halves the search space by comparing the target to the middle element, discarding the half that can't contain the target, running in O(log n) time. It requires the data to already be sorted. Running binary search on unsorted data gives an incorrect, unreliable result, since the halving logic depends entirely on the sorted order.

Track a low and high boundary, repeatedly checking the middle element between them. If the middle element equals the target, you're done. If the target is smaller, move the high boundary down. If larger, move the low boundary up instead. Repeat until the target is found or the boundaries cross, meaning the target isn't present.

Bubble sort repeatedly compares and swaps adjacent elements that are out of order, making multiple passes through the list until it's fully sorted, running in O(n^2) time. It's rarely used in real code because far more efficient sorting algorithms, running in O(n log n), exist and are readily available in every standard library, making bubble sort mainly useful as a teaching tool for understanding sorting conceptually.

Selection sort repeatedly finds the minimum remaining element and moves it to its correct position, making the same number of comparisons regardless of the input's initial order. Insertion sort builds the sorted portion of the list one element at a time, inserting each new element into its correct place among the already-sorted elements, and it performs noticeably better than selection sort on data that's already mostly sorted.

Binary search's speed depends on being able to jump directly to the middle element in constant time, which an array supports through indexed access. A linked list has no indexed access. Reaching its middle element requires walking from the start, which alone takes O(n) time, defeating the entire benefit binary search would otherwise provide.

Stability is about preserving the relative order of equal elements. In-place refers to using only a constant amount of extra memory beyond the input itself. A sort can absolutely be both, insertion sort is both stable and in-place, but the two properties are independent of each other, and some algorithms trade one for the other, like merge sort typically needing extra space to remain stable.

Inorder visits left subtree, then the node itself, then right subtree, which produces sorted output for a binary search tree specifically. Preorder visits the node first, then left, then right, useful for copying or serializing a tree's structure. Postorder visits left, then right, then the node itself, useful when children need to be processed before their parent, like when deleting a tree.

Average case is O(log h) where h relates to the tree's height, roughly O(log n) for a balanced tree. It can degrade to O(n) in the worst case if the tree becomes unbalanced, effectively turning into something resembling a linked list, which happens when data is inserted in an already-sorted or nearly-sorted order without any rebalancing.

A balanced tree keeps its height as small as possible relative to the number of nodes, roughly O(log n), by rebalancing itself as elements are inserted or removed. This guarantees search, insertion, and deletion all stay close to O(log n) in the worst case too, rather than degrading toward O(n) the way an unbalanced tree can.

A binary heap is a complete binary tree satisfying the heap property, every parent is either always greater than or always less than its children, depending on whether it's a max-heap or min-heap. It's commonly used to implement a priority queue, since it gives constant-time access to the minimum or maximum element and logarithmic-time insertion and removal.

A hash table maps a key to a value using a hash function that converts the key into an index into an underlying array. As long as that hash function distributes keys reasonably evenly and collisions are handled well, most operations, lookup, insertion, deletion, run in average-case constant time, which is what makes hash tables so widely used for problems needing fast key-based access.

A collision happens when two different keys hash to the same index in the underlying array. Chaining handles this by storing a small list of entries at that one index, while open addressing handles it by probing for the next available slot in the array itself instead of using a separate list per index.

Load factor is the ratio of stored elements to the number of available slots. As load factor increases, collisions become more frequent, degrading average-case performance from close to constant time toward something noticeably slower. Most hash table implementations automatically resize and redistribute their entries once load factor crosses a set threshold, trading a one-time resizing cost for keeping typical operations fast going forward.

Iterate through the array, checking each element against a hash set as you go, adding it if it's not already present, and returning true immediately if you find one that already is. This runs in O(n) time on average, compared to O(n log n) for a sort-then-scan approach, or O(n^2) for a naive nested-loop comparison.

As you iterate through the array once, check whether the complement, target minus the current number, already exists in a hash set you've been building. If it does, you've found your pair. If not, add the current number to the set and keep going. This solves it in O(n) time, compared to O(n^2) for checking every possible pair directly.

Merge sort recursively splits the array in half until each piece has just one element, then merges those pieces back together in sorted order. It runs in O(n log n) time in every case, best, average, and worst, and is a stable sort, meaning elements that compare equal keep their original relative order.

Quicksort picks a pivot element, partitions the array so smaller elements land on one side and larger on the other, then recursively sorts each side. Average case is O(n log n), but a poorly chosen pivot, like always picking the first element on an already-sorted array, can degrade the worst case to O(n^2).

A stable sort preserves the original relative order of elements that compare as equal. An unstable sort makes no such guarantee, and equal elements might end up reordered relative to each other. This matters when sorting by one field but wanting to preserve a previous sort's order among ties on that field, a common real-world need when sorting a table by multiple columns in sequence.

Quicksort is often faster in practice due to better cache performance and a smaller constant factor, and is commonly used when average-case performance genuinely matters more than a worst-case guarantee. Merge sort's guaranteed O(n log n) worst case, and its stability, make it the better choice when a worst-case guarantee actually matters, or when sorting data that doesn't fit entirely in memory, since merge sort adapts naturally to external, disk-based sorting.

A graph is a set of nodes connected by edges, with no restriction on how many connections a node can have or whether cycles exist. A tree is actually a special, restricted kind of graph, one with no cycles and exactly one path between any two nodes, which is why every tree is a graph, but not every graph is a tree.

An adjacency matrix uses a 2D array where each cell indicates whether an edge exists between two nodes, giving constant-time edge lookup but using O(n^2) space regardless of how many edges actually exist. An adjacency list stores, for each node, a list of its actual neighbors, using space proportional to the number of edges, which is far more efficient for a sparse graph with relatively few edges.

BFS explores a graph level by level, visiting all of a node's immediate neighbors before moving further out, implemented using a queue. DFS explores as far as possible down one path before backtracking, implemented using a stack, or recursion, which uses the call stack implicitly.

BFS is the natural choice when you need the shortest path in an unweighted graph, since it explores nodes in order of increasing distance from the start, guaranteeing the first time you reach a target node, you've reached it by the shortest possible path. DFS doesn't offer that same guarantee, since it can go deep down a long path before ever trying a shorter one.

DFS with a way to track nodes currently on the active recursion path, beyond simply marking them visited overall, detects a cycle if you encounter a node that's already on that current path. This is different from an undirected graph's cycle detection, since in a directed graph, encountering an already-visited node isn't necessarily a cycle unless it's specifically on the current path being explored.

Backtracking is a recursive technique that builds a solution incrementally, and abandons, backtracks, from a partial solution the moment it becomes clear it can't possibly lead to a valid, complete answer, rather than continuing to explore a dead end all the way to the bottom. This pruning is what makes backtracking practical for problems with a huge number of possible combinations, most of which don't need to be fully explored.

Build a permutation one element at a time, at each step trying every element not yet used, recursing to add the next one, then backtracking, removing that element, once you've explored every possibility with it in that position. This systematically covers every possible ordering without missing any or repeating any.

Place queens one row at a time, and for each row, try each column, checking whether that placement conflicts with any already-placed queen (same column, or a diagonal). If no conflict exists, recurse to the next row. If every column in the current row leads to a conflict, backtrack to the previous row and try a different placement there instead.

Memoization caches the result of a function call keyed by its input, so if the same input is encountered again during recursion, the cached result is returned instantly instead of recomputing it from scratch. It's especially powerful for recursive solutions that would otherwise repeat the exact same subproblem many times, like a naive recursive Fibonacci implementation.

The naive recursive version recalculates the same smaller Fibonacci values over and over, since fib(n) calls both fib(n-1) and fib(n-2), which themselves each call overlapping smaller values again, leading to exponential O(2^n) time. Memoization stores each computed value the first time it's calculated, so every subsequent request for that same value is an instant lookup, bringing the total time down to linear, O(n).

Memoization starts from the original problem and recursively breaks it down, caching results as it goes, which is generally more intuitive to write since it follows the natural recursive structure of the problem. Tabulation starts from the smallest subproblems and iteratively builds up to the final answer, avoiding recursion's call stack overhead entirely, and is often more memory-efficient since it can sometimes discard results it no longer needs.

Build a table where each cell represents the best achievable value using a specific subset of the first i items within a specific weight capacity. For each item, you decide whether including it (if it fits) improves on the best value without it, filling the table based on that choice. The final answer sits in the cell representing all items and the full available capacity.

It asks for the longest sequence of characters that appears in the same relative order, though not necessarily contiguous, in two given strings. A 2D table, where each cell represents the longest common subsequence of prefixes of each string up to that point, builds up incrementally, comparing characters and either extending a match or taking the best result from ignoring one character from either string.

Look for language suggesting an optimal choice among many combinations, minimum cost, maximum value, number of distinct ways, combined with the sense that a naive recursive solution would repeat the same subproblem many times. If you can express the problem as a recurrence relation where the answer to a larger case depends on smaller cases of the same problem, that's a strong signal DP is the right tool.

A greedy algorithm makes the locally best choice at each step without reconsidering it later, which works correctly only for problems where the locally optimal choice always leads to the globally optimal solution. DP considers all relevant possibilities and their downstream consequences, which is necessary exactly when a greedy choice that looks best right now can lead to a worse overall outcome than a different choice would have.

A self-balancing BST automatically maintains a roughly balanced structure as elements are inserted or removed, keeping operations close to O(log n) even in the worst case. AVL trees and Red-Black trees are the two most commonly discussed examples, each using a different specific rebalancing strategy to maintain that guarantee.

An AVL tree enforces stricter balance, keeping the height difference between any node's two subtrees at most one, which makes lookups slightly faster but requires more frequent rebalancing on insertion and deletion. A Red-Black tree allows a looser balance in exchange for fewer rebalancing operations, which is why many standard library implementations of ordered maps and sets use a Red-Black tree rather than an AVL tree.

A trie is a tree structure where each path from the root represents a sequence, typically a string, character by character, with shared prefixes sharing the same path in the tree. It's particularly well suited for autocomplete and prefix-matching problems, since checking whether any word with a given prefix exists takes time proportional to the prefix length, not the number of words stored.

Insertion takes time proportional to the length of the word being inserted, following or creating one node per character, regardless of how many other words already exist in the trie. This is different from a hash set or a sorted structure, where insertion time can depend on the total number of elements already stored, beyond simply the size of the new item being added.

Dijkstra's algorithm finds the shortest path from a starting node to every other node in a graph with non-negative edge weights, using a priority queue to always expand the currently-closest unvisited node next. It's the standard approach for shortest-path problems in a weighted graph, as long as no edge weight is negative, since negative weights can break its core assumption.

Dijkstra's is faster but requires all edge weights to be non-negative. Bellman-Ford is slower, O(VE) compared to Dijkstra's roughly O(E log V), but correctly handles negative edge weights and can even detect a negative weight cycle, something Dijkstra's algorithm simply can't handle correctly at all.

A segment tree supports efficient range queries, like the sum or minimum over a subrange of an array, alongside efficient updates to individual elements, both in O(log n) time. It's the right tool once a problem needs many repeated range queries interspersed with updates, since recomputing a range query from scratch on every request would be far too slow at scale.

Both find a subset of edges connecting all nodes with the minimum total edge weight and no cycles. Kruskal's algorithm sorts all edges by weight and greedily adds the smallest one that doesn't create a cycle, checked efficiently with a union-find data structure. Prim's algorithm instead grows a single tree outward from a starting node, always adding the cheapest edge connecting the current tree to a new node.

Topological sorting orders the nodes of a directed acyclic graph such that every edge points from an earlier node to a later one in that ordering. It only works on a DAG, a graph with no cycles, since a cycle would make a valid linear ordering impossible. It's the exact algorithm behind resolving task dependencies, like determining a valid build order when some tasks depend on others finishing first.

Union-find efficiently tracks a collection of disjoint sets, supporting two operations, checking whether two elements belong to the same set, and merging two sets together, both in nearly constant time when implemented with path compression and union by rank. It's commonly used for cycle detection in Kruskal's algorithm and for problems asking about connected components in a graph.

A Bloom filter is a space-efficient probabilistic structure for testing whether an element might be in a set, using far less memory than a regular hash set at the cost of allowing false positives, saying an element might be present when it isn't, though never false negatives. It's the right tool when memory is genuinely tight and an occasional false positive is an acceptable trade-off, common in caching layers checking whether a value is worth looking up in a slower, more expensive store.

NP describes problems whose solution can be verified quickly, in polynomial time, once you're given one. NP-complete problems are the hardest problems within NP, and every other NP problem can be transformed into one of them. NP-hard problems are at least as hard as NP-complete problems but aren't necessarily even in NP themselves, meaning a proposed solution to an NP-hard problem might not even be quickly verifiable. Recognizing a problem as NP-hard in an interview context signals that an efficient, exact solution likely doesn't exist, and an approximate or heuristic approach is probably what's actually expected.

Say so explicitly, and pivot to discussing an approximation algorithm, a heuristic, or a solution that's efficient under some reasonable, stated constraint on the input, rather than continuing to search for an exact polynomial-time solution that almost certainly doesn't exist. Recognizing and naming NP-hardness is itself a meaningful signal of understanding, often more valuable to an interviewer than grinding uselessly toward an optimal solution that can't exist.

A hash-based structure gives faster average-case lookup, insertion, and deletion, all close to constant time, but offers no ordering at all. A tree-based structure like a balanced BST gives slightly slower O(log n) operations but maintains sorted order, supporting operations like finding the next-largest element or iterating in sorted order, which a hash-based structure simply can't do efficiently.

Beyond raw Big O complexity, I'd weigh actual access patterns (is it mostly reads, or a mix of reads and writes), whether eviction is needed once the cache reaches a size limit, and memory overhead per entry at real scale. A textbook-optimal data structure that carries too much memory overhead per entry can be the wrong practical choice once you're storing millions of entries, even if its asymptotic complexity looks best on paper.

A sliding window log or a token bucket algorithm are the two common approaches. A sliding window log can be implemented with a queue storing recent request timestamps, removing old ones as they fall outside the current window. A token bucket instead tracks a count of available tokens that refill at a fixed rate, which tends to be more memory-efficient at very high request volume since it doesn't need to store individual timestamps at all.

A trie is the natural fit, since it lets you efficiently find every word matching a given prefix by simply walking down the tree following the prefix's characters, then collecting everything reachable from that point. For ranking suggestions by relevance or popularity rather than just existence, each trie node would also need to track some additional ranking information alongside the basic structure.

A hash map for counting frequencies, combined with a min-heap of size k to track the current top k elements as you stream through the data, avoids ever needing to hold the full dataset or a fully sorted result in memory at once. This runs in O(n log k) time, meaningfully better than sorting the entire dataset by frequency when k is small relative to the total number of distinct elements.

Combine a hash map, mapping each value to its index in an array, with a dynamic array holding the actual values. Insertion appends to the array and records its index in the map. Deletion swaps the target element with the last element in the array before removing it, updating the map accordingly, avoiding the need to shift every subsequent element the way a plain deletion in the middle of an array would.

A B-tree keeps more keys per node than a binary tree, which means fewer levels for the same number of keys and, critically, fewer disk reads to traverse it, since each node read is a relatively expensive disk access rather than a cheap in-memory pointer dereference. This is exactly why databases use B-trees (or a close variant) for indexes rather than a plain binary search tree, since minimizing disk I/O matters far more than minimizing the raw number of comparisons for data that doesn't fit in memory.

Profile first to find where the actual time is going, rather than guessing based on which part of the code looks the most complex. Then look for a fundamentally better algorithmic approach, a better Big O complexity, before reaching for micro-optimizations within the existing approach, since a better algorithm almost always beats even heavily optimized code built on the wrong underlying approach.

I weigh how they approach an unfamiliar problem, do they clarify constraints and edge cases before jumping to code, do they recognize when their first approach won't scale and adjust, far more than whether they land the single most optimal solution immediately. A candidate who reasons clearly and asks good questions on a problem they haven't seen before is a stronger real-world signal than one who's simply memorized a similar problem's solution from prior practice.

I'd connect the dots explicitly, pointing out a real design decision they made and asking what data structure or algorithmic idea it actually maps back to, since the two skills can genuinely feel disconnected to someone who learned DSA mainly for interview prep rather than as a tool for solving real problems. Making that connection concrete and specific tends to stick far better than a general reminder that DSA matters.

I'd calibrate the bar to what the role genuinely requires day to day, favoring practical problem-solving and reasoning about trade-offs over a narrow focus on optimal algorithmic complexity for its own sake. A rigid, one-size-fits-all DSA bar across every role, regardless of what the job actually involves, tends to filter out strong candidates for reasons that have little to do with whether they'll actually succeed in the role.

Favor problems the candidate is unlikely to have seen before, or add a twist to a common problem that requires genuinely adapting the approach rather than reciting a memorized solution. Paying attention to how a candidate thinks out loud through an unfamiliar problem reveals far more about their actual reasoning ability than whether they've simply seen that exact problem before somewhere else.

I'd focus the discussion on specific, observable moments from the interview itself, how the candidate handled a hint, whether they caught their own mistake, how they reasoned about a trade-off, rather than a general gut feeling about the interview overall. Anchoring disagreement to concrete evidence from the actual conversation resolves it far faster than two people arguing from differing overall impressions.

It depends entirely on actual scale and real-world constraints, not the appeal of finding the theoretically optimal solution. A solution that's technically O(n^2) but runs comfortably within a system's real, bounded input size and performance requirements doesn't need further optimization just because a better complexity theoretically exists somewhere on paper.

I'd push for benchmarking against realistic data and realistic scale rather than settling the debate through theoretical argument alone, since a theoretically superior algorithm's real-world advantage can vary a lot depending on actual data characteristics, implementation details, and even hardware. Real numbers on real, representative data settle a genuine trade-off debate far more effectively than continued theoretical back and forth.

This is a judgment question interviewers use to see how you reason about a real trade-off, not to test a specific algorithmic fact. A strong answer names the actual constraint that mattered, why a simpler, less theoretically optimal approach was the right call in that specific context, or conversely why the added complexity of a more sophisticated approach was genuinely worth it, rather than defaulting to the more impressive-sounding option without a concrete reason behind the choice.

Staying involved in code review and technical design discussions keeps that knowledge genuinely applied rather than purely theoretical, even without writing algorithm-heavy code every day yourself. Occasionally working through a genuinely hard problem, whether through interviewing candidates or a real technical challenge that comes up, also keeps that reasoning muscle from going fully dormant over time.

I'd point to a concrete, already-happened example specific to the business, a feature that got noticeably faster or a cost that dropped significantly because of a better underlying data structure or algorithm choice, rather than defending algorithmic thinking as valuable in the abstract. A real, dollar-or-time-denominated before-and-after story lands far better with a non-technical audience than an argument about elegance or theoretical efficiency.

I'd translate the optimization into terms leadership already tracks: infrastructure cost that would drop, a specific performance complaint from customers that's already been raised, or a scaling ceiling the current approach is approaching that would otherwise force a much larger, more disruptive rewrite later. Framed as cost avoidance or risk reduction with a concrete number attached, it competes far better for prioritization than framed as a technical improvement for its own sake.