# Strategy Guide for Software Engineering Interviews

We’ll assume you’re already familiar with basic algorithms, problem solving techniques, and the typical interview format.

Strategically, there are two things you should be constantly assessing and calibrating throughout a software engineering interview. These are:

1. Your ongoing mental state, and
2. Your delivery of technical information.

We will explore how managing these factors properly will improve your interviewing performance.

## Mentality

Imagine you’re sitting in your dorm, waiting for a phone call from a software engineer. How do you feel? Excited? Nervous? More importantly, what’s the best mentality for success?

Netflix has a culture where they want employees to think of themselves as pro athletes on a sport team. As a candidate, you should think the same way: I’m a programmer; I am fully qualified for this job. I’m grateful for a chance to challenge myself mentally while demonstrating my capabilities to the interviewer. Repeat this until you convince yourself. Or at least until you hear the problem:

Today, you will implement a regular expression matcher. Given two strings named pattern and input, how would you determine if input matches the pattern? Assume pattern contains only lowercase English letters and the symbols * and +. (Adapted from Design of Computer Programs).

When candidates see questions they’ve never seen before, their eyes usually glaze, and they think: Huh? I’ve never heard that before. Is that even possible? Uh oh, I am so screwed.

However, as the pro athlete that you are, what you should think is instead: interesting problem - a worthy challenge! Since they’re asking this, it’s most likely solvable using the basic algorithms and data structures I know. Let’s see if we can break down the problem …

Starting with and keeping a confident, positive attitude is imperative.

## Problem Solving

So, after getting over the initial shock of hearing the problem, most people regress into “exam mode” - namely, they’ll think quietly to themselves until they’re ready to start coding. This approach is fatal.

Why? Because you’re not interacting with your interviewers at all. If the company wanted to know how well you can code by yourself, they’ll send you a coding challenge (and many do). That’s not the same thing as a live interview! Not only are you evaluated on your algorithmic knowledge, coding hygiene, and the typical assortment of technical skills, but also on how you present them. In short, they want to hear how you think. Think aloud as much as possible.

If you keep the interviewer up-to-date on your progress, it’ll also make correcting your mistakes less painful. Suppose you made a poor assumption at the beginning - if the interviewer notices the error after you write code, correcting it would be very costly or impossible. But if they hear the error before you start writing, then they can correct you if needed, and you can use their corrections or suggestions with less effort.

How can you talk to the interviewer effectively? You can:

1. Summarize what you know about the problem
2. Clarify any ambiguities
3. List sample cases
4. Solve a simpler problem
5. Consider related algorithms
6. Try a promising approach

Example:

So, we’re given two strings, right? Hmm, interesting. So one string is composed of [a-z+*] , but what about the second, input ? Just lowercase letters? Cool. What should we output? A boolean of whether we found a match or not? That makes things easier. What do the special symbols mean in this case? Match 0 or more and 1 or more of the previous character? I see. Wait, that means previous character must exist, and is in [a-z] right? Mhmm. What is a “match”? A substring match? No, a match must start from the beginning? Okay. So it should output true for ("dog", "di*og") , but false for ("dog", "di+og") , right? I see. There’s not much data to keep track of, so this probably doesn’t involve data structures like heaps or trees. That suggests the solution probably involves more of iterating over things in a tricky way to, say, mashing data structures together. If only we didn’t have the special symbols! Then we can just compare the strings for equality. Hmm …

Thinking on-the-fly is hard; talking and thinking on-the-fly is harder still. Practice, practice, practice.

## Getting Out of a Rut

Suppose you’re completely stuck - you simply cannot think of anything else. What do you do?

Sit there and think harder, dummy! Wait, not quite.

What you should do is ask for a hint. Because of pride, embarrassment, or simply not knowing they can, inexperienced students never ask for hints. But if you can’t make progress, what else can you do?

Of course, only ask for hints if you’re truly stuck, since this will be factored into your evaluation. If you’re on the verge of finding a solution, it may be best to think a bit harder instead. Use your best judgement.

I’m stuck - I can’t think of anything that’d work. Can you give me a hint on what I can try? Recursion? Oh right, I forgot about that. “Eat” different lengths? Let’s see …

## Delivery

One way or another, you should know how to solve the given problem by now. Should we start coding now?

Not so fast! Aristotle once gave three tips for delivering a speech:

1. Tell them what you will tell them
2. Tell them
3. Tell them what you just told them

Coincidentally, these are the same steps you should follow to present your solution memorably.

Step 1: Tell them what you will tell them

Before writing any code, you should first summarize your algorithm to the interviewer in a few sentences. This lets you …

