Blog articles

5 Ways to Practice for a Coding Interview

By Pluralsight    |    December 01, 2015

Interviews for programming jobs aren’t like most interviews you hear about. There’s less, “What is your greatest weakness?” and, “Why are you right person for the job?” and way more code — lots of code.

That’s right, software engineering interviews involve writing code on the spot, right in front of your interviewer. And if that sounds terrifying to you, you’re not alone.

The best way to conquer the fear of coding interviews is to get really, really good at them. And it can be done! It just takes careful practice. So today I want to share 5 ways you can practice and some advice for acing each and every interview.

1. Write code on a piece of paper or whiteboard.

From my experience, most companies will have you write code on a whiteboard during the onsite interview.

If you’re not used to coding on a whiteboard, it’s quite awkward at first. You have to write out every single character, you can’t easily insert new lines or delete whole blocks, and you don’t have the helpful highlighting you’re used to from your favorite code editor.

So iron out that awkwardness before your interviews. Run a few practice problems on a piece of paper or, if you can, on a real whiteboard.

Once you have the code hand-written, try debugging it. Run through what it does, step by step, and look for errors. Then, type it up and actually test it.

2. Read up on language-specific trivia.

Interviewers love asking trivia about coding languages. But don’t stress out — they usually won’t throw you questions about languages you don’t know. The general rule is that any language listed on your resume is fair game, but most interviewers will focus on the 1 or 2 languages you state as your most comfortable.

For web engineering jobs, folks love to ask about JavaScript trivia. Last time I interviewed, I was asked about JavaScript closures 3 times! People also like to ask about hoisting and the JavaScript object model.

For Python folks, interviewers love to ask about the global interpreter lock, or the difference between Python 2 and Python 3. For Java, it’s the difference between string literals and String objects. And for Ruby, it’s some fanciness with .inject().

The idea behind the questions is the same — to see whether or not you understand the quirks and specifics of the languages you use. This helps the interviewer gauge if you’re the kind of engineer who thinks not just about writing code, but about writing good code.

The good news is there are plenty of language-specific coding interview question lists available for free online, and a quick Google search will turn up lots of options to look through and help prepare you.

3. Don’t be afraid of algorithmic thinking.

Many interviewers like to focus their questions on algorithm design. What does that mean exactly? That means writing code that not only works, but works efficiently. An important (and great) tool for this is Big O notation — and if it’s new to you, you’ll want to practice it.

It’s tempting to skip this algorithmic problem-solving piece altogether — especially if it’s new to you — and I see so many candidates make this mistake. And remember, it doesn’t matter if you’re interviewing for Google or a small start-up — many small shops like to talk about algorithm design just as much as the big guys.

If this stuff is hard for you, you’re not alone. This is the hardest part of coding interviews for most candidates, even folks who have a computer science degree. But you’ll find that Big O notation and algorithm design come together more quickly than you’d think. On top of all that, and maybe most importantly, it really will make you a better engineer. It totally changes your relationship with coding. Eventually you’ll find that you can rigorously reason through whether your code is the best solution to a problem.

4. Write down your mistakes.

Grab a fresh notebook. After each question you try, look back and ask yourself, “What did I get wrong about this problem at first?” In other words, what did you learn? For each question, take the time to write down 1 or 2 things you learned.

After each practice session, read through your whole running list of learnings. This adds a nice layer of rigor to your practice, so you remember things to fix for next time. You’ll be less likely to repeat the same mistakes and, eventually, checking for those things will become second nature.

5. Schedule lower-stake interviews first!

The very best practice for coding interviews is other coding interviews. The more you do, the better you’ll be. So, if possible, don’t interview with your #1 choice company right away — schedule a few others first to maximize the practice you get ahead of time.

Apply to several companies at once. It means more practice, and if you’re lucky enough to get multiple offers, it gives you more negotiating leverage! Lots of companies can be found and contacted quickly on sites like WhiteTruffleAngelList, and Hired. But remember, don’t overdo it — you don’t want to waste anyone’s time. Let yourself be open to opportunities you might not initially consider during your search (after all, my last job was at a company I wouldn’t have considered if I hadn’t found them on AngelList!). Most importantly, just remember to have confidence in yourself and your skills — pair that with plenty of practice, and interviewing will be a piece of cake.

About the author

Pluralsight is the technology skills platform. We enable individuals and teams to grow their skills, accelerate their careers and create the future.