Hiring Masters

Tomorrow morning I have a job interview for a CTO position at a startup in Amsterdam. I prefer not to prepare for job interviews but this one is an exception. I'm confident in my ability but with the rise in good development jobs lately, I've grown more picky on which interviews I take. In my past and future jobs, hiring developers is a large part of my work. Many articles have been written about how to interview developers but I have my own thoughts on how to spot a good developer and how to maximise their impact.

Hiring

Hiring a developer is no easy task. Most of the developers I've hired in the past were hired after a single interview, which had massive impact on our employee turnover rate. Sure, within a couple minutes you know if a developer is completely wrong for your company but it takes much longer to verify a developer's true skill.

Code tests
Doing a code test during an interview is completely ridiculous. An hour of development time is not going to give you any indication of a developer's true skill. Toss this technique in the garbage and leave it there.

Riddles
I like riddles in job interviews. Make a developer think, test their out of the box thinking skills and see how much they like hard problems without a clear solution. This is a decent intelligence test but more than that, it's an endurance test. I don't care if it takes a developer 15 minutes longer to figure out how to solve a problem but I do care if they give up after 5 minutes.

Language related questions
Another one of those ridiculous job interview techniques. Just because someone knows a language doesn't make them good developers. Most of the job interviews I went on myself were for jobs in companies who developed in a language I didn't know. A developer's skill level is not measured by his control of a specific language.

However, if you are only hiring for one language and you don't want to take time to train new developers, this will give you a decent indication of someone's instant knowledge of their language.

Good conversation
Nowadays, when I hire developers, I plan long job interviews. An interview might take me two hours to complete, depending on how well I can get along with the interviewee. I'll ask them questions about Object Oriented Programming vs Functional Programming, general programming problems and personal motivation and inspirations. If I can have a two hour conversation with someone about software development and feel like I had a conversation where I learned something or was genuinely impressed by the other party, there's a good chance I'll be able to work with this person.

Software development in a company is a team sport. As any good coach will tell you, a good team requires more than a couple skilled players. You need synergy, you need personal connection but most of all, you need respect.

Training

I have never hired a perfect developer. I don't believe perfect developers exist and I think training your employees leads to better code and more synergy in the team. I had a job where I only worked 4 days a week and my 5th day was entirely spent learning something new. Never did I feel so connected to my team and never was I so excited to go to work. My salary was terrible but I couldn't be more excited about waking up on Monday and getting to work. I worked harder, learned more and had more fun doing it. I believe this is incredibly important in development teams and I will continue to implement similar structures in future jobs.

Training a developer doesn't have to be expensive. Give them a book they'll enjoy reading, give them a video series on a new language they're eager to learn but also do code review with them. Show them their mistakes and help them improve. I have team members do each other's code review and I have had employees tell me my code could be improved several times. Not only are you training your employees as a team, you're learning a lot yourself.

What is mastery?

When it comes to hiring a developer, it's incredibly difficult to find the right person for the job. It's hard to measure mastery, and even harder to measure personality in a short interview. I believe it's not mastery of a language but mastery of software design and problem solving in general that make a good developer. I've had people comment on my code because I didn't know a language very well and that's fine. Learning a new language is much easier than learning how to be a good developer.

Much like learning about other people's mind states, learning how to be a good developer requires suspension of disbelief. Some patterns and languages seemed off to be when I first heard about them but when I took the time to study them, it became clear they existed for a reason. Good developers allow themselves to be wrong and then quickly adjust their thinking.

Hiring a team member is more than hiring a code monkey. Make sure whomever you hire is a good corporate fit, is willing to learn from others and most of all, wants to play nice with the rest of the group.

Tomorrow morning I have a job interview. I can't wait.