Tips for interviewing

Engineering interviews can be challenging because we often feel like we know how to code, we have samples of our work and these samples should be good enough to get us hired. From a hiring manager’s perspective though, development is usually a team effort and no matter how great a coder might be, if he doesn’t fit in with the group, it can make for a less-than-awesome work environment. Also, skill-sets vary from company to company and it’s important to remember that a hiring manager needs to find a person with the right experience and temperament for the position.

It’s as important for the interviewee to land in a great spot as it is for an interviewer to find a good engineer so the interview process should work well for both parties. So like it or not, interviewing is just part of the process of landing a great contract.

Here are some tips for getting prepared to ace your technical interview.

Know Who You’ll Be Meeting

If you’re interviewing at a start-up, you’ll most likely be meeting with a senior developer, possibly the CTO) and definitely members of the dev team. You’ll probably “cut to the chase” and focus on technology because the interviewers will likely all be engineers.

Larger companies often have additional interviews with HR or recruiters and possibly non-technical managers. These interviews look for soft skills: how you collaborate, communication skills, and how it might be to work with you on a team.

Know your audience! Tech-speak is great for the engineering interview but probably less great with a non-technical interviewer. Facet will give you background on each of the people you’re meeting with so you can appropriately prepare.

As for the technical portions of the interviews, you will be asked challenging technical questions that are often not related to anything you do, day-to-day.

The Interview Process

In general, there are three distinct parts to an engineering interview, and they are usually in this order, and are broken out in detail below.

Coding: This is usually first, because if you can’t code, it’s not worth moving forward.
Behavioral or working style: While actual programming is a solitary work, building software is usually a team endeavor. Companies want to ensure you play well with others.
Design/architecture: Once the basics are done, then comes the test to see how you envision the bigger picture.

Coding

It’s not enough to talk about your qualifications and why you’re right for the job, you must prove it. And that means a coding challenge.

Challenges may be online (hosted by sites like CoderByte) or on a whiteboard; and the exercise is usually done with your interviewer in the room.

Here’s what the interviewer is looking for during the coding portion of the interview:

Can you actually code? (This seems silly, but you’d be surprised!)
How do you approach the problem?
Are you methodical or do you try a bunch of stuff to see what sticks?
What do you prioritize (e.g. speed, cleanliness, elegance)?
How do you manage your time?
What happens if you get stuck?
How do you test?
How do you document your work?

Dos and Don’ts
We’ve seen great coders get hung up on simple coding tests so consider these dos and don’ts:

Do understand the problem you’re solving. Don’t just jump in before you’re clear about what you’re trying to accomplish.
Do think out loud. Part of the purpose of the code challenge is that the interviewer can see how you think. Don’t be shy!
Do practice coding problems. When you practice, don’t do it silently, but talk out loud as if you were in an interview setting.
Do brush up on technical jargon. Don’t think that because you’ve been coding in a particular environment, that you still remember how to explain what you’re doing.
Do review key algorithms. Don’t go in without having practiced.
Do ask questions, especially if there are multiple solutions. This is an exercise to see not only your coding skills, but how you approach a problem. That said, don’t ask questions that are not going to help you get started.
Do focus on the path of least resistance. Don’t get hung up on edge cases. Work on edge cases at the end when time allows.
Do focus on making your code work; having a working sample is more important than having a “pretty” sample. Don’t waste time if time is running short.
Do make it clean. You’ll be working with others so be sure others can actually read your code. Don’t declare every single thing; use comments efficiently. (If your coding requires that much comment, consider useful naming.)
Do be consistent. Don’t leave unnecessary logging and debugging statements.
Do add data validation and error handling if you want to stand out. Don’t spend time on this exercise at the expense of making it work.

Behavior/Working Style

While “soft skills” might not seem important for engineers, how teams work together can actually make or break a product. There is no way to know exactly what to prepare for but there are some basic types of questions that are asked. Here are some samples:

Tell me about a product you worked on. What part did you build? How did you work with other developers during that process?
How do you check your work? How do you ensure your work is bug-free?
What code are you most proud of and why?
What mistake would you like to take back?
Tell me about a time when you were under an unreasonable deadline. How did you get through it?
Tell me about the best and worst teams you’ve worked on.
Why do you want to work here? What will you contribute?

Dos and Don’ts
Remember to find pride in your work and yourself. And consider these tips:

