The Software Engineering Interview Study Guide

(InterviewX is an interactive study guide for job interview prep- available now at InterviewX.co!

Section 1: Intro to Software Engineering

Abstract

Coding is increasingly seen as the competency of the future by some of the world’s most innovative executives & business leaders- the chorus of CEOs encouraging people to learn how to program is growing louder and louder. Those who possess programming skills already are very well positioned for incredible careers. However, before you can join a rocket ship company with a software engineering job offer, you still have to pass the engineering job interview, which is still a challenging and somewhat opaque process.

This article is meant for anyone prepping for a software engineering interview and looking for more clarity around what to expect. The further along you are in your career, the more exposure you’ll likely have to the interview process- both as a candidate, and sometimes as an interviewer. Therefore, this article is mostly going to be helpful for those earlier in their careers, or those who haven’t been in an engineering interview setting for a couple years and wants a refresher.

Below, we’ll cover the types of interview questions you can expect, best practices on how to perform to your highest potential, tips on preparation methods, and a bunch of examples of sample interview questions you can expect. This guide is roughly a 15 minute read start to finish, but feel free to skip around to the sections that are most relevant to you!

What separates a great engineer from the pack?

The job of a software engineer is to take the idea that a product manager, designer, or engineering manager has (or another type of decision maker,) and turn that vision into something that actually works. That’s why the ability to code is such a sought-after attribute, and why software engineers are in such high demand- if you write the proper code, the possibilities for the functionalities you can enable are endless.

Great engineers are excellent problem solvers. They are skilled at anticipating complexities in a project before they manifest themselves as problems, and can build with those things in mind ahead of time. They will also build in a way that allows others to add to their code with relative ease.

Great engineers also understand how to test their code properly, and make sure the functionality they’ve built actually works as intended. Engineers talk about “unit testing” as an effective way to test what they’ve built- it takes an input that a user would enter into the application, and examines how reliably the proper output is created. Nearly half your work as an engineering team involved testing the work you’ve done to ensure that it works as expected.

Section 2: Inside the Engineering Interview

The two main types of engineering problems you’ll be asked to solve

In your quest to prove your technical capabilities as an engineer, you’ll typically be asked to solve two main types of problems:

1. algorithm questions (aka “programming questions”)
2. architecture questions

Algorithm questions will require you to code (or examine code) live on the spot, and create some sort of desired functionality that the interviewing team proposes- typically with a whiteboard, and even sometimes with a laptop.

Meanwhile, an architecture question will nearly always occur on a whiteboard. This type of question will require you to consider the architecture needed to make something work — essentially, how the code would be organized.

Finally, you may also be asked general questions about high-level software engineering topics, which will help your interviewer gain a sense for how familiar you are with well known engineering topics. For instance, a couple commonly asked general questions:

1. What is the difference between struct and class?

2. How can you make an input string type safe?

3. What is the difference between a strong and weak variable?

We share more of these examples in the last section of the article, but these types of questions help an interviewer make sure that you possess the baseline of technical competency.

Algorithm questions explained

Algorithm questions (also referred to as coding tests, or coding problems) essentially require an engineer to solve a coding problem with a whiteboard. They will propose a functionality, or a problem they want you to solve, and watch as you write code for a solution. The interviewer will evaluate your abilities in a few key areas:

• data structures
• sorting algorithms
• time/space complexity
• pattern recognition
• edge case recognition
• recursion
• Big O notation

Architecture questions, explained

Algorithm questions are mainly focused on the actual code you’d write in order to build something. At a high level, architecture questions are focused on the big picture steps you’d take in building an application. So architecture questions will not require you to write code- it’s more about diagramming on a whiteboard than it is deploying actual code, line by line. The architectural questions are far broader in nature than algorithm/coding questions, which are highly specific.

Here, you’re being graded on your ability to take a general idea, and design something that will produce the desired functionality. This type of interview problem requires creative thinking, architectural prowess, and a strong understanding for how software works under the hood.

How are engineering interviews structured, from start to finish?

There is no foolproof structure to an engineering interview but they typically take about a month to unfold from phone screen to offer letter. Here’s a sense for the cadence you might expect:

Week 1: Take an online coding test, to make sure you clear the technical bar

Week 2: Talk to a recruiter to make sure there are no showstoppers off the bat, like location, education level, or a gap in what you claim to be capable of vs. what the role actually entails

Week 3: A technical phone screen, which is almost always a couple of algorithm questions. This serves as a baseline of technical proficiency- does this candidate possess a base level of coding ability that passes the team’s bar.

Week 4: An onsite interview, where you’d typically meet with 3 to 4 people. This would usually involve a couple quick and direct questions, a programming problem, an architecture problem, and a discussion that’s a little bit fuzzier in nature around past projects you’ve tackled. The focus here will be the things you actually owned- the results you were accountable for, and things you really drove start to finish.

Week 5: Meet with the hiring manager, which is 50% getting a sense for your personality and culture fit and 50% a chance for you to ask questions. It’s important to have questions for your interviewing team because it shows that you’re engaged and truly curious about the role. Asking questions around what your day would look like, who you might report to in the role, and what metrics you’d be evaluated on are tried and true.

Week 5 or 6: Sometimes, if a team isn’t certain as to whether or not to extend an offer, or if it’s simply part of their typical process, they may assign a take home coding test or mini-project.

Section 3: Tactical Engineering Interview Elements

Behavioral Interviewing, and soft skills

In any interview, team and culture fit is an enormous factor in whether or not you’ll be hired, it’s not 100% about how strong a programmer you are. Here are a few things to remember as you think beyond the coding component of an interview:

Behavioral:

• Develop a narrative for what you like about the company you’re interviewing with, and the product you’d be working on
• Brainstorm the anecdotes from your past that highlight your best successes, and the hardest problems you’ve solved
• Research the company culture, and map out the examples from your past that show that you align with them
• don’t throw anyone you worked with under the bus; nor should you throw the product you’d be working on under the bus, or the work of the people who built that product

Stylistic:

• Be passionate and enthusiastic about the problems you’re asked to solve
• Be collaborative with your interviewer
• be personable- half of the assessment is how you’d fit in as a teammate
• Put your brain on “speakerphone,” and let the interviewer into your thought process.

The importance of “putting your brain on speaker phone” as you solve coding problems

One of the biggest, and most common, mistakes made in an engineering interview is assuming you can’t interact with your interviewer as you solve the problem. Engineering hiring experts advise that you do your best to “put your brain on speaker phone,” meaning, explain your thought process as you solve the problem.

This approach has many immediate benefits:

• An interviewer can understand how you’re thinking through a problem, so if you make a couple small mistakes, they can give you the benefit of the doubt by seeing where you went wrong. If you solve it perfectly, they see your thought process, and you get even more credit.
• If you’re really struggling, and explaining why, the interviewer can give guidance that you’re on the right track, or in some cases, hop in with advice. Sometimes, they may see that they miscommunicated the problem, and if you’re thinking out loud, they will hop in to let you know.
• You can avoid time traps. If you would have gone back and tested for edge cases, but realize you don’t have time, you can simply reference that out loud. The interviewer will then understand that you would have known to take care of it if the time limits weren’t in place. Never waste meaningful time on something minor that you could just easily explain out loud.
• Explaining your thought process out loud is far less boring, and far more engaging, for the interviewer. At the end of the day, your interviewer needs to be rooting for you and be engaged with your interview, and letting them into your brain a little bit is a perfect way to develop that empathy.

One of the worst things you can do is create arbitrary interview formality rules for yourself. The goal is to communicate what’s in your head proactively, not to be completely silent until you can produce the right coding solution (an assumption that is frequently, and incorrectly, made by many.)

What to do if you get stuck during the coding test

Most people get stuck when they’re not exactly sure what code to write. Instead of banging your head against the wall, take a step back and diagram the way you want to attack the problem. It will either unblock your thinking, prompt the interviewer to validate that you’re thinking about it the right way, or realize that you haven’t understood the question as they intended to ask it.

You can also ask the interviewer for a hint, or try to talk through the questions you’re asking in your head out loud to the interviewer. Again, this is one of the benefits of “putting your brain on speakerphone” — often, an interviewer will assist you if you’re struggling, rather than allow a full empty half hour to pass with you being completely stuck. Explain your thought process, identify where you’re getting stuck specifically, and try to bounce ideas off your interviewer until it either clicks in your own head, or the interviewer gives enough feedback to get you going again.

What to do if you make an error during a coding test

Typically, you won’t know that you’ve made an error unless they bring it up. However, sometimes, you may realize you’ve made a foundational error in your code- if that’s the case, try to call it out immediately, and do your best to prevent yourself from diving down a rabbit hole that was based on faulty logic.

If it’s an edge case error, announce that you realize there could be issues with an edge case (and why it might occur) but explain that you’re going to push forward for the time being to not lose momentum. If you call out that it’s something you’d look to address later, the interviewer will have a difficult time knocking you for the error, because you ultimately caught it and demonstrated awareness that it would need to be changed.

How to defend a decision if questioned

So much of this is about your tone. You have to balance between standing up for yourself and being confident in your work, with humility and the ability to demonstrate coachability. If you use a calm tone, are thoughtful about feedback, and open minded, you can’t lose either way (whether you stand by your original thinking, or concede that the interviewer is bringing up a good point.) Remember, when an interviewer challenges you in an interview, it’s often times just a test to see how you’ll react.

What if an interviewer wants specific experience that you don’t have?

Typically, you wouldn’t get onsite if you didn’t have a strong enough match in your technical skillset. If they are looking for a specific coding language that you don’t have experience with, and they press you on that or similar expertise gap, do not panic. You should emphasize your strength as a problem solver- learning a new coding language is incredibly doable if you’re hungry, and most engineering leaders are open minded about this.

Smart + scrappy + problem solving skill is an unbeatable combo in an engineering interview, as engineers are constantly solving problems and learning new skills when they work on projects.

Section 4: Steps in your preparation

A couple preparation steps to consider:

1. Practice solving coding and architectural problems on a whiteboard. We share some examples below, but these can be found all over the internet if you search for “algorithm question engineering interview examples” or “architecture question engineering interview examples” (or something similar.)
2. Enlist the help of online resources (like HackerRank for example) to simulate the pressure of a coding environment.
3. Go through practice questions WITHOUT looking at the answers first. Only check the answers to your practice questions at the end once you’ve had a chance to work through it fully.
4. Map out your best anecdotes and accomplishments from your career thus far.
5. Think about why you want to work at this company, in this role, specifically. A personal pitch is important regardless of what team you’re interviewing for.
6. Try to practice as many questions as you can with a friend, out loud. Something magical happens when you force yourself to vocalize something- it’s a presentation best practice that applies to interviewing very well.

Other Resources:

• Medium’s internal (and publicly available) Engineering Interview Rubric
• Cracking the Coding Interview (book)
• Inside Big O notation
• Firsthand story of how an engineer prepared for a Facebook interview
• Technical Interviewing Software (Interviewing.Io)
• HackerRank

Examples of questions you may be asked in an engineering interview:

Company Specific:

• why do you want to work for this company specifically?
• what is it that you like about our product?
• what’s one thing you’d improve about our product?

Behavioral:

• can you tell me about a time you had to get yourself “un-stuck” when you were stuck?
• can tell me about the most difficult engineering problem you ever had to solve?
• can you tell me about a time when you code cleanliness was able to make you successful in a project?

Behavioral for engineering manager candidates:

• can you tell me about a time when you helped someone on your team to reach their goals?
• can you tell me about a time when you were able to allocate responsibility on a project in accordance with your team members’ individual strengths?

Section 5: Sample Technical Questions (General, Algorithm & Architecture)

General:

1. What is the difference between struct and class?

2. How can you make an input string type safe?

3. What is the difference between a strong and weak variable?

4. What is a closure?

5. How does threading work?

Algorithm:

1. Code a function that takes in a sentence (string) and returns the word in the sentence that appears most-frequently. Example: Input: "the cat climbs the tree" - Output: "the"

2. Code a function that takes in an array of numbers and returns an array of numbers that contains all of the numbers appearing exactly once in the original array. Example: Input: [1, 1, 2, 3, 3, 4] - Output: [2, 4]. No guarantees the input is sorted.

3. Code the same function as #2, but this time the input is guaranteed to be sorted.

4. Code a function that takes in an array of numbers and returns an array of the same numbers sorted such that x1 > x2 < x3 > x4 ... xi > xi+1 < xi+2. Example: Input: [1, 7, 9, 3, 2, 3] - Output: [7, 1, 9, 2, 3, 3]. No guarantees the input is sorted.

5. Code the same function, but this time the input is guaranteed to be sorted.

Architecture:

1. What is the Singleton pattern, and when should it be used?

2. What is your favorite object oriented programming pattern, and why?

3. You are building the Facebook-esque newsfeed and need to handle different types: weblink, status, or video. Each of these posts will contain author information, a timestamp, an optional description, and a unique identifier. Weblinks will additionally include a link, status will require a description, and video will additionally include thumbnail information and a unique identifier of the video. Build classes to handle this.

4. You are building a book store app that will contain bookshelves and books. Bookshelves can have different categories and books contain author name, ISBN, title, publisher year, and publish date. Books can be owned by a person or a bookshelf, but not both. Build classes to handle this.

Special Thanks to:

Steve Flory and Andy Scheff, who have conducted hundreds of engineering interviews between them. Steve is the co-founder of Out of Office, and Andy is a lead engineer at Motion.

About the Author:

Mike Marg lives in San Francisco, and has worked at some of the fastest growing technology companies in the world at Dropbox and Slack. He is also the founder of InterviewX, an interactive study guide for job interview prep.

You can check out InterviewX’s blog for more strategies around interviewing, and his interactive study guide product can be found at InterviewX.co.