How to run a bad interview loop for engineers

I have a little over two decades as a full stack software engineer.
During that time, I’ve held multiple positions of varying seniority as a software engineer.

Each job I got, I’ve been asked to do this thing called an ‘interview loop’.
Not as much fun as a roller coaster, but your heart rate goes up all the same.

Funny story, I once interviewed even when I didn’t want a job.
Just wanted to move to a different team.

All that just to say, I’ve been interviewed quite a lot.
I’ve also interviewed quite a few candidates too.
So, I feel like I have the qualifications to write about bad interviews.

I’ve sat through bad interviews, and good interviews.
Some interviews were bad, because I wasn’t doing well.
Others were bad because the interviewer was bad.
Still others where the interview itself was bad.

The worst interview I recall was when the interviewer became visibly annoyed by my apparently inadequate answers.
To a question that was hypothetical.
Something like: ‘how would you roll out a risky release to a large organization?’
I instantly questioned all my life choices that led me there, and promptly rolled back the release.

The interviewer’s body language matters a lot in interviews.
They might think that it would be deceitful to put up a fake smile.
And they’d be right usually. But!
The interviewer is not there to build a relationship with the candidate.
It’s to answer the question: ‘Should we hire this candidate?’

In the first couple of minutes the candidate makes up their mind by the interviewer’s demeanor.
They know whether they want to be in this room or not.
Their stress levels skyrocket, and an already uncomfortable situation is now agonizing.
Any chance the interviwer had to get data from the candidate has now been tainted.
The whole reason the interviewer is sitting there is to collect data about the candidate.
Data? Yep, data.

Probably the most important thing I’ve learnt over years of being an interviewer is:
The interviwer is there to collect data about the candidate.
It might seem odd to reduce a complex human being to data.
The alternative is worse.
It’s worse to have an ‘intuition about the candidate’.
That the interviewer goes by ‘feel’.
That introduces all kinds of biases into the interview, and the team ends up hiring the person they like.
Not the person who is most likely to succeed at the role.

I once applied for a position at a company whose product I really liked.
I wanted to work on that product.
It was just so cool, and I was so excited.
The interview started, and we introduced ourselves.
It was comfortable, the interviewers seemed nice, I was confident.
I traditionally do pretty well with coding challenges.
Then the problem was presented.
It was fairly challenging, but doable; I eventually solved the problem 🎉.

Then things got a bit confusing.
They didn’t like the solution, they ask if I can improve on it.
It works, they say, but it’s not performant enough.
No problem, I ask questions about what they want, and they give me some hints.
I ask them why they would like me to do this during the interview.
They say it’s because they’re trying to find candidates that can handle complex problems. And solve them in a performant fashion.
That’s just how daily life is like in the company.

No problem, I think.
I ask questions about what they want, and they give me some hints.
Problem is, that I’ve used up most of my time to solve the problem.
And it’s a decent solution.
There’s definitely a faster solution out there, but this one’s not bad for 20 minutes of work.
Coding under scrutiny only exists during these coding loops.

I start thinking, but the answer is going to require me to do it all over again.
And even then, I don’t know if the idea will work.
I’m also running out of time.
I’m starting to get a bit stressed, and frustrated.

After tearing down the existing solution, and furiously trying to figure out the performant answer, my worst fear is starting to realize.
I’m not going to do well on the interview.
On the contrary, I’m bombing it.

We all see the writing on the wall as time starts to run out.
I’m stressed, embarrassed, and feeling quite dumb.
I give an overview about the approach I was taking; Not confident that it would actually solve the problem.

Then they hand over the mic to me, and allow me to ask questions.
I ask them what was the most complex problem they’re solving right now.
There were two engineers interviewing me.
I asked them both separately.
I wanted to know what the day to day life was like for this company that I obviously wasn’t going to get employed at.

First engineer: We’re currently moving from a monolithic architecture to microservices.
Second engineer: I’m between projects, just doing some bug fixing.

Well, that was a bit of a let down. Even an algorithmically challenged engineer like me could do that.
More importantly, why did they want me to solve that problem in that way, then? I thought.

The best tool to not fall into this interviewing trap, is to ask the following question:
‘Can this candidate succeed in the role they’re applying for?’
In the case of my interview, I think my poorly performing solution gave them a good enough idea that I can code.
From a coding — and migration to microservices stand-point — that should have been enough data.

Some companies tailor their engineering interviews to find engineers that can spit out complex, niche algorithms at the drop of a hat.
I don’t see the point of that.
In my decades long engineering experience, I have never encountered a situation where any engineer had to come up with a complex algorithm in 45 minutes.
So, why are hiring loops like that then?
Because someone thought that coding is problem solving, and thus the engineers that can solve the hardest problems are the best engineers?

Which is probably true. I’m a mediocre engineer at best, I admit.
Unfortunately, though, modern software engineering is more than coding.
Engineering is working together with other engineers to solve a big problem.
Engineering is communicating effectively.
Engineering is understanding what kind of product to build.
There are parts of it where you need that spark of brilliance.
But those things are hard, and they take time.
Seldom does a question comes up that requires a nlogn solution to find the smallest three numbers in a 10 Terabyte array.