Many programmers think that the way DS&A work is that one beautiful spring morning, some requirements fall onto your lap where the words "nodes" and "edges" are neatly circled, thus marking a key moment in your life where you can finally put to use that old dusty algorithm book. Meanwhile, trees and graphs have been flying up to your face, slapping you left and right, every single day of your career and you kept repeating to yourself "see, you don't need all that DS&A stuff".

I think the article is unnecessarily trying to contrast two orthogonal and separately useful software development concerns. DS&A are about having the most efficient tools for the specific job. Testing is about ensuring that results match expectations. But I'd be surprised by anyone who only learns DS&A in theory and also naturally develops the related, but subtler skill of recognizing classes of problems that match up to particular algorithms. It's an almost tacit skill, which many programmers don't have despite knowing some of the classic DS&A, because it requires to linger a bit longer in the material. And that's the real gap leetcode type challenges try to bridge. The more you do them, the more you reinforce an intuitive understanding of involved structures and techniques, including some of the subtler properties and oft undocumented corner cases. What looks like "memorization" to some is actually more of an almost indelible grokking, which you carry with you in professional programming.

Admittedly, people who only do leetcode type challenges and never write software in the real world don't know which parts of these challenges are useless (in my opinion, the puzzles and lateral thinking parts). But people who never do these challenges also know squat about how useful they can be at honing one's "real life" problem solving and coding skills.

> ...unnecessarily trying to contrast two orthogonal and separately useful software development concerns.

> ...only do leetcode type challenges and never write software in the real world...

Respectfully, I agree with OC's point about testing vs implementation. (Both are programming.) It's been a (long) while since I've had peers who regularly, usefully tested their own work.

Like this OC, I too have struggled to articulate why leetcode has tiny IRL relevance.

How's this:

A useful distinction may be implementation vs usage.

Of course, a tiny handful of people are entrusted with implementing libraries of algorithms, so should be properly vetted for that work. Ditto crypto, parsing, and other misc arcane arts.

OC's point remains that leetcode hazing ignores the majority of actual work as a programmer. Such as fixing bugs, testing, modeling, documenting, enduring meetings, etc.

--

IIRC, I haven't implemented a sort algorithm, either in anger or for fun, since my BASIC & Pascal days. Why would I?

But I have recast real world problems as a Traveling Sales Person problems a handful of times.

As you well know, modeling using well known data structures, to enable using stock algorithms, is a big part of the job.

I'd rather interviews verified applicable skills. Such as data modeling, sequence diagrams, etc. And maybe some lightweight arch like (from the hip) caching, serialization, indexing, queuing and backpressure, locks, and validation (and whatever other bog standard stuff is immediately relevant).

--

(Oops: I did recently implement topo sort, just to understand it better, even though I was using a ready-baked solution. Just like +25 years ago I implemented (poorly) taboo, simulated annealing, etc. during my brief optimization kick.)