Giving an excellent technical interview

There are several things I do in my technical interviews which I think make the experience quite a bit better than your average interview.

The first step comes before the actual interview in selecting the technical question. I have a few which I’ve created myself based upon actual problems I faced as a professional developer. They are, of course, somewhat simplified to be able to fit into an interview time slot, but they have the ring of a “real” problem rather than some annoying “toy” problem. Each question is intended to have multiple “extra features” you can add to it, so every candidate is able to complete at least part of it, and exceptional candidates can complete several. Only once have I had a candidate who completed all of the sections I had prepared.

Second, as the interview starts, I deliberately adopt a fairly casual, friendly, outgoing attitude, and chit chat. If possible, I try to crack jokes, and put the candidate at ease. I try to get them to tell me stories about something which will give me a sense of whether they’d be a good culture fit with the company and our team.

Then, as I introduce the technical question, I make a few points right up front to try to take some of the anxiety out of it:

  1. This is a pair-programming exercise, and the primary point is to see how well we like working together.
  2. I’m not particularly interested in seeing how much of the language you’ve memorized; if you’re uncertain on something, just ask, and we’ll look it up, if necessary.
  3. I’m not as much interested in how quickly you solve the problem, but how you approach the problem, and how you think it through.

At this point, I turn my laptop around for them, and either project the screen or slide my chair around so I can see what they’re doing. On the laptop is a basic IDE already set up with a “hello world” program and a simple test case. There’s also a browser with Google brought up.

I think this is the most important part.

I want to make the impossibly contrived interview situation as close to actual working conditions as humanly possible. Starting with a simplified, but realistic problem, continuing with real tools (i.e., IDE and Google), and ending with us looking at the same screen, side-by-side, I’ve tried to emulate, as closely as possible, a situation developers find themselves all the time: pairing up to write a piece of code.

As we start to work on the problem, I try to strike a balance between being a helpful part of the pair programming team, and leaving enough of the problem for the candidate to solve that I can evaluate their performance. The more junior the candidate, the more helpful I am. The more senior, the less. If a candidate seems to be stuck at any point, I’ll suggest a possible solution.

During this process, I will deliberately probe a candidate to see how they react when:

  • I suggest something which isn’t the best solution.
  • I directly contradict a course they had chosen.
  • I point out a minor typo or error in their code.
  • I press them to justify a design choice.

I never interrupt the natural flow of the conversation to do these things, but I always have my eyes open for an opportunity to slip them in. In all of them, I’m looking for the candidate to have the best possible answer in mind, and to neither try to boost their own ego or mine.

As we get to the end, I keep my eye on the time (easy, since we’re looking at my laptop where I keep it up in the corner), and let them naturally stop when we get to the end of a part with somewhere between 5–10 minutes left. At this point, I let the candidate ask me questions for the remaining time.


I think the important take-away here is to try to make the interview feel as much like a pair-programming session on a real problem as possible. Pick a problem which isn’t directly from an algorithms textbook. Set up a real development environment for the candidate (for coding questions). Sit next to the candidate and look at the same screen, just as you would for a pair-programming session (or stand at the whiteboard with them, for a more design-y, less code-y question). Finally, don’t interrogate the candidate, or just let them squirm if they’re stuck; be a good member of the “pair” and help them along.

Process is not a four-letter word

As a software engineer, I’ve worked with a lot of different development processes over the years, and I’m a pretty big fan of a number of them. Also, as a Getting Things Done (GTD) fan and advocate, I have a pretty rigorous process I’ve imposed on myself for doing my daily work. However, I constantly hear my colleagues decry “process” as an unnecessary burden, and look to eliminate it whenever possible. I think this attitude is somewhat mistaken at best, and actively harmful at worst.

Let me start, though, by being clear what I mean by “process”. A process is the means by which something gets done. Using that definition, if you get anything done at all, there was some process by which it happened. It could be a good process, a bad process, or even just plain trial and error. It’s still the way it got done.

So, process clearly isn’t actually the enemy here, since we all like to get things done. Really, the problem my colleagues are reacting to is having a bad process with too many unnecessary, laborious, or complicated steps. This is definitely a problem, but not the worst one you could have.

