3 ms·

I feel like 99% of eng interview advice sounds just like this: "I've interviewed a bazillion people, everyone else is doing it wrong, here's the one good way."

I feel like 99% of eng interview advice sounds just like this: "I've interviewed a bazillion people, everyone else is doing it wrong, here's the one good way." Honestly, I think a lot of it is akin to medieval quackery. "I've treated hundreds of patients with leeches and the large majority of them eventually recovered - you should listen to me!" I wish that we, as an industry, would spend less time reinventing interviewing from first principles. There are decades of research on how to interview people effectively. I highly recommend Schmidt + Hunter's meta-analysis (https://www.researchgate.net/publication/232564809_The_Validity_and_Utility_of_Selection_Methods_in_Personnel_Psychology https://www.researchgate.net/publication/232564809_The_Valid...) as a starting point. From my read of the research: 1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way. 2. Use structured interviews. Engineers love to just have loose conversations and judge people based on that, but structured > unstructured. Plus (just my guess here), I suspect unstructured interviews leave a lot more room for bias. 3. Plenty of techniques are effective on their own (eg references), but add minimal effectiveness when you're already doing a more effective test (eg work sample) and are therefore pretty much wastes.

ghaff 3y ago
>1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way. I'd argue that you're basically pushing the workload onto the applicant. Now, sometimes it makes a lot of sense to the degree that the applicant can just share a work sample with you--GitHub, published report/paper/other writing, a video of a presentation. In fact, I've hired for non-developer roles where some sort of work sample is pretty much non-negotiable. But recognize this creates biases (and acts as a filter) where something needs to be created from scratch.
threatofrain 3y ago
One of the most stable and effective findings in I/O psychology is the predictive value of IQ on job performance, which unfortunately is also often legally gray. Maybe companies know what they're doing with coding challenges as an under-the-legal-radar proxy for IQ? Especially if companies are hiring young adults straight out of college with little to differentiate themselves.
- sapiogram 3y ago
  Totally agreed, I always assumed leetcode was primarily used as a proxy for IQ, with the added benefit of testing basic coding competence.
- suzzer99 3y ago
  The problem with both IQ tests and leetcode interview questions is that in addition to aptitude, they also measure ability to perform under pressure and with a time constraint, skills which rarely come up in the actual job of software development (save needing to fix some bug 10 minutes before a presentation). Everyone feels pressure differently. For some devs a job interview whiteboard can feel like trying to code with a gun to your head. I've known brilliant devs who froze under the pressure of an interview. And other brilliant devs who needed to meditate on something, or sleep on it, before coming back with the optimal solution. I've worked with devs who tended to just run with the first solution that popped into their head, with no patience to mull over a variety of possible approach looking for the simplest one. These devs are fine for straightforward tasks, but become a liability when designing or writing foundational core code.
  - dbingham 3y ago
    > I've known brilliant devs who froze under the pressure of an interview. And other brilliant devs who needed to meditate on something, or sleep on it, before coming back with the optimal solution. Yeah, this is me. Not that I'm brilliant, good side of solid is maybe a better description. But I freeze on whiteboarding and l33tcode. I taught myself binary search and insert sort in high school, but ask me to write insert sort in 40 mins with someone looking over my shoulder and judging and I'll struggle. Every job I've gotten has come from a take home test.
  - edanm 3y ago
    There's very unlikely to be a general way to interview people that will fit everyone. These kind of cases happen, but how often? 1% of people? 10% of people? I'm guessing it's far less prevalent than some people seem to think, and that unfortunately, there's no good general system for solving this.

ghaff 3y ago

>1. Use work-sample tests. Yes, they're annoying, but they're high-signal. Take-home tests, online tests, in-person tests, trial periods - there are plenty of options here, but it seems clear this is the most effective way. I'd argue that you're basically pushing the workload onto the applicant. Now, sometimes it makes a lot of sense to the degree that the applicant can just share a work sample with you--GitHub, published report/paper/other writing, a video of a presentation. In fact, I've hired for non-developer roles where some sort of work sample is pretty much non-negotiable. But recognize this creates biases (and acts as a filter) where something needs to be created from scratch.

threatofrain 3y ago

One of the most stable and effective findings in I/O psychology is the predictive value of IQ on job performance, which unfortunately is also often legally gray. Maybe companies know what they're doing with coding challenges as an under-the-legal-radar proxy for IQ? Especially if companies are hiring young adults straight out of college with little to differentiate themselves.

sapiogram 3y ago
Totally agreed, I always assumed leetcode was primarily used as a proxy for IQ, with the added benefit of testing basic coding competence.
suzzer99 3y ago
The problem with both IQ tests and leetcode interview questions is that in addition to aptitude, they also measure ability to perform under pressure and with a time constraint, skills which rarely come up in the actual job of software development (save needing to fix some bug 10 minutes before a presentation). Everyone feels pressure differently. For some devs a job interview whiteboard can feel like trying to code with a gun to your head. I've known brilliant devs who froze under the pressure of an interview. And other brilliant devs who needed to meditate on something, or sleep on it, before coming back with the optimal solution. I've worked with devs who tended to just run with the first solution that popped into their head, with no patience to mull over a variety of possible approach looking for the simplest one. These devs are fine for straightforward tasks, but become a liability when designing or writing foundational core code.
- dbingham 3y ago
  > I've known brilliant devs who froze under the pressure of an interview. And other brilliant devs who needed to meditate on something, or sleep on it, before coming back with the optimal solution. Yeah, this is me. Not that I'm brilliant, good side of solid is maybe a better description. But I freeze on whiteboarding and l33tcode. I taught myself binary search and insert sort in high school, but ask me to write insert sort in 40 mins with someone looking over my shoulder and judging and I'll struggle. Every job I've gotten has come from a take home test.
- edanm 3y ago
  There's very unlikely to be a general way to interview people that will fit everyone. These kind of cases happen, but how often? 1% of people? 10% of people? I'm guessing it's far less prevalent than some people seem to think, and that unfortunately, there's no good general system for solving this.