©2011-2023 Less Accounting
I’ve been leading development teams for many, many years. Whenever we needed to hire a developer, I tried all sorts of ways to figure out if the person would be as good (technically) as they say. In the old days, I would ask all the right questions, have someone write pseudo code on a whiteboard or computer, read resumes, talk to their references, etc.
What I found was that I would still choose people that were not as good as I thought they’d be. Clearly, I was doing something wrong. I realized that it was a little like trying to get married after the first date, none of us would expect that to go well, either.
When you hire a developer, what you really are trying to discern is whether this person has the ability, knowledge, and experience to be successful at the job. A few years ago, I decided to start asking people to do a sample project. Not a big project, nothing too complicated, but complicated enough to show they had a high degree of skill.
We’d give some deliverables for the paid test project. Instruction were to build an app that a person can create an account, authorize the flickr access and pull in their pictures. Then give that user the ability to display the pictures using different themes.
It’s fairly simple but it required the use of an API, and was enough code to see how they think through a problem and how clean their solution is. We also encouraged applicants to hang out in our chat room, video with us, and ask as many questions as they needed so we could get a feel for what it would be like to work with them.
What the test showed us:
The last person we hired has been with us for almost three years, so we haven’t had to hire a developer in a while. If I were to do this now, I might change the assignment a bit, or omit it altogether if the person had a lot of good code on their Github profile (most people don’t).