Helping our students find great jobs is a huge part of what we do at Epicodus. In fact, it’s our mission. Over the years, we’ve accrued quite a bit of job-hunting knowledge to help set our students apart. In the next few weeks, we’ll be sharing our best tips and tricks for junior developers who are looking for their first jobs.

A technical interview, or technical portion of an interview, will focus on your coding knowledge and problem solving skills. The purpose is to get an idea of how you think, and what strengths you can bring to their company.

A technical interview is, for many, the most stressful part of the job-hunting process. Coding is hard enough on your own or with a pair, but now you're going to be asked to solve coding and pseudo-coding problems in front of potential employers. The key is to practice before the real thing, so you're not too nervous when you're in the real thing.

Job interviews can take many formats. Some employers will conduct a pairing interview, where you'll pair program with your interviewer. Sometimes this will be on a standard problem the employer uses to evaluate candidates; sometimes it will be on real work that the employer has; and occasionally they may ask you to pair on one of your own projects. This is an excellent interview format, as it tests what you'll actually be doing on the job, and doesn't really require any special prep. Unfortunately, only a minority of employers use this format.

Another common format is to send you requirements for a simple program, ask you to solve it on your own time without outside help, and send them back a solution. This could be a full-blown web app or just a simple server-side or JavaScript program. A variation on this format is to ask you to come into their office and build the app on your own, within a couple hours. Again, this format is fairly nice because it tests the way you work, and doesn't really require a whole lot of special preparation.

Whiteboard Questions

The more difficult interviews will involve answering technical questions out loud, or "whiteboarding" a solution to a coding problem - sketching out a visual and/or pseudo-code solution to a problem, and talking out loud about your thought process as you go. This is one of the most common interview formats, and where you should spend a good amount of extra time preparing.

There are three things you should make sure to do when you get an in-person technical question:

  1. Ask clarifying questions. Often, your interviewer will intentionally be vague about something or leave out information. Don't be shy about asking for clarification or more information!
  2. Talk out loud. Even when you have no idea where to go, don't just stand there silently. The interviewer wants to hear your thought process, even if it's just you coming up with ideas and then saying why they won't work or are wrong. You should strive to talk constantly.
  3. Admit when you don’t know something. When you don't know something, it will be obvious to the interviewer. If you try to "BS" your way through a question, you will most likely not get the answer, or the job. Just say "I don't know," or if applicable, "I don't know, but here's how I might figure it out."

An excellent practice method for this type of question is to find a resource for code challenge questions, and practice talking out loud while you solve the problem. You can do this while writing the answer on a sheet of paper, or even with a dry-erase marker on the bathroom mirror. The main practice point is to write the code by hand, and explain what you're doing while you're doing it. You can find some great sample challenges to work on from CoderByte. 

Open Questions

Another type of question you get in a technical interview may not require you to code at all. These questions may come in addition to a code question, and are open ended discussion questions designed to give you a chance to showcase your knowledge. It's important to take advantage of these opportunities, as you have the freedom to highlight your strongest area of knowledge.

Here are some sample interview questions:

  • Name every database association relationship.
  • What is the difference between POST request and a GET request?
  • What is Git and why would you use it?
  • What happens when a user logs into a website?
  • What is a class?
  • What is an object?
  • What is unit testing?
  • What happens when a user types in a URL?
  • What is a foreign key?
  • What is REST?
  • Pretend I’m another programmer who has never used Drupal/.NET/Rails– explain to me how an app is structured, and why it’s a good framework for web apps.
  • Show me some code you wrote that you're especially proud of.
  • Talk about a time that you solved a difficult coding problem.
  • What is an array?
  • Explain MVC.
  • What is a join table in SQL?
  • What is floating in CSS?
  • What are media queries and how do you use them?
  • You've been working on a site for a couple months here at our company. You come in one day and the site is down. What do you do?

Final Thoughts

Here is some great advice taken from a presentation on technical interviews:

  • Make sure you understand the question. Do not start until you do! Ask for clarification if you're at all unsure.
  • Use the programming language you're most familiar with. It doesn't matter if the interviewer is unfamiliar with that language. They can probably figure it out. They can consult colleagues after with any questions.
  • Verbalize your thought processes. Don't just stand there and do nothing while you think about the problem. Talk about what you're thinking, discuss the pros and cons. Think out loud!
  • If you don't know something, admit it. The interviewer may give you a hint, or move on to another question.