Compare this to my interview at a web consultancy in June of 1999:

Me: (sits down with president of the company, the only person to interview me)
President: So I hear you can program!
Me: Yup.
President: How much do you want?

My degree was in music. Things: they have changed.
posted by grumpybear69 at 2:22 PM on February 21 [25 favorites]

I got my first professional programming job in 1999. I didn’t actually interview, I just mentioned I was interested in websites while I was at another job and they said hey, we need some built!

Recently, I had the worst interview of my life. It went pretty much like the original describes. I said I’ve been doing this long enough that I’m not really on board with the algorithm Q&A, let’s just talk about the work, and in so doing I sailed through 4 phone screens and landed an onsite interview. I was assured it would be practical and no one wasted their time on algorithm brainteasers. You can imagine there this is going. I arrive and the first interviewer says I have 3 eggs and need to determine the maximum height they can be dropped from without breaking… This session was brief and ended with me declining to attempt a different question. The remainder of the interview passed as a blur conducted from a place of great despair. I almost wrote a snarky email suggesting they get it together. I gave up. 3 weeks later I got a job offer from another team who I wasn’t interviewing with but who was in the interview and was impressed with how I handled myself. Turns out that job was my dream job and I never would’ve wanted the first one anyway. The company is great, too. Well meaning but even that is not sufficient for conducting a good interview.
posted by feloniousmonk at 2:30 PM on February 21 [17 favorites]

Compare this to my interview at a web consultancy in June of 1999:

I was doing interviews in 1999 to get hired in 2000, and I had to design multiple SQL queries on the fly (not even a flipping piece of paper) for the megacops of the day. This stuff isn’t new. My room-mate interviewed at Microsoft, and had to design an instant messaging application in the in-person interview. I guess that has changed, it wasn’t over the phone then. He didn’t get the job, but did 10 years later as a network engineer with experience and none of the nonsense.

And yes “senior” and non-senior are the only options for engineers. After that are ‘architect’, ‘team lead’, and ‘business sales/estimations’, which are completely different skillsets.
posted by The_Vegetables at 2:31 PM on February 21 [1 favorite]

The nice thing about contracting is you get hired (well kind of hired) on a recommendation alone.
posted by w0mbat at 2:33 PM on February 21 [7 favorites]

lols. the trouble with these insane interviews is that people keep passing them. It’s an arms race. If you’re not spending 80 hours preping for your interview at Search & Ads Inc yeah, it’s going to go badly. And yeah, it’s totally disconnected from reality. But what are you going to do, just hire people at random?

Honestly I think the complaint about a shortage of people is overblown. The issue is a lack of mentorship and properly transitioning junior developers into architects or whatever it is you want.
posted by GuyZero at 2:33 PM on February 21 [13 favorites]

People like to say that software development is a seller’s market but I find that hard to believe when the process to get hired is so nightmarish.

I’m terrified of getting fired because while I have a decent resume and I’ve been keeping up to date, I’d need to study months to be able to get through a whiteboard interview. And I know that no matter what I learn for the interview, chances are I’ll never need to use it again until the next time I’m looking for a job. It’s a very specific skillset that’s almost completely divorced from day-to-day reality.
posted by simmering octagon at 2:36 PM on February 21 [15 favorites]

I think I’ve screened or interviewed at some of the same companies he has. A well known Ride Share/Self-driving Car company had me write a task dependency checking system in python as a take home test for a QA job. I spent a Saturday writing it along with a suite of pytest unit tests and submitted it and promptly got rejected with exactly zero feedback. That was four years ago and they’ve pestered me multiple times since to re-apply for an interview. Considering that one of their cars ran someone over in Arizona a few years ago, I’m not sure I think much of the effectiveness of their QA department.
posted by octothorpe at 2:37 PM on February 21 [13 favorites]

I do not have a positive attitude towards recruiters. No, I do not.
posted by SoberHighland at 2:37 PM on February 21 [4 favorites]

It’s a very specific skillset that’s almost completely divorced from day-to-day reality.

Yep. The only thing the whiteboard gauntlet screens people for is if they are good at interviews.
posted by GuyZero at 2:38 PM on February 21 [4 favorites]

The issue is a lack of mentorship and properly transitioning junior developers into architects or whatever it is you want.

This is what it all boils down to. The magical beings that companies think they can somehow locate with these insane interviews are, summarized: people they never have to invest time or money into. That’s it. That’s why they’re trying so hard to filter at the interview process with such ridiculously demanding questions.

I have said for many years, and I will continue to say: we (software developers) have a serious cultural problem with not wanting to actually train or develop people. We let ourselves think that if we can just interview hard enough, with an exacting enough set of tests, we’ll just hire fully formed developers who will never need mentors, never need outside training, and will just manage their careers themselves. It’s why we also lie to ourselves and say it’s totally normal for someone to be promoted from a hands-on engineer to a manager, because obviously management isn’t like a skill or requiring of any specific qualities …

I’ve worked for some companies that do better than this, but even the ones that have done best are still failing people on a regular basis (just not as hard as the average ones).
posted by tocts at 2:41 PM on February 21 [27 favorites]

Metrics are hypnotic. The turning of a candidate into a score makes some people feel like they understand the world.

It’s important to ask interrogate if all these metrics around Structured Interview questions (“Tell us about a time when…) and discrete toy problems are really good predictors of someone who is a valuable or capable worker. Is this even an area of academic interest? I’ve never seen a shred of study or testing of any of this. It all appears to be gut and supposition.

I have a strong sense that most of these sorts of HR issues are drunks looking for keys under streetlights. We know the keys aren’t there, but this is the part we can measure and search.

I’ve advocated instead, where possible, for real work products, past projects, doing a presentation on a past project, previous written works be evaluated instead (ok, in addition, not won that battle with HR yet). In all cases I think the hiring boards found the more relevant job-related evaluations more useful.
posted by bonehead at 2:43 PM on February 21 [7 favorites]

Well, he’s also not looking for just any coding job. He’s looking for the plumbiest, get-richest, most competitive companies on the planet. Yeah, it’s hard.

I have never been a part of a hiring team and I am sure there are things going on that I don’t know about.

