DEV Community

Cover image for What's Wrong with the Tech Interview Process?

What's Wrong with the Tech Interview Process?

Brian Rinaldi on September 20, 2019

There seems to be a growing consensus that the interview process often adopted at tech companies for hiring technical staff, in particular develope...
Collapse
 
daedtech profile image
Erik Dietrich • Edited

I like the turn of phrase "interview/hiring system is failing a ton of unit tests."

Anyway, here's my controversial take of the day: maybe the job interview itself isn't an effective way to scale.

I actually, in writing a book, did a bunch of reading up on the history of the job interview, and it's surprisingly unchanged since emerging randomly as a management fad 100 years ago. Google did some internal research and found that the most effective interview-style, simulating the actual work in the role, was only something like 25% predictive of future performance. (IOW, any given single interview style would be the worst game in any casino for achieving good results).

The job interview is so iconic that when I bring this up, people think the idea abandoning is akin to a suggestion that they stop drinking water or something. But I can't help but wonder if, someday, the job interview won't look a lot in the rearview mirror like waterfall software development: "why did it take us so long to stop trying to predict the future and start adapting to the fact that we're not very good at predicting the future?"

FWIW, we've been building a business with an informal fundamental principle that we don't do job interviews. And it's worked quite well, so far, bringing us to 4 salaried staff and something like 100 engaged contractors. So, it might be possible to scale talent without conducting interviews at all.

/end food for thought

Collapse
 
remotesynth profile image
Brian Rinaldi

That's super interesting. I will say though that I have had a number of good interviews and interview processes. Often those focused on my working style, how I interact with other, my critical thinking skills, etc. rather than trying to decipher specific coding skills. Point is, I think there are better alternatives that focus on getting to know the person and how they fit into your team and culture.

Collapse
 
codenoodle profile image
Nate May

I had one of those all day marathon interviews where they flew me 3000 miles for a single day and they asked me during lunch what I thought of their interview process. I had the guts to tell them that all these coding puzzles shows them very little of what I am capable of and doesn't even translate the the work they want me to do. I didn't do great on two of the puzzles in the afternoon and I didn't get the job. I only really thought of it because my interview for MongoDB (my previous employer) was the exact opposite. One of their managers even wrote a great piece on how to step up your own interview game. I was particularly excited by his idea of putting all your current employees through the interview you plan to give new people. You should expect them all to pass with flying colors.

Collapse
 
remotesynth profile image
Brian Rinaldi

That is a really interesting idea. It's an interesting way to validate that you will get the results you expect.

Collapse
 
mfrohberg profile image
Michael Frohberg • Edited

I am glad to see that I am not the only one who abhors the way tech interviews are conducted. If this were somehow producing better engineers I could understand, but the data does not suggest that it does.

viglobal.com/2018/06/13/tech-indus...

This is more than just a matter of preference to me.
Having been born with learning and attention differences I struggled daily against a system that seemed to place the highest value on memorization. Memory is not an indication of intelligence. I’d rather have 64GB of RAM and a 2.5GHZ quad core processor than a 16/32bit processor and 2TB of storage.

To me this is an issue of accessibility and a lack of inclusiveness.

PS. Been an engineer almost 10 years. I have not as of yet, needed to implement a bubble sort

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao

I kind of think it comes down to those who gave you technical interviews. The bulk of them is from HR.

With little to no technical background to give you those tests and when you combine it with negotiating your salary & compensations with them and fulfilling their extensive checklist is kind of hard.

Don't get me started with a recruiters/head hunter who always sends me a cookiecutter message and thinks that I don't know it was a mass spam message to multiple developers on Linkedin.

Collapse
 
remotesynth profile image
Brian Rinaldi

I think this is definitely true for the screener process, though, in my own experience, the code quiz and technical interview beyond that aren't with HR.

Collapse
 
filisha12 profile image
Filisha

This is something our team at Live Share has been deliberating for a while. Being able to find good candidates is often not a failure of talent but failure of the process. We actually just introduced Live Share interviewing- aka.ms/vsls-interviews so that you can recreate the real developer environment as much as possible.

Collapse
 
raymondcamden profile image
Raymond Camden

Great article! One comment about these 'tests' and such. Since I'm quoted above I think folks know how I feel about it. However, I've had a few jobs ask me to do the following and I've been ok with it:

1) Write an article about our products
2) Give a presentation about one of our products

