Re-Sharpening the Saw with Data Structures and Algorithms

Since AI entered my workflow, I solve fewer problems and write less code. I don't see that as a bad thing. I see it as an evolution of software engineering.

I went to Rocky Mountain Ruby this year (September 28 and 29, 2026), where one of the organizers, Spike, gave a lightning talk on this exact topic. He compared it to the shift when programmers no longer had to worry about manual memory management. Some people had built entire careers on that skill, and they had a choice to make: adjust to what the industry demanded, or go down with the ship. There's something ironic about refusing to learn something new in an industry that only exists because people kept learning.

A reset

I was recently let go from my previous role (maybe I'll write about that someday), and it triggered a kind of reset in my brain. Suddenly I was taking stock of what I know and don't know about software engineering.

I haven't physically written code in a long time (thanks, Claude). I also haven't physically typed a prompt to an AI agent in a few months (thanks, Wispr Flow). But as I work through interviews with various companies, I felt the need to intentionally re-sharpen some skills that may have dulled.

Eventually I'll find a way to practice interviewing that feels less awkward and contrived. (Maybe that's an app idea.)

Back to the algorithms

This post is about the more algorithm-y technical challenges, sometimes known as LeetCode within the industry. They tend to be pattern and math problems, where the hard part is the mental work of discovering the pattern rather than showing your work with equations.

I don't think I have the kind of brain that can solve these without a pencil and paper, but I keep returning to interviews from years past. One that stands out went something like this:

Given a 2D array where the inner array elements are 0s and 1s, where 0 is
water and 1 is land, return the size of the largest island.

Tip: diagonal 1s don't count as part of the same island.

e.g.
input = [[0,1,1,0], [1,0,1,0], [0,0,1,0]]
expected output = 4

I was given this exact question a few years ago, and I started solving it in the most TDD, beginner-programmer way possible (this was an interview for a Senior role). I even let my helper function decide that 0 was water and 1 was land, mostly to buy myself time. Eventually I told the interviewer I wasn't sure how to solve it, but that I'd love to spend the rest of our time pairing on a solution so I could make the most of the opportunity. Somehow, I got an offer from that company.

Learning in public

I'm slowly working through courses and problems on Neetcode, and I'm trying to post four times a week on Threads. I'm mostly a reader of social media, but I've always figured that if there was ever a time to #learninpublic, and to have someone tell me I'm wrong and give me tips, it's now.

Feel free to follow along. Here's my profile.