Yeah. They’re also probably evaluating that you maybe didn’t communicate very well for the specifc role they want you to do.
posted by Abehammerb Lincoln at 2:43 PM on February 21 [6 favorites]

As an aside, this shit is why I refuse to respond to the dozens of emails I get a month from the usual suspects (Apple, Amazon, Google, etc). I have zero interest in undergoing an insane intellectual gauntlet that bears no resemblance to what I’d actually be doing for the company. I also frankly don’t trust companies made up of people who were willing to put themselves through this shit, and I suspect it plays into the very poor work/life balance at these big companies.
posted by tocts at 2:45 PM on February 21 [11 favorites]

Interviewing at a big financial firm in 2003, who took maybe 3 months to respond to my dice.com resume submission, consisted of:

1. A phone screen w/ a clueless recruiter
2. A phone screen w/ an engineer (I had learned the definition of “polymorphism” at that point, it having bitten me at a previous interview at a big travel site)
3. A 4-hour in-person session of interviews with engineers and managers during which I was asked lots of those “tell me about a difficult situation” and “tell me where you see yourself 5 years from now”
4. Another 4-hour in-person session of interviews with engineers and business people, for which I needed to buy a new button-down shirt* since the one button-down shirt I had was dirty (see #3).
5. A role-playing phone screen w/ a business person who was in London during which I had to pester him for requirements

* said shirt having been returned the same evening after I discovered slit** in the arm which I presumed to be a defect
** 18 months later, said shirt then being brought up in conversation at happy hour due to slits in both arms which were apparently a design feature and caused everyone that interviewed me to think that I was Really Confident About My Biceps when in fact I had no clue at all
posted by grumpybear69 at 2:46 PM on February 21 [11 favorites]

I went through this recently. Yes, it sucks. But as a person going into software engineering from a non-traditional background and with a non-traditional profile, I kinda appreciated that at least the requirements to pass these interviews is clearly stated; yes, it’s a game, but I know the rules. I’d be more nervous if they were judging me on culture fit. Anyway, it was fairly successful and I’ll be joining a megacorp in May, go me! Now I can start worrying about lack of mentorship and properly transitioning into an architect. 🙂

There were many people graduating from my program who found jobs without doing the algorithm interview prep thing; they chose to focus instead on projects, and targeted companies without a strong focus on algo interview questions. So, I think there’s hope for people who don’t want to engage in the leetcode grind, but you do have to be intentional about it.
posted by catcafe at 2:48 PM on February 21 [4 favorites]

> Abehammerb Lincoln: “Well, he’s also not looking for just any coding job. He’s looking for the plumbiest, get-richest, most competitive companies on the planet.”

For the record, in his follow-up, he says “Contrary to popular perception, I did interview with companies outside of the FAANG club.”, fwiw.
posted by mhum at 2:48 PM on February 21 [4 favorites]

But what are you going to do, just hire people at random?

The algorithm interview is a desperate attempt to quickly screen out the garbage applications which have increased so massively in number as the internet has spread. Trouble is, it’s so poorly implemented that it ends up screening out the people you actually want to hire as well. And as such, it turns out to be a downgrade on the company boss many years ago who famously said that he made his pile of applicants manageable only by stacking all the CVs on his desk and sweeping the top 90% of them into the bin.

So, the answer to your original question is yes.
posted by Cardinal Fang at 2:49 PM on February 21 [5 favorites]

I also frankly don’t trust companies made up of people who were willing to put themselves through this shit, and I suspect it plays into the very poor work/life balance at these big companies.

So people do pass these things somehow. These interviews are also a total crapshoot and the stories you read have a whole lot of selection bias to them – no one posts 10K words on medium about a perfectly reasonable interview with a well-prepared interviewer. And work/life balance is great at big companies because of all the inertia – if you’re a day late with a project, no one cares. There are 30,000 people within 2 miles of your desk, no one notices when one goes home early to watch a swim meet. Work life balance at startups is way more random.
posted by GuyZero at 2:51 PM on February 21 [4 favorites]

Work life balance at startups is way more random.

Agreed! I worked at a startup once where the trust-fund founder actually put a bedroom in the office in case any of us felt the urge to work all night and wanted a place to sleep. Nothankyou.com
posted by grumpybear69 at 2:54 PM on February 21

I was recently forced to be part of the interviewing/hiring process for software. Based on all these articles and my experience, I gave an interview question that tried to actually represent what I actually do with my time:

1. Write a tiny program that does function A
2. Modify the program to do function B, which is pretty different than function A, but also it has to accomplish function A
3. Modify the program to do function C, which is pretty different than function B, but is really similar to function A

The ideal candidate would notice the similarity between A and C and restructure it instead of adding to the mess from step 2, but it was ok if it just implemented A, B, and C competently.

I had a lot of fun writing it up and asking the candidate, but otherwise I don’t think anyone else wants to ask it, because it’s not a “fun algorithm question”.
posted by meowzilla at 3:00 PM on February 21 [1 favorite]

That was the disease. This is the cure
posted by Leon at 3:05 PM on February 21 [8 favorites]

> And as such, it turns out to be a downgrade on the company boss many years ago who famously said that he made his pile of applicants manageable only by stacking all the CVs on his desk and sweeping the top 90% of them into the bin.

If they get binned, they were unlucky. Who wants an unlucky person on the team?
posted by Leon at 3:08 PM on February 21 [10 favorites]

I had a similar experience. I have over 20 years of programming experience. Made it through a couple rounds of interviews then got asked to show if a binary tree was valid. I didn’t give a good solution, I didn’t get an offer.

The big tech companies (Google, Facebook, Microsoft etc), despite what they say, don’t need any more programmers. They have all the programmers they need. They could fire half their engineering force and still have all the engineers they need.

As stated above, companies unrealistically only want people who can walk in in the morning, fill out their I-9, sit down and immediately starting contributing.

I also enjoy the obsession with algorithm complexity trivia.
posted by lowtide at 3:13 PM on February 21 [1 favorite]

I have been out of the game for years now and still occasionally get calls. Sometimes I try to make sure I get to talk to an internal hiring authority, and I berate them for these practices. Once this aggressive and antisocial behavior led to a non-loop interview, but as you may guess I definitely did not want the job.
posted by mwhybark at 3:17 PM on February 21

*weeps*

I am currently looking for tech work. This hits a bit too close to home. Also I am 1) female and 2) over 50. Oh goody!
posted by supermedusa at 3:22 PM on February 21 [11 favorites]

