A framework for crushing Big Tech interviews
A simple framework from someone who learned the hard way
Big Tech programming interviews are about more than just your ability to program, the sooner you recognize that and change the way you prepare, the faster you will get a job.
The key pillars of a Big Tech interview
The programming questions
The random factoid check
1. The programming questions
There is a lot behind preparing for a whiteboard interview. I’ll write a follow up post that will deep dive on this topic soon. (Follow the substack or twitter for updates)
Some resources to get your started until then:
Websites to use: Hackerrank, Leetcode, Pramp
Books to read: Algorithm Design Manual
2. The random factoid check
Sometimes an interviewer will ask you about some random factoid that they are convinced is important to know. Asking questions like this is highly discouraged in big tech, but interviewers still do it. Not handling these correctly can sink your interview all together.
3. The conversation
Most Big Tech companies have a dedicated behavioral interview. You’ll also be having conversations with the interviewer before and after your programming sections. You need to show that you are easy to talk to and that you are knowledgable about the direction the industry is heading in. Ideally each interviewer leaves with the impression that you are more plugged into the industry than they are.
4. Your experience
Knowing how to talk about your experience and make it sound exciting is important. It always comes up and is a great chance to show off and standout.
The Checklist Framework
To make sure you are preparing for all aspects of your upcoming tech interview you’ll want to make some progress on each pillar every day.
I recommend creating a daily checklist and keeping yourself accountable.
Solve a programming interview question
Learn one new factoid about your area
Read one article/document around your focus area
Commit something to github every day
1. Solve a programming interview question
Again there is a lot behind this topic, but the best place to start is to do at least one programming interview question everyday. There are a ton of websites to help facilitate this and make tracking your progress easy. I’ll post about this in the near future.
2. Learn one new factoid about your area
Learn one random fact about anything in your “focus area” and keep a running list of them in a readily available document.
This is a system to defend you against the “random factoid” that an interviewer asks about, it also has the added benefit of helping you standout during an interview, you become the one dropping random factoids instead of the interviewer!
What you’ll realize after about a month or two of learning random little facts is that there aren’t that many random facts to learn. If you’ve been learning little facts for a while, and you still don’t know the random factoid that the interviewer asks about, chances are you know a bunch of adjacent facts that you can spew out, showing them you are still knowledgable in the area.
3. Read one article/document in your focus area
Becoming an expert in a specific focus area isn’t as hard as you think and is critically important to impressing an interviewer. If you don’t have one, it’s never too late to pick one. If you don’t care, just start as a language expert(python,js, c++ etc.). By reading one article or tech document a day on your focus area, you will quickly get up to speed with the latest terminology, trends and learn what new features are available. Within a month you’ll be starting to feel like a "python expert”. This will give you great filler talk during the interview and it will allow you to flex little tricks during the programming section of the interview. When you are clearly very knowledgable about a certain vertical, you get more forgiveness for not knowing about other verticals. Ex. You wouldn’t expect a python expert to know much about how browsers work.
4. Commit something to Github everyday
Even if you are just updating a readme, commit something to github every day. Filling out those green squares on your profile is more valuable than most people realize. Recruiters and devs will checkout your Github, maybe click through one project that you reference on your resume, and leave with a positive feeling if you seem active.
My Github commit history from 2016-2017:
Ideally you are working on some interesting project you are actually passionate about, this will just make you a more exciting candidate. I plan to write a post soon about what side projects you should/shouldn’t work on.
Case Study: How I got my job
2015 - I got an interview at google with 0 engineering experience.
2016 - I tried again, still didn’t get a job at google
2017 - I got offers from Facebook + Google + several smaller companies
2018 - I taught a course on programming interviews
When I initially got invited to interview with Google in 2015 I didn’t make it through the initial phone screen. I really didn’t know much about programming but I wrote an epic cover letter that got their attention.
I studied all of the wrong things between 2015 & 2016, overstudying the wrong topics and understudying the right topics. There wasn’t any structure to my studying, I was just consuming every resource I could and I got denied again at Google in 2016.
Between 2016-2017, I realized all of the resources I’d been using had pieces of the puzzle, but none of them provided a high level overview of how to handle the interview. Thats when I created this checklist system. I followed it for about a year and thats what helped me land multiple job offers. I felt like I was completely in control of the programming interview process. Since then, I’ve helped colleagues and friends follow versions of the Checklist Framework tailored to their history, skills, and desired job. After watching multiple people use this framework and get jobs at Amazon, Facebook and Google, I figured it was worth sharing!
My checklist system in my NYC apartment up until I got the job at FB.
I’m actively tweeting about building LeetDesign, a massive list of interactive system design problems to help you learn system design faster.
If you are interested in the all of the lessons and wacky bugs I encounter building the product, give me a follow: https://twitter.com/DannyHabibs