9 ms·

Call me crazy but I always focus more on the individual and asking them personal questions more than delving into silly leetcode they learned for the sake of ga

Call me crazy but I always focus more on the individual and asking them personal questions more than delving into silly leetcode they learned for the sake of gaming a system and will soon forget. My company works with a bunch of not so mainstream APIs so if I just waited for experts in everything we work on, I’d wait forever. I’d rather hire good, smart, people and then fill in the gaps in their knowledge. Smart, hardworking dedicated employees are much harder to find than leetcoders. And they learn really quickly with a lot less attitude and grandiose opinions of themselves.

StephenJGL 5y ago
I want to talk about code just enough to know you can talk about it. Then, I"m trying to find out if you're curious, knowledge seeking, and refining your craft. I expect everyone I hire to get better over time and on long timespans measured in multiple years these other skills win out over point in time knowledge. Unfortunately, really identifying curiosity and growth mindsets is also hard.
- mycall 5y ago
  You would think there has been research done in identifying curiosity and growth minds. Anyone? I think having a talk during lunch could answer this.
mewpmewp2 5y ago
The whole leetcode thing is atrocious. People practicing months to leetcode instead of working on actual projects. People who do actual work will fail the interviews.
- bennyelv 5y ago
  What about the people who don't do actual work, but have a decent CV and a good story about how they do? Have you ever experienced what it's like to try and hire decent developers or are you only offering the candidates' point of view? In my experience more than 50% of the applicants who make through to an interview are the kind I describe in that first sentence.
  - mewpmewp2 5y ago
    Yes, I am interviewing, but I'm offering a real world problem to solve for candidates, not an exercise picked from Leetcode. I actually enjoy Leetcoding type problems, so I'd love to grind those, so I as a candidate don't have problems with those - although still I'd rather be building stuff. The real world problem most of the time resembles understanding instructions, navigating in an existing codebase, implementing some feature. This gives really good insight into how much they've built, how much they know or how much potential they have - for example if they are unfamiliar with some things, they are always allowed to Google and if they do it efficiently, that's very telling about their potential. With Leetcode you won't know whether the person has actual skill or experience to build something or they just practiced Leetcoding for 6 months straight.
- the_only_law 5y ago
  Yeah I can’t tell whether I should put my limited energy leetcoding or working on contrived side projects in tech that’s not even a good fit just so I can put it on my resume to get past the screen.
CodeAndCuffs 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. 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.
    - 5y ago
jollybean 5y ago
Delving into the individual is complicated because it brings up enormous amounts of pop psychology. We're not as good as evaluating people as we think. It's nary impossible to tell how competent someone is in a discussion, really what we can see is their communications skills, presentation, confidence, and maybe EQ/general intelligence and hints of subject matter knowledge. Leetcode, far from silly, is far more likely to get an idea of whether or not they can do the job ahead of them. Joel Spoolsky speaks to this directly: get people to code. In my younger years, I noticed that there was zero correlation between the quality of code of all of my mentors/seniors and their work ethic, composure, communication skills etc.. Great, thoughtful organized thinkers who could barely code. Great leaders with lazy schleppy code. Obnoxious weird guys obsessive over absolute perfection (to greater or lesser extent). Leetcoding on completely irrelevant or arcane things is a waste of time, but given a very straight forward, general problem which 'homework' wouldn't have helped with - works well. A big misunderstanding about leeting is people think that the problem being solved is 'test worthy', like an exam - and really it shouldn't at all. The other issue relates to people's ability to slog through documentation and find solutions to tricky problems because that's what we do 1/2 the time but is harder to test. Someone who can take basic requirements, understand them, communicate the tradeoffs, and write something approaching 'clean code' after a couple of iterations - that's worth gold. It also requires kind of a 'rounded experience' with a bunch of tech so that they have at least a bit of intuition for it. I honestly feel the best devs are not the one's extohlling some kind of genius, or deep knowledge, but rather more of an 'extreme common sense' where they can absorb all of the fuzz of a situation and produce something simple and coherent. I feel the 'personal' issues relevant will also come out well enough during some basic leeting, though obviously that part of the interviewing has to be done.
- wildrhythms 5y ago
  I absolutely disagree with this. Engineers are perfectly capable of walking through a problem with a candidate and almost immediately measuring their ability in how they approach it. In fact, I would argue that engineers are the most qualified to assess a candidates engineering ability. If the contention is that Leetcode measures the bare minimum, the lowest bar, the 100-course material, then what does that say about the people who are being hired? An interview should be far more nuanced and compassionate than that.
irrational 5y ago
We are always more interested in their problem solving skills. We give them a very basic exercise like here is a drop down. As you can see, the items in the drop down are not in alphabetical order. We want you to change this at the sql level. How would you figure out how to trace back to the sql query that drives this drop down? It’s amazing how many supposed web developers won’t open the developer tools without our prompting them. And then, when they get in there it is obvious they have little familiarity with the developer tools. How exactly do people do web development without using the developer tools? I’ve been doing this for 23+ years and I can remember what it was like in the bad old days before firebug was created. Why would anyone want to continue to work in that past? Anyway, off tangent, it is interesting how even a very simple exercise, with lots of hand holding, can show a lot about people’s abilities to think through a problem logically.
- jason_phillips 5y ago
  This is a very good, practical solution to the problem (at least for junior web dev candidates)
devwastaken 5y ago
>I'd wait forever The biggest hires, like Microsoft, Amazon, etc - are fine with this. The core of the problem is companies become Uber corportizized, entirely separating employment from the work being done. Where HR are filtering resumes based on criteria they learned in university that applies to traditional jobs like accounting. Big corporate works despite inefficiency, due to economy of scale and control. Therefore they will wait and wait, and if they can't find a "senior full stack programmer 20 years in rust", then no matter - they'll just up the work on current devs and ultimately let the project fail because they can.
- mtnGoat 5y ago
  Good for them, but not all of us have billions and can wait for years for the perfect candidate while also constantly complaining about the lack of skilled developers. Some of us just train our own instead and get on with our lives.

