Up until the mid-late 2000s tech interviews consisted of a few conversations, followed by checking references.
CS trivia interviews were largely introduced by Google, with other companies cargo culting that into their interview practices.
CS trivia interviews were largely introduced by Google, with other companies cargo culting that into their interview practices.
What I am not fine with is that you're judged entirely on that. My biggest complaint about this industry is not the CS trivia, it's that my entire job history is irrelevant. I have a decade in this industry and a staff title and I am still treated like a junior developer with no experience when I am interviewed. It's degrading and insulting. I can understand rigor in an interview at our average salary but the market is still firmly controlled by corporations despite what the media says about job prospects. Given that there are approximately 10-20 jobs per engineer in the industry right now, if we really cared, all we would have to do is just collectively say "no".
So basically my solution is to just ghost people when they ignore the subtle "maybe look at my GitHub that you asked for to establish basic competency?" and start asking for coding tests because I neither want to do the test nor come off as a twat, and this seems like the "least bad" option. The truth of the matter is I have the time and can do it, I just don't feel like doing it; nothing more.
And I also consider it as a bit of an indication whether I want to work for them in the first place. "Rules must be followed, at all times" with zero flexibility or common sense is not really something I deal well with.
I think a far more likely explanation is that lots of interviewers are very bad at interviewing, and that interview anxiety, especially given the kind of shit that gets thrown at you in programming interviews, is a lot worse and more widespread than one usually supposes. Result: interviewers are convinced they're constantly catching "frauds" that they couldn't have caught otherwise, but they're frequently wrong about both those things—that the person was a "fraud"; that the interviewer couldn't have caught actual "frauds" with an ordinary interview.
If you have enough applicants, why not filter out so you have the best of them? (well, maybe not quite the best, there is some value in having someone less likely to get bored and move on PDQ).
In my opinion the best interview process involves simply looking at the work history and having a conversation about it. If it sounds pretty good, you go with your gut and hire. A bunch of different people paid this person a lot of money for 5, 10, 20 years and you really think there's a chance they were all fooled? The conversation and your gut figure that part out with a decent success rate.
Also, do they try to BS you when you ask them something they don't know...
The "traditional" coding interview is really only appropriate for a college student/new grad with no work history to lean on. Even then, there's probably a better way...
I had two previous "tech" interviews prior to that. The first was for a Perl shop. All Perl-specific questions, and the interviewer even gave me a copy of the Camel Book to thumb through if necessary. The second was for an MS-based web shop. They sat me down at a computer and told me write a relatively simple C#-based CRUD app. I was allowed to Google whatever I needed. The Perl interview was fairly challenging (I knew parts of the language, but was not an expert), the C# one not so much, but I'm sure it weeded out a lot of applicants.
I've also had three other jobs where there was not a "tech" interview at all, mostly just chatting about projects and whatnot.
Here's an article that digs into this specific history: https://www.hillelwayne.com/post/linked-lists/