The dystopian world of software engineering interviews

At my last job, I was trying to hire a frontend engineer. More programmery than designery, so I would kind of expect the ideal candidate to have heard of Typescript, and to have maybe written a unit test before. Our recruiter put a job listing on the usual places with those exact criteria, and ... we got hundreds of resumes by the time I took a look at the queue a few days later. I reviewed them all! 90% of the applicants had gone to a bootcamp and had nearly identical resumes. They wrote down their camp projects as though they were work experience. They linked to their Github that had line-for-line identical code between applicants that went to the same boot camp. Some were just directly the output of create-react-app with no additional code added. The common theme was, "I hear you get paid a lot to be a programmer. Count me in!" The other 10% of applicants didn't really have anything negative going on. They have some claimed programming experience, and they want to get paid to write computer programs. Why not call them up and ask them to find the k-th element of a binary tree? It's not a super-obscure area of study.

When I was at... erm... "Giant Search and Advertising Company"..., I did in-person interviews. I went through a lot of the shared interview questions to use, but ultimately came up with my own: given a stream of events from a variety of event sources, count how many unique event sources emitted an event in the last 5 minutes and last 30 minutes. I chose this because I literally wrote this exact program, and it took me a few iterations to get it to be optimal. (Or what I think is optimal!) For that reason, I found it to be a pretty fair question. The answer is just a few lines of code. The problem is a real-world problem. It's not a puzzle, but it does involve some thinking and maybe asking some questions.

The last thing I'll say, which I know is kind of snarky... As a Senior Software Engineer at Google, your total compensation is going to be north of $300,000 a year. You should be able to find the k-th element of a binary tree. Teach yourself how; it's kind of fun, and might someday be useful.

I agree with the HN consensus that hard CS comes up somewhat rarely in the day-to-day life of a programmer. But when it does come up, you really do need to know it. You will never be finding the k-th element of a binary tree. But there will be tree structures, and you will come up with some brute-force algorithm because you haven't seen that class of problems before, and you will push your "uses too much memory and time on production-sized datasets" hack to production, and production will crash, and then you find yourself with a production outage you don't have the tools to fix. You aren't getting paid $300,000 a year for that. So that's probably why they ask you CS-y questions.

I got this exact question on a phone screen with "Giant Search and Advertising Company." I got stuck on a stupid detail and botched the implementation. Once I hung up the phone I took a deep breath and fixed the algorithm in about 15 minutes. That still isn't very good since I was only given 15 minutes total at the end of the interview to implement it in the first place so I assume that is the time-span they expect to get an answer from a senior engineer.

Fair enough, I didn't study for the interview, I don't have a lot of binary tree experience. I realized that if I couldn't get through that phone screen cleanly/easily then I probably wouldn't make it passed 4 or 5 whiteboard problems either (which are likely to be significantly more difficult). Fair play to any company that wants to screen candidates using that approach because I am not the kind of guy they are looking for and that is just fine. Everyone I spoke to was polite, professional and sounded competent. I do wish they would stop calling me and letting me know that I did well enough to be eligible to retry.

I have no doubt that I would contribute at an above-average level within any of those FAANG orgs but I appreciate their process and the reasons behind it. I have had no problem finding high-paying employment and distinguishing myself within any team I have worked on for my entire career. I generally get promoted quickly and asked to lead teams. As far as I can tell there is no dystopia, just people looking for different things.

I think most things you can write in less than 30 lines of code or so could be reasonably written inside of 45 minutes. Like this Lisp interpreter in JS http://canonical.org/~kragen/sw/dev3/terp.js or this octal-to-binary converter in assembly http://canonical.org/~kragen/sw/dev3/osmb.s or this Collatz-sequence searching program http://canonical.org/~kragen/sw/dev3/collatzsearch.py or this paren-matcher in Scheme http://canonical.org/~kragen/sw/dev3/pmatch.scm or this paint program in C https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/%CE%BC... or this Unicode Wang tile ASCII-art maze generator http://canonical.org/~kragen/sw/dev3/uniwang.py or numerous other things like that.

There are some things that are really tricky and so they take longer than that to write even when they're less code, but the examples above are not among them. Also, it's pretty often that I've written longer programs than 30 lines inside of 45 minutes.

I know there are people who can do things like that but can't do them in an interview because they freak out, and there are people who can program somewhat but can't do things like that, and they might be better at other things than I am. You aren't going to find out how well someone's high-level architectural abilities can help you steer clear of unnecessary implementation problems in a 45-minute interview, unless they're the same as your own high-level architectural abilities, in which case you can recognize them.

But you can find out if they can write code that works, at least sometimes, because that's a thing that you can actually do in that timespan.