Why do programmers accept current technical interview practices?

8 points by entyphom ↗ HN
Most other jobs don't ask you to perform a pale staged imitation of what your real job would be before they hire you.

We have resumes to prove our past work, and yet we keep having to prove we know how to implement fibonacci on a whiteboard or rediscover the wheel of sorting algorithms that are already implemented in the languages we use.

Technical interviews don't even remotely reflect ability to do the job, at best they show that you can write basic code, which isn't enough.

More importantly, for me the big flaws in those interviews are:

- They're very susceptible to bad luck or bad days. Projects in real life don't last an hour, sometimes you will do something easily and sometimes not. In interviews, a problem might be about an algorithm you know about, or about one you never heard of.

- It gives an edge to people who have time to do "interview homework", which effectively means the best strategy for succeeding at interviews is to not be employed, and if you interview while still being employed you're putting yourself at a disadvantage

- It makes some personality types more likely to succeed. Anyone who gets stressed "performing" in front of an audience will have more trouble. Reading a problem and finding a solution for it in real time for an audience during a test is very different from what people do on the job.

- It's basically a school test. We're not school children, we have resumes and past projects to attest of our ability to do our job (unless it's your very first job obviously)

I am so tired of having to learrn linked list algorithms for big company interviews, or having to spend a week-end of my life to do a code test. Those things make it super hard to schedule interviews and tests around work too because it's basically a second job, and makes it impossible to consider more than a small handful of companies at a time.

There are literally entire startups based around providing what is effectively homework to prepare for interviews, and they're even sponsored by FAANG companies which literally expect you to practice their interview questions before going on the interview. It makes no sense.

Are there any companies that are starting to move away from that? Could we just collectively agree to just stop agreeing to those practices? Why is it considered normal for me to have to schedule a 2 hour technical interview in the middle of your current job's workday?

11 comments

[ 3.5 ms ] story [ 39.0 ms ] thread
Why does any worker put up with less than ideal interview practices?

Because you need a job more than they need to hire you.

Many potential employees will be turned off by such practices, but there are plenty who will participate too.

Exactly. I couldnj't find a job during the pandemic. I refuse to work with react or angular. I finally found a vue job where I didn't have to answer stupid questions. Just an informal "get to know you" interview and that was it.
That's where I think things should change. Programmers are in demand and very hard/expensive to hire. We tend to have the advantage in this process.

You can see an example of that with remote work. After covid, most people in tech simply refused to go back to being forced in an office full time, and would simply quit their current job in favor of one that accepts remote.

It's similar here. All you need is for enough programmers to start refusing to do those tests

> After covid, most people in tech simply refused to go back to being forced in an office full time, and would simply quit their current job in favor of one that accepts remote

“Most people” is a huge exaggeration. The numbers support a very slight increase in job churn from around 1% to 2%, but that includes people who simply took higher paying jobs and moved on to something else. The number of workers who “simply refused to go back” is extremely small. It wasn’t a huge movement like some headlines claimed.

If you want change, the conversation needs to be about proposing better alternatives for interview formats. Nobody likes interviewing because nobody likes being judged. However, interviews are structured as tests because companies can’t simply hire people based on what they claim on their resume.

It’s not true that programmers are the only profession in which candidates are tested on their knowledge or asked to perform example work. In fact, programming interviews were relatively straightforward compared to some of the trials I’ve seen given when hiring for non-programming roles. In fact, many of my non-programming peers are blown away when I tell them that our interview study material is freely available online and there are multiple free websites that will help you practice for interviews.

> Why is it considered normal for me to have to schedule a 2 hour technical interview in the middle of your current job's workday?

Why would it be abnormal to ask someone to invest 2 hours of their time in an interview? You’re applying for a job that you might hold for the next 3 years or more. Is a part day of interviewing really a dealbreaker? If nothing else, use that time to get a feel for your future coworkers and ask them questions.

It's not one 2 hour interview though, it's usually a 5 stage process if not more
I was quoting your 2 hour claim, but the fact remains: You need to propose better alternatives if you want progress. It’s not enough to simply complain. Companies can’t just not interview candidates or hire people based on whoever claims the most experience on their resume.
My better alternative is to just skip the code test part. You can still have the candidate chat with other engineers which is usually enough to be able to probe and figure if someone knows what they're talking about.

I can learn much more about the technical ability of a candidate by speaking to them about their projects and how they work than by checking whether they know how to implement a binary tree

In fact, I have been pondering over the same controversies over technical interview for quite sometime, and I think the sheer intention of a company on recruitment is to recruit the candidates that fit their requirement/expectation as much as possible.

I have been thinking: are the following approach works better in terms of technical recruitment and interview?

- Say a company wants to recruit .NET Core developer with experience/knowledge in Sql Server.

- In the job scope, as usual, they would put in their expectation / requirements. At the same time, they should put few (but reasonable enough) specially curated training videos (either from YouTube channel, pluralsight, lynda, oreilly, udemy and you name it) by the company on .NET Core and Sql Server that they expect the potential candidates to go through.

- Most of the interview questions should come from those videos. During interview, the interviewer can ask additional questions with its answers won't be directly from the training videos but more to the experience that candidates put in their CV/resume.

With this, those candidates who are really interested in the openings will take the initiative to go through the training videos and equip themselves better for the interview. Those are not prepared, they, themselves are well aware that they most probably won't pass the interview questions which its answers can be obtained from the training videos and most probably they won't even go for the interview too.

This, i guess is the most effective way for both the recruiters as well as the candidates to find their perfect match.

Maybe it will make you feel better to know that this is not exclusive to it. For example, in Finance, there is something called the CFA (Chartered Financial Analyst) certification, that let's you break into financial analysis at about a 5th of FAANG salaries.

You can take it...wait for it - once a year. There are 3 parts. Admittedly, you can take the first part twice a year.

Anyway, average prep time is worse than for, say, GCP Architect - so basically they ask you to budget 6 months and 300 hours. That is a LOW starting amount.

And you know what passing it usually gets you? Nothing.

Then there are the actuarial exams which are worse. There is the Professional Engineer cert in engineering. CPA for accountants. 12 years of med school for doctors. Etc.

IT does NOT have it that bad at all. Keep that in mind.

P.S. I do think studying for FAANG interviews pretty much ensures you learn your school curriculum if you haven't already.

I agree with most of your points. But if you'll excuse an economic analogy, I think one of the reasons why you don't see "market dynamics"-like forces causing change here is that you don't really know what a company's interview process is like until you do it, and I think it would be rare that someone passes an interview and remains motivated to get it changed, or fails an interview and has any say whatsoever. So there's no equivalent of "voting with your dollars".

I suppose one could come up with a dramatically new approach and "market it" to get a lot applicants. But I think the current process, while deeply flawed, probably does at least correlate with good engineers, and such a process would perhaps be biased towards poorer applicants. At the very least, I can see how there's the expectation of that, and that alone is enough to prevent it from happening.

The problem is I'm sure we've all worked with people who had impressive resumes but were unproductive and probably couldn't pass FizzBuzz, and we all want to avoid that. I would imagine that making the labor market a little more fluid would help, so companies bias more towards hiring without a bunch of arbitrary tests, and are more inclined to let a poor performer go early. But it's still hard to really see someone's potential for several months, because it can always be blamed on getting up to speed, onboarding processes, etc. There are companies who don't hesitate to let poor performers go (e.g. PIPs and up-or-out positions), but companies that do that a lot are widely regarded as having toxic, corrupted versions of such a process. I wouldn't actually bet on it being a net improvement.