6 ms·

Check your premise. It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period. The danger with this

Check your premise. It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period. The danger with this is that this is not a real world scenerio of how two people would approach a task or problem. It’s also important to recognize that everyone is different with regards to how they process information. Stress has a real biological effect on how the brain processes information, and who doesnt feel stressed during an interview. I’m somewhat autistic and struggle to process verbal information. But I try not to share that with people because I choose not to be labeled by it. It’s unfortunate that in our society that we have to conceal things like that. All of us could be better at trying to understand people around us and accepting them for who they are instead of scrutinizing them for what they are not.

deleted 9y ago
[deleted]
tytytytytytytyt 9y ago
> It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period. Of course, you have a limited amount of time to interview people. Please let me know when you figure out how to give someone an infinite amount of time to answer questions during a 1 hour interview. > The danger with this is that this is not a real world scenerio of how two people would approach a task or problem. That doesn't mean it's not a reasonable way to test basic skills. It's even too easy to test that by itself. What good alternative do you have? > All of us could be better at trying to understand people around us and accepting them for who they are instead of scrutinizing them for what they are not. How exactly would you structure a 1 hour interview so that it's not, "scrutinizing them for what they are not"? Or are you just having fun being preachy here?
- chrisbennet 9y ago
  I realize that you’re doing the best that you know how given the time pressures you have as an interviewer. There is no perfect answer to this problem. Here’s the thing though, you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent. When HN developers are telling that Test A is a bad proxy for developer competence, perhaps, just perhaps, you might consider trying to improve it with the advice given. The upside of being able to accomodate developers who “lock up” in stressful interviews, is that you now have access to great developer that are (according to your competitors) “impossible to find”.
  - tytytytytytytyt 9y ago
    A lot of that's true or might be true, but how do we improve things? > you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent. That's true for any non-perfect interview process at any job. The problem isn't that people don't know this, it's that it's hard to accurately measure who's good. > you might consider trying to improve it with the advice given Hah, as if the advice is something amazing! Which of these pieces of advice could we use that wouldn't make things worse in some way and also have a chance of being accepted by existing coworkers and managers? There's some great pie in the sky ideas, but nothing without serious issues. > Pete Holiday, an Engineering Manager at CallRail in Atlanta, used to use homework as part of job interviews before realizing that he was ruling out good candidates. Some told him they didn’t have time for homework. Others may have never gotten to that point. “It’s way more inclusive to just have someone come to the office and talk to them,” Holiday said. “You’re not counting on them having time, or a computer at home. We have candidates with sick family member, single parents. Without the homework we can cast a wider net.” So is homework worse than whiteboarding onsite? Who do we believe, some article or the crackpots here?
    - chrisbennet 9y ago
      I wasn’t referring to the in-office vs. take-home aspect, just the “stress test” nature of the white boarding test. (And I was admittedly unclear about that in my post and I’m sorry.) Think of ways you can de-stress the candidate while extracting useful information. Ideas: 1. Have them bring something they wrote with them and describe it in the interview. A lot of developers will “come out of their shell” when they start explaining something that they worked on. 2. Show them some code and have them explain it to you. I had a manager open a C book once and had me explain some code. 3. Pair program on a problem that the interviewer doesn’t know the answer to. This situation is a lot more like a true work situation.
    - preordained 9y ago
      One thing I would say is just talk through problems with candidates as simple as that sounds. Try to grok how they think through software problems. Nothing mind-blowing there, but what I'm saying is how someone codes fizz-buzz tells very little...or to me this is like hiring a driver by taking them out to a parking lot and doing doughnuts. If you can fathom the idea that they can drive a car (at all) it seems like it is much more enlightening to hear about how they organize a schedule, clients they have picked up, problems they have solved...how they react and comment to situations you pose to them,etc. I guess the key here is to do this conversationally, and not like you're grilling them. Or you have to be a good question asker and a good listener..but if you are, or can become one, I 100% believe you can get the information you need in a humane and efficient manner. But even as I type this, I'm wondering if the ability to read people is why this so hard for software interviewers...or maybe it's for lack of that simple skill that our industry has resorted to silly proxies like fizz buzz, etc.
tboyd47 9y ago
Solving a problem within a fixed time period is the best real world scenario for programmers. No project has an unlimited budget, so no one gets unlimited time in the real world.
- poulsbohemian 9y ago
  "Plan to throw one away." This was one of the major thesis statements of The Mythical Man Month, by Fred Brooks. It's one of the hallmark texts on software development. I don't disagree with what you are saying - that we need to be cognizant of time and money - but there is a scary shift happening in software where more emphasis is put on time-to-market above all else, where we are boiling the frog of consumer expectations. Millions of people lose their personal financial information in a hack, and the entire population just shrugs their shoulders. I'm left wondering if this would be the case if we put less emphasis on continuous production deployment, and more on the care and quality of our processes and systems.
- pdonis 9y ago
  > Solving a problem within a fixed time period is the best real world scenario for programmers. Not if the fixed time period is 45 minutes with an interviewer looking over your shoulder.
  - tytytytytytytyt 9y ago
    Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures. The scenario here sounds like it's as relaxed and simple as you can get without it being so easy it tests nothing. Are you assuming the interviewer always yells like he's Sam Kinison?
    - pdonis 9y ago
      > Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures. Yes, and they're troubleshooted by people who are already intimately familiar with the systems they're troubleshooting. Nobody in the real world writes an app for a requirement they've never seen before from scratch in 45 minutes.

