That job market seems like so long ago. See job ad, type out a letter with your CV, wait for them to write back, somehow organize a time to meet, more rounds, and so forth. At least it must have been hard to spam out CVs.
The guy seems pretty hardcore from my perspective. University training for all those techs. Of course hardware back then cost a lot of money so you wanted people who knew what they were doing.
What did people do for interviews back then? Reverse-a-linked-list? That would have been a relatively recent publication in 1980. Kadane's algo didn't arrive until 1984 IIRC. Was K&R published yet?
My copy of K&R belonged to my dad and was from the early 80s!
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.
Got a job working on an old Ada system during the Great Recession (I was unemployed and desperate enough to take any job). Mom was kind enough to give me all of her old Ada books - apparently her employer (defense contractor) had sent her to training when the language was first introduced.
> 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."
> The last interview was with someone very technical, who had printed out a few pages of listings of the obfuscated C contest.
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.
> 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.
It's nice to know that stupid interview questions are not a modern innovation.
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.
My first interview for my first job in 1981 consisted of the manager asking me general programming questions ending in a description of an errant program which I had to explain how I would figure out what was wrong, and what it was likely to be. No whiteboards, no coding, nothing. That was the only interview, and I was hired on the spot, despite having 0 work programming experience and 0 college education in programming (was chemistry major, programmed for fun on an Apple ][). Highly unlikely to happen so easy today. I retired recently after nearly 40 years as a working programmer.
> What did people do for interviews back then? Reverse-a-linked-list?
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.
The guy seems pretty hardcore from my perspective. University training for all those techs. Of course hardware back then cost a lot of money so you wanted people who knew what they were doing.
What did people do for interviews back then? Reverse-a-linked-list? That would have been a relatively recent publication in 1980. Kadane's algo didn't arrive until 1984 IIRC. Was K&R published yet?