Technical Interview Tips For Bootcamp Grads

Adrienne Domingus
3 min readMay 31, 2018

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.

Know how the internet works

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!)

Think out loud

This is specific to whiteboarding, but may also apply to pairing or some other types of technical interviews.

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

--

--