The Most Ridiculous🙀 Tech Interview Feedback I Ever Got
As software developers, we should carefully consider the feedback we receive. We might receive what I might term trash feedback which is either inaccurate or not actionable — like being told you need to work on technical skills in an appraisal, or that you aren’t professional.
During some recent interviews, I’ve been given some feedback that is even worse than that. I’m starting to wonder why companies give feedback to unsuccessful candidates if it turns out to be so low quality, and I’m curious to know who it benefits?
In this article, I’m going to go back over my interview history and let you into some of the most downright ridiculous, nonsensical feedback I’ve been given during interviews. Are you ready for it?
Both Too Strong Opinions and Too Flexible Opinions
This is a recent piece of feedback I’ve received from a technical interview. I think they thought they were being honest.
“You have strong opinions about your own code, but were too flexible about code generally”
I get what they mean, but the fact they explained it so poorly is telling.
Let me explain the situation. I handed in a tech test with a couple of dubious decisions.
From there I decided to go in hard and defend what I’d done. This resulted in the strong opinions feedback.
Later they asked me if I would block a pull request using network objects in business logic. I said it depends on the team, I’m flexible — a classic “it depends” argument. They wouldn’t take that for an answer and kept pushing. I eventually said that I would block the PR but it appears that they remembered the word flexible.
The result is the feedback that I have both too strong opinions, and am too flexible.
The feedback they should have given: We don’t like you, and the decisions you made were wrong.
Your Experience is Not Quite Right
I interviewed for a small startup. I decided to think of a compelling reason why I’d want to work for them even though for me it wasn’t an exciting opportunity.
As in any interview I needed to justify why I would want this position.
So, I said:
“I’ve worked for massive companies, and tiny ones too. Working for a scale up would really excite me because of the opportunities it would give me”.
I felt this is an argument that would be compelling to an employer. I’ve relevant experience, and I’m excited for their company (I’d earlier laid it on to think about the values and product).
Here is the feedback from the company:
“Has never worked in a set-up quite like this, has always been in a much smaller company or much larger company.”
I understand this is their feeling. If you haven’t worked in a company just like ours that is a good reason to reject. However, that’s going to limit the pool of potential employees to those who currently work in your company, right?
The feedback they should have given: It is clear from other feedback — “couldn’t always get a sense of what they were trying to say” that they really didn’t like me.
Too Technical
I went for a technical interview and got this feedback (in the cons section):
“Their instinct was always to talk about the tech”
A technical interview for a software engineer gave me this feedback, to be clear. I usually think that you’d want a programmer to be interested in the technology they’ll work with, but obviously not in this company.
The feedback they should have given: Talked too much.
Bored
“You might get bored not doing new things all the time. Also, you’re too junior.”
The classic “you’re overqualified and underqualified at the same time.”. If I’m too junior I’d need to work hard to get up to speed, so how would I be bored, exactly?
The feedback they should have given: We want a unicorn who can also perform magic tricks at the company picnic.
Software Engineering
“You didn’t know enough about good software engineering practices.”
This followed a pointless discussion down a tangential tech rabbit hole. They found an area I was weak in and kept asking, asking and asking until I couldn’t answer. I don’t see what that has to do with software engineering practices honestly.
The feedback they should have given: We rate you on your weakest areas, not your strongest.
Conclusion
It seems to me that tech interviews are more about fitting into a company’s unpublished specifications for an employee rather than assessing their abilities. I used to think that job descriptions were there to help candidates and were written honestly, but I no longer believe this.
As developers, we should take such feedback with a grain of salt — understanding that it often says more about the company’s internal confusion than about our own skills.