The worst is having no process at all. Of course, that’s not actually possible, so really what this means is that your process is made up as you go along, on the spur of the moment, each time you try to accomplish something. It may feel good not be restricted from tackling the job in whatever way occurs to you, but you’re very unlikely to take the optimal path from concept to completion. Instead, it’s very likely that pieces will be missed along the way, thrown back in haphazardly, not completed in time, or in the wrong order, and stakeholders will be unaware of what’s going on, or when to expect results.

The worst part of this ad-hoc process is that you’re doomed to repeat the same chaos every time you do it again. Since everything was made up on the spur of the moment, you’ll most likely wind up doing it a completely different way next time. Any lessons learned about what worked and what didn’t (even if you’re able to recall enough of what you did to try to analyze it), won’t be applicable the next time.

The essence of process improvement is repeatability. If you can reliably repeat the same sequence of steps each time, you now have a chance to: 1) clearly understand what you did, and 2) deliberately make changes the next time.

So, one step better than total chaos is what most people think of when you say “process”: a clunky, cumbersome, set of steps which create a lot of unnecessary busywork for those trying to accomplish the goal. I say this is still better than no process at all because it is repeatable. That means, you can tweak the process each time you repeat it to make it better.

The very best processes, of course, are those which only include exactly as many steps as are necessary to ensure the right work is done, done well, and all the right people know what’s going on at each step along the way. The problem is that it’s not always possible to predict what steps those are, and whether those will continue to be the right steps in the future (e.g., as the team grows, or the problem gets more complex).

That leads you to the real goal: to create a process which includes a means of improving the process itself. There are many examples of such processes (SCRUM, Kanban, etc.) when they are practiced well. In those cases, the built-in self-correcting nature of the process allows the details to change to adapt to new circumstances.

Of course, this ideal implies a few failure modes. One is to adopt a “we’ve always done it this way” sort of attitude which fails to allow for refinement, growth, or adaptation. Then, no matter how good or bad the process is at any given moment, you’ll never get better. And, as times change, the process will suit the current situation worse and worse.

A second failure mode is to change lots of thing with each repetition. It is very hard to successfully and consistently change a habit: even when you’re only trying to make one small change. This becomes nearly impossible when you pile on too many things at once. And, even if you managed to do it, it’s very difficult to judge which changes had what outcomes. Better to keep things simple and tackle one change at a time.


As I said to start, a “process” is the means by which something gets done, and any time something gets done, there was a process by which that happened. Instead of treating “process” as a four-letter-word, I think we should embrace it. Whatever process you’re following for whatever goal you have, start by striving for repeatability, and then—bit by bit—keep making it better.

Improving your estimates

Estimating most projects is necessarily an imprecise exercise. The goal of this post is to share some tools I’ve learned to remove those sources of error. Not all of those tools will apply to every project, though, so use this more as a reminder of things to consider when estimating, rather than a strict checklist of things you must do for every project. As always, you are the expert doing the estimating, so it is up to your own best judgement.

Break things into small pieces

When estimating, error is generally reduced by dividing tasks into more and smaller pieces of work. As the tasks get smaller, several beneficial things result:

  • Smaller tasks are generally better understood, and it is easier to compare the task to one of known duration (e.g., some prior piece of work).
  • The error on a smaller task is generally smaller than the error on a small task. That is, if you’re off by 50% on an 8 hour task, you’re off by 4 hours. If you’re off by 50% on an 8 day task, you’re off by 4 days.
  • You’re more likely to forget to account for some part of work in a longer task than a shorter one.

As a general rule, it’s a good idea to break a project down into tasks of less than 2 days duration, but your project may be different. Pick a standard which makes sense for the size of project and level of accuracy you need.

Count what can be counted

When estimating a large project, it is often the case that it is made up of many similar parts. Perhaps it’s an activity which is repeated a number of times, or perhaps there’s some symmetry to the overall structure of the thing being created. Whichever way, try to figure out if there’s something you already know which is countable, and then try to work out how much time each one requires. You may even be able to time yourself doing one of those repeated items so your estimate is that much more accurate.

Establish a range

