4 ms·

Interviewing is an inherently flawed way of determining skill. This manifests itself in numerous ways; one of which is our inability to properly extrapolate inf

Interviewing is an inherently flawed way of determining skill. This manifests itself in numerous ways; one of which is our inability to properly extrapolate information from an interview: if a good programmer needs to search online for information to solve a problem about once each 8-hour day, then during the interview, the good programmer may ask for help once. But if they do that, then the interviewer sees that they need to ask for help once every hour. Alternatively, if they don't ask for help, the interviewer might be led to believe that they don't use tools afforded to them. Because one cannot ask for help 1/8th of a time, the interviewer has a negative impression of the candidate regardless of the choice the interviewee makes. This sort of lose-lose for the interviewer due to extrapolation can happen for many different facets: anything that is necessary, but only in moderation. Interviews are a very flawed system for identifying skill.

jarin 15y ago
Maybe I'm actually a terrible coder and don't know it, but I search through documentation way more than once a day. Saves a ton of time. I always thought a great interview would be something like "Here's a dev machine, make me an app that does this. I'll be back in an hour." (coding test), followed by a code review and "Let's go to happy hour." (personality test).
mikeash 15y ago
An interview where the interviewer favors people who look at documentation less often is already deeply flawed. In my experience, the best programmers spend the most time reading documentation, and the worst programmers are the ones who never read docs and never ask questions. I would never want to hire or work with someone who read docs only once a day.
- CGamesPlay 15y ago
  Yes, totally. Once per day is a ridiculous figure. Let's say "less than one time per interview-difficulty problem", and the numbers still hold.
  - mikeash 15y ago
    Do I understand you correctly that you're now saying that multiple times per day is acceptable, but d/i times per day, where d is the length of the day and i is the length of the interview, is unacceptable? This is still nuts. There is literally no amount of documentation checking that is too much, as long as the guy produces results.

jarin 15y ago

Maybe I'm actually a terrible coder and don't know it, but I search through documentation way more than once a day. Saves a ton of time. I always thought a great interview would be something like "Here's a dev machine, make me an app that does this. I'll be back in an hour." (coding test), followed by a code review and "Let's go to happy hour." (personality test).

mikeash 15y ago

An interview where the interviewer favors people who look at documentation less often is already deeply flawed. In my experience, the best programmers spend the most time reading documentation, and the worst programmers are the ones who never read docs and never ask questions. I would never want to hire or work with someone who read docs only once a day.

CGamesPlay 15y ago
Yes, totally. Once per day is a ridiculous figure. Let's say "less than one time per interview-difficulty problem", and the numbers still hold.
- mikeash 15y ago
  Do I understand you correctly that you're now saying that multiple times per day is acceptable, but d/i times per day, where d is the length of the day and i is the length of the interview, is unacceptable? This is still nuts. There is literally no amount of documentation checking that is too much, as long as the guy produces results.