In this article, I'll discuss some pro tips that'll help you ace your interviews at your dream companies and get the most out of your job offers.
Introduction — From Wall Street to the Googleplex
On March 31, 2019, I was downsized by a startup hedge fund. Having been a quantitative software developer in the finance industry for the last 10+ years, I didn’t want another job doing more of the same. I set out to follow my passion and find my next job in Artificial Intelligence, Machine Learning, and Deep Learning.
Over the next 6 months, I worked very hard towards that goal. By September 2019, I had multiple Machine Learning related on-site interviews and offers, including offers from both Google and Facebook.
Here is how I did it. Hopefully it will encourage and help other potential career switchers to make this transition. Your reward for switching could be two fold, both intellectually and financially.
Article Summary
If you are short on time, here is the quick 5 step recipe that worked for me.
- Curate: Work on a project that you are passionate about and showcase it online
- Study: Practice Algorithms and Data Structures coding and System Design problems intensively
- Apply: Leverage multiple channels to land interviews
- Interview: Keep your cool during Phone and On-site Interviews
- Negotiate: Know what you want as you negotiate offers and match with teams
As you can see, this is a simple 5-step recipe. However, completing each step takes a lot of hard work. Read on for details.
About Me
Here is a little about me, because I think this guide would be most helpful for someone with a similar background as myself.
Namely, I'm an experienced software engineer/developer in a non-tech industry who wished to switch to a top tech company on the west coast (San Francisco Bay Area or Seattle).
If you have no software engineering work experience, the recipe above should still work for you. You just have to work a lot harder than someone with the coding experience.
I graduated from the University of Waterloo in Canada as a computer engineer. In my earlier career, I worked as a software engineer for Microsoft and Oracle. Then I switched into the Quantitative Finance industry after my MBA.
For the past 10+ years, I worked as a quantitative developer/analyst for Bank of America, UBS, Citadel, and a few smaller firms. But since 2016, when I first stumbled upon Machine Learning (ML) and deep learning, I fell in love with it. I knew I wanted a job in the AI/ML field eventually.
In April 2019, I started my full-time preparation for this career switch. And I will be moving to the Bay Area next week to join Google, one of the leaders in AI and ML.
5 Simple Steps to Success
Step #1: Curate - Work on a Cool Project and Showcase it
In February 2019, my good friend, Igor, encouraged me to create a cool project and write about it. At the time, I didn’t have any good ideas. I had never published anything online and didn’t know where to begin.
But in early April, while I was vacationing with my family in Mexico, one night I suddenly had a revelation that I wanted to build a self-driving car. Given that I had no prior experience with robotics or electronics, I set out to build a Deep Learning/Self-Driving Robotic Car, DeepPiCar, that could run in my living room.
One month later, after I successfully built the self-driving car, I started to write a 6-part blog post on Towards Data Science to teach others how to build one.
Within weeks, my blogs received over 10,000 views, and the reaction from readers worldwide was overwhelming. I felt my 2 months hard work — one month to build the car, and another month to write the blogs — was well worth it.
However, I did not realize its full impact on my professional career until my interviews and offer team-matching calls, when interviewers asked me “Why are you looking to switch from your current industry?” I was ready with talking points!
Not only was I able to tell them how passionate I feel about AI/ML, but when I pulled out my car (yes, the actual robotics car) from my backpack and put it in the hands of the interviewers, I could see the excitement from their eyes! Many of them even said they would love to build such a car with their kids.
I then told them that I had published the full step-by-step instructions with source code online (with links in my resume) for them to follow. I was pretty sure they wouldn't file my resume in the recycle bins afterward. ;-)
Some of my friends ask me to recommend good projects to work on. Here are some of my suggestions:
- If you want to transition into front-end development, create a cool website with a lot of interactivity with popular open-source frameworks, such as React and Angular.
- If you are interested in server-side development, try to create a web crawler or search engine using distributed server technology such as Cassandra, ZooKeeper, Memcached, and Elastic Search, etc
- If you are into mobile devices, try to create and publish an Apple/Android app. Note that publishing an app on Apple’s App Store takes much longer than Google’s Play Store.
- If you are interested in AI/ML, take one of the existing Computer Vision or Natural Language Processing deep learning models, and try to make a product out of it. For example, I took a pre-trained object detection model, SSD, and adapted it to be a traffic sign detector for my DeepPiCar. If you are new to AI/ML, be sure to read Part 1 of DeepPiCar, where I list several ML courses and resources to get you started.
- If you are into robotics, try to build some cool robots using a Raspberry Pi or an Nvidia Jetson Nano. Be sure to use either the new Raspberry Pi 4 or Jetson Nano. Raspberry is more widely used by makers and enjoys better support, while Jetson Nano has a GPU onboard, so it may be better for Deep Learning projects.
- If you don’t have any project ideas, do not despair. You can always contribute to one of the open-source projects mentioned above, as well as TensorFlow or PyTorch if you are into AI/ML. You may think you need to be an expert to contribute to these well-known open-source projects. You do NOT. Actually, in each open source project, there are quite a few small features and easy bug fixes designated for noobs to get their hands dirty first. This way, you can be familiar with the code base and submission process before tackling more complex issues.
Once you finish your project, be sure to let the world know about it! Is it enough that you just publish your finished code on GitHub and be done with it? No! Because most people prefer to read blogs about what your code does first.
Nice, well-polished blogs are great marketing material for your project, and more importantly, for you!
Yes, writing polished blogs with nice pictures and graphs takes a long time. It took me about all of May to write 6 articles. I estimate about 200 total hours or 30 hours/article. If you are working full time, maybe write one well-written blog, which serves as an overview of your project.
One thing to remember is that you have to enjoy what you are doing, instead of doing the project just to land a job. If you do have a passion for what you build, it will shine through when you talk to interviewers.
Step #2: Study Hard and Study Smart
Algorithms and Data Structures
If there is one single skill you need to master for tech interviews, it is Algorithm and Data Structures (A&DS) coding skills. No matter which big or small tech firms you interview with, they will grill you on your coding skills, although most firms won’t care which programming language you use.
My favorite programming languages are C++ and Python, but for coding interviews, I recommend Python. It is so concise and you can do so much with so few lines compared to C++, which is very verbose. There are tons of resources that prepare you for A&DS. I used the following resources:
Cracking the Coding Interview Book (CtCI): this book is about 700 pages, and only costs $30. If you need a refresher on A&DS concept, this is an excellent starting point. In addition to concepts, it gives a series of easy to medium level practice questions with full solutions. I spent about 2 to 3 weeks full time on it, spending 1–2 full days on each A&DS related chapter. I skipped chapters on math/brain teasers/OOD/C++/Java/SQL, as they are not related to A&DS.
LeetCode.com: I also used LeetCode (LC) heavily, as I felt CtCI did not give me enough practice. Leetcode is probably the most comprehensive and organized online database of coding interview questions, with over 1000 easy, medium, and hard questions. Each question has a unique number. (e.g. LC#1 is TwoSum) Many online posts simply refer to their interview questions as LC #xxx instead of typing out the whole question.
I highly recommend spending $30/month to sign up for LeetCode Premium, as it gives you access to ALL of the LC questions and solutions. I felt that it was so helpful, I signed up for the annual membership for $99, as I think of it as a “gym membership fee for my brain.”
I completed over 100 LeetCode questions (35 easy, 60 medium, 14 hard). About 90% of my actual interview questions, or their slight variants, could be found on LeetCode. In most cases, I didn’t know they were from Leetcode until after the fact. But since I practiced enough of the LC medium questions, I was able to solve questions around the same difficulty. In the end, I felt I could NEVER do enough LC medium questions, because to this day, I still struggle with some of the LC medium questions.
Tushar Roy’s LeetCode Hard Solutions: Tushar is actually an Engineering Manager at Apple. He made these videos when he was just a software engineer. I would say that watching his videos taught me not only these algorithms but also how to present complex ideas/algorithms clearly. This helped me immensely when I was doing whiteboard coding during on-site interviews.
Note that most interviewers will give LC medium level questions, as it is pretty fair to ask someone to solve a medium problem in 20–30 minutes. I would suggest doing at least 20 easy, and 30 medium LC questions before your first phone interviews. I did my first phone interview after I finished the CtCI book and before starting on LC, and was promptly slaughtered.
Also, I timed myself on each practice problem, as if I was in an interview. However, I used an IDE, with auto-completion and a debugger. You won’t get these in an actual interview, so I usually set a tighter time constraint when I practiced, at about 30 min/question, instead of 45 min. You may choose to mimic the real test environment by using a regular text editor only or even a whiteboard. It's up to your personal preference.
System Design
The second most important skill you need to master is System Design. Usually, one on-site interview session will ask you to design a large scale distributed system, such as the Netflix video serving system, or WhatsApp instant-messaging system, or Instagram stories, and so on.
This test is a mixture of both hard and soft skills. It is a hard skill test because you need to understand a lot of the commonly used distributed system components, such as a distributed database, distributed in-memory cache, distributed configuration manager, distributed file storage, and distributed search engine, etc., along with when is the right time to use each of them.
It is also a soft skill test because you need to be able to draw a clear diagram to illustrate your design and verbally discuss and defend your design. I was told that system design interviews heavily influence the level you are offered if you pass the on-site interview (that is, it may decide whether you are offered a Level 4 or Level 5 engineering position, for example).
Here are the resources that I used:
- Cracking the Coding Interview Book(CtCI): There is a chapter that discussed system design, but it is covered at a pretty basic level
- Gaurav Sen’s System Design YouTube Channel: I felt unfulfilled after reading CtCI’s system design chapter. Then I stumbled upon Gaurav’s channel, which has 22 videos. I downloaded all his videos onto my laptop and watched them on a long plane ride. Man, this guy is so GOOD (and funny) and explains things so clearly! About 10 videos are in-depth descriptions of individual distributed system components, the rest are actual use case discussion on how to build Netflix, or Tinder, or Facebook systems, etc.
- Tushar Roy’s System Design Videos: While Tushar is very good in LC Hard questions, he also has 5 great System Design videos. I recommend watching these videos after Gaurav’s, as Gaurav gives you a solid foundation in system design, and Tushar’s videos assume some of that knowledge.
For me personally, since I had worked on quite a few distributed systems before, I was able to grasp the general idea pretty quickly even though I had not used some of the new technology mentioned in the videos above. After watching enough videos, I was able to generalize most distributed system into the following layers:
- Clients (PC/Mobile apps, browser)
- A distributed Load Balancer to handle client requests
- Location-based Content Delivery Network (CDN) or In-memory Cache to quickly deliver large and relatively static content (videos and images) to clients that are geographically closer to the CDN/Cache.
- A series of microservices to handle various business logic, such as authentication, serving/saving user content, deliver messages between users.
- Communications between microservices are sent via a distributed messaging system.
- A distributed database to save user content and messages. Optionally, add a distributed caching layer before the database to improve read/write throughput.
Behavior Questions
I think behavior questions are the easiest part of the interview. Unfortunately, they also carry the least amount of weight in an interview evaluation. Sure enough, tech companies know that it is easy to put on a “nice person” personality and say the right thing in a behavioral interview. But it is much harder to train yourself to be a good coder.
For a career switcher, the most important question to prepare for is, of course, “Why are you looking to switch industries?” Hopefully, with the project you built in Step 1, you can probably knock this question out of the park by showcasing your project and your passion for the new industry and the company you are applying for.
Here are some other behavioral questions to prepare for:
- Why do you want to work for my company/my group?
- Give an example of a goal you reached and tell me how you achieved it.
- Give an example of a goal you didn’t meet and how you handled it.
- Describe a stressful situation at work and how you handled it.
- Have you been in a situation where you didn’t have enough work to do?
- Have you ever made a mistake? How did you handle it?
- Describe a situation when you had a disagreement with your coworker/boss/subordinate, and how did you handle it?
The key to all behavioral questions is to end on a positive note. For example, even if you are asked about a disagreement with a co-worker or a failure in your career, truthfully describe what happened, but more importantly mention what you learned from it. Talk about how it helped you become a more effective team member/engineer when similar situations arose again.
Step 3. Apply via Multiple Channels
I started to monitor the ML Engineer job market in the Bay Area closely at the start of June, right after I published my blogs on DeepPiCar. At the same time, I started my one month of intensive full-time coding preparation (about 200 hours total).
By the end of June, even though I didn’t feel quite ready, I started to apply to companies. The reason is that there is a 1–2 week lead time between when I sent in my resumes and the phone interviews. Via multiple channels, I made contact with over 20 companies and did over 30 phone interviews. Sometimes multiple phone interviews with the same company.
Resume — List the relevant stuff first
I won’t discuss resume writing too much, as there are already many great articles on it. My focus is on how to do it from a career switcher’s point of view so that recruiters will be able to quickly identify you as a good fit for the new industry/job function.
Remember that I was changing from a quant developer in Finance to an ML Engineer in Tech - so it was doubly tricky, as it was both a role shift and industry shift. Again, my projects came to the rescue. I listed them at the top of my work experience, as “Personal Projects”. Yes, even though they are not exactly “Work”, they were my work, and were highly relevant to what I wanted to do as my next job.
You should know that most recruiters don’t read past the first page of a resume. If they can’t spot the keywords they are looking for in 10–20 sec, your resume is tossed aside. I also listed the skill sets (and all the keywords) relevant to the new job at the top half of the first page of my resume. See below.
LinkedIn — Let them come to You!
The best job applications are the ones you never have to send out. After I posted my DeepPiCar blog posts on LinkedIn, I was excited to receive so many messages/calls from recruiters, including from some huge self-driving companies, asking me if I would be interested in their ML Engineer roles.
I was surprised by the power of Medium blogs and LinkedIn posts. But be sure to mark yourself as “open to opportunities” in the LinkedIn Privacy Settings, so that recruiters can easily find you. When recruiters contacted me, I almost always got a phone interview.
Internal Referrals — Have a strong advocate
I would say the 2nd best job applications are the ones submitted by internal referrals. I had an internal referral at both Facebook and Google. I failed my first Facebook interview badly, but because my referral gave me a strong recommendation, Facebook offered to let me try again. Luckily, I passed the 2nd phone screen a month later.
With Google, it was even more surprising. Partly because of my strong referral, and partly because I told them I had other on-sites coming, they skipped me directly to on-site interviews, even though I was a remote candidate (I live in Chicago, by the way).
So I recommend that you find any of your family member/friends/classmates that work in one of the tech companies that you want to join. If none of them work there, maybe they know someone who does. Please ask your friends to introduce you to them, and maybe have them submit your resume via internal referral. Your chances of getting a phone interview are much higher that way.
Another way is to use your LinkedIn network wisely. You can search for people that work for a specific company, and ask one of your mutual friends to introduce you two. If not, send the person a LinkedIn Mail.
Note that if you send a lot of LinkedIn Mail, you need LinkedIn Premium. I signed up for about 3 months of LinkedIn Premium (about $30/month) and was able to connect with a lot more people directly. Some of the connections lead to interviews. As a side benefit, I received many more recruiter messages than before, because I believe that the LinkedIn algorithm ranked me ahead of non-paying users.
3rd Party Recruiting Agencies
Overall, I felt that most 3rd party agencies didn’t work well for my job search this time. As a reference, when I looked for finance jobs in the past, I exclusively used executive search firms, and the results were great. But most of the tech giants don’t use 3rd party recruiting agencies. The only agencies that worked well for me were TripleByte and DeepLearning.ai, which I will discuss below.
TripleByte — Skip the phone interviews
TripleByte is a unique recruiting agency. Its appeal to the candidate is that once the candidate passes TripleByte’s comprehensive 2-hour live tech screening test, they can go directly on-site with many companies. It is also appealing to companies because TripleByte weeds out most of the weak candidates for them, saving their engineers hours of phone screening time.
When I passed TripleByte’s test, I could choose from about 200 companies. They were mostly small startups, but with quite a few large companies, such as Apple, Adobe, American Express, etc. I ended up interviewing with the Apple Siri group (huge), Zoox (medium), and Determined.ai (small) on-site. All of them are doing amazing engineering work.
I highly recommend going through the TripleByte process, as it identified my weak points and saved me from many hours of phone screening and related headaches. Take TripleByte’s online test here.
DeepLearning.ai and Workera.ai — The Gospel for Aspiring Data Scientists/ML Engineers
If you are an aspiring Data Scientist/ML Engineer, you must have heard or taken one of Andrew Ng’s Machine Learning/Deep Learning courses, offered by Coursera/Deep Learning.ai.
Actually, DeepLeaning.ai has two parts: one part is education, which is very well known, and the other part (Workera.ai) is recruiting, which is lesser-known. That’s because Workera.ai is quite new, only started mid-2019. They don’t have nearly as many affiliated firms as TripleByte, but I believe they are quickly ramping up this effort. They also make you take a test.
The differences between Workera.ai’s and TripleByte’s tests are two folds. First, it is a test designed for Data Scientists(DS)/ML Engineers, where TripleByte has tests for general software engineers as well as ML engineers — the ML engineer test is brand new.
Second, the Workera.ai test is non-binding, meaning passing its test does NOT skip you straight to on-site interviews. Instead, Workera.ai refers you to DS/ML groups in a few of their affiliated companies, and essentially brings you to the front of the queue. But you still have to go through the whole phone/on-site interview process.
I feel it is still very valuable as Andrew Ng’s reputation and network in Deep Learning space in the Bay Area are quite wide-reaching. I ended up interviewing with Pinterest and Scale.ai’s ML groups. I don’t think I would’ve gotten interviews from either company had I just applied directly. Click here to apply to Workera.ai’s AI Program for Experienced Engineers.
Online Job Boards — Don’t rely heavily on them
To widen my search, I had also set up job search alerts at a few online job boards, such as LinkedIn, GlassDoor, Indeed and ZipRecruiter, so they would notify me of any new job postings matching my search criteria. Over time, I did receive a few phone interviews after applying.
Overall, I have found the signal-to-noise ratio to be somewhat low, meaning I would get a lot of daily emails, but very few good job functions from top companies. But don’t ignore this channel altogether. You need to cast your net wide initially, and maybe you will catch some fish via this channel
Direct Apply — Doesn’t really work
In the old days, people would send a nice cover letter with a resume to the companies, and they would expect to hear back from someone from the HR department. But this time around, this approach didn’t work for me at all!
I identified about 10 companies (mostly autonomous vehicle companies) that I wanted to work for, and directly applied on their company websites, under the career page. To my surprise, I didn’t hear back from ANY of them, not even a rejection email!
Luckily, applying to each company online didn’t take that long. I would say, still apply to any companies that are interesting to you but do not hold your breath to hear back.
Apply for Jobs in Phases
Try to apply to a few companies that you are not so excited about or that you think are easier to get into in your first phase. Then apply to your dream job/companies in a later phase. You can use your first phase to practice, improve, if you get offers, even leverage those for better offers from your dream companies.
This may sound quite controversial and may seem like a very “materialistic” approach, but think about it: many people would work at a less prestigious company, with the plan to gain experience and then move into a more prestigious company a few years later. And who knows, if you don’t land your dream job, at least you have a few offers to choose from among your first phase companies.
Get Organized: Keep a log book
When you are applying via so many channels, it is hard to keep track of which companies you applied to, and which stages you are at with each company.
To help with this, I maintain a detailed interview log book. It's organized by interview stages (Applied, Interview, Offer, Rejected, etc) and then by companies. Each company is essentially a page, with background information and a list of events in chronological order, such as phone calls and interviews. This way, I can see which companies that I have applied and interviewed with so that I can do the proper follow up.
Step #4: Interviews
4.1 Phone Interviews
Initial HR Calls
Usually, the first contact with a company is a recruiter’s email. The recruiter asks you for a time for an initial phone call, which is usually a “fit” call, where you discuss your interests and background and why you would be a good fit for the role. Don’t stress too much over the detail. This will most likely be a short call, and the recruiter will want to move you to the next stage, which is the Technical Phone Interview.
Before the Technical Phone Interview
One or two days before the technical phone interview, be sure to read up on Glassdoor and Leetcode for previously asked interview questions for this company. For big companies, such a Google and Facebook, this does NOT work well, as there are hundreds of previously asked questions.
But for smaller companies, this is somewhat effective. I would scroll through many posts on Glassdoor and copy down any specific technical questions. Then I would try to solve all of them. During the phone interviews, it is pretty rare to bump into the exact questions posted online, but doing this company’s past problems better prepares you for this company’s phone interview.
This is analogous to practicing past years’ final questions before taking the final exam of the same professor — the questions may be different, but the style and type of questions would be similar.
Technical Phone Interviews
Technical phone interviews are where the rubber meets the road. The stage is designed to separate the capable candidates from the less-capable candidates. I have read that only about 10–20% of the candidates can pass the technical phone screens of top tech companies.
The measuring stick is simply a coding test, NOT how well you talk, NOT how experienced you are at your current job, NOT how many programming languages you know, NOT even your personal projects. Most interviewers simply want you to complete a coding exercise in whatever programming language you are most comfortable in.
Personally, I don’t quite agree that this is the best way to find the best engineers. For example, I've worked with many very experienced software engineers. Some are expert GUI/app developers, some are C++ experts, others are low-level Linux gurus, but many of them tell me that they would fail miserably in a timed Algorithms and Data Structures (A&DS) coding test.
But since this is the only game in town, in order to break into the tech industry, you have to “Crack the Coding Interview”…
The coding exercise is always done via a shared online notepad, such as CoderPad or Google Docs, where both you and the interviewer can type at the same time.
While some companies, like Google and Facebook, only ask you to write down the correct algorithms and won’t ask you to run your code, many companies expect you to come up with fully working code within the 45–60 minutes time window.
In addition to the shared notepad, most companies conduct voice-only calls, while some companies conduct phone interviews via Zoom/Skype video calls.
Personally, phone screens are the hardest part of the interview process for me. For reference, I passed about only 50% of my technical phone screens. They are difficult because:
- The 45–60 min time window is usually tight for me, as I am not fast at typing. (Believe it or not, I am faster at whiteboard coding for reasons I will discuss in the on-site interview section.)
- You need to code while talking with the interviewer throughout the call. Most people, including myself, prefer to discuss a design/approach first, and then type the code and debug in silence. But if you don’t talk for 20–30 min during your implementation stage, it would be very awkward.
- Online notepad is text-based and is not a whiteboard. So it is hard to draw a diagram or illustrate your code workflow graphically.
- Online notepads are NOT IDEs. While most of the online notepads, such as CoderPad, can do decent syntax highlighting and indentation, they are not full-blown IDEs. For example, they can not do word auto-completion. They can not highlight obvious syntax errors while you type and they certainly don’t support line-by-line debugging. So a lot of times, I had to resort to the “old faithful” print statements for debugging, which is very slow and clumsy.
- Voice calls are non-visual. As I tried to explain my approach over the phone, I couldn't draw a picture and couldn't look at the interviewer’s facial expression or body language to gauge if I was on the right track.
Here are what I did to combat the above difficulties:
- Use a good phone headset. This should be very obvious because you want to free both of your hands to code! So invest in a good Bluetooth headset and make sure it is fully charged before phone interviews.
- Keep “Chit-chat” to a minimum. In my first couple of interviews, I would try to give the interviewer a good impression of myself. So I would spend about 5–7 min talking about my background, my experiences, and then my self-driving car. Sometimes, the interviewer would ask me a few questions, and it could drag on to the first 10 minutes! What I quickly discovered was that all this “chit-chat” time ate into the total 45 min allotted for my interview, which meant I had less time to work on the coding problem. In fact, most interviewers are there to gauge your coding skills ONLY, and your strong work experience is not relevant to them at this time. So I learned to shorten the “chit-chat” to about less than 2 min at the beginning, and leave my questions to the end of the interview. In fact, if I finished the coding problem successfully, the interviewers usually are more willing to talk with me a bit longer than the 45 min slot. On the other hand, if you “bombed” the coding interview, chatting won’t change the outcome of the interview, anyways. Note that this tip applies to on-site interviews as well.
- Use two monitors. One monitor would be for the shared notepad, and the other monitors would be for googling and IDE, etc. Most laptops nowadays have ports for external monitors. Be sure you connect your laptop to at least one external monitor when you code, so you won’t have to flip back and forth between windows.
- Use an external mouse. If you use a laptop, be sure to invest in an external mouse. For me, using an external mouse significantly improves my ability to select, copy and paste code.
- Use an IDE. Even though you are coding in the shared notepad, sometimes, to troubleshoot, it may be better to copy-paste the code into your IDE, fix syntax errors and bugs, and then copy the working code back into the shared notepad. Most interviewers won’t mind, as long as you can get the code working within the allocated time. They want to see you succeed as well! Before your phone interview, be sure to set up an empty project where you can quickly paste in code and run. You don’t want to spend precious interview time creating a project and setting up run parameters. Having an IDE open also means that you can directly paste in your code at the end of the interview so you can save a copy of the questions and your solution for further analysis.
- Use a programming language that saves you from typing. Most of the tips here are designed to help you save time TYPING, so you can spend more time THINKING about the solution. So try to choose a language that can do a lot with very little typing. My best languages are C++ and Python. I choose Python for all my interviews, unless an interviewer specifically requests C++, because it is so much more expressive compared with C++.
- Make good use of Google. This is one advantage of a phone interview over an on-site interview because you can google! If you are not too familiar with the API of a function, or certain syntax of a language, feel free to google it. It is understood you can google during a phone interview. Heck, if your interviewer is lazy and grabbed a problem verbatim from LC, then congratulations! ;-)
- Talk through your approach thoroughly with the interviewer BEFORE you start implementation. For my first few interviews, I would start coding after having a rough idea of what to do, thinking I could flesh out the details as I coded. This was NOT a good idea. Try to flesh out as much as detail during your initial discussion with the interviewer. This will actually save you lots of time later on. The interviewer is, of course, very familiar with all the good and bad approaches to the problem. If you present a suboptimal or incorrect approach, they may steer you towards a more optimal one and/or may point out bugs/corner cases you forgot to consider. This can save you tons of implementation time down the road. But be sure to cover as many corner cases as possible on your own, as you will get points deducted if the interviewer has to point out the missing corner cases.
- Solving the problem is better than not solving the problem. This statement may not be that obvious when you are searching for the most optimal solution. Sometimes, if I couldn’t conjure up the most optimal solution, I would propose and finish implementing a suboptimal solution. In any case, the fact that I came up with some working solution (albeit suboptimal) gave the interviewer a decent data point to compare me to others. In some instances, the interviewers told me, after the fact, that the “optimal” solution that I thought was possible does not exist! As I learned from my own failed experiences, not coming up with a working solution would certainly be a FAILED interview.
Remember, at this point, you should NOT be focusing on Systems Design questions, as they are only asked during on-site interviews because it requires a whiteboard to draw diagrams.
Online Coding Tests
I have encountered very few tech companies that still give online coding tests, such as HackerRank or Codility, although quite a few finance companies still give those. The reason to give these tests is to save hiring companies’ manpower.
Usually, you would get a link to an online test from a company’s recruiter. There are usually 3–5 coding questions, which you need to complete within a 2–3 hours window. You need to complete it anytime within 7–10 days of the recruiter’s email. No human is overlooking you while you take the test, and you need to pass most test cases to pass this stage.
Here are some tips for online coding tests:
- Use an IDE: you can write and test your code entirely in your favorite IDE and then paste into the online test page to run the official test cases.
- Read all the problems before you start. Some online tests are designed so that most people can’t complete all questions within the allotted time. So be sure to read all the questions before you start any problems and start on the easier questions first so that you can finish as many questions as possible.
- Get it working first. For most of the online tests, time is a scarce resource. So the goal is generally to pass as many test cases as possible, not necessarily ALL the test cases. If you have a working solution, it should pass most of the test cases. If your solution is not the most time-optimized, you may time out on a few test cases, which is fine. Just move on to solve the next problem, come back if you have more time left. (Note: DO NOT do this when you are writing production-level code. For production-level code, DO spend the time to get your algorithms right and cleaned up, and add enough documentation so that you and others can maintain your code in the future.)
- Save a copy of the questions and your solutions for future analysis. This should be routine that you save ALL your interview questions regardless of whether they are phone/online/on-site questions.
Take-Home Projects
A few companies give take-home projects before, or in lieu of, a technical phone screen. I had two companies that gave me take-home projects, both of which were Machine Learning related. I have found these projects to be much more enjoyable and more relevant to the job that I was applying for. So I wish more companies would give take-home projects in lieu of technical phone screens.
But I do understand that it may not be as effective or as fair because 1) companies don’t know if you or your ML expert friend did the project, and 2) even if you did it yourself, how long did it take you?
For take-home projects, since you typically need to spend a lot of time on them, make sure you are using your time wisely.
For a company that you are really excited about, yes, do spend the 8–10 hours do a nice job coding and documenting your approach and design decisions. For Scale.ai’s project, I spent at least 10 hours working on their project — even though the instruction told me to only spend about 2–3 hours. I did this because I thought it was fun and I learned a lot by exploring different ML approaches.
For companies you are not so excited about, don’t spend that much time, and save the time for more LC problems, so you can be better prepared for coding interviews in general.
Interview Scheduling
Once you have done a few phone interviews, you should be getting some on-site interview invitations. In the beginning stages of your phone interviews, your success rate will be somewhat low. I literally failed all of my first 4–5 phone interviews. Then I realized that I needed to focus on practicing more dynamic programming and recursive algorithms.
Your experience may be different, but don’t be discouraged when you get rejection emails in your interview process. Ask the recruiters for feedback and study more. There are a lot of companies out there for you to try.
Here are some interview scheduling tips:
- Keep a detailed interview log: This is the same log mentioned in Step 2. Now is the time to start to keep track of when and what was discussed in each interview.
- Put all interviews in your calendar and set reminders/alerts. You don’t want to miss a single interview because you forgot about it. Also, make sure you confirm the interview time zone. For simplicity, I always communicate to recruiters in their time zone (usually this is Pacific Time).
- Schedule back-to-back phone interviews with at least 30 mins in between. This is because some interviewers may call 5–10 min late, and some interviewers may allow the interview to go over the time limit by 5–10 min. So if you set two phone interviews back-to-back, you may have to cut one short or miss the other call. Plus you need a 5–10 min break to clear your head and write down the interview notes.
- Ask for a Second Chance. This may be a little known fact. If you fail the first phone interview, many companies will allow you to have a second chance. Most won’t offer it automatically, but would if you ask nicely. So always ask, but schedule it a few weeks after the first interview, so you have enough time to study. There usually won’t be a third chance unless you wait for 6 months.
- Stagger your interviews. I staggered my interviews in phases. I put the companies I believed were easier to pass in the earlier phase, and the harder-to-pass and more well-known ones in the later phases, which was about 2–3 weeks later. This way, if you discover you are weak in some topics, you have 2–3 weeks to study them.
- Cluster your on-site interviews. Because most of the companies that I interviewed with are in the Bay Area, I tried to schedule all of the on-site interviews within a 1–2 weeks span, so I could fly out once and get all these on-site interviews done. For example, my Bay Area on-site interviews lasted 2 full weeks, during which I interviewed with 6 companies — 3 interviews per week. Some companies would be more willing to bring you on-site if they know you would be in town for other interviews. Also, they don’t have to pay for your plane ticket. Various companies paid for some of the hotel nights, and I had to cover the other nights. This was fine for me, since it saved me a lot of time, and I was able to cluster all on-site interviews together, so I could hear back the decisions from all of them around the same time.
4.2 On-Site Interviews
2–3 weeks before the on-site interview, start to focus on System Design questions. Many companies allow you to schedule on-site interviews up to 4–6 weeks after you pass the phone interview. This should give you ample time to prepare for both A&DS and System Design questions.
Normally, there are 4 to 5 45-minute interview sessions for each company’s onsite interview — 2 in the morning, lunch, and 2–3 in the afternoon. There will be 1 System Design, 1 Behavior and 2–3 A&DS coding interviews. Very few companies will ask you about math or brain teasers, so I wouldn’t spend a lot of time preparing for them.
System Design Interviews
This was covered in Step 2: Interview preparation. If you watched all the system design YouTube videos I recommended and can generalize it to a framework similar to what I outlined, you will be in pretty good shape.
Clarify the spec. One important technique of the System Design question is to clarify the features and functionality of the system early on. You want to define a set of features that is not too trivial and not too complex that you can’t finish within the 45 min time frame.
For example, when asked to design an Instant Messaging App, be sure to mention essential features such as:
- User authentication (this should be in most systems)
- One-to-one messaging
- Group messaging
- User active status
- Offline messages (if you have time)
For a 45 min session, I would not mention these non-essential features:
- voice calls
- video calls
- multi-person calls
- personal timelines (i.e. Facebook Stories)
Of course, if you are asked to design Skype, you would have to design for voice and video calls, but I wouldn’t include sharing computer desktops just to limit the feature set to a manageable scope.
Watch for curveballs. During the interview, watch out for odd questions and be able to respond intelligently.
For example, when I was at the Facebook interview, I was asked how to design a simplified version of Google Search. I proceeded by drawing a pretty good high-level design on the whiteboard. Then the interviewer threw me a curveball:
Interviewer: “So how many servers do you think you need?”
Me: “Well, this depends on how many people are using it and how beefy the servers are…”
Interviewer: “Why do you need to know how beefy the servers are?”
Me: “My thinking is that the actual usage is sort of like the numerator, the server hardware capability is like the denominator, and the number of servers depends on these two numbers.”
Interviewer: “NOPE, the hardware spec of a server is irrelevant.”
Me: “Surely hardware spec matters. If I can host a service with 10 beefy servers, I would probably need 100 laptops to host the same service”
Interviewer: “Hardware spec is irrelevant.”
At this point, I was at a loss, because I thought he was being quite unreasonable. After a long and awkward pause, I almost gave up.
Me: “So what do you mean by hardware specs don’t matter”
Interviewer: “Pretend you don’t know the hardware spec of a server, how do you figure out how many servers you need?”
OH, THAT’S WHAT HE MEANT??!! He didn’t mean hardware spec is irrelevant, he just meant we don’t know the exact hardware spec.
Me: “Oh, in that case, I would have to benchmark the throughput of the servers, and the number of servers required is roughly the maximum usage divided by the throughput of a single server. Am I on the right track here?”
I could see him slightly nodding his head.
This moral of the story is to illustrate how important it is to clarify what the interviewer is asking/telling you. You can do this by repeating the question/statement back to them in your own words. If you are really stuck, ask them what they meant by what they just said. Maybe they will rephrase the questions/statements in a different way, so you can understand and proceed.
Remember many interviewers are not native English speakers, so what they say and what they mean to say may not exactly match. Similarly, many interviewees (yours truly included) are not native English speakers either, so what they hear and what they think they hear also may not exactly match.
Having the interviewers say the same thing in different ways may greatly help interviewees understand what the interviewers truly mean.
Whiteboard A&DS Coding Interviews
On-site A&DS questions are almost exclusively done on whiteboards. Many people, including myself, are scared of whiteboard coding initially, because who in a real work setting writes detailed code on a whiteboard?!
But as I went through all these onsite interviews, I have found that whiteboard coding is, in some sense, easier than phone interviews. I will cover some techniques specifically for whiteboard coding below.
Illustrate your algorithm with diagrams/charts/tables. There is an old saying, “A picture is worth a thousand lines of code”, or something like that. Before you write code, try to illustrate how your code would work with diagrams/charts/tables. This will give your interviewer a road map of what your code might look like, and will allow them to point out any potential issues that they see.
Once you are done coding, try to walk through your code line-by-line with the diagrams on the side, so that you can show the interviewer that your implementation matches what you intended to do. Be sure to watch Tushar Roy’s LeetCode Hard Solutions YouTube videos to learn how to present ideas on a whiteboard.
Split the whiteboard into sections. For reasons mentioned in the previous tip, I recommend splitting the whiteboard into at least 2–3 vertical sections. One section is reserved for diagrams, and other sections are for code. This way, you can always refer to the diagrams before/during/after you code.
Don’t sweat the syntactic details. If you are allowed to code in any programming language (as this is the norm), then the interviewer should not be very picky on the syntax of your code. For example, if you miss a trailing semicolon in C++/Java, or trailing colon in Python, it is not a big deal, as long as your indentation is correct. Or if you misspell or shorten the name of a built-in function, it is also not a big deal, as long as the interviewer understands what your intentions are. On the contrary, you are not afforded the same luxury in phone interviews.
Use shortened variable/function names. Because writing out long names with a marker can take a long time and a lot of space, tell your interviewer the full name and meaning of a variable, and then use the shortened name in your code. This will save you a lot of precious time as well as precious whiteboard space.
Constantly Seek Feedback. This is one of the many benefits of an on-site interview because you can quite easily gauge the feedback of an interviewer. When I present my design or approach, I regularly check the facial expressions of the interviewer and ask casually, “Am I on the right track?” or “How does it look?” Usually, the interviewers are pretty helpful and give you some feedback, or at least nod or frown. If you are way off, they surely let you know, if you ask.
As I found out the hard way a few times, when I didn’t seek feedback, some interviewers would let me finish the whole implementation and then point out some major flaws in the end. As a result, I failed all those interviews miserably. So try to flesh out your design as much as possible before coding and seek feedback.
Other On-site Interview Tips
Some of these non-technical tips may be common sense, but I will list them as a reminder.
Ask good questions at the end. You probably won’t have a lot of time to ask questions at the end of each interview session. So keep these questions short and impactful. The interview is a two-way process - companies are trying to extract information from you for their evaluation process, and you need to do the same to these companies, so you can make the most informed decisions when you get offers.
Here are the typical questions I like to ask:
- Can you tell me about your background and what you do in your current group?
- Can you tell me about the technology stack and development process in your group/company? Once the interviewer mentions a few programming languages or tools, you can echo by saying you also have worked with these technologies.
- What would be an ideal candidate for your group/company? Once the interviewer mentions a few characteristics of the ideal candidate, you can echo by saying you also have some of these characteristics and give a quick example to back it up.
- Sell yourself a bit. This may not work for everyone. I also used the “questions” time at the end of the interview to show my self-driving robotic car and a couple of YouTube videos of the car to the interviewers. I think it worked out surprisingly well because I saw most interviewers were quite pleasantly surprised when they held the actual car in their hands.
Stay hydrated. You will be talking a lot during the interview, and you will be sweating a lot (unconsciously), so you always want to be hydrated at all times. This means refilling your cup after every interview session, and taking a sip whenever you are not writing on the whiteboard. I find caffeine (coffee/tea/Coke) to be quite effective at keeping me at peak performance.
Take washroom breaks. After each interview session, be sure to take a washroom break. Unfortunately, these 45–60 min interview sessions are usually back-to-back with no breaks in between. So be sure to ask for one before the next session starts. You want to be able to walk and stretch your legs a bit and more importantly, wash your hands and face, so you can go to the next interview refreshed. Don’t take too long a break though, because the break time eats into your next 45 minutes.
Take notes. I always keep a detailed log of my interviews. Since most of your interview sessions are back-to-back, the only time you can take notes is during bathroom breaks. :) Bring your phone and quickly jot down a few notes of the questions and your approach so you can remind yourself after you are done for the day. This should take no more than 1 min.
Eat a light lunch. It is pretty hard not to overeat at lunch because many top tech companies have awesome free food! Facebook even has free ice cream! While it is tempting to try all the free food while you are there, you need to remember you are not there to eat just once but to interview and get the job, so that you can eat there every single day!
Two reasons to not overeat: first, you want to stay alert in the afternoon session and not feel drowsy. Second, you want to spend most of the time chatting with your lunch buddy. While for some companies (Google/Facebook), your lunch buddy’s feedback is not part of the offer decision, many times, they are senior folks in the firms so their opinions may matter and you want to leave a good impression.
Pack some snacks. On the flip side to the last point, for some of my on-site interviews, either by design or due to time conflicts, the lunch is scheduled at 1:30–2 pm or skipped altogether! I would be so hungry by then and would be running on fumes. So I learned to always pack a granola bar and a few pieces of chocolate with me so that I could take a few quick bites in between interviews.
Bring a few resumes: Yes, most interviewers would indeed bring a copy of your resume with them. However, occasionally I encountered interviewers who didn’t bring a copy of my resume with them, so I just gave them a copy. For tech interviews, it probably doesn’t matter that much, but it is a nice gesture.
Post mortem analysis. After you are done with the interviews for the day, don’t relax right away. While your memory is still fresh, go back to the hotel/home and immediately jot down as much detail about the interviews as you can, including interviewers’ names/background, all the questions asked, your approaches, interviewers’ answers to your questions, etc. Do this electronically (not on a paper notepad) so it is easier to search and archive later.
Also, at a later time, revisit all the interview questions, get optimized solutions, and think about how you can improve your performance next time. If you find the interview questions on LC, be sure to tag the questions with the company names, so others can benefit from your experience.
The above are just tips and tricks that help you tip the scale in your favor a little. You still need to practice the A&DS problem intensively and learn to quickly identify an approach to each problem.
For example, know when do use BFS or DFS in a tree/graph, when to use recursive vs iterative algorithms, when to sort or index data before processing, etc. And ALWAYS know the big O time and space complexity of your algorithms. I started interview preparation in late May, did my first phone interview in late June and finished my last onsite interviews in late-August — three of the most intensive months of my life.
If any of you ask me for specific interview questions that I encountered, unfortunately, I can’t disclose them here. But I have tagged all relevant interview questions on LeetCode, as a way to give back to the online community anonymously. I hope you will do this as well after your interviews.
Step 5. Offer Negotiation and Team Matching
5.1 Offer Negotiation
If you are reading this, you probably have received at least one offer. Wow, congratulations!
If you have not received any offers yet, stop reading right now, and go back to do more LeetCode and interviews! ;-)
Components of an Offer Package
These are the typical components of an offer package of a tech company. I will give a sample of a mid-level software engineer (SWE), typically 3–5 years of experience (YoE).
- Sign-on Bonus: This is the money you get right after you start work, NOT when you sign the offer letter. For example, $30,000 one time payment.
- Base Salary: This is the money that goes into your bank account every month. For example, $150,000/year.
- Annual Bonus: This is a percentage of your base salary, usually 10–30%, given every year. For example, 20%, which is $30,000 for a base salary of $150,000.
- Stock Options or Stock Grants: bigger companies tend to give Stocks (called Restricted Stock Units, RSUs) which are worth something at the time of the grant. Startup companies tend to give stock options, which are worth very little at the time of the grant but may have big potential. For example, $300,000 worth of Stock Grant vested over 4 years, so $75,000 is vested every year.
- Relocation package (If you need to relocate): This usually includes 1) a few weeks of corporate housing for your family, 2) moving of all your belongings, 3) help with selling and buying houses, and optionally 4) some cash to help with other relocation-related expenses. The relocation package is based on your family composition, location, and level. It is not usually negotiable.
Annualized Total Compensation (TC) This is the one number that makes all the offer packages comparable.
TC = Base Salary + Annual Bonus + Annual Stock Grants+ amortized Sign-on bonus (Assume you amortize the sign-on bonus over 3 years)
TC of our mid-level SWE
= $150k + $30K + $75K + $30K / 3 = $265,000
Note that the relocation package is not considered part of TC calculation, as it is expected you will be spending most, if not all, of the relocation package.
Know Your Level
Even though you know your YoE, the company may interview you at a certain level that is company-specific. For example, a 4 YoE engineer may interview at L3 or L4 at Google, E3 or E4 at Facebook, and Level 59–62 at Microsoft.
Ask the recruiter what level are you interviewing for. But this may not be the level you will be offered the job at. For example, you may interview at Facebook at E4, in the end, the hiring committee may decide that your performance is not stellar enough for an E4, but good enough to receive an offer for E3. So ask the recruiter again what level is your job offer for. With this level, you can find out the expected value and range of TC. (see below)
Know Your Market Value
You can’t negotiate if you don’t know your prevailing market value. For years, companies have kept compensation information very secretive, so the candidates have suffered HUGE information disadvantage.
Fortunately, in recent years, the compensation information has been democratized, with many websites crowdsourcing from many candidates and then presenting the anonymized compensation data by level, job function and location. One well-known site is levels.fyi.
As you can see above, all the top-paying jobs are in the San Francisco Bay Area. SWEs with 3–5 YoE can earn as high as $290,000 TC, and SWEs with 5+ YoE can earn over $400,000.
For any non-Bay Area engineers, total compensation of $300,000–$400,000 may be eye-popping. But remember that Bay area housing is THE most expensive metro area in the US. The median housing price of Palo Alto, CA is $2.8M (source: Zillow.com), and of San Francisco Metro Area (source: censusreporter.com) is $1.1M. For preciously this reason — lots of people are paid at a much higher rate.
As a comparison, the median home prices of Manhattan, NY is $1.2M (source: Zillow.com), and that of New York/New Jersey Metro Area is only $440K. (source: censusreporter.com)
Armed with levels.fyi, your level (obtained from the previous step) and the company name, you can clearly see the average reported TC as well as its range. For example, for the Google L4 SWE in the Bay Area, the average reported TC is about $260K, with a range from $200K to $320K. So if you received a Google L4 offer in the low $200K, then you know you have room to negotiate.
Startups
Levels.fyi is a great tool to compare offers between more mature companies (public or private), as the equity component of the comp can be evaluated in dollar terms with higher certainty.
But for early-stage startup companies, you can not find reliable data points on Levels.fyi. Very often you are given either 1) a percentage of the company stocks or 2) given a certain number of stock options. The company recruiter or the CEO may tell you that even though the value of your equity component is worth very little right now, it may work 20x–50x more if the company goes IPO in 3–5 years.
In reality, these equity components are hard to evaluate, are extremely non-liquid with no monetary value for years to come, and indeed go to zero value when 90% of all startups fail. (source: Forbes).
I received a few offers from early-stage startup companies. The typical package is light on cash (i.e. low base salary and bonus) and heavy on equity (lots of options with a huge potential payout… or nothing). This makes sense, as most early-stage startups do not make a profit, and any cash salary/bonus they pay out depletes their cash on hand or, in Venture Capital (VC) speak, burns up their runway.
Even though the startups I received offers from do really exciting work and the prospects look very promising — one had Google Ventures as a backer — I ended up choosing Google because I need the certainty and stability of a large company. After all, I'll have a college-bound kid soon. I can’t afford to join a startup for a few years only to see it fail and have my equity component wiped out.
However, if I were younger and had no kids, I would certainly work for a startup and try to hit a home run. If I failed, I wouldn't be under pressure to support the family and still have enough time to start over. If my wife made enough income to support the expenses of our entire family, then I could also work for startups for its potential upside. In finance speak, this is called diversification — by combining risky stocks with safer stocks or bonds, you can actually achieve higher risk-adjusted returns.
Don’t Accept an Offer on the First Call
When you are first offered a position, the recruiter always tells you the offer details (base salary, bonus, equity grants, etc) over the phone. This is called a “Verbal Offer”. What you want to do on the first call is to thank the recruiter, write down all the offer details, repeat it back to the recruiter to confirm, and ask them to send you this offer details in an email. Then hang up.
Remember, DO NOT accept the job on the spot. (If this is your dream job, you can jump up and down AFTER you hang up the phone.) Sometimes, the recruiter will refuse to send you anything in writing or email. If this is the case, then email them with the offer details you just wrote down and ask them to confirm whether what you heard is correct. They'll usually respond affirmatively.
This is important because after something is in writing, the recruiter can not easily back out of what they just told you over the phone.
Many times, recruiters will push you to verbally accept the offer right away over the phone or give you a 24-hour deadline to accept. DO NOT BITE! You should always try to negotiate for a better offer.
Offer Negotiation — Multiple Offers
Offer negotiation is like playing high stakes poker — indeed, we are talking about tens of thousands of dollars here — and it is both exciting and stressful. For some people like myself, it can also be scary. However, armed with information from level.fyi, you can call a recruiter’s offer bluff, if that offer is too low.
To have leverage in the offer negotiation process, it helps to have another strong offer, or in poker speak, a strong hand. Many recruiters are very willing to try to match competing offers. They can present the competing offer to the hiring/compensation committee as strong justifications for putting together a better offer for you.
In this case, you can try to let these companies bid up your compensation. This is quite normal, as bidding happens every day around us when a commodity is in demand, such as in the stock markets, eBay, and Google Ads. The bidding process ensures the commodity is valued at a fair market price.
Offer Negotiation — Just One Offer
Even if you don’t have a strong hand — i.e. only one offer or only low offers — you can tell the recruiter that you are really excited about the company, but your salary expectation is actually $XYZ. The recruiter will probably ask you to justify this figure, and you can say it is based on figures from levels.fyi, or your friends/co-workers who have similar YoE and their TC is $XYZ.
If you present yourself professionally, it is very likely the initial offer will be bumped up somewhat. It is highly unlikely that the company will retract its original offer simply because you try to negotiate. After all, the company invests a lot of effort to find a qualified candidate, so it doesn’t want to lose a good candidate over a small increase. So you have nothing to lose by asking for more comp, nicely.
Offer Negotiation — Money is Not the Only Thing on the Table
Remember money is not the only thing you can negotiate. Anything that the company can offer you is on the negotiation table.
For example, you can ask to work for a different group (say a core group rather than support related group), a different title (say Senior Software Engineer instead of Software Engineer), a different job function (say a research engineer rather than a software engineer), more Paid Time Off days, flex time to work from home, or a better relocation package.
Of course, this varies heavily from company to company. Larger companies may be less flexible, but smaller companies that may not be able to match the monetary compensation of larger companies may be more willing to consider these alternative demands. Again, it doesn’t hurt to ask, if you do it nicely.
Offer Negotiation — Don’t Be Too Greedy
After a few rounds of back-and-forth with the recruiter, if you sense that there is not much more room to negotiate, stop asking for more. Recruiters at larger firms see this every day, and probably won't mind too much. For smaller firms, the recruiter may be working directly with your hiring manager or even the owner/founder. If you drive your bargain too hard, you may be perceived as too greedy. So even if they hire you, they may view you negatively. Know when to be content.
Offer Stalling Tactics
If you are not quite happy with any of the offers after negotiation, you should try to delay the acceptance of the offers. This can happen if some offers’ job functions are very attractive, but comps are too low, while other offers’ comps are nice, but you don’t like the job functions.
Delaying an offer allows you more time to interview and land that perfect offer. But it does have risks, as the open position may be filled anytime. But for large tech firms, that risk is minimal, as they are always hiring. If you need to delay an offer, here are some tactics to try. (Disclaimer: I have not tried all of them, some of them have been suggested to me.)
- Meet with the team/peers: Request a call, coffee, or dinner to meet the rest of the team or learn more from peers. This is a great way to not only show interest but also get a strong signal on the company/team culture.
- Request Product Demos: Requesting a product demo is another great way to show interest. It’s also a good way to assess the technical challenges, the product roadmap, and how product-oriented the company is. You can usually combine this with meeting the team for lunch.
- Ask various Stock/Option related questions, such as the company’s current valuation, last funding round, company’s exit plans/strategies, and option exercise schedule, etc
These above strategies work best for most companies. For some large tech companies, once they decide to give you an offer, the offer is usually good for at least a few months, because you have met their technical bar, and they would be happy to hire a good SWE anytime. Your recruiter may not be willing to tell you this, as they want to close on you ASAP, but you can find out from other sources, i.e. Google Search and Blind App.
Lastly, remember all recruiters want to see you get hired by the company. Being able to close on a candidate (i.e. convert a qualified candidate to an employee) is one of their performance metrics, which is tied to a recruiter’s performance bonus. So treat your recruiter as your advocate, not your adversary.
5.2 Team Matching/Selection
Don’t choose a job simply because it pays the most right now. While compensation is an important factor in your offer decision process, what may be more important is how a job impacts your career. I will discuss how to select a company/team that will maximize your career potential in the long run.
Team Matching Process
For many companies (including Apple/Microsoft/many other companies), you will be interviewing with a few specific teams. And when you are offered the job, it will be for one of those teams.
However, for some companies such as Google and Facebook, they interview most candidates as general SWEs and only try to match a candidate to a team after that candidate is extended an offer. Since I have only experienced the team matching process with these two companies, I will discuss my experience below.
Facebook extends a firm written offer first and then match you to a team. Team matching can also happen before you join, as you take calls from hiring managers, or after you join, during the first 4–6 weeks of orientation/boot camp stage. The pro of this process is that the candidate knows that their offer is firm. The con is that you run the risk of joining then not being able to find a team you like during boot camp. But I was told by my Facebook friends that this situation is highly unlikely.
Google, on the other hand, works very differently. They do not run a long orientation/boot camp like Facebook. They first extend you a verbal offer and then require you to be matched to a team before extending a formal written offer. Even after you are matched with a team, this offer can be rejected/modified by the hiring committee. Even the final comp can be revised from the initial verbal offer by the compensation committee.
I have read, from many online posts, that this is a long and arduous process. As I found out personally, the team matching process was indeed long and frustrating and took 1.5 months. At one point, I seriously thought it would not work out and wanted to join another company instead.
Had Google extended me a firm written offer first like Facebook, it would’ve been much less stressful, because I would've known for certain I was going to work for Google and all I had to do was to find a team. Luckily, things worked out for me as I was finally matched with a group of my choice, and the offer was approved by various committees shortly after that.
How to Select a Team
Here are the questions that I ask myself during the interview or offer stage. You don’t need to ask these exact questions to the interviewers, but you want to somehow extract the answers to these questions from your interviews/conversations with the companies/groups.
- Which group will I be joining? I wanted to join one of the “core” groups of a company – a group that the company had put a lot of commitment and resources behind. These are often its flagship product groups or high growth groups. Working in these groups offers stability and/or growth.
- What types of work will I be doing for this company/group? I looked for work experiences that were transferable in my later career. I would prefer to work with publicly available tools and technologies, and not so much with the company’s proprietary technologies. For example, if I was to work on an ad recommendation machine learning system, I am sure I could easily find another company that also wanted to improve its ad/product recommendation system. However, I would not be so interested to work on automating some internal processes with a company's proprietary scripting language.
- What will I be learning by working for this company/group? Work is a two-way street. I wanted to be able to contribute a lot to my company. At the same time, I wanted to learn a ton from my work, so that my skill sets could be in high demand whenever I look for my next job. I believe AI/ML, Computer Vision, Cloud computing, Self-driving car, and AR/VR skills will be in high demand in the future, so I wanted to learn some of these skills in my next job.
- Do I have a passion for this job? If you don’t have a passion for what you do, it doesn’t matter how much the job pays – you won’t be happy and won’t be putting in that 120%. I was passionate about quantitative finance because it was cool to see math and technology transforming a whole industry. But after 10+ years, my passion is now in AI/ML. It is really awesome and magical that you don’t have to tell a computer exactly how to do something. All you have to do is to feed it data and it will figure out how to do it better than someone would with code.
- Do I like my manager and my peers? And do they like me? You want a manager that appreciates you and will support you in your new job. You also want to enjoy being around your teammates, since you will be with them for 8+ hours every single day, even longer than when you are with your family!
Many times, not all of the above can be satisfied. Then you have to weigh the pros and cons of each. But if one of the above gives you a red flag, I would seriously consider passing on that position.
I ended up choosing to go to Google’s Pixel Phone’s camera group because it offers three things that I am very passionate about: Computer Vision, Machine Learning, and Hardware. These are exactly what my robotic self-driving car project was all about! Also from what I learned, Google is now deeply committed to its hardware and smart home strategies, where the Pixel Phone will be a central part of that ecosystem.
Final Thoughts
Thanks for reading this far. It was quite a journey for me these last 6 months. Through my personal projects and intensive interview preparation, I believe I am now a better engineer (or at least a better interviewee. ;-) What I presented are my own lessons and experiences.
I have found that A&DS questions are the core of any tech interview, and there is no shortcut to getting better at them except through practicing more LC questions. Once you are decent at A&DS and System Design questions, the suggestions that I presented in this article should help you tip the scale in your favor.
I recommend bookmarking this article as you will need to refer back to it in the next 2–6 months as your job search progresses. Some of the tips in the later stages won’t make much sense until you actually get to that stage. For example, you may need to do a few phone interviews to appreciate the tips presented in Step 4, and you certainly shouldn’t be thinking about Step 5 offer negotiation before you get any offers.
If you are going through interviews, please let me know which of my tips worked well or not so well by leaving a comment below, so that others will benefit as well. Please also suggest new tips in the comments as well. Thanks!
Resources
Here is an appendix of resources (in alphabetical order) that I used in my job hunting process. Hope you will find them helpful as well.
Blind: This is an app that allows employees of varies companies (mostly tech) to post questions and answers anonymously. People generally discuss career decisions, company culture, interviews, and compensation, etc.
I found this platform to be both good and bad. It is good because you get more candid answers/responses and sometimes inside information. It is bad because some people write offensive responses due to the anonymity, and the environment can be toxic at times. You have been warned.
Coursera: Learn about the subjects you are passionate about. It is free or for a very nominal fee. I took both Machine Learning and Deep Learning courses there.
DeepLearning.ai and Workera.ai
- Take the 5 course Deep Learning series, if you are interested in Deep Learning techniques in computer vision (CV) or natural language processing (NLP)
- Pass their screening test to be referred to hiring managers in ML groups in top tech companies
Elements of Programming Interviews Book: This is another excellent interview preparation book, similar to the CtCI book. But it is more geared towards experienced engineers, while CtCI can be read by beginners who have little algorithms background.
GeeksForGeeks: Like LeetCode, this is another website with very comprehensive A&DS questions and solutions. This site is free, and sometimes contains interview questions not found in LeetCode.
- Check a company’s employee reviews
- Find previous interview questions
- Set up job alerts to receive new job updates
Google Search: The starting point for ANY question in life. Do I need to say more?
Internal Employees: Always try to reach out to your friends, or friends of friends, that work in the companies you want to apply to. They will be your most effective informants as well as advocates. Connect with me on LinkedIn, and if you are a good fit, I would be happy to refer you to Google myself, or one of my friends who work at other top tech firms.
- Practice A&DS questions
- Use LeetCode Premium ($35/month or $99/year with coupon) to find past interview questions asked by a given company. I recommend paying for the annual membership. Just think of it as a gym membership for your coding brain.
Level.fyi: This site lists crowdsourced salary information by company, by seniority levels, by location, and by job function, so you will know if you are getting a fair offer from the companies. Of course, this works well only for larger companies, as there are more data points.
- Lookup people’s professional and educational background
- Turn on “Open to new opportunities” setting so that recruiters can find you.
- Use LinkedIn Premium to connect to people who interest you
- Set up job alerts to receive new job updates
- Read tutorials and how-tos to help with your personal projects
- Blog on Medium or elsewhere to showcase your own personal projects
TripleByte: Skip the phone interviews and directly go to on-sites if you pass their tech screening. See detailed description above
- Watch tutorials and how-tos when you work on your personal projects
- Watch System Design and algorithm videos
- CAUTION: Do NOT get distracted and watch hours of videos for fun during your interview prep time
That's all. This is a huge undertaking. But if you put in the time and effort, you can do it.