Common Issues In Coding Interviews

Getting stuck during a coding interview can be really demoralizing. That is, until you get good at getting un-stuck. That's right, you can get good at getting un-stuck! You just have to learn the steps.

But surprisingly, sometimes you're supposed to get stuck, and sometimes you're supposed to lose your train of thought. To understand why, read up on how the coding interview is like a maze

Of course, with more practice you're less likely to get stuck or lose your train of thought. Check out our practice coding interview questions.

Finally, make sure you're doing everything you can to get yourself into the best possible headspace in the 24 hours before your big interview.

The trick to finishing problems faster is using a specific process and sticking to it:

1. Brainstorm and design your algorithm by manipulating sample inputs by hand on the whiteboard. Don't start writing code until you know exactly how your algorithm will work.
2. Code it up as quickly as possible. Don't get caught up in details like, "should this be a '<' or a '<='?"—just make a checkmark in the margin and move on. Don't start debugging it until it's all written out.
3. Finally, walk through your code with a sample input and fix any bugs you find.

The important lesson here is to never skip ahead. Only move on to the next step after finishing the last step. This keeps your thinking more organized, makes it easier for your interviewer to follow what you're doing, helps you avoid mistakes, and ultimately makes you move faster.

This process is explained in more detail in our general coding interview tips article.

You're probably making a common mistake with how your practice is structured. Is this you?:

You pull up a practice problem, work on it, get as far as you can . . . until you get stuck. You give up and look at the answer.

"Whaaat?? How do you even come up with something like that?"

You understand what the answer is, but you have no idea how you could have gotten there yourself.

That's the common mistake. Simply looking at questions and answers isn't enough. You need to learn how to derive those answers yourself.

That's why with Interview Cake, each of our questions walks you through the thought process for coming up with the answer, including a review at the end where we pull out the generalizable lessons that can be applied to solving other questions.

Whether or not you use our full course, there are plenty of other small things you can do to make sure you're getting the most out of your coding interview practice.

A lot of people struggle with data structures, algorithms, and big O notation. Especially people who don't have a computer science degree.

It's easy to think this stuff is just objectively hard to understand, since it's associated with the "academic" side of software. That makes it seem more technical and difficult.

The truth is this stuff just feels technical and difficult because people are bad at teaching it.

Yes, thinking in algorithms and data structures is a specific skill that's different from general coding. It's a separate thing you have to learn.

But it's very learnable. Check out our Intuitive Guide to Data Structures and Algorithms.

This feeling is very common. The interview process makes us doubt ourselves. It eats away at our confidence. This is called impostor syndrome, and it can be fixed.

Disclosure: some of the services below give Interview Cake a kickback if you end up using them.

Probably the easiest way to get interviews is to use one of these services that bring companies to you:

• Hired
• Triplebyte
• Underdog.io

These services are really selective though, so not everyone gets in.

Then there are a bunch of hip job board sites. These make it super easy to cast a wide net—just pick a bunch of companies that sound interesting and apply. They also let you do stuff like set up email alerts for jobs that might interest you.

• AngelList Jobs
• Whitetruffle

For the companies you already have your eyes on, try to get a referral from someone inside the company. This is doubly important for the big names like Google, Facebook, Amazon, Microsoft, etc. Big companies weigh referred applicants more heavily.

Search your LinkedIn and your Facebook to see if you have a friend who can refer you. Ask your family members if they have anyone in their network. If you went to college, ask your school’s alumni services to find an alum who can refer you.

Here's a trick to getting interviews for jobs that require knowledge of a fancy new language or framework: ignore the job description and apply anyways.

One month after Apple announced their new programming language Swift, there were job listings that asked for a minimum of three years experience with Swift. Which was impossible.

A lot of description text is just boilerplate. Don’t let it keep you from applying.

The people putting job descriptions together often don’t know what all the specific technologies mean. They tend to pepper them with the latest buzzwords. It happens in every industry.

Many of these places will put good faith in your engineering skills. They’ll trust you to learn whatever languages or frameworks they use.

One more tip: Don’t apologize for not knowing the hip new thing. It reveals that you think you're underqualified, which biases your interviewers towards thinking you're underqualified. So focus on sounding interested rather than apologetic. "I haven't had a chance to work with Rust yet, but I've heard some cool stuff about it!"

Short answer: probably longer than you think.

Long answer: It depends.

The best way to deal with exploding offers is to avoid them altogether by carefully structuring your coding interview timeline.

That said, once a company has given you an exploding offer, you have two options:

1. Just work within the exploding offer's timeline. In other words, do nothing.
2. Ask for an extension.