When estimating individual tasks (i.e., those which can’t be further subdivided), it is often beneficial to start out by figuring out the range of possible durations. Start by asking yourself: “If everything went perfectly, what is the shortest time I could imagine this taking?” Then, turn it around: “If everything went completely pear-shaped, what shortest duration I’d be willing to bet my life on?” This gives you a best/worse-case scenario. Now, with all the ways it could go wrong in mind, make a guess about how long you really think it will take.

Get a second opinion

It’s often helpful to get multiple people to estimate the same project, but you can lose a lot of the value in doing so if the different people influence each other prematurely. To avoid that, consider using planning poker. With this technique, each estimator comes up with their own estimate without revealing it to the others. Then, once everyone is finished, they all compare estimates.

Naturally, there are going to be some differences from one person to the next. When these are small, taking an average of all the estimates is fine. However, when the differences are large, it’s often a sign that there’s some disagreement about the scope of the project, what work is required to complete it, or the risks involved in doing so. At this point, it’s good for everyone to talk about how they arrived at their own estimates, and then do another round of private estimates. The tendency is for the numbers to converge pretty rapidly with only a few rounds.

Perform a reality check

Oftentimes, one is asked to estimate a project which is at least similar to a project one has already completed. However, when coming up with a quick estimate, it’s easy to just trust to one’s intuition about how long things will take rather than really examining specific knowledge of particular past projects to see what you can learn. Here’s a set of questions you can ask yourself to try to dredge up that knowledge:

  • The last time you did this, how long was it from when you started to when you actually moved on to another project?
  • What is the riskiest part of this project? What is the worst-case scenario for how long that might take?
  • The last time you did this, what parts took longer than expected?
  • The last time you did this, what did you forget to include in your estimate?
  • How many times have you done this before? How much “learning time” will you need this time around?
  • Do already you have all the tools you need to start? Do you already know how to use them all?

There are loads of other questions you might ask yourself along these lines, and the really good ones will be those which force you to remember why that similar project you’re thinking of was harder / took longer / was more expensive than you expected it to be.

Create an estimation checklist

If you are planning to do a lot of estimating, it can be immensely helpful to cultivate an estimation checklist. This is a list of all the “parts” of the projects you’ve done before. Naturally, this will vary considerably from one kind of project to the next, and not every item in the checklist will apply to every new project, but they can be immensely valuable in helping you not forget things. In my personal experience, I’ve seen more projects be late from the things which were never in the plan, than from things which took longer than expected.


Estimation is super hard, and there’s really no getting around that. You’re always going to have some error bars around your estimates, and, depending upon the part of the project you’re estimating, perhaps some considerably large ones. Fortunately, a lot of people have been thinking about this for a long while, and there are a lot tricks you can use, and a lot of books on the subject you can read, if you’d like to get better. Here’s one I found particularly useful which describes a lot of what I’ve just talked about, and more:

Software Estimation: Demystifying the Black Art

Makers vs. Managers

I recently read an article about the sharp divide between how different people use their time.  It divided people into two general camps: the “maker” and the “manager”.  People who fall into the former camp have work which requires large blocks of time which they can dedicate to a single concentrated task.  Engineers, authors, designers and the like all fall into this camp.  On the other hand, people in the “manager” group have work which requires them to constantly shift their focus from one task to another fairly quickly. Program managers are the quintessential profession in the software industry, but supervisors in nearly any field, people managers, and executives all of this pattern of work.

Unfortunately, makers and managers often need to work closely together, and often don’t really respect (or possibly even understand) the differences in each other’s mode of operation.  Managers will disrupt makers by scheduling meetings at whatever time works best to get the meeting scheduled soonest, without regard for leaving two funny 30 min chunks on either side of the meeting (which does a lot to kill the maker’s productivity).  On the other hand, makers will frequently drive managers right up the wall by failing to respond to a requests in a timely manner, or getting buried in one task and letting the schedule on another one slip.

There are two specific practices I’ve used which work well to smooth things out between these two groups: “Daily/Weekly War Team Meetings” and “Maker Time”.