StephenJGL 5y ago

I want to talk about code just enough to know you can talk about it. Then, I"m trying to find out if you're curious, knowledge seeking, and refining your craft. I expect everyone I hire to get better over time and on long timespans measured in multiple years these other skills win out over point in time knowledge. Unfortunately, really identifying curiosity and growth mindsets is also hard.

mycall 5y ago
You would think there has been research done in identifying curiosity and growth minds. Anyone? I think having a talk during lunch could answer this.

mewpmewp2 5y ago

The whole leetcode thing is atrocious. People practicing months to leetcode instead of working on actual projects. People who do actual work will fail the interviews.

bennyelv 5y ago
What about the people who don't do actual work, but have a decent CV and a good story about how they do? Have you ever experienced what it's like to try and hire decent developers or are you only offering the candidates' point of view? In my experience more than 50% of the applicants who make through to an interview are the kind I describe in that first sentence.
- mewpmewp2 5y ago
  Yes, I am interviewing, but I'm offering a real world problem to solve for candidates, not an exercise picked from Leetcode. I actually enjoy Leetcoding type problems, so I'd love to grind those, so I as a candidate don't have problems with those - although still I'd rather be building stuff. The real world problem most of the time resembles understanding instructions, navigating in an existing codebase, implementing some feature. This gives really good insight into how much they've built, how much they know or how much potential they have - for example if they are unfamiliar with some things, they are always allowed to Google and if they do it efficiently, that's very telling about their potential. With Leetcode you won't know whether the person has actual skill or experience to build something or they just practiced Leetcoding for 6 months straight.
the_only_law 5y ago
Yeah I can’t tell whether I should put my limited energy leetcoding or working on contrived side projects in tech that’s not even a good fit just so I can put it on my resume to get past the screen.

CodeAndCuffs 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. 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.
  - 5y ago

jollybean 5y ago

Delving into the individual is complicated because it brings up enormous amounts of pop psychology. We're not as good as evaluating people as we think. It's nary impossible to tell how competent someone is in a discussion, really what we can see is their communications skills, presentation, confidence, and maybe EQ/general intelligence and hints of subject matter knowledge. Leetcode, far from silly, is far more likely to get an idea of whether or not they can do the job ahead of them. Joel Spoolsky speaks to this directly: get people to code. In my younger years, I noticed that there was zero correlation between the quality of code of all of my mentors/seniors and their work ethic, composure, communication skills etc.. Great, thoughtful organized thinkers who could barely code. Great leaders with lazy schleppy code. Obnoxious weird guys obsessive over absolute perfection (to greater or lesser extent). Leetcoding on completely irrelevant or arcane things is a waste of time, but given a very straight forward, general problem which 'homework' wouldn't have helped with - works well. A big misunderstanding about leeting is people think that the problem being solved is 'test worthy', like an exam - and really it shouldn't at all. The other issue relates to people's ability to slog through documentation and find solutions to tricky problems because that's what we do 1/2 the time but is harder to test. Someone who can take basic requirements, understand them, communicate the tradeoffs, and write something approaching 'clean code' after a couple of iterations - that's worth gold. It also requires kind of a 'rounded experience' with a bunch of tech so that they have at least a bit of intuition for it. I honestly feel the best devs are not the one's extohlling some kind of genius, or deep knowledge, but rather more of an 'extreme common sense' where they can absorb all of the fuzz of a situation and produce something simple and coherent. I feel the 'personal' issues relevant will also come out well enough during some basic leeting, though obviously that part of the interviewing has to be done.

wildrhythms 5y ago
I absolutely disagree with this. Engineers are perfectly capable of walking through a problem with a candidate and almost immediately measuring their ability in how they approach it. In fact, I would argue that engineers are the most qualified to assess a candidates engineering ability. If the contention is that Leetcode measures the bare minimum, the lowest bar, the 100-course material, then what does that say about the people who are being hired? An interview should be far more nuanced and compassionate than that.

irrational 5y ago

We are always more interested in their problem solving skills. We give them a very basic exercise like here is a drop down. As you can see, the items in the drop down are not in alphabetical order. We want you to change this at the sql level. How would you figure out how to trace back to the sql query that drives this drop down? It’s amazing how many supposed web developers won’t open the developer tools without our prompting them. And then, when they get in there it is obvious they have little familiarity with the developer tools. How exactly do people do web development without using the developer tools? I’ve been doing this for 23+ years and I can remember what it was like in the bad old days before firebug was created. Why would anyone want to continue to work in that past? Anyway, off tangent, it is interesting how even a very simple exercise, with lots of hand holding, can show a lot about people’s abilities to think through a problem logically.

jason_phillips 5y ago
This is a very good, practical solution to the problem (at least for junior web dev candidates)

devwastaken 5y ago

>I'd wait forever The biggest hires, like Microsoft, Amazon, etc - are fine with this. The core of the problem is companies become Uber corportizized, entirely separating employment from the work being done. Where HR are filtering resumes based on criteria they learned in university that applies to traditional jobs like accounting. Big corporate works despite inefficiency, due to economy of scale and control. Therefore they will wait and wait, and if they can't find a "senior full stack programmer 20 years in rust", then no matter - they'll just up the work on current devs and ultimately let the project fail because they can.

mtnGoat 5y ago
Good for them, but not all of us have billions and can wait for years for the perfect candidate while also constantly complaining about the lack of skilled developers. Some of us just train our own instead and get on with our lives.