Comment by tombert | Hacker News Reader

Comment by tombert | Hacker News Reader

Parent Full thread

> I haven't heard of any interview method that wasn't roundly condemned on HN.

Sure, but none have been more thoroughly condemned (and correctly) than the idiotic leetcode whiteboard challenges.

> And you wouldn't be wasting your time on candidates who: 1. don't know what a hashmap or minheap is 2. didn't bother to study up before the interview

OR, and hear me out, you actively filter out people who know how stupid these problems are and know that big-O is misleading for a lot of these problems. You're selection-biasing towards people who are going to regurgitate bad answers, and the middle manager conducting the interviews is usually too incompetent to understand what a "constant factor" is.

I've been rejected for jobs specifically because I mention that using a hashmap for these things will likely be slower than a naive implementation, even when the I get the problem "right" in the way that they wanted it.

Now we could argue that I'm a bad candidate in general, but (at the risk of sounding cocky) I likely do understand data structures and algorithms better than most mediocre engineers conducting the interview, but because most engineers are pretty uninspired and have never asked "why" for anything in their lives, they will "correct" me. They will assume that me providing nuance is a lack of understanding on my end.

> A quick check shows that Google, Microsoft, Nvidia, Meta, Apple, Anthropic all do leetcode testing.

Yep, can confirm. I've worked at a FAANG, and they did indeed leetcode testing for the interview. It turns out that big corporations are fully capable of doing stupid things in perpetuity.

I appreciate that, but my whole life I've heard again and again and again that "high stakes testing" does not work. I've heard all the arguments. But the bottom line is the testing is an effective filter.

After all, would you get on a jetliner piloted by a handsome fellow with a firm handshake who failed to pass all the written tests, but really knows how to fly?

It's not that hard to study the leetcode books. Doesn't the prize of a top shelf salary make it worthwhile? It's a good investment in your career.

Person that can fly every time - Diana Barnato Walker flew 80 types of aircraft before finally getting a commercial flying licence.

I'm sure she passed the written tests.

My dad flew 23 airplane types - single engine, multi engine, 2 wings, 1 wing, bombers, fighters, jets, and piston engines. In his papers I found some of the written exams he had to pass to get certified to fly them. Just "knowing how to fly" is a good way to get yourself killed.

There was one incident where his F-86 Saber jet had its engine quit. He was faced with the choice of bailing out or gliding back to base. Having passed the written test, he knew how to calculate the best gliding angle, the best velocity, the best configuration of the airplane, took into account the wind, the altitude, and the weight, and figured he could bring the bird in. Which he did, safely.

All that boring stuff that requires study and it has to reside in your brain.

> It's not that hard to study the leetcode books. Doesn't the prize of a top shelf salary make it worthwhile? It's a good investment in your career

You are arguing two different points here.

I am, generally speaking, reasonably good at the leetcode stuff, because I agree that it’s not that hard to get good at it. As a practical thing for society as it currently is, sure, studying up on the idiotic leetcode stuff is a relatively good investment.

But that pays little bearing on whether leetcode is a good test, and whether it should be something that we are using as a metric. I am arguing that it’s a dumb test and we should stop doing it at a systemic level.

> But that pays little bearing on whether leetcode is a good test, and whether it should be something that we are using as a metric. I am arguing that it’s a dumb test and we should stop doing it at a systemic level.

Would you feel differently if you owned the company, and you'd be paying the salary for months for someone who talked a good game but was incompetent?

We are at an impasse here, because I do not accept the premise that the leetcode tests realistically gauge competency or serve as an effective filter.

In your hypothetical the implication is that the leetcode would be effective at removing people who “talked a big game but are incompetent”. I disagree with that.

I could be wrong about leetcode, but for me to realistically engage with your argument would be a tacit agreement with the premise, and I cannot engage with that in good faith.

Not really. I'm typically less concerned with how much someone costs than I am with how much time they'll wind up wasting, but I'll admit that this perspective is colored by my experience having run a kitchen in a restaurant.

The secondary challenge in the kitchen (beyond the challenge of hiring someone who'll simply show up when scheduled, ha) is hiring someone who has a genuine interest in cooking as a craft. It's true that being a line cook isn't especially glamorous work, but I absolutely need someone who has enough love for it that they're proud to show off what they can cook when it isn't my menu.

I interviewed someone who made nothing but scrambled eggs, hash browns, and grits, but they were cooked and seasoned to absolute perfection. This individual was one of my slower line cooks starting out, but the fact they had the drive to learn this level of cooking was good enough for me to invest time in them to improve that speed.

I look for the same love for the craft in software. Literally everyone who's worth their salt has something they've worked on that they will happily show off, or some technique (like, e.g., abusing generics to implement monads in Ada and why this is more interesting than the typical approach using interfaces), or some pet data structure (e.g., critical bit trees and what their pathologies look like vis-à-vis hash tables) that they try to shoehorn into everything, or some bit of code they've read (e.g., SQLite and the Tcl interpreter) that left a lasting impression on their practice.

There's a snag though: being worth one's salt only starts at being able to cut code. I need to witness a candidate write about and walk me through that very technical aspect of the craft that they want to show off.

Assessing craft requires interviewers who understand craft, and the literal only reasons I can see for using LeetCode are when the interviewer is themselves not an expert in the domain (perhaps for reasons of scale, among others), the interviewer cannot (or will not) engage in heavily technical conversation with a candidate, or the job is plainly not about writing software that works.

The trouble with untrained craftsmen is they are not aware of what they do not know about the craft. For example, I recall working on a codebase where the craftsman used bubblesorts in multiple places, evidently unaware of qsort(). I fixed that, and the program got a lot faster.

The role of an engineering degree is to teach you the things you should know about engineering. And an engineer should understand data structures and algorithms.

Forgive me. Did I advocate for not understanding data structures and algorithms?

Reply on news.ycombinator.com