I’ve rarely heard of anyone quitting a job before they had another job offer already lined up. Any time you see a coworker sending out a “Farewell!” email to the entire engineering organization, the first question you ask them is: “So where are you going now?”.

I’ve switched jobs twice so far—and both times I’ve prepared for the technical interviews while working full-time. I’m guessing from your question that you’ve already discovered that it’s very difficult to continue outputting what you usually do at work, while studying up for the technical interviews.

As someone who completed going through the entire interview cycle with six companies less than half a year ago (Google, Facebook, Apple, LinkedIn, Uber, AirBnB), I can let you know what I did to prepare and how I paced myself to prepare in time for interviews.

First, in order for you to be able to prepare, you have to know what to prepare for. Every interview I’ve ever gone through in my eight years of industry experience have been…pretty much the same. I completed a cycle of interviews in 2009 (when I graduated from undergrad), in 2012 (when I switched companies to join Box), and in 2017 (when I ended up joining Google). Supposedly at some point, I’ll start getting different interview questions because I’ll have enough years of experience, or be “senior” enough (I was a “Staff” level engineer at Box, which is the one above “Senior”) to merit non-whiteboard-coding interview questions. But I haven’t reached that yet.

Anyhow, if you’re in the similar position as me, you’ll get the following breakdown of interview questions (for the onsite):

• 3–5 algorithms questions (e.g.: find the maximum sum of any k contiguous elements of an array, write a function to serialize and deserialize an imbalanced binary tree, find the minimum distance to get from point a to point b in a directed graph)
• 1–2 design questions (e.g.: design Facebook newsfeed, design a url shortener, design Google docs)
• 0–1 other programming questions (e.g.: implement a circular buffer with raw only arrays)
• 0–2 cultural/personality questions (e.g.: talk about a time you resolved a disagreement at work, what are you looking for in your new job?)

All six companies I interviewed with adhered to this format (as of 2017), and that preparing for one company is as good as preparing for all of them — because their interviews are essentially the same.

If your time is limited (whose isn’t?), I would focus almost all of your energy on mastering the algorithms questions. Not only because they are the largest segment of your interviews, but also because it’s the only skill that you almost never use in your regular job (probably) and consequently will be the least prepared for.

I design systems all the time at work. I think hard about what type of data structures to use, and how to tweak existing ones to be optimized for a particular implementation and usage. I also deal with personal conflicts all the time, and have a huge bank of stories to tell regarding work-drama and conflict resolution. What I NEVER do, is solve how to find the largest palindromic substring in O(n^2) time and O(n) space. I imagine most software engineers don’t.

I could dedicate a whole blog post talking about how ridiculous it is that in 2017 we are still giving engineers (who have several years of industry experience) white-boarding algorithms questions and using that as the primary indicator of technical talent. This particular topic has been ranted over several times already on the internet, so I’ll spare you from another rendition of it.

But if you’ve set your heart on joining one of the top-tier tech companies, and have succumbed to being ok with winning inside the system rather than protesting against it, then you’re in luck.

The exact thing that you will do on the day of your actual interview is 100% repeatable, and practicable in your own home, on your own time. The resources and practice problems available for you to perfect your technical interviewing skills is vast and mostly free—and they very much accurately reflect the questions that get asked in real interviews. I’ve done phone screens and on-sites with six companies, which amounts to something like 30 technical interviews (each about 45 minutes a piece); I can attest to the fact that the practice problems you'll find on the internet will prepare you for the interviews well. I firmly believe that anyone who is already proficient at coding can pass the technical interview gauntlet at any top tech company given that they prepare for it. You just need to suck it up and practice.

Your preparation for ALL of the algorithms questions can be covered by LeetCode.com. LeetCode really is, your one-stop shop to preparing for the algorithms questions. I solved the first 175 LeetCode questions to prepare for my interviews — and I did very well on the interviews. You won’t need to solve as many as I did— I was over-prepared if anything. If you complete 100, you’ll be very solid. Don’t skip the ‘hard’ ones to only do the ‘easy’ and ‘mediums’. Do them all.

I highly recommend investing in a whiteboard. Coding on a whiteboard is nothing like coding on a text editor. Rectifying a mistake, or changing your mind on the approach of your solution, on a text editor is completely fine; doing the same on a whiteboard is completely unforgiving. You should get used to coming up with short, but somewhat descriptive, variable names (writing long words over and over on a whiteboard is not only tiring/slow, but also makes you run out of space real fast). Get used to your shoulder/arm being tired for holding it up for so long while writing on a whiteboard. Gain good judgment on how much space/room you need to implement some functionality; sometimes you want to jump around implementing different parts at different times, and having the spacing correct can be really clutch here.

When I was preparing, I’d read the question off of LeetCode and I’d try to implement it on a whiteboard. When I’d convince myself that I had a working solution on the whiteboard, I’d copy my solution into LeetCode’s text editor and submitted the solution to see if I passed all of their crazy performance requirements. If I only passed the correctness tests, but not the performance tests, I’d rethink my approach and start the question from scratch on the whiteboard. And then repeat, until all of my LeetCode tests passed.

During my more intense weeks, my preparation schedule looked something like this:

• Solve one LeetCode ‘medium’ problem in the morning before going to work. Or two ‘easies’. I never was able to solve a ‘hard’ problem in the morning.
• Solve two LeetCode ‘mediums’ after work, or one ‘hard’. One LeetCode ‘hard’ takes a LOT longer than two ‘mediums’ combined FYI — but it’s just the rule I came up with myself.
• Solve ~15–30 LeetCode questions (mixture of all three difficulties) on a weekend.

I started preparing for interviews about a month before my technical phone screens. I scheduled all six of my onsites about a month after my phone screens. It was a tough two months, but it left me super prepared.