A war team meeting is a routine standing meeting which the decision-makers of the team are required to attend, and which everyone is invited to attend.  The agenda for the meeting is decided in the first few minutes of the meeting.  Everyone present is welcome to add an item to the agenda, and request a certain amount of time for it (e.g., 5 minutes for a fast time, and up to 15 minutes for a long one).  The facilitator will put it up on the whiteboard.  Once the agenda is set (i.e., no one has any further items to suggest, or the duration of the meeting is spoken for), the facilitator starts walking through the items on the list.  Their job is primarily to keep the discussion on topic, capture items for future discussion, and keep things running on schedule.  If an issue cannot be resolved within the allotted time, it can either be settled privately between a few individuals who become empowered to settle the issue, or it can be brought back to the next meeting. Once all of the items which interest a person have been discussed, that person is welcome to leave.

This technique works fantastically well when coming up to a deadline, but is generally a good practice at any time (the closer to release, the more often you generally want to have the meeting).  The first positive effect is that it gives everyone on the team a forum and a voice on how decisions are made.  They don’t get to make the decision, but they can be part of the process.  That goes a long way toward improving morale on the team (especially one with really passionate, dedicated people).  The second effect is that it tends to consolidate hours of meetings into a much shorter span.  The vast majority of meetings take much longer than is required because they don’t have a really tight agenda, and because there is no strict timekeeper to keep things on track.  The third effect, and most important to makers, is that it makes the time of meetings predictable and consolidated.  This technique eliminates the need for many other meetings, and therefore gets rid of those odd little chunks of time which are hard for makers to use effectively.  Finally, and this is most important to managers, it creates a forum in which blocking issues can be resolved quickly and often. If your team does this daily, then the majority of issues which require a meeting can wait until the already-scheduled meeting the next day.

The second technique I’ve used for this kind of issue is “Maker Time”.  This is where makers are invited to block their calendars, reject meeting invites, close their doors, put on headphones or whatever else they need to do to put the world on hold for a few contiguous hours each day.  On one team I ran, we decided that we would prohibit meetings after 14:00.  In other situations, the team would pick a “meeting-free” day of the week (i.e., no meetings at all on Thursdays every week).  Whichever way, the leadership of the group made it clear to makers and managers alike that this time was to be set aside for makers to get their jobs done, and no one was to interrupt them (except for clearly defined emergencies).  This allows makers to have their dedicated time without completely blocking out managers for long periods of time.

Breaking Out of Consensus Deadlock

Back when I was working in a very small start-up with only two other people, we would often have a great deal of difficulty coming to decisions.  We would have seemingly endless meetings where each person would express their viewpoint, then someone would rebut that viewpoint, then the first person would express it again in slightly different words.  On and on, and sometimes about things which wound up being pretty trivial.  However, since there were only three of us, it felt like we ought be able to come up with some kind of consensus, but seldom was it that easy.

We had fallen into the trap of consensus deadlock.

I think of consensus deadlock as being any time a group of people gets stuck on making a decision because:

  1. there’s not enough data to make a clear decision obvious
  2. everyone feels that a unanimous decision is necessary
  3. no one is willing to ceed the decision to someone else
  4. there’s no clear owner for the decision

