Filed under: Recruiting, — Tags: Clean code, Good software developers — Thomas Sundberg — 2014-12-31
You are recruiting a new software developer to your team. How can you decide that this candidate is a good candidate?
The only good way I know is to work together. And do it for some time, preferably a few weeks.
Working together is unfortunately not an option when you evaluate if you want to hire this candidate or not.
Before you can decide if the candidate you are evaluating is a good developer or not, you have to decide what you think is a good developer.
My opinions are that a good developer writes code that is
Given this list, you may think that code is the only important criteria. Code is important, but it is not enough. Evaluating the code can sometimes be done by examining code the candidate has written in other projects. But the value of examining the code may be limited since the only thing you see is the end result.
Other qualities that are important are
These qualities are almost impossible to validate unless you actually work together. But the purpose of this evaluation is to decide if you should hire this candidate or not.
And as a disclaimer, the list above are not exhaustive. There are more properties that are important.
I have seen recruitment procedures where the candidates are requested to solve, sometimes pretty hard, programming problems in a very limited time. This is always done unattended and it is impossible to know how the candidate approached the problem. The only thing you see is the end result.
Coding challenges usually don't measure anything but the ability to create an algorithm under time pressure. And the ability to search Stackoverflow for the solution. These may be desirable skills, but they are not what separates good developers from bad developers. The interesting part is how the developer approaches the problem. The approach often says more about the candidate than the actual solution.
I once did a programming challenge that should be sent to the company recruiting. They had prepared a task resembling the domain they are working in. I did the challenge, sent it to them but was never able or allowed to comment on my solution. The result? They claimed that I hadn't done any refactoring. They based that claim on one data point. I didn't get the assignment and I am glad I don't work for a company that are so uninterested in getting good developers to work for them.
If I got a similar challenge today, I would probably create a GitHub project and host my solution there. I wouldn't share my solution unless I was able to look at it together with the evaluator and comment on my solution as well as motivate why I used one solution over another. Why didn't I use inheritance to avoid duplication? I can motivate that if I am able to talk to the evaluator.
I have asked candidates for code sample after many interviews. It often gives me a feeling of how they write code. It doesn't tell me anything about their approach to a problem.
It has, however, happened that the samples I received were so bad that I got good reason to terminate the recruitment.
I have also found code a candidate host on GitHub. The candidate was late so I had time to browse the code for a Maven plugin he had written. It was an interesting experience. The code was badly written and it alone gave me a reason to be sceptical. It turned out a few minutes later that the candidate wasn't even showing up for the interview. He was never offered a job.
The value of code samples may be very limited. It is hard to say that a candidate is a good developer based on a code sample. It is sometimes possible to determine that this is not a good candidate for a programming job.
Checking references are common and definitely worth doing.
I once called and checked the references for a candidate. The answer I got was very positive. Working with the person for a while revealed that this particular person was far from good for the job. Writing tests without asserts was perhaps the thing that got me most upset. Especially when you claim to be a professional tester that works with test automation.
In perspective, I have a feeling that the person I spoke to almost wanted to get rid of the candidate and was happy that we were interested of working with him. The negative part of this is that I know the reference and usually have reason to trust her.
References can be good, but not always.
If you have a personal contact that you trust, call that contact and try to get an opinion about the candidate. But be aware that they still might not give you the entire picture.
My approach next time I am in charge of a recruitment will be to
This will take time, but spending half a day up to a day on evaluating someone who is an interesting candidate is probably well worth the time and effort. The cost of a failed recruitment is high and avoiding that cost by spending a few additional hours getting to know a candidate is probably a low price.
RSS