One of the fun and interesting things that has been cropping up with some job interviews for contracts and employment is the potential employer wanting to know whether someone is actually a good software developer or programmer. The trouble is that there are flaws in just about any way of doing it. Having been on both sides of the desk, I’ve helped hire good programmers and bad – even over the phone – and I’ve interviewed for positions that fit me like a glove or didn’t.

Here’s some things I’ve seen recently – but if you want, just skip to the ‘How To Hire A Good Software Developer‘ part at the bottom.

How Did You Learn?

This is a legitimate question for anyone without a year of experience – to be safe, lets say 2 years. I recall interviewing for a position around 2003 in Trinidad and Tobago – a position for some oil related company about a VB 5.0 position – and I was asked this. With close to two decades of experience on my resume at the time, I explained that it was learned on the job and that I had references on it. But that’s not what they wanted. That people learn stuff in the real world seemed to escape them.

Recently, I applied for an Open Source Consultation position. It’s a natural position for me, really – open source advocacy, familiarity with open source projects and not just how the code works but the communities around them as well as their directions. I’ve even spoken at 4 open source conferences I can recall off the top of my head (not counting smaller group meetings). But somehow, someone in that company thought… If they don’t have a degree in something, even underwater basket weaving, they can’t do the job.

Does a  degree actually help with programming? I’ve seen it go both ways. I’ve met great software developers – yes, some better than me, more than I might like to admit – but whether they had a degree or not wasn’t material. I’ve also met some really poor programmers who had great GPAs. Poor programmers without degrees don’t exist. Why? The College of Experience is not as easily gamed.

Degrees don’t matter unless it’s an entry level position – and entry level positions are high risks for both employers and employees anyway.

Code Samples

There are a few companies out there that ask for code samples and, really, that might be a good way to judge how someone wrote code when they wrote the code – with or without help on a project that may or may not pertain to what the potential employer needs to have done – as opposed to what they may actually advertise for the particular position.

Another problem – one that I run into – is the ever present NDA. Believe it or not, there are companies out there that don’t seem to understand that work done these days is almost always covered by an NDA. Unless you contribute code regularly to open source projects, this may be a pit of despair. My thought: If the hiring company doesn’t understand NDAs, maybe they haven’t worked on things that work with business intelligence.

Fizzbuzzed.

When Jeff Atwood wrote ‘Why Can’t Programmers… Program?”, the Fizzbuzz test became popular with employers unable to design their own tests. A mind familiar with solving academic problems does well with these things. Not all programmers are familiar with solving academic problems. Recently I was asked to write some code that showed the first 10 prime numbers – and in trying to recall the first 10 just as a quiz for myself, I missed a few. I did do the code on the whiteboard, but hey, the point is – the muscles exercised are the strong ones. In programming since the 80s, this was the first time someone thought the prime numbers were important enough to write code for.

Code testing is subjective. This is as it should be. But if you want to do some code testing with a candidate, why not make it subjective to the job itself? Factor in that problems as famous as Fizzbuzz can also be crammed for. Really. Just Google interview code question. Rather than throwing Fizzbuzz or an analog of it out there, why not have a test that relates to the business in the position being filled? That might be a good test. In fact, that should be the test. The candidate should be able to tackle a problem that relates to the position being filled.

What’s special about the position? Test that. It typically includes the skills that you need tested anyway.

The other part of this deals with attitude. Throw a real problem at a real software developer and you’ll get to see how they really think, code and how they approach that problem. People don’t always approach the same problem the same way and that has benefits. The interviewers have to be able to understand that. When trying to make a good first impression sometimes people don’t.

Personality

Personality tests are used here and there and the results are almost never released to the candidate. As someone who has tested consistently as an INTJ¹ for decades, I’ve made it a hobby. To an INTJ, a hobby is a serious thing. I don’t claim to be an expert on personality tests but I’ve read a lot on the topic and have taken a lot of tests.

Some things to remember about personality tests:

• They are snapshots. A personality test is affected by ‘where’ the person is when they are taking the test; stress and other factors change the results.
• They are incomplete.
• They create a great industry for people who make money testing personalities and telling you that you need to do them.

How To Hire A Good Software Developer

So here it is. The magic of hiring a good software developer can be summed up in point form.

• Why do they want the job? Save the ‘World Peace’ beauty contestant speech. If a software developer has everything you need for the position, they can’t grow. A good software developer grows. If a developer has nothing to aspire to then they aren’t a good developer.
• Do they understand your business? A developer who understands the business, even in the broad strokes, is better than someone who can do the Fizzbuzz test in one line (yeah, it can be done in one line in at least one language I know of). Some of the hardest and best interviews I’ve had involved ‘walking the floor’ and being shown the business and the role the developer would be playing within it.
• Can they problem solve? The best way to check is to go over problems related to the business. You could hand them a Rubik’s cube – if your business is about solving Rubik’s cubes. You could have them write code, too, but try to make it at least related to the job.
• Interviews can be nerve-wracking for people on both sides of the desk. A good interviewer harnesses this and can choose to disarm or build pressure – typically both. This is why some companies play ‘good cop, bad cop’ in interviews – but the interviewer has to understand people to do any of this. If you’re pulling someone kicking and screaming away from their keyboard and their social skills are limited to Internet interactions, their body language will likely throw things off. If the interviewer doesn’t interact with people on a social level very well… things can go bad.  And if the software developer being interviewed is a social misfit, the question is whether this misfit will fit in with the other misfits.
• Curiosity. Good developers are curious.
• Thoughtful – not in the ‘brings flowers to funerals and weddings’ thoughtful, but a good developer will sometimes take the time to think through something rather than rushing off on tangents. Rushing off on tangents is typically what less experienced developers do.
• Confident. This is not to be mistaken for false confidence.
• Interested. If they’re yawning, they’re not interested.

Clearly, everyone will approach hiring a software developer differently and it’s no question that they get different results. The trick is not finding the perfect software developer.

The trick is finding the right software developer.

Feel free to comment!

¹Myers-Briggs Type Indicator and Socionics, thank you very much.