Why It's Time To Stop Complaining About Technical Interviews

Interviews are part of every hiring process.

And, software engineering is no exception.

Yet, why is it that so many software engineers complain about technical interviews?

Think about it:

Before you write someone a job offer, you need to be confident that they can actually do the job.

What's all the complaining about? Is all this complaint justified?

Today I'm going to explain why software engineers hate technical interviews, even though it won't change anything, and what you can do about it.

People Love To Complain

There's got to be something rooted in human psychology that explains why we like to complain so much.

Did you read Robert Sweeney's LinkedIn post about how he turned down Daniel Buchmueller for a position at Netflix [1]?

That sparked some pretty interesting conversation on Hacker News (as usual).

It also sparked a few blog posts written in reaction to it.

Some of them brought up how senior engineers nowadays are going to be in for a rude awakening when they go back on the job search.

Others brought up Max Howell's tweet from 2015 and his thoughts on Google's interview process [2].

Let's face it.

With all these people complaining, SURELY all these tech companies must have gotten it completely bass-ackwards.

Or Have They?

Here's the bottom line:

This style of interviewing (algorithms/data structures) is here to stay as surely as it'll get dark tonight.

So quit your bellyaching, and senior engineers, I'm looking at you.

But I do get it. There is something a little strange about putting senior engineers through the technical interview process.

After all, here is an engineer with years of experience and a proven track record of building applications, driving innovation, and mentoring junior engineers.

How on earth could you possibly filter this information through a 60 minute technical interview? Classic case of putting a round peg through a square hole!

Nope, Not Bass-Ackwards

At this point, you're probably thinking:

"Exactly! You see? This whole thing is broken because you're measuring senior engineers with a broken yardstick. Terrible!"

And that's exactly the point!

As a company, interviews need to be objective and measurable. There needs to be some way to say, "Candidate X performed better than candidate Y by arriving to a solution that was better in performance by measures A, B, and C".

While it is possible to gauge an engineer's experience through a STAR interview, it's not really enough to hit a senior engineer with only behavioral questions.

After all, you can kind of fake your way through a STAR interview, but there's no way to fake through a technical interview.

All Riled Up

But what is it exactly that gets us so riled up about technical interviews?

After all, technical interviews assess computer science fundamentals by asking the candidate to manipulate a data structure, or modify an algorithm for a specific problem.

Sounds fair right? What's wrong with this approach? Aren't CS fundamentals important?

True, but computer science fundamentals don't take into account an engineer's experience!

Think about it:

Whenever you hear someone complain about technical interviews it usually sounds like this:

I have nearly X (usually 12+) years of experience building critical applications in the Y sector. Millions of people have used the software that I've written. I've done everything from (older) Technology A to (modern) Technology B and yet can't get a job because of these algorithm/data structure type questions.

What's really being said here?

I've been building large scale mission critical applications for X years and never needed to know this. Why are you asking me this? Questions like these are NOT a good indicator of my future performance.

Questions like merge k-sorted lists or detect a cycle in this linked list are absolutely useless at probing a candidate's experience.

So Why Are They A Thing?

We know it's a flawed process. And yet companies keep asking them.

The bottom line is:

Despite all its flaws and shortcomings, it's the most objective and measurable way to assess a candidate's future performance.

Besides:

Most people are thinking about interviews in the wrong way.

Interviews are not to find the star candidate and make that person an offer.

Instead, interviews weed out unsuitable candidates that would do more harm than good.

You can group candidates into 3 buckets:

1. Great candidates. Sharp as a tack, enthusiastic as hell, and a pleasure to work with.
2. Good candidates. With mentoring, they'll be real heavy hitters.
3. "Stay away" candidates. These are not worth the investment to mentor.

Now it's obvious right?

Interviews are used to filter out those in the 3rd bucket, leaving you with those in the first 2 buckets [3].

Put on your thinking cap:

It's an optimization problem where you attempt to minimize the number of 3rd bucket candidates that you let into your company. And the algorithm used to solve this problem is not perfect.

True, that might mean losing out on some great candidates, but that's preferable to the alternative, which would be detrimental to the business.

In other words:

Technical interviews may produce some false negatives. They're not 100% accurate at detecting qualified candidates.

But they are almost certainly 100% accurate in determining unqualified candidates, which is a tradeoff most companies are willing to make.

A Word Of Advice

If you're fresh out of college and looking for a job in tech, get used to these types of interviews.

If you're a senior engineer, get used to those questions too. They're not going anywhere. Their one redeeming factor is that they're measurable, unlike the Microsoft brainteaser questions of old.

Luckily, since more and more companies are asking these types of questions, it's getting easier and easier to prepare since websites like leetcode and hackerrank are crowdsourcing these questions into a single place (for free!).

The bottom line:

While some of the complaints are valid, I don't have any sympathy.

There's too many free resources on the internet where you can practice on questions asked in real interviews for there to be a real issue [4].

P.S. Keap Is Hiring

Read this far? We're hiring for a variety of engineering positions at Keap. Come check us out. Go ahead and click it. It's right there.

---

[1] Robert Sweeney's LinkedIn Post

[2] Max Howell's Tweet

[3] Tech interviews remind me of the 40 yard dash at the NFL Combine. No other event in the Combine receives as much attention as it. Doing well in the 40 could mean the difference between a Day 1 and a Day 3 pick, and a much more lucrative contract.

It's not just applied to the more skilled positions like running back and wide receiver. Everyone needs to run a fast 40.

But is it really a concrete predictor of success? It's dubious at best. Consider Tom Brady's 40 time of 5.28 seconds with 6 Super Bowls under his belt.

Why does a quarterback even need to run a 40? Sound familiar?

[4] Check out leetcode to practice specific questions, and the github tech interview handbook for general preparation tips.

back

---

---