#2 Maximizing Success in Engineering Interviews

March 25, 2019 · 8 mins read

1:1s

Here is today’s 1:1 topic — finding success in software engineering interviews. The person I spoke to is new to tech and has been feeling frustrated understanding how to maximize their chances of success. This is largely because they haven’t received much feedback on what to improve on post-interview.

Trying a little experiment: starting next Sat (03/09), I'll be doing one-on-one meetings with people from under-represented minorities who are interested in: career/manager/tech advice, feedback on conference proposals, and more!

💁🏻‍♀️ Go here to apply: https://t.co/O2ve1Lp0pl
— lauren (@potetotes) March 2, 2019

I honestly struggled putting together this post. There is much that isn’t right about the tech interview process, but I’ll save that for another time. This guide is for maximizing success in that interview that’s coming up for you next week.

Note: This post is based on my own experience, and is highly dependent on the company you’re interviewing with. I’ve tried to keep this as widely applicable as possible.

Before you begin

The thing that sucks the most about interviewing is that they are hugely one-sided in the power dynamic. As a candidate, you don’t really know what the company is looking for, and it’s easy to walk away from interviews feeling like you’re a failure. Remember: if you’re not finding success at interviews, it doesn’t mean that you’re a bad software engineer. Interviews are poor proxies for approximating the day-to-day work that software engineers actually do, and they often get it wrong (companies consider false negatives preferable to false positives).

Interviews generally suck and there’s no reason to feel bad about not being good at it. Learning to separate your value as engineer/self-worth from your interviewing skills will greatly help with your mental health. Please take the time for self-care!

What do interviewers look for?

Software engineering interviews generally try to answer these questions in different proportions. When you’re answering questions, keep these general areas in mind:

At a minimum, can this person do the job? If not, can we teach them?
Do they “raise the bar”? (i.e improve the team’s ability to execute)
Will they be successful in our team/company’s culture?

Depending on the needs of the company, the specifics may vary. These areas should be pretty common though. Think of an interview like giving an interactive presentation. It’s an artificial setting where you’re trying to communicate the value that you’ll bring to a team. Knowing what they’re looking for will help you adjust your approach and present your best self.

How do I demonstrate that I can do the job?

These are questions that involve your core skills as an engineer: problem solving, logic, breaking down large requirements into smaller tasks, knowledge/usage of specific technical concepts, and most importantly communication.

The kinds of questions you’ll get in this area depends on the role and company you’re applying for. Some places might place emphasis on CS fundamentals like data structures and algorithms. Others may focus on practical questions (ps: check out my hiring-without-whiteboards repo for a list of such companies). Regardless of what you get, the approach to answering them is mostly the same. The interviewer is trying to understand if you have the necessary skills to do the job, so help them out.

It’s important to remember that any question that involves technology can fall into this area. For example, even the question “Walk me through a particularly tricky project or challenge you tackled, and how you went about it.” has a technical component to it, although smaller than a fully technical question. Even seemingly “pure” technical questions will test you on important skills such as communication.

When you get a question in this area, take these approaches:

Work the question

For technical questions, this usually means starting with the simplest approach. The interviewer will then expand the scope of the question by asking you additional questions that make it more complex. For questions such as the “tricky project” one, start high level, then go into more details. For example: “One of the most challenging projects I worked on was Project Donut. The requirements were confusing, and we had to implement a complex data-driven UI that had a lot of perf constraints. To be specific, I had to work closely with our PM to clarify what the requirements were. They were new to the company and didn’t have a lot of context about the users we were trying to help. […] We first tried doing X to render all the items on screen, but this turned out to cause a lot of jank when scrolling. We then tried doing Y which […]”

What level of technical detail would they like you to go to? Will this list contain only integers? Would they prefer you spoke about a technically challenging project, or an organizationally challenging project? Asking for context will help you understand what the interviewer is looking for, and reduce the amount of guesswork you have to do.

Even if the interviewer is technical, explain what you’re doing and why. Don’t assume that they already know what it is. If you’re unsure, you can always ask if they would like you to explain something.

Throughout the interview, your interviewer may share feedback with you. If they’re suggesting something, go with it! It’s very rare that interviewers will try to mislead you or throw you off. If they suggest something, it’s usually because they’re trying to help.

Compare the tradeoffs

There are always pros and cons to every approach. Be prepared to talk about what you gain and lose from either. Why did you choose X over Y? Which would you recommend given the context of the problem? If you were to revisit this challenge again, what would you do differently?

Be honest

This one is arguably the most important. Just because you don’t know something doesn’t mean you’re not qualified for the job. How many super senior engineers still need to google stuff? 🙌🏻 Be honest if you aren’t familiar with a concept, don’t try to fake it because it’s easy to spot someone who doesn’t know what they’re talking about. This isn’t to say that you shouldn’t attempt the question, but set the right expectations before you do.

Do I raise the bar?

This area is much more subjective. There aren’t any specific questions that interviewers will ask you. It depends on the team and what they’re looking for. How you can show this is mostly about how you answer their questions in both technical and cultural rounds. One way to suss this out is to ask your hiring manager in the first few screens if there is anything specific they’re looking for that would make someone successful in this role. For example, they might say that they need someone with distributed systems expertise, or someone who can lead a project. You can use this information to adjust your approach in answering questions.

If you don’t get a specific answer, you can still tell based on the kinds of questions they ask you. If they ask you very specific questions about certain technologies or paradigms, you can probably guess that that is a skill they’re looking for. If the questions are pretty generic, they might not know what they’re looking for. In these kinds of interviews, try injecting bits of your strengths into every question. Even if you’re answering a technical question, you can add more information. For example, “if this were a real world problem, I would spend some time with the PM and designer to better understand what the user experience should be. Even though we could put hundreds of thousands of items on screen, it might not be the best experience for our users.” or “when we tried this approach, it improved the performance of our app by 20%. There was actually more performance I thought we could squeeze out by doing X and Y, but after speaking with my manager and considering the constraints of the business, I decided to put that on the backlog and tackle more pressing needs first.”

Being successful in a company’s culture

Another way of looking at a company is that it’s a group of people. The way groups of people interact, what they consider acceptable, and what they don’t, defines the culture of that group. Most companies these days have cultural values on their jobs pages (for example, check out Netflix’s culture memo). The company you’re applying for will most likely have one of their own as well. The point here is to do your homework before you interview. If you feel excited after reading a company’s culture page, it’s a good sign that it could be a great place for you to work.

Keep in mind that both you and the company are interviewing each other to see if there is a mutual fit. How the interview process works, the interviewers’ attitudes, and the kinds of questions they ask (or don’t ask) will tell you a lot about how they work and what they value. Asking questions will help you understand if it’s a place you want to work at:

Tell me about a time someone on your team was promoted (what do they value?)
Tell me about a time someone on your team was let go (what’s unacceptable?)
What was something questionable you’ve been asked to do recently? (are they evil?)
What was something you did recently even though others disagreed with it? (do they trust their employees?)

These answers will help you evaluate their claims about the company’s culture.

Ugh

Interviews aren’t the most pleasant experience, but they can be prepared for. If you’re still struggling, ping me on Twitter and I’ll try my best to help.