Bootcamp Prep Technical Interviewing

Technical interviews are where the magic happens. It’s where you get to meet potential teammates and collaborate with other developers to solve problems.

Interviewers may approach the tech portion differently but the objective is always the same: assess whether you are the right person to join their team.

No need to worry though. You’ve been coding for months and now it’s time to show off those skills! Let’s go over the different formats and how best to prepare.

Formats

There are a number of different formats for technical interviewing. You may encounter one, some, or all of these formats during your interviewing journey. Every company interviews in a different way. Some may start with a code challenge while others start with whiteboarding and save the code challenge for the end. Be ready for anything!

Here is a list of the types of interviews you can expect and should be prepared for.

  • Coding challenges
  • Technical phone screens
    • Trivia
    • Pair-programming
  • In-person technical interviews
    • Trivia
    • Whiteboarding
    • Pair-programming

Coding Challenges

We have a whole other lab on coding challenges so we won’t get into details here but the gist is a company will send you a “take home” challenge where they ask you to build an app in an allotted amount of time, sometimes in a specific language, sometimes in a language of your choice.

Technical Phone Screens

Typically there are two types of technical phone screens:

  1. Trivia: essentially a Q&A session. The interviewer will quiz you on terminology:

What’s the difference between == and === in JavaScript?

What does MVC stand for and how does it work?

To do well, you’ll need to study. An easy way to find interview questions is simply to google Interview Questions <Language> with being whichever language the job requires (e.g. Ruby, JavaScript, etc). You can, and should, also read technical books like:

Note: this style of interview is a relic from the past and is becoming less common than pair-programming, but still exists (and you should still be prepared for it!):

  1. Pair-programming: sites like CoderPad have recently enabled remote developers to share code in real-time. This has shifted technical interviewing from the Q&A format to a more collaborative exercise.

Typically, the interviewer will ask you to solve an algorithmic problem and ask you to code a solution (just like how you solve labs). You’ll be able to view each other’s code on-screen and make edits in real-time. If you get stuck, they’ll likely give you hints. If you finish quickly, s/he might ask you to optimize your answer and do even better. What s/he’s doing here is implicitly asking you about Big-O and how efficient your solution is. Make sure to read up on Big-O notation.

The point of pair-programming is to gauge how you solve problems, how you communicate, and how easy it is to work with you.

You should feel comfortable Googling anything you need to. The interviewer will stop you if it’s not okay. Always try.

Both formats are typical for first-round interviews and usually last 30-60 minutes.

In-Person Technical Interviews

In-person interviews tend to come later in the process once you’ve passed a phone screen and/or completed a technical phone interview or code challenge. In-person technical interviews are often a mix of trivia and whiteboarding or pair programming.

  1. Trivia we’ve already covered. Instead of being asked over the phone or Hangout, you’ll be asked questions in person.

  2. Whiteboarding:

This is the most traditional type of technical interview and is where you are asked to solve an algorithm question using a marker and a whiteboard. You might be asked a question like:

Given an array_of_ints, find the highest_product you can get from three of the integers.

Then you stand at a whiteboard discussing the right solution with your interviewer while writing out the code by hand. Interviewers want to see that you can code the solution without a computer and communicate effectively.

If you can’t remember the method to return the first item in an array and remove it, just ask. It’s not a memorization problem.

Feel free to have magic methods that remove some of the incidental complexities. For example, if I was designing an algorithm to find if a number was prime, and I needed a method to find if a number was divisible by 1 through 10, I would just say “ok I have a magic, is divisible method.” Sometimes they will say no go and implement that, other times they’ll be fine with it.

Pro-tip: Be vocal! Walk your interviewer through your thought process and ask questions throughout the process to ensure you fully understand what’s being asked of you. A big piece of critical feedback employers often have is that candidates don’t talk enough in technical interviews

  1. Pair-programming.

    Pair-programming we also covered earlier but this time it’s in person. An added bonus here is that you’ll develop a strong understanding of what it might be like to work with that person.

Admit When You Don't Know Something

When you’re stumped, try and compare it to something you do know (e.g. “So Tree Maps are like Hash Maps, let me talk about hash maps...”

If you come across an algorithm you don’t know and you are asked to implement it, ask your interviewer to explain it, then do your best to directly transfer what they said into real code. Don’t do any optimizations the first time around.

If you simply don’t know the answer to a question, be honest and admit you don’t know. Don’t lie or try to BS your way through it.

Interviewers already know the right answer before they ask you the question.

A graceful way to answer is, “I’m sorry, I don’t know the answer to that but I’ll take some time to learn about it after this interview”.

What to Do If You Make a Mistake (Stay Calm)

It’s likely you’ll make a few mistakes during the interview.

  • You might have a syntax error when you run your code during the pair-programming portion.
  • You might not know the answer to one of the trivia questions.
  • You might run out of space while whiteboarding.

There a million other things that might go wrong. Interviewing - technical or otherwise - is stressful. The trick to doing well is staying calm and maintaining your composure.

Every developer knows that you don’t just wake up one day, build an entire application from scratch, and run it without a single bug. Real-life development is iterative and you’re allowed to make mistakes in an interview so don’t beat yourself up if you get something wrong.

If you don’t know the answer to one (or some) of the trivia questions, that’s okay. Just admit you don’t know and the interviewer will move on.

You might have been asked an ambiguous algorithm question and don’t know where to start. The interviewer may have done that intentionally. Don’t be afraid to ask questions and probe for more information. It’s also okay to take a minute and think about the problem before you attempt to solve it.

Last but not least...

Have Fun With It

Junior developers often get anxious when it comes to technical interviews. It’s normal. You may feel like you have a lot riding on the interview but the best way to succeed is to have as much fun as you can.

Treat technical interviews as if you are already on the team. Ask questions like you would in your group projects. Treat your interviewer like s/he’s your partner and you are collaborating to build a fun new app.

If you think of tech interviews as less about being evaluated and more about working with another person, you’ll remove any doubt you had and end up exuding the passion for problem solving that got you into coding in the first place.

Knock ‘em dead.

View Bootcamp Prep: Technical Interviewing on Learn.co and start learning to code for free.

Unlock your future in tech
Learn to code.

Learn about Flatiron School's Mission

With a new take on education that falls somewhere between self-taught prodigy and four-year computer science degree, the Flatiron School promises to turn students with little programming experience into developers.

In the six months since the Manhattan coding school was acquired by WeWork, it has spawned locations in Washington, D.C., Brooklyn, and London. Now, WeWork is opening a fourth Flatiron School location, this time in Houston.

Adam Enbar, Flatiron School's cofounder, believes now is the time to grow. "How the world is changing has impacted working and learning in very similar ways. We think education fundamentally is about one thing: enabling people to pursue a better life."

Learn. Love. Code.
Students come to Flatiron School to change their lives. Join our driven community of career-changers and master the skills you need to become a software engineer or a data scientist.
Find Us