My freelance work has become a very small trickle, and I have thought about getting a job, but under these circumstances? Would never make it. I’d be off their list the second they saw my grey hair, anyway.
posted by maxwelton at 3:26 PM on February 21

Being over fifty, I have the extra problem of having to suppress my eye-roll when I get asked to do something like Fizz-Buzz which I could have coded in 1979. Telling an interviewer that you could have solved their question fifteen years before they were born, isn’t really an effective strategy.
posted by octothorpe at 3:27 PM on February 21 [12 favorites]

If they get binned, they were unlucky. Who wants an unlucky person on the team?

Actually, no, they were the lucky ones. The unlucky ones got interviewed and the really unlucky ones took the job.
posted by suetanvil at 3:27 PM on February 21 [1 favorite]

My horrible variation on this was similar. Breezed through the phone interview and the in person then I was passed off to the ‘practical test’ which was a computer set up to display on the projector. There was a sample code project with a test suite. The code accomplished some arcane task and the tests confirmed it. The catch was that the code was essentially obfuscated. All the variables were named a, b x1 etc. and the code was deliberately spaghettified. My mission was to refactor the code to be more understandable, but functionally the same, and also rewrite the tests too because those were also a mess. You have 30 mins….go! Any questions I asked as to what the purpose of this code is, or what it’s supposed to accomplish were met with ‘it’s live code that you need to refactor’.

I bungled along for 30 mins, left and never heard back. Thank the gods. If that’s a realistic version of the work environment, no thanks.
posted by SonInLawOfSam at 3:30 PM on February 21 [1 favorite]

> GuyZero: “The issue is a lack of mentorship and properly transitioning junior developers into architects or whatever it is you want.”

Sometimes, I idly daydream about how different things would be if software engineering had evolved along the same lines as trades, either like the traditional building trades (e.g.: electricians, plumbers, carpenters, ironworkers, etc…) or like doctors and lawyers. Personally, I think that an apprenticeship->journeyman->master or intern->resident->fellowship framework would be a much more sensible system than whatever the heck we have now.

Meanwhile, when it comes to interviewing in general (not just for software but for everything), I’ve long been of the opinion that no one really knows what they’re doing. Anecdotally, Daniel Kahnemann, the behavioural economist, wrote up his experiences of evaluating officer candidates in the Israeli army for the NYT in 2011 “Don’t Blink! The Hazards of Confidence”:

Because our impressions of how well each soldier performed were generally coherent and clear, our formal predictions were just as definite. We rarely experienced doubt or conflicting impressions. We were quite willing to declare: “This one will never make it,” “That fellow is rather mediocre, but should do O.K.” or “He will be a star.” We felt no need to question our forecasts, moderate them or equivocate. If challenged, however, we were fully prepared to admit, “But of course anything could happen.”

We were willing to make that admission because, as it turned out, despite our certainty about the potential of individual candidates, our forecasts were largely useless. The evidence was overwhelming. Every few months we had a feedback session in which we could compare our evaluations of future cadets with the judgments of their commanders at the officer-training school. The story was always the same: our ability to predict performance at the school was negligible. Our forecasts were better than blind guesses, but not by much.

Basically, if these people weren’t able to infer anything about the future performance of these soldiers based on multi-day, intensive exercises, I wonder how much anyone can infer about job candidates on the basis of four or five one-hour-long chit-chats.
posted by mhum at 3:35 PM on February 21 [6 favorites]

Can you write an algorithm to detect a cargo cult?
Yes.
posted by a complicated history at 3:43 PM on February 21 [5 favorites]

When I interviewed at Large Search Company, they actually had me go in for a pre-interview prep session to watch talk about what would happen in the interview and then sent me home with a syllabus of subjects that I should study up on for the interview and a bibliography of books to read. I got about half-way through studying and emailed them to cancel the interview.

If anyone needs a copy of Cracking the Coding Interview, send me a MeMail.
posted by octothorpe at 3:44 PM on February 21 [5 favorites]

Sitting down and talking to someone human to human gives me most of what I need to know when hiring a software developer. Having a genuine conversation with someone is a great way to get a read on where they’re at. But then, I know what I’m talking about and am generally actually interested in people’s opinions on software development topics, even if they have fewer years of experience than I.

These sorts of human conversations also don’t “put people on the spot” which just seems like a way to screw them up and make them seem less competent than they actually are. I don’t intend to play those kinds of shitty head-games on the job, so why would I play them during the interview process?
posted by chasing at 3:49 PM on February 21 [6 favorites]

I remember way back in the day I interviewed for a web designer position and they asked me to design them a website by writing HTML and CSS on paper with a pen and no reference materials allowed. I waited until they left the room Nd were down the hall before I went home.
posted by Ghostride The Whip at 3:51 PM on February 21 [7 favorites]

This is why I’m glad I went back to grad school. I met someone on break last Thursday, he offered to have me come job shadow with his team and now I’m doing that next Thursday. I’ll get to see what the job is like and I have a feeling open some doors. Fuck trying to wade through a bunch of bullshit AIs selecting resumes and weird fucking tests like this. I just want to talk to people about what they do, why they do it and why I can do it (maybe) slightly better.
posted by OnTheLastCastle at 3:51 PM on February 21 [1 favorite]

> Sitting down and talking to someone human to human gives me most of what I need to know when hiring a software developer

This. And what you need to know is (a) are they genuinely interested in software dev, and (b) do they seem like a good fit for the team. Given those two things, anyone can be productive (on my team).
posted by merlynkline at 3:52 PM on February 21 [3 favorites]

When I would post a job for a technical tester or software dev for a not so big startup in NYC, I would get hundreds of responses. I had to have something to start screening with. No cover letter, not looking at your resume. Awful cover letter, not looking at your resume. Give me something, anything of interest to work with, I didn’t care what it was – talk about the relevance of your fiber crafts experience, anything, please lighten the tedium of looking through hundreds of applicants – I’d look at your resume and probably schedule a phone call (because honestly, resumes are pretty useless as a filter other than to get a sense of how long you’ve been working and the kinds of things you might know about).