In both cases I was ok with it because a) I was given a LOT of time and b) I asked (demanded) to be able to share the stuff on my blog later.

So for me, while I was losing a bit of time even if I didn't get the offer (or it wasn't an offer I wanted), I at least learned something and got some content for my site.

Collapse
 
remotesynth profile image
Brian Rinaldi

I have had some experiences like that as well. One company asked me to write a blog post about their product and, should I not get an offer, even said they'd pay for the time. I think that a blog post or presentation is perfect for a DevRel role, but if it were used for a standard developer role, I'd think you'd have to ensure it isn't graded on writing or presenting skills that are likely not part of the job requirement.

I am definitely not opposed to relatively short, relevant homework even for developers. I don't equate these with coding quizzes and whiteboarding. However, I do think companies need to be aware of the time demands of their homework and make sure they are reasonable. I also don't think companies should use this as an opportunity for some free labor by making the developer do actual job work (like fix an issue on a repo) as homework without compensation.

Collapse
 
sarafian profile image
Alex Sarafian

Let me share some insight, at least from Europe. I've done interviews in Greece (where I'm from), Belgium, The Netherlands, Luxembourg and most recently UK.Just to be clear, I've not interviewed in all countries for developer roles as I've been doing Dev management and architect roles for the last decade.

I've only once had a code test, which I did from home with a time restriction. Then they checked and used some parts of it as discussion points. I got actually hired there. The test was ok and yes didn't reflect the job but showed if the candidate had some degree of attention to detail and the ability to google. Later on, they did the same interview to a former colleague of mine who failed on the subtleties and got rejected although this person is one of this commando people that will carry you out of shit situations. Recently, I was asked to prepare a presentation.

If you ask me, code tests could have some merit if you find something simple and you don't take it too seriously. Just use it as discussion points. Most important aspect is the discussion but to be able to proper evaluate candidates you need to be relevant and this is where the problem lies.

I actually think that biggest mistake done is this perception of hiring the best fit for an spot. Like it or not, most jobs don't differ from each other. A CMS is a CMS and yes we've all re-invented the wheel but only in our dreams is our code and product so unique. Hire someone who fits the profile, has potential and give it a try instead of spending so much time trying to find the best person. At least in Belgium this is the biggest mistake. To borrow an expression, they are kind of looking someone to be wedded with the job and this is wrong. If the talent is good then he/she might stay only if properly incentified. So I say, get people to get started, don't waste time and if doesn't work try again but don't wait to find the person while everyone else has moved on.

Collapse
 
dougaws profile image
Doug

Interviews should be mostly about figuring out whether there is a good culture fit for the candidate within the team. If everyone on the team gets to work at noon, hacks around until 11pm, and goes out to paintball, a more-staid person probably won't work out.

The problem with so many hiring hurdles is that they are gameable. Want someone who knows data structures inside-out? Cool, but they may fall on their face when asked to write testable code that fits a business need. I recall years ago regaling an interviewer about puzzles (give me a word in the English language that changes pronunciation when capitalized/uncapitalized? Polish/polish).

If you don't try different approaches, and do follow-up a year or so later, how can you say your interview process works? I don't know any company that does such A/B testing, do you?

Collapse
 
desolosubhumus profile image
Desolo Sub Humus 🌎🌍

To be honest, I think much of the problem boils down to two major issues.

In the effort to appear more open to a more financially diverse group, college requirements have been dropped, but replaced by code issues not really encountered outside of college. This means self-learners like me are still effectively shut out, while the company can use the PR to pat themselves on the back for being more inclusive.

In the effort to show that they can't possibly hire citizens from their own country and absolutely must hire lower paid remote developers from another country, unicorn-level requirements are added in the interview process. This allows the company to weed out as many candidates as possible, claim there are no qualified workers in their home country, and hire only people who are willing to work for half the pay. This isn't the fault of the foreign hires, but of the company. This has led to some companies listing job requirements like -

Must be able to make the perfect cup of espresso, have full skills for making realistic CGI videos, be able to code in Fortran, Python, C++, Java, JavaScript, Kotlin, React, Angular, Vue, and Scalar, be able to use Excel and TextEdit, be a subject expert at Machine Learning, and be able to shimmy up a coconut tree and pick coconuts in under 2 minutes, 30 seconds. Benefits include a foosball table and a photobooth in the breakroom.

  • for a simple, data entry job in the past.

Shell games for the job market suck.