I’ve been reflecting recently on my past few years working as a software developer. During those years I’ve had a lot of job interviews. I got many rejections, a few job offers and never heard back from some companies.
This is a review, from my own perspective, of what works and what doesn’t work when it comes to interviews and hiring processes for software developers.
The Programming Quizzes Interview
In this kind of interview you have to solve ACM kind of problems, brain-teasers, or general Computer Science quizzes. Things like finding the shortest path to traversing a graph. Any good Computer Science fresh graduate will probably be able to go through such interviews with ease. A few years later though you’ll struggle with answering most questions, simply because they have absolutely nothing to do with what you actually do in practice. Can you even remember when was the last time you had to write an algorithm to traverse a graph? Those interviews are the worst as they give absolutely no indication about how good or bad someone is going to be when they get hired.
You Seem Nice, Here’s a Job Offer
No technical interview, no tasks, absolutely nothing. This has actually happened a couple of times with me and they just left me baffled. If that’s how you have picked the rest of the team I will be working with, then thanks, but no thanks, I can’t work for you.
I’m not really sure how some companies decide to hire people entirely based on how nice their CVs look, or based on a short conversation they had. You’d be surprised by how often people make things up in their CVs.
Go Do a Task and Get Back to Us
I have encountered 2 different kinds of tasks that fall under this category. Some companies give you a generic task that they give to all candidates. Those tasks are usually designed to test your understanding about specific parts of the technologies they are using, your coding style, and how scalable and maintainable your code is. I like those kind of tasks as they show my skills in a much better way than answering some stupid questions on the spot.
What’s even better is the second kind. Your task is actual work on one of the company’s projects and your code might be used in production at some point. This not only shows your technical skills more accurately, but also shows how you communicate with the rest of the team, how you approach the problem and understand the logic business behind it. Most companies that do this kind of tasks pay you for it, whether you get accepted or not.
Come Work With Us for a Few Days
Some companies invite you to come work with them for a few days. You don’t have to be at their office 8 hours a day, but you have to show up at least a few hours everyday for 2 to 4 days. I believe this is the best way for a company to get to know candidates and see how they fit with the rest of the team, it’s also great for candidates to know the people they will be working with and see if they are comfortable working together and also get to experience everything about the work environment of the company. The only problem with this is that it’s often hard to do for candidates already working full-time at another company.
If you’re hiring a developer, specially in a startup, I urge you to ditch CVs and traditional interviews. Ask people for their Github accounts. Ask them to tell you about a personal project they have been working on recently. Invite them to come work with you for a few days. Whatever you do just make sure it gives you a meaningful indication about their skills, not how good they are with word processors or solving Computer Science quizzes.
Update: Thanks for the tree vs. graph heads up.
There have been some nice discussion about the article over at Hacker News. Make sure you check it out.