This page is a work in progress.You can help improve it. →

Technical Interviews

Technical Interviews can come in many shapes and sizes depending on the company and its development team. There are the five types of Technical Interviews/Assessments you may come across in your career:

  1. Open-Ended
  2. Question/Answer
  3. Whiteboard
  4. Pair Programming
  5. Take-Home

A technical interview evaluates a candidate's abilities to think creatively, adapt solutions, and solve technical problems in a limited time/setting. Completing a technical interview signifies that a candidate has the minimum qualifications to meet specific job requirements.

The interviewer uses technical interviews to assess how the candidate approaches the problem, breaks it down, and solves it. While arriving at a correct answer can be beneficial in this interviewing scenario, even incorrect solutions can help interviewers understand your methodology when solving problems.

Let's look a little deeper into what interviewers want to learn about you during a Technical Interview before we dive into the types.

Communication

How accurate is your technical diction? How clearly can you explain something in a concise manner that fits within your level of understanding?

Your word choice should include specific usages of technical terminology. Interviewers want to know that you can use technical terms and that you understand them. Be careful not to throw out phrases if you are not 100% sure of their meaning.

Perform Under Pressure

Interviewers are trying to feel out where your knowledge gaps are and how you handle that situation. It's ok to admit when you don't know something, but break down what you would do to figure out a solution or learn it.

You don't always have to have the right answer, use this as an opportunity to ask questions to show that you are interested and willing to learn.

Problem Solving

Like learning how you perform under pressure, interviewers want to see how you react if you reach something you don't know or understand. The interviewer wants to know if you ask questions, stare at your computer, say nothing, or erupt in frustration.

How you handle pressure is a crucial indicator of how you might be as a teammate and what the team would have to work with should you run into an issue once hired.

People Skills

Companies want to find people that fit into their team. Use the interview as an opportunity to have a conversation and relate to the interviewer. You don't have to tell them everything you do or don't know but avoid answering using short answers. When possible, use your chance to respond to build a short story that relates to a similar problem you solved and what steps you used to solve it.

Types of Technical Assessments:

Open-Ended

Open-Ended assessments are more of a question/answer conversation format. The purpose of these interviews is to help the interviewer get to know you and what type of communication they can expect from you as a team member. They also want to hear how you talk about your projects.

  • Were you excited about what you built?
  • Did you express more negatives than positives?
  • Do you think about improvements or lessons learned?

Some common questions you might see are:

  • Tell me about your capstone project?
  • What project are you most proud of?
  • Be prepared to talk about questions like these, have stories and experiences in your mind that you can talk about.
  • Tell me about a technical challenge you have faced?
  • What are you working on now?
  • Tell me about something you are proud of from the past?
  • Tell me about something you could have improved upon and how in the past?

Be ready for questions that might be there to throw you off like "How does the internet work?"

  • Think about what you do know and break it down the best you can.

Resources

Question/Answer

Question/Answer assessments are as they sound. The interviewer will ask you a straightforward technical question that they expect you to answer. Depending on your skills level and experience, the questions may start easy and continue to build in complexity.

These types of questions are another way for the interviewer to gauge your level of understanding. It helps them know if you are under or overselling yourself and your skills. During this type of assessment, you can ask clarifying questions when needed, and you will want to be honest about your level of understanding.

Don't use terms you are not familiar with in the hope that using them will make you look better. It's ok to stay away from jargon if simple words can get the same point across.

Resources

Whiteboard

A whiteboard interview tests your communication and problem-solving skills. You will receive a code problem or task to work out your code and go over your solution. These can often feel the most stressful because you don't have access to an IDE that helps you with formatting and syntax.

Here are some tips to help you through a whiteboard interview:

  • Not sure what they want? Ask questions
  • Talk through what you are doing, don't work in silence
  • Practice on an actual whiteboard
  • Use the PEDAC methodology to break down the problem

Need more practice? Attend the next Whiteboard Meetup to practice in a safe and supportive environment while you meet other developers looking to do the same.

Resources

Pair Programming

The purpose of a pair programming interview is to discover your technical ability and what it's like working with you. Pair programming sessions are typically 2-3 hours in-person or on a screen share.

During a pair programming assessment, you will have the opportunity to talk with the developer you are paired with and learn more about them and their approach to issues while showing your abilities.

Here are some tips to help you when pair programming:

  • Work through your problem
  • Talk through what you are doing, don't work in silence
  • Ask questions when you need to
  • Not sure what they want? Ask questions
  • Start a conversation with how you would start and ask if that works or if they prefer a different method
  • Demonstrate some of the more advanced things you know how to do (example: hooks) if you can
  • DRY code, refactor if you can to keep it clean

Don't forget!

  • Complete the task in time
  • Keep your code as DRY as possible
  • Take the advice of the person you are pair-programming with, and appreciate their guidance.
  • Use their feedback in your solution to show you are listening.
    • If you can merge it with your idea, talk it through with them to show you can collaborate.

Take-Home

Take-Home assessments are an opportunity to work on a challenge on your own time and in a comfortable place with less pressure. Now, this doesn't mean that they will be easy to do or allow you to slack off and do it all last minute.

Take-home assessments will come with a timeline if the interviewer doesn't mention the due date YOU need to ask. Never assume a due date because that could knock you out of an opportunity because you missed a deadline. In addition to a set time to get the challenge completed take-home assessments, are often vague, they may not tell you how to style the project or what layout they are expecting. These are decisions you will need to make and support if questioned about them afterward.

Here are some tips to help you:

  • It's okay to ask questions if there is something you don't understand but only ask for the necessary information to make it work.
  • Work consistently, push to GitHub so you can show you worked continuously, and you pushed up your code. Pushing your code to GitHub will give them an idea of how you manage your time. Time management skills are something every development lead will want to see from you.
  • Document carefully
    • Create a README with the project title and a link to the deployed site.
    • Show off your technical writing skills.
    • If Heroku takes a long time to load, so it is delayed mention why that is happening. Add sections about how you implemented features or why you made design decisions. List technologies/libraries you used.
  • Be prepared to talk about your test in an in-person interview.
  • Don't mention the downfalls or things you didn't complete; instead, talk about what you are proud of with this project.

Resources:

Additional Resources

_Special thank you to Dylan Attal - Cohort XII and Nick Weber - Cohort XV for providing the information used for this page

© 2017 - 2022; Built with ♥ in St. Petersburg, Florida.