Hiring Great Developers

September 4th, 2008
[ Office Gossip ]

I was part of a working session here at BOS where the topic was ‘hiring and keeping great developers’. The topic of testing in interviews came up. The majority of people agreed that testing was important, however, they acknowledged fundamental flaws in that people could be nervous, feel rushed, etc.

So what’s the problem with tests? The test environment is completely unlike the real work environment. Maybe I’m naive but isn’t the simple fix to strive to make your test environments as much like the real work environment you need that person to perform in?

Do you need to hire someone who can stand up in front of a room full of strangers and write software on a whiteboard with no outside resources?

Do you need someone who can sit in a room alone with pen and paper and write pseudo-code?

I doubt it but if you do, you’re in luck. Most of the existing testing environments are perfect for your company. If, however, you need to hire a developer who can make use of all the resources they can find, work both alone and with a team, and produce creative solutions to stated requirements then keep tweaking your test environment to get as close to that setting as you can.

Cooper design has been doing this for years with their interaction design exercise. Recently we started using simple developer tests for both brainpark and boc meant to put the candidate in a truly work-like environment.

How? Find a simple tutorial publicly available on the net that’s technically related to your work. The tutorial should take the average person 1 to 3 hours to complete and should end in a functioning application. With brainpark we use the django tutorial. We have the candidate go through the tutorial on their own time with their own resources and then submit the code when complete. You could provide clear directions such as satisfying a requirement not in the tutorial or just leave it open ended.

Then sit down with them and their resulting application, run it and walk through the code. We now have the opportunity to discuss real code…why did you extend that class? would that method be difficult to maintain? Why doesn’t your application start?

The goal is to give candidates an opportunity to shine and truly show you what they’re really capable of.