Draft: true Don't judge
We (tech workers) are all very lucky. There is an abundance of “rocket science” jobs available at incredible companies which have their shit together to an astounding degree. 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. This makes getting an interview easy even if you are not even living in a tech hub. It seems to me that remote hiring was already beginning before COVID-19, and it was in fact a reaction 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 had to be strong in a multitude of skills, and someone in the intersection of all sets is exceedingly rare.
I sometimes joke that the biggest computing constraint is finding enough humans to operate the computers. This makes them highly sought after, so wealthy companies aggressively compete for each individual.
How do you even know if an individual is
qualified talented? The last thing a company wants to do is hire a “B player”. An extremely damaging scenario for a company is hiring someone who is less than ideal, who can then breed a culture of mediocrity. Firing someone is difficult for both parties.
To do this in a manner that scales well you must have an exceedingly difficult 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 community (their organization’s success) and this can have lasting organizational damage (For example, increasing direct report headcount for the sole purpose of increasing influence rather than shipping code).
The interviews are hard. You (often) get asked a multi-part algorithmic question that you’re expected to solve at breakneck speeds, optimally, without mistakes for the first screen. 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, where you are grilled by 5-10 engineers who give you more algorithm puzzles & 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, but remember that most tech workers will parallelize interviews with multiple companies (ideally 3-6). This is because, well, they’re smart & can be aggressive min-maxers. 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 on the same week. This is because offers only stand for a week 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.
My perscription: 3-4 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 55 minutes in front of a stranger for a company that you are really interested in joining. Yes, I got the question. Yes, I wouldn’t have gotten it if I hadn’t studied for 3-4 hours every day after work.
The system design section of the interview process is actually quite fair. 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 endurance to come through a difficult obstacle. And maybe it makes sense that the interviews are designed similarly.
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.
While reading this, note that all these jobs were remote positions.
This is the job I ended up taking.
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. For square, I wouldn’t have gotten the offer if I didn’t grind HARD every day for a long time. Square’s new hires would then more likely to be younger/childless individuals who can sacrifice a large portion of their time, while Stripe can get a more diverse selection of hires (Diverse in the dimensions of age & marital status).
I’m super excited to work at Stripe (It’s my dream job!) and I will be writing more about it soon.
Thanks for reading,