Don't Trust the Process

Prelude

The first thing I did, after signing the offer letter, was to uninstall the Blind app from my phone. My brain needed a long break from that one. The anonymous commentary from tech employees is valuable, but I don't love the picture it paints of us. Next, I cancelled all the five-hour-long "virtual onsite" interviews I had scheduled for early January and closed my in-progress homework assignments. The feeling of liberation from this was palpable. I had finally landed a new job, one that I was very excited about. More on that later. For now, let's delve into the months of misery leading up to it.

As is tradition in my field, allow me to lay out a statement of scope.

Not in Scope

• A solution to these problems. If you're someone who thinks that nobody can present complaints without bundling them with a neatly packaged solution, you should probably turn back now.
• Any treatment of those coming from less advantageous backgrounds. We have ample data that shows some people face higher barriers to being hired in general . I don't know what it's like to navigate this field as a woman or person of color, but I can only surmise that they face all of the problems I will enumerate, but "at scale".
• The H1B problem. This adds an additional dimension of exploitation on top of everything outlined below, but I'm not really in a position to address it.
• The mental health angle. Rejection always hurts. But when you're someone who has always been a strong performer, repeated rejections can really start to make you question things. It was hard for me to suppress the imposter syndrome that kept rearing its head throughout it all. I'll omit any further discussion of my own personal struggle with mental health.
• Originality. You're only getting my personal telling of something that many, many people have called out and decried over the years.

In Scope:

• Lots of ranting. Mostly visceral, occasionally eloquent, hopefully with a dash of humor.

Also, please take note of the following:

• This will be the ultimate embodiment of a first world problem. Despite my "ordeal", I'm still in an extremely privileged position compared to most workers in the United States, to say nothing of the world at large. I haven't lost sight of that.
• The names of all companies, as they relate to my own personal experiences, have been changed. Although some richly deserve the admonishment, that really isn't the point here.

My Journey

Sometime in 2020, I started the process of looking for a new job. I was feeling stagnant and unexcited in future prospects in my current role, and decided to look for new challenges elsewhere. In my line of work, this is commonplace. I expected to find something awesome within several weeks, or a couple months at the longest. My naivete, in hindsight, was staggering.

I didn't anticipate the difficulty I would have in finding a new role. I assumed that if there was mutual interest, I'd be able to pass their hurdles with ease, since I've always been praised for my work and know how to write code. But things didn't quite happen the way I had hoped.

When asked, tech companies will tell you that they have a really hard time finding good senior engineers. That they're always desperate to fill these positions. Assuming that's true*, maybe they should try to develop a hiring process that isn't utter dogshit.

The Process

Assuming you're lucky enough to even garner a response to your job application (which, for about half of mine, wasn't the case), or if someone refers you, then the recruiter or hiring manager will walk you through The Process. For most companies, The Process for hiring software engineers is roughly the same. Oddly, the recruiter often seems to use a tone that conveys "isn't this unique?" (no).

1. The Phone Screen
2. The Coding Round(s)
3. The Behavioral Round(s)
4. The System Design Round
5. The Homework (sometimes)

Let's explore these steps, one by one.

The Phone Screen

This is the hour the company spends talking to you to make sure that it won't be a complete waste of time. Sometimes, you are asked to write code during this round, and sometimes not. In any case, if you make it past the phone screen, you will usually advance to the onsite (i.e. "final") interview rounds. Or, as they were called during the pandemic, "virtual onsites".

I was declined after the phone screen for Company A. This was one of the FAANG companies, one that you have definitely heard of and whose products you almost certainly use. Even though I implemented both of the solutions within the tight 40 minute window, getting to optimality required just a bit too much nudging by the interviewer for their taste. And that just won't do for Company A. Now, in fairness, I knew going in that perfection was essentially required in order to advance, so the rejection email came as no surprise.

The Coding Round(s)

This is usually the first (and sometimes second and third) step in the onsite interview. After a brief introductory chat, you're given some problems to solve (usually with an online coding tool that can actually run the code, although not always).

When interviewing with Company B, I lost points in the Coding Round because I struggled with the replacement problem a bit more than they liked. You see, when we first got in the room, the interviewer started walking me through the exact same problem that I had already solved perfectly during The Phone Screen with one of their colleagues. I stopped him and pointed this fact out, even though doing so cost me five precious minutes (while he dug up a different problem). I still thought my honesty would garner some kind of karma points; again with the naivete.

"Leetcode Bullshit"

Sometimes, the Coding Rounds are fairly simple, and sometimes they're more challenging. If you've done your research, hopefully you won't be caught off guard when entering the dreaded and infamous Leetcode round.

