7 ms·

Leetcode measures nothing but your most basic understanding of a languages syntax, and your ability to memorize leetcode questions and common interview algorith

Leetcode measures nothing but your most basic understanding of a languages syntax, and your ability to memorize leetcode questions and common interview algorithms. The only people to ever write a merge sort are either in/preparing for an interview, and John von Neumann. If someone can fizzbuzz with a for loop, recursion, and a list comprehension, they probably know enough of that language to do your junior/mid-level job. If they get a problem they don't know, throw their hands in the air, slam their desk, and start crying, you may not want to work with them. That should be the goal of interviews. Not flexing obscure language details or academics. You need to see if you can tolerate/enjoy working with this person, and how they handle a problem they don't understand. More time on the job is spent trying to figure out why this API isn't working, and discussing solutions, than writing sorting algorithms

jollybean 5y ago
It measures the most important thing, which is the ability of people to actually write coherent code, a skill which is lacking among many devs. and which is the most important artifact (of many) of an Eng. ... "Most of the time in the interview, though, should be spent letting the candidate prove that they can write code." - Joel Spoolsky, the Guerrilla Guide to Interviewing ... " If they get a problem they don't know, " Well they should be leeting on something at least a tiny bit novel in the first place, not over the top algorithms, but something that requires a bit of thought. No trick questions needed, just something a bit open ended. [1] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
- wildrhythms 5y ago
  If Leetcode is solely measuring the lowest bar, what does that say about the people the company is looking to hire? I guarantee an engineer sitting down with a candidate for just 15 mins will gather way more impactful, insightful, accurate hiring information than any hours-long Leetcode obstacle course ever has or ever could.
  - bennyelv 5y ago
    Unless that engineer gets them to write some code in that 15 minutes, you're fundamentally wrong. An hours long leetcode assessment is not the answer, but you need the candidate to have provide proof that they can actually code, and "having a chat about it" doesn't prove it. You need them to write some code AND have a chat about stuff.
    - adwww 5y ago
      I'm yet to meet anyone that can talk at a high technical level for 45 minutes about any subject, without actually knowing something about that subject. I couldn't bluff my way through an interview with a senior C sharp developer, and if I'm interviewing a Go or Typescript dev I can tell within about 2 minutes if they actually know the language, and within about 10 how well they know it. I'm not sure what else the practical code test tells me, apart from how much spare time they have.
      - jollybean 5y ago
        "yet to meet anyone that can talk at a high technical level for 45 minutes about any subject, without actually knowing something about that subject." You're not getting the point. There are plenty of people with years of developer experience who can talk about things for 45 minutes, quite thoughtfully - and are still terrible developers. Talking about music is not making music. Nobody has the ability to judge the quality of a developer after only 10 minutes of talking to them about Typescript. Knowing some arcane things about Typescript is not a measure of problem solving or coding ability. "I'm not sure what else the practical code test tells me, " It tells you something more important than how much they've read up about Typescript. Typescript is simple / accessible enough, that I wouldn't even care if someone was familiar with it. I wouldn't even make it a requirement for the job even it was a TS focused job. I would take a 'great all around dev.' any day over someone I knew to be very knowledgeable about TS but otherwise big question marks about their development ability. Of course, the same holds true for memorizing algorithms - it's a nice signal that someone can do some fancy B-Tree stuff off the top of their head, but not really what you are looking for so interviews shouldn't be focused on that. Typescript and most of it's best practices (most of the odd corners of TS are not important), can be taught very quickly to any decent dev.
rufus_foreman 5y ago
>> Leetcode measures nothing but your most basic understanding of a languages syntax, and your ability to memorize leetcode questions and common interview algorithms. 90 something percent of people on earth will never be able to do any of that.
- brailsafe 5y ago
  90% of people on earth also aren't programmers of any kind
  - rufus_foreman 5y ago
    Yeah. So 90 plus percent of people aren't going to be able to do anything like that. Hell 90% of the people who call them selves programmers can't code.
carnitine 5y ago
What do you think of Google’s process then, where interview questions are constantly refreshed and removed if they’re found to be leaked? I think the weakest form of these style of interviews (boring CRUD companies asking how to find a loop in a linked list) are used to argue against all algorithmic interviews.
- wldlyinaccurate 5y ago
  Google's interview process lends itself to finding people who really want to work at Google. Nobody would go through that process to work for a small unknown company, even for the same total compensation.
908B64B197 5y ago
> If someone can fizzbuzz with a for loop, recursion, and a list comprehension, they probably know enough of that language to do your junior/mid-level job. If they get a problem they don't know, throw their hands in the air, slam their desk, and start crying, you may not want to work with them. That's setting the bar pretty low. If the candidate is from a serious institution he should be able to manipulate more complex data structures.
Zababa 5y ago
> The only people to ever write a merge sort are either in/preparing for an interview, and John von Neumann. Do you mean "for the first time and without errors"? I assume that most people should be able to give an overview of how a merge-sort works, and a pseudocode implementation.
- brailsafe 5y ago
  Why? It's really only in those contexts that's it's necessary to have it on hand. Unless you're in the context of needing it on-hand, it's trivia.
  - Zababa 5y ago
    I wouldn't call it "trivia" but "fundamental knowledge". If the person you're interviewing went through college it should be easy. If they didn't, they probably read about it somewhere (or should have) and can describe it to you.
    - brailsafe 5y ago
      It's not as much a question to me of whether they've ever seen it, wrote it, or studied it, it's whether they know off the top of their head even which one it is or what the implementation looks like.
    - jjav 5y ago
      > I wouldn't call it "trivia" but "fundamental knowledge". Something that will never be needed in a career can hardly be called "fundamental knowledge". I don't remember anything about how merge sort works. If someone wanted to interview me on that, they'd convince themselves I can't code, despite decades of delivering production code. > If the person you're interviewing went through college it should be easy. I did study CS in university. A very top CS school, even (CMU). Probably I must've studied merge sort at some point, but the last algorithms class I took at CMU was almost 30 years ago. Not once have I needed that info since then, so it's long long forgotten. Its relevance to a software engineering career is nil.
