3 ms·

Of course the candidate is under more pressure than they would be at work - that's why we don't expect them to create a Leonardo masterpiece in front of us and

Of course the candidate is under more pressure than they would be at work - that's why we don't expect them to create a Leonardo masterpiece in front of us and we give the candidate the benefit of the doubt. You would be surprised at how poor some of the candidates are at this. Candidates who are unable to draw a few squares on a board to describe the last thing they worked on, and candidates who have never questioned any of the work they were assigned or don't understand that there are often multiple options for a solution, each with pros and cons. If someone can't even draw a simple diagram on a board, I don't want to have to plan and come up with highly complex solutions over whole months with them.

mlthoughts2018 8y ago
I think an important point is that you are assuming someone’s design communication moves along a spectrum from good to bad as you increase time pressure or stress, and so you can accordingly adjust your expectations along a spectrum and still be well-calibrated to evaluate the meaning of the candidate’s performance. I propose it doesn’t work like that at all. Rather, if someone’s brain is loaded with time pressure or interview jitters, and they are not the type of person who thrives on stress, then it will be more like you have totally switched off the part of their brain that is good at communicating design thinking, and their performance in the interview will be entirely unrepresentative of what their performance would be in a regular day-to-day team meeting on the job. I think the same effect is even more severe with any type of coding / mathematics / puzzle solving questions done inside a short timed session or using things like Coderpad or HackerRank.
- simplesleeper 8y ago
  And how do you propose a removal of all stress? Shall we hire everyone and fire them if they turn out to be dreadful after a week? That would ensure EVERYONE is under pressure all the time...
  - malvosenior 8y ago
    This is what take home projects or allowing someone to present their own code help fix.
  - mlthoughts2018 8y ago
    Evaluate software engineering candidates the same way virtually every other skilled profession on the planet evaluates their candidates: through a series of conversational interviews that involve technical communication about their skills and past experiences, and perhaps some version of “sample work” that ideally should just come from GitHub, school project, Stack Overflow answers, etc., and only be based on some take-home (with tons of time to complete it) in the rare cases the candidate doesn’t have any samples they want to discuss with you. I don’t understand why people keep overthinking it and believing you need any type of timed testing aspect at all. Through many years of leading engineer hiring for my teams, a simple conversational style has helped me successfully hire effective software engineers much, much more than traditional software tests. Imagine asking a plumber, lawyer, or tax accountant to solve a pipe problem, law problem, or accounting problem in ~40 minutes while you watch over their shoulder and iteratively add complicating details, while telling them to use some foreign interface they never use for their own work and confusing them by saying you don’t care about syntactical correctness and just want high level communication to “see how they think,” despite the very nature of the problem being rooted in sweating micro details about correctness.
    - jjav 8y ago
      Yes, exactly! I've been in the tech (software) industry over 25 years now, nearly all of those years here in Silicon Valley. Worked in everything from 3 person startups to the largest of enterprises. I feel good about saying I've never made a bad hire (meaning: I've never come to regret saying "hire", everyone I have given the thumbs up after an interview has turned out to be a fine contributor). I don't ask candidates to code, I don't ask them to come up with whiteboard architectures out of the blue or any of these silly artificial techniques that don't measure anything relevant. Here's what I do: I carefully read their resume. I have a conversation about the projects they have worked on. I encourage them to talk about what jobs/projects/tasks they liked and disliked and why. What they found easy vs. hard and why. And what they want to work on next and why. That's it. Works extremely well. I wish everyone would try it. You'll find it is very easy to pick out those who padded their resume. You can't actually have a meaningful conversation about what you loved and hated about working on foo if you didn't do it.
- 01100011 8y ago
  I was on a phone interview where my anxiety crossed a threshold and my brain just shut down. I literally could not comprehend the code I had just written. For a few minutes, I forgot how to program. I've programmed for 21 years professionally, across many languages, but still fell apart. I recovered after about 5-10 minutes, but at that point it was too late. A couple hours later I went back and breezed through the problem, wrote a few test cases, and ran them without issues.

mlthoughts2018 8y ago

I think an important point is that you are assuming someone’s design communication moves along a spectrum from good to bad as you increase time pressure or stress, and so you can accordingly adjust your expectations along a spectrum and still be well-calibrated to evaluate the meaning of the candidate’s performance. I propose it doesn’t work like that at all. Rather, if someone’s brain is loaded with time pressure or interview jitters, and they are not the type of person who thrives on stress, then it will be more like you have totally switched off the part of their brain that is good at communicating design thinking, and their performance in the interview will be entirely unrepresentative of what their performance would be in a regular day-to-day team meeting on the job. I think the same effect is even more severe with any type of coding / mathematics / puzzle solving questions done inside a short timed session or using things like Coderpad or HackerRank.

simplesleeper 8y ago
And how do you propose a removal of all stress? Shall we hire everyone and fire them if they turn out to be dreadful after a week? That would ensure EVERYONE is under pressure all the time...
- malvosenior 8y ago
  This is what take home projects or allowing someone to present their own code help fix.
- mlthoughts2018 8y ago
  Evaluate software engineering candidates the same way virtually every other skilled profession on the planet evaluates their candidates: through a series of conversational interviews that involve technical communication about their skills and past experiences, and perhaps some version of “sample work” that ideally should just come from GitHub, school project, Stack Overflow answers, etc., and only be based on some take-home (with tons of time to complete it) in the rare cases the candidate doesn’t have any samples they want to discuss with you. I don’t understand why people keep overthinking it and believing you need any type of timed testing aspect at all. Through many years of leading engineer hiring for my teams, a simple conversational style has helped me successfully hire effective software engineers much, much more than traditional software tests. Imagine asking a plumber, lawyer, or tax accountant to solve a pipe problem, law problem, or accounting problem in ~40 minutes while you watch over their shoulder and iteratively add complicating details, while telling them to use some foreign interface they never use for their own work and confusing them by saying you don’t care about syntactical correctness and just want high level communication to “see how they think,” despite the very nature of the problem being rooted in sweating micro details about correctness.
  - jjav 8y ago
    Yes, exactly! I've been in the tech (software) industry over 25 years now, nearly all of those years here in Silicon Valley. Worked in everything from 3 person startups to the largest of enterprises. I feel good about saying I've never made a bad hire (meaning: I've never come to regret saying "hire", everyone I have given the thumbs up after an interview has turned out to be a fine contributor). I don't ask candidates to code, I don't ask them to come up with whiteboard architectures out of the blue or any of these silly artificial techniques that don't measure anything relevant. Here's what I do: I carefully read their resume. I have a conversation about the projects they have worked on. I encourage them to talk about what jobs/projects/tasks they liked and disliked and why. What they found easy vs. hard and why. And what they want to work on next and why. That's it. Works extremely well. I wish everyone would try it. You'll find it is very easy to pick out those who padded their resume. You can't actually have a meaningful conversation about what you loved and hated about working on foo if you didn't do it.
01100011 8y ago
I was on a phone interview where my anxiety crossed a threshold and my brain just shut down. I literally could not comprehend the code I had just written. For a few minutes, I forgot how to program. I've programmed for 21 years professionally, across many languages, but still fell apart. I recovered after about 5-10 minutes, but at that point it was too late. A couple hours later I went back and breezed through the problem, wrote a few test cases, and ran them without issues.