Very few people like tests, particularly developers, and especially in interviews. During my career I've hated doing code tests, I've avoided them like the plague, or at least as much as I can...
Recently Gearloose Jones wrote on Dev.to that we should do away with the test...
What's worked for me - and I'm speaking from experience on both sides of the interview table - is that you put the coding test away; you put the whiteboard marker down. Probe the candidate for general knowledge about the language in question.
I have a lot of sympathy with this view. Developers, like everyone, are complex amalgamations of skills, knowledge and experience. They cannot be quantified by a test. In addition the best developers are not those who are simply great coders, they are those who always want to learn more and have good communication skills. And you can't spot that in a test.
However, while I sympathise with the 'no test' view I don't fully agree with it. I've come to this belief since I began managing and hiring developers. My strongest argument in favour of the code test is that if you just talk to someone there is a significant chance you will get burnt. And that one time you hire a bad developer will cost you, both emotionally and financially.
The reality is that some people are very good at blagging. They will tell you what you want to hear, and they will know just enough to achieve this. For example, someone successfully explaining what polymorphism is doesn't mean they know how and when to use it. Blagging occurs a lot in industries where the rewards are high, as they can be in software development. Therefore it is imperative that you run some sort of test to validate capability.
If you are going to run a test though it should be part of a process, not a filter. It also has to be the 'right' sort of test. The obvious reason for this is you may miss the good candidate because of a poorly written or interpreted test.
My view is that tests should follow similar rules to these...
- A test must be non-binary. It should not be a test that a candidate passes or fails.
- The test should be short. Don't waste people's time.
- The test should focus on a core principle. Not build me something.
- You should speak to the candidate, even if it's just for five minutes on the phone.
The most important part of the code test is that it is non-binary. The test aims to spot where someone is on the junior to senior spectrum. It does not judge whether you should hire them, that they can code to your standard, or that they will work well with you and your team. It is not pass or fail! The only way you can judge if someone will work well with you is by meeting them and speaking to them.
As an example, I have written and used a test that I've placed on GitHub. The test is a simple array based test, it's not perfect and it may not be the test you choose to run. It is though non-binary, it can be solved in a number of ways, it is short, and it focuses on a core principle, array manipulation. As part of a good interview process a test like this will help reduce the likelihood of hiring a bad developer.
Hiring people is one of the most challenging tasks a manager or lead developer will face. It requires time, patience and a mixed approach. This will include both a test and face time, there is no shortcut sadly.
Top comments (0)