artisanal bytes

Abraham Lincoln is famous for, among other things, having put together a cabinet of people with differing points of view. He wanted lively debate in his Oval Office to ensure the cabinet members were forced to think about an issue from all sides. Similarly, those who have read “World War Z” will recall the Israeli policy of the “tenth man doctrine”. This policy states that if nine people in the room agree, then it is the responsibility of the tenth man to dissent, no matter how unrealistic his forced position is, and even if this means going against his own opinion. He must wage the dissenting fight to ensure they think about all possibilities¹. These practices for putting together a committee that will evaluate all possibilities and investigate all angles to an issue unsurprisingly carry over to the software world. What I have come to realize though, is that while it is valuable for people in the group to have dissenting opinions, it is just as valuable that everyone share a common philosophy, and that is the “fit” that we all must hire for.

In the software world, the philosophy focuses on how you evaluate solutions to problems and how you go about building the software to address them. I think of it as the principles of engineering, such as

• building for the long term, or just coding up something to get it done
• working within constraints, or inflexibly requiring changes
• relying solely on new technologies to solve the problem, or using the tools at hand
• building tools to do the work for you, or doing the work manually
• valuing experience, or accepting the open mind

None of these choices is black and white, and there are certainly many more to think about when considering what your philosophy is.

How does this relate to hiring? Along with evaluating hard skills, there is almost always some step of the interview process that is focused on “fit.” Typically when we question whether or not someone would fit on the team, we first think about the question, “Would you want to have a beer with him?” While it is valuable to be able to socialize with your teammates, we should really be digging in to find out if the candidate’s philosophy of engineering is the same. Does she share the same guiding principles when it comes to the decisions she makes?

How to determine philosophical fit

The first step is to figure out what your own philosophy is. What do you believe in as an engineer, or what has your team already agreed upon (either explicitly or implicitly)? Ask questions like these:

• Would you rather bring in a new tool or try to work out a way to use the tools at your disposal to solve a problem?
• Is your first instinct to search for an open source project that has solved the problem you have or to read an academic paper about it?
• If a tool you already use does not have the functionality you need, do you look for a new one or ways to build the function into what you have?
• When you think about a system, how much do you think about how you might be running it next year?
• When you design a piece of software, how much do you think about how developers coming after you might react to it, or how they may interpret it?
• When you come across an organizational issue, what do you do: discuss the problem and come up with ways to change or try to ignore it?
• Do you fix bugs before moving on to building new features?
• How do you think about the users of your software? Are they the best source of input, or are they morons who don’t understand the system you built for them?
• When time to solve a new problem, do you jump head first into coding, or do you start by thinking quietly in a corner?

Once you have thought about the answers to these questions and answered more questions that have come up, you should have a good idea of what your engineering principles are. Now when you are taxed with determining “fit” for a candidate, start by asking similar questions. Use behavior interviewing techniques to tease out of them how they behave. That will be much more telling than just asking, “What is your philosophy of engineering?” For one thing, most people will stare you blankly in the face, having no idea what you are driving at. And secondly, they will be able to more easily bullshit the answer if the question is not specific to their experiences.

Argue as much as you want about which language to use, whether the cloud is good or not, or any other technical detail. But agree upon how you will evaluate solutions and how you will build them. Then hire people who fit with your philosophy.