3 ms·

Oh I’m not sure what you mean but certainly sounds interesting. Can you expand a bit on Atwood and Spolsky’s influence on hiring?

_qulr 6y ago
"A new study from North Carolina State University and Microsoft finds that the technical interviews currently used in hiring for many software engineering positions test whether a job candidate has performance anxiety rather than whether the candidate is competent at coding." https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/ https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/ Programmers can program, but they usually aren't stage performers. Using auditions to evaluate non-performers is doomed to failure, predictably.
- dimmke 6y ago
  I agree that programmer interviews (especially ones with whiteboarding) do have a degree of "stage performance" that programmers aren't used to, but what exactly is the better alternative? Take homes might work if your company isn't very large but that doesn't scale. Asking domain specific questions can easily have as many false negatives as Ds/A questions - Do you really need to have a precise, perfect definition of what a closure is in JavaScript on the tip of your tongue to be an effective front-end developer in 2021? Domain specific questions are worse than algorithmic questions IMO because no matter how well you know a subject, there's always going to be pockets you might have missed. What if you took a more holistic approach and actually went through a person's projects/Github? That's more time consuming and harder to be consistently objective with. Plus, then you get the crowd of people who say you shouldn't have to have side projects to be a programmer on your case. There's going to be some level of anxiety inherent in interviewing, period. I do agree that making people write code on whiteboards is not good though. They should at least be given a somewhat similar environment to what they use day to day, like being able to type. I say this as someone who has absolutely bombed in person interviews before on the same level (probably worse) as the guy getting tripped up by basic Python elsewhere in this thread.
  - _qulr 6y ago
    > what exactly is the better alternative? When people ask this question, they almost always mean, what's the alternative to one kind of testing that's still a test? Nobody seems willing to accept the answer that interviews shouldn't be tests. The demand for testing assumes the idea, the self-fulfilling prophesy, that 99% of programmers can't program. If you start with that assumption, then you'll always end up wanting some kind of test. But it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world. We know that interviews, not just programmer interviews but interviews in general, are poor predictors of performance. The best predictor of future performance is past performance. In other words, experience. Our industry is also insanely afraid of the proverbial "bad hire". It's a pervasive mental illness. There's a failure to recognize that perfection is unattainable, and mistakes are a fact of life. Look of professional sports: they spend vastly more time and money on talent evaluation than tech, and yet pro sports teams get talent evaluation totally wrong all the time! Bad draft picks, bad trades, bad contracts, etc. They just accept it, deal with it, and move on. Nobody has the perfect programmer hiring method, and nobody ever will. It's a crapshoot. And just because a programmer "can program" doesn't mean they're not a bad hire. They could still write buggy, overengineered code, they could be a bad teammate, they could be a sexual harasser, or have any number of other issues. Or they could leave for another jobs a few months after getting hired. There's no way to guarantee a good hire. It's a mistake to turn hiring into an "algorithm". It's not a programming problem, it's a human problem. Programmers are humans, not robots, and they're not going to perform robotically in interviews. The only way to truly know is to give someone a chance. They may unpleasantly surprise you, but they may also pleasantly surprise you.
    - dimmke 6y ago
      I'm with you that there is way more to being an effective developer than just being able to write code. I feel very strongly about that. But that's not a compelling argument against doing coding assessments in interviews, I could see it as an argument in favor of also having behavioral questions. >it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world. There's no standardized licensing for our profession. The closest thing we have really is Computer Science degrees which, as the article this thread is about points out, doesn't churn out job ready programmers unless they're also doing independent study. Evaluating on past performance alone would be impossible. What if this is to be their first job? What if their previous job won't tell you anything other than "Yes this person worked here" because they're scared of getting sued? If you're relying on a candidate's self description of their past performance you've just switched out selecting for people who can perform under pressure to selecting for people who are good at bullshitting/charming. To become a lawyer, you have to sit for a very intense and stressful exam that you took two extra years of schooling for. There are similar processes in place for becoming a doctor, after even more schooling and forced on the job training. Some form of assessing coding skills is going to happen just like some form of skill assessment happens with any knowledge worker job. It'll just either happen during interviews or eventually through some kind of certification process. The example you gave of professional sports is odd to me- Yes, they have to deal with it when they make bad hiring choices just like most organizations do but they still clearly feel that it's worth the effort to be very selective in their hiring process. There is an opportunity cost to "giving someone a chance" - even if you moved to a very permissive system where it's easy in, easy out people still have to onboard that employee and go through the process of firing them. If a simple coding assessment had revealed they can't even complete very basic tasks it would avoid taking up company resources. This isn't a defense of forcing someone to write perfect code on a whiteboard, I just think it's absolutely valid to ask someone to write code in an interview setting.

