3 ms·

I agree that working with the candidate is the greatest signal for competence and team fit. My concern is that oftentimes, there's a lot of context to absorb b

I agree that working with the candidate is the greatest signal for competence and team fit. My concern is that oftentimes, there's a lot of context to absorb before being able to contribute, and a few hours wouldn't be enough. Don't want to extend interviews to multiple days --> biases against candidates that have packed interview schedules. I'm thinking we could structure a problem to take a few hours, and pair program with them, with the interviewers swapping out every hour and half (which would also help test how well the candidate brings someone who doesn't have context, up to speed). Or perhaps, have multiple candidates work together to solve a problem, and observe how they work together.

im_down_w_otp 9y ago
I don't see how any of those other options you mentioned ameliorate the concern of requiring contextualizing the work for the candidate. You're still going to have to contextualize the fake work. It also continues to favor weird gauntlets and puzzles without any basis for what kinds of gauntlets or puzzles are meaningful to create, nor whether or not you'd know how to interpret the results even if one could squeeze useful meaning out of them. I also assume you know well ahead of time what kind of work you're hiring for and what kind of work (in general shape) your team will be doing, so that you can schedule the interview or the team's work to appropriately coincide? I have to hire people who either have an esoteric skill-set or people who will have to rapidly learn one (formal methods, vehicle hacking, control theory, microkernel architecture, etc.), and I've yet to find a decent substitute for just planning ahead and setting up the environment to get the existing team and the candidate directly engaged on something immediate and real. I've seen a ton of bad hires made trying to contrive scenarios and meaning from more traditional methods. :shrug:
deepaksurti 9y ago
>> My concern is that oftentimes, there's a lot of context to absorb before being able to contribute, And that exactly is the problem with interviews where we can't measure what we should really measuring, so despite these marathons and what not, ending up with misfits. I can't explain it better than below: source [0]: Your scenarios are different, the normal scenario inside a company is: a) Your boss tells the new problem to the team at Monday morning. b) You have your first approach in your mind to the problem. c) The team discuss the problem for 50 minutes. You still don't have a clear idea about the problem and for sure you don't have any idea about how to solve it. But who cares? Is pancake day ! d) Lunch, you think about the problem by your own, for first time in a "serious" way. e) One day later you write an email to clear some doubts about the problem. f) You talk with another member of the team. He notices some potential problems with your approach but also you realize that, after all, your approach is better than his. You walk in the supermarket alley with your wife thinking about how to explain why your approach is better using a metaphor and trying to foresee objections from other team members. g) Thursday you finish those TDD pending upgrades, do the pull request and then you think an hour about the problem meanwhile you are still in the "zone". You have those beautiful "I got it! " moments. h) Friday you "play" with some library that you find googling and you read some code from github from a guy who did something similar. You then notice that there is a part or a step that you didn't consider before, that could change your design to solve the problem in a deep or shallow way. i) After redditing for an hour, yo do a minimal code that solve the functionality. At this time the problem has been processed in your mind for a week from different angles and using different tools. j) Monday at lunch time you take the marker and you write in the whiteboard trying to explain to the team your solution. The team decides to follow your approach. The other scenario is: a) The interviewer tells you an isolated and descontextualized problem. b) Ten seconds later you have a marker in your hand in front of a empty whiteboard. My problem is: how the real cognitive process can be replicated in an interview? Notice that in the real scenario is not the most smart developer but the best "architect" who gets the best solution after many trails and error experiments and dead-ends paths. Of course companies must have a selection process, but the whiteboard kind is just producing a lot of false negatives. [0]: https://www.reddit.com/r/programming/comments/4h15a1/why_is_hiring_broken_it_starts_at_the_whiteboard/ https://www.reddit.com/r/programming/comments/4h15a1/why_is_...

im_down_w_otp 9y ago

I don't see how any of those other options you mentioned ameliorate the concern of requiring contextualizing the work for the candidate. You're still going to have to contextualize the fake work. It also continues to favor weird gauntlets and puzzles without any basis for what kinds of gauntlets or puzzles are meaningful to create, nor whether or not you'd know how to interpret the results even if one could squeeze useful meaning out of them. I also assume you know well ahead of time what kind of work you're hiring for and what kind of work (in general shape) your team will be doing, so that you can schedule the interview or the team's work to appropriately coincide? I have to hire people who either have an esoteric skill-set or people who will have to rapidly learn one (formal methods, vehicle hacking, control theory, microkernel architecture, etc.), and I've yet to find a decent substitute for just planning ahead and setting up the environment to get the existing team and the candidate directly engaged on something immediate and real. I've seen a ton of bad hires made trying to contrive scenarios and meaning from more traditional methods. :shrug:

deepaksurti 9y ago

>> My concern is that oftentimes, there's a lot of context to absorb before being able to contribute, And that exactly is the problem with interviews where we can't measure what we should really measuring, so despite these marathons and what not, ending up with misfits. I can't explain it better than below: source [0]: Your scenarios are different, the normal scenario inside a company is: a) Your boss tells the new problem to the team at Monday morning. b) You have your first approach in your mind to the problem. c) The team discuss the problem for 50 minutes. You still don't have a clear idea about the problem and for sure you don't have any idea about how to solve it. But who cares? Is pancake day ! d) Lunch, you think about the problem by your own, for first time in a "serious" way. e) One day later you write an email to clear some doubts about the problem. f) You talk with another member of the team. He notices some potential problems with your approach but also you realize that, after all, your approach is better than his. You walk in the supermarket alley with your wife thinking about how to explain why your approach is better using a metaphor and trying to foresee objections from other team members. g) Thursday you finish those TDD pending upgrades, do the pull request and then you think an hour about the problem meanwhile you are still in the "zone". You have those beautiful "I got it! " moments. h) Friday you "play" with some library that you find googling and you read some code from github from a guy who did something similar. You then notice that there is a part or a step that you didn't consider before, that could change your design to solve the problem in a deep or shallow way. i) After redditing for an hour, yo do a minimal code that solve the functionality. At this time the problem has been processed in your mind for a week from different angles and using different tools. j) Monday at lunch time you take the marker and you write in the whiteboard trying to explain to the team your solution. The team decides to follow your approach. The other scenario is: a) The interviewer tells you an isolated and descontextualized problem. b) Ten seconds later you have a marker in your hand in front of a empty whiteboard. My problem is: how the real cognitive process can be replicated in an interview? Notice that in the real scenario is not the most smart developer but the best "architect" who gets the best solution after many trails and error experiments and dead-ends paths. Of course companies must have a selection process, but the whiteboard kind is just producing a lot of false negatives. [0]: https://www.reddit.com/r/programming/comments/4h15a1/why_is_hiring_broken_it_starts_at_the_whiteboard/ https://www.reddit.com/r/programming/comments/4h15a1/why_is_...