Depending on the company in question, you're asked to solve one or two "easy" or "medium" problems. (The really elite companies might sometimes ask a "hard" one, so you're better off practicing a few dozen of those as well.)

The thing about Leetcode Bullshit is that most of these problems actually have two very different components.

1. Discovering the pattern/clever math/trick (henceforth referred to as "the trick" for brevity)
2. Implementing a correct and efficient solution given that realization ("the implementation")

Consider an example to make this more concrete: Number of Islands. There is a very efficient, concise solution, which you can read here. As noted in the discussion thread, the key realization is that an "island" can be explored by a tree search of the grid (either breadth or depth first, it doesn't really matter for this problem), starting from any spot of land. The "trick" also requires you to zero out (i.e. turn into water) those island spaces as you search, so you don't run across them again later. Doing this negates the need to allocate additional memory, beyond the amount already used for input. Once you "sink" an entire island/tree, you increment your island counter and keep going.

The implementation is relatively straightforward once you "get" the trick. However, unless you can do both of these parts very well, you're screwed in the interview. Now, the thing is, the implementation is what you are actually doing on the job most days. But to get good at the trick requires either an innate gift, or weeks to months of practice on Leetcode or similar sites. Eventually, you can start to recognize the patterns and apply them to problems that are presented during interviews.

Hell, if you've practiced enough of these, you might even be asked the exact same problem you've already seen. That actually happened to me (with Number of Islands) during an interview round with Company C. I couldn't believe my luck. I paused to think a bit, then confidently presented the solution with time to spare. I was still rejected, mind you, because I didn't do a good job of designing S3 (more on that below) in ~15 minutes. Apropos nothing, but Company C apparently thinks it prudent to smash together The System Design Round with The Coding Round(s), and even some Behavioral Round(s) into one single, hour-long call.

The Behavioral Round(s)

The idea here is to assess a candidate's "soft skills". Nobody wants to hire an asshole, because working with one sucks. And outside of a few very specific situations, they also don't want somebody who's going to do the bare minimum and never take any initiative, jump in to help on shared problems, or try to improve the practice of building the products. There generally aren't too many surprises here, as long as you come across as humble, yet competent, and have some crisp answers ready.

The System Design Round

The prompt here might be "Design S3". For those unaware, S3 is one of the earliest services offered by Amazon on its AWS platform. It provides an extremely simple and relatively cost effective way to store data in "the cloud", and makes that data generally available anywhere in the world, with high durability and availability. By now, it underpins so much software infrastructure and platforms of many companies that it would be hard to imagine the modern internet functioning without it. Scratch that; no imagination required.

In the System Design Round you're tasked with nothing more than designing a complete system, such as S3, from scratch on a whiteboard. Besides being completely audacious, this round is by far the most subjective and the hardest to prepare for. In fairness, they will say that there is no "right answer", that the interviewer is looking more for how you approach the problem, seeing whether you can ask the right kinds of questions, unearth the myriad hidden assumptions and complexities, etc. As reasonable as that sounds, there is still a large amount of luck required.

It was ultimately the System Design Round that cost me an offer for Company B. The recruiter was surprisingly forthcoming about that, which I appreciated. It turned out that even though I spoke confidently and provided great detail about the various components of my solution, including a discussion of tradeoffs and alternatives, I had failed to connect everything back to the initial prompt offered by the interviewer. The recruiter invited me to try again in 10 months (their minimum amount of time that must pass before a rejected candidate can run the gauntlet again).

For liability reasons, companies typically refuse to disclose any details or provide anything approaching constructive feedback, leaving aspiring candidates to trawl through the bevy of content coming out of the cottage industry of Technical Interview Prep. If I had a strong desire to go through this process again, I would probably pay for a few coaching sessions through one of the companies that hires real engineers from FAANG companies to help candidates refine their approach to The System Design Round through mock interviews.

The Homework

Sometimes, as part of The Process, you are asked to do some work and send it back. There's usually a problem statement of some kind, and you are given leeway to implement a solution as you see fit. This means you can use your own tools, do research, Google things, etc.

Personally, I prefer this approach to timed coding exercises. In general, it's a much closer approximation of the work that one actually does. And on a personal level, it jibes better with the way my mind works. I tend to be slow to start on a problem, but once I have some time to wrap my head around it, I can really crank.

Now, there is one common objection to this practice. Some people argue that companies are benefitting from the unpaid labor of candidates (who are themselves sometimes in a desperate position). With a few exceptions**, I seriously doubt companies are really getting any value out of the work a candidate produces in this context, close as it may be to their particular problem domain.

Still, The Homework can be frustrating. I was rejected for a position with Company X: a tiny, stealth startup that my former boss joined. Since he vouched for my abilities and track record, I thought I would have a shot, even though I knew it was still a stretch. The work I submitted to them for the "easy round" (one of two) was "good, but didn't blow them away". Once I calmed down about it, I got very curious about what "mindblowing" code for that problem would have even looked like.

The Upshot

Seriously, what the hell are we doing here?

When forced to defend the practice of asking Leetcode style questions to candidates, the Facebooks and Googles of the world will respond by saying, "No, really, we have problems at such a huge scale that this stuff really matters!" I will grant this premise without hesitation. And yet, I find it extremely unlikely that even Facebook or Google needs their engineers to quickly invent complicated, bespoke algorithms and distributed systems at the drop of a hat on a daily basis. It's far more likely that the majority of developers at these companies are being paid lots of money to solve the same kinds of banal, everyday problems that beleaguer most "regular" companies who build software***. But Facebook isn't optimizing for that in their hiring. Instead, they're optimizing for people who can learn a set of patterns and quickly apply them under time pressure.

When those Really Big Problems do arise, they are solved methodically and thoughtfully by teams of brilliant people on a time scale that goes well beyond a 40 minute whiteboard session. Google's original problem of crawling the entire web and ranking the relevance of all webpages clearly falls into this category. When they managed to crack it, their approach became the basis of a piece of software upon which several other companies were built. And when you read the famous DynamoDB white paper from Amazon, it's abundantly clear that the people who designed it did so very deliberately and thoughtfully. They meticulously synthesized academic theory (some of which dates back to the 1970s and earlier) with hard learned lessons from industry into something that solved their particular problem very well, even at a massive scale. Let's not mince words here: DynamoDB is a triumph of engineering and a thing of beauty. But were those individuals' intuitions correct in the first twenty minutes they spent pondering the problem of the Amazon Shopping Cart? If not, they might well be turned down for the next round of interviews at AWS today.

I firmly believe that The Process is, in essence, a self reinforcing loop. "Since Facebook only hires the best, we should do what they do if we want to be as successful as they are." There are so many things wrong with this mentality that it's almost absurd on its face. If we strip away all the bullshit, perhaps the only remaining thing is the drive for prestige. One can reasonably conclude that The Process exists primarily to satisfy the ego of the current employees, executives, and board members.

Epilogue

As I alluded to at the beginning, I did end up landing a really great new job. It's actually one that, given perfect information from the beginning, I would likely have pursued as my first choice. Their product is wonderful and already well loved by tons of people despite zero marketing. The technology is extremely interesting and cool, but still largely falls within my wheelhouse of experience. I feel good about their business model (which is certainly not something one can say about every tech company). And everyone I talked to from the other developers to the CEO was delightful, intelligent, and pleasant. If I hadn't been rejected by some other company earlier on, I might not have had the opportunity to accept it.

Now, some might argue that this undercuts my entire thesis. That, somehow, things worked out for the best because this crazy system I'm denigrating actually works. But let me assure you this happy outcome is not the result of some well oiled machine. When I originally saw the job posting, I became interested. I submitted my application, but heard nothing back for weeks. If the story had ended there, it would have been completely normal and boring because that sort of thing happens all the time. It was only by a confluence of outrageously unlikely events**** that I got my foot in the door for the initial interview.

I recently got an email from a recruiter from Company A. He was just reaching out to see if I was "interested in revisiting software engineering opportunities" at the company. Apparently, their minimum amount of time is only 3 months! It's very common, their recruiters will explain, for a candidate to interview multiple times before finally getting an offer. They strongly encourage candidates to keep trying and not be dissuaded by any particular rejection. That, to me, is a tacit admission that they know full well how bad The Process truly is.

* An alternate interpretation is they aren't offering high enough compensation for these positions

** Years ago, I fixed a real (but tiny) bug in the Wikimedia software that powers Wikipedia, as part of a job interview with them. I hope you will join me in granting them a special dispensation.

*** This includes, but is not limited to: finding the best way to connect two different systems together, debugging production issues, investigating performance problems, helping unblock proof of concept implementations, refactoring configuration files, upgrading library versions, ensuring releases go smoothly, etc.

**** It hinged on one employee of this tiny startup also being on the same language specific, CHICAGO SPECIFIC Slack channel at the same time, posting about working there, at roughly the same time I was online and checking Slack, having me rant about not hearing anything back, and reaching out to the VP of Eng on my behalf. I haven't run the numbers, but I'm inclined to think this was extremely serendipitous.