The Horrifically Dystopian World of Software Engineering Interviews
February 21, 2020 2:10 PM   Subscribe

Jared Nelsen describes what it's like interviewing for software engineering jobs in 2020 as an experienced hire. After the article hit number 1 on Hacker News, he wrote a follow-up.
posted by Cardinal Fang (162 comments total) 44 users marked this as a favorite
 
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 [63 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 [34 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 [4 favorites]


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 [10 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 [23 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 [26 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 [29 favorites]


I do not have a positive attitude towards recruiters. No, I do not.
posted by SoberHighland at 2:37 PM on February 21 [8 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 [10 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 [65 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 [13 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 [8 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 [29 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 [20 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 [7 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 [5 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 [11 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 [7 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 [6 favorites]


That was the disease. This is the cure
posted by Leon at 3:05 PM on February 21 [30 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 [19 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 [3 favorites]


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 [27 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 [1 favorite]


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 [23 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 [7 favorites]


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 [5 favorites]


> 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 [17 favorites]


Can you write an algorithm to detect a cargo cult?
Yes.
posted by a complicated history at 3:43 PM on February 21 [15 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 [10 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 [22 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 [12 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 [5 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 [4 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 [5 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 [10 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 [20 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 [6 favorites]


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 [27 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 [3 favorites]


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 [4 favorites]


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 [7 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 [9 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 [6 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 [12 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 [1 favorite]


@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 [5 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 [4 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 [6 favorites]


I was Really Confident About My Biceps

User name! Freshly coded user name!
posted by GenjiandProust at 5:47 PM on February 21 [8 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 [12 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 [8 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 [3 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 [3 favorites]


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 [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 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 [7 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 [2 favorites]


@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 [2 favorites]


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 [9 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 [5 favorites]


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 [8 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 [6 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 [22 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 [1 favorite]


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 [8 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 [3 favorites]


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 [3 favorites]


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 [10 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 [3 favorites]


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 [3 favorites]


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 [2 favorites]


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 [1 favorite]


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


From 2000-2015, the amount of time between starting the hunt for a web development position and my first day in the new job was only 2-3 months. To back up the first comment here, I got my first real web dev job in 2000 because I had a CS degree and 3 months experience with the language they wanted - that's it. (And it worked out, too - I spent several years there.)

TBH, eventually I got cocky about it, quitting jobs and moving around the country secure in the belief I could quickly find work just about anywhere.

That all changed when I turned 40. Suddenly the job searches drag for months and only end with contract positions. My current job search is about to celebrate its 1st birthday.

Yeah, I have interview war stories.

On the one hand, I feel better knowing this guy is 20 years younger than me, prepares 20x more than I do, and fails tech interviews just as hard.

On the other hand, this guy is 20 years younger than me and already has a broader resume than I do - web dev AND mobile dev AND machine learning! - so he can go fuck himself.
posted by frogstar42 at 10:17 PM on February 21 [4 favorites]


Nerds! XOR is how I anonymized IP addresses when iff the results of the study were interesting it would be a shame to not be able to de-anonymize them.

Which is another thing that makes these interview and job-hunting stories horrifying. You've done so many things over a couple of decades that you probably shouldn't actually talk about. Technically employer owns your work. And then the NDAs. It's an iffy situation all around. I couldn't write a cover letter or CV that was more than a paragraph.

Anyway, I try to avoid this sort of horrible interview thing because I haven't had to do it for decades.

But once, fuck me, I saw a YouTube thumbnail with a Google interview question where I went Pssht trivial pay no mind. All day that question kept popping into my head during commercial breaks or other moments when I had nothing better to do. It haunted me over and over and over. Oh how I wish I hadn't seen it.

A while later after trying not to think about it but failing... 0 < 1 < 2 < 3.

You have 25 horses who always run the same speed. (spherical cows)
You can only race them 5 at a time.
How many races do you have to run to find the fastest 3 horses.

Gah, maybe I could have done that in half a minute but I really didn't want to even try. But it haunted me until it came down to some bit of maths.
posted by zengargoyle at 10:24 PM on February 21


The future: doing an endless amount of unpaid makework labor amounting to jumping through arbitrary hoops at the behest of taskmaskers looking for any excuse to fail you for the slim chance of being allowed to sell your services to them on a more consistent basis, forever.
posted by JHarris at 10:30 PM on February 21 [7 favorites]


This thread is giving me a case of the DT's, started a few ironic comments but backspaced, between this and the Frontline Amazon expose sortof looking forward to the pandemic.
posted by sammyo at 10:38 PM on February 21 [2 favorites]


Also:
I attempted to remedy my chronic unemployment last September with a phone test on Python with a headhunting outfit whose name I forget. The idea was to write Tic-Tac-Toe in 30 minutes. I have my questions on whether writing Tic-Tac-Toe is a problem that will ever come up in production. Maybe I'm not the fastest coder in the world, but I know my Python. They can go to hell.
posted by JHarris at 10:38 PM on February 21


That racehorse Google question, yuck. It’s so arbitrary and binary: do you get the right answer, or not? How does the interviewer progress if you get it right away, or very slowly?

At Social Media Company where I work the coding interviews are a slightly more plausible implementations of still-abstract algorithmic problems. They are designed to escalate: you don’t get the one true answer or declare victory, and the interviewers always have a way to add or change parameters if you’re fast. Coding interviews are interspersed with system interviews that are higher-level and more open-ended, for example asking a candidate to come up with a strategy for building a product feature. One of mine was about an API that might sit behind a news feed, and the escalating questions were about additional features like images or links.
posted by migurski at 10:42 PM on February 21 [2 favorites]


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.

Ha, that describes about 3/4 of my ~18 years of web dev experience. Little did I know I'd be punished later in my career for my employers not hiring QA staff/existing in a time before automated testing.

Interviewers also don't like to hear my usual development environment is Notepad++.
posted by frogstar42 at 10:52 PM on February 21 [4 favorites]


zengargoyle: You have 25 horses who always run the same speed.

This is a classic brainteaser puzzle that seems much more Microsoft circa-1992 than present-day Google. I'd honestly be quite surprised if they were asking this as a regular, current interview question. It's really not a very good question for an interview. All it seems to be testing is, "is this candidate good at brainteaser puzzles?" which I'm skeptical is really that relevant to day-to-day software engineering.

In any case, the answer is (I'm pretty sure?) 7. Answer follows below...
.
.
.

If you had to only find the fastest horse, it's pretty straightforward. Group the 25 horses into 5 groups of 5. Run a preliminary round of 5 races, one for each group. Let's call the groups A, B, C, D, and E and we'll denote the winners of each group as A1, B1, ..., E1; similarly, let A2, B2, ..., E2 denote the second-place finishers in each group and A3, B3, ..., E3 denote the third-place finishers. Then, run a "winner's race" of A1, B1, C1, D1, and E1. Obviously, the winner of this winner's race will be the overall fastest horse.

Now, let's figure out which horses could be the second-fastest horse. Suppose, without loss of generality, that horse A1 won the winner's race, B1 came in second, and C1 in third. With a bit of thought, you can infer that the only possible candidates for the second-fastest horse are B1 and A2. For example, B2 cannot be second-fastest because we know that it's slower than B1 (from the group race) and that B1 is slower than A1 (from the winner's race). Similar logic reveals that the only candidates for third-fastest are B1, C1, A2, B2, and A3. So, running a "consolation race" of B1, C1, A2, B2, and A3 will make sure that the first- and second-place finishers in that race are the second- and third-fastest horse, respectively.
posted by mhum at 11:37 PM on February 21 [2 favorites]


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

Fair point. I mean, *my* team isn't a bunch of jerks so a jerk wouldn't be a good fit :P

I guess if they *were* a bunch of jerks that kept hiring jerks then they'd fail and dissolve pretty quickly in the environment I'm in. In other words I'm lucky enough to work for a company with values that wouldn't put up with that shit for very long. So I guess that approach is OK for me but not a one-size-fits all. Glancing around the office, I am conflicted - my immediate thought is that we do pretty well as far as underrepresented groups go but I can also see that they're still badly underrepresented; just not as much as some (most?) other shops.

(Edited to add: I misread what I was responding to, slightly. But the general point still stands: I'm probably lucky that this approach seems to work quite well for me.)
posted by merlynkline at 12:11 AM on February 22


It's a perfect question for Google because it a distibuted map reduce ordering. But I agree on the brain teaser aspect as an old who grew up taking Reader's Digest 'IQ' tests and spending too much time on these sorts of logic puzzles.

What I would expect as an answer is a more generic pick top X of N taken M at a time. And the realization that position can only increase and transfers and that the final answer is 0, 1, 2 as the number of races lost.

0 1 2 3 4
5 6 7 8 9
10 11 12 13 14
15 16 17 18 19
20 22 21 23 24

If you have ever lost to more than 2 horses, you're not important and will never be in the top 3.

First race 0,1,2 forget 3,4 they're out.
Continuing 5,6,7 10,11,12 14,16,17 20,21,22.
All are groups of 0 faster horses, 1 faster horse, 2 faster horses.

0 1 2
5 6 7
10 11 12
14 16 17
20 21 22]


Run the 0 loss horses because losses to faster horses transfers down.

0 1 2
5 6
10

Every other horse has at more than 2 horses faster and will never be in the top 3. Horse 0 has already beaten every other horse, that leaves the final 5 horses, race 1,2,5,6,10 and the top two will be second and third after 0.

The thing they want to know that you can grok is that the number of losses can only increase, that there's a cut-off point where you can forget about any horse that has lost to more than 2 other horses. 0 < 1 <2; ...

Now, generalize that into picking X of N taken M at a time. Totally a Google sort of question.
posted by zengargoyle at 12:20 AM on February 22 [1 favorite]


Sadly, this makes me think of 25 people applying for a job and splitting them up between 5 people and narrowing it down to three final candidates. Ugh.
posted by zengargoyle at 12:28 AM on February 22 [4 favorites]


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!"

I would be so excited if all interviews were like this. I would tell elaborate lies (hey, they never said it had to be true) and I’d probably be the CEO of Goldman Sachs right now.
posted by sfkiddo at 1:00 AM on February 22 [2 favorites]


don’t worry, I always followed company code review policies

I once worked at a large company where the bug tracking process was so byzantine that the only way to actually get a bug fixed at all was to fix it first and only then file the ticket.
posted by Cardinal Fang at 1:24 AM on February 22 [2 favorites]


Two quick points that other people have hopefully made by now: job seeking sucks, no matter the field, partially thanks to the defunding of Human Resources departments. Of course now I can't find the article that convincingly argued this.

Two: Nelsen talks about a mentorship pipeline and professionalization of software engineering but seems unaware of the Professional Engineering license which is intended to be exactly this. A PE exam for software engineering was added in 2013 but interest had been pretty low.
posted by muddgirl at 1:28 AM on February 22 [1 favorite]


you go to tech meetups, you meet people, you impress them

... you melt down, you finally think about getting that diagnosis...
posted by Cardinal Fang at 1:33 AM on February 22 [9 favorites]


... you melt down, you finally think about getting that diagnosis...

(Sorry, I realise how flippant that sounds. I'm trying to say that neurodiverse people can have trouble relating to situations that may be reasonable and natural to neurotypicals. It's a lot of the reason why we chose to work with machines in the first place, instead of with people, and that many of us made that choice long before we, or anybody else, knew anything about the nature or even the existence of neurodiversity. Thanks for not flaming me.)
posted by Cardinal Fang at 1:44 AM on February 22 [6 favorites]


you go to tech meetups, you meet people, you impress them

... you melt down, you finally think about getting that diagnosis...


Yup, and that's not even the worst problem with this approach. 5-8 years ago, when I was new to the city I currently live in, I used to go to tech meetups sometimes, and it was just so patently obvious that most of the people there were just looking to Network™—it was just a bunch of people who didn't have jobs (or connections) trying to find jobs (and connections) by talking to each other. Completely useless for finding a job, and now that I'm in a position where I'm trying to find people to hire, it's also pretty useless for finding people because there's so many people who are just there to put up a front and Network™, rather than actually being interested in whatever the topic of the meetup is.
posted by tkfu at 2:10 AM on February 22 [5 favorites]


horses... I'm going with 5 races
5 groups of 5
once you've raced them all you know their speeds because you were measuring... you were measuring right? why would you do something this important without instrumentation, auditing, and reporting?

i joke but also that's the direction I'd go in an interview just to point out how artificial and ridiculous these kinds of questions are - i wouldn't get the job but I'd leave the interview happier i think
posted by kokaku at 2:24 AM on February 22 [9 favorites]


Microsoft circa-1992

Still waiting for someone to ask me why manhole covers are round, so I can look at them like they are insane, pause a long while, and say , as if it is the most obvious thing in the world: "Because manholes are round!"
posted by thelonius at 4:11 AM on February 22 [9 favorites]


"You have 25 horses who always run the same speed."
There isn't a fastest one then, trivially. Job done and we can all go home.
posted by edd at 4:19 AM on February 22 [6 favorites]


Seriously, if you want someone to spot bugs in programming you want someone who thinks too literally, like this idiot here.
posted by edd at 4:23 AM on February 22 [3 favorites]


The version of the question I've seen says "you don't have a watch", if you did it would be 5 races.

My reading of the question makes me think you need 6 races. 5 initial heats, take the winner from each heat (arbitrarily pick one if there is a tie for first) and then race those to determine the fastest.
posted by epo at 5:13 AM on February 22


Why do people find coding so easy and natural, yet documenting so difficult and excruciating? Good documentation makes setup a matter of minutes over hours, or hours over days, but then the noob hasn't passed through the gauntlet, have they? Never mind the increased cost to the bottom line in lost productivity to everyone involved.

Why are so many neccessary dev tools hard to use and easy to break? The fact that a website like ohshitgit.com has to exist is testimony to this. Brogrammer X doesn't want others to have a free ride; he wants them to struggle and suffer as much or more than he did. Never mind the increased cost to the bottom line in lost productivity to everyone involved.

I was complaining openly about the self sabotage of "tech machismo" as a metaphor for human greed and warfare twenty years ago, but people looked at me like I had horns growing out of my head.
posted by CynicalKnight at 5:33 AM on February 22 [1 favorite]


posted by Cardinal Fang

For want of a vowel eponysterical was lost.
posted by inflatablekiwi at 5:54 AM on February 22 [4 favorites]


Still waiting for someone to ask me why manhole covers are round, so I can look at them like they are insane, pause a long while, and say , as if it is the most obvious thing in the world: "Because manholes are round!"

Hah, I got asked that in an interview for my first job in 1998; don't remember how I answered it. That interview lasted all day, 8 individual hour-long interviews with different engineers. That was after an hour-long interview at my school's placement office with HR and an hour-long phone screen. At least they took me to a fancy lunch.
posted by octothorpe at 6:14 AM on February 22 [2 favorites]


One problem with the Leetcode programming puzzles is that usually they are so constrained that the really clever solutions will only ever work with all of those constraints. In the real world you don't need to find the one and only duplicate in an array of integers with no possibility to copy or modify it, you are finding duplicates in databases or some collection of possibly somewhat heterogeneous or messy objects, or some more difficult criteria than just duplicates. Etc.

I've been trying a bunch of C++ ones on leetcode and the majority of the time simply using the standard library algorithms in a boring straightforward way gets me >80% score. In an interview I'd argue for the robustness and clarity of doing so, while also showing I understand any performance or other limitations at play. My only hope is to get to that stage of being able to talk to another software engineer with the same practical mindset rather than being filtered out earlier.
posted by thefool at 6:44 AM on February 22 [4 favorites]


Imagine a pathological situation where all the five fastest horses are in one initial group. Then, the three fastest horses will be the first three finishers in that group. Any solution for finding, in general, the three fastest horses out of all 25 must be able to correctly reach this result.
posted by thelonius at 7:01 AM on February 22 [1 favorite]


Why do people find coding so easy and natural, yet documenting so difficult and excruciating?

[...]

Brogrammer X doesn't want others to have a free ride; he wants them to struggle and suffer as much or more than he did.


I'm sorry, but this is much too reductive, and very unfair. Documenting doesn't have to be excruciating, but it certainly is difficult. A very quick list of some of the things that are hard about documenting any non-trivial piece of software:
  • The type of docs that are perfect for you might be useless for somebody else. Beginner docs and tutorials are a useless and distracting slog for an expert, and documentation that suits an experienced expert will look like impenetrable nonsense to a beginner.
  • Every piece of documentation you create has a maintenance cost forever, and it's really unclear what the best approach to keeping docs fresh and accurate is. Should I check through the docs every time I make a commit to see if my change has affected anything previously documented? That adds a really big burden to every single code change. Should it be a quarterly/point-release task for someone to go through and grok every change that's been made, then go through the documentation and make a big update? That's a huge and thankless job, and if you take that approach it generally needs to be done by someone with very deep and broad knowledge of the entire code base, plus knowledge of the problem domain, plus a certain amount of skill in writing. 90% of dev teams don't even have one person like that, and when you do have someone like that they're usually the most in-demand person on the team, so it's hard to get them to allocate a big chunk of time to fix up docs. Docs-as-code methodologies can help, but aren't a panacea.
  • Versioning. Versioning software with multiple parts, and the docs between them. Once you set up some kind of docs versioning system, deciding how important it is to backport docs fixes.
  • Good how-to-get-started tutorials and guides that approach real-world conditions usually involves explaining how your software fits together with other software. What do you do when that other software changes? (This brings in all the difficulties of maintenance cost and versioning, except on a nightmare difficulty setting.)
And this is barely scratching the surface. Creating genuinely good documentation for complex software is one of the hardest problems around, and keeping it good is even harder.
posted by tkfu at 7:03 AM on February 22 [8 favorites]


There's a reason that my LinkedIn account has a more polite version of this in my profile:
"I don't do whiteboard interviews or coding tests; save your hoop-jumping for someone else. However, if you want to have an in-depth discussion about a project I've coded previously, or if you'd like to work through an actual real-world problem (i.e. not FizzBuzz) with me to see what my process is, let's talk."
Unfortunately, the reason is a long, painful, humiliating job search that took place during 2016/2017. I've still got the scars.
posted by Mr. Bad Example at 7:11 AM on February 22 [4 favorites]


Test-based hiring is a least-bad solution to the following challenges:

* the vast number of fraudulent or self-deluding applications that have to be dealt with

* the desire to hire on merit and not charm, affinity, networking, or claims of past results that might have been attributable to colleagues or might not be repeatable

* the costs of hiring errors: lost on-boarding spending, lost opportunity to hire someone better, potential to be sued by someone who is quickly fired

I don't often hire for the kind of roles that are amenable to test screening now, but when I was hiring for such roles, the tests were a godsend.
posted by MattD at 7:40 AM on February 22 [1 favorite]


I've been watching this thread since the beginning. I kept thinking, ya know, I really should contribute. I'm a software engineering manager, having been a software engineer for many years. I've conducted a fair amount of interviews, both technical and of the "culture and fit" variety.

I'm sitting here thinking to myself, hey, I've got a three-hour, mandatory training course I need to complete that's just about interviewing. It focuses on removing bias, improving diversity, and maintaining a consistency of methods across teams. Surely this is somehow relevant?

But I'm a lifer. I've been with the same company for almost fifteen years. I've only really done internal interviews for my own advancement. Often with people I had built professional working relationships with, making the interview process essentially a formality.

This post has reinforced the gratitude I feel for my current situation. My team is happy, highly functional, extremely diverse, and nothing like the horror stories I hear online. In fact, with new hires and interns, one of the common themes is a need to sort of deprogram (heh) their defensive behaviors learned at other companies. Things like not asking questions, being terrified of making the smallest mistakes, and not knowing that constructive feedback can be a healthy, collaborative, two-way street rather than a personal attack steeped in office politics.

So, with a rather soullessly verbose wit, I can only add to this thread a huge sigh of relief and a genuine stab of empathy for the unlucky many that have been documented in this thread.
posted by Godspeed.You!Black.Emperor.Penguin at 8:12 AM on February 22 [3 favorites]


zengargoyle: "You have 25 horses who always run the same speed. (spherical cows)
You can only race them 5 at a time.
How many races do you have to run to find the fastest 3 horses.
"

Surely the answer to this fastest horse teaser from upthread is zero races?
The problem stipulates that you have 25 horses, all of whom run at the same speed, so there is no fastest horse (or alternately, every horse is fastest horse.)

(I mean, I know the question is supposed to be read such that each individual horse never varies its individual speed from race to race, but if I got this in an interview, I'd give my answer, and then explain why my answer exposes the need for better understanding of the problem being solved / clearer requirements before one attempts a solution, and oh incidentally this is yet another reason why brain teaser questions are bullshit... )

(I see others got here before me, which coincidentally pretty much sums up my interview experience...)
posted by namewithoutwords at 8:20 AM on February 22 [1 favorite]


The fundamental problem with hiring (not just for programmers, mind you) is the cost of onboarding an employee, and the cost of terminating an employee. It costs actual money to just commit to *trying* an employee. If we offloaded all this extra non-business garbage like health insurance and 401k savings plans, we could literally just hire anyone that walked in the door and expressed an interest in the job, sit them down and see what they can do. If they're no good, let them go.
posted by Xyanthilous P. Harrierstick at 8:27 AM on February 22 [4 favorites]


thelonius: Still waiting for someone to ask me why manhole covers are round, so I can look at them like they are insane, pause a long while, and say , as if it is the most obvious thing in the world: "Because manholes are round!"

A couple of weeks ago I saw a city crew trying to fish a square manhole cover out of a square manhole, and I immediately thought of that question. (Which I'm pretty sure I first read about in Reader's Digest...)
posted by clawsoon at 8:32 AM on February 22 [1 favorite]


a city crew trying to fish a square manhole cover out of a square manhole

I have never seen an explanation of why, supposedly, only a circular manhole cover cannot fall in the hole but a square one can. How many people who "know " this can actually give you the geometrical proof, assuming there is one?

Can't you just make a lip around any shape cover, so that it is larger than the hole and can't fall in?

The most convincing explanation I have heard is that the covers are heavy, and it's nice to be able to roll them, and to not have to deal with how it should be oriented to fit.
posted by thelonius at 8:36 AM on February 22


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.

This is what jumped out at me, too. It seems that there are a couple of things going on:

1. Demand isn't always as high as I thought it was, meaning that having a long, drawn-out job search process with lots of barriers isn't a bad thing for companies. Keep interviewing people long enough and you will eventually find a near-perfect candidate.

2. Even when there is demand for applicants, companies are dealing with massive numbers of unqualified applicants who look qualified on paper. Therefore, multiple levels of screening are needed simply to reduce the applicant pool to a manageable size and eliminate the most obviously unqualified applicants.

2a. However, the screening tools may be in conflict with broader goals of increasing diversity, opening doors to non-traditional applicants, or getting applicants with a broader range of skillsets and abilities. Especially if the screening tests are biased towards recent CS grads, that is who you are going to end up hiring.

I am in an entirely different field (though still in the broader STEM family), and we've had to start incorporating a very, very basic testing into hiring for engineering positions. People put "skilled at XYZ" on their resume, and they will tell you about how skilled they are in the interview, but we have found that when you sit them at a computer and ask them to demonstrate a few very basic tasks (i.e., create a file, bring in this spatial data, and do something very basic with it), suddenly many people turn out not to have the skills they say that they do. (We leave them alone at the computer, and googling how to do those tasks is a totally valid approach that many applicants either can't or won't do, any more than they are apparently capable of reading and following the "how to" information in the help files in that program itself.)

So I am not opposed to having screening tests in general, but they have to make sense, be appropriate to the situation, and not create opportunities for additional overt or accidental bias in the hiring process. And, the burden on the applicant needs to be reasonable -- people have lives and unless you are paying for their time, making them work extensively for you seems inappropriate.
posted by Dip Flash at 8:40 AM on February 22


thelonius: Can't you just make a lip around any shape cover, so that it is larger than the hole and can't fall in?

Hmm. For a round hole/cover, the lip can (in theory) be infinitesimally small in order to prevent the lid from falling in. And if the cover has non-zero thickness, you theoretically (ignoring steel's ability to stretch) don't need any lip at all. For a square cover, the lip would have to be at least... uh... sqrt(2) something something bigger than the hole.
posted by clawsoon at 8:42 AM on February 22


Can't you just make a lip around any shape cover, so that it is larger than the hole and can't fall in?

But remember that you can turn that square cover on the diagonal and fit it down the square hole, even with the lip, because the diagonal of a square is of course longer than each of the edges. So, easy to drop a square cover down a square hole, but impossible to do so with the round one.
posted by Dip Flash at 8:43 AM on February 22 [2 favorites]


Can't you just make a lip around any shape cover, so that it is larger than the hole and can't fall in?

You always need a lip, but the circle is the smallest lip. Your square cover needs a lip so large that the diagonal of the inside of the lip is smaller than the height of the square. (Covers rotate through three dimensions) The necessary size of the lip goes down the more sides you have, until you get to a circle. For regular polygons only, of course.
posted by mrgoat at 8:43 AM on February 22 [1 favorite]


the covers are heavy, and it's nice to be able to roll them

Fun fact, this is also why cows are spherical
posted by oulipian at 8:49 AM on February 22 [10 favorites]


Oh yeah, it's pretty simple! Guess I better keep my job.....
posted by thelonius at 8:49 AM on February 22


For my sanity, can I assume that any take-home work or any interview longer than, say, a couple of hours, is compensated, even at a nominal rate? Because otherwise, fuck that.
posted by maxwelton at 8:51 AM on February 22 [1 favorite]


Yeah, the manhole cover question is a bad interview question, but the proof is fairly straightforward. Because circles by definition have fixed maximum width no matter how you turn them, if Circle A is smaller than Circle B there is no way to turn Circle B in 3 dimensions so that it fits through Circle A. But, for example, take a square -- because you can turn the square so that it goes in diagonally (the widest distance between two points of a square), you need a much larger Square B to not fit through Square A.

(for a square, "how much larger" is 41% -- so a 3 foot square manhole would need a cover that was nearly 4.25 feet wide to not be able to go through it)
posted by tocts at 8:51 AM on February 22 [2 favorites]


For my sanity, can I assume that any take-home work or any interview longer than, say, a couple of hours, is compensated, even at a nominal rate?

Not in any scenario I've been in, no. If a company is far away from you (e.g. offering to relocate you), they will pay to fly you to them and for hotel and maybe food while you're there, but I have literally never been offered payment for take-home pre-interviews (taking up to 3-4 hours), nor for in-person interviews requiring 6-8 hours of my time.
posted by tocts at 8:55 AM on February 22 [1 favorite]


Trick question: those take home interview questions are also to see how well you accept unpaid overtime.
posted by mrgoat at 8:58 AM on February 22 [6 favorites]


For my sanity, can I assume that any take-home work or any interview longer than, say, a couple of hours, is compensated, even at a nominal rate?

Never ever ever.

In fact, last fall I had a multi-hour interview that was a 3-hour drive away. I drove down, stayed in a hotel the night before, and drove back afterwards. The company reimbursed me... $5 for parking.

(And I didn't get the job.)
posted by frogstar42 at 9:13 AM on February 22


I feel like I'm right in the middle of all of this. I spent a solid 6 months looking for work - mostly as an engineering manager, with a few interesting lead-level IC roles sprinkled in. It was just painful how much I was rejected not so much because of anything I did or didn't do, but more because the interviewer wasn't good at interviewing. I flubbed a few leetcode-type challenges, but mostly passed them. I lost out on a lot of jobs that I could have done very well, before finally "hitting the jackpot", and finding a good position with some really great people.

(Side note: I recommend that you always do leetcode challenges in Python, even if that's not your first language, or a requirement of the position. It gives you the best typed-code for time tradeoff, and its standard library gives you a lot of tools that work well for these types of problems. e.g.: DefaultDict will allow you to do in one line what most other popular languages make you type 3-4 lines to do.)

And, from the other side of the table, I had always been a fierce proponent of giving people a shot if they show you that they're smart and teachable. So, I'd push back against these too-tight filters all the time. And, then (in the past)... I ran face-first into leading a team with not one but two of these legendary "mis-hires" that everyone seems to fear so much.

One was a recent young graduate with zero experience, who would NOT. DO. WORK. I mean, it was comical. If I wasn't on top of this person near-continuously, they would sit around, play on their phone, or just be wondering around the office and not at their desk. The whole team did their best to teach this person how to do things, but it was an incredible time sink for the team, and especially for me. No amount of pointing out how bad the behaviors were changed much of anything.

The other was an older, very experienced/senior individual who passed the interview with flying colors. And who, upon starting to do real work, managed to make a complete hash of every task they were given. Not knowing basic things about the language (Python, in this case), not being able to solve rudimentary problems correctly, and just writing code that other people had to spend an inordinate amount of time correcting in code review. This person was nice, worked hard, and genuinely wanted to do the right thing. But, no matter how hard they tried (and, they tried really hard), they just couldn't do the job with any level of competency or correctness. I felt bad for them, but there was nothing I could do to prevent them to keep them from being a drain on everyone else.

The kicker in all of this is that no amount of testing or filtering would have prevented this. But, I'm more careful about pushing back on the filters. I guess that I at least understand now what companies are trying to do, even though it's not effective.
posted by Citrus at 9:22 AM on February 22 [1 favorite]


Oh dear, I didn't read the question properl ...
posted by epo at 9:23 AM on February 22


I'm sorry, but I have a hard time believing there's an epidemic of fraudulent coders in the job market.

If something is on my resume, I've done it. However, it might've been 5 or 10 or 15 years ago, so the details are fuzzy. It wouldn't surprise me if some interviewers think I'm lying.

If employers are that concerned with resume inflation, why not ask for references? It used to be a standard part of the hiring process, now almost no one does it. My last couple of clients seemed really happy with my work, I wish I had a way to share that.
posted by frogstar42 at 9:24 AM on February 22 [4 favorites]


I have never seen an explanation of why, supposedly, only a circular manhole cover cannot fall in the hole but a square one can.

Fun fact, a circle is not the only shape that can’t fall in! It’s just the easiest example of what are called “bodies of constant width”. The Reuleaux Triangle is another, and has been used as manhole covers.
posted by leahwrenn at 9:26 AM on February 22 [9 favorites]


Oh, I would like to add that when I interview people, I'm much more interested in how they answer questions than what specifically they say. Barring any insane answers of course.

We do coding challenges in our interviews, but they're fairly simple and nothing like those described above. The focus is more on their thought process and how they communicate that process. At the end of the challenge I like to do a collaborative post-mortem. Give them a chance to objectively critique their own work. Then I like to brainstorm solutions or enhancements together, emphasizing the back-and-forth exchange of ideas.

I can train somebody on the best practices for a programming language they're less familiar with. I can show people the particulars of our CICD pipeline or how to use the latest features of a framework or any number of things. But it's really, really hard to teach a good personality.

And to clarify, I'm not referring to some kind of social butterfly personality. Or anything specific in that sense. I'm referring to people being open-minded, patient, thoughtful, and capable of introspection. Beyond that, just some basic manners. I'll take a less qualified applicant with those traits over a more skilled but insufferable egotist every day of the week, forever. And thankfully, I'm privileged enough to have that luxury where I work.
posted by Godspeed.You!Black.Emperor.Penguin at 9:29 AM on February 22 [4 favorites]


I'm sorry, but I have a hard time believing there's an epidemic of fraudulent coders in the job market.

My employer has had entire crops of candidates that we couldn't hire because they had things like "5 years of SQL" on their resume, but couldn't answer "what is a join". Or "How would you print each successive number from 1 to 100". We're talking 30+ candidates delivered off the civil service eligible list, and we pulled the entire posting unfilled until we could re-post later with different candidates.

Some of this however, has to do with how entirely screwed up the civil service system is. (You can actually list several hundred years of full time experience, and nothing catches it, so people do)
posted by mrgoat at 9:35 AM on February 22 [1 favorite]


This Techcrunch piece on Secretly Terrible Engineers will never get old.
Secretly terrible engineers (STEs) are everywhere, and they may be on your very team as we speak.

There is only one way to stop this scourge, one interview to defeat them all. Well, more like a dozen interviews with white boards, but that doesn’t sound nearly as cool. But I digress. One interview to rat these jackals out, to prove just once that no matter how much you did in the past, you will be discovered as the Person Who Doesn’t Know The Big-O Of Trie Insertion.
posted by Ralston McTodd at 9:39 AM on February 22 [2 favorites]


Secretly terrible engineers (STEs) are everywhere, and they may be on your very team as we speak.

My most recent position as a business intelligence engineer involved three interviews. One with a panel of managers, another 'technical' interview with an older man who just asked if I can code in C# and then went about talking about his VR game he was building, and another with the head manager of the department.

The irony is the older fellow that interviewed me regarding my technical qualifications is not college educated in computer science, but he can build things for sure, but was protective of his code. He was asked to train me on a certain program that he built that archives our databases and that apparently triggered some sort of existential anxiety in him that has made him quite agitated and aggressive toward me. I finally got to see the code and holy shit. It's a fucking mess. It does some awesome things, sure, but man, dude has some sloppy, unnecessarily complex code. He basically pieced together his knowledge from Google, which is fine as a supplement, but it does seem to be a hallmark of lack of formal training in a certain generation of workers. Of course I realize that is not the case for everyone else who is self-taught but...yeesh. He could not explain to me how anything worked in a basic flow chart, because I don't think he knew. It JUST WORKED.

I don't even want to get into the labyrinthine SSIS packages I had to rebuild recently.

I'm sorry, but I have a hard time believing there's an epidemic of fraudulent coders in the job market.

I dunno about an epidemic, but I recently worked with a dude who managed to somehow fake being able to code/write SQL queries for 5 years and no one noticed until he was placed on my ETL development team. He could throw around enough data and programming jargon to fool managers or amateurs, but the second he used the term 'metadata' incorrectly I knew what was up. We had a peer review system in place for everything we built in terms of our ETL applications and nothing he built worked correctly. He constantly broke our applications that worked without issue. He was able to copy my and my colleague's simple work until he was asked to write more complex queries/build applications that required more complex transformations and script tasks, which made it obvious he didn't understand the fundamentals of anything we were doing. Honestly, it was almost as if he couldn't even look at an Excel spreadsheet and understand what he was looking at. He just got fired from that team about a month after I was hired at the aforementioned BI job. They're out there and they slip through the cracks.
posted by Young Kullervo at 10:07 AM on February 22 [2 favorites]


Secretly terrible engineers (STEs)

This is great and I enthusiastically agree with 95% of it, but the solution being "here, read these $80 worth of books" gives me pause. It may be a great ROI for the company, but probably not for the candidates. Depending on what the books are like, I can imagine spending weeks getting through eye-watering tech writing, only to wind up with nothing because I was the 6th best of 20 candidates.
posted by frogstar42 at 10:28 AM on February 22


I applied for a job as a computer operator at Rolls Royce Aero Engine Division back in 1975.
I went to the interview and completely blew it by telling the interviewer that I really wanted to train as a programmer, but didn't have the qualifications required for that job. They obviously turned me down as they had recently had to lay off a large number of staff - or so I thought.
Three weeks later I got an offer as a trainee programmer with them at a salary I could only have dreamt of at the time. I still don't really understand why as they were not taking on any other trainees at the time.
posted by Burn_IT at 10:50 AM on February 22 [2 favorites]


I'm sorry, but I have a hard time believing there's an epidemic of fraudulent coders in the job market.

The use of "coders" makes the next thing I'm about to say redundant, but this sentence makes it clear that you've never hired software engineers in your life.

My current company has an entire recruiting pipeline that weeds out the most obvious bullshitters, but when I was closer to the firehose, I'd estimate that the ratio of people applying with legit to resumes to those with total horseshit was about 1 to 10.

I could put down "3 centuries experience in TechnologyIJustMakeUpForThisJobReq" and I'd get hundreds of resumes (usually foreign, but they'd be local too) from people who spent the last 300 years working at a job where they just happened to be specialize in TechnologyIJustMakeUpForThisJobReq.
posted by sideshow at 12:18 PM on February 22 [2 favorites]


For my sanity, can I assume that any take-home work or any interview longer than, say, a couple of hours, is compensated, even at a nominal rate?

Personally, I figure this is a cost of being a professional, and one that gets embedded into the $300k compensation package, the same way that independent consultants bill at high rates to compensate for the 30 percent of the year they're sourcing new work, learning new tech, etc.

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

At least in my line of work (SRE), the programming interviews have mostly been on task. I've been asked to implement pstree, log filters, LRU caches, to write a small script to calculate the latency of a stock ticker API. There have been a few places that clearly repurposed their developer interview, where the final question was a thinly veiled request to calculate the number of cliques in a graph (I got it right and landed an on-site, but that isn't something I would make a requirement).

I haven't yet run a programming interview on the hiring side of the corporate world, but my gut thinking here is that if your company is built around An Algorithm, maybe the interview should focus some on said algorithm. Like, at Google, you'd ask people a series of questions like, "given a textbook sized document as input, generate an index" and then "given the index you built in question 1, write function search(A,B) that returns all locations in the document where word A is followed by word B". I'm sure there's enough variations on that to avoid the student effect.
posted by pwnguin at 12:25 PM on February 22


> The fundamental problem with hiring (not just for programmers, mind you) is the cost of onboarding an employee, and the cost of terminating an employee.... extra non-business garbage like health insurance and 401k savings plans

Whoa! There's a lot more to the cost than that. I'd argue that those are at least measurable and probably not that big.

If you have a few applicants and you pick someone who doesn't work out, the others may have found other jobs & are now not available (so be kind to those you reject!). You can't really throw someone into coding without providing some training and documentation, then someone has to review their code. A new hire under the present system is going to feel pretty crappy If they're excluded and given toy tasks to test them. Maybe under this new system that would be tolerable.

It's also a drain on team morale to hire people who don't work out.

It's also expensive to fire people, even in an at-will state, by any company of a size where there are lawyers advising H.R. months of "documented coaching" & the like.

If people could be paid a regionally customary contracting rate to do what's given as take-homes now, that might work. It would cost a lot more measurable money up front, but would end up in less guessing when it came to hiring which would save a lot. Those savings aren't easily measurable, so it'll be a hard sell to try this plan anywhere.
posted by ASCII Costanza head at 1:04 PM on February 22


At one point a particular committee got so critical that they rejected every packet for several months. When HR caught wind of this they decided to set up a test. They sent the committee a new round of packets and once again the committee rejected them all. HR then called them all into a meeting and explained that they packets they had just reviewed were in fact the hiring committee member’s own packets from when they interviewed for that company. They had unknowingly rejected themselves!

I freaking love this anecdote
posted by ejs at 1:43 PM on February 22 [3 favorites]


Hmm, it seems to me like nobody is mentioning the main thing about big company interview setups, which is that they have to interview a lot of people. This usually means that they have to have a lot of people doing those interviews, and that usually means you're going to have a lot of variance between interviewers. So anything too vague, like "talk to the person and see if you get a good feeling" is out, because who knows how that's going to come out across five different interviewers. Ok, that naturally leads to trying something more "objective", which is where you get into skills tests.

For skills tests, people tend to have two separate but related complaints: that they're too difficult, and that they're not relevant enough to on-the-job skills. The thing about the difficulty complaint is that, again because it's a big company talking to lots of people, most interviewers have asked the question to many people and have a pretty good sense of what range of answers they'll see. So it doesn't actually matter if it's a hard question or an easy question, how it matters is how you perform relative to other people (and actually harder questions are better than easy questions for this purpose, since easy questions can lead to a bunch-up of people at the A+ end of the scale).

The relevancy question is a little trickier, since for any given question there probably actually is a job at Big Company that it's relevant to (even the racehorses thing probably corresponds to stuff the compiler optimizer people have to prove or whatever). The problem is mostly that the company is large and contains lots of different kinds of jobs, and people are often supposed to be considered qualified for any job if hired, so in practice the only thing you can do is a couple of different skill-based questions and hope for the best. In most big companies they will make some effort to cover multiple areas in the questions they ask to try to get better coverage, but it's true it's something of a crapshoot whether you get something relevant to your area or not. It's also true that some areas are harder to ask about than others - testing someone on their debugging skills is pretty relevant for a lot of software jobs, but designing a debugging question you can ask to a bunch of people with no assumed background is difficult.

Finally, almost none of what I said above applies to small companies who don't have a lot of applicants. So why do they give up their advantage of being able to ask subjective and tailored questions and ape big-company hiring practices that they can't possibly perform as well as the big companies do? I have no idea, beyond that hiring is hard and they often don't know what they're doing.
posted by inkyz at 1:54 PM on February 22 [1 favorite]


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.

You pretty much can't predict performance. The most effective thing you can do is:

a) Remove the candidates who clearly don't have the skills. To do that you have to actually read the resumes. You also have to test some things in the interview only to the extent you need to to identify and eliminate the shameless liars and exaggerators.

b) Remove the insufferable dicks. That person in the witchcraft coding story linked (quite a ways above)? Not getting the job. They're probably going to think I'm the clueless one because I didn't know genius when I saw it. On the contrary, I saw what I was looking for.

That improves the odds immensely right off the top, but then you still have to:

c) Accept that a certain percentage of hires are going to be bad. Develop a mentoring and monitoring strategy that does not fall for the sunk cost fallacy. When you're sure you've made a mistake that isn't going to get better, pull the rip cord so you have room to hire a better one. Too many places I know just silently seethe about certain people, and sideline them to where they can't do much damage, but continue to pay them money. And often those people aren't even aware everyone is unhappy with their performance (because spineless managers), so they aren't going to magically improve.

So really your interview needs to test a few claimed skills at the level claimed, if they are important to the job; get them comfortable enough to show what they are really like to work with; and find out if they are the kind of person who can accept feedback about their performance and try to change it. Still kind of a tall order in a few interviews.
posted by ctmf at 2:19 PM on February 22 [5 favorites]


You have 25 horses who always run the same speed.

1. Run 5 races (1..5, 6..10, etc.). Time them secretly.
2. Run a 6th race for the winners of the first 5. Place an enormous bet on it.
3. Now you don't need the job any more.
posted by Cardinal Fang at 2:32 PM on February 22 [2 favorites]


Yeah, each individual horse is consistent with their speed, different horses have different speeds, you don't have a stopwatch. All you can do is run 5 horses at a time and find 1st, 2nd, 3rd, etc. by which order they cross the finish line.
posted by zengargoyle at 5:40 PM on February 22


I am part of this problem, since I do SWE interviewing, how-to-interview-people training, and (formerly) how-to-interview-here sessions for candidates, at a large tech company. Nobody knows how to do interviewing. If I re-interviewed it would be a crapshoot whether I'd get in, because of the noise in the process and the so-called "high bar" that is set.

Whiteboard interviewing is bad but it's the least-bad thing I currently know how to do. And that's *not* to filter out people who talk like a programmer but turn out not to be able to write FizzBuzz. That negative filter is easy enough. No, writing and talking about code is the only way I've found to distinguish candidates who are excellent from candidates who are in the broad middle. Storytelling about problems and interesting bugs, past team situations, these I have not found how to do that with. Now, maybe this is a mis-posed problem, and it would be better to draw randomly from the whole middle+. For sure it's hard on the many candidates who didn't, like, screw anything up, but also didn't stand out. (Sounds like the author of the linked post may have been in this position sometimes. Odds are I would be if I interviewed tomorrow.)

For whiteboard/laptop coding I don't care about syntax or details of what's where in your standard library, and I assure candidates of that. I also don't ask algorithms-heavy questions for coding. Just something with enough details managing logic and state that you have options to explore, and enough that everybody is likely to screw up somewhere. I really want to see, can you sense when your coding is running ahead of your grasp of what's going on. Do you know when to pull up and rethink or do you spackle point-fixes on in reaction to bugs. (Also, do you react to mistakes by attempting to explain over the interviewer (this is typically gendered yes).) Or for designing an interface, not do you foresee every future, but how do you respond when someone brings them up.

However, no matter what I do, the interview scenario is unrealistic bullshit. It is not how we work. The real job is mostly reading existing code, which I've not seen an interview built around? I'd also be interested to hear more about how people use "take a week to do this sample work", though as a candidate I'd hate to do that much unpaid labor as the norm.

Man, if I personally were hiring programmers, I would be tempted to rely very heavily on personal references from people who worked with other people. Personal experience signifiies a lot more than any interview. But that's a way to build an exclusive club, so socially there's something to be said for crapshoot interviewing of a broader set of people.
posted by away for regrooving at 9:37 PM on February 22 [3 favorites]


A lot of this system gets built on the fear of "lowering the bar": this idea that "if the alphas hire betas, then the betas can't distinguish alpha quality so they're go and hire gammas..." This I believe is crap on multiple levels. First, obviously, people aren't adequately represented by a single scalar much less a single category code. "Raising the bar" thinks in terms of a scalar value but acts as a qualitative narrowing of the field. Second, just practically it doesn't work that way in the case of an organization that keeps non-local input into hiring.
posted by away for regrooving at 9:47 PM on February 22


I managed a team for a few years, and got a lot of experience being the interviewer. We had to reject most of the people who made it onsite. We had a pretty good rubric of fairly straightforward data processing and modeling scenarios, and expected answers. Some of our best hires came without the necessary work experience, but were able to reason their way through easily.

The ugly secret though is that everyone on the team, including myself, suffered a bit of imposter syndrome: we needed help doing this really hard stuff, and we were muddling through it somehow, but we didn't really feel like we knew what we were doing and we hoped somebody from outside could show us The Right Way. Therefore we didn't really know how to even identify such a person.

We had our biases about how our jobs should be done, and our interview questions were a pretty good approximation of our day to day. We did have one interviewer who had a very simple algorithm question, which was highly controversial among the pool of interviewers, so it didn't have much weight; the same interviewer also tended to ask bookish questions which were also a little controversial.

Anyway, about a year ago, I found myself looking for another job, and discovered that even the FAANGs are as unsure of how to interview as my team had been! One of them had me go through 2 onsite interviews before rejecting me. A couple of times I got a very strong sense from the hiring manager that they were struggling to settle on a workable interview process, and they were sort of asking for my advice! Another put me through the expected brutal day long interview loop, during which I made one mistake; it wasn't serious enough to get me rejected immediately, so I had a follow up call with a manager. This I failed at because of a genuine work culture mismatch.

Luckily I landed somewhere wonderful soon after that.

Anyway, nobody knows how to do this well, but I was lucky to find companies with open minded cultures and interview processes.
posted by dbscissors at 10:38 PM on February 22 [1 favorite]


> However, no matter what I do, the interview scenario is unrealistic bullshit. It is not how we work.

Separate from our coding portion, we also take a real challenge/problem/bug from our day-to-day and ask the candidate what they think about it. We generalize a few details, but mostly not.

I like to hear what people think in those situations. Do they arrive at similar conclusions as we did? Do they understand the scope and scale of the issue? How well do they synthesize what we explained and how well can they engage in meaningful discussion about it?

It can be very illuminating.
posted by Godspeed.You!Black.Emperor.Penguin at 10:42 PM on February 22


The ugly secret though is that everyone on the team, including myself, suffered a bit of imposter syndrome: we needed help doing this really hard stuff, and we were muddling through it somehow, but we didn't really feel like we knew what we were doing and we hoped somebody from outside could show us The Right Way. Therefore we didn't really know how to even identify such a person.
There is an interview in the mid 90s where I'm pretty sure this is what happened. They asked a question, I gave them a long detailed answer, and they went "We don't need to hire him because he just told us everything we need to know."

I also interviewed with Sanford Wallace the SPAM KING which you can imagine how that went.

We tended to promote within so the one time I was involved was a dilemma. Fuck, if we promote them, they're a good one who doesn't piss me off when they wake me up in the middle of the night because they know what they're doing. That means I have more annoying people do deal with waking me up in the middle of the nignt who are idiots. We need people. This is exactly how I ended up in this position in the first place. In a month we'll shove them into on-call rotation and I get an *extra week* of not being on-call. Can not do anything but give the thumbs up. Hurts so good.

This thread continues to be sad/scary/informative/weird from someone who spent 17 years working at the same place (research university IT). It's an insight into a totally different world.
posted by zengargoyle at 12:34 AM on February 23 [1 favorite]


The duplicate is array.sum() - (n(n+1)/2). Whether it is a good solution depends on constraints no specified in the question. But it is simple and easy to explain.
posted by Nothing at 4:21 AM on February 23 [2 favorites]


The problem is not that simple: The duplicate number can appear more than twice and the other numbers each appear at most once, not exactly once.
posted by erdferkel at 7:14 AM on February 23


Perhaps. But given the problem as stated, that would be my first response. And I think it is appropriate with the information given. It solves the simplest form of the problem in a straightforward way. If by "assume there is only one duplicate" they do not mean one duplicate but instead one duplicated number, then I would say the specification needs some clarification, and work to understand the actual problem being solved. Which is exactly why these kinds of tests are not a good proxy for actual programming work. Most programming is understanding the problem, not solving it.
posted by Nothing at 2:14 PM on February 23 [1 favorite]


Most programming is understanding the problem, not solving it.

That's a good point. Plenty of developer time is wasted by insufficient clarification of user needs. Perhaps the true best answer to this question is, "I noticed there's some ambiguity here. Would you have a few minutes to help me clarify it?"

You're not going to get that in an online quiz, of course.
posted by clawsoon at 4:15 PM on February 23 [2 favorites]


I do really like giving a natural description that isn't a full specification and seeing what the candidate picks up to specify -- when it works. It can go poorly if they don't see the ambiguity and just proceed with one assumption, because then if you want to give them a chance to discuss and show understanding (which you do want), it becomes a fairly clear "hi, you missed this thing I was hoping you'd see", which isn't that big a deal to me the interviewer, but often is anxiety-producing to the candidate given the power disparity.

This works more smoothly in a question about designing a large thing ("how might you build a URL shortening service") than in a toy-scale question, because it's more apparent that the question can't be fully posed.

@Godspeed, I do some of that "talk about this problem of mine" (that I think we've solved so I hope I don't get a great answer that I can't ethically use), but I've become increasingly wary that it may be picking up more on familiarity with the problem domain than I'm able to correct for. It might be that you do better at filing off domain details than I can manage.
posted by away for regrooving at 8:28 PM on February 23


Why do people find coding so easy and natural, yet documenting so difficult and excruciating?

When I am coding, I get to take my context for granted and narrow my attention to what is supposed to happen inside this class or that function. When I am documenting, I must think in a completely different mode: how this function is relevant, which is to say, how it interacts with and is used by its context. The former, focused mode feels easier for me than the latter, more holistic mode.
posted by Jpfed at 9:07 PM on February 23 [1 favorite]


Why do people find coding so easy and natural, yet documenting so difficult and excruciating?

We had a dozen or so scripts for various bits of the things we needed to do to bits of hardware on various occasions. I wrote most of them and maintained the older ones.

I had this brainfart moment and realized that I could do everything with one single script. And I did. It was called 'grok' (natch). I could type 'grok blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah' and accomplish complex everything. It took me a hot minute to do things that took other co-workers using those other scripts half an hour or more.

It was impossible to expain without writing a hundred pages and having hours long training sessions to teach people the weird CS, Math, Logic, Grammar that they would need to understand to be able to do the 'blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah' part. So I just kept maintaining and writing those dozen or so piecemeal scripts.

Documentation is like that. By the time you've written it, it's so obvious that it's hard to explain. Or the options are combinatoric in a logical way but that means that there are 100 example usages. Documentation turns into textbook writing which is not necessarily something that the programmer is good at doing. You need somebody who can't program, but can understand and can write that textbook. They don't know how you do the voodoo but they understand what the voodoo does and they can explain how to use that voodoo to others. Asking the people who do voodoo to explain voodoo probably isn't going to work out as well.

Good developers spend half their time paring down that interface layer to a point where it's explainable. Actually writing documentation is hard when you already know exactly how everything works. And the more complex it gets the harder is is to make sure the documentation matches the code.

I do like the trend of languages including in-code documentation and access to comments as actual objects. It's nice to put a comment on a variable and have that comment magically appear in the -h/--help section. Or to have the program throw out the relevant section of documentation about why the thing you did was wrong. Much better than the old separate code/documentation model.
posted by zengargoyle at 12:02 AM on February 24 [2 favorites]


I'm about 6 months away from starting the application / interviewing process for my first dev job (as a queer dude at age 36 reskilling out of being a bartender yay) and I am...not looking forward to it. I'll have a masters degree in software dev from an ivy which I am hoping will counteract the ageism and whatnot that I will be up against, but I also will never work for a FAANG company (ethics) and I don't really know what to expect.

One thing I do know: there are companies that don't play this game and treat people like people. Unfortunately, I only know of exactly one: Basecamp. There's no way I am getting hired at Basecamp as a new grad. If anyone knows of other companies with the culture of Basecamp, please let me know.
posted by lazaruslong at 6:19 AM on February 24


lazaruslong, work at a university, get poached. Work at a university that is international and diverse. OMG a fun game was playing up evil cranky Boss^3 to new hires just waiting for the day he'd storm into a meeting cross-dressing in a nice dress, high-heels, makeup and hair coiffed. I have a bazillion stories about how I don't quite get this thread and the current hell that is the real world.

Makes me sound like an asshole but (dials it back a bit)... I worked with... hijab wearing women, Xena/StarTrek old dykes, nice guy who kept asking me to come see him DJ, navigating Ramadan and diets, black, white, young, old half the important people were women, the fun ones were old black women, ... NOBODY CARED if you were competent. Not the greatest pay, fighting people getting poached by startups of the big folks.

So... go work for a university that has to deal with student workers, diversity, etc. because they can't afford not to keep the talent they can get their hands on. Then get poached and move on if you like. I found the benefits and good feelings of helping learning to mitigate the desire to make tons of money. Many of my co-workers were about the same. Shop around.
posted by zengargoyle at 8:44 PM on February 24 [4 favorites]


At my current workplace we do, at my suggestion, code review in the interview. We've pulled few snippets from earlier code reviews, and then we tell the candidate "let's review this code together" and give them some time to prepare. There's a mix of stuff in there, like bad naming, duplicated code, manual solving of things that are available in the standard libraries etc. It seems to work well for our purposes, and lets us work together, at least for a little bit. The best one yet was the guy that found a mistake we hadn't caught ourselves! He was also a great co-worker and contributor while he worked here.
posted by Harald74 at 11:02 PM on February 24 [3 favorites]


funny zengargoyle, I currently work at a university. the only way i could overcome the 2 main barriers to top tier college education (access and cost) were to get a job here, parlay that into more-or-less free admission to the little sub-college for vets and "old" people (I don't have a BA), parlay that into a submatriculation into the master's program to circumvent typical application / vetting, and keep working full-time while doing both degrees full-time so that i can use the employee benefit to cover almost all of the cost.

my job here isn't coding though, so i don't know if I can get poached in quite the same way as you are describing. hope springs eternal.
posted by lazaruslong at 5:53 AM on February 25


This thread has all but destroyed my confidence that I'll be able to find a coding job someday working for other people.
posted by JHarris at 3:43 AM on February 26 [1 favorite]


Oh, my.

Here in Europe, mobile dev.

A lot of experience, touched all aspects of mobile (BT, wifi, using both cameras at the same time when this was thought impossible, watches, large Google Glass projects, design, UX, complete encryption, dealing with large corporations, complex math in personal projects, architecting for fun ... we're talking from PalmPilot to Windows Mobile to Android with some iOS thrown in [up to globally rolled out Apple Watch projects]).

The worst thing are the 'hey, do this code test for us' which turned out to be between 24-40 hour projects.

Then there are the interviews which terminate in 'hey, we really liked you, lets meet at a conference! Where can we meet you!?' but you don't get the job. And why? Because of 'you lack in-depth software engineering knowledge/leadership skills/coaching skills'.

Yet I give talks at conferences about deeply technical aspects where the feedback is amazing. And I've always been thrust into leadership positions throughout my life. And I LOVE helping people advance themselves and have numerous examples of doing that.

Previously finding a job has been easy. But this time around I have found it, for some reason, to be idiotically hard and unfair. I have found the feedback to be ... almost comically incorrect. Things I have demonstrable skill at/experience in have been used to deny me the job whilst being praised for my interpersonal skills.

And thinking back it has almost always been the case that those aspects which were criticised were aspects which had been majorly under highlighted during the interview process. One where my leadership ability and coaching skills were the reason not to hire me had just one question concerning the subject (whereas I had so much to talk about those subjects! So many examples to give!).
Another questioned my [specific skill] based on 7 year old code whilst I had demonstrable experience in the subject.
Then there was the one where the crusty old coder completely trashed my Conway GoL implementation. Because he wanted to see two complete NxN matrices and I, in the interest of scalability and memory efficiency used one completely grid (NxN) and a per-cell grid (3x3 around the cell).

Or the interview for a senior position where the feedback was 'he is too senior'. WTF?!?!?!?

I'm starting to come to the conclusion that:

a) HR/hiring managers have no clue as to what they should be looking for
b) most interview processes are looking for a perfect fit ... but don't know what that is and don't allow the candidate to know what is being looked for and thus the candidate can't tell them about times where they showed aptitude for that fit
c) 'give us 30 hrs of your unpaid time' should be fucking illegal
d) HR can/should be only the very first gateway keeper and then should GTFO
e) it turns out people are incapable of just asking about things they want to know about! Or asking further about the things they care about without telling/asking the candidate about the things they think are important

I'm very good at what I do. I have previous experience which proves that. Work experience which proves it. I have apps in Google Play which show that. I create complex programs (amongst which a game with a tiling system implementing a 4D Simplex Noise fractal map which seamlessly tiles, a completely unique realtime game and apps). I have demonstrable people skills. I have gotten Google to add API calls. I have more than 10 years experience in mobile (Watches, Glass, Android, even iOS [which I hate]). I have worked with global multinationals on projects which have been rolled out globally. I have leadership, training, coaching skills. I often do stuff which I then give presentations about cutting edge stuff which a year later are simplified by new API's. I am personable enough that the leads/programmers opposite me at interviews want to meet me outside of work/at conferences/at meetups.

And yet. It is as if the people doing the hiring are looking for the tiniest facet which they can use to reject me: 'oh, he's perfect except for [thing they should ask about but don't]'.

And all I want to do is work with people to create shit which people use.

So, anyone wanting to hire an experienced android programmer?
posted by MacD at 8:43 PM on February 26 [5 favorites]


« Older Seashells glued to Jesus   |   “She’d watch & watch & watch, but could... Newer »


This thread has been archived and is closed to new comments