The Matrix Mindset: Writing Clean, Readable Solutions in Interviews

The Quest Begins (The "Why")

I still remember my first technical interview like it was yesterday. The interviewer slid over a whiteboard marker and said, “Given an array of integers, return the largest sum you can get by picking numbers that aren’t next to each other.” My brain instantly went into overdrive. I started scribbling a recursive solution, then a DP table, then a mess of nested loops that looked like I’d tried to translate Inception into code. After fifteen minutes of frantic erasing, I looked up and saw the interviewer’s polite smile fading into a “let’s move on” vibe.

That moment stung—not because I failed, but because I realized I’d been solving the problem the wrong way. I was focused on getting any answer instead of communicating a clear thought process. In an interview, the code you write is a conversation. If the reader has to decode your intent, you’ve already lost points before they even test edge cases.

I went home, opened a notebook, and asked myself: What do the top candidates do differently? They don’t just know algorithms; they have a mental framework that turns a tangled problem into a short, readable story. That’s what I’m going to share with you today.

The Revelation (The Insight)

The breakthrough came when I stopped thinking about “how to compute the answer” and started asking, “What information do I actually need to carry forward at each step?”

For the house‑robber‑style problem (max sum of non‑adjacent numbers), the answer at position i depends only on two things:

1. The best sum including the current element (incl).
2. The best sum excluding the current element (excl).

That’s it. You don’t need an entire array, you don’t need recursion, and you certainly don’t need to mutate the input. You just update those two variables as you walk through the list.

The “aha!” moment was realizing that the problem isn’t about building a table; it’s about maintaining a state that tells the story of the best possible outcome so far. Once I saw that, the solution fell into place like a puzzle piece snapping into its correct spot—no more guesswork, no more sprawling code.

Wielding the Power (Code & Examples)

The Struggle: A Before‑Snapshot

Here’s what my first attempt looked like (spoiler: it’s hard to follow):

function maxNonAdjacentSum(nums) {
  // memoization map – unclear what the keys mean
  const memo = new Map();

  function rob(i) {
    if (i < 0) return 0;
    if (memo.has(i)) return memo.get(i);

    // take current + best from i-2
    const take = nums[i] + rob(i - 2);
    // skip current + best from i-1
    const skip = rob(i - 1);

    const best = Math.max(take, skip);
    memo.set(i, best);
    return best;
  }

  return rob(nums.length - 1);
}

Why this feels clunky:

• The helper rob hides the core idea behind recursion and a memo map.
• Variable names like take and skip are fine, but the reader has to keep track of two separate calls and a map that isn’t obvious.
• Edge‑case handling (i < 0) is buried inside the recursion, making the flow harder to follow.

The Victory: After‑Snapshot

Now, applying the “state‑only” mindset:

/**
 * Returns the maximum sum of non‑adjacent numbers.
 * Runs in O(n) time and O(1) extra space.
 *
 * @param {number[]} nums - input array (can contain negatives)
 * @return {number}
 */
function maxNonAdjacentSum(nums) {
  let incl = 0; // best sum that includes the previous element
  let excl = 0; // best sum that excludes the previous element

  for (const val of nums) {
    // If we take this element, we must add it to the previous excl
    const newIncl = excl + val;
    // If we skip it, we keep the better of incl or excl from last step
    const newExcl = Math.max(incl, excl);

    incl = newIncl;
    excl = newExcl;
  }

  // The answer is the better of including or excluding the last element
  return Math.max(incl, excl);
}

What changed?

• Intent is explicit: incl and excl are named after the states we’re tracking.
• No extra data structures: Just two scalars, constant space.
• Linear scan: The loop reads like a story—“for each number, decide whether to take it or skip it.”
• Edge cases handled naturally: Starting both at zero works for empty arrays, all‑negative numbers, etc.

Traps to Avoid (The “Boss Fight” Moments)

Even with the right mindset, it’s easy to slip back into old habits. Here are two common pitfalls I’ve seen (and fallen into myself):

1. Trying to “optimize” too early.
   
   Some candidates start by allocating a DP array of size n, then later try to shrink it to two variables. The extra array distracts the reader and wastes time. Tip: Write the two‑variable version first; if you need to prove correctness, you can always explain the DP intuition afterward.

2. Mutating the input.
   
   A tempting shortcut is to store the running total directly in nums[i]. While it saves space, it makes the function side‑effectful and harder to reason about—especially if the interviewer later asks, “What if I need the original array later?” Tip: Treat the input as read‑only unless the problem explicitly says you can modify it.

Think of these traps like the surprise attacks in a Dark Souls boss fight: you see them coming, you prepare, and you avoid taking unnecessary damage.

Why This New Power Matters

Adopting this “state‑first” mindset does more than make your interview code look pretty—it transforms how you approach any algorithmic challenge.

• You write faster. No more fiddling with memo tables or recursion depth; you focus on the minimal information needed.
• You communicate clearer. Interviewers can follow your thought process in real time, which often earns you extra points for “clarity of explanation.”
• You debug easier. With only two variables to watch, you can quickly verify invariants (incl never exceeds excl + current, etc.).
• It scales. The same idea works for problems like maximum subarray (Kadane’s), longest increasing subsequence (patience sorting variant), or even DP on trees—you just identify the right state to carry forward.

In short, you stop fighting the problem and start dancing with it.

Your Turn

Here’s a quick challenge to test your new power:

Given a string s, return the length of the longest substring without repeating characters.

(Yes, the classic “longest substring without repeating characters” problem.)

Try to solve it using only two pointers and a set (or an array) that tracks the current window. Focus on naming your variables to reflect the state you’re maintaining (e.g., start, end, seen).

When you’ve got a solution, drop it in the comments or tweet it with #MatrixMindset—I’d love to see how you framed the state!

Remember: the goal isn’t just to get the right answer; it’s to tell a story that anyone can follow. Happy coding, and may your next interview feel like finally seeing the code behind the Matrix. 🚀