4 ms·

Do you have any proposals for how to fix this from the interview's point of view?

by gms 17y ago

jacquesm 17y ago
Interviews don't work to ascertain how well someone will work as a programmer other than the most trivial reject / accept scenarios. Everything else plays out in the first two weeks to a month after hiring. Interviews select for people that are good at doing interviews, they present themselves well and may be able to subconsciously flatter the person interviewing them. Because of that, if the number of applicants for a given job is high the interviewer has an easier job of it, he/she can simply raise the bar during the interviews, eventually someone will pass the bar and that person will get hired. The reverse, in a market where talent is scarce the bar will be lowered until someone gets hired. But all that says is that during the interviewing phase the person performed 'as expected'. How well they work in a team, what their work attitude in general is and so on is still largely unknown. The same goes for the quality of their production. Interviewing is a 'rough' selection process, you try to do a sort of 'triage' here. The groups are hire, wait-and-see, and no way. The 'wait-and-see' might not get the nod this round but in a next round when quality is scarcer they might come up for a second round. There are probably plenty of people in this second group that would outperform people in the first group. They're just not that good at 'selling' themselves.
derefr 17y ago
Make the coding part of a larger flow. Instead of saying "there's something wrong with this code; find it and fix it," perhaps say "this is a (synthetic) bug database, and this is a repository for the project it refers to. Prioritize and fix the bugs you think are the most important. Don't worry about not knowing the codebase—I want to see how you go about learning it." Give them a day or two (and make sure there's way more than two days' worth of work entered as bugs); let them work from home, and track their commits.

Do you have any proposals for how to fix this from the interview's point of view?

by gms 17y ago

Do you have any proposals for how to fix this from the interview's point of view?

Interviews don't work to ascertain how well someone will work as a programmer other than the most trivial reject / accept scenarios. Everything else plays out in the first two weeks to a month after hiring. Interviews select for people that are good at doing interviews, they present themselves well and may be able to subconsciously flatter the person interviewing them. Because of that, if the number of applicants for a given job is high the interviewer has an easier job of it, he/she can simply raise the bar during the interviews, eventually someone will pass the bar and that person will get hired. The reverse, in a market where talent is scarce the bar will be lowered until someone gets hired. But all that says is that during the interviewing phase the person performed 'as expected'. How well they work in a team, what their work attitude in general is and so on is still largely unknown. The same goes for the quality of their production. Interviewing is a 'rough' selection process, you try to do a sort of 'triage' here. The groups are hire, wait-and-see, and no way. The 'wait-and-see' might not get the nod this round but in a next round when quality is scarcer they might come up for a second round. There are probably plenty of people in this second group that would outperform people in the first group. They're just not that good at 'selling' themselves.

derefr 17y ago

Make the coding part of a larger flow. Instead of saying "there's something wrong with this code; find it and fix it," perhaps say "this is a (synthetic) bug database, and this is a repository for the project it refers to. Prioritize and fix the bugs you think are the most important. Don't worry about not knowing the codebase—I want to see how you go about learning it." Give them a day or two (and make sure there's way more than two days' worth of work entered as bugs); let them work from home, and track their commits.