My job interviews in the 80s and 90s (college summer jobs, or the one time a company tried to get me to leave college for a job) had no whiteboard-coding-style technical skills components, aside from demos of software I'd written and general discussions of implementation details.

One job I interviewed for was at Davinci Email. This was probably 1990-ish? They made a LAN email product that ran on top of Novell NetWare. There were a couple of hours of general interviews, including a lunch on-site. The last interview was with someone very technical, who had printed out a few pages of listings of the obfuscated C contest. He asked me to go through them and tell him what each program would output. I did not get the job.

> The last interview was with someone very technical, who had printed out a few pages of listings of the obfuscated C contest.

That's cold. The worst I've had was otherwise normal code with a few deliberate bugs introduced: "Tell me what's wrong with this code."

I had something similar happen in 92. The interview consisted of leaving me alone looking at one screen of Apple BASIC that came from their actual production code. The screen was nearly full of characters. I was supposed to tell them what that bit of code did.

I spent about 5 minutes looking at it, and though I think I could give the correct answer, I also realized I didn't want to work with this code base. I then thanked the interviewer and left.

The headhunter that sent me on this interview was quite irate that I had "embarrassed" them. C'est la vie.

CS trivia interviews were largely introduced by Google, with other companies cargo culting that into their interview practices.

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...

https://sellsbrothers.com/12395

Here's an article that digs into this specific history: https://www.hillelwayne.com/post/linked-lists/

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.

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.

The last time I was hired for a purely software-related position was 1993. They were looking for an IC (they didn't call it that, then) who would quickly transition to tech lead / system architect. The technical part of the interview involved role-playing myself presenting an initial proposal to a potential customer who had provided a brief written requirement. One of the interviewers role played the customer. IIRC the interview schedule was something like 30 mins to read the requirement and think, 15 mins to ask initial questions, an hour (perhaps longer?) to develop the proposal, an hour (?) to present it and face customer questions.

In essence I was being asked to spot ambiguities in the requirement and develop an initial estimate. I passed. I would have failed had I applied for the same job straight out of uni.