How to land Software Engineer offers in 43 days while working on a full-time job
Around one year ago, I got offers as Software Engineer from Google, LinkedIn, Amazon, Uber… Most of the offers came with a promotion, and the base salary raise was as high as 40%. I ended up choosing Uber out of all those companies (not the one with the highest pay but I was deeply aligned with the potential of this company haha). As today marks the first work anniversary with Uber, and as friends around me are constantly requesting advices with interviews, I decided to reflect on the interview process a year ago and try to include the very essence that I found helpful during the preparation.
I value highly on both my career and the city I live in. I worked for Microsoft Office team and lived in Bellevue by the time I started my job hunting and both factors contributed equally to my job hunting decision. I would like to work on web related software engineering and live in a vibrant city full of young work-professionals who can both work hard and party. With none of preferences being fulfilled by my previous job and city, I decided to move on.
IMO, Silicon Valley style interview for Software Engineers is a separate evaluating system which is a lot different from evaluating one’s performance at work. Although many of the companies are trying to modify the interview process so that the signal emitted from the interviews would reflect the candidates’ capability of doing real work as much as possible, it is still far from perfect. At the very start of this preparation process, my goal is crystal clear: view the interview process as a standardized test and nail it.
Benefited/survived from the long exposure of China’s education system, preparing a standardized test, for me, has always been on the easier side of the spectrum: I need a high intensity timeline, and I will only spend time on things that are going to be impactful towards interview. There are countless posts online telling people to read textbooks from college all over again, and to me that is an overkill. You simply do not need to know the history of Knapsack in order nail the interview, all you need to do is being familiar with how to use Dynamic Programming to solve the problems. I am not saying there is necessarily a “shortcut” for interview preparation, but there should be at least this “clear path” that reasonable candidates should mutually agree on.
Finalized timeline: 1 day for updating my resume, 2 days for sending/referring/networking/ (any process helping with getting the interview), and 20 days for preparing before the first interview, and finally another 20 days for interviewing/continued preparation.
Above is the company list I compiled in Evernote. Since I value the city I live in so much, I categorized the companies into 3 clusters: NYC, LA, and SF bay area (I don’t appreciate the rest of bay area that much so those companies became second tier for me. I hate long commute.).
For each of the company listed above, I made sure to reach out to those companies from 3 different perspectives: online portal, friends’ referrals and recruiters that can be reached from LinkedIn. One small tip is that try prioritizing friends’ referral over online portal, since for some companies, referrals become unavailable once you have submitted online application.
I did all of the above processes for all of the above companies during a weekend, and by EOD next Monday I had over 10 interviews scheduled.
Algorithm & Data Structure
Candidates are usually scared of algorithm & data structure interview, but I personally think it is actually one of the easier topics once you have the systematic approach. I focused on two perspectives during preparation: problem solving, and explaining the problem solving.
I used an online coding platform called Leetcode.com for preparing my problem solving, and I’m happy with the result. Preparing Software Engineer interviews by practicing on Leetcode.com is nothing new, but I think I differentiated on my “less is more” approach: I only focused on the first 150 problems, unsorted. There are quite a few people online saying that you should sort by difficulty and start with the easier ones, and to me that’s nonsense: you are not preparing for entertaining yourself or boosting your confidence, and you should try reflecting on the real interview scenario as objectively as possible.
The first 150 problems are awesome. They pretty much cover all of the required topics in a Software Engineer interview: from common topics like String, Array, Binary Tree, Dynamic Programming, Bit Manipulation, to not that common topics like Segment Tree, Trie, Topological Sort.
Time each programming attempt. Having a strict timing is critically important for getting into interview rhythm. I allocated 30 minutes for each problem for my first iteration of the 150. During my first iteration of the problems I really tried hard to solve every single one of them. If I did not solve one problem in 30 minutes, I will not call a hard stop until I could not figure it out after another 30 minutes. For my second iteration, however, I put the time constraint to be 15 minutes each problem, having the assumption that I have the approaches already consolidated in my memory.
Explaining the problem solving plays another big part. I used to think that it will naturally become my shortcoming because English is not my first language. However, being fluent in English is not the determining factor for a tech interview. It is true that it is all about “talk the right language”, but “the right language” is actually an aggregation of the right terminologies which happens to be wrapped by English language context. So having the right terminologies and the right process of conveying the idea are the most import aspects to strive for.
Geeksforgeeks.com is the by far the website that I benefited the most for preparing for explaining my thought process. It is a tech blog briefing about each class algorithm and classic example problems. Tech blog fits the tempo of an interview perfectly: both of them are trying to convey a crystal clear idea in a time-efficient and concise manner. For every single programming problem within the 150, I made sure to reflect on what algorithm is behind the problem. Then I will thoroughly read the Geeksforgeeks.com article about the algorithm, as well as the example problems and their solutions.
In the process of reading Geeksforgeeks, I realized that how much I have been lacking in the tech interview process as a new grad. Getting solutions fast for every problem makes the candidate look smart, but “talk the language”/explaining the problem solving in the right way makes interviewers want to work with the candidate. Usually the latter plays an even more important role, and that was what happened to me for one round of Google interviews, in which I did not get the correct answer fully but my communication won over positive feedback.
System Design weighs way more for industry hires than for NCG. Without the experience on designing web system on a large scale during my previous job, I felt clueless.
Luckily the System Design courses in hiredintech.com helped me in the biggest way. It covered basic concepts, elaborated on the key bottlenecks in a web system, and most importantly: how to quantify a lot parts of your design so that it will appears that you are speaking from years of experience.
Practicing System Design can be hard since it is by nature an open-ended question and hard to find a universal/standardized process for problem solving. So what we should do when one universal approach cannot be found? We categorize system design problems and then we divide and conquer.
The categorizing process is pretty straightforward. I categorized by the bottleneck that some popular products have faced, and summarized examples on how those products overcome those bottlenecks. Below is part of the web app list that I dug deeply into.
As you can see, a lot of the articles from above are from highscalability.com. Dig deep into that website.
Looking back, those were 43 though days. I prepared for at around 5 hours on a weekday and approximately 15 hours on a weekend day. I divided all companies into two batches: the first batch being Google, Amazon, LinkedIn, Uber etc., and the second batch being Facebook, Bloomberg, Airbnb, Spotify, etc. I decided to only go ahead with scheduling the first batch to begin with. The idea is that if my preparation totally did not work out, I will still have time to adjust my strategy and shoot for the second batch, which is an equally good set of companies IMO.
Luckily all the strategies and effort paid off. 30 days in preparation I already felt like I am getting the gist of Silicon Valley style interview. More importantly, I felt that I already have a deep enough understanding of the interview system to objectively assess my interview performance. My expectation set after the interview has always been consistent with the outcome, which was indeed a good feeling.
In the end, being a good interviewee does not guarantee a top performance when facing real-world projects. It is lucky that we have a systematic way to game this evolving interview system, but it also needs to be clear to each candidate that long-term knowledge accumulation and passion for the entire industry would go a long way. I’m still on my way to become a good Software Engineer, and this part will take some real effort.
I hope this article helps. Feel free to discuss, critique, and share.
(As of end of year 2019 to early 2020) Our team is actively looking for Software / System Engineers. If you think you are ready, please feel free to reach out to me on LinkedIn and let’s start from there.