Interviewing for a programming or other technical job can be stressful. In a short period of time, a company must try to understand whether or not a candidate has the skills to be successful in the role. In the same limited time, the candidate has to convey their true potential. This process is stressful for candidates, and difficult for everyone.
Technical interviews have historically been a complicated and fraught aspect of the tech industry. Many forms of technical interview don’t necessarily screen for the skills that are the most important predictors of success on the job. Candidates can feel unduly stressed by these interviews, leading to situations where they don’t fully convey the depth of their skills to an employer.
A candidate might miss out on a job opportunity that they would excel at, and an employer might miss out on a great employee.
As an industry, we’re all still working this out. Educators, employers, and aspiring programmers are continually working to better prepare and screen candidates. Aspiring programmers are constantly trying to do better in technical interviews.
At LaunchCode, we have a lot of experience with technical interviews. Many of our staff have previously (or still do) work as developers, and have gone through the hiring process from both sides. And LaunchCode has placed individuals at hundreds of different companies across the country, each of which has a slightly different technical interview process.
This guide intends to distill the best and most useful information about technical interviews, as we see them play out day-by-day. The industry will continue to evolve its practices, and we will continue to adapt this guide–as well as our education programs–to prepare aspiring developers to be as successful as possible. We’ll focus on interviews for programming jobs, but many of the same dynamics and principles apply for other technical jobs.
An interview for a programming job involves two high-level types of evaluation: technical and behavioral. These evaluations can take place in a single interview, or be spread across multiple interviews. Some companies will initially screen candidates with a relatively short behavioral interview conducted by a non-technical employee (often from their Human Resources Department), followed by a more in-depth interview involving the technical hiring manager and possibly other members of the team.
Behavioral and technical portions are sometimes part of the same interview. And in some cases there will be multiple components to the technical screening. When beginning the interview process with a company, ask your interviewer what the interview process will be like. If interviewing for a job through LaunchCode, your contact on the Company Relations Team may also be able to give you an idea of what to expect for the given company and team.
For the purposes of this guide, we’ll refer to “behavioral interviews” and “technical interviews”, but keep in mind that these can be part of the same actual meeting, or might be spread across different meetings.
Behavioral interviews give the company an idea of what type of coworker you would be. They cover soft skills like communication, drive, and responding to adversity. They can also cover non-technical planning skills, like project and task management. We don’t discuss behavioral interviews in depth in this guide, but keep in mind that they can be just as, and in some cases more, important than technical interviews in determining whether or not you get the job.
Technical interviews are intended to give the company a clear picture of the depth and breadth of your technical skills. This is a very, very difficult goal to achieve in a short period of time. The only truly reliable test of how you will contribute to a team as a programmer is to actually go through the process of working on the team for some period of time. An apprenticeship gives the company an opportunity to evaluate your skills properly, but they’ll still want to have a good idea of what your skills are like before committing to you as an apprentice, so that they have confidence that the apprenticeship will be successful.
In March of 2018, LaunchCode pulled data from Glassdoor, a site that allows individuals to post questions from job interviews that they have participated in. We pulled several hundred of these questions for programming jobs in St. Louis, MO and Miami, FL, and categorized them. The results are shown in the chart below, with behavioral categories in orange and technical categories in blue.
Interview Questions by Type¶
We will explore each of the technical question types below. Before doing so, however, let’s discuss how this data should be interpreted.
The first thing to keep in mind is that this is self-reported data from users on the Glassdoor site, so we should certainly not consider it to be a completely accurate reflection of all job interviews. Additionally, we can’t view this data as representing the breakdown of the questions within an “average” interview.
What we can say about it is that it reflects a significant emphasis on both behavioral and technical components. The most often reported question type in each of these categories is “Sell yourself” (behavioral) and “Technical concepts” (technical). This indicates that these are extremely important components of an interview; if a candidate shines in these areas, they stand to have a much better chance of getting a job offer.
Considering technical questions only, it’s tempting to diminish the importance of live coding questions, since they represented only 7.1% of the questions reported. At LaunchCode, however, we observe that one of the most common reasons a candidate is not offered a job is due to poor performance in a live coding exercise. Live coding very different from the experience of programming on the job, but if the employer gets the impression that you are likely to struggle with a relatively small-scale coding problem, they are going to infer–reasonably or not–that your coding skills are not mature enough.
The technical interview is intended to gauge whether a candidate has the skills necessary to be a productive team member within minimal on-boarding time. Employers generally accept the fact that LaunchCode candidates are entry-level candidates and may need more mentoring and support than other new hires, but they still need confidence in a candidate’s skills.
One other important aspect of the interview is to determine how you will work on the team, from a technical perspective. Despite popular perception, being a professional programmer is a very collaborative role. One of the questions the technical interviewer is trying to answer is,
If this person was on my team, are they somebody that I could work through problems with?
Therefore, you should treat the technical interview as a conversation more than an exam. Don’t just strive to give the “correct” answer, but also engage the interviewer. Ask follow-up questions and be honest about what you know and don’t know. It’s better to clearly state that you don’t know the answer to a question than to try to cobble together an answer; this will not fool the interviewer.
A Note on “Classical” Tech Interviews
The ways in which companies assess technical skill has evolved over time, and continues to change. The reasons why are myriad, but one of the primary reasons is that, quite frankly, nobody has figured out a foolproof way to measure skill in the interview process. The evolution of techniques is in part an attempt to improve the process.
That said, you will sometimes encounter companies that do “classical” or “old-school” technical interviews. Broadly speaking, these interviews consist of questions and challenges that most often have are meant to serve as a hurdle to be cleared rather than as an accurate gauge of skill. They often rely heavily on questions about algorithms (searching, sorting, graph traversal, etc), data structures, and algorithm analysis. Questions of this sort are well-documented on blogs, forums, and even entire books. It’s not that these concepts don’t come up from time-to-time on the job, or that they aren’t required for some programming roles, but the degree to which they have been used historically is out of proportion.
One popular theory about why data structures and algorithm questions used to be more ubiquitous in job interviews is that they were popularized by the big tech companies like Google, Amazon, and Microsoft. These companies have the luxury of choosing the best of the best, and they often recruit programmers from top-tier university Computer Science departments. In such programs, algorithms and data analysis are taught in-depth. And indeed, jobs at these companies are more likely to require a higher level of skill in these areas than in the industry as a whole. That said, other companies adopted the same interview techniques as the tech giants, with little regard to how well that process aligned with the work at their companies.
This trend has been reversing in the last 5-10 years, as companies have realized that such mis-aligned interview processes are likely to screen out qualified candidates.
The best way to prepare for technical interviews, in our experience, is to become a strong learner and programmer. This doesn’t mean that you have the flashiest capstone project in your class, or that you finished your assignments earlier than others. It means that you understand and can explain the concepts behind the design and implementation of the programs you have written, you can talk about the how and why of your code in addition to writing code that works.
While we don’t necessarily believe in “teaching to the test,” there are some additional ways you prepare for technical interviews.
The first is to practice the type of problems that regularly show up in live coding exercises during interviews. These problems are often much smaller in size than the larger assignments and projects that you are used to working on, but often compact multiple core concepts into a single problem. For instance, you may be tasked to write a function that requires you to exercise nuanced knowledge of data structures, control flow, data types, and exceptions. Sites like HackerRank and Exercism provide such practice problems in a variety of skill levels and languages.
Finally, research can go a long way when preparing to interview for a company. If you have an interview scheduled with a specific employer, there are multiple ways to gain insight into their process. Search for interview questions encountered by others using Glassdoor. If you know other programmers that have worked at the company, ask them for advice. If you know details about the area(s) the job will focus on (language, platform, etc.), then refresh your knowledge of those concepts. And if your interview was facilitated by LaunchCode, ask your Company Relations contact if they have any insight into what you might encounter in the interview.
Technical Concepts
Live Coding
Logical Problem
Your Technical Experience
The interviewer is on your team.
Avoid approaching the interview like an exam
Prefer more in-depth explanations and examples over short, direct responses
It is inevitable that you will, eventually, be asked a question that you can not answer. In fact, this is sometimes the goal of the interviewer, to ask questions of increasing difficulty until they find the boundary of your knowledge. Knowing how to respond in such a situation is important in order to properly convey that you are a capable programmer, aware of your limitations and hungry to continue learning.
There’s no shame in saying, “I don’t have experience with that concept,” or, “We discussed that in class, but my memory of the concept isn’t very solid.” When you give one of these responses, though, be sure to follow up with an explanation of how you would go about learning it if you needed to use it on the job.
All programmers, no matter their experience level, have gaps in their knowledge. A good programmer is not distinguished by the sheer volume of technical knowledge, but rather by the ability to learn on the job and solve difficult problems. If you can convey to the interviewer that you are capable of doing so, you’ll be well on your way to landing the job!
Explain the concept
Give a concrete example
Prefer examples from projects you’ve worked on over abstract examples
Restate and clarify the problem; create an example test-case
Outline a solution using comments or pseudo-code
Code the solution, talking through your work as you go
Test your solution
Refactor