How I Interview

At Blizzard I had a reputation for being tough during interviews. I was the guy who would ask for additional time with a candidate and could easily spend 2 to 3 hours with someone. I don’t claim to be perfect at it, but I do have a system that I think works and works pretty well for interviewing people for technical positions. Coniser this blog post version 1.0.0 of Nick’s Technical Interview Guide.

Before You Begin

Interviewing someone for a technical position is complicated and goes well beyond technical prowress and know-how. Candidate expectations, company expectations, company and team culture, communication ability, technical ability and personality are all factors that should be carefully evaluated. This document focuses on technical ability and how to determine what you are looking for and if a given candidate is a good fit.

The Holy Trinity

There are three things that factor into gauging the technical ability of a canidate:

  1. Fundamentals / Computer Science Knowledge
  2. Tools / Software / Libraries
  3. Domain Knowledge / Language

The first point, fundamentals, is the depth and bredth of knowledge that can be applied to any langauge or domain. This includes knowing object-oriented design, threading and concurrency techniques and models, data structures and algorithms, architectural patterns, etc.

The second point, tools-software-libraries, is really about specific application, toolkit and library knowledge and usage. An example would be knowing details about selenium or vagrant but also extends to more domain/language specific things like Spring or Tomcat.

The third point, domain and language knowledge, is how well the candidate understands and is able to apply knowledge about the field they work in and languages used to the day to day tasks of the position. An example would be, as a Java SWE, understanding and having experience with generics or as a front-end engineer, understanding javascript class implementations and quirks.

Holy Trinity Balance

In my experience, you can’t and shouldn’t expect a candidate to have an even amount of knowledge and experience in each of the three categories. Different positions require a different amount of each and you’ll probably have different needs depending on the team that the candidate will be in.

Consider the following positions to be filled.

QA Engineer: Expectations include working with software engineers and developer support teams to test and exercise an application before deployment.

Software Engineer, Application: Expectations include implementing features for and maintaining a codebase for a user facing application.

Software Engineer, Platform: Expectations include implementing services, libraries and applications used by other software engneering teams that may be distributed, multi-region and data heavy.

Software Engineer, DevOps: Expectations include working with software engineering teams to support the development, deployment and management of the applications and libraries developed.

Based on the descriptions of the above positions, you can start to see how the balance of technical ability can vary. For the QA Engineer position, I may expect them to be weaker in areas 1 (fundamentals / computer science) and 3 (domain knowledge / language) but be very strong in area 2 (tools / software / libraries).

For the Software Engineer (Application) position, I may expect them to have a more even balance of the three. However, for the Software Engineer (Platform), I may need them to be strong in area 1 over area 2.

The Software Engineer (DevOps) position is an interesting variant because I may want them to be stronger in areas 1 and 3 and weaker in area 2.

In addition to balancing the tehnical ability requirements for a position, you may need to factor in team and company needs. Consider a situation where you may have a team that is very strong in area 1 but is very week in area 2. It may be worthwhile to bring on team members who have substantial experience in areas 2 and 3 to bring balance to the team.

Before The Interview

Before the interview, have the candidate send you some sample code. Ideally, the candidate can provide you a link to their GitHub or BitBucket account and has 2+ projects that they’ve contributed to. If possible, look through both older code and newer code of the same language and make note of the evolution of their style and quality. Being able to determine growth and direction of change could make the hiring decision very quick and easy.

If the candidate does not have any publicly viewable code available, consider giving them a sample project to work on. My personal preference is to contact them directly several days before the interview with a small project that can underscore personal style preferences, project organization and code quality. I would lean toward making the project less difficult over more difficult as this isn’t a direct test of competance but instead a way to quickly gauge code quality. At the end of the day, good engineers will solve simple problems with simple solutions.

During The Interview

When going into an interview, consider the following tips:


Based on the above areas are several sections and subsections of topics and questions. This is the checklist and flow that I use when working through a technical interview.


In the next section is a checklist of sorts that is broken down into each of the three areas. Before you start reading through it, it is important to calibrate your expectations of the position(s) you are trying to fill. The checklist that I outline descibes someone in the senior/staff software level. Your millage may vary.

What I advise is to print this out and with different colored highlighters, mark things that you want or expect candidates of different levels to understand. For example, highlight in green things like OO design, MVC and some basic data structures/algorithms to note things that your lowest level software engineer should be familiar with. With yellow, highlight things like unicode, unit testing, select design patterns, etc to note things that your mid level engineer should be comfortable with. You may also use a color like red or underlining to note must-have knowledge or comfort with a particular topic. If your team deals works with many regions and languages, knowledge of unicode may be a must.

Area 1: Fundamentals / Computer Science Knowledge

Object Oriented Analysis & Design

Data Structures and Algorithms

Big-O Notation

Design Patterns?

Architectural Patterns

Computer Organization Basics

Network Basics



Area 2: Tools / Software / Libraries

Development Environments

Operating Systems Basics

Software Testing, Automated

Dependency Management, Maven

Continuous Integration

Version Controlling Systems

Area 3: Domain Knowledge / Language

This area is java specific and is based on the tech stacks that I’ve been using for the past several years. Your millage may vary.

DI (Dependency Injection)

ORM (Object relational mapping)

This may or may not be useful to you. At the very least it can get a conversation started.

Requirement Analysis

Writing Clean Code

Service Design

Data Warehousing

Capacity Planning