Technical Interview Tips for Bootcamp Grads

I’ve been doing a lot of mock interviews lately with people who are about to or have just graduated from coding bootcamps. While each has their strengths and weaknesses, there are a few things that I end up sharing more often than not — so here they are!

Some of these tips are specific to whiteboard interviewing. Whether whiteboard interviews are the best way to interview candidates or not (not) isn’t the point here, the reality is that most interviews do involve some whiteboarding, so you’ll need to know how to do it well.

This is of course only relevant if you’re looking for a job to build for the web, but if you are, these are some (but not necessarily all!) of the things I’d expect you to know, in varying levels of depth, depending on whether you’re a front end or back end dev:

  • What DNS is and how it works (bonus: DNS cache)
  • What’s in an HTTP request (headers — method, path, cookies, auth; body)
  • What happens once my request hits the server — feel free to be specific based on which frameworks you know/have used, this stuff is usually applicable in others, even if the details or vocabulary is different (Bonus: what are some other things you might have to go through before you hit the server or database? Load balancers, connection poolers, etc.)
  • What’s in an HTTP response (status codes, and what codes in various ranges mean, content-type, body)
  • what the browser does with a response once it’s received. How it renders the content, and whether it makes additional network calls to get other assets (this is assuming the body contains HTML, which is not necessarily an assumption your interviewer will be making, but likely is for a front-end role!)

Your interviewer is more interested in how you approach problem solving than whether you can actually get to a working solution in the time allotted (hopefully — if they’re not you probably don’t want to work there). Explain your thought process. Explain the ideas you’re considering, even if you know you’ll likely not implement them — they will often help you get to your next idea until you do eventually get to the one you want to use, and the how did you get to this idea is useful information for the interviewer. There should be very few, if any, stretches of silence.

I’m a pretty active interviewer, so I ask clarifying questions and give hints if people get stuck, but I’ve met people who are totally poker-faced the whole time. Don’t just say “I don’t know what to do next” (even if it’s true!) and hope they’ll come to your rescue. Break the problem down into the smallest piece you think you can solve, and start there. There’s an added bonus — you typically learn something about the problem by trying, even if it’s wrong!

This is of course only relevant if you’re doing a remote interview that involves sharing your screen — please, please, turn of all notifications. This seems obvious, but you’d be surprised how often folks forget! There’s nothing quite like a slack or text message notification, that could say anything, showing up in the corner of your screen while a potential employer can see it.

While the hope is that interviews accurately represent the work you’ll be doing on the job, the reality is somewhat different. Which unfortunately means that it’s another thing you’ll have to learn and practice.

Interviewing may not be a ton of fun, but it’ll be less stressful if you’ve practiced a few or several times in lower-stakes environments. It’s one thing to read tips like these, but something totally different to be able to put them into practice effectively and consistently.

You can practice with peers, or ask people in the industry — people are usually happy to help!