One of the hardest aspects of getting a software engineering job is getting the interview in the first place!  As a principal engineering manager and engineer not only have, I been through the interview process repeatedly, but I’ve also conducted dozens of interviews to fill positions on my teams.  In this article I’m going to walk you through the interview process and give you an inside look as to what we look for in a candidate.

As is the case with most things, what happens in interviews will vary depending on the company.  Most of my experience with hiring has come from big companies (Google, Microsoft) and medium sized companies (Door Dash), though I have interviewed (as a candidate) at other sized companies.

The Informational

If you are applying for a job at a specific team, you may have the chance to do an informational interview first.  This is chance for you to “interview” the team and ask questions to make sure the role is a good fit for you.  This will often be with the hiring manager but could potentially be with a recruiter that will be working with you through the interview process.  While this is supposed to be informal, first impressions matter.  For most of the interview you will be asking questions of the hiring manager, but they may take the chance to ask you more informal questions about your resume or your experience so be prepared.  The team will still be filtering the list of people who apply to decide who gets to interview so use this as a chance to make a good impression.

The Phone Screen

A phone screen is a lightweight interview to act as a first line filter so that they don’t need to spend doing a full interview on candidates who don’t meet the bar.  You do need to prepare for this, but it will generally be less difficult than a full interview.  I’ve seen the quality of phone screens range from a full algorithmic question to pre-selected questions that the recruiter just reads off.

Online Screening Quizzes

One of the alternatives to phone screens is to have an online quiz to filter candidates.  The team will select a question or set of questions and send it out for a large pool of candidates to answer.  The quiz is essentially open book, and you are given a week or so to complete it and return it.  The team will then grade all the quizzes and select the next step of candidates to move to a full interview.  The questions can range from an open essay like “Describe how packets travel through a network” to more specific questions like “write out the code for merge sort”.  Sometimes they will use online quizzes where you must send an answer that compiles, like websites like leet code.

The Interview Loop

If you make it through the next phase, you’ll generally move ahead to the interview loop.  An interview loop is when you go through interviews with multiple people in a company.  Depending on the role it may be with all engineers asking algorithmic questions, but it also can be other roles at the company such as a tester or a program manager to see how you would interact with them.

How We Select Questions

Usually when a loop is setup, each interviewer will be assigned a core competency.  We want to make sure that we test all the different areas and don’t overlap with what we are asking.  Some example areas include:

• Technical (algorithms)
• System Design
• Scalability
• UI Design
• Team compatibility / Culture fit

At Microsoft it used to be that after each interview we would discuss the candidate to decide if where if anywhere we needed to dig in to get more information but that has fallen out of practice since it could create bias for the latter interviews.  In some companies they allow one interviewer to leave notes for the next interviewer in case more specific information is needed.

The Interview

The interview will generally start with introductions and the interviewer might ask you to give a brief overview of your work history.  The interviewer may choose to dig into a particular project on your resume to get more details, and to make sure the projects you listed are accurately represented.  I have had many cases where I’ve asked someone about something on their resume only to find out it an exaggeration.  You should be able to explain everything on your resume in detail, or you should leave it off.  Getting caught in an embellishment on your resume can be an instant disqualifier.

The S.T.A.R.R. Strategy for Experience Questions

You want to have a strategy for how you answer behavioral questions to make sure you provide a complete answer without rambling on and forgetting to include important details. 

To manage this, I practice using the Situation, Task, Action, Results, Reflection or STARR method.  Using this method, you briefly describe the situation including relevant context and external factors.  You then move into the task at hand.  What did you have to do?  What were the goals?  Next you describe what action you took.  Make sure you detail specifically what your role was in the situation, but also talk about how you worked with others and showed leadership in the situation.  This is the meat of the question and your chance to really show the impact you had.  You can then wrap up your story with the results.  What concrete results can you show?  Did some process get improved?  Did you improve customer satisfaction by 5 points?  Or maybe you increased code coverage by 20%.  Be detailed and provide concrete values to really make it stand out.  Finally reflect on what you learned from this.  It shows great introspection and maturity when you describe how you used the experience to grow yourself.

One important note here is to always be positive about your situation and experiences.  Never talk poorly about your current team no matter how dire the situation, it just makes you sound like a jerk.  Be kind and forgiving of your current team.  If your team failed, try reframing it as creating a learning opportunity, not as a failed project.  If there’s something your team isn’t good at, pose it as a chance for improvement. These are all important attitudes to have in general, but especially important when you have a short time to make a good impression.

Have a Plan for Coding