Naturally, there are a bunch of techniques to break out of the deadlock, and they all involve removing one of the things in the list.  The best thing to do, when it’s possible, is to figure out what information would tip the scales, and then go get that data (#1).  Of course, that’s not always feasible.  In that case, you might stop to consider how strongly you each feel about the issue, and choose to go with the approach someone feels most strongly about (#2).  You might also try thinking over the reversibility of the decision, and allowing someone else to give their idea a shot (#3).

Those are all good ways to break the deadlock, but perhaps the best way is to assign the decision to someone, and then hold them accountable for making a sound decision.  Of course, that doesn’t mean letting them simply go do whatever they want.  In order for this to end well, owning a decision involves a lot of responsibilities.

The decision owner’s job is really to pull everything together, and then follow the data where it leads.  First, the owner needs to ensure that all the available data has been gathered and is available for consideration by the team.  Depending upon the decision, this may be more easily said than done.  Second, the owner needs to collect feedback from everyone affected by the decision and give full consideration to each point of view.  In particular, this means that they should be able to represent each point of view as well as they represent their own.  Finally, the owner must be able to weigh the pros and cons of all those positions, measure them against the available data, and then present a clearly reasoned rationale for choosing a particular course along with its strengths and weaknesses.

The job of each other team member is to help the decision owner reach a good decision.  This may be offering up what data they have (all of it… not just what leads to a certain conclusion they support).  This might be to pose questions which are critical to understanding the problem.  This might be to help brainstorm various possible options and their pros and cons.  At all times, though, each team member needs to remain supportive of the process and the decision owner’s authority over that particular decision.


The only way this technique works is for every member of the team to act in a mature and responsible manner.  The decision owner has to be able to step back from a pet idea to consider all possibilities, and the rest of the team has to trust that the decision owner is honestly considering all points of view.  If, at any point, someone on the team feels this isn’t the case, a discussion becomes necessary about whether process is being followed faithfully—not about the particular details of the decision at hand.  That makes it much easier for everyone to start from a place of agreement, and to get back on track.

Avoiding Us vs. Them in Problem Solving

I can’t count the number of times when I’ve seen two people trying to solve a technical problem where the real conflict is anything but technical.  Often, this starts when one person brings an idea to the table, and is trying to promote it to the group.  Then, someone else proposes a different idea.  Each goes back and forth trying to shoot down the other person’s idea and promote their own.  Perhaps there was a pre-existing rivalry, or some political maneuvering, or private agenda.  Whatever.  Sides form, and before long, the debate isn’t really about a technical solution anymore… it’s about who’s going to “win”.

Of course, no one “wins” such a contest.  It’s stressful to be part of.  It’s stressful to watch. And, worst of all, it kills the collaboration which could have produced a better solution than either “side” was proposing.  Fortunately, I’ve run across an excellent way to avoid the problem nearly 100% of the time.

The Technique in Theory

The key is to get everyone involved in the process to bring multiple ideas to the table.  This seems too simplistic to possibly work, but it does.  It could be that they come with these ideas ahead of time, or that they come up with them in a meeting.  That part doesn’t matter.  What matters is that each person comes up with more than one.  The reasons this works have a lot to do with how it forces people to approach the whole brainstorming / problem-solving process.

The Opened Mind

The first thing that happens if you insist on each person bringing multiple solutions is that it opens up each person’s mind to the possibility of there being multiple solutions.  If you, yourself, brought three different approaches to the table, it’s very hard to imagine there’s only one way to do it.  And, if you’ve already formed favorites among your own ideas, you’ve probably started to develop some criteria / principles to apply to making that judgement.  At that point, it becomes a lot easier to weight the pros & cons of another idea you didn’t originate, and fit it into the proper place among the rest of the ideas.

Breaking Up False Dichotomies

The second useful trait of this approach is that the decision is no longer an either-or decision (a “dichotomy”).  Instead, you, yourself, have already thought up a few different approaches, and your thought partners probably came with a bunch of their own.  With that many potential solutions on the table (even if some of them are obviously very bad) it becomes a lot easier to see the complexities of the problem, and how there are a whole range of ways solve it to a better or worse degree: or even solve parts of it to a better or worse degree in a whole variety of combinations.

Cross-Breeding Solutions

Another handy aspect of having a lot of potential solutions, and seeing the many different aspects of the problem they tackle, is being able to mix and match.  Perhaps you grab a chunk of your solution, throw in a little bit of someone else’s, and then add in a piece which neither of you thought of ahead of time.  And again: but with a different mix.  And again… and again.  Before long, you’ve all moved past the original set of ideas, and have generated a whole bunch of new ones which are each better than anything in the original set.  At this point, the question of “us vs. them” is impossible to even identify clearly.  And… you’ve got a much better solution than anyone generated alone.

Goodwill Deposits

In my last post about “goodwill accounting“, I talked about how fun experiences strengthen relationships.  The process of brainstorming with an eager partner who isn’t defensive, and who is eager to help is extremely exciting and fun.  This makes substantial “deposits” for the future.


The Technique in Action

In practice, the technique is dead simple.  Guide your problem solving with three questions:

  • How many ways could we do this?
  • What does a good solution look like?
  • How do these potential solutions stack up?


When I find myself in a brainstorming / problem solving context, I’ll often start out by literally saying: “Okay… so how many ways could we do this?”  Then, I’ll start to rattle off, as quickly as I can, every different solution I can imagine: even really obviously bad ones.  Sometimes, I’ve come with a few I already thought of, but very often not.  Others soon join in, tossing out more ideas.  I keep pushing everyone (especially myself) until everyone has given 2–3 solutions.  At this point, we really do want all the possible ways: even the ludicrous or impossible ones.

Once everyone is mute & contemplative, I’ll echo back all the ideas.  At this point, the order is so jumbled, it’s impossible to tell who added which.  Then I’ll ask: “So, what does a good solution look like?”  Now that we’ve had a chance to see some proposed solutions, it’s a lot easier to figure out what we like about some and not others.  This rapidly crystalizes into a set of criteria we can use to rank the various options.

At this point, I start pointing out how various solutions match up with our criteria.  Some get crossed off right away, and others take some discussion and even research.  We might even loop back to re-consider our criteria.  The major difference is that everyone is focused on the problem, and not on the personalities or politics.


I use this technique a lot.  Early in my career, I was (embarrassingly) often one of the pig-headed people at the table insisting on getting my own way.  Now, I jump in with my “how many ways…” question, and I’m almost never even tempted.  My own relationships with my teammates are better, and I’m often able to use this technique to help smooth over difficulties between other members of my team.  I find it invaluable, and I think you will, too.

Sending Cold Emails

This is part 2 of a series on interviewing.  Check here for part 1 on setting up an interviewing team.


At a rough guess, I get about 4–5 recruiting emails every week.  Sometimes more, sometimes less.  I only bother to even say “no” to perhaps 1 in 100.  The others go straight to the trash: often unread.  For the benefit of all my recruiter friends, I’d like to explain why.

First, I should mention that I’m a software engineer with roughly 20 years experience.  In that time, I’ve worked up and down the technology stack from web to mobile to back-end to dev-ops: you name it.  I’ve also worked for companies from IBM to a freshly-minted startup.  So, I imagine I’ve gotten on a lot of lists.


Getting it Wrong

The common thread in the 99% of emails I don’t answer is that they’re really just spam.  They obviously take no time to pitch me on why the job fits my interests, talents, or would be better than the job I currently have.  The worst offenders are the bulk emails which invite me to peruse a “jobs” page and apply.  Slightly less obnoxious are the “we saw your resume and think you’d be a good fit…” emails. However, they all focus on what the company wants: not what I might want.  Fire and forget may be a good tactic for filling some positions, but you’re never going to pull a qualified senior person out of their current company that way.


Getting it Right

The tiny fraction of emails I do answer have at least one of the following traits:

  • they come from the hiring manager / founder
  • they clearly demonstrate some specific knowledge about me
  • they clearly tell me why I—me in particular—would enjoy the work
  • they clearly reference that this is a referral from someone I’ve worked with


An Example

One email I recall getting recently was from Matt Lott, the co-founder of CodeCombat: a startup which is trying to help kids learn coding by making a (really cool) game out of it.  He nailed nearly every point on my check-list. Here’s the actual text:

Hi Andrew,

Fellow co-founder here. I checked out Crafting Guide – kudos on
building a really cool guide to everything Minecraft-related :). I
also read on your LinkedIn profile that you enjoy mentoring others so
I thought I’d reach out. Our “World of Warcraft”-inspired game teaches
kids how to become programmers; to climb between levels, students
write code to navigate mazes and defeat savage monsters. More than
20,000 teachers currently use CodeCombat, and our investors include
Andreessen Horowitz and YC.

