Why do programmers accept current technical interview practices?
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 ] threadBecause 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.
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
“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.
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.
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
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.
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 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.