When I was looking for jobs, 4 times in a couple year stretch of bad luck, I sent out over a hundred applications each time, tracked the whole process in a spreadsheet. It seemed pretty random as to who would respond, how far things would go, which ones would make an offer. Came to conclude that it’s a numbers game and you never know which applications are going to be the right one at the right time.
posted by kokaku at 3:53 PM on February 21 [2 favorites]

Timely. I’m in the middle of interviewing software developers right now.

I have no idea what I’m doing, really, and it’s nice to know that giant companies don’t, either. When you’re interviewing someone, you’re trying to predict the future, and that’s the hardest thing to predict.

We do have a programming test – created before I got there, that I had to take myself to get hired – but we let people take it home and give them a few days to do it. I suspect that its very existence has chased away more than one good, experienced developer. I excuse it to myself with the idea that we do kinda boring, simple, business-process work sometimes, so if you’re not up for the boredom of the test maybe you won’t be up for the boredom of the job. Am I right about that? Probably not. Who knows?

We have gotten one good hire out of it, a young woman who keeps taking on new challenges and growing as a developer with each project she’s given.
posted by clawsoon at 3:54 PM on February 21 [3 favorites]

The federal hiring process has plenty of things to complain about — especially with regards to how long it can take — but I really have come to appreciate that it isn’t as prone to these unrealistic high-stress interviews. There’s something refreshing about simply talking with someone about what they’re working on and how they work rather than putting people into a high stakes whiteboard test.
posted by adamsc at 4:05 PM on February 21 [4 favorites]

Well, clawsoon, I’ve read there are three kinds of people who spoil teams and they’re jerks, people who won’t do their fair share and people who are overly negative/down. Programming tests don’t really catch any of those so my advice is to have a good conversation.

I guess we could call them Slackers, Assholes and Depressed (Dudes) and use the acronym SAD. (The classification of which three types utterly decimate group cohesion is from a book called The No Asshole Rule, some HBR article that inspired it and The Power of Bad a new book about how negativity really sticks with us.)

I’ve had an asshole turn me into a slacker AND extremely depressed! So fuck people who are assholes at work.
posted by OnTheLastCastle at 4:06 PM on February 21 [8 favorites]

Honestly, you’d think a lot of places screen to favor assholes. If someone devised an emotional intelligence test you could whiteboard, it would be a more ruthless method of culling candidates than any conceivable algorithm test. One of the things I like the most about my current place is that our orientation is a week long and consists of mostly classes on how to communicate effectively and kindly, aside from the obvious deep dive on the company itself.
posted by feloniousmonk at 4:14 PM on February 21 [1 favorite]

Sitting down and talking to someone human to human gives me most of what I need to know when hiring a software developer

So this is Not Wrong, but it’s historically how tech companies end up hiring all white guys, or to a lesser extent, all Indian guys.

and (b) do they seem like a good fit for the team.

sigh. So do you want to hire a jerk? No. But this is also how underrepresented groups keep being underrepresented in tech. “good fit” is a pretty fine line to walk.

they actually had me go in for a pre-interview prep session to watch talk about what would happen in the interview and then sent me home with a syllabus of subjects that I should study up on for the interview and a bibliography of books to read. I got about half-way through studying and emailed them to cancel the interview.

They do this because it’s very helpful for students who are well-connected with existing people in tech. Apparently doing this helped improve the interview pass rate for HBCU students.
posted by GuyZero at 4:16 PM on February 21 [12 favorites]

This is definitely bringing back nightmares of my last experience interviewing for programming jobs almost a decade ago. I quickly found I am truly, truly terrible at whiteboard write-code-on-the-spot interviews. Personally, I took that as a sign that I’m just not meant to code and moved to a different career field.

Definitely timely, as I’m considering leaving my current position for semi-unrelated reasons, and am starting to re-evaluate (and occasionally regret) my career choices to date. Some days I wish I had stuck with software (particularly when I see what y’all make, JFC) – maybe being bad at getting a job wasn’t so indicative of my actual capabilities to code.
posted by photo guy at 4:18 PM on February 21 [1 favorite]

I’ve had my share of interviewing (from both sides) and find that as an interviewer I prefer to ask just one simple question that involves coding something up (like FizzBuzz in difficulty), then chatting about things more generally. I do like to ask about a project the interviewee has done (could be a class project, or a professional one) that has stayed with them. That filters out most of the applicants who have no real idea about programming. Mostly though I just want to get a feel for the person.

On job applications though, I’ve had three really awful experiences that I remember too well.

In one I was asked to solve (at home) a geometric puzzle that was essentially a search for solutions. It was supposed to run in some limited time (not sure, maybe 60 seconds) my first solution (in Python) was way over the limit, but at that point I’d figured out what to do and recoded it in C which ran much faster than they’d asked and sent it in. But at that point the company had reduced the time alloted to maybe a tenth of what they’d originally asked and said that my solution had to be competitive with the fastest one they’d received and I called it quits.

Another (on site) interview was maybe ten minutes of technical knowledge and 6 hours of some bullshit personality assessment given straight out of a booklet. I didn’t get that job.

The worst one was recently where there was a week of at home quizzes ranging from programming to analyzing sql queries for efficiency. Not too bad, but after easily solving the first programming task their online quizmaster wouldn’t let me submit it. When I went to do it again, the question was maybe ten times harder and it timed out on me. Grrr. I decided to bag the whole thing, but a couple days later got a call saying that I should finish the weeks tests and that I was among the top candidates for the job. The money would have been good enough that I did finish the tests. I think I did ok on most of them, but the final question was to analyze a multi-thousand line program and then comment on it and draw a data flow diagram. Two hours for that and while I had some (I think) good comments, but my data flow diagram was way too awful (and I knew it). They said “Thanks, but no thanks” with no other feedback and in retrospect, if that was the kind of thing they wanted, I was pretty sure I’d not have enjoyed the position.

Thankfully, I’m retired now and should be able to make do with savings and Social Security. I still sometimes browse the job boards in case something really nice shows up, but I’m not seriously looking for a job.
posted by Death and Gravity at 4:32 PM on February 21 [1 favorite]