Do be your authentic self. Don’t try to guess what the company is looking for.
Don’t finger-point. When asked about something that went wrong, do take responsibility for your part. Interviewers are looking for people who take responsibility, not a blamer.
Do talk about what you learned, especially from your mistakes.
Do talk about an awesome project and specifically what your role was within the team. Talk about how the team worked together. Don’t take massive credit for a project where an entire team was involved.

System/Architectural Design

In the system or architectural design part of the interview, you may be given a product and then be asked to design the system or architecture. While the coding portion of the interview is the actual nuts and bolts of building something, the architectural portion is about designing the blueprint.

During this part of the interview process, there are no right or wrong answers. (Of course, there are better answers than others!) This is a test of how you would approach a problem and how you would go about solving it.

Here’s what the interviewer may be looking for during this part of the interview:

Can you think strategically and see the big picture?
Do you ask the right questions?
Do you understand how to scope a problem?
Do you understand scale?
Are you good at parsing the big problem into many smaller problems?
Can you create clarity out of something fuzzy?
How do you handle trade-offs?
Can you make progress through a problem?
What is the breadth and depth of your knowledge?

Scope the Problem
The first thing is to ask clarifying questions of the interviewer and agree on the scope. Come up with use cases for the main functions and ask questions about requirements. Find answers to questions like: What is the goal of the system? Who will be using this? How will they use it? What inputs does the system need to handle?

Find out the constraints, like traffic and scale. How many people will be using this? Will they be using it all at the same time? Are they geographically distributed? Is there special functionality required?

The purpose of the clarifying questions is to narrow the scope in order to start. There are questions that must be addressed in big gnarly systems, and the purpose of this exercise is not to solve every single thing – because that is impossible in 45 minutes – but to decide what you’re going to work on during the time you have. It is vital to keep moving forward!

Start High, Then Drill Down
Cover the end-to-end processes needed to establish the goals you’ve set. What systems will you need? What kind of services, data storage, caching systems are required? And how will these systems work together?

Then, what are the components to be designed? What APIs are required? What does the data structure look like? How do these components relate to each other?

Talk About Failure
Have you addressed availability and reliability? What about bandwidth, latency and security? How are errors handled? Are you ignoring bottlenecks? What are the hidden costs?

All these questions must at least be addressed, if not answered. While you do not have to be an expert in every single topic, you must at least know about them. That way, you instill confidence that, if you run up against something that you’re less than familiar with, you’ll know the right questions and when to ask them.

Dos and Don’ts
The architectural portion of the interview can feel most elusive. Hang in there and remember these things:

Do grind through it. Even if the problem is not your area of expertise, the interviewer is looking at how you apply your total knowledge to problem solving.
Don’t stop. If you’re stuck, it’s better to ask for help than to just sit there, stuck.
Do be creative! This is an opportunity to show who you really are. Don’t worry about right/wrong. Design interviews measure your ability to think, not get the actual answer.
Don’t lose track of time. The interview is generally 45 minutes or so and it is impossible to solve a huge problem in that amount of time.
Do practice! Find sample questions below and FDN members are available to go through the process with you.

Resources

Here are resources to help prepare you for your interview.

General
25 Things I’ve Learned in 250 Interviews (at Google)
This video is long (one hour) and while it’s from the interviewer’s side, there is a lot of great information. Plus, if you have someone who is less than great at interviewing, this may help you get through it.

Coding
Here are practice coding questions for you to tackle:
Practice for Engineering Interviews
Practice for Cracking any Coding Interview
Top 10 algorithms in Interview Questions
Algorithm Study Materials
Commonly Asked Algorithm Interview Questions | Set 1

There are engineers that have posted videos on this topic. And while you may find that your solutions or style are different, here are some perspectives for you to consider:
How to Crack a Google Coding Interview - An Ex-Googler’s Guide
Coding Interview Problem: Largest Rectangle in a Histogram
Coding Interview Problem: Calendar Conflicts
Coding Interview Problem: Dinner Party
Coding Interview Problem: Least Disruptive Subrange
Actual Coding Interview @ Slack

Behavioral
Sample behavioral interview questions:
10 Must-Ask Interview Questions for All Engineers
7 Engineer Interview Questions and Answers
Engineer Job Interview Questions

Video on behavioral interviews:
Intro to Behavioural Interviews

System/Architectural Design
Practice questions:
System Design Cheatsheet
How to prepare system design questions for an IT company
Crack the System Design interview: tips from a Twitter software engineer
System Design Problems

Video on system/architectural design interviews and problems:
Intro to Architecture and Systems Design Interviews
Seven System Design Interview Questions (Seven separate videos of different topics)