• Re-organize thought processes;
• Most importantly, let the interviewer know what to expect.

This allows interviewers to make any final corrections to your approach if needed; interviewers rarely would want you to spend 10+ minutes coding a solution that is fundamentally flawed.

Example:

Okay, so what we want is a recursive function that handles three cases based on the 2nd character of pattern: a) no special symbol (really easy case), b) has a + as the second symbol, c) has a * as the third symbol. We handle the base cases (len(pattern) <= 1) explicitly. For the special symbols, we can try all the different ways of matching the first character of pattern from the beginning of input . Example: for input=dddog , pattern=d+o , we will absorb 1-3 “d”’s from the start of input, then recurse on the truncated substrings …

Step 2: Tell them

Only after you inform the interviewer of your finalized algorithm, and only after they agree with you it’s correct and efficient enough, should you start coding. But before you start, remember these two Laws of Interview Coding:

1. Don’t make mistakes
2. Code quickly

People typically code like this: they’d write something down, think a bit, write some more, delete a few lines, rename some variables, refactor a bit, and so on. If you do this during an interview, interviewers can mercilessly pounce on any bugs you make while coding. Make sure you can visualize the code before you commit anything down. Ideally, you want to write code that gets everything right on the first try.

Focused organization is a start. You can do this by:

• Declare any necessary data structures before writing functions;
• Declare what functions (and helpers) you’ll need;
• Write their signatures (i.e. inputs and outputs) before filling in their implementations.

The overall amount of work done is the same, but the overall presentation would be noticeably better composed, and the code would likely have fewer bugs.

Isn’t this process essentially the opposite of ‘code quickly’?

Yes, yes it is. No one said coding during interviews is easy. But to pass interviews, you have to do all of the above, as well as code at a high enough WPM to flesh out your solution in time.

Coding in a concise language (e.g. Python) helps. So does knowing how to use the language idiomatically (e.g. string slices, iterators, list comprehensions).

I recommend practicing solving problems just below what you can code comfortably in 15 minutes, then practice writing everything down, without editing what you have written halfway through.

Step 3: Tell them what you just told them

After you typing your final keystrokes, you’re done, right?

Not quite. You need to wrap everything up by:

• Explaining what your functions calculate
• Proving why your implementation is correct
• Showing how your implementation handle all the edge cases you can think of
• Scanning your program for bugs, and fixing them before the interviewer finds them

After this, the interviewer will likely say one of three things:

1. “LGTM! Now for an extension/another problem …”
2. “On line 42, you wrote foo instead of bar - why?”
3. “What if the input is (insert something you didn’t think of)?”

#1 means you’ve done well. Congratulations! Now onto the next problem.

#2 means you have typos. Ideally, you won’t, but these mistakes are harmless. After fixing them, you should quickly scan to see if you made similar errors throughout your program.

#3 is the most common outcome, so you should mentally brace yourself. By design, problems usually have edge cases that are difficult to think of. How gracefully you handle this scenario usually decides your performance.

If this happens, the first thing you should do is relax. Take a deep breath. Most people panic when they face this - you are not one of them. Your next sentences carry weight, so take your time. Carefully think through possible ways you can patch your program to avoid creating more bugs. Try to re-frame your perspective as if the technical challenge was to fix a bug all along. Once you’ve settled on a plan, implement your patch deliberately. At this stage, there’s no need to rush.

## Final Remarks on How to End the Interview

So, after you solved your technical challenges efficiently and effectively (or blundered so badly that the interviewer doesn’t want to see you writing code anymore), the interviewer would ask: do you have any questions for me?

Of course, there’s only one question you need to ask: how much will I get paid?

In all seriousness, you should honestly ask yourself: what do I care about? Personally, all my questions relate, in one form or another, to culture! They’re mostly variants on: what’s it like to work here?

More than anything else, I think this is probably the most important part of the job I need to clarify, which is also something engineers can answer more authentically than, say, recruiters can.

But if you simply ask a generic question like, what’s it like to work here?, you’d probably get a generic response: oh it’s pretty good, coworkers are nice, and such. More informative questions may be:

• How often does your team eat lunch together? This is a signal of team/company cohesion, friendliness, and such.
• What sort of projects have interns shipped out before? These examples give you an idea of the calibre of work you’d do.
• What is something you think the company can do better culture-wise? This signals how much employees are aware of the company’s human issues (which every company has), as well as how much the company invests in improving its culture.

I hope my questions will inspire you to think of ones you find meaningful.

Software engineering interviews are pretty random - sometimes, you fail when you do everything right, and pass when you don’t. With these tips in mind, you’ll have a better experience next time you interview.