I’m the head of the web dev team at my small-ish startup and good Lord, is this really what it’s like to interview at other shops?

When I get a resume from wherever, my first step is to scan it then check out their GitHub/Gitlab/etc presence if any, to see what sort of code they’re capable of producing.
Next is a half-hour informal phone screen with me, their prospective boss.
After that they get a take-home open-book exercise to work on for the next few days, to see how capable they are of taking a skeleton project (built with the languages/libs/tools in our prod codebase) and a requirements doc and some wireframes and turning that into a working app.
We discuss that deliverable and a lot of other stuff in the in-person interview, where they meet with me and the rest of the web team and UX designers / backend engineers / product people / whoever else they’d be interacting with in their day-to-day duties.

It seems insane to me to conduct an interview any other way other than the one which mimics to the greatest extent possible the actual working conditions of the position. For this particular job title and for this particular company’s product, FizzBuzz is bullshit. Whiteboarding syntactically-correct code is bullshit. Memorizing trivia about today’s hot Javascript framework is bullshit. And I think that’s true for a lot of dev positions at a lot of companies. Very few places are doing the sort of work where every dev should know how to write a red-black tree class blindfolded. But those places are the Microsofts and Googles of the world, and if they’re interviewing candidates a certain way then that must be the best way for every two-guys-in-a-garage startup to do it too!, so here we are.

(any frontend devs in Boston looking for a new gig?)
posted by Old Kentucky Shark at 4:43 PM on February 21 [4 favorites]

Oh, and I did once hire someone who couldn’t solve FizzBuzz, but who otherwise managed the interview really well and since the company was a bit desperate to backstop me, we went with him. He got along well with everyone (except for the boss), worked hard and went from a poor novice to learning a whole bunch of good stuff and helping me out quite a bit. He eventually quit (because of the boss) and was quietly emotional as we said good bye and thanking me profusely for the opportunity and for what he’d learned (which had helped him find a much better job).
posted by Death and Gravity at 4:44 PM on February 21 [4 favorites]

I did once hire someone who couldn’t solve FizzBuzz

You’re braver and wiser than I am.
posted by GuyZero at 4:48 PM on February 21 [3 favorites]

Very few places are doing the sort of work where every dev should know how to write a red-black tree class blindfolded.

US Customs and Immigrations feels differently.
posted by GuyZero at 4:49 PM on February 21

I’ve been writing code for a living for about a decade now – I’ve interviewed for a few software engineering roles over the years, and I certainly appreciate it is arduous to do a series of 4 or 5 on-site interviews and can be pretty demoralising to get knocked back after setting aside half a day to interview and a few evenings prior to prepare, particularly if you’ve needed to travel for the interview. Depending on the market you’re in, and how much financial risk you can take, it can be much easier (and more profitable) not going after permanent roles and instead going for contract jobs, at least if you can find ones where you can make a case that you’re a good fit for the project or get someone you’ve worked with to recommend you. Companies tend to be much more relaxed about making quick decisions to try out a contractor because it is less commitment if the person turns out not to be what they’re looking for, or the project gets cancelled.

In the past two years while working at a large non-tech company I’ve sat on the interviewer side of the room to run about about 150 programming interviews. Some anecdotes:

For about a year our hiring process had a pre on-site phone screen that took about 10 minutes with a few simple technical questions, but no coding test. About 20-25% of candidates who applied for software engineer roles who passed the phone-screen and made it to on-site interviews had essentially no ability to write simple programs. These people often had reasonable looking CVs and could talk the talk about their experience. Once someone makes it to on-site interviews it’s a multi hour interview process involving multiple engineers who all need to write up reports about the interview afterwards, so the company invests about 1 day of engineering effort assessing anyone who makes it to an on site.

So if you are a capable programmer being asked to jump through hoops and do a few simple fizz-buzz puzzles during a hiring pipeline, apologies, but the hoops aren’t there because of you! If the market only had capable programmers applying for programming jobs, life could be a lot simpler and more efficient for everyone involved.

So we’re now doing an online programming test (just an hour or so) as a filter before letting people proceed to on site interviews. Even with this in place, we still get a minority of people who turn up to on site interviews and demonstrate no ability to write basic code, and when we try to understand what’s gone wrong and dig into the details of their online code test results, often it looks like they have (a) googled the question and plugged in code from the first search result, or perhaps (b) got their friend to sit the assessment for them.

About one in twenty or or one thirty candidates who interview for programming roles demonstrated a relatively high level of ability compared to everyone else — people who are able to ask probing questions to clarify requirements, brainstorm and propose multiple solutions for a given problem, explain the tradeoffs between the possible solutions, tell you which solution they would recommend and why, implement it in 15 minutes writing relatively clean code in one pass, answer a few analysis questions about performance, go in to some depth about the data structures they chose to use, and then answer deeper questions about what would be going on “under the hood” in their chosen programming language while it runs their code. Once you’re aware that these people are out there in the market, if you don’t need to hire someone to fill a role right now, you can keep interviewing until you find them. That said – we also hire people who demonstrate a lower level of ability than this in an interview for more junior roles. But it’s also worth noting that strong computer science graduates with no real world work experience who have learned to program competently (some don’t) and paid attention during their algorithms classes can do well in many of these dimensions during an interview.

It’s arguably even worse with IT services / IT consulting companies. It is potentially a very profitable business to be a shady middleman who can employ a fresh grad or someone who doesn’t really know what they are doing and then try to flip them and present them to a client as an “expert” / “experienced $whatever developer” in whatever the client’s problem or tech stack happens to be, then bill them out to the client at high-end daily contract rates. If you’re buying these kinds of contract IT / software engineering services and don’t have some kind of in-house capability to assess or measure if you’re being sold a lemon, you’re going to get absolutely fleeced while at the same time your project starts to go off the rails (if it isn’t off the rails already).

Personally I think it is unfair when companies give prospective hires larger take-home assignments to design & build systems as part of a hiring pipeline. This could be okay in principle if the company _pays_ the candidate a decent rate. For the hiring pipeline to be “fair” it should consume similar resources for the candidate and the company to try to figure out if each other are a good fit. I.e. it should require a fairly symmetric investment of time and resources.

