How to Ace a Coding Bootcamp Technical Interview
No matter how much you prepare on your own, demonstrating your technical proficiency can be one of the most daunting parts of applying for a coding bootcamp—especially for students coming from non-technical backgrounds. And while most students probably have experience with the other parts of the admissions process from their previous education—non-technical written applications and interviews that just seek to get to know you—a technical assessment is a new scary, prospect. But it doesn't have to be.
Assessing Your Aptitude
First, let's break down the ways coding bootcamps might assess your technical aptitude. Online coding bootcamps like Flatiron School's Online Web Developer Program look to see that you're making great progress coding on your own, either through our free intro courses or other resources. In-person programs, on the other hand, generally rely on some form of technical assessment in the interview process. Coding bootcamps have to cover a lot of ground in a short time span, so we move through curriculum fast. A technical assessment is a way to test whether you're ready to hit the ground running from day one.
Different bootcamps may assess this in different ways, but you're likely to see a process resembling what we do here at Flatiron School for our in-person Web Developer Program. Applicants complete several coding challenges on their own in advance of a technical interview—a live coding session with an instructor—in which they will be asked questions about their prepared work and possibly to expand or change their code to solve new problems. (Sounds like something a tech company would do to interview developer talent? That's by design. We want to prepare you for that process as early as possible.)
Keep in mind: we are not trying to assess how you work under pressure; it's more about determining your ability to learn, communicate what you're learning, and improve in real time… much like what you'll be doing as a bootcamp student, and later, on the job. But even knowing this, many students still approach the technical interview feeling considerable stress. Luckily, there are a few simple steps you can take to prepare yourself and put your best foot forward.
Before your interview:
- Practice talking about your code. Students sometimes get tripped up in the interview not because they don't understand a concept, but because they've never had to describe code out loud before. Grab a friend, your SO, your cat, whoever, and describe your code to them until you feel comfortable talking about it. If you don't have anyone to talk to, be the crazy person who talks to themselves—I promise it will help.
- Have a text editor up on your machine, ready to screenshare with the instructor.
- Turn off all notifications! (Here's how to do it in OS X.) It can be incredibly distracting to get a text from your partner or roommate asking if you brought the milk home while you're walking an instructor through your code.
- Find a quiet space. This is less for the instructor and more for your benefit. The interview will be a high-energy 20-30 minutes. You'll need a space where you can focus.
During your interview:
- Explain your code! In English. Don't just read the code. Go a level above and explain your code. This gives the instructor the opportunity to have a conversation with you about it. Remember: our goal is to teach you. Making this a conversation allows us to give our insights and help steer you in the right direction. So, for example, don't say, "I run this if statement to check to see if the total is less than $500. If that is true, I say 'expensive.'" Rather, say it like you're having a conversation: "OK, so now I do a check to see if the product is expensive at the $500 cut-off."
- Slow down. If you're asked to change your code in a certain way, your first instinct is probably to just start talking. Slow down; breathe. Spend a few seconds thinking through the problem, and then ask clarifying questions. This gives you more time to think of solutions and it shows the instructor your thought process.
- Make it work, then make it right. As you work on your code, don't get tripped up thinking about whether you're choosing the best solution; just get something into the text editor. The act of getting something to work will give you a better understanding of the steps you'll have to take to get to a better solution.
- It's all about iteration. More important than bringing in perfect code that you can't improve on is showing that you can learn from us—and apply that to your code. Being able to iterate on what you've done is actually a better indicator of your aptitude than your initial code. Even if you've brought in broken code but come with the right questions, show what you've tried, and have a discussion with us that leads you to a solution, you're demonstrating that you can learn through our teaching style.
So you're stuck:
- Breathe! Take a few seconds before you answer. No one thinks less of you if you hit a bug or get stuck. In fact, we want to see you confront something you don't know because that mirrors the coding you'll do on the job. We often say: the default state of code is broken—if your code works, you're not programming, you're looking for next piece of broken code to work on.
- State what you know. I'd bet that when you state what you know, you'll discover there's either a hole in your knowledge or a misunderstanding. This is what's called rubber duck debugging: explaining your code in order to better understand it; by saying it out loud, you crystallize it.
- Walk through your code. Don't make assumptions; read carefully. You might find that just like when you're dealing with an essay you're overly familiar with, you might gloss over it instead of truly reading it. Try reading it backward or super close and you'll probably find little mistakes that previously eluded you.
Want to learn more about Flatiron School? Check out their courses and read what alumni have to say on SwitchUp.