Hiring Tests
January 20th, 2009[ Office Gossip ]
I was part of a working session at BOS with the topic of ‘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. The point being it doesn’t accurately reflect how they’ll function in the real work setting.
The issue with most interview testing is that the test environment is completely unlike the real work environment. Maybe I’m naive but isn’t the fix to make your test environment as much like the real work environment that you’ll be requiring that person to function in?
Are you hiring someone to stand in front of a room full of strangers and write software on a whiteboard with no outside resources? Or 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 leverage all the resources available, work alone, 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 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. We’ve benefited from leaving it open ended, it gives us a view into how the person is able to leverage opportunities. Do they take a few extra steps like ensuring the application will install and run? Maybe add some features relevant to what you’re company is up to? Do they go too far and bloat the feature set and UI? All of this is great information for you in assessing where this person may, or may not, fit into your team.
Then sit down with them and their resulting application, run it and walk through the code. You 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 run? It’s amazing what a difference it makes to talk about real code instead of fictional examples.
The goal isn’t to filter people, it’s to give candidates an opportunity to shine and truly show you what they’re really capable of in a setting reflective to your working one. Hopefully it allows you to find the people who best fit with your team.