So far, we’ve built a popular single-player game, and we have many
cool challenges on the horizon – like building real-time multiplayer
mechanics and revamping our graphics engine. With your experience, I
thought you’d be interested in leading these initiatives.

If you’re interested in helping kids learn, I’d love to chat. How
about a phone call or coffee next week?

Matt Lott
CTO, CodeCombat

First, this is clearly coming from the hiring manager / co-founder.  This means that someone who has many other responsibilities thinks there’s a good enough chance that we’d want to work together that it’s worth his time to contact me in person.

Second, Matt clearly did his homework here.  He obviously read my LinkedIn profile carefully; he noted that we’re both co-founders, and that I mention enjoying teaching.  He also found the gaming-related hobby site I made, and he obviously spent some time figuring out what it is all about.

Third, while a big chunk of the email is clearly pretty general-purpose, he starts by calling out the why my specific interests—teaching & gaming—would lead me to being interested in working on their product—which is all about teaching through gaming.  Then, he gracefully transitions from the more personalized part to the less personalized part.

In fact, the only point he didn’t hit was mentioning this as a referral, but hey… sometimes that’s just not the case.  Still, 3 out of 4 is better than 99.99% of recruiting emails I get.

And, for the record, while I didn’t accept Matt’s offer for coffee, we did have a very nice email exchange.  Of greater importance, though, is that if I heard back from him under different circumstances, I’d be happy to renew the acquaintance.


