Ask HN: Why is tech hiring so focused on leetcode?

For context, I'm a pre-seed startup CTO and ex Googler who's probably conducted 50-100 interviews.

In short, "it gives some signal, it's easy, it requires less infra, and it's common so people won't criticize you for it".

- It gives some signal: I can generally rule out people who are clearly unable to write basic code (loops, good variable names, not getting lost while retracing code). In my experience, this camp accounts for some 80%+ of the people coming in for interviews, even at Google.

- It's easy: the up-front costs of asking a Leetcode-type question are low. As an interviewer, I can prepare for such an interview well with 2-3 hours of question searching and an hour or so of doing the question myself. Contrast this with "closer to real" interview questions, where you may create an entire "fake project" for candidates to work in which may get leaked. It could easily take 10-20 hours to think of a "right size project" with natural extensions for candidates, which is an eternity as a hiring manager that's hiring because they're strapped for time

- It requires less infra: you don't need any sort of "shared environment to see and run code", timers to ensure that people don't spend too long on take home questions. All you need is a shared notepad or white board

- It's common so people won't criticize you for it: "Nobody ever got fired for choosing Microsoft". These types of things have a self-perpetuating nature where people cargo cult what works for large successful companies.

I don't at all endorse asking these types of interview questions and agree that there are better ones, but I do think it's important to acknowledge there are real reasons why they get asked.

> where you may create an entire "fake project" for candidates to work in which may get leaked.

as opposed to entire companies created (read: interviewkickstart) that allow people to practice and memorize/study these types of questions in order to game the system? i'm not really sure how this provides any kind of signal other than that this person has the willpower and spend thousands of $$$ to sit through hours of mindnumbing LC practice. bleh.

> It's easy: the up-front costs of asking a Leetcode-type question are low.

sounds exactly like "we take the costs of interviewing and push it on the interviewers bc we are too lazy or don't find it important enough to prepare effective interviews so instead we expect that you waste hours after work and on weekends to study for our interviews."

no wonder blind has threads like "i am pipped everywhere i go but i can destroy LC interviews." the whole thing is setup for people like that to thrive. our industry is a joke in that perspective.

I agree LC sucks, but given the reasonable argument made by the parent it seems it is the least bad to a large extant.

Unless you have an idea for a better system? I mean interviewing isn't a value add activity, and so you wouldn't want expensive employees spending an enormous amount of time doing it, and if you hire a professional to just do that, congratulations you just invented the HR department, and putting them at the front of your hiring pipeline sucks for everyone involved.

Leetcode sucks but I'll take it any day because it at least means the person has some idea of how to evaluate the job in comparison to some HR drone that writes down I'm an experienced front end developer because I have 10 years experience in Java.

Agree as a fellow faangchad

I've been working on a blog post about that subject but basically. The most important feature of code in general is maintainability, the problem is maintainability is something that can really only be measured over a long time frame.

The other challenge is that most jobs don't need you to be that great of a developer they need you to be a decent developer and then it wouldn't matter if your Donald Knuth or Donald Rumsfeld you can perform within expectations.

So there isn't an easy way to really determine whether or not some produces lasting good work in a reasonable way in an interview, and you don't really need rockstar so much as you need people that can perform the minimum.

So you get crazy ideas that certain companies use and can use because they are making money hand over fist,and everyone assumes since that company is making so much money and hire people like that, that must be why they are making so much money, so they copy it in a cargo cult management fashion.

And if you think the leetcode is bad it at least has a tangential relation to development. You should've seen things back in the MS years when you'd have people ask you with a straight face "how many ice cream shops are in San Francisco?" "How many marbles can I fit in a bus?" "How many fields could our team fertilize using only what is produced in staff meetings?"

Stuff like that is even more annoying.

> ...the problem is maintainability is something that can really only be measured over a long time frame.

I think here are certain heuristics that can be used to examine this.

  - Review GitHub repos if the have them; see how they structure code in actual projects.  Yes, not everyone has a GH profile or spends time writing side projects, but if it is there, that's a great starting point.
  - Focus coding interviews on writing testable code and test cases
  - Observe how the candidate structures classes, functions, parameters; many simple decisions can affect maintainability; we even have standard measures like cyclomatic complexity that are objective indicators of maintainability.
  - Have them write something simple but meaningfully complete as take home and see how they comment, document, organize, and explain their code

> So there isn't an easy way to really determine whether or not some produces lasting good work in a reasonable way in an interview, and you don't really need rockstar

Is writing maintainable code a hallmark of rockstars?

> Observe how the candidate structures classes, functions, parameters;

How long must be a project to be able to see how good is the interviewed choosing classes, functions, parameters?

For a two hours project, I may write it in a single pass. Perhaps some small auxiliary functions. Do I have to add docstrings? Make it a three hour project. For test cases give me another hour.

I think that leetcode-style interviews probably used to be more useful/more predictive when they weren't super common. Also, if you're one of the most-desirable employers in the market [as Google was at the time it popularized this type of interview], nearly any aggressive interview strategy will be at least moderately effective, as the most dedicated candidates will invest lots of effort in preparation for your interview specifically, and if you reject tons of candidates that would have been effective, it costs you ~nothing, since, as a top target for candidates, you'd never run out of top talent to hire.

Google also had an initial product which was primarily based around having a really good algorithm. Actually, several of their top early internal products also were about solving difficult problems with interesting and novel algorithms -- which gave them a huge bias in terms of what they were seeking.

Of course, at Google's scale and popularity, books were literally published about their interviews and both how to pass them and how great they were -- so naturally others who either were or wanted to be top-of-market adopted similar strategies. Lots of top companies also had Ex-Googler founders or early hires, which helped perpetuate the familiar structures throughout the industry.

For myself, I really dislike leetcode-style interviews. I think there is some value in asking, say, two different leetcode easy problems to verify that the candidate can produce reasonable code samples, and that they can express their ideas in code (and hopefully, also, verbally either while they code or in response to probing questions from the interviewer).

The argument is if you can leetcode, you can learn everything that is in TS list