Yesterday, I failed a technical interview. It happens, and that's OK[0]. But this one left me with a pretty bad taste in the mouth: I didn't feel I was rejected because I hadn't met the company's standards, or because I made a mistake, but mostly because I was tested for something completely irrelevant for a developer job.
The technical interview wasn't a conventional one, it was one of the new fancy “automated interviews”, where you log into a website and then you're being given instructions and a tight time limit. When the limit expire, your code is checked against an automated test suite and you're being given a grade.
For the HR's perspective, it sounds awesome: you have a very cheap way to screen dozens of candidates without human interactions. No more false positive, every candidate passing the test must be “technically proficient” and all you have to do next is assess their social skill.
Unfortunately, these kinds of tests are very bad at measuring technical proficiency of a developer. To understand why, you need to understand what a developer's job is about.
A developer's job isn't to write code: the role of a developer is to turn someone's needs (1) into a product (2). We do so by writing code(3) as part of a development team (4).
(1): a big part of a developer's job is to ask questions, to clarify the needs. You want me to write a program that converts a camelCased
string to kebab-case
? OK, what do you mean by “camelCase”? Does this string: PascalCase
counts as “camelCase” in your mind? And how about acronyms? And numbers? And emojis? Are your input always gonna be well-formatted because they have been validated, or do I need to handle the situation when I'm being given a string which isn't “camelCase” in the first place? What do you want the program to do if an error occurs? Send an event to your telemetry system? Print a stack trace? A user-friendly error message? If so, should the message be internationalized? As you can see, there's no such thing as “a program that does X”, it's all about clarifying the stakeholders needs. And there's nothing worse than a developer who starts coding as soon as they think they understand the specification, without asking any questions to be sure that their understanding is aligned with the needs.
(2): a product is more than a piece of code, and sometimes your users' business depends on your product working as intended. How you make sure your code is working, how you monitor when something goes wrong and how you deal with failures in production, are what makes the difference between reliable and bad software.
(4): a developer almost never works alone: reading someone's else code, writing code that is easy to understand and maintain by your coworkers, and using a version control are fundamental skills for any developer.
[0] : to be honest, it's the fifth time in eleven years, and I've always been pissed off after failing a technical interview, but I'm usually mad at myself for being bad.
[1] : https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/
[2] : https://deepmind.com/blog/article/Competitive-programming-with-AlphaCode