A more reliable interview process for computer programmers
One of the first things I noticed in the software industry, was that verbal technical interviews tended to highly unreliable. On many occasions, I had observed average performers at work clear interviews that top performers had not. The former didn’t know much about programming computers, but were very good at clearing interviews. They had the confidence and knew the answers to all the usual interview questions, which they usually brushed up on the previous day.
As an interviewer from Google once remarked, some candidates were often extremely knowledgeable in interviews, but in practice, could not code the most basic programs in any language.
The problem is that verbal technical interviews rely largely on communication and confidence. Confidence is normally considered a sign of ability but the two are not actually correlated. Studies have shown that mildly capable people often tend to be more confident than extremely capable people (Dunning–Kruger effect). But as the average performer’s abilities improved, so did his awareness of his own shortcomings, thus bringing his confidence down to more realistic levels.
The problem can be much more acute in a field as abstract as computer programming, and it was made worse by the fact that most technical interviews were usually conducted by engineers who were not able to get development work. So not only were the interviewers less skilled, they would select candidates more like themselves; consciously or subconsciously asking the ones they liked the wrong questions.
My solution as an interviewer was to eliminate the verbal technical interview altogether. Instead, all potential candidates were given a simple programming problem to solve on paper - using any algorithm and any language they liked. Syntax was not checked and there was no specific time limit. The result was edifying. A person would either solve the problem in 15 minutes, or not at all.
Typically, out of a group 30 candidates, 25 could be eliminated this way in 15 minutes. The Team Leads and HR were then free to interview the others at their leisure. The technical ability of the remaining candidates was no longer in doubt, just their fit. Most rejected candidates would not even contest the results. A few disagreed, but with a laptop, could quickly be shown the flaws in their code.
Suddenly, the technical interview had become a lot more open, fair, faster and reliable. Instead of testing what someone can memorize, the interview now checked how a person thought and worked on a day to day basis. The same abstractness and peculiarity of programming that had made verbal technical interviews so subjective, now made it far easier to find the best candidates.
In fact, computer programming is probably one of the few fields in which such a direct test of aptitude is possible and yields such accurate results.
As an interviewer from Google once remarked, some candidates were often extremely knowledgeable in interviews, but in practice, could not code the most basic programs in any language.
The problem is that verbal technical interviews rely largely on communication and confidence. Confidence is normally considered a sign of ability but the two are not actually correlated. Studies have shown that mildly capable people often tend to be more confident than extremely capable people (Dunning–Kruger effect). But as the average performer’s abilities improved, so did his awareness of his own shortcomings, thus bringing his confidence down to more realistic levels.
The problem can be much more acute in a field as abstract as computer programming, and it was made worse by the fact that most technical interviews were usually conducted by engineers who were not able to get development work. So not only were the interviewers less skilled, they would select candidates more like themselves; consciously or subconsciously asking the ones they liked the wrong questions.
My solution as an interviewer was to eliminate the verbal technical interview altogether. Instead, all potential candidates were given a simple programming problem to solve on paper - using any algorithm and any language they liked. Syntax was not checked and there was no specific time limit. The result was edifying. A person would either solve the problem in 15 minutes, or not at all.
Typically, out of a group 30 candidates, 25 could be eliminated this way in 15 minutes. The Team Leads and HR were then free to interview the others at their leisure. The technical ability of the remaining candidates was no longer in doubt, just their fit. Most rejected candidates would not even contest the results. A few disagreed, but with a laptop, could quickly be shown the flaws in their code.
Suddenly, the technical interview had become a lot more open, fair, faster and reliable. Instead of testing what someone can memorize, the interview now checked how a person thought and worked on a day to day basis. The same abstractness and peculiarity of programming that had made verbal technical interviews so subjective, now made it far easier to find the best candidates.
In fact, computer programming is probably one of the few fields in which such a direct test of aptitude is possible and yields such accurate results.
Comments
Post a Comment