It’s a bit of a numbers game from both the job seeker’s perspective and the employer’s perspective. Even people who usually do very well at artificial whiteboard algorithms interviews can have a rough day, or happen to get asked 1 out of 5 possible questions and that happens to be the one they’re weakest at. Some candidates get super stressed and anxious during interviews and freeze up, while in normal work situations they’d likely be able to think things over and produce good work. The questions or tasks that are asked during interviews only measure a subset of what really should be measured for the role, or measure things that aren’t really relevant at all. The hiring process is very flawed, and can be improved, but there would be a real cost to the business of not having it in place at all.
posted by are-coral-made at 4:55 PM on February 21 [6 favorites]

I have not read any comments. I started to read the article and came across
“Given an array nums containing n + 1 integers where each integer is between 1 and n (inclusive), prove that at least one duplicate number must exist. Assume that there is only one duplicate number and find the duplicate one.

You have 24 hours!”

So I thought trivial, and then re-read it. lol, clever question 🙂
posted by baegucb at 5:05 PM on February 21

@GuyZero

>> Sitting down and talking to someone human to human gives me most of what I need to know when hiring a software developer

> So this is Not Wrong, but it’s historically how tech companies end up hiring all white guys, or to a lesser extent, all Indian guys.

I’m a white guy, but I’ve got a strange professional background and I appreciate smart people who come from diverse backgrounds. And I’m someone who finds people different than me honestly pretty interesting to talk to. And I *HATE* monoculture — especially the sort of bland default techie monoculture. So this has absolutely not been a problem in my case.
posted by chasing at 5:06 PM on February 21 [1 favorite]

lol, clever question 🙂

Solutions here – I would have done #2, #1 is pretty obvious too, #3 blew my mind
posted by GuyZero at 5:12 PM on February 21 [3 favorites]

GuyZero: “prove that at least one duplicate number must exist. Assume that there is only one duplicate number and find the duplicate one.” going to infinity. Identifying a dupe is easy 🙂 That’s where I got a smile, proving the dupe exists, or perhaps I read the question wrong.
posted by baegucb at 5:32 PM on February 21

This crap is why I’ve been at the same company for ten years. I’m really not at all confident I could pass the interviews to get a better job.
posted by potrzebie at 5:39 PM on February 21 [3 favorites]

Every time this comes up, someone mentions FizzBuzz, and I want to know whether there are really coding interviews that require you to code FizzBuzz. Because that seems ridiculously trivial to me? I am in no way qualified to be a software developer, and I could definitely code up FizzBuzz. (I could partly code up FizzBuzz because the prof in my first CS class, the intro for non-majors, showed us how to code up FizzBuzz. But I don’t think I’d have trouble doing a different coding task of similar difficulty.) It’s a little shocking to me that it’s an effective way to screen for anything other than whether someone panics and freezes during a coding interview.

It seems to me that one thing that whiteboard interviews do is give a pretty big advantage to recent CS students. I’ve taken a couple of CS classes recently, and most of them had tests that required you to write out programs on a piece of paper, which seems like a totally weird and arbitrary thing to require. But it occurred to me at some point that those exams were really good training for whiteboard interviews: they’re a similar task, performed in a similar high-stakes setting. On the one hand, there’s a sense in which whiteboard interviews give non-traditional applicants an opportunity to prove their skills. But there’s another sense in which they favor people who have taken college CS classes and who have taken them recently.
posted by ArbitraryAndCapricious at 5:40 PM on February 21 [4 favorites]

I was Really Confident About My Biceps

User name! Freshly coded user name!
posted by GenjiandProust at 5:47 PM on February 21 [2 favorites]

Because that seems ridiculously trivial to me? I am in no way qualified to be a software developer, and I could definitely code up FizzBuzz

Yes, it is trivial.

AND YET
posted by GuyZero at 5:53 PM on February 21 [5 favorites]

It’s arguably even worse with IT services / IT consulting companies. It is potentially a very profitable business to be a shady middleman who can employ a fresh grad or someone who doesn’t really know what they are doing and then try to flip them and present them to a client as an “expert”

This is literally what I do and can confirm its immensely profitable. We’ve been fleeced banks for years and made great coin from all the post 2008 compliance and regulations. Its a very different part of the technology world from FAANGS and startups. One thing I will say about consulting companies is that they a have huge interest in getting you work. It’s essentially a numbers game, get as many grads as possible, farm them out as swiftly as possible. The great thing is the good ones get opportunities really fast if they prove themselves, we once had business analyst who just taught himself to code and made the system himself as it was faster. He would have never passed a coding interview obviously.
posted by Damienmce at 6:03 PM on February 21 [6 favorites]

If you’re buying these kinds of contract IT / software engineering services and don’t have some kind of in-house capability to assess or measure if you’re being sold a lemon, you’re going to get absolutely fleeced while at the same time your project starts to go off the rails (if it isn’t off the rails already).

No bank, outside of maybe investment bank front office quant/modelling teams, has the inhouse expertise left to accurately assess the quality of developers anymore. All thats left are technology managers who are usually from a biz or project admin background. You can get away with daylight robbery, maintaining ancient systems and going home by 6.
posted by Damienmce at 6:10 PM on February 21 [2 favorites]

The interviewer…asked me to code up a very involved image filtration algorithm…
Then came an analytics company that asked me to do a take home challenge. The challenge was a three sentence blurb. I did the best job I could on it and wrote a very involved multithreaded image processing system…..

Who can do this off the top of their head? Someone who writes image processing software for a living OR someone just out of school who still remembers a good signal processing class, I think. Someone who has spent a few years slogging away in Javascript frameworks or whatever most jobs actually have you do all day would have little chance.
posted by thelonius at 6:16 PM on February 21 [1 favorite]

Giant online retailer interviewed me on the phone once. I am a freelance coder and come from a small-shop environment where the goal is to make things on a small budget for a tiny number of users and make it work how the users want. Zero emphasis on nanoseconds of efficiency or proper algorithms. Except for maintainability, the only important thing was not spending 100 hours on the formalities of a 10-hour project. When interviewer asked me, “Tell me how you test something” and I said “I test it myself and then send it to the users and wait for feedback” I thought he was about ready to hang up on me. Then he started asking me for definitions of obscure programming terms I’d long forgotten and I hung up on him.
posted by thorny at 6:18 PM on February 21 [1 favorite]

