"Just Use a Library": The Most Expensive Mindset Trap in Software

I came across a comment that went roughly like this:

"Those LeetCode/algorithm questions in interviews are basically hazing. In real work, who actually sits there grinding out an optimized recursive solution? It's all just existing libraries anyway."

And I'll say it straight: this person is right. And precisely because they're right, their conclusion is dangerous.

This isn't a cute "half right". It's the kind of half-truth that leads directly to websites that load slowly, fall over when real customers show up, and eat dozens of times more hosting budget than they need to. Let me show you where the trap is.

The part that's right: no, nobody rewrites quicksort

Let me start with honesty, because I used to think exactly the same.

Years ago I also saw inverting binary trees and optimizing recursion as theater. In real work you import a library, call the built-in sort, use an ORM to query the database. You don't re-implement sorting algorithms or hand-build a red-black tree. That's 100% true for the vast majority of day-to-day web, app and CRUD work.

And it goes further: the LeetCode interview ritual itself genuinely has problems. On this point I'm with the commenter.

interviewing.io's research on roughly 700 candidates found that LeetCode ratings and contest scores have almost no correlation with actual interview performance. The number of problems solved correlated at just 0.27 — weak. In other words, grinding contest points doesn't prove you're a good engineer.

The classic example: Max Howell, creator of Homebrew — software that, in his own words, "90% of your engineers use" at Google — was turned down by Google because he couldn't invert a binary tree on a whiteboard. His tweet became Exhibit A in a whole backlash against whiteboard interviews.

And there's a lesser-known study I find the most telling: Behroozi et al. at NC State had 48 candidates solve the same problem. The group watched by an interviewer failed 61.5% of the time, while the group solving in private failed only 36.3%. So the whiteboard is largely measuring how well you handle being watched, not technical ability.

If this post stopped here, I'd agree with the commenter completely. But this is where they slip.

The trap: confusing the problem being tested with the skill being tested

The commenter's conclusion: since the job is just using libraries, algorithmic thinking is useless.

That's a bait-and-switch. An algorithm interview — done well — doesn't expect you to write optimized recursion at work. It uses the problem as a proxy to measure three things:

1. Problem decomposition — breaking a big, vague problem into small, solvable steps.
2. Understanding complexity and trade-offs — knowing this is fast, that eats memory, and why.
3. Debugging under pressure and explaining your own reasoning.

Look at number 2. That's the link "just use a library" cuts in the wrong place.

"Just use an existing library" doesn't remove the need for algorithmic thinking. It moves that need somewhere else — somewhere far more expensive if you can't see it.

Precisely because you're not writing the algorithm yourself, you need to know even more:

• Which data structure should you use — a Set or an array? Get that wrong and a lookup loop goes from O(n) to O(n²).
• Why is your product listing page fast in testing but crawling in production?
• Why does one missing database index make a query a hundred times slower?

You don't write the algorithms. You choose and debug algorithms someone else wrote. And to choose well, you need exactly the kind of thinking the LeetCode question is trying to measure — it just measures it clumsily.

The most expensive "invisible bug" I've seen: the N+1 query

Here's an everyday example you don't need to code to understand.

There's a classic bug called the N+1 query. It happens when your code runs one query to fetch a list (say, 20 products), then runs a separate query for each product to fetch related data. 20 products become 21 queries. 5,000 products become 5,001.

What makes it nasty, as the technical write-ups describe, is that on a developer's machine with 5 records it runs perfectly and nobody notices. In production with 5,000 records, it turns a 100ms page into a 10-second one — and on cloud infrastructure billed by CPU milliseconds, it can make your hosting bill up to 50 times more expensive.

Who causes this bug? Usually someone who "just uses the ORM" without understanding how many queries each call actually fires off. The library is all there. But without complexity thinking, the library becomes a gun pointed at your own foot.

The consequences aren't abstract either. One analysis of production incident costs shows that just 22 minutes of degraded payments at a company doing $15M a month in revenue cost $25,592. Bugs like this almost always trace back to someone not seeing the hidden cost behind an innocent-looking line of code.

For a website owner, this isn't just a developer problem

You don't code? Fine. Here's why you should still care.

