Why it’s easy to get an interview

We (tech workers) are all very lucky. There is an abundance great jobs available at incredible companies. These places aren’t only great to work at, but are also quite lucrative to work for. The availability of these jobs is a result of a severe shortage of qualified individuals which these companies are trying to collect. With the surge in remote hiring, you don’t even have to live in a tech hub to score one of these jobs. It seems to me that remote hiring was already beginning before COVID-19, as companies reacted to exhausting the supply of talented engineers living in tech hubs. COVID-19 was simply a catalyst to an already existing phenomenon. Anecdotally, I started working remotely for a company that did quite well at obtaining talented individuals without having to compete with Big Name Companies, before the 2019 pandemic.

From my experience, the biggest challenge tech companies face today is acquiring & retaining talented individuals. These individuals exhibit strength in a multitude of skills.Coming across someone in the intersection of all skill sets is exceedingly rare.

I sometimes joke that humanity’s biggest computing constraint is finding enough humans to configure the computers.

Why the interviews are so hard (For everyone)

How do you even know if an individual is qualified talented? The last thing a company wants to do is hire a “B player”. Hiring someone who is less than ideal damages the group, as they can breed a culture of mediocrity. Firing someone is difficult for both parties, so its best to avoid that. This means that false positives are much more harmful than false negatives.

You get around this with designing a difficult (but not unfair) interview process. While this will produce many false negatives, you will guarantee that you do not have any false positives. In a scenario where the risk outweighs the reward, you want to minimize the risk as much as possible. Furthermore, because the need for people is so high & the job can be so lucrative, the ingress of job applications is almost unmanagable. You need a quick way to filter out a large portion of them without sacrificing 8 engineering hours interviewing a bad fit.

What’s even worse is that people lie on their resumes. If you look at it through the lense of game theory, the risk of lying on your resume (none) vs the reward (great job) will incentivize people to do so. I’ve had someone send me their resume for a referall in the past, and I noticed misrepresentation of their titles from when I worked with them. You do not want dishonest people in your organization, as these people optimize for themselves rather than their peers. This can leave lasting organizational damage (For example, increasing direct report headcount for the sole purpose of increasing influence rather than producing value).

How they are so hard

The interviews are hard. For your first screen, you (often) get asked a multi-part algorithmic question that you’re expected to solve at breakneck speeds, optimally, without mistakes. Many people just give up upon learning how difficult the interviews are. They are so difficult that it discourages many from even trying.

The interviews are often 2-3 distinct parts, the first 1 or 2 parts being a screen where you have to solve a programming puzzle. The last part is an interview that lasts the whole day. You get grilled by 5-10 engineers who give you more algorithm puzzles and ask you system design questions that you’d only really be able to answer if you were a huge nerd about large distributed software systems. This needs to all be managed while you anxiety levels are through the roof.

The time itself required for one set of interviews may seem unmanagable. In spite of this, most tech workers will parallelize interviews with multiple companies (ideally 3-6). The best way to maximize your gain from the large risk of switching jobs is by having a BATNA (Best Alternative To a Negotiated Agreement). To add even more difficulty to this, all of the final day long interviews need to be scheduled around the same time. This is because offers only stand for a limited time before they expire, which seems to be standard practice by Big Name companies these days. A negotiation tactic? Maybe.

The engineers who actually manage to get these interviews will have been already working for a Big Name company, and can have a lot of responsibilities at their deamnding day job. So they have to save up their PTO to take time off, or make up for work lost at night after they have an interview. I personally had to hand off a few on-call days, which I do not like doing as my team members have children. Ideally you are keeping up with your responsibilities, because well, no one wants to leave their team-members hanging. But also, it’s smart to not do this, as you might not get the job offers and have to continue your job.

The grind

My perscription: ~3 hours a day of leetcode every weekday, and 4-6 hours a day of sys design & leetcode on the weekends, over 1.5 months. You might ask, isn’t that overkill?

No, it’s not. Especially when you get blindsided by a leetcode hard and must solve it in 50 minutes in front of a stranger for one of your dream companies. Yes, I got the question. Yes, I wouldn’t have gotten it if I hadn’t studied for 3 hours (sometimes more) every day after work.

The system design section of the interview process is less painful. It’s the closest to what I would do on the job, and that made it easy to prep for. Well, I would prep for it by actually doing my job. However, chances are you have never sharded a database (because how many people were on the team that updated the database infra for shopify in 2015?). Since you have to be able to describe how sharding a database works, studying is definitely required. This part of studying was quite fun, I really learned a lot of cool things.

There were a few interviews that were much more pleasant than others. These were ones that were totally fair, and I feel like I passed because I was genuinely interested in software engineering. They had me code things up that I could see myself doing on my free time (although I still had to do it extremely quickly with 0 mistakes, it was by no means easy).

Going through the prep process, it became apparent to me that the challenge wasn’t the actual interview. The challenge was finding discipline and time to sit my ass down and grind through problems. The test was the endurance required to make it through interview prep. Is it intended to be like this? Maybe. I think that companies just found that this general process was the best way to find the best candidates with the least false positives.

The real test is the prep. The interview is just to check if you were able to do it. Software engineering isn’t an excercise of pure intelligence, but rather summoning endurance to overcome difficult obstacles. And maybe it makes sense that the interviews test for the same things.

So if you’re preparing for interviews or thinking about interviewing soon, my advice is to trust the process. Anyone with a CS degree can write a disjoint set algorithm, provided that they spend enough time trying to write it from scratch.

My interviews & my experience

While reading this, note that all these jobs were remote positions.

Square

• Their screen was way too hard. If I hadn’t done all my prep, I would have never gotten it under that much pressure. It was really hard (leetcode hard). If all their screens are this hard, it’s incredible they have people at all.
• They had a pretty heavy final day interview. I think I met about 10 people that day.
• The final day programming questions were actually super fair. It was code I could see myself writing for my hobbies.
• Their system design was really fun, I learned a lot
• Everyone was really friendly.
• Got a senior offer, didn’t accept

Coinbase

• Their screen was pretty easy, and I had actually seen it before.
• They didn’t want to level me as senior, and their intermediate comp wasn’t competitive enough, so didn’t go through with it.
• They don’t have comp ranges, instead each level has a precanned comp. The difference between senior & mid was ridiculously large, which is probably an artifact of precanned comps.

Plaid

• Their screen was fair, it would be code that you would write on the job
• I unfortunately shit the bed and got a reject ;_; anxiety and bad luck lead to a choke

Stripe

This is the job I ended up taking.

• Interview process was difficult
• Interview process was also fair
• Would have been likely to get through it with only system design prep, no leetcode/algorithm prep required
• Tests you more on if you actually code for a hobby & solve your problems at your day job
• After getting a description of the interview, felt like my day job was actually the prep for the interview
• Everyone was very friendly
• Got the job!

It was really nice to see a job interview which both was difficult, yet did not need a large amount of preparation. I think this is important to get right, as this would be more inclusive of engineers who are parents & have obligations outside of work. In comparasion, Square’s new hires would then more likely to be younger/childless individuals who can sacrifice a large portion of their time.

I’m super excited to work at Stripe (It’s my dream job!) and I will be writing more about it soon.