7 ms·
I've interviewed a fair number of programmers over the years. There's a surprising number of people who interview well and who have good resumes, but who can't
by ekidd 9y ago
I've interviewed a fair number of programmers over the years. There's a surprising number of people who interview well and who have good resumes, but who can't actually code. (By "can't code", I mean, "Can't sum an array of numbers in their favorite programming language.") And checking references is hit-or-miss in the US, where many employers will only confirm title and dates of employment.
I know of three possible ways to evaluate coding ability:
1. Ask coding questions in interviews. This is biased against people with performance anxiety.
2. Give people take-home "work samples". This uses up more of a candidate's time, and it may filter out high performers with multiple offers. Plus, if you give anything that takes more than a few hours, it really ought to be paid.
3. Ask for a GitHub profile with open source contributions. This is biased against people who leave work at work, or whose previous employers don't contribute to open source projects.
It's been a few years since I last interviewed candidates, but if I were designing the interview process, I'd probably want at least one of the above before hiring a candidate. Maybe the candidate could choose? "If you have public open source contributions, please submit a link and a description. If you don't, no worries! We'll can do a coding test instead."
- karlmcguire 9y agoAs someone with performance anxiety take-home programming "challenges" have been my bread and butter. I have no problem working 2-3 hours on an assignment to demonstrate my knowledge. Those at least seem more realistic than some of the interview questions about the most nuanced aspects of programming.
- mrfusion 9y agoWhy not let candidates choose between 1,2 and 3?
- UncleMeat 9y agoBecause then it is hard to have a consistent and fair method of judging candidates.
- mrfusion 9y agoSeems like you can’t compare even if you stick to one method. Some people have performance anxiety or social anxiety and can’t do 1. Others thrive on 1.
- eradicatethots 9y agoYou might want to filter out those people.
- eradicatethots 9y agoIs that very important? As long as you get a good candidate..
- watwut 9y ago3. Or who worked a lot for previous employers or took school seriously. GitHub full of contributions is hard if you work 40 hours a week without slacking at work, basically impossible for those who do a lot of overtime. People who spend their out of work time learning (e.g. reading books or other theoretical stuff) are out too. But really most importantly, it is important for reviewer to be prepared for things like performance anxiety, like shy people who are not good at looking confident, to people cant think out loud (don't hold it against them if they are silent for few minutes for christ sake) and so on and so forth. But people here throw temper tamtrum over really simple well known questions. Maybe the companies would to the best if they made their expectations clear and realistic in ad itself. Let people know how interview looks like before hand, let them know what exactly it is you expect and then stick to it.
- kevinconaway 9y agoAfter an initial phone screen, we give candidates a short programming exercise that they can complete on their own time. We feel that engineers work best when they have time to think about a problem and work on it at their own pace with their own tools. If the solution passes some objective criteria that we have, it then forms a significant component of the on site interview where we discuss their solution in depth and have them talk about the decisions they made and opportunities for improvement. Not only does this allow us to ensure that they actually wrote the submitted solution but it gives the candidate the chance to speak from a position of authority on their own code.
- deleted 9y ago[deleted]