That "10 seconds" above isn't a technical detail — it's revenue evaporating. The 2025 numbers are clear:

• 53% of mobile users leave if a page takes longer than 3 seconds to load (source).
• Conversion rates drop by roughly 4.42% for every extra second of load time in the 0–5 second range.
• Pages that load in 1 second convert 3x better than pages that load in 5.

Now re-read the N+1 story: one "use the library without understanding the complexity" decision turned 100ms into 10 seconds. Put that next to the numbers above and you see what it means for your bottom line. Your website can run perfectly in the demo and bleed revenue once real customers arrive. The difference is the thinking of the person who built it — invisible until it's too late.

This is exactly the work I do in SEO & performance optimization: not rewriting algorithms, but spotting where complexity thinking got skipped and fixing it.

The paradox: AI makes this thinking more important, not less

This is the most counterintuitive part, and the reason the whole debate is getting turned on its head.

The popular argument: "AI writes the code now, there's a library for everything, who still needs to understand algorithms?" It sounds very reasonable. It's wrong.

Stack Overflow's 2025 Developer Survey of more than 49,000 developers found:

• 84% use or plan to use AI tools — up from 76% the year before.
• But 46% don't trust the accuracy of AI output — a sharp jump from 31% in 2024.
• And the most important number: 66% say they're spending more time fixing AI code that is "almost right, but not quite".

See what's happening? AI has taken over the easy part — gluing libraries together, writing boilerplate. The part the commenter thought was "the whole job" is something a machine can already do.

What's left for humans is the hardest and most expensive part: judging where that "almost right" code will break, slow down, or blow up memory in production. And that judgment is complexity thinking — exactly what the LeetCode question, clumsy as it is, is trying to measure.

Put another way: the better AI gets at gluing libraries together, the more valuable the person who knows when the library breaks. Someone who just pastes AI code without being able to vet it is someone about to plant an N+1 time bomb.

So what do you do with this? A practical lens

Skip grinding 500 LeetCode problems — the research above suggests around 500 problems is the point of diminishing returns, and grinding beyond that is nearly useless. What's worth investing in is the thinking, not the problem count.

If you're hiring a web team (and you don't code): don't ask "which frameworks do you know?" Anyone can list those. Ask questions that reveal complexity thinking:

• "When our data grows from 100 to 100,000 records, which page slows down first, and how would you handle it?"
• "Do you test performance on real data, or only on demo data?"
• "If you use AI to write code, how do you vet it before it goes to production?"

Someone who "just glues things together" will hedge. Someone with the thinking will answer immediately, with concrete examples.

If you're a developer: don't grind algorithms to show off. Learn enough to read the hidden cost of a line of code. Understand Big-O well enough to know which nested loop will explode. Know why your query is slow. That's the 20% of algorithm knowledge that delivers 80% of the practical value — and none of it involves inverting a binary tree on a whiteboard.

Bottom line

The commenter is right that you rarely write algorithms by hand, and the LeetCode interview ritual really is overused. If it stopped there, I'd nod along.

But the conclusion "so it's useless, just hazing" is wrong — and wrong in an expensive way. The skill being tested (seeing complexity, choosing the right tool, knowing when it breaks) still transfers even when the specific problem doesn't. It just shifts from "writing algorithms" to "choosing and vetting algorithms" — and in an era where AI writes the code, that's the most valuable skill humans have left.

A website that's fast, scales, and doesn't burn money on hosting doesn't come from knowing lots of libraries. It comes from understanding the hidden cost behind every line of code — whether that line was written by you, by a library, or by an AI.

If your website is getting slower as it grows, or you suspect it's carrying a few N+1-style time bombs, let's talk. That kind of "hidden complexity" is exactly what I go looking for.

---

Sources:

• How well do LeetCode ratings predict interview performance? — interviewing.io
• Does Stress Impact Technical Interview Performance? — Behroozi et al., NC State (FSE 2020)
• Max Howell / Homebrew — original tweet
• What is the N+1 Query Problem — PlanetScale
• How to Calculate the Real Cost of a Production Incident — Medium
• Website Load Time Statistics 2025 — Envisage Digital
• Stack Overflow 2025 Developer Survey: trust in AI at an all-time low — Stack Overflow