The most critical part of the interview process of course is the coding question(s).  I won’t go into detail on how to answer specific questions (there are way too many of them) but I do want to talk about the strategy for making sure you cover all the important parts of the question.  As with behavioral questions I like to break the process into steps.  Unfortunately, I don’t have a great acronym for remembering all of this, so you must put the work into remembering the steps.

1. Ask clarifying questions. The first step is to ask clarifying questions.  This is something a lot of interviewers look for explicitly.  For me it’s a red flag is the interviewee instantly jumps into the problem headfirst without first making sure they understand the question.  Look for edge cases or things that the interviewer purposefully left ambiguous.
2. Find the right tools. Often these algorithmic questions are meant to see if you can use a specific tool. Instead of generically trying to solve the problem, see if you can apply a specific data structure or algorithm. Commonly I’ll look at hash tables, lists, trees, and heaps. I’ll look specifically at if the problem gets any easier if we sort the data first and think about what type of sort I’d use. Generally, graphs are too complex for a 1-hour interview question but if all others fail, I’ll also look at how I might use those.
3. Write the algorithm and examples: Again, to reinforce your understanding of the question, walk through an example without code.  You can do this quickly and it helps you think through the challenge without getting tripped up on the specifics of code.  You can also verify with your interviewer that the output you got from your input matches their expectations. This is also a good time to talk about optimizations and tradeoffs that you considered when designing the algorithm.  If you can get the correct answer here, the rest will be very straightforward.
4. Edge and error cases: Once you’ve got the basics down, try thinking about edge cases.  Can the input be null?  What about an empty array?  Try out some of the edge cases on your algorithm to make sure the right things happen (which you can verify with your interviewer).  Should the null case return an empty array?  Or should it throw an exception?  Take note of any edge cases you find and remember them later for test cases.
5. Confirm the solution: It depends on the interviewer, but sometimes you can just ask their opinion directly “does this meet your requirements”. Some won’t tell you but sometimes they’ll respond with an affirmative.
6. Break down the problem: My next step is to break down the problem into functions.  This demonstrates that you know the importance of modular code, and helps you think of the problem in parts.  Write each part individually.
7. Test Cases: I have seen a lot of cases where a candidate got a “no hire” because they didn’t think about test cases.  It’s important to show you know the importance of testing, and writing test cases will help you make sure your solution is correct. To preserve time don’t write the tests first but do at least mention them.
8. Code: The next step is to write the actual code.  If you’ve already come up with a successful algorithm, you have most of the hard work done.  Now you can focus on the code without worrying if the algorithm will work or not.  Focus on the traps that are common in your programming language such as null pointer dereferenced, forgetting to free memory, or over indexing arrays.
9. Walk through the code with your values from step 3: Once you’ve come up with your code, including error cases, take the values from step three and walk through your code.  You should get the same results.
10. Bonus: Write tests: We already thought about tests but if you have time, you can write the tests.  I find I rarely get this far which is why it is important to mention tests early on.

The Evaluation

Each interviewer will write up their feedback after the interview while it’s fresh in their mind.  If the company hires for specific teams, after all candidates have interviewed, they will have a debrief where they discuss each candidate.  Some companies use hiring committees to ensure there is a consistent hiring bar across the company.  Functionally, it’s the same as a debrief but instead of the team that is hiring conducting it, it will be a panel of engineers who look at the packet blindly to prevent bias that the interviews may have had.  Because there are often multiple people applying for a given job, it’s important to solve the interview questions, but also to stand out as someone the interviewer would want to work with.

What I look for

Finally, I’d like to share some tips on what I look for when evaluating a candidate.  The prime measure I use above all others is, would I want to work with this person?  I’d rather have someone who took longer to solve the problem but was open to feedback and guidance and was a pleasure to talk to. 

Communication is key. When they get stuck do they communicate their thoughts, or are they stubborn and defensive?  I’ve had a candidate tell me I was wrong and rebuff my advice, which is never a good idea. Not only does it make you seem obstinate, but it’s also very likely your interviewer has asked this question a dozen times and knows the answer inside and out.

I also look for how you process the problem.  Do you dive right in without asking questions?  Do you verify your design works, or do you constantly backtrack and have to correct yourself?  I also look for a positive mindset. Do you get frustrated by a hard problem, or do you enjoy the challenge and express curiosity?  The key takeaway here is that it’s not just about solving the presented problem, how you got there is just as important as the destination.

Hopefully this gives you some insight into the interview process to make it less scary.  Every company will have a unique process, but this should give you a general feeling of how the interview process progresses. If you’d like to know how to study and plan for the interview process see my article on that topic here