Every time this comes up, someone mentions FizzBuzz, and I want to know whether there are really coding interviews that require you to code FizzBuzz. Because that seems ridiculously trivial to me?

I mean, that’s the point. Or at least it’s the premise of the article that introduced it widely, that it’s a very basic filter that will nonetheless catch a portion of applicants with legit-looking credentials.
posted by atoxyl at 6:18 PM on February 21 [5 favorites]

Yeah, FizzBuzz is trivial, it’s meant to catch out only the people who really have no idea what they’re doing and are just playing a numbers game trying to get a programming job. The more fiendish FAANG style tests are this idea taken to an extreme, where instead of using a low bar to filter out the least qualified applicants, they raise it up to a more difficult class of quizzes (thinking that will filter all but the highest quality applicants, but of course that’s not what it does AT ALL).

I’ve been at my current position for over a decade and have no plans to leave, and stories like this make me fantasize about spending some of my free time to go interview for CS jobs and then reject THEM when they make an offer b/c they had me do some dumbass coding tricks in step 2 of the interview process.
posted by axiom at 6:23 PM on February 21

@Damienmce , I appreciate your candour & taking my characterisation of the business in good humour, hope the business keeps rolling your way! I agree that contract work can provide opportunities for motivated people to really grow and gain valuable project experience.

> No bank, outside of maybe investment bank front office quant/modelling teams, has the inhouse expertise left to accurately assess the quality of developers anymore. All thats left are technology managers who are usually from a biz or project admin background. You can get away with daylight robbery, maintaining ancient systems and going home by 6.

You very accurately describe my (huge non-tech) employer’s previous approach to software engineering hiring: it was all entirely outsourced, they didn’t have any permie employees with engineering or tech capability, mainly just a bunch of middle managers with business or project admin backgrounds. If you wanted to have a career with the company as an employee, you had to be a project manager, there were no opportunities as a tech specialist. After operating this way for about 10 years they started to figure out that it didn’t produce good business outcomes.

Presumably in about 10 years someone will bring in a management consultant to explain that having permanent engineering employees is expensive while the longer-term benefits to the business are harder to estimate, and the great cycle of outsourcing life will begin again.
posted by are-coral-made at 6:28 PM on February 21 [1 favorite]

One of the best ways to do a job interview is not to *need* to do the job interview.

Helps a lot. (Hard to do)
posted by aleph at 6:29 PM on February 21 [5 favorites]

I just found a new job through my network (full stack webdev, ten years of experience). I feel like that’s by far the best way to go for experienced people: you go to tech meetups, you meet people, you impress them, they let you know about a good gig and recommend you.

If you’re an experienced person that works much better than firing off a hundred resumes, imo.

You can’t build a network in a day, but a shortcut can be to give a talk. Meetups are always looking for talks, and you stand up there, you say “I’m Kwine, I’m looking for a new gig in X” at the X meetup, you give a great talk about X, and then people are going to want to hire you.
posted by Kwine at 6:32 PM on February 21

I interviewed onsite at a megacorp (for a job with the word “algorithms” in the title, no less) and got asked FizzBuzz – and I MESSED IT UP! (yes, we are here in this very thread!) But I caught my mistake immediately on review, cheerfully went “oh whoops!”, proceeded with the rest of the interview more or less unfazed, and ended up with a very nice offer that I accepted. Part of the reason I decided to take the offer was because they were very kind and reasonable about me having a dumb moment like that, and didn’t expect me to be a CS fresh grad who was really good at doing “algorithms interviews”. I’m still at that job and wonder how the hell I’m ever going to leave, because I certainly haven’t gotten any better at those questions in the intervening years.
posted by btfreek at 6:32 PM on February 21 [4 favorites]

Also

> The great thing is the good ones get opportunities really fast if they prove themselves, we once had business analyst who just taught himself to code and made the system himself as it was faster.

People who understand (or can learn) about the domain and context and goal of the business problem, figure out which are the important parts to model, and then implement a (perhaps ugly) actually working piece of software are very valuable people!

I’d personally much prefer to be working on a project with people like this than colleagues who may be much more capable programmers but who are completely disinterested in understanding what the business actually needs them to do, or who don’t want to do any of the analysis work and expect well-defined formally specified coding tasks to be handed to them on a plate.
posted by are-coral-made at 6:36 PM on February 21 [2 favorites]

You know how some amazing speakers prepare a lot for their speeches, and some go up to the microphone and deliver a completely off-the-cuff talk?

Tech interviews are like if a hiring manager said, “I am only going to hire the best speakers in the land,” and then tested people by thrusting a mic into their hand, plunked them in front of a stone-faced stranger, and said “Quick! Tell me a story about… CAN OPENERS!” and if the person didn’t give a succinct, snappy, quotable speech about can openers immediately, the hiring manager would say, “Oh! Haha! You’re a terrible speaker! You couldn’t even give a five minute talk about CAN OPENERS! Everyone uses CAN OPENERS! You must have been lying on your resume! **I** can give a five-minute talk about a CAN OPENER and I deserve to be here, so you must not!”

Whereas if the job seeker had a 24- or 48-hour heads up, they could have given an interesting, thought-provoking speech. That job seeker IS a good speaker — they just aren’t a good EXTEMPORANEOUS speaker.

And — here’s the thing — **most tech work is not done extemporaneously**!!! You can think about (and Google) something for 20 minutes, or wrestle with a tricky problem for a few days, instead of rattling something off at a minute’s notice! Most of your interactions around your work are done in writing and text chat! Many of your tasks are as much about common sense as they are about math! Your colleagues who are itching to take the mic and belt out Can Opener Facts are honestly probably the LEAST helpful when it comes to real, messy, impactful programming work which is an equal mish-mash of people problems and computer language!

Storytime: I had a hellish time doing tech interviews as a career-changer from another industry. I got my current software engineering job through a take-home and then a thoughtful on-site where my choices on the take-home were discussed. In the past year at this job, I have gotten nothing but glowing feedback on my job performance. I constantly catch things in code review and make my colleagues’ code better, even colleagues who have been coding for many years, for BigCos. My code is praised. My colleagues seek out my advice and help, and my opinions and explanations about programming concepts are respected.

