If you’re thinking about going into software development, you’ll eventually have to get real comfortable with technical interviews. For those of you considering applying to a coding bootcamp, chances are high that this will be your first foray into technical interviews. A lot of expectations such as thinking out loud or even typing code while someone’s watching will seem foreign at first. This is perfectly normal, is not negatively indicative of your success, and is actually out of the ordinary if you don’t feel this way!

After I decided I wanted to pursue a career in software development, every day at my previous job felt unfulfilling. I wanted to dive in as quickly as possible and a bootcamp was the perfect way to fill in the missing knowledge gaps. Having had the opportunity to live in San Francisco for the past few years during this bootcamp craze, I knew a fair amount of Hack Reactor grads who did the research for me and raved about the program. I’m halfway through the program now, and it’s already turning out to be one of the best decisions I’ve made. It’s true though that this program is intensive, requires a high level of dedication (as well as savings), and not for everyone.

Here are some of my key learnings from going through the Hack Reactor interview process to help you get started.

On the interview:

The structure of the 1-hour interview is as follows: a 5–10 minute brief introduction, then straight into the technical portion, and a few minutes at the end to answer any questions you might have. I’ve heard that this format has been fairly similar throughout the years so much of what you’ve read online probably hasn’t changed. Definitely use this time to ask anything you want to know more about and to get actual answers from the source, but don’t sweat it if you already know what you’re getting in to.

The interview tests for a combination of three things: your application of JS concepts to actual problems, how you respond to challenges, and your communication skills. It’s similar to conventional technical interviews; they’ll ask you easier warm-up questions and slowly ramp up the difficulty. Points are awarded for not giving up, thinking out loud, and walking the interviewer through your thought process. The guide that Hack Reactor sends you once you sign up for an interview should be your starting point; it’s incredibly useful and covers all the basic qualities they’re looking for. In my experience, I did find that it was less “collegially working” with the interviewer as per Hack Reactor says and more along the lines of rubber ducking. After all, they want to see how you respond to challenges, right?

At this point, just knowing the concepts and the definitions isn’t enough; you need to be able to work them in seamlessly while simultaneously interacting with your interviewer. The barrier to entry for bootcamps touting a program that takes you from “20 to 120” is enough familiarity with basic concepts and syntax so that you aren’t fumbling around in lecture and can follow along without falling behind. During the program, you’ll be learning so much material every day that it’s crucial you’re comfortable enough with JavaScript to keep up, have the ability to move quickly, and can effectively communicate your challenges.

On practicing:

Practice makes perfect. As a beginner, it’s easy to get overwhelmed by the sheer amount of material that’s out there and by how much you don’t know. Now that I’m coding 10 hours a day, 6 days a week, I’ve come to the conclusion that coding is not hard. Of course, there are varying degrees of complexity depending on the abstractions but for our intents and purposes, gaining the skills to pass the technical interview for a bootcamp is not by any means impossible. It does, however, take hard work, dedication, and tons of practice.

If you’re starting from scratch like I did, don’t expect yourself to be a coding wiz in a week (like I did). The first time you look at a for loop, you’ll probably tell yourself it looks easy, move on, and then forget what it is the next day. I did mock interviews where I butchered the syntax and I improved simply by repeatedly typing out answers to problems I had already solved. The goal here is to do as many problems as you can so that basic concepts become second nature, and you’ll be able to move on to harder concepts quicker and with much less difficulty. During the interview, you’ll need to show your interviewer that you’re comfortable with the syntax and capable of trying new concepts out. Some tips to convey this can be as simple as typing faster or using shortcuts to navigate the editor you’ll be typing in, both of which come with repetition.

If you’re struggling with the interview itself, this same approach can be easily applied to it as well. I was disastrous at technical interviews when I started and am less so now, thanks to forcing myself to practice. I primarily used to do behavioral interviews so the concept of thinking out loud in a problem-solving setting seemed unusual to me at first. I stayed up until 2 AM many work nights going through interview questions and voicing my thought process until I was satisfied with my delivery. The more time you put into practicing, the more confident you’ll become and in interviews, confidence means everything. It’s a continuous process, but the only way to get better at interviews is to do more.

On productivity:

Make sure you understand enough of the concept before moving on. Work hard, but work smart too. The trick here is being honest with yourself about where you fall. You can “get it” when the answer is shown to you but that’s very different from being able to implement it from scratch. You can understand how a certain function is implemented in one use case, but you also need to know how to effectively manipulate it within the context of a larger problem. For example, you probably know how to use the reduce function to find the sum, difference, or product of an array. But can you use it to find the max value in an object?

Whenever I didn’t get a problem, I’d console.log every line to understand exactly what I was putting into the interpreter and what the interpreter was spitting out. It’s important at this stage to familiarize yourself with how the JavaScript interpreter reads your code. You’ll eventually move on to use more advanced debugging tools that’ll immensely increase your understanding but for quick fixes, nothing beats the efficiency of a console.log. I’ve turned back to this handy method many times in a crunch.