Why Companies Should Run Tech Tests on Existing Software Engineers
Photo by Patrick Fore on Unsplash
Many companies implement convoluted and long software engineering interview processes. Once a company has thought of a series of questions, they are happy to let employees coast and as long as they push new features and squash bugs, what’s to worry about as we have vetted and checked our employees?
Let me step in and say I think things can and should be better. Interview processes aren’t of sufficient quality, we don’t train interviewers, and we don’t improve our current staff sufficiently.
I think I can help solve a couple of these issues at once. Who is with me?
The Status Quo
The Interview Process
As far as I can see most companies keep their interview process in place for years. The questions “were good enough for me, so they’re good enough for everyone else. Most take a mix of data structures (+ algo) questions and a series of quiz questions about the target technology. The answers to these questions are on a shared drive or CRM so interviewers have access to the answers.
Once You’re Hired
Most companies seem to operate under the delusion that once you’ve hired a person everything is set. The employees’ skills remained honed forevermore, and what’s the point in tracking perfection?
Even if our people copy-paste answers from Stack Overflow we know they’re good developers as we tested them, right?
A Reality Check is Needed
I’ve been through a few interview processes recently and I can confirm that interviewers cannot answer the questions they’re asking.
I know this because at times I give answers that are not the textbook answer because I’m *good*. That is, I listen to the question, ask follow-up questions and then give an answer rather than a tinned memorized question. I’ve found to my cost that this strategy sometimes elicits a response where (after my initial question) they simply tell me the answer.
“WTF? I ask a clarifying question so I can give an answer. That doesn’t mean I don’t know!”
I’ve questioned myself. Am I being unclear? Does it appear that I’m asking for help rather than clarifying the question? I’ve discovered that the truth is somewhat different. The interviewer has the question and answer written in front of them and is unable to deviate from that.
They’re doing the interview equivalent of copy-pasting from Stack Overflow, and it isn’t good enough.
The Solution
Imagine, just for a second, doing this.
When you have the idea for a tech test you run it on your current team. I don’t mean run it by your current team I mean get them to take the test.
They’ll find problems in the test and streamline it for you with their feedback (win).
You’ll get results and be able to understand how well your developers can actually code (win).
Perhaps your rock-star coders are looking a little like one-hit wonders? No problem — you process your results into a skills gap matrix. You know now where your developers need a little bit of work.
You are now able to invest in training. You don’t throw down some Udemy coupons, you are actually able to work with your staff and understand what they need to improve together. You can allocate time during working hours (because, honestly, you need to). Suddenly that company value of “continuous learning” is one you actually live by.
Your candidates would have improved tests. Your colleagues would be involved in improving your recruitment process. Your software engineers would have improved training.
What is not to like?
Conclusion
It’s a fast-moving industry. Staying static means future unemployment for most.
With that perspective running tech tests on your existing staff and implementing training programs isn’t just a good idea — it’s essential for survival.
So go ahead, take the plunge. Your team might hate you for it at first, but they’ll thank you when they’re not replaced by AI (for at least another few years).
After all, ignorance might be bliss, but competence keeps the lights on.