_qulr 6y ago

"A new study from North Carolina State University and Microsoft finds that the technical interviews currently used in hiring for many software engineering positions test whether a job candidate has performance anxiety rather than whether the candidate is competent at coding." https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/ https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/ Programmers can program, but they usually aren't stage performers. Using auditions to evaluate non-performers is doomed to failure, predictably.

dimmke 6y ago
I agree that programmer interviews (especially ones with whiteboarding) do have a degree of "stage performance" that programmers aren't used to, but what exactly is the better alternative? Take homes might work if your company isn't very large but that doesn't scale. Asking domain specific questions can easily have as many false negatives as Ds/A questions - Do you really need to have a precise, perfect definition of what a closure is in JavaScript on the tip of your tongue to be an effective front-end developer in 2021? Domain specific questions are worse than algorithmic questions IMO because no matter how well you know a subject, there's always going to be pockets you might have missed. What if you took a more holistic approach and actually went through a person's projects/Github? That's more time consuming and harder to be consistently objective with. Plus, then you get the crowd of people who say you shouldn't have to have side projects to be a programmer on your case. There's going to be some level of anxiety inherent in interviewing, period. I do agree that making people write code on whiteboards is not good though. They should at least be given a somewhat similar environment to what they use day to day, like being able to type. I say this as someone who has absolutely bombed in person interviews before on the same level (probably worse) as the guy getting tripped up by basic Python elsewhere in this thread.
- _qulr 6y ago
  > what exactly is the better alternative? When people ask this question, they almost always mean, what's the alternative to one kind of testing that's still a test? Nobody seems willing to accept the answer that interviews shouldn't be tests. The demand for testing assumes the idea, the self-fulfilling prophesy, that 99% of programmers can't program. If you start with that assumption, then you'll always end up wanting some kind of test. But it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world. We know that interviews, not just programmer interviews but interviews in general, are poor predictors of performance. The best predictor of future performance is past performance. In other words, experience. Our industry is also insanely afraid of the proverbial "bad hire". It's a pervasive mental illness. There's a failure to recognize that perfection is unattainable, and mistakes are a fact of life. Look of professional sports: they spend vastly more time and money on talent evaluation than tech, and yet pro sports teams get talent evaluation totally wrong all the time! Bad draft picks, bad trades, bad contracts, etc. They just accept it, deal with it, and move on. Nobody has the perfect programmer hiring method, and nobody ever will. It's a crapshoot. And just because a programmer "can program" doesn't mean they're not a bad hire. They could still write buggy, overengineered code, they could be a bad teammate, they could be a sexual harasser, or have any number of other issues. Or they could leave for another jobs a few months after getting hired. There's no way to guarantee a good hire. It's a mistake to turn hiring into an "algorithm". It's not a programming problem, it's a human problem. Programmers are humans, not robots, and they're not going to perform robotically in interviews. The only way to truly know is to give someone a chance. They may unpleasantly surprise you, but they may also pleasantly surprise you.
  - dimmke 6y ago
    I'm with you that there is way more to being an effective developer than just being able to write code. I feel very strongly about that. But that's not a compelling argument against doing coding assessments in interviews, I could see it as an argument in favor of also having behavioral questions. >it's such a bizarre idea that programmers are uniquely incompetent among all professions in the world. There's no standardized licensing for our profession. The closest thing we have really is Computer Science degrees which, as the article this thread is about points out, doesn't churn out job ready programmers unless they're also doing independent study. Evaluating on past performance alone would be impossible. What if this is to be their first job? What if their previous job won't tell you anything other than "Yes this person worked here" because they're scared of getting sued? If you're relying on a candidate's self description of their past performance you've just switched out selecting for people who can perform under pressure to selecting for people who are good at bullshitting/charming. To become a lawyer, you have to sit for a very intense and stressful exam that you took two extra years of schooling for. There are similar processes in place for becoming a doctor, after even more schooling and forced on the job training. Some form of assessing coding skills is going to happen just like some form of skill assessment happens with any knowledge worker job. It'll just either happen during interviews or eventually through some kind of certification process. The example you gave of professional sports is odd to me- Yes, they have to deal with it when they make bad hiring choices just like most organizations do but they still clearly feel that it's worth the effort to be very selective in their hiring process. There is an opportunity cost to "giving someone a chance" - even if you moved to a very permissive system where it's easy in, easy out people still have to onboard that employee and go through the process of firing them. If a simple coding assessment had revealed they can't even complete very basic tasks it would avoid taking up company resources. This isn't a defense of forcing someone to write perfect code on a whiteboard, I just think it's absolutely valid to ask someone to write code in an interview setting.