Hacker News Reader

Comment by commandlinefan | Hacker News Reader

It seems like a lot of these discussions end up being something along the lines of "the standards are bad because they exclude me, therefore there shouldn't be any standards at all" (just with a lot more words).

View on HN

The standards (e.g. algorithmic questions) are bad because

A) they're only tangentially related to the work, meaning they include bad hires and exclude good hires

B) they put a huge workload on employees who must practice tens or hundreds of hours of underwater basket weaving, time which would be better spent doing almost anything else

C) they systemically exclude anyone who can't play the dumb game due to a lack of time, including but not limited to older people and poorer people

> A) they're only tangentially related to the work, meaning they include bad hires and exclude good hires

And that's the reason many companies have to set the standards so high in the first place: excluding false positives (bad hires) is so important in practice that this distorts the whole hiring process. Fine as far as that goes of course, but it does mean that people who practice their leetcode questions are basically stuck with very expensive (per B and C) lottery tickets.

I think everyone knows at this point that algorithmic puzzles are not desirable; the real question is whether one can do better, even at FAANG scale.

Puzzles no, but it really matters how candidates are evaluated on coding.

For coding, if a coding question boils down to implementing KMP string matching or something that's only realistically solvable by memorizing the entire algorithm and writing it out on a whiteboard, then it's not any different than any of the puzzle type questions like "why are manholes round?"

The proper way to evaluate coding questions, and what is mentioned in the article, is that one is evaluating general intelligence in the context of software programming. Is the candidate coming up with a reasonable solution? Are they asking questions to understand the problem better? If they get stumped by something, do they stay stuck on it, ask for help, or think through it? Can they find the issues with their code and improve on it?

I haven't heard of a better way to interview engineers, but if there is I'm definitely all ears.

I agree the standards are bad, for senior devs in particular. In addition to your points:

Technical understanding of systems in general (networking, CAP, testing, writing maintainable code) are all overlooked in the interview process, though these are what actually make a developer productive.

The older you get the more specialized and optimized you are to learning what matters, which is why most of the older guys suck at these types of interviews.

Imagine interviewing Brendan Gregg by giving him some leetcode problems!

That's a very good summary. Discerning what truly matters is really the mark of experience. And you're right, algorithm memorization doesn't fit in the top-50 of what matters for a software engineer.

I went to CMU, enjoyed algorithms classes a lot. In the nearly 30-year career since, I've used that knowledge... never. Not once.

It's not about the interview bar being too high. It should be high, mine is. But interviews based on algorithm memorization have the bar in the wrong place, measuring something that has no real-world relevance.

I think of "the bar" as being basically our industry's equivalent to a law degree: it's just a way to show that you have some foundational knowledge in the subject, even if it bears little resemblance to day-to-day work. All of the flaws you enumerated could also apply to law school, but at least "the bar" is reasonably accessible and doesn't cost hundreds of thousands of dollars.

The annoying thing is that with the bar exam, there is a clearly defined test with criteria. Whereas what you have in the software industry is a vaguely-defined set of expectations that vary widely. There's no standard.

Definitely agree with you there. I wonder how far we are from some kind of standardization. Lots of startups are already in this space, but if a few FAANG companies adopted a common standard it wouldn't be long before a large share of the industry followed suit.

ctci and leetcode seem to be the unofficial standard tbh

Yes well except you forgot that lawyers pass the bar once and don’t have to redo randomized exams over and over in under 45 minutes. My lawyer friends are making 160$/h and their interview efforts were an hour discussion with a few lunch meetings.

Not only the law degree is a standard exam, but you only have to pass it once not ten times in your career.

Most of the criticism probably should be articulated again to probe whether these standards are realistically something one can work towards.

If we’re out of the running no matter how much you practice, no matter how much job experience, and if there really is this mysterious value G, with the right combination of Ivy League CS program, then I can see how these discussions mirror the notion of ‘the bar’ - that is, a forgone conclusion.

You could start a company and hire people on other standards, and I suspect it would work, as long as the "other standards" are painful in the same way as the current ones. For example, you could require candidates to learn ten pages of Chinese poetry by heart, or anything else that tests their ability to keep their mind on-task for long stretches of time. In my experience, people with that ability can become good programmers if they're inclined to.

What won't work though is hiring based on only past experience. The bullshitters will eat you alive. You really do need some kind of "underwater basket weaving" as a test.

Reply on news.ycombinator.com