This article is part of our series on Software Engineering. For even more help and resources, check out our complete Software Engineering Interview Course
The best way to take away the anxiety of interviewing is to go in knowing that you are absolutely prepared. There’s nothing to be nervous about once you’re confident in your skills and knowledgeable about the normal software engineering interview questions. To help get you there, Exponent is pooling together our resources and knowledge into this compact guide so you can build your confidence and smash that interview.
This article will start by talking a little about the procedure of most software engineering interviews. After that, we’ll get into what kind of questions you need to be ready for, and we’ll even include some sample questions with our suggested answers.
Mục lục bài viết
The Process
We can give you a general idea of what to expect with a software engineering interview at most companies, but keep in mind that there’s likely to be some variety between companies. There was a time when there seemed to be a single standard in the process of software engineering interviews, but some companies have now begun to try different interviewing strategies in order to stand out.
These variations in the process are more common among start-ups. The big tech companies (i.e. Google, Facebook, …etc) usually follow the standard process. Generally, the process looks like this:
- Recruiter phone screen
- Follow-up phone/video interviews
- On-site interviews
Recruiter Phone Screen
Your interview process will likely start with anywhere between 1-3 phone/video call interviews before you actually meet anyone face to face. The first interview will usually be the recruiter phone screen. The recruiter will be asking about your work history to make sure your resume is legit, and they will also be making sure you have experience that lines up with job. Make sure to read up on the company, understand the position you’re applying for, and be familiar with the details of your resume.
Follow-up Phone/Video Interviews
The following phone/video interviews will get more technical. You might be talking with team leaders, and you should expect to move on from talking about your experience and be ready to talk about technical know-how.
These interviews often contain about 30 to 40 minutes of technical interview questions, along with roughly 10 minutes of behavioral questions.
For the technical questions, you should expect some coding challenges. They might ask you to do this challenge while on the phone using a shared Google Doc so they can see you work, or they might give you the challenge as a sort of homework assignment after the behavioral interview.
On-site Interviews
Once the phone/video interviews are done, it’s time for the onsite technical interview. This interview can go for up to 6 hours and it’s usually done in person. It takes so long because you’ll be talking to multiple people at the company, and you should also expect multiple coding challenges. Some companies will have you do these challenges on a computer, but some will have you write out the code on a whiteboard.
The whiteboard process will likely feel unnatural to engineers who have only ever written code on a computer, so you should practice writing code on a whiteboard before you begin your first technical interviews.
After that, the interview is essentially done other than perhaps a few more talks to negotiate terms of employment.
Now let’s talk about how to answer some typical software engineering interview questions.
Skills
Throughout every stage of the software engineering interview process, there are certain sets of skills and qualities that almost every company will be looking for.
Team Player
If you work for a company, then you’re part of a team and recruiters need to know that you can work well in that environment. When it’s appropriate in the process of your interviews, you should highlight ways that you’ve been able to collaborate with people to achieve a goal. Provide them with examples to show them that you provide value to a team, but also that you are drama-free and that you are open to the ideas of others.
Try to keep things positive throughout the interview. Rather than going on a rant about a previous boss or team member, focus on the good things that have come from your experience working with various groups of people.
Computer Science Fundamentals
You can write on your resume that you have experience with this tool and that field, but recruiters and hiring managers will still want to poke around your experience to verify that you really do know what you say you know.
Be ready to explain technical concepts involving algorithms, operating systems, various programming languages, and so on. Also be ready to explain more big picture topics in CS, like how the internet works.
Technical Experience
They will be curious if you have ever built web or app software from the ground up. It’s not necessary that this software is from a professional experience. It could even be something you developed as a student or on your own time. They want to know if you’ve seen a piece of software through every stage of development.
And if you have, they’ll want to know what became of it. Did you deploy it to actual users? How did you evolve it? Did you scale the software? What was the process? The more experience you have developing, delivering, and scaling software products to real users, the more confident the hiring managers will be in your ability to join the company and deliver results.
Experience Collaborating in Technical Teams
Recruiters will likely want to know what sort of technical issues you have experience working through. For example, they might ask if you’ve spent time conducting coding reviews or writing tests. They also might ask if you have experience using Git for source code management, and how you used it.
Overall, there’s a lot of variability in what companies are looking for, but these are consistent skills that every software engineering team will want to see. Throughout all the stages of the interview process—and especially in the behavioral section—try to show how you possess one or more of these skills.
Behavioral Questions
In the behavioral portion of the interview, the interviewer is trying to dig deeper into your resume and work experience. They’re also trying to figure out what it’s like to work with you on the team. With that in mind, come to the interview prepared to talk about examples of success in your work/education background, and also make sure to keep the conversation positive.
Everyone’s answers will be different because these questions are about your personal experience. For this question, we’ll provide tips for each question, and we’ll provide answers from a fictional software engineer named Po Nent.
Po was previously a high school history teacher. For years, he used his off-time to learn about software engineering. He recently went through a coding bootcamp, and now he’s on the job hunt. He’s focusing his applications on companies in the Ed Tech field so that he can leverage his experience as an educator.
Question 1: Why are you thinking of leaving your current job?
Tip: Never complain about your previous job. No matter how legitimate your complaints might be, it’s just a bad look to complain about previous jobs or teams in an interview. The only result is that the recruiter will think you’re someone who is going to introduce negativity to the team, and no one wants that.
Therefore, express gratitude for the people you met and the skills you developed in previous jobs and classes, then focus your answer on your excitement for the future. Show the recruiter what this change means to you. Explain why the company is an ideal fit for you.
Ex. Po Nent said: It’s not going to be easy to leave. I work with some great people and I’ve made a lot of good friends. But ever since I learned the basics of coding, it’s become an obsession for me. I’ll teach a full day, and then come home to spend my night coding because it’s fun to me. So that’s why I have to leave my current job. I have to find a way to turn this obsession into a career.
That being said, I do still love education and that’s what brought me to this company. I mean, there’s a reason that I became a teacher in the first place, right? I want to help people improve their lives and I want to help improve our education system. Working for you will allow me to combine my coding obsession with my education passion. It’s perfect.
Question 2: What do you like to do in your free time?
Tip: With questions like this, recruiters are trying to get a snapshot of your life to see if this is just a job for you or if it’s a passion. People who see it as just a way to pay the bills will do the bare minimum to be acceptable. People who see this job as their passion will engage more with the company’s overall mission, and they’re more likely to stay with the company long-term.
It’s certainly okay to mention non-programming hobbies. In fact, if you have a hobby that’s particularly interesting then that can be a great way to make yourself memorable among the sea of applicants. However, your goal with this kind of question is to show recruiters that you’re all in on software engineering and on the company’s industry.
Ex. Po Nent said: Well, I play bass guitar with a group of friends and I also spend a lot of time reading computer science news, particularly new languages or any innovation on the horizon. But mostly after work, I spend a lot of time building apps. I’ve built some of them for public or private use, but honestly a lot of them aren’t for any use at all. I like building apps just to explore how to get certain functions to work. Like with one app I’ll explore how to get a chatbot to work, or with another I’ll try to fine tune how to make a better search function.
I like to learn. That’s why I got into education in the first place. And for me, I learn by doing. I started out reading guides online, but when it really clicked with me was when I started building stuff. It became like a game for me.
Question 3: Talk about a complex project that you’re proud of, and tell me how you contributed to it.
Tip: Always go into an interview with a short list in mind about work or side projects you’re proud of. Be ready to explain exactly why you were a valuable asset to the team. Remember to show, not tell. Instead of telling them you did a good job, show them the results of specific features you made. Instead of telling them you were valuable, show them choices that were before you and explain why you made your decision.
It’s also helpful to show what you learned from experience. Nobody knows everything, especially with software engineering, so companies want people who continually learn. When you talk about projects, explain what you learned from it, or describe what you would do differently now with what experience has taught you.
Ex. Po Nent said: Half a year ago, I picked up a side gig for a company that was building an online education platform for a school. They wanted it to create more communication between teachers, students, and parents after class. It needed to have a way for teachers to submit feedback, assign homework, and for students to submit assignments.
I did most of my work on the feedback form. It turned out to be a lot more complex than I expected, mostly because the feedback had to integrate with the student’s overall grade and with a couple other performance tracking forms. On top of that, it had to be extremely user-friendly so that young students and busy parents could easily use it. It was stressful at the time, but that project is what gave me the confidence to pursue software engineering full time. It didn’t just teach me new skills, but it taught me how to learn new skills. I spent a lot of time brainstorming with team members to solve problems.
Question 4: Talk about a time you did not get along with a coworker. How did you resolve the situation?
Tip: Keep it positive. Don’t talk down about anyone. Don’t try to persuade the interviewer that you were right and the coworker was wrong. Instead, just focus on the facts about the problem and explain what you did to improve the situation.
Also, keep the focus of the story on yourself. The recruiter isn’t looking to see what your coworker learned from the process, they want to know what you learned. Describe what you could have done differently to prevent the situation, and tell them what positive lessons you learned from the experience.
Ex. Po Nent said: Yeah, for one project in my bootcamp there was this one classmate on my team who I really clashed. It was difficult to make any kind of progress because she and I would get into debates over every little detail. After talking to some team members, I realized there was something I could do to make the situation better.
You see, I’m usually a light-hearted and humorous person, but my whole demeanor changes to humorless and logical when I’m working out a solution. When I do that, I’m having a lot of fun. I love working out solutions, and usually people appreciate that I’m focused and direct. But what I realized is that she was interpreting that change as though I had become angry, and that set us up for confrontation.
After realizing that, I did three things. The first thing I did was to apologize for all the confrontation. Then I explained to her the way I communicate. And then, I made sure to be warmer in future conversations with her. It worked, and we were finally able to bounce ideas off each other in a way that was productive. We ended up delivering a great project, and I think we both put in a little extra because of the respect we developed for each other.
The whole situation taught me that I need to focus on people before focusing problems, because not everyone works through problems in the same way that I do.
Data Structure
Data structures are the building blocks of the programs we write. Dealing with them might not be something that we need to worry about every day, but it’s still important to remember the fundamentals and to prove in an interview that you understand them.
Here’s an example of a common type of data structure problem, and our suggested answer.
Question: Difference of arrays
Write a function diff(arrA, arrB) that accepts two arrays and returns a new array that contains all values that are not contained in both input arrays. The order of numbers in the result array does not matter.
Hint #1: It’s possible to solve this problem by brute force (comparing every element to the elements in the other list), but can you think of a more efficient solution?
Hint #2: You could use a hash table or a set. A hash table will allow you to check whether an element exists in the other list more easily. Sets—if your language of choice supports them—are an even better option.
Short Answer
An efficient way to solve this is by using two hash tables (or sets). We create a hash for each array. Then we loop over each value in the hash and check if the opposite hash contains that value. The final solution looks almost indistinguishable from the brute force version, but since the lookup time of a hash is constant, our runtime performance is reduced to O(n), which is huge improvement.
See a more detailed answer—including code—in Exponent’s Software Engineering Course.
Algorithm
Problem solving is at the core of what a software engineer does, and algorithms are the rule sets by which we solve those problems. You need to be ready to create and also explain algorithms to solve problems in your interview.
Note that the interviewers know that you will feel rushed and you won’t be crafting perfect code. They want to see you code, but they also want to see how your mind works when you’re solving a problem.
Question: Maximum profit
You and your friend have decided to start an international trading business. You want to earn a profit through some old fashioned arbitrage: You’ll buy widgets in one country and sell them in another at a higher price. Your friend has already found the current market prices for widgets in cities around the world, and you’d like to use this data to pick which cities to buy and sell widgets in.
Write a function max_profit(prices) that efficiently finds the two cities that maximize your profit (i.e. largest difference in prices).
Input: A dictionary with cities as keys and prices as values Output: An array (or tuple) containing the names of the cities (min, max)
Hint #1: You can think of this as two sub-problems: Finding the lowest price, and finding the highest price.
Hint #2: You can keep track of the lowest and highest values and update them as you iterate through the list.
Short Answer
For our solution, we’ll simply iterate through the prices list and simultaneously keep track of the minimum and maximum values we’ve seen so far. This only requires one iteration, so it’s more efficient than the ‘brute force’ approach of calculating the profit for each pair of cities, which would require O(n^2) time. See a more detailed answer—including the code—in Exponent’s Software Engineering Course.
Architecture
If you’re given architecture questions, it’s often to decide what level they’ll hire you at. These questions deal with the bigger picture. How do you go about designing an entire system to handle an open-ended problem?
The note from before about not needing 100% perfect code is even more true here. You’re not expected to develop an entirely new and perfect program during the interview. Instead, they want to see how you think about the systems of software engineering.
Question: Design Reddit
Imagine you’re the lead engineer responsible for building Reddit from the ground up. Walk me through how you would design the system to support the following functionality.
Requirements:
- Users can make posts in different forums (i.e. “subreddits”)
- Users can attach images to their posts
- Users can upvote or downvote posts
- Users can add comments to posts
- Users can see a feed of posts sorted by ranking or recency
Constraints:
- We want to support a large volume of users (millions) viewing and posting content
Hint #1: Think about the core components that you’ll need, and then dive deeper into them. What kind of database would you use? How will users interact with your service?
Hint #2: How does the large volume of users impact our architecture? What can we do to ensure that our system scales properly?
Short Answer
First, define the space. Start by clarifying the scope. What is required and what features do you desire? We’ve decided that want to focus on web users, we want to host user content directly on our server, and we want the content to load quickly no matter what region the user is in.
Secondly, it’s time to design the big picture structure of the system. The question tells us viewers need to be able to view content, post, upvote, and comment. We’ve decided we want an SQL database to store data about posts and upvotes, and then an object storage system for arbitrary files. Furthermore, we want application servers to perform “CRUD” operations on the underlying data, handle user authentication, and so on. Due to the scale of our system, we’ll also need many server instances (or even multiple points of presence), along with a load balancer to distribute traffic across these servers.
Finally, we would dive into the nitty-gritty details of the database, API, and caching systems. It’s unlikely that you’ll have time in an interview to get into much depth for all of these topics, but you should be prepared to talk at least a bit about any of them. Remember the interview is a discussion, so there will be some give and take.
And once again, for a significantly more in-depth discussion about this answer, check out Exponent’s Software Engineering Course.
