6 ms·

I feel like interviewers can’t win here: no matter what, Hacker News will complain about it. HN says whiteboard questions are terrible, leetcode is terrible, Gi

I feel like interviewers can’t win here: no matter what, Hacker News will complain about it. HN says whiteboard questions are terrible, leetcode is terrible, Github resumés are terrible, take-home projects are terrible... these are all defensible arguments in isolation, but what should interviewers do? There’s a lot of griping re: interviewing but few suggestions on what to do instead.

tizz98 7y ago
I like Basecamp's approach of not having live coding in the interview. They discuss past projects and you walk through some code you're proud of or think is interesting. 1. https://m.signalvnoise.com/hiring-a-programmer-ditch-the-coding-interview-and-get-back-to-basics/ https://m.signalvnoise.com/hiring-a-programmer-ditch-the-cod... 2. "... you’ll submit some code you’re proud of, review it, and tell its story. Then on to an interview. Our interviews are one hour, all remote, with your future colleagues, on your schedule. We’ll talk through some of your code and some of ours. No gotchas, brainteasers, or whiteboard coding." from https://apply.workable.com/basecamp/j/F2CB808F33/ https://apply.workable.com/basecamp/j/F2CB808F33/ edit: spacing
- Analemma_ 7y ago
  This seems decent, except for the “submit some code you’re proud of“ part. What about applicants whose only jobs have been on proprietary code they can’t share? This is the same problem as using GitHub resumés: it’s kind of unfairly biased against people who either don’t work on open source projects, or like to have a life outside of coding when they’re not on the job.
  - _throwawayyyyyy 7y ago
    That sounds like a good case for paying someone to do a project for you (if they're employed, give them an 'hours' budget over a longer 'days' or 'weeks' period). Then you'd have something to look at that they just built, fresh.
- esyir 7y ago
  Until you run into the guy who literally cannot code. I'm not talking hard algorithms either.
  - mixmastamyk 7y ago
    Then you fire them.
    - _throwawayyyyyy 7y ago
      This - California is an at-will employment state. Given that, you'd think hiring and firing would both be quicker. Literally any reason that isn't illegal. So why are there so many barriers to being hired if I can be fired at whim?
      - mixmastamyk 7y ago
        Currently cargo-cult fashion.
pmiller2 7y ago
There's a bit of missing info in the OP: how much time is this project expected to take? If it's literally 2 hours or something, then fine, don't pay me. If you want me to spend 8+ hours developing a polished looking site or a standalone API, then I'm probably not going to do your interview unless passing the test gets me straight to the offer stage. Roughly speaking, I can get to an offer decision after: 1 recruiter call (20-30 minutes, usually, pretty softball). 1 or 2 phone screens (30-60 minutes apiece, generally). 1 day onsite for 4-6 hours. If you're going to demand much more than that amount of time from me, you have to offer something compelling. The definition of "compelling" varies depending how much I think I need a new job.
- _throwawayyyyyy 7y ago
  The most recent project I did last week was 3 days. Three unpaid days, and in the prompt no time limit per day. It's for a company that is top 10 most valuable startups in the world. Do you tell them you won't do it..? How long do you work on it? Open ended. I actually like what I made but I would normally charge thousands of dollars for it. It's so frustrating. Haven't heard back yet but regardless it's not a good process
  - pmiller2 7y ago
    Yes, I tell them no thanks and give them my reasoning. I would rather work for a public company that pays real money (like the company I work for now) than a startup with paper equity, anyway.
    - _throwawayyyyyy 7y ago
      Google does it too, I've done projects for them the same way. Good on you for sticking to your principles though. If everyone did maybe it wouldn't be so commonplace. Not everyone is in the situation to refuse. Thanks for the viewpoints.
      - pmiller2 7y ago
cramey 7y ago
I can tell you what's worked for me when hiring experienced programmers: Ideally the candidate offers code samples, I then pick through the code samples to find things that strike me as unusual or problematic and ask questions about those parts. This gives me a great deal of insight about how people think, and their relative level of skill. I firmly believe this is the best way to interview. Failing that, candidates frequently provide details on projects they worked on. I'll then ask questions about those projects like, "What language did you develop it in and why?" and "What do you think was the most difficult part about this project and why?" These questions are a gateway to the same kind of details you get from code samples. For example, a candidate once mentioned he had worked for the Navy, and had done water simulations for them and I asked, "What's so difficult about water simulations?" and he gave me a 20 minute lecture on how water simulations work, which won him the job. It's probably worth noting that the job had nothing to do with water simulations, but his lecture made it clear he had passion and knowledge and could do the job. The worst interviews are ones where the candidates worked in an environment where they can't offer code samples or talk about previous projects (military contractor, for example) - these you just kind of muddle through by talking about programming in general.
- Shaanie 7y ago
  The problem with talking about previous projects is that it can be hard to tell whether the candidate was an important contributor to the project or just a subpar developer making the changes (s)he's told to do by more knowledgeable teammates. A candidate which is charismatic and good at talking can be quite convincing. Provided code samples is good, but only if the candidate has written all the code themselves and isn't just passing off other's code on a project as their own. When I was conducting interviews I was frequently surprised by just how bad some candidates with fancy titles and a decade of experience were at actually coding. And I mean things like a understanding a simple recursive function, integer division, inheritance and other core concepts. I would never hire someone without at least a brief code comprehension check nowadays.
  - mixmastamyk 7y ago
    The problem is you’d probably do just as poorly under the gun and away from your subject of expertise.
lsthree 7y ago
So much this. I give people options of many interview workflows as I don’t care... I need some way to test and make a discussion about it. I want you to succeed more than you half the time! I’ve still seen failed candidates go on social media and complain that they’d rather do X when it was a freaking option. Entitled little twats
- deleted 7y ago
  [deleted]
- _throwawayyyyyy 7y ago
  kudos for giving options; too bad the candidates didn't appreciate that. once they spend some more time in the wild, they might!
ta35256236263 7y ago
For me the irritating part is, I haven't encountered any other professions where the interviewee has to "prove" themselves with this kind of nonsense (isn't that what the resume and references are for?), especially over and over again in the case of consultants and frequent job hoppers - it gets tiring and I avoid companies that try it now (unless it's a small trivial application/test). I can understand it to a small degree, given the nature of software development. I wonder how other professions would take it - "Excuse me Sandra, I know your resume says you're an electrician, but I'm going to need you to wire up this house so I can just check". I'm sure some other professions do do this, but none I've heard of.
- mattr47 7y ago
  Sure there are plenty of other professions. Pilots being the first one I can think of, as they require some type of checkride (flight exam) which will include an oral examination by the instructor/interviewer. And they don't get paid for taking that checkride. Professional musicians have to prove themselves in auditions, CPAs, auto mechanics (good ones at least), etc. The list goes on.
  - cramey 7y ago
    Professions like pilots, doctors and CPAs are bad examples because they have a certifying body that exists outside of the relationship between employee and employer. It's true they're not getting paid for that certification, but once they have it, it's valid and transferable between jobs. Musicians and actors are better examples, as they do have auditions, but lots of actors and musicians get jobs based on their previous body of work, rather than an in-person audition. I'm curious, can you name more professions that use what is essentially auditions for hiring, besides artist-types?
- Shaanie 7y ago
  I assume you've never conducted interviews, am I correct? There are so many "developers" out there that simply can't code, regardless of what their CV or education says. 15 years experience with Java development as a senior developer but doesn't know integers have a limited size (never heard of BigInteger), knows a hash map is used for key-value but not what hash means nor what the point of an interface is? Sure, I've seen that candidate. There's just so many terrible developers that you pretty much have to do some extra filtering to weed these out.
flukus 7y ago
It's more like different subsets of HN will complain about each and there's no one size fits all solution. What interviewers should do is take that into account. Github resumes are great for some people who like working on OSS stuff but horrible for others who can't share comercial work and want to have a non-coding life outside of it. Take home projects can be terrible if they're too early in the hiring pipeline and also exclude anyone currently working full time. Whiteboard questions are mostly terrible because of nerves and poor input methods, at least do it on a laptop connected to a projector, then it's acceptable for some people. The one thing you can't do is have a single process for everyone and pretend there's scientific rigor behind your decisions.
- _throwawayyyyyy 7y ago
  "The one thing you can't do is have a single process for everyone and pretend there's scientific rigor behind your decisions." Right on.
mifreewil 7y ago
It's easy - let the candidate choose what works best for them.

tizz98 7y ago

I like Basecamp's approach of not having live coding in the interview. They discuss past projects and you walk through some code you're proud of or think is interesting. 1. https://m.signalvnoise.com/hiring-a-programmer-ditch-the-coding-interview-and-get-back-to-basics/ https://m.signalvnoise.com/hiring-a-programmer-ditch-the-cod... 2. "... you’ll submit some code you’re proud of, review it, and tell its story. Then on to an interview. Our interviews are one hour, all remote, with your future colleagues, on your schedule. We’ll talk through some of your code and some of ours. No gotchas, brainteasers, or whiteboard coding." from https://apply.workable.com/basecamp/j/F2CB808F33/ https://apply.workable.com/basecamp/j/F2CB808F33/ edit: spacing

Analemma_ 7y ago
This seems decent, except for the “submit some code you’re proud of“ part. What about applicants whose only jobs have been on proprietary code they can’t share? This is the same problem as using GitHub resumés: it’s kind of unfairly biased against people who either don’t work on open source projects, or like to have a life outside of coding when they’re not on the job.
- _throwawayyyyyy 7y ago
  That sounds like a good case for paying someone to do a project for you (if they're employed, give them an 'hours' budget over a longer 'days' or 'weeks' period). Then you'd have something to look at that they just built, fresh.
esyir 7y ago
Until you run into the guy who literally cannot code. I'm not talking hard algorithms either.
- mixmastamyk 7y ago
  Then you fire them.
  - _throwawayyyyyy 7y ago
    This - California is an at-will employment state. Given that, you'd think hiring and firing would both be quicker. Literally any reason that isn't illegal. So why are there so many barriers to being hired if I can be fired at whim?
    - mixmastamyk 7y ago
      Currently cargo-cult fashion.

pmiller2 7y ago

There's a bit of missing info in the OP: how much time is this project expected to take? If it's literally 2 hours or something, then fine, don't pay me. If you want me to spend 8+ hours developing a polished looking site or a standalone API, then I'm probably not going to do your interview unless passing the test gets me straight to the offer stage. Roughly speaking, I can get to an offer decision after: 1 recruiter call (20-30 minutes, usually, pretty softball). 1 or 2 phone screens (30-60 minutes apiece, generally). 1 day onsite for 4-6 hours. If you're going to demand much more than that amount of time from me, you have to offer something compelling. The definition of "compelling" varies depending how much I think I need a new job.

_throwawayyyyyy 7y ago
The most recent project I did last week was 3 days. Three unpaid days, and in the prompt no time limit per day. It's for a company that is top 10 most valuable startups in the world. Do you tell them you won't do it..? How long do you work on it? Open ended. I actually like what I made but I would normally charge thousands of dollars for it. It's so frustrating. Haven't heard back yet but regardless it's not a good process
- pmiller2 7y ago
  Yes, I tell them no thanks and give them my reasoning. I would rather work for a public company that pays real money (like the company I work for now) than a startup with paper equity, anyway.
  - _throwawayyyyyy 7y ago
    Google does it too, I've done projects for them the same way. Good on you for sticking to your principles though. If everyone did maybe it wouldn't be so commonplace. Not everyone is in the situation to refuse. Thanks for the viewpoints.
    - pmiller2 7y ago

cramey 7y ago

I can tell you what's worked for me when hiring experienced programmers: Ideally the candidate offers code samples, I then pick through the code samples to find things that strike me as unusual or problematic and ask questions about those parts. This gives me a great deal of insight about how people think, and their relative level of skill. I firmly believe this is the best way to interview. Failing that, candidates frequently provide details on projects they worked on. I'll then ask questions about those projects like, "What language did you develop it in and why?" and "What do you think was the most difficult part about this project and why?" These questions are a gateway to the same kind of details you get from code samples. For example, a candidate once mentioned he had worked for the Navy, and had done water simulations for them and I asked, "What's so difficult about water simulations?" and he gave me a 20 minute lecture on how water simulations work, which won him the job. It's probably worth noting that the job had nothing to do with water simulations, but his lecture made it clear he had passion and knowledge and could do the job. The worst interviews are ones where the candidates worked in an environment where they can't offer code samples or talk about previous projects (military contractor, for example) - these you just kind of muddle through by talking about programming in general.

Shaanie 7y ago
The problem with talking about previous projects is that it can be hard to tell whether the candidate was an important contributor to the project or just a subpar developer making the changes (s)he's told to do by more knowledgeable teammates. A candidate which is charismatic and good at talking can be quite convincing. Provided code samples is good, but only if the candidate has written all the code themselves and isn't just passing off other's code on a project as their own. When I was conducting interviews I was frequently surprised by just how bad some candidates with fancy titles and a decade of experience were at actually coding. And I mean things like a understanding a simple recursive function, integer division, inheritance and other core concepts. I would never hire someone without at least a brief code comprehension check nowadays.
- mixmastamyk 7y ago
  The problem is you’d probably do just as poorly under the gun and away from your subject of expertise.

lsthree 7y ago

So much this. I give people options of many interview workflows as I don’t care... I need some way to test and make a discussion about it. I want you to succeed more than you half the time! I’ve still seen failed candidates go on social media and complain that they’d rather do X when it was a freaking option. Entitled little twats

deleted 7y ago
[deleted]
_throwawayyyyyy 7y ago
kudos for giving options; too bad the candidates didn't appreciate that. once they spend some more time in the wild, they might!

ta35256236263 7y ago

For me the irritating part is, I haven't encountered any other professions where the interviewee has to "prove" themselves with this kind of nonsense (isn't that what the resume and references are for?), especially over and over again in the case of consultants and frequent job hoppers - it gets tiring and I avoid companies that try it now (unless it's a small trivial application/test). I can understand it to a small degree, given the nature of software development. I wonder how other professions would take it - "Excuse me Sandra, I know your resume says you're an electrician, but I'm going to need you to wire up this house so I can just check". I'm sure some other professions do do this, but none I've heard of.

mattr47 7y ago
Sure there are plenty of other professions. Pilots being the first one I can think of, as they require some type of checkride (flight exam) which will include an oral examination by the instructor/interviewer. And they don't get paid for taking that checkride. Professional musicians have to prove themselves in auditions, CPAs, auto mechanics (good ones at least), etc. The list goes on.
- cramey 7y ago
  Professions like pilots, doctors and CPAs are bad examples because they have a certifying body that exists outside of the relationship between employee and employer. It's true they're not getting paid for that certification, but once they have it, it's valid and transferable between jobs. Musicians and actors are better examples, as they do have auditions, but lots of actors and musicians get jobs based on their previous body of work, rather than an in-person audition. I'm curious, can you name more professions that use what is essentially auditions for hiring, besides artist-types?
Shaanie 7y ago
I assume you've never conducted interviews, am I correct? There are so many "developers" out there that simply can't code, regardless of what their CV or education says. 15 years experience with Java development as a senior developer but doesn't know integers have a limited size (never heard of BigInteger), knows a hash map is used for key-value but not what hash means nor what the point of an interface is? Sure, I've seen that candidate. There's just so many terrible developers that you pretty much have to do some extra filtering to weed these out.

flukus 7y ago

It's more like different subsets of HN will complain about each and there's no one size fits all solution. What interviewers should do is take that into account. Github resumes are great for some people who like working on OSS stuff but horrible for others who can't share comercial work and want to have a non-coding life outside of it. Take home projects can be terrible if they're too early in the hiring pipeline and also exclude anyone currently working full time. Whiteboard questions are mostly terrible because of nerves and poor input methods, at least do it on a laptop connected to a projector, then it's acceptable for some people. The one thing you can't do is have a single process for everyone and pretend there's scientific rigor behind your decisions.

_throwawayyyyyy 7y ago
"The one thing you can't do is have a single process for everyone and pretend there's scientific rigor behind your decisions." Right on.

mifreewil 7y ago

It's easy - let the candidate choose what works best for them.