OP didn't go into detail about the problem, so we have no idea what the actual problem or solution was. Empirical research has found many people don't do well in high stakes problem solving situations while being watched (shocking).

Many people also don’t do well in high stakes problem solving situations even when not being watched.

I’m not suggesting OP is dumb, but if someone is setting hiring criteria and thinks they need X skillset judged by Y, I think there’s a good chance they’re directionally correct.

I get it, I’ve bombed interviews I was excited about and rationalized it anywhere and everywhere. Once I started hiring folks, my opinions evolved significantly.

How else do you hire someone out of a pool of people that are all knowledgeable and likable? A bad hire, even if they’re super smart and just the wrong fit, is worse than not hiring anyone at all.

If you climb the management ladder, you’ll likely be graded on your org’s hiring outcomes. If 10 people all seemed qualified, I’m going to burn down the risk as much as possible. If I’m wrong 1 time for this, but it not obviously wrong 9 others, I’ll call it a win.

For context: this is coming from tiny startups to billion dollar companies and different things in between.

What if there's solid evidence (e.g. visible work in open source) that all ten can code? The problem is not that coding interviews exist at all but that they're mandatory for all levels and roles. At L5+ coding isn't even the most important skill, so LC-style coding interviews introduce a risk of false negatives without providing any actually useful information. BTW those false negatives occur disproportionately for some demographics, and it only takes a single mention of "culture fit" to make one wonder if that's the whole point.

Normal programmers call the sort() method in their language of choice.

Call sort() to merge two sorted linked lists? (Which is what this sub-thread is discussing.)

I mean the bubblesort of a solution is to simply concentrate the two lists and call sort on the whole thing. And then move into the next ticket. If called out during code review, yell the words "premature optimization" repeatedly and then storm out.

That's for after you get the job though. During the interview you'll need to be a bit smarter and more practiced with algorithms.

It's a trick question. We would never use a linked list in the real world.

"What's a cache locality? Is it webscale?"

What domain of programming are you in that this is a common item of work you need to do?

I saw the question, and thought maybe the recruiter was being literal about it being a formality...

So I asked "is a naive implementation fine"? The answer was a quizzical "... well I guess we could start there? But we're probably going to need at least <insert Big O notation for time> and preferably get to <Big O notation for time and space>", so I wrote out a completely naive implementation and switched to questions.

-

But you're right, I can't program. Not memorizing elaborate cache-unfriendly vectorization-unfriendly algorithms has made me unhirable.

There was a reason they were excited to talk to me, and I thought it was an impressive career of programming to solve hard problems that started from writing assembly games for calculators in middle school... but who knows, maybe it was my charming smile?

Luckily my smile got me hired by a company that's paying me a FAANG salary but hasn't had to lay off thousands (knock on wood)

The problem is that if your company is routinely hiring people on their accolades (or just trust me bro) alone, you'll eventually end up with people who _can't_ merge linked-lists. The FAANG model of making people solve BS programming puzzles at least guarantees that a person is a try-hard or is capable of slinging some code, which its own issues aside is better than the baseline of charlatans who don't know anything. Outside of FAANGs I've routinely interacted with fairly senior engineers who just could not code, period, full stop. Maybe you can scale to 100s of engineers without the stupid interview gimmicks, but you won't hire 1000s engineers who _can_ actually code without ascertaining that they posses some logic, and if their rote memorization is so good as to be indistinguishable from general intelligence, so be it, they're passing the turing test :)

Who said it's accolades alone?

I hold myself to the standard of knowing enough the problem space before I interview people that I can open an editor and come up with domain specific problems that anyone who's doing what they claim they're doing daily can work through (crazy bar I know...)

> Outside of FAANGs I've routinely interacted with fairly senior engineers who just could not code, period, full stop

My first thought was "You must be joking if you think there are no L5s in FAANG who can't write code",but then I realized you actually think of writing code as literally being able to write statements in a given order... but that's such an insanely low bar that people regularly meet it by repeating problems over and over for a few months.

My bar for writing code at past a junior level is to be able to solve a problem with production grade code. LC almost precludes that between the time constraints and rigid solution set so people settle for "they wrote a guard statement against an empty list".

I just want to know that a new hire isn't going to ignore things like cache locality or not know what a memory mapped file is and try to load gigabytes of data into memory and parse the whole thing just to run their O(N) solution across 4kb of data.