Extemporaneous speeches about can openers are not my strong suit. In fact, if someone shoves a mic in my hand and barks at me to rattle off the date the first can opener was invented, I will likely bomb the speech, even if I *am* an expert on can openers!

The annoying thing is, even though I am excelling at my job, if/when I would ever look for another job, I will have to spend many, many hours studying and drilling Can Opener Facts even though that has 0% to do with my job, and I’ll have to go through many humiliating interviews where stone-faced interviewers imply that I don’t know anything, that I don’t belong and that I’m not smart enough. I am not looking forward to that. Even typing this makes my heart race and my stomach hurt. But, that’s this unfair, bonkers industry, and I am stubborn enough and privileged enough that I will push through the humiliation and keep on fighting. Good luck to everyone else going through it.
posted by rogerroger at 6:46 PM on February 21 [5 favorites]

As has been mentioned above this dystopian hell interview trip *can* be bypassed. Though that’s not the most common route(s). The most common solution I saw above (there were others[networking]) was doing contract work for Agencies (or just yourself if you have the contacts). The bar to hire you is much lower if they have experience working with you. IIRC, a lot of the Agencies charge a stiff fee to “let you go” to them for a permanent hire position.
posted by aleph at 6:58 PM on February 21

It seems to me that one thing that whiteboard interviews do is give a pretty big advantage to recent CS students.

They definitely do, and it’s a big part of why they’re ultimately not going to be a reliable filter for good candidates. I’m nearing 20 years in this industry, and my honest answer to most of these kinds of questions is that it’s way more important for a candidate to know why they would care about these things and how to research them than to be able to rattle them off on command. 90% of this stuff never comes up, and the 10% that does you should be researching when it comes up even if you think you know it, to be sure you haven’t forgotten something.

Honestly, all of this bullshit is just the latest evolution of the kind of cargo cult interviewing techniques that proliferated in the late ’90s/early ’00s because “that’s how Microsoft does it”. Before it was stupidly detailed algorithm interviews, it was stupidly pointless lateral thinking exercises, and I’m sure in more time it’ll be some other stupid thing that doesn’t actually work but everyone copies because the big guys are doing it and they must know what they’re doing.
posted by tocts at 7:12 PM on February 21 [3 favorites]

One side effect of this system is to hire people who have proven compliance with company demands. The ones who have been hired have jumped over the bar on command. Those who did not jump were never in consideration, or never showed up in the first place.

I occasionally wonder if that’s why the FAANG’s end up buying so much of their innovation.
posted by cowcowgrasstree at 7:31 PM on February 21 [1 favorite]

If they really wanted to hire senior developers they should ask things senior developers/architects in my position get asked “For n programmers and y budget please make everyone happy oh yeah we need to off-shore more code so this part of your budget is gone. Where will the application suffer and how have you identified it as a core aspect of our value add to the market place?” MySpace did not lose to Facebook on performance or coding, in fact when they had equal traffic, MySpace made judicial use of Windows (?!) and CQRS, using half the hardware Facebook required to do the same thing. We call CQRS microservices now, but in any case the obsession with algorithms is silly out of very specific domain problems. It rarely impacts whether a business is a success or failure. Even in case of Google it is often easier to buy yourself out of a problem then it is to hire Feynman. Maybe if MySpace spent less time creating more efficient systems and more time analyzing their business, they’d still be around.
posted by geoff. at 8:00 PM on February 21 [1 favorite]

I have often been “the business analyst who learned how to code something because it was faster than waiting for the actual dev team” (don’t worry, I always followed company code review policies and had a senior dev approve my changes)…and having been in the industry in various roles for nearly 20 years, I’m confident I could do well as a programmer at most places if I had to make it my day job… but I wouldn’t pass a coding interview because I lack the background and rigor.

That would make me a junior at best. And I still bet I would do a better job than even most senior devs at the companies I’ve worked with. That’s not a brag, that’s just what I see. Most companies don’t need better technicians who know more magic spells. They need to foster a culture of communication, ownership, and collaboration*. Yes, you have to know enough to be able to build things and sometimes untangle poorly planned messes, but your ability to do those things has as much to do with active listening and user empathy and creative abstraction (sometimes even just for fun) as it does with being able talk about big O notation and the vagaries of searching a binary tree.

*and they need to treat programmers better
posted by Doleful Creature at 8:10 PM on February 21 [3 favorites]

An innumerable number of writing problems.
posted by medusa at 8:30 PM on February 21

Doleful: some of the best managers I ever worked for had similar backgrounds. You could make a lot of techies happy somewhere. 🙂
posted by aleph at 8:50 PM on February 21

It’s a little shocking to me that it’s an effective way to screen for anything other than whether someone panics and freezes during a coding interview.

As one of the people who handles the technical part of the interviews for my organization, I try to compensate for this. I want to provide an environment that at least does not exacerbate the inherent stress of the situation, and give candidates time to take breaks to center themselves if necessary. And I try, when evaluating the results, to control for candidates’ panic level. This has meant taking a few “leaps of faith”, where it was hard to see their technical skill through the fog of their anxiety but we hired them anyway. And those people have turned out great.
posted by Jpfed at 8:57 PM on February 21

I think I know a fourth solution to the duplicate number problem:

Starting with zero, xor that with each number in the array, then xor that with each of the numbers between 1 and n inclusive. You’ll be left with the duplicated number, which is the only one that got xor’ed three times instead of only twice. Because, as apparently all programmers know, integers with xor are a commutative group where every element is its own inverse and the identity element is zero.

My wife assures me that real programmers don’t do this kind of stunt at work, but you can bet she practiced it at home while she was looking for a job.
posted by meaty shoe puppet at 9:10 PM on February 21

I think I know a fourth solution to the duplicate number problem

FYI, I think this only works when the duplicated number appears an even number of times. Some variations of this problem specify that the duplicated number appears exactly twice while every other number appears exactly once. This version only says that a single number is duplicated but allows for multiple duplications (e.g.: every single number in the array could be the same).
posted by mhum at 9:25 PM on February 21

Whoops, you’re right. I assume she was practicing the variation you describe.
posted by meaty shoe puppet at 9:42 PM on February 21