I don’t need to tell anyone that there’s a lot more open headcount for senior people than there are actual people willing to join your company.  I also don’t need to tell anyone that, in general, we are well-paid, and have our choice of jobs.  Naturally, that implies that everything in recruiting is backwards compared to other more junior positions.

If I could make every recruiter understand one thing about recruiting senior-level professionals, it would be: you are in sales.  I’m a prospect, and you’re pitching a product to me.  You need to learn enough about me to understand what will motivate me to buy, and then sell it to me.  You’ve got one email to convince me that you’ve made an effort to pitch me on something that I actually want.  Don’t blow it on cheap form letters or junk mail.

Conducting an Interview Loop—Part 1: Setting up the Team

I’ve worked at a pretty diverse range of companies from the massive (IBM, Microsoft) to the merely large (Amazon, Groupon), to the small (Boom, Pelago), to the positively tiny (Kima Labs, Redwood Labs).  In every place I’ve worked, interviews are conducted according to the same general pattern, but with a lot of differences in the details.  This series will explore what I think are the best practices I’ve seen across all those different places.


Even before a candidate has been identified, the hiring manager should have prepared the team for the potential interview loop(s).  The first step is to actually have a team.  That is, a dedicated group of people for interviewing all the people coming in for a certain position.   This has several advantages:

  • the team can form a “group memory” of all the candidate who have interviewed
  • the team can coordinate on “focus areas” and even individual questions
  • the team will get to know each other’s questions, and therefore save time in debriefing about the candidates

I’d like to talk more about assigning “focus areas”.  Each member of the team should be assigned a couple of very specific areas to focus on.  For example, in the case of hiring a software engineer, one person might be asked to look at algorithms, another object-oriented design, and yet another front-end development skills.  In additional to technical areas, people are generally also asked to investigate some cultural value of the company’s.  For example, at Boom, we value people who like to make things in their spare time, so we might have someone assigned specifically to dig into that a little bit.

Once assigned an area(s) to focus on, each interviewer should plan out what questions they want to ask in order to learn the most possible about that area.  Here it works best to develop questions in two different ways: a simulation of actual job skills, and asking the candidate to relate a story.

Simulating actual job skills works best for technical areas of focus, and the best questions are those which are closest to the real task involved.  So, in the case of assessing programming skills, I’ll always make sure to have a computer on hand, and a set of real development tools installed and ready to go.  Finally, I’ll have made up a question which is a simplified version of some actual challenge I’ve had to solve at work.  The goal is to come up with a question which, as nearly as possible, uses the tools and skills the candidate will actually have to demonstrate at work every day.

Asking a candidate to tell a story (i.e., Behavioral Interviews) work very well in cases where a skill is hard to demonstrate on the spot, or when trying to understand a candidate’s culture fit.  In this style of questioning, you ask the candidate to tell a story about a time when… you fill the blank.  These are often things like: you had to deal with a difficult customer, you missed a deadline, you were forced to be innovative, etc.  These can also be much more specific.  For example, I might ask a software engineering candidate to tell me a story about when they had to fix a particularly nasty bug in a piece of code they weren’t already familiar with.

It’s extremely helpful for each member of the interview team to use the same questions for each candidate for a particular position.  This allows them to:

  • get better at asking the question in a clear way
  • get a sense of what good and bad answers look like
  • figure out what guidance works to help a candidate if they get “stuck”
  • be able to compare answers directly between individual candidates

This also allows the other members of the interview team to plan their own questions to avoid any possible overlap: especially when multiple people share the same areas of focus.


At this point, you’ve got your team together, and you’re ready to start talking with candidates.  In future posts, I’ll talk the best practices I’ve seen around getting candidates to show up, what to do before they arrive, how to conduct the loop, etc.