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.

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).

✧✧✧

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.

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.

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.