How to Ace a Coding Bootcamp Technical Interview
Updated 6/2/21: Flatiron School no longer requires a technical interview. Instead, students will take a 15-minute admissions assessment. Read this article about how to pass the assessment. 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 — […]
Updated 6/2/21: Flatiron School no longer requires a technical interview. Instead, students will take a 15-minute admissions assessment. Read this article about how to pass the assessment.
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. 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, slightly scary, prospect. But, technical coding bootcamp interview questions it doesn’t have to be.
Assessing your aptitude
What is a technical review?
First, let’s break down the ways coding bootcamps might assess your technical aptitude. Online coding bootcamps like Flatiron School’s Online Software Engineering Bootcamp look to see that you’re making great progress coding on your own, either through our free Coding Bootcamp Prep or other resources. In-person programs, like our immersive Software Engineering course, 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 like Flatiron School's technical interview 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 Immersive Software Engineering Bootcamp or immersive Data Science course. Applicants complete several technical coding challenges on their own in advance of a technical interview—a live technical 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. If this sounds like something a tech company would do to interview developer talent, it’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. However, the technical interview can lead to considerable stress for many students. Luckily, there are a few simple steps you can take to prepare yourself and put your best foot forward.
Before your Flatiron technical interview:
Practice talking about your code. Students sometimes get tripped up in the interview 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, talk to yourself in a mirror—I promise it will help.
Have a text editor up on your machine, ready to screenshare with the instructor.
Turn off all notifications! It can be incredibly distracting to get a text from your significant other about dinner 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 Flatiron School technical 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 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 and 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. At times, it's better to 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 ask 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 technical 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 backwards or super close and you’ll probably find little mistakes that previously eluded you.
Disclaimer: The information in this blog is current as of 26 October 2018. Current policies, offerings, procedures, and programs may differ. For up-to-date information visit FlatironSchool.com.
Posted by Amanda D'Avria / October 26, 2018
Learn to Code Python: Free Lesson for Beginners
Eric Saber: Professional Organizer to Product Designer
Eric Saber admits to taking a winding road to design. Beginning in business, he was a professional organizer, before finding his way to tech.