- 5y ago

jollybean 5y ago

It measures the most important thing, which is the ability of people to actually write coherent code, a skill which is lacking among many devs. and which is the most important artifact (of many) of an Eng. ... "Most of the time in the interview, though, should be spent letting the candidate prove that they can write code." - Joel Spoolsky, the Guerrilla Guide to Interviewing ... " If they get a problem they don't know, " Well they should be leeting on something at least a tiny bit novel in the first place, not over the top algorithms, but something that requires a bit of thought. No trick questions needed, just something a bit open ended. [1] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/ https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

wildrhythms 5y ago
If Leetcode is solely measuring the lowest bar, what does that say about the people the company is looking to hire? I guarantee an engineer sitting down with a candidate for just 15 mins will gather way more impactful, insightful, accurate hiring information than any hours-long Leetcode obstacle course ever has or ever could.
- bennyelv 5y ago
  Unless that engineer gets them to write some code in that 15 minutes, you're fundamentally wrong. An hours long leetcode assessment is not the answer, but you need the candidate to have provide proof that they can actually code, and "having a chat about it" doesn't prove it. You need them to write some code AND have a chat about stuff.
  - adwww 5y ago
    I'm yet to meet anyone that can talk at a high technical level for 45 minutes about any subject, without actually knowing something about that subject. I couldn't bluff my way through an interview with a senior C sharp developer, and if I'm interviewing a Go or Typescript dev I can tell within about 2 minutes if they actually know the language, and within about 10 how well they know it. I'm not sure what else the practical code test tells me, apart from how much spare time they have.
    - jollybean 5y ago
      "yet to meet anyone that can talk at a high technical level for 45 minutes about any subject, without actually knowing something about that subject." You're not getting the point. There are plenty of people with years of developer experience who can talk about things for 45 minutes, quite thoughtfully - and are still terrible developers. Talking about music is not making music. Nobody has the ability to judge the quality of a developer after only 10 minutes of talking to them about Typescript. Knowing some arcane things about Typescript is not a measure of problem solving or coding ability. "I'm not sure what else the practical code test tells me, " It tells you something more important than how much they've read up about Typescript. Typescript is simple / accessible enough, that I wouldn't even care if someone was familiar with it. I wouldn't even make it a requirement for the job even it was a TS focused job. I would take a 'great all around dev.' any day over someone I knew to be very knowledgeable about TS but otherwise big question marks about their development ability. Of course, the same holds true for memorizing algorithms - it's a nice signal that someone can do some fancy B-Tree stuff off the top of their head, but not really what you are looking for so interviews shouldn't be focused on that. Typescript and most of it's best practices (most of the odd corners of TS are not important), can be taught very quickly to any decent dev.

rufus_foreman 5y ago

>> Leetcode measures nothing but your most basic understanding of a languages syntax, and your ability to memorize leetcode questions and common interview algorithms. 90 something percent of people on earth will never be able to do any of that.

brailsafe 5y ago
90% of people on earth also aren't programmers of any kind
- rufus_foreman 5y ago
  Yeah. So 90 plus percent of people aren't going to be able to do anything like that. Hell 90% of the people who call them selves programmers can't code.

carnitine 5y ago

What do you think of Google’s process then, where interview questions are constantly refreshed and removed if they’re found to be leaked? I think the weakest form of these style of interviews (boring CRUD companies asking how to find a loop in a linked list) are used to argue against all algorithmic interviews.

wldlyinaccurate 5y ago
Google's interview process lends itself to finding people who really want to work at Google. Nobody would go through that process to work for a small unknown company, even for the same total compensation.

908B64B197 5y ago

> If someone can fizzbuzz with a for loop, recursion, and a list comprehension, they probably know enough of that language to do your junior/mid-level job. If they get a problem they don't know, throw their hands in the air, slam their desk, and start crying, you may not want to work with them. That's setting the bar pretty low. If the candidate is from a serious institution he should be able to manipulate more complex data structures.

Zababa 5y ago

> The only people to ever write a merge sort are either in/preparing for an interview, and John von Neumann. Do you mean "for the first time and without errors"? I assume that most people should be able to give an overview of how a merge-sort works, and a pseudocode implementation.

brailsafe 5y ago
Why? It's really only in those contexts that's it's necessary to have it on hand. Unless you're in the context of needing it on-hand, it's trivia.
- Zababa 5y ago
  I wouldn't call it "trivia" but "fundamental knowledge". If the person you're interviewing went through college it should be easy. If they didn't, they probably read about it somewhere (or should have) and can describe it to you.
  - brailsafe 5y ago
    It's not as much a question to me of whether they've ever seen it, wrote it, or studied it, it's whether they know off the top of their head even which one it is or what the implementation looks like.
  - jjav 5y ago
    > I wouldn't call it "trivia" but "fundamental knowledge". Something that will never be needed in a career can hardly be called "fundamental knowledge". I don't remember anything about how merge sort works. If someone wanted to interview me on that, they'd convince themselves I can't code, despite decades of delivering production code. > If the person you're interviewing went through college it should be easy. I did study CS in university. A very top CS school, even (CMU). Probably I must've studied merge sort at some point, but the last algorithms class I took at CMU was almost 30 years ago. Not once have I needed that info since then, so it's long long forgotten. Its relevance to a software engineering career is nil.
5y ago