The Secret Interview Code That Means You’ve Failed
Photo by Alexander Jawfox on Unsplash
I’m not perfect in any sense of the word.
I make mistakes. I even make mistakes in tech tests when I’m trying to job-hop. That’s how I learn.
I’ve learned the secret phrase that means “you’ve failed” during the interview following the submission of a tech test.
“I’m curious as to why…”
As soon as this phrase is uttered there is no way that you will have a positive interview.
Here’s what is happening, why I’m simply bewildered that this is allowed to happen in interviews and I finish by proposing my solution.
The Situation
I’ve been trying to think of a way to easily explain my *stupid* mistakes in tech tests that a wide audience of software engineers will all understand.
So I can take my tech tests from a few years ago when I was a little greener than now (so please don’t judge me too harshly for being junior).
Sometimes on a property I incorrectly set the access control on fields in a class. This happens when I rush through the challenge and don’t pick up that the properties can be private.
I’ve discovered that this is simply because at the time I was a little junior. Not setting the properties to private showed that on a first pass of writing code, I just wanted to get it working, and only then would think of things like access control as “nice to have” and I would therefore fix this towards the end of development. A this point there was too much to do and I might miss a class or two in my submission. [Note today I can find these errors by simple use of AI in my code, and I have also changed my working style so don’t panic everyone].
These mistakes happen. Yet invariably my tech tests would pass, and I went through to the technical interview stage. This is where the problem starts.
The Tech Interview
One of two things happens during the tech interview.
Either:
The interviewer does not pick up these small mistakes
The interviewer picks up on the mistake, and there is no chance of passing the interview
The first case does happen. At the level of mid/junior, there will always be some minor mistakes, things that could be picked up, but the interviewer sometimes seems not to notice or decides not to pick up on these (do they think they are trivialities? I don’t know). I got hired by Revolut with these mistakes in my tech test.
The second case is where the interviewer stops and asks :
“I’m curious to know why these properties are accessible from outside the class.”
I’ve been in this situation a few times, and I know there is no way out from this question. If you admit that it is a mistake you’ve failed the interview. If you justify that in this case, for this class, it might make sense to make the properties available but yes it might be premature optimization you’ve failed the interview.
As soon as you’re asked the question “I’m curious as to why…” the interview is over.
The Issue
Oftentimes one person reviews a tech test, and one person interviews candidates. This means plenty of bias can be introduced to the interview process, and candidate’s times is wasted by disagreements between team members.
For the example above of access control, it is wrong to make properties accessible from outside a class when they can be private. Yet the code works, and it is the type of trivial mistake that can be found in code review. Everyone makes a mistake sometimes, and in 1000 lines of code written after work how many such mistakes are acceptable — if the answer is zero why do we need code review?
This means one team member “passed” the code and the candidate to the next stage, but then the code is reviewed again by another team member and “failed”.
The candidate cannot give an acceptable answer for such a mistake, and therefore during the interview they have already failed. The result of this is that time is wasted and inappropriate feedback is given.
My favorite feedback from this has been “Didn’t know enough about good software engineering practices.”
Sigh. Just say I make too many mistakes.
The Solution
Why isn’t there anybody who looks after the process end to end?
How are standards maintained, and make sure that one single developer making decisions about a candidate does so, based on data and team fit, rather than their own opinions?
The question is where is HR in all of this?
I’m claiming that this is the answer. We should have dedicated HR people who understand the technical details and can make hiring decisions — but crucially are not simply developers. This would require extra training and a different emphasis on their job.
Conclusion
I’m currently working on techniques to stop making any mistaes in tech tests. Sure, that means using AI and getting people to review my work.
I wish interviews were more like my day-to-day work. How about allowing AI in interviews for a start?