4 ms·

I give coding interviews and I try to take the original concern (Questioner can't think fast enough or freezes) into account, but I can't really say with any ce

by steego 9y ago

I give coding interviews and I try to take the original concern (Questioner can't think fast enough or freezes) into account, but I can't really say with any certainty if I'm successful or not. About 10 years ago, I gave a woman a coding interview question and her hands were literally shaking. She got through it, but I felt terrible because clearly she was the type of person who gets really nervous when under that type of pressure. She was very experienced and my discussions with her really seemed to indicate she learns quickly and would probably be a decent fit. The only reason we didn't hire her was I found another woman who was a better fit. Since then, I've tried a lot of things. Lately, I've been putting the emphasis that we allocate some time to pair program. We simply get in a room to make something together and we may take turns with the keyboard. I actually go out of my way to tell people this is not a coding test, but rather a play date. I emphasize I don't expect them to know everything and I even half-joke I deduct points for not asking questions. Some people have told me they really like this approach, the others haven't commented one way or the other, but I'm still skeptical about my method. Most seem to relax well enough, but there are always people who may be more than competent who simply don't manage to relax in a realtime environment. Some people work like tortoises. They may appear slow, but the culminated effect of their very deliberate and careful decisions accumulates far better than a hare. I'm pretty sure my current process doesn't work in their favor, but I'm at a loss for better alternatives at this time. I'd love to know what HN readers think. Do your interview processes penalize tortoises or other people who don't simply fit a mold? Do you have a good system that takes into account the diversity of people's talents?

ryandvm 9y ago
I think the test that is the least stressful as well as most closely simulates the work they'll actually be doing is to give interviewees some "homework" that they should be able to knock out in a few hours before their interview. Maybe write a few API endpoints or whatever. This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with. If you're concerned they'll cheat and have their friends do it for them - you needn't be. As long as the interviewer is knowledgeable enough to ask good questions (e.g. "Why did you use that auth strategy?" or "What performance problems do you anticipate?") you'll quickly be able to tell if they fully understand the problem space. That's a much more useful test than asking someone to implement a red/black tree.
- steego 9y ago
  Do you think I should ask people if they prefer the homework format? That answer might be eye-opening itself.
- david-gpu 9y ago
  Going to an interview is already a time-consuming affair that requires taking time off from your current job, but at least you know the interviewer is somewhat serious because they are willing to spend their own time interviewing you. With a "homework assignment" it is possible for the interviewer to throw a much wider net, and that is why as an job hunter I would not waste my time with it.
- CodeWriter23 9y ago
  I would reject that as well, it indicates the company thinks nothing of giving me a half day of work to do for free.
  - ryandvm 9y ago
    Oh I don't think it should be free. They should definitely compensate you at a reasonable market rate for a couple hours of effort.
- pseudalopex 9y ago
  What about letting people provide code they've already written? It might take more effort to come up with good questions, but the answers should be more interesting.
- qudat 9y ago
  I'm going to go against the grain and say homework assignments work for me. If I know that I would perform better at them instead of a whiteboard code test then I would take the time. But I think you can see the bias here, the people that are interested in taking a homework assignment over in person interviews are ones that prefer them.
steego 9y ago
I would like to add the reason I continue to use my current method is that it creates so many diverse points of data (using that term loosely) because so much happens in the hour we're together. There is something incredibly revealing when it comes to collaboration, especially if the objective is slightly open-ended. People have very different styles of approaching ideas and a lot of the time, it's revealed when the objective hasn't been overconstrained. Simply asking people, "What would you do here?" and "What's your approach?" in a non-judgemental way that actually conveys you're interested in their ideas goes a long way. Also, phrasing your questions so they come off as genuinely curious rather than pointed goes a long way. Most of all, letting people take you somewhere you didn't expect to go is an interesting way to learn about someone. When your agenda is open enough to allow a person to solve a problem with tools or ideas they're comfortable with, it can be eye opening. However, if I see them doing something where I feel like I improve it, I offer to show them a trick and this gives me a tiny peek to see how they learn. Do they get it right away? Do they ask good questions? I think all those things are important aspects of collaboration. You need to have a genuine interest in each other's ideas and receptive to teaching each other new ideas and making each other's work better by adding your insight as well as absorbing their insight. That's why I'm hesitant to simply interview and ask questions. I actually enjoy coding with other people and it's hard for me to see if I'm going to like working with this person if all I'm doing throwing questions at them so they can wax poetic about their last job, thoughts on tech/methods, etc. Again, I'm still not convinced my method is optimal.
- mercer 9y ago
  FWIW, as someone dealing with pretty severe (social) anxiety, I'd go for your approach over any other if I had my choice in interview method! Homework would be my second-favorite approach, but the reason why I prefer yours is that it would also give me a lot of insight in who I'd be working for/with.
RandomOpinion 9y ago
> Some people work like tortoises. They may appear slow, but the culminated effect of their very deliberate and careful decisions accumulates far better than a hare. I'm pretty sure my current process doesn't work in their favor, but I'm at a loss for better alternatives at this time. As someone who prefers to contemplate a question carefully before answering and stutters considerably when put on the spot, kudos for you for considering taking a more inclusive and compassionate approach.

by steego 9y ago

ryandvm 9y ago

I think the test that is the least stressful as well as most closely simulates the work they'll actually be doing is to give interviewees some "homework" that they should be able to knock out in a few hours before their interview. Maybe write a few API endpoints or whatever. This allows them to tackle the exercise at their own pace and do it at a level of quality that they're comfortable with. If you're concerned they'll cheat and have their friends do it for them - you needn't be. As long as the interviewer is knowledgeable enough to ask good questions (e.g. "Why did you use that auth strategy?" or "What performance problems do you anticipate?") you'll quickly be able to tell if they fully understand the problem space. That's a much more useful test than asking someone to implement a red/black tree.

steego 9y ago
Do you think I should ask people if they prefer the homework format? That answer might be eye-opening itself.
david-gpu 9y ago
Going to an interview is already a time-consuming affair that requires taking time off from your current job, but at least you know the interviewer is somewhat serious because they are willing to spend their own time interviewing you. With a "homework assignment" it is possible for the interviewer to throw a much wider net, and that is why as an job hunter I would not waste my time with it.
CodeWriter23 9y ago
I would reject that as well, it indicates the company thinks nothing of giving me a half day of work to do for free.
- ryandvm 9y ago
  Oh I don't think it should be free. They should definitely compensate you at a reasonable market rate for a couple hours of effort.
pseudalopex 9y ago
What about letting people provide code they've already written? It might take more effort to come up with good questions, but the answers should be more interesting.
qudat 9y ago
I'm going to go against the grain and say homework assignments work for me. If I know that I would perform better at them instead of a whiteboard code test then I would take the time. But I think you can see the bias here, the people that are interested in taking a homework assignment over in person interviews are ones that prefer them.

steego 9y ago

I would like to add the reason I continue to use my current method is that it creates so many diverse points of data (using that term loosely) because so much happens in the hour we're together. There is something incredibly revealing when it comes to collaboration, especially if the objective is slightly open-ended. People have very different styles of approaching ideas and a lot of the time, it's revealed when the objective hasn't been overconstrained. Simply asking people, "What would you do here?" and "What's your approach?" in a non-judgemental way that actually conveys you're interested in their ideas goes a long way. Also, phrasing your questions so they come off as genuinely curious rather than pointed goes a long way. Most of all, letting people take you somewhere you didn't expect to go is an interesting way to learn about someone. When your agenda is open enough to allow a person to solve a problem with tools or ideas they're comfortable with, it can be eye opening. However, if I see them doing something where I feel like I improve it, I offer to show them a trick and this gives me a tiny peek to see how they learn. Do they get it right away? Do they ask good questions? I think all those things are important aspects of collaboration. You need to have a genuine interest in each other's ideas and receptive to teaching each other new ideas and making each other's work better by adding your insight as well as absorbing their insight. That's why I'm hesitant to simply interview and ask questions. I actually enjoy coding with other people and it's hard for me to see if I'm going to like working with this person if all I'm doing throwing questions at them so they can wax poetic about their last job, thoughts on tech/methods, etc. Again, I'm still not convinced my method is optimal.

mercer 9y ago
FWIW, as someone dealing with pretty severe (social) anxiety, I'd go for your approach over any other if I had my choice in interview method! Homework would be my second-favorite approach, but the reason why I prefer yours is that it would also give me a lot of insight in who I'd be working for/with.

RandomOpinion 9y ago

> Some people work like tortoises. They may appear slow, but the culminated effect of their very deliberate and careful decisions accumulates far better than a hare. I'm pretty sure my current process doesn't work in their favor, but I'm at a loss for better alternatives at this time. As someone who prefers to contemplate a question carefully before answering and stutters considerably when put on the spot, kudos for you for considering taking a more inclusive and compassionate approach.