deleted 9y ago

[deleted]

tytytytytytytyt 9y ago

> It sounds to me that an assumption is being made because they didnt meet the expectations within a fixed time period. Of course, you have a limited amount of time to interview people. Please let me know when you figure out how to give someone an infinite amount of time to answer questions during a 1 hour interview. > The danger with this is that this is not a real world scenerio of how two people would approach a task or problem. That doesn't mean it's not a reasonable way to test basic skills. It's even too easy to test that by itself. What good alternative do you have? > All of us could be better at trying to understand people around us and accepting them for who they are instead of scrutinizing them for what they are not. How exactly would you structure a 1 hour interview so that it's not, "scrutinizing them for what they are not"? Or are you just having fun being preachy here?

chrisbennet 9y ago
I realize that you’re doing the best that you know how given the time pressures you have as an interviewer. There is no perfect answer to this problem. Here’s the thing though, you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent. When HN developers are telling that Test A is a bad proxy for developer competence, perhaps, just perhaps, you might consider trying to improve it with the advice given. The upside of being able to accomodate developers who “lock up” in stressful interviews, is that you now have access to great developer that are (according to your competitors) “impossible to find”.
- tytytytytytytyt 9y ago
  A lot of that's true or might be true, but how do we improve things? > you are “leaving money on the table” when your interview process deselects great programmers because of a mistaken belief that Test A is a good proxy for developer talent. That's true for any non-perfect interview process at any job. The problem isn't that people don't know this, it's that it's hard to accurately measure who's good. > you might consider trying to improve it with the advice given Hah, as if the advice is something amazing! Which of these pieces of advice could we use that wouldn't make things worse in some way and also have a chance of being accepted by existing coworkers and managers? There's some great pie in the sky ideas, but nothing without serious issues. > Pete Holiday, an Engineering Manager at CallRail in Atlanta, used to use homework as part of job interviews before realizing that he was ruling out good candidates. Some told him they didn’t have time for homework. Others may have never gotten to that point. “It’s way more inclusive to just have someone come to the office and talk to them,” Holiday said. “You’re not counting on them having time, or a computer at home. We have candidates with sick family member, single parents. Without the homework we can cast a wider net.” So is homework worse than whiteboarding onsite? Who do we believe, some article or the crackpots here?
  - chrisbennet 9y ago
    I wasn’t referring to the in-office vs. take-home aspect, just the “stress test” nature of the white boarding test. (And I was admittedly unclear about that in my post and I’m sorry.) Think of ways you can de-stress the candidate while extracting useful information. Ideas: 1. Have them bring something they wrote with them and describe it in the interview. A lot of developers will “come out of their shell” when they start explaining something that they worked on. 2. Show them some code and have them explain it to you. I had a manager open a C book once and had me explain some code. 3. Pair program on a problem that the interviewer doesn’t know the answer to. This situation is a lot more like a true work situation.
  - preordained 9y ago
    One thing I would say is just talk through problems with candidates as simple as that sounds. Try to grok how they think through software problems. Nothing mind-blowing there, but what I'm saying is how someone codes fizz-buzz tells very little...or to me this is like hiring a driver by taking them out to a parking lot and doing doughnuts. If you can fathom the idea that they can drive a car (at all) it seems like it is much more enlightening to hear about how they organize a schedule, clients they have picked up, problems they have solved...how they react and comment to situations you pose to them,etc. I guess the key here is to do this conversationally, and not like you're grilling them. Or you have to be a good question asker and a good listener..but if you are, or can become one, I 100% believe you can get the information you need in a humane and efficient manner. But even as I type this, I'm wondering if the ability to read people is why this so hard for software interviewers...or maybe it's for lack of that simple skill that our industry has resorted to silly proxies like fizz buzz, etc.

tboyd47 9y ago

Solving a problem within a fixed time period is the best real world scenario for programmers. No project has an unlimited budget, so no one gets unlimited time in the real world.

poulsbohemian 9y ago
"Plan to throw one away." This was one of the major thesis statements of The Mythical Man Month, by Fred Brooks. It's one of the hallmark texts on software development. I don't disagree with what you are saying - that we need to be cognizant of time and money - but there is a scary shift happening in software where more emphasis is put on time-to-market above all else, where we are boiling the frog of consumer expectations. Millions of people lose their personal financial information in a hack, and the entire population just shrugs their shoulders. I'm left wondering if this would be the case if we put less emphasis on continuous production deployment, and more on the care and quality of our processes and systems.
pdonis 9y ago
> Solving a problem within a fixed time period is the best real world scenario for programmers. Not if the fixed time period is 45 minutes with an interviewer looking over your shoulder.
- tytytytytytytyt 9y ago
  Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures. The scenario here sounds like it's as relaxed and simple as you can get without it being so easy it tests nothing. Are you assuming the interviewer always yells like he's Sam Kinison?
  - pdonis 9y ago
    > Lots of real world problems are troubleshooted in less than that time, under more pressure, and have far more variables to consider/are far more difficult, like build failures. Yes, and they're troubleshooted by people who are already intimately familiar with the systems they're troubleshooting. Nobody in the real world writes an app for a requirement they've never seen before from scratch in 45 minutes.