What are the "best" requirements (or what does one look for) when hiring a software developer?

Question

Hi guys,

I'll make this a community wiki seeing that there's no exact correct answer.

I've started a project (which I'm proud of) and due to the demand of the requirement, I need to hire developers (mostly java and C++). Now, I know there are some who are java certified and some are qualified computer scientist. In my work experience, I have worked with qualified people than I, but simple things such as design patterns, OOP, etc. were just "clueless". Some found it hard to even implement Fizz Buzz.

My question is this: What are the requirements to look for when hiring a software developer? A highly qualified developer with intellectual knowledge but implementation is poor or someone who lives as a "bedroom" coder and eventually harnesses his skills professionally?

Answer 1

Well, I don't come from a hiring background. But if I was looking for someone to work under me, I'd like someone:

• Passionate about programming ( it would suck to have some one that doesn't care about their work)
• Someone that can solve problems. (Problems more difficult that fizzbuzz :P )
• Isn't afraid to learn new things

But, I guess in the interview phase, I'd throw some reasonable problems for them to solve and take close note at how they approach the problem. :)

Answer 2

I normally look at the social side more than on pure technical skills. If someone knows how to develop in general and I have the impression that collaborating with her or him is fun, that I would prefer that person over someone having exactly the technical skills, but who cannot communicate clearly.

You can more easily learn some technical details, especially on a background of some other technical skills than change your attitude.

Answer 3

I've been involved in hiring when my start-up was expanding. Our primary thing that we looked for was skill with object-oriented programming. (We have complex OO code, because of the problems we try to solve). The exact language experience was very much secondary to that.

Programmers who can do the OOP paradigm can generally learn new programming languages on the job. The reverse is not true. (edit:) So if you've got some particular sort of problem you're working with, consider if it's really programming-language specific, and whether you really need to say "N years experience with programming language" or whether that will unduly narrow your field of candidates.

Answer 4

For technical requirements, I have found this simple question to be very effective:

In your programming language of choice, write a function/subroutine/method that takes a string argument and reverses in place.

If they answer that, then most probably they've got the technical basics covered and can learn the rest as they need it, provided you're willing to invest in them.

I would rather have a rookie who is humble and understands the basics than a buzzword-laden developer with an attitude and sloppy execution.

Answer 5

"Write a Singleton in any OOP language. Just the very basics." - shows if they have a clue.

"How many spare-time projects do you work on a year?" - shows if they actually like programming.

"Google or Apple?" - shows if they are awesome or an asshole.

Those 3 questions can't fail you.

Answer 6

Ask, "How would you design X?"

Copy-and-paste programmers will tell you in exacting terms exactly one way to do it. They'll know exactly one way, because they've been taught a cookie-cutter method, and every day they cut the same cookie, over and over.

Real programmers who can think will discuss several ways, comparing the pros and cons of each.

Really good programmers will discuss several ways, and ask you what your constraints are. (E.g., time costs versus space costs, ease of implementation versus extensibility, programmer time versus maintainability.)

Answer 7

Definitely read (several times) Joel's Guerrilla Guide to Interviewing.

Then make your peace with the fact that finding a good developer is a long and painstaking process. Also review your posting and ask yourself whether the job description and qualification description is something that is going to attract a decent developer.

Answer 8

Assess productivity:

• Can the person work as part of a team, or are they likely to work in isolation. Isolation reduces productivity no matter how good you are.
• Do they think about the process of what they are writing? Everyone looks for people who understand and design their work before just pitching in (+1 productivity) but do they look for new tools and approaches which would make their lives easier and their code more maintainable (productivity multiple).
• Do they think anyone who is less capable than them is an idiot (- productivity) or do they try and mentory others to their own standard (productivity multiple).
• For juniors, will they resist being treated like an idiot for not knowing, find mentors and grow or just sit and sulk.

Just one dimension obviously - the ability to write some code would be nice too.