7 Effective Steps to Cracking the Code Interview

Originally published from Books on Code

There is a reason programmers are prone to imposter syndrome. Failing a technical whiteboard coding interview can be one of the most sobering experiences alive.

Getting tested on data structures & algorithms, taught to you by a dull lecturer years ago, is the foundation of the test. Yet the test is absolutely brutal.

A failed test -- or several -- can cause you to question your self worth as a programmer. But don't.

I am here to tell you that a test is all the coding interview is, and to crack it, you need to study to pass the test.

This is our own version of the Bar exam for US lawyers or the Fundamentals of Engineering Exam (FE), only we get no credential and we are simply being measured against other candidates (which is a relief!). Engineers and lawyers who pass these exams study hard; they don't just rely on their experience. We should approach the coding interview the same way.

Studying successfully to pass this popularly-used whiteboarding coding interview will get you the software engineering job at a top software company, so making the investment in studying is one of the best you can make.

Overview

The seven steps below are based on the popular book, Cracking the Coding Interview, now in its 6th edition. This well-regarded book is monolithic in size and intimidating: 17 thick chapters of grueling interviewing questions as well as additional advice: how to behave during interviews, think about Big O notation, and how to handle offers and rejections.

This book is your friend -- someone to laugh with and cry with over wine, a movie, and a cheap box of chocolates. It's the book you hug in victory as you run up the steps from Rocky, having successfully completed your training.

What this book has to offer is hard work and big rewards.

The advice in this book is coming from Gayle Laakmann McDowell, someone who has seen it all as a software engineer and interviewer at Google. She knows the pitfalls software engineers commonly fall into. She serves as a guide, climbing treacherous and deadly terrain. Listening to her advice is clinging to your liveliness as a software engineer.

7 Steps to Cracking the Coding Interview

I'm excited for you and for the skills you are going to develop. Thorough preparation will give you a wide range of technical and communication skills. It will be well worth it, no matter where the effort takes you.

--- Foreword, Cracking the Coding Interview

Step 1: Practice on Paper

We are spoiled by IDEs, Google searches, and autocomplete. It's possible you have typed a command hundreds or even thousands of times, but when at a plain text editor, a piece of paper, or a whiteboard, you draw a complete blank. When you're on a whiteboard, you have no mental crutch.

This is normal and one of the main pitfalls that makes these exams so challenging.

Cracking the Coding Interview has several recommendations around training your mind for paper when solving problems:

Write the code on paper. Coding on a computer offers luxuries such as syntax highlighting, code completion, and quick debugging. Coding on paper does not. Get used to this --- and to how slow it is to write and edit code --- by coding on paper.

Test your code --- on paper. This means testing the general cases, base cases, error cases, and so on. You'll need to do this during your interview, so it's best to practice this in advance.

Type your paper code as-is into a computer. You will probably make a bunch of mistakes. Start a list of all the errors you make so that you can keep these in mind during the actual interview.

Are you squirming in your seat right now? I know I am. It's crazy to think that we can or must code on paper in order to excel in our careers.

As a mind hack, you can get in the mood of coding on paper by choosing a distinctly separate and delightful place to practice your coding. Splurge on a favorite pen. Light a candle. Brew your favorite hot beverage. Then, think about how nice it is that you get to practice code while away from your computer.

I want to emphasize the last tip, Type your paper code as-is. This is a crucial step. Studies have shown that when we make a guess, check ourselves, and get it wrong, we learn from the mistake and learn faster.

Getting it wrong is one of the best ways to learn.

Throwing ourselves into these problems cold, writing our answers on paper, and being willing to face everything about how wrong we were will put us in the absolute best place for when we face the real interview.

Step 2: Do Mock Interviews

Heed my words: do not skip out on this absolutely crucial step to cracking the code interview.

I'm serious. If you ever think of not doing mock interviews before the real deal (out of fear --- fear of asking your friends or fear of failure), imagine Mr. Resetti, the mole from Animal Crossing, not letting you get away from this.

Recite to Mr. Resetti now: "I will do mock interviews." He doesn't believe you. Say it again.

Now let's look at what Cracking the Code Interview has to say about this:

In addition, try to do as many mock interviews as possible. You and a friend can take turns giving each other mock interviews. Though your friend may not be an expert interviewer, he or she may still be able to walk you through a coding or algorithm problem. You'll also learn a lot by experiencing what it is like to be an interviewer.

Offering to give and receive coding interviews is a great way to help prepare. Reach out to your network. Remember that asking for a mock interview is not selfish. Friends who give or receive tests benefit as well.

If you don't have friends to do mock interviews with, you can turn to the internet. Pramp.com is a free service that pairs you with other programmers to conduct practice coding interviews.

Step 3: Listen to Every Detail

When in your mock interviews (and later, in the real interviews), practice your attentive listening.

Coding interviews are interactive --- an exchange between the interviewer and interviewee. As such, you need to pay attention. Your active listening reveals the intelligence and inquisitiveness they are looking for.

When listening to a problem, you need to pay attention to all of the details. This is like gathering the ingredients to a recipe: you're not using it all in the first step.

When you listen to a problem, you need to be absolutely certain you heard it correctly so that you are not off to the races solving the wrong problem. Ask questions. Repeat it back. Asking for clarification is encouraged.

It is unlikely that the interviewer will give you information that does not relate to the problem.

Cracking the Coding Interview says:

Many candidates will hear the problem correctly. But ten minutes into developing an algorithm, some of the key details of the problem have been forgotten. Now they are in a situation where they actually can't solve the problem optimally.

If you find yourself stuck, ask yourself if you used all of the information in the problem.

But also, if you find you are not using some of the details in your first draft of the solution, don't worry. A necessary step to problem solving is just having a solution --- even if there's some problems with it to start. Your interviewer would understand that you are actively problem solving.

Step 4: Draw a Specific and Sufficiently Large Example

In your mock interviews, as every first step to solving your problem, you need to draw an example. The author of Cracking the Coding Interview cautions that interviewees commonly draw bad examples.

What is a bad example? They are too small and do not sufficiently convey a common case for the problem scenario.

The book illustrates a tree with only two branches: three cells in total. That tree is not sufficient for the problem space.

It is also possible for you to draw an example that later turns out isn't quite right.

But in a technical interview, everything can be adjusted. Go back and fix your example.

Step 5: Design an Algorithm and Optimize

Before you write code in your coding interview, you need to design your algorithm based on your example. And here's where you need to start: you just do it.

Start, even if your algorithm is terrible.

Start, even if your algorithm is so obvious that surely the interviewer will think you're an idiot.

Just do it. A solution --- even a bad one --- is a place to start.

And once you have it in place, you can speak aloud what you're thinking: the ways it is not optimized. And you have a place to move forward and you've taken a step toward wrapping your mind around the problem.

Cracking the Coding Interview has several suggestions to improving your algorithm. These are among my favorites:

Look for any unused information. Did your interviewer tell you that the array was sorted? How can you leverage that information?

Use a fresh example. Sometimes just seeing a different example will unclog your mind or help you see a pattern in the problem.

Use a hash table. Hash tables are widely used in interview questions and should be at the top of your mind.

Step 6: Write Beautiful Code

In order to write beautiful code during your mock or real coding interview, you need to know your algorithm well.

When you have your algorithm planned, you do not need to jump straight into coding. You can take a second to plan the code and to understand exactly all of the steps. Know what the variables are as well as where and when they are going to change.

Cracking the Coding Interview cautions: "Whiteboard coding is slow---very slow. ... If you don't understand exactly what you're about to write, you'll struggle to code it."

To write beautiful code, you are facing the challenge of the board, your own handwriting, and your own neatness --- oh boy. Simple precautions you can take is to give yourself plenty of room and be cautious about writing straight lines.

But beautiful code isn't just how it looks on the whiteboard. Beautiful code is modularized, with error checks, uses other classes and structures, and has good variable names. You can do it.

Step 7: Test Your Code

Once you make your best attempt at writing beautiful code, you are not done! The final step is to 'run' the code and 'debug' the errors using the power of your own brain.

Cracking the Coding Interview warns this is a major pitfall for many interviewers, because running a test by hand takes a long time --- too long. The interview will be over before you have solved the major bugs in your code.

So what then? Cracking the Coding Interview recommends taking a faster approach by first reading the code line-by-line, explaining what each line of code does to the interviewer. Check to see the code is doing what you think it ought to do.

Next, scrutinize any part of your code that looks odd to you. Did you make choices that are not obvious in the code?

Next, check spots prone to error. If you have coded for a long time, you will know where these places are.

Next, actually test with a small test case.

Next, test special cases, such as null or extreme cases.

Finally, when fixing the errors you find, take a second to analyze why the bug occurred and ensure your fix was actually a fix.

Conclusion

Now that you reached the end of these 7 steps, do you feel ready to crack the code interview?

I know. It's like drinking from a firehose.

But there are resources out there to study and gain more confidence. You can find live coding interviews posted on YouTube to see what coding interviews are really like. You can refresh on your data structures & algorithms by watching lectures, reading books (which, I recommend Grokking Algorithms), or taking an inexpensive online class.

---

If you liked this article, share it with the programmers in your life. Use it as a way to break the ice and start doing mock interviews together.

The life of a programmer can be hard sometimes, but you have the support of a community who live and breath the lifestyle of learning and continuous improvement.

If you want to join me on this journey to improvement through code, join the Books on Code newsletter and receive motivational updates about the coding and learning journey.

And with that, I will see you in the next article. 👋😊