Software Engineer's Interview Survival Guide: Grinding Your Way to Whiteboard Interview Confidence

Is This Book Right For You?

Our book is written for software developers with at least one year of full-time professional experience. Here's what we expect you to know already:

If you can do all these things, and especially if you rolled your eyes – then read on. This book is for you.

The "Minimum Effective Dose"

Below, see the skill tree for what is required to get a top-paying software engineering job.

You may be 80% of the way there, just missing the 20% you need to unlock a really easy interview process. These skills are the key to confidence in interviewing.

The mission for this book is to let you breeze through cover to cover, enjoying the journey while acquiring the information – the minimum effective dose – that creates those "a-ha" moments, enabling you to comfortably learn the missing pieces. 

How do I get a top-tier software engineering job?

Broken down, the process consists of getting your foot in the door, providing optimal solutions to a particular company's algorithms questions in 15 minutes per question, and conducting the interview process with the correct social tactics (these might surprise you).

"I find "Whiteboard Interview Practice" unbearably boring."

We use "Whiteboard Interview Practice" as a catch-all term to refer to sites like Leetcode, HackerRank, and Topcoder. Jumping in and trying to grind through is daunting and miserable – unless you do it in a way that consistently builds your confidence and gradually increases your skills, with the finish line always in sight. If you approach the process in the correct way, it becomes fun – starting with foundational building blocks leads you into flow, the intersection of challenge and ability; having a managed plan and systematic process eliminates frustration and uncertainty.

Step 1: Really Learn The Data Structures (there's ~20 of them)

We cover ~20 data structures, and this provides a foundation for the vast majority of interview questions – this helps you avoid wasting time on esoteric data structures that you don't need to know. We teach in a building block fashion. Any programmer is familiar with some of these, but understanding the implementation details creates the foundation that makes the rest of the process easy.

For experienced programmers, concepts like Sets and Dictionaries may seem trivial to use and perhaps a waste of time to learn. Nevertheless, learning how the data structures are implemented at a deep level will set you up for an easy, frustration-free process. This makes interview solutions intuitive to derive and as easy as arithmetic. When quizzed on how much memory and compute time your program uses, you will have an easy time coming up with the answer – and you won't need to waste time memorizing with flashcards.

Step 2: Learn The Foundational Algorithms (Fewer Than 20)

People are often surprised to learn that the tough whiteboard interviews ultimately just boil down to implementing different variations of fewer than 20 different algorithms. These algorithms are much, much easier to learn once you truly understand the data structures. Grokking the data structures will make most of the variations come to you effortlessly and intuitively.

The foremost purpose of the technical sections of this book is breaking down these main algorithms and some of their variants.

.

Step 3: Spend 15 Minutes A Day On Leetcode

Once you have learned the foundations, the process is going to be a lot less frustrating and a lot less boring, and you just need 15 minutes a day – you don't need to complete the entire loop in a day. Some problems require several days of 15 minute effort; sometimes an algorithm makes sense after taking some time away to let the idea digest.

Go to "All Problems", sort in descending order by frequently seen in interviews, and start with the most common problems. Skip the easy problems, the hard problems, and the problems with more downvotes than upvotes. Here's a state machine for how to spend your 15 minutes:

• Step 1: Try to solve the problem without looking at the solution. Limit yourself to 15 minutes. Don't waste more than 15 minutes trying to solve. If you get it done in 15 minutes, great! Check the "Solution" tab or the "Discussion" forums to see if you solved with the optimal computational complexity; if you did, just move on to the next problem. If not, tomorrow, proceed to Step 2. 
  
  
• Step 2: Read up on the answer to the solution. Either reference the "Solutions" tab or go to the "Discussion" tab, search for your favorite language, and find the solution that is most easy to understand. Read it through once and bookmark it. If you don't understand it yet, spend 15 minutes the next day re-reading it. If you have a question, ask in the thread. Once you understand how the solution works, proceed to Step 3.
  
  
• Step 3: Copy down the high level steps onto a piece of paper. Really, use "dead tree" paper: it builds a habit for planning and helps reinforce the information. Then, try to code up a solution just following your high-level steps. If you can't, go back to the solution and rewrite the high-level steps in a way that's more clear. Use pseudocode; don't use code for this. If you can code the problem from scratch, within 15 minutes, referencing your notes on the high-level steps, you're clear for Step 4. Some people might liken this to an "open book test." 
  
  
• Step 4: Try to solve the problem in 15 minutes without referencing your notes. If you fail, repeat Step 3. If you succeed, move on to the next problem.

Our goal is to have you solve 70 problems. This is the sweet spot where you will feel really prepared and confident during interviews.  That sounds like a lot of work...because it is. Most people never pay this one-time cost (pain) and even in a major metro market like San Francisco, top out at $200k or $175/hour. The time to build strong foundations varies depending on experience, but for someone with at least three years of full-time employment, we estimate an upper bound of 100 hours or approximately $10,000 in opportunity cost. This uncertainty of the time investment intimidates a lot of people – and the pain of any learning curve is normal. We're here to strongly suggest that it can be conquered within 100 hours, with tolerable pain, and the typical reward to moving to a top tech company is often a $50k annual comp increase (and that's really a low-end estimate).

Anyway, when you're ready to interview with a particular company, subscribe to Leetcode premium and learn that company's 20 most popular questions – and if you really like that company, learn the top 10 most popular questions.

How do I get the interview with {dream_company}?  I've applied in the past and.... *crickets*.

We explain this in the "How To Run Your Interview Process" section. That's Step 4 and follows easily after mastering data structures, algorithms, and practice problems.

How do I develop excellent interviewing social skills?

Top tech companies are filled with "booksmart" people who aren't naturally gifted with a genius-level Emotional Intelligence, also known as "EQ." This doesn't mean that their employees have low EQ – in fact, most top tech employees (who don't get fired) have a decent if not high EQ. What this means is that they weren't necessarily born with high EQ, but they did the work to develop social skills, even if that implied a bit of "fake it 'til you make it." These skills are learnable, and more or less, boil down to rules of etiquette akin to if-then or switch procedures. We elaborate in the "How To Run Your Interview Process" section, and we describe specific best practices for targeting a particular company.

How do I get through the process as fast as possible?

Really learn the data structures, then really learn the common algorithms. Then practice the frequently-seen whiteboard interview problems.

Commit to spending 15 minutes a day. You're aiming for consistency and forming long lasting habits rather than a heroic grind. That's 15 minutes of either reading through this book on the process fundamentals, attempting to solve a problem, reading up on the problem's answer, or copying down the answer. On days when you have more energy, do more. Keep yourself surrounded with positive people who encourage you in the process – the

If you try to jump ahead in the process, by doing whiteboard interview questions before you've mastered fundamental data structures and algorithms, you're going to get discouraged and end up quitting.

Some people reading this are already lifelong learners and self-improvers who just happen to be struggling, in particular, with the elite tech company-type interviews. For these people, we're absolutely not saying "slow and steady" – it's possible to run through this process extremely quickly, even within a month, if you have lots of previous experience, burning motivation, or innate talent. What we are saying is that a disciplined and methodical approach to completing the interviewing skill tree, which we describe in the next section, is going to drastically reduce the role that luck plays in the process.

But for anyone else, we do want to emphasize "slow and steady." This helps with long-term retention, yes, but building a habit of learning difficult and uncomfortable things should be a lifelong pursuit and it will be needed for advancement once you're in. Having this habit will make anyone a better engineer.

Recap

Learn the foundations and master the skill tree. Make regular, incremental progress. Study efficiently, and invest energy into improving your weak skills rather than drilling skills you're already great at. Once you're ready to proceed, read our guide on how to run the interview process.

Skill Tree

Technical skills

The first technical skill you should tackle is understanding how data structures are implemented, under the hood. This is absolutely required. We teach the data structures necessary to implement optimal solutions to the most frequently asked problems at the top tech companies – and a few that are worth learning simply to expand your "programming muscles".

Once you understand how a Dictionary or an Array is implemented, describing the computational complexity of the various operations becomes really easy and intuitive, like basic arithmetic. Don’t make the common mistake of trying to start by memorizing the complexities instead of learning the implementation and then deriving the complexity from first principles.

For example, you might be tempted to try to memorize the time it takes to look up an item by value in an array, which is O(n). That would lead you down a path of frustration, because there are hundreds of things to memorize when you account for the number of data structures multiplied by the number of different operations (adding, removing, best case, worst case) and then consider sorted vs. unsorted.

On the other hand, once you learn that an array is implemented as a contiguous block of memory, then you know that you need to step through N elements, one at a time, in order to find a particular item.

Even when you get to something as advanced as a red-black tree, if you have learned the fundamentals, it's intuitive to understand. Hence "red-black trees" appearing much later in our data structures skill tree.

The second component of the Technical skills tree is understanding the implementation of fundamental algorithms and their computational complexity. The best way to learn this is to understand how they work, through understanding the data structures involved, and then not memorizing the code implementation of the algorithm but instead memorizing the algorithm through understanding the high-level ideas.

Once you've learned the data structures, it's a lot easier to learn the algorithms because you don't have to do any thinking about the data structures when you study the algorithms.

One secret of these "whiteboard interviews" is that based on the most frequently-asked problems at the top tech companies, there are really fewer than 20 algorithms in total that you have to learn before you should proceed with the interview process, and we're going to explain all of them in this book. Once you learn them, it's just a matter of practice. The goal of your practice should be to develop an intuition of which algorithm to apply to which problem, and which slight modification it needs. The vast majority of problems are variations or subtle transformations of some common algorithm.

I remember studying for calculus, and going to online forums for help, and reading someone's wise post: "Calculus is like a bag of tricks; you just have to have a little practice to develop intuition and judgment to know which trick to apply to which problem."

Interviewing skills:

Once you have done the necessary preparation work on the foundations, the rule "99% of success is just showing up" truly applies. Being comfortable under pressure comes from confidence; confidence is a result of ability; ability comes from experience through practice. You develop the experience through learning the data structures, learning the algorithms, and then practicing the whiteboard interview questions.

Having done the preparation enables you to be fully present in the interview and adapt to the social cues you get. In the "How to run your interview process" section, we elaborate in detail about various cues and exemplary responses; you're getting another flow chart. Sometimes it's obvious you're not doing well; for example, at Apple, a candidate was once presented with a dynamic programming problem (these can be pretty challenging). The candidate had no clue about dynamic programming, but he was up front and honest with his limitations: "I have to tell you that I really don't know dynamic programming, but I have a lot of strengths. I don't want to waste your time, so I would love it if you gave me a different problem that enabled me to demonstrate my abilities." The candidate did well in his other interviews and got the offer.

Other books in this genre can be overwhelming and intimidating. We're going to do our best to break this down into a skill tree, like you might encounter in a video game. Through your career as a developer and general life experience, you may have some of these skills already, so it would be wasteful to practice what you already know. The important thing is to constantly iterate; constantly evaluate which is your biggest weakness, work on it until it is no longer your biggest weakness. Then you re-evaluate, determine which one is your new biggest weakness, and repeat the process of addressing it.

offers the example of elite musicians: the best musicians actually spent the same amount of time on practice as the lesser musicians, but their practice was focused on their weak points. Once musicians learn the fundamentals, including scales and music theory, musicians practice through playing entire compositions. The best musicians would play through a composition and find the parts, such as complex musical phrases, caused them to stumble. Then, they would practice those difficult phrases over and over until they were able to play them elegantly. The lesser musicians had a worse practice method: repeating the pieces end-to-end, wasting time on time on phrases that presented no trouble. Still, all the time the "lesser musicians" spent practicing made them extremely competent and capable.

While technical skills are necessary, they're not sufficient; this is where interviewing skills and culture skills apply. A snarky way to describe "culture-fit" would be "a code word for the current employees being able to stand being in the same room as you for an extended period of time." But taking the time to unpack this a bit, true culture isn't about ping pong balls or foosball tables (sometimes referred to as "cultural confetti"); culture is about what happens when the boss leaves the room. And at good companies, the kind where you want to work, the company's values aren't aspirational or generic tacky posters, but genuine reflection and distillation of the company's culture. So in a sense, culture-fit test is to see whether your behavior is like the other employees' behavior, in how they act when the boss leaves the room. This is because social cohesion is fundamental to human nature. The good news, for the "oddballs" reading this, is that there are some high-end companies that do have a lot of oddballs, and oddballs fit in. It’s not about being charismatic in a “life of the party” kind of way. It’s about expressing yourself professionally, being humble, and having similar skill-enriching habits that make you a better engineer.

In an interview, you might get a hint about how you should be solving the problem (before you've actually finished the solution). That's because you're going down the wrong track, and you should listen – not only has the interviewer seen a bunch of people make the exact same mistake, but it's a test to see whether you're someone who listens to feedback. We discuss all of this in great depth in the "How To Run Your Interview Process" section.

Interviews are not a test to see whether you can think on your feet. They are a test to see whether you can prepare, and preparation for interviews is unpleasant – it requires sacrifice and thinking like an owner, taking short-term pain in exchange for long-term gains. That's why the best tech companies' stock perform so well; the employees often take true ownership of their work.

At big companies, preparing is crucial to being successful in day-to-day work: not preparing and sending out unnecessary questions to a large email thread is wasting perhaps people's time. Same with questions/comments in meetings -- don't waste people's time on explaining things to you that you should already know.

A standardized "whiteboard" interview process is something that's scalable at an enterprise level; it's a repeatable process, with standardized test questions and scripts that can be performed by any trained personnel. Sure, there are companies that don't have a standardized interview process, but dealing with those is a crapshoot, and your salary is constrained by having to interview with one of those companies. Adequately building up the entire skill tree required for success at a top-tier interview reduces variance – it becomes a sure thing rather than luck.

Pro-tip from a former recruiter and a former job applicant: once you go through this process of preparation, if you ever want to accelerate through the interview process, just mention to the Recruiter (or even in your cover letter) that you have solved a lot of Leetcode problems and are a top percentile performer. Recruiters are mostly concerned about bringing forward people who are going to succeed in the phone screens and onsites; they're scared about looking bad. Knowing that you can do the tough coding problems eliminates that concern for them.

A Point to Remember

The stronger you perform in the technicals, the higher your compensation package – without having to negotiate.

If you fail the soft skills, your strong technical skills are not going to save you.

User's Manual: How To Study

Discipline and willpower are finite resources; if one is sad or stressed for whatever reasons, then there's going to be less willpower available. It's pointless to move forward when you're not "feeling it."

But one definition of discipline is your ability to take action irrespective of your emotional state. And mastering the interview process requires discipline. So, commit to 15 minutes a day on the current step in your process; it's possible to succeed with just 15 minutes of daily effort even though it might take you many, many days. It's certainly doable.

If you're a developer late in your career, there's an understandable emotional feeling of wanting to "make up for lost time." This is completely normal, but the fact is, rushing the process is going to make it fail.

We define being "minimally ready" as knowing the fundamental data structures, knowing the most frequent algorithms, and having canned answers to the most frequent soft skills questions. Completing the entire skill trees we've defined makes you ready in a way that is robust. Forcing yourself to interview at a top tier company before you're "minimally ready" is one of the surest ways to both guarantee failure and also get discouraged – but applying to companies that are less interesting to you, and going through the process, is a useful way to refine your technical and interpersonal interviewing skills.

Even on days when you're not feeling it, follow the flow chart and go through the motions for 15 minutes – that's valuable. If you have more energy, go for longer. The point is that your goal should be building the daily habit of practice, not necessarily counting minutes invested. Having a daily habit will lead to eventual success; spending 15 or 45 minutes on any given day makes no difference in the medium/long term.

Through writing this book, and the feedback of our helpful early readers, we've ruthlessly forced ourselves to write everything that you need to know and remove what you don't need to know.

So, some sections are going to be things you already know. If you need to quickly check whether you already know it, just read the first sentence of each paragraph and the last sentence of each paragraph. If it doesn't feel like there's any new information, just move on to the next paragraph.

Spend 15 minutes a day

You're going for consistency, not perfection. If a recruiter contacts you and you feel a sensation of "FOMO" or "fear of missing out", don't let that get to you. Later in the book, we explain why the recruiter is incentivized to make you feel that way. The time to interview with the top companies is when you're ready; you're ready when you've mastered the foundations – data structures, algorithms, whiteboard interview problems, and interviewing skills. If you fail, you often have to wait 18-24 months before you can re-interview.

It's okay to suck; it's not okay to skip

If you struggle with making it through some material, it's not because you're dumb. Either we failed to make it simple enough to understand (please send us feedback) or because it's simply intrinsically hard.

Tim Sweeney, the founder of Epic Games, is one of the most successful programmers in the world. He developed the Unreal engine and built the organization that made Fortnite. He is extremely and deeply technical, spending lots of time working in C++ on highly mathematical optimizations.

Even he said, on Twitter: 

"I had to switch programming languages twice before I fully understood recursion."

Okay? So even the greats had to struggle with some of the foundations stuff. The key to succeeding is by consistently moving forward, whether that's through repetition or trying a somewhat adjusted approach.

There's a reason we designed this the way we did

This book is designed to be read end-to-end. We start with the fundamentals, and subsequent sections build on those ideas. If you're overwhelmed, just commit to reading 15 minutes a day. If you read 15 minutes a day, and that 15 minutes can be spent rereading or posting a question online about something you read, or doing a bit of research, you are going to eventually get through to the end.

Rome was not built in one day. The top tech companies are filled with people who spent a long time trying to break in. Rushing the process is only going to slow you down. Here's the good news: learning the advanced concepts, including how to solve whiteboard interview questions under pressure, is a lot easier, and not at all tedious, once you have a handle on the fundamentals. In fact, it even becomes fun because "flow" happens at the elegant intersection of challenge and ability. You can learn algorithms easier once you've learned data structure because it's easier to encode less information into memory – there's less of it to chunk.

For example, let's take the concept of "3 * 2". If all you know is counting and addition, you might try to memorize it as "(1 + 1 + 1) + (1 + 1 + 1)", which is 3 repeated twice. Or you can go the much faster way and memorize the shorthand of "3 * 2". But that requires you knowing what "3" is, what "*" is, and what "2" is. Chunking is the ability to mentally parse patterns into small reference bits, rather than storing the details of the entire pattern in memory. Think of it like compression. The canonical example to explain “chunking” in pedagogical texts is the example of driving. A beginner driver thinks of driving in terms of many activities - speed, gas pedal, steering, mirrors, brakes, etc. An experienced driver thinks of driving as a single activity - all the various components of the act of driving have been “chunked” into memory. Similarly, this book aims to help you build more robust “chunks” so you can see patterns in coding problems and think from a higher level perspective. This is why we offer such strong insistence that you need to master the data structures themselves.

As you progress, studying is going to get easier and easier, since your "chunk database" is going to expand and you can encode more information with less effort.

Repetition is the mother of learning

Memory works through neural associations – for example, if you study while caffeinated, you're going to have better recall while you're caffeinated. If you study in one room of your house, you're going to have better recall when you're in that room of the house. A popular study on this involved showing a pattern to divers while they were submerged; they then split the group up in two. One group tried to recall the pattern underwater and the other tried to recall on land. The underwater group showed better recall.

When you're studying, your brain isn't only encoding the information that you're studying. The body can't help but also encode the other information you're taking in, such as the furniture, and it stores that information with the memory. So, seeing the furniture acts as a "recall cue" or a "pointer" for you to access the memory.

If you want to form a more robust set of memories, study in different locations; that way, you'll have a more diverse set of "recall cues" and "entry points" for you to remember the information. Studying at different times of the day will also help.

If you use caffeine, try studying with and without caffeine, because the caffeine affects how the memories are encoded – but if you always use caffeine, then make absolutely sure that you are caffeinated before you interview! Try studying during different times of the day.

You may find it helpful to teach someone else something you recently struggled with. After all, the best teacher is one who empathizes with the challenges of a beginner, and teaching others is a forcing function to see whether you really understand the material. If you have no potential student, you can always explain the concept to the mirror.

Ask For Help

We encourage you to reach out and ask us for help at any time (thecodingteacher@gmail.com). We confess, we have our selfish reasons. One, we can take your question, make it anonymous, and turn our response into a blog post. Not only does it benefit the greater community (for every person who is scared to ask a question, there are others who suffer in silence), but this is helpful for SEO and marketing reasons. You can even use a throwaway email address to send in your question. Two, it's a lot easier to write a response to an email than it is to an empty writing prompt. Three, it gives us the opportunity to improve the next version of the book