Imagine an actor going for an audition in a West End play – this actor has played the same part before in several productions and they’ve played a smaller part on the West End stage before, too – you could say that they’re likely to be a great fit for the role. When they arrive at the audition, they walk on stage and are ready to give the audition of a lifetime, impress the Director and get the part. However, just before they start, their hands are tied, their feet are tied and they’re blindfolded.
Surprisingly enough, the actor is unlikely to perform very well and will be unlikely to get the part, even though they would probably have been great for it.
Now to the point of this: Why are developers given hand-written tests to do at interview? (This is a genuine question that I'd love the answer to.)
My actor analogy is probably a little dramatic… but I think the point is a good one. I’ve written a lot about technical tests for the developers I work with – some love them, some hate them, some cheat on them, some completely refuse to do them. The simple fact is that clients still feel the need to give them out, generally early in the interview process, to gauge how technically capable a candidate is. Fair enough!
However, testing someone with a pen and paper for a job that’s on a keyboard, someone who spends their working day and likely a large portion of their spare time on a keyboard, doesn't make sense to me. I’m not talking about planning and designing something on a white-board, that’s likely to be part of the job and clearly a skill that should be tested at interview, I’m talking about; ‘here’s a notepad and biro, write me some code’. Anyone non-technical (like me) who’s ever seen a developer actually write code for the first time would be astonished at how quickly the syntax appears on the screen. This is due in a large part to the vast number of shortcuts and hot-keys they use in their development environment and will always use when they code. When these tools are taken away, just like the tied-up actor, the candidates are unlikely to demonstrate their skills to the best of their ability.
It’s not just the format of the test, the content can often be baffling as well. It tends to be a trait of the larger firms, but the one-size-fits-all test means that more-often-than-not, the best candidate for a specific role is not going to be the one who gets the job. This will be the subject of my next article / rant.
Dear hiring managers, if you’re going to set a technical test for candidates, please make it relevant to the role you’re hiring for and not just the one your firm has always used across multiple different teams, otherwise it’s unlikely that the best person for your role is going to be the one who gets the job.
I'd really like to understand why written tests are given - all answers gratefully received.
In Conversation with Jon Butler at FIX Americas Trading Conference | FinTech Focus TV with Jon Butler, Co-Founder and CEO at Velox
By Laura Weeks
Building Exceptional FinTech workplaces: Ten Strategies for Success
By Nadia Edwards-Dashti, Co-Founder and Chief Customer Officer at Harrington Starr Group
Embracing Accessibility: My Personal Journey | The Financial Technologist
By Kris Foster, Co-Founder of Open Book and Office Engagement Assistant at Thredd