Interview prep for software engineers

What is a typical software engineering interview with you like?

Answer by Gayle Laakmann McDowell, Consultant (tech hiring/interviewing), Author (Cracking the * Interview):

My role in an engineering interview (when I was at Google, and when I’m doing interview coaching now) is typically to focus on coding/algorithm questions.

Typically, I start off with a few minutes of behavioral questions. I ask big open-ended questions, partially to get the candidate comfortable. I might ask for a general “walk me through your resume” or “tell me about a challenging project you’ve worked on.” If this is interview coaching, I’ll give feedback at this point. Often the feedback is that while they told me about a challenging project, they haven’t really said what the actual challenge or hard stuff was.

After this, I’ll ask a coding/algorithm question. I tend to only ask one question, but it’s a challenging one (and it’s not a well known one).

My favorite questions are ones that have a reasonably obvious algorithm that the vast majority of candidates could come up with.

You’ll come up with an approach reasonably quickly, probably. If you’re having trouble, I’ll make some suggestions. I’ll start off with simple “interview tactic” suggestions (e.g., not problem-specific hints, but things that help you perform better), but I might get increasingly specific as necessary. Often, this might be prompting you to develop an example or to make your example larger.

You’ll make an optimization or two, and then I might ask you to code what you have. This is often just ten minutes into the interview. I like to do this early on in the interview, to get the coding portion out of the way early. We’ll come back to optimizations later.

You’ll write the code and I’ll do some things to make your life easier. For example, I might suggest that it’s okay to use abbreviations, especially in more verbose languages.

If you’re having trouble writing the code, this is often because you didn’t think through the approach carefully enough before writing. I’ll suggest that you go back to your example and think through it again.

I try to be very friendly and reassuring, regardless of how you’re actually performing.

Once you write the code, I hope you’ll test it. I worry a little with people who just say “ta-da, I’m done” as though any code they write is correct. Test your code!

If you throw in a large test case, I’ll stop you early on and encourage you to use a smaller one. I’ve done a lot of interviews and I know that a big test cases will be time consuming, but typically no more effective than a small one.

If you find a bug, I hope you can fix it on your own. I’ll give you help as necessary during the coding/testing, but it’s best if you can do it independently. When I feel like I’ve gotten the information I need out of your coding/testing, I’ll switch you back to the algorithm—even if your code isn’t 100% correct. (My goal is to evaluate, not to get you to write correct code.)

Now, we have all the time in the world (or until the interview ends) for optimizations. That’s why I like doing it this way. I used to do the optimization piece first, and then all the coding. What I realize though is that I need to see code. I don’t need to see code that happens to be for the perfect algorithm. If I do this early, and get it out of the way, I don’t need to guess how long I need for coding.

The optimizations piece is much like it was before. I’ll give you help and guidance to the extent necessary. You might develop an optimal algorithm, or you might not. It depends, but whether you do is not totally indicative of how you performed. Again: my goal is not to get you to the perfect solution. My goal is to evaluate.

You probably won’t walk away with a great feel for how you did. I want you to be comfortable and reasonably challenged, regardless of your performance. So I try to be nice and positive while also challenging you.

At the end of the interview, I offer you a chance to ask questions about the company/role/me/whatever (or that’s what I would do, if I were working for another company). The interviews I do nowadays are actually coaching, so that’s when I’ll give you some additional feedback and let you ask any questions you have about the process, me, or whatever you’d like.