Why do programmers accept current technical interview practices?

Post by macksd » Mon, Jul 19, 2021, 1:58 PM UTC

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.

Post by tatsean » Mon, Jul 19, 2021, 2:18 PM UTC

PragmaticPulp wrote: post #8

entyphom wrote: post #6

Earlier quoted context omitted.

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.

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.

Re: Why do programmers accept current technical interview practices?

Re: Why do programmers accept current technical interview practices?