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.

Once upon a time, before PCs were routinely connected to each other, smart people backed up their data on diskettes. As time progressed, they did so on CDs, DVDS and so on. The Internet came along. Some people, like Linus Torvalds, quipped about backing up via FTP to servers - an early open source methodology of sharing code instead of hiding it.

Horror stories of a lack of backup abound. It's the sort of stuff that built Norton Utilities - where the undelete and unformat commands became lifesavers for people who didn't backup things on their now ancient DOS based systems.

Now we have clouds. Data allegedly frolics in the clouds, much like toys play with each other when a child leaves the room (Tron meets Toy Story), and clouds are data services provided by companies such as Google and Amazon. With Google, companies large and small share with Google Docs and Gmail. People sleep better at night knowing that their data is being managed by corporations with user agreements that they may not have read but did agree to.

Until you get dumped by Google.

Gmail Risk Mitigation

Now, I can say 'I told you so', and that I use old school email in conjunction with Gmail - I download my email and store it on my computer. That's why I use Seamonkey. My email is only temporarily stored on Google's server and deleted when I download. To share between machines, I use MozBackup. I could leave my emails on Google's servers and hope that I somehow don't create a problem with their terms of service - which does seem to be rare but may not  be as rare as we would like to think.

Of course, I didn't get into these habits because I mistrust Google. I got into these habits when I was in the Caribbean and wasn't sure when I would have a connection. Despite what people might think, internet connections aren't as ubiquitous as marketing departments might have you believe.

And if you want to integrate some PGP, check out Enigmail.

Google Docs Risk Mitigation

For most documents I work with, there's really no need to go further than OpenOffice.org. However, sometimes people want/need to collaborate with others in 'real time' and Google Docs is good for that. Yet, again, if you need to work offline or don't want to trust all your information to Google's Great Cloud of Data, you can backup all your files - something I learned when I was working for a particular company when I was in charge of documentation. There was so much information in Google Docs and only one person responsible (me). Losing access to documents was simply something I wouldn't have happen on my watch.

Get gdocbackup. Use it.

Where's Your Data, Anyway?

As 'What Nationality is the Cloud?' points out, you may want to look into laws relating to your data as well. I'm not suggesting that you wrap your head in aluminium foil, but you probably should know the laws that govern your data - and those laws are subject to geopolitical lines on maps and agreements that have to do with who has access to your data.

Your Data, Your Responsibility

At the end of the day, there are a variety of things that could go wrong - from an obscure failure of cloud-based applications to lack of connectivity (your ISP) to data vandalism. These risks are glossed over by a lot of people because the cloud does make things easier - but it introduces new ways for you to be unable to access your data.

If your data is important then you need to treat it that way. Back it up.

While Google was the core of this article, the same rules apply to any cloud and cloud based services. Don't be the example.

Like many people out there, I've turned entrepeneurial and have been working independently or through consulting firms for some time.

I've made some serious mistakes. I've repeated those mistakes more often than I would like to admit and I excused myself for all sorts of reasons:

• Damn it, Jim, I'm a programmer, not a businessman.
• I need to bid low so I get the job.
• This will be a good company to land work with so I'll sweeten the deal so much that they can't say no.
• I'm against the wall with my bills so I'll have to do this at a rate that I wouldn't like to do it at.

These mistakes are serious and in my life I did learn things that applied but I didn't pay attention to - mainly because I didn't acknowledge the reality of the first: If you are independent, you are a businessperson.

There's some anecdotes that spring to mind.

Marketing vs. Engineering

Back at Honeywell, when I was in the Sensor & Guidance Products Division ("if it moves, we're on it!" was the motto. Really.), there was a lot of pushing and pulling between the marketers and the engineers because marketing was bidding on everything and the engineering end was typically under the gun on the projects over budgets and timelines. In short, we were being oversold.

The new Director of the Division - I forget his name - had a meeting with marketing and engineering. He'd hit the ground hard, made his own assessments and in that meeting he did something that shocked a lot of we engineers. He took marketing to task.

The takeaway on this was that if you win everything you bid on, you're underbidding. That was around 1997.

Engineering vs. Finance

Around the same time, my mentor - the joke was that I was his tormentor - nudged me while I was buying all sorts of texts on the company's expense for research. I was studying up on neural networks and fuzzy logic at the time, and he told me: "People have told me that if I had invested as much time in my financial education as I had in my engineering education, I'd probably not have to work right now."

He was, of course, completely right. And being a tormentor, I didn't realize how right he was.

Beyond Anecdotes

I'm fortunate in that in my life's turns, I've had to suffer poor markets before - trying to find jobs/contracts in Trinidad and Tobago during 2000-2008 was neither easy or profitable. It did, however, allow me to survive and constantly improve my technical knowledge during my downtime. Between my writing and programming, I eeked out a living where others didn't. In retrospect, I could have done better - but that's what retrospect is supposed to show you. You're supposed to look back and see your mistakes so that you don't repeat them.

At present, my contacts in the headhunter and consulting arenas were waiting for the 2nd quarter to start so that budgets would open up. The positions out there that I'm hearing of are of some low budget contracts that will be snatched up and at least some of them will be done poorly. This means that the projects will either end up being abandoned or will go over budget when they have to be fixed later on.

Me? I like to do things right the first time. It costs more up front but the recurring costs are decidedly lower.