I am 100% fine with CS trivia interviews. I am fascinated by CS and can talk your ear off about it.
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".
I really struggle with this, because on one hand I don't want to be the arrogant special snowflake kind of person, but on the other hand I also have a 15 year job history and 100k lines of code on GitHub, including some fairly widely used stuff. If you want to establish basic competency it's not hard.
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've brought that culture back in our company. Hasn't failed us yet. Turns out for a CRUD web app you really don't need top hackerrank skills. In my humble opinion, people who excel in algorithmic code interviews want to overcomplicate everything and get burned out super fast with 'real world' tasks.
I'm deeply skeptical of claims that you can't suss out "fakers" like this. For one thing, people who were that good at faking could be making a lot more money leveraging that skill directly rather than trying to sneak into mid-paying software jobs.
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.
You are right, it happened once, but that's what probation periods are for, in my opinion. Also I'd add we don't hire a lot, so this approach probably doesn't work for places which are hiring a lot of people regularly.
Yep, I blame Microsoft. Now these sorts of interviews are done even by companies writing pedestrian web apps that don't require hard-core CS knowledge. Yet they test every applicant on it anyway.
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).
One reason, besides the obvious lack of respect, is that the more you test for things you don't need, the higher the odds that you select somebody with false positive results on the things you need.
I've never seen any evidence these interviews accomplish finding the best or even a competent candidate.
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.
Yep. Can they talk at length and in reasonable detail about previous projects they've worked on? You can usually figure out if they were actively engaged and involved in the work vs ...just kinda there.
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...
The last "tech" interview I had was in 2007, with my current employer. It was not an algorithmic interview, but rather a deep dive into how much I knew about SQL (which was a critical part of my position at that time), and a bit of general web knowledge. I definitely hit a point where I said "well, I don't know," but managed to get the job anyway.
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.
They were definitely influential, but it's way more complicated and probably has as much to do with The Guerilla Guide to Interviewing, which was Microsoft-based.
CS trivia interviews were largely introduced by Google, with other companies cargo culting that into their interview practices.