> Expecting engineers to develop skills they don’t learn/use in their actual professions to prove they’re capable of working a job makes no sense.

I used to feel this way, but I think I’ve changed my mind. Interviews aren’t really primarily testing for skills you’ll use day to day, they’re testing for breadth of skills and knowledge and more importantly breadth of understanding. When I’m interviewing, knowing if the candidate has the specific skills for the job is the bare minimum needed to get in the door. I’m really more interested in potential, how much they can grow, and indicators of growth potential include how interested they are in the art of programming in it’s many different forms, whether it’s algorithms or math or software architecture, or coordinating people who write software. Puzzles are only the tiniest fraction of all that, but they’re still a signal that you like thinking about algorithms, and have exposure to different ways to write code and lots of algorithmic concepts.

A university CS degree isn’t particularly good at teaching job skills per se either, there isn’t much I use in my job day to day that I practiced in school, at a superficial level. But the school degree is pretty good at covering the broad concepts of computer science, and that has lasting value over the course of a software career.

How do these questions give you any indication that the candidate can do the essential job functions of shipping working code that is actually useful to your business and being a good teammate?

That question is impossible to answer. However, the negation is answerable. "Is the candidate incapable of the essential job function?" Questions like fizz-buzz, et. al. answer that readily.

Put up a job posting on a job board and you'll get hundreds of applications. 90% of those you're going to throw out because the resume doesn't match the job description at all. What does that tell you about the candidate pool? It's an all out assault of candidate spam. You have to employ these sorts of basic filters to even get the number of interviews you do down to a managable number.

What it tells you about the candidate pool may be less than what it tells you about the qualifications for the position. Job requirements in the computer industry routinely include nonsensical requirements (5 years experience in something that's been around 3 years, 2 years experience in each of 8 items for an entry level position, etc.)

This is endemic to the point where applying only for jobs where you fit the job description is a losing strategy.

And even if your own job posting isn't one of those, how is the applicant supposed to know you're one of the few employers who actually means what's in the job description?

This is a good question. However, there is nothing that will tell you this reliably aside from employing the person.

Most people who are smart and get things done will be capable of shipping code, if they can stay motivated. And that’s where having some signal about their interest can help. I want to know if people can inspire their teammates, not just get along, I want to know if they can lead by example, whether they’ll rise quickly, and whether they’ll love it for many years. The essential job functions are just plumbing, the important parts are more than that and aren’t demonstrated by evaluating for narrow, specific job skills.

Look, I don’t in a million years think grinding on Leetcode is some singular answer, or even particularly good. But I don’t see anything wrong with people who are interested doing it, and I also don’t see anything wrong with asking interview questions. I never put a huge weight on such algorithm questions, and there are a dozen other major interview categories. So there’s nothing wrong with asking a few algorithm theory questions, to see the bounds of what people know. I like getting into questions that people don’t know the answer to, whether it opens a conversation about what it means, or whether the candidate has no idea or doesn’t care, that is a small amount of useful signal to me.

If playing scales were actually relevant for a professional musician, then why do they have to spend time outside of concerts practicing them in order to get better?

Inverting a binary tree is nothing but basic pointer-chasing and recursion. Both skills that software engineers need.

It's like a chef complaining about being asked to make a fried egg. They might not be making that exact food in their job, but it's trivial for anyone proficient with the basic techniques that they need in their job.

I'll say it again -- if these skills were something software engineers needed, there wouldn't be a need for services like Leetcode because SWEs would just learn these skills at their jobs.

Reversing a tree is not a skill. It's a test of rudimentary experience working with fundamental data strutures. You are not expected to know the solution, but you are expected to produce one if asked.

"Leetcode puzzles"... jeez.

Again, if this "experience" so "rudimentary", why do top engineers spend time on leetcode trying to get better for interviews? Wouldn't this "rudimentary" experience be learned through their, you know, actual work experience?

Because these "top engineers" are self-taught with massive gaps in their base CS education? Reversing a tree tests for the knowledge of binary trees and recursion, which is... what?... a second year of a CS program, conservatively?

Go on Blind. There are plenty of engineers at top companies in the Bay Area talking about “grinding leet code” as a part of their job searches.