You're likely to have better luck asking for an extension if you give a specific date you want to extend to. From the company's perspective, they mostly just want to have some date they can trust they'll have an answer by, so they can plan the rest of their hiring process.

Behavioral questions or "soft questions" are an important part of the interview. Your interviewer might ask you something like:

• "What's the biggest project you've shipped?"
• "What's your favorite programming language? Why?"
• "How do you overcome interpersonal conflicts with coworkers?"
• Or just an open-ended, "Tell me about yourself."

Nailing these questions can be a big differentiator. If you wanna wow your interviewer, check out our article on telling stories for behavioral questions.

For most of us, saying, "I should spend a few hours practicing for coding interviews each week" just doesn't work. Whenever there's a spare hour, it's suddenly really important to send some emails. Or do laundry. Or do some other "productive" bit of procrastination.

The fix is to pick a specific, regular time for your interview practice. Block it off and stick to it.

An hour a day, or a few hours over the weekend. Just pick something you can actually commit to.

Open up your calendar and do it right now.

Couple more tips:

• Try going to a cafe or library. The ritual of going to a new place tells your mind, "Okay, we're going to a specific place to do a specific thing now."
• Grab a pen and paper to write your code on. This is good practice for coding on a whiteboard, but it also helps you focus in on the task at hand.
• If you're using our course to practice, consider using the browser on your tablet instead of your laptop—again, it's less distracting.
• Leave your phone at home, or put it in airplane mode while you're practicing.

Not all programming interview practice is made equal. There are a lot of things you can do to make sure you're getting the maximum possible benefit out of your practice sessions. Check out our guide to getting the most out of your coding interview practice.

In general, a coding interview is about 45 minutes of problem solving. Sometimes you'll get a few short technical questions, but usually you'll only dig into one complex algorithmic coding interview question (like the ones in our course).

So, 45 minutes per question is a good rule of thumb. But don’t worry too much if you’re taking longer to finish our practice questions—you’ll get faster with time. Stressing about the clock usually does more harm than good.

Yes! There are a few great websites that offer mock interviews as a service. Check out:

• Interviewing.io (free)
• Pramp (free)

Or you can grab a buddy and organize some mock interviews yourselves.

For phone interview practice, do it over the computer. Use a shared coding environment tool like CoderPad, and actually talk to each-other over the phone or through Skype (great opportunity to test that your laptop's microphone works!).

For onsite interview practice, whip out some paper and pencils or, better yet, actually get on your feet and write stuff on a whiteboard.

You can even run a mock interview with a nontechnical friend! Try loading up one of our practice questions on a laptop or tablet—the progressive hints and gotchas allow your friend to use the page like a script.

And of course, real interviews are very effective as "mock interviews" :) Reach out to some more companies and try to get some extra interviews.

There's a lot to say about this, and getting yourself into the best possible headspace the day before a big onsite can make a huge difference!

Read our full guide on what to do in the 24 hours before a big onsite interview.

And check out our guided meditation for visualizing yourself breezing through a day of onsite interviews.

This is pretty common, and it can actually be a big problem. A messy whiteboard makes it more likely that you or your interviewer will get totally lost trying to understand your code, especially when you come back to it a few minutes later to walk through it with a sample input. Here are some tips:

Start in the very top-left corner of the board. Most people's instinct is to leave some margin on the left and top of the board, so their code comes out "centered." But this just ends up leaving you with less space. And you want all the space you can get.

Leave blank space between each line as you write your code. This makes it much easier to add an extra line later.

Take an extra second to carefully name each variable. Don't rush this part! It might seem like this'll slow you down, but using more descriptive variable names actually ends up saving you time in the end. Few reasons why:

1. You're less likely to confuse your interviewer, which means you don't have to waste time explaining things.
2. You're less likely to confuse yourself, especially later on when you go back and walk through your code with a sample input to see if it works.

Rejection happens. It’s an ugly reality of the interview process. If you can afford to, take a brief break from your studying so you can come back fresh.

The good news: You’re better at interviewing now. Sure, running practice questions is good preparation, but actually getting out there and failing some interviews is great preparation. Nothing approximates real interviews quite like other real interviews!

Reach out to the company and ask for feedback. Some companies can’t do this for legal reasons, but it never hurts to ask.

Keep in mind that rejection can happen for any number of reasons. There’s definitely an element of randomness. A lot of Google engineers feel there’s only a 50-50 chance they’d get an offer if they went through the interview process again.

Sometimes company priorities change, and they decide they need to slow down hiring. Sometimes you just get unlucky and get the interviewers who like to give low ratings.

There’s lots you can do to prepare, but there’s also lots that you can’t control. The best you can do is keep showing up and slowly getting better!