Hiring by Personality-Type

As I have elaborated in some of my previous articles, the underlying personality of a developer should be of chief concern to you. Depending on the types of products that your team develops, you should have a desired ratio of personality-types among your engineers.  For instance, if you run a contracting service that develops websites for businesses, you will likely want a higher ratio of solution-providers on your team. If you develop pattern-recognition image-processing libraries, you likely want a higher ratio of puzzle-solvers.  Before hiring a new developer, you should seriously consider the type of developer of which you are currently most in need.

Job-Post
Once you determine the personality-type that you are seeking, you should word your job-posting so that it will be as attractive as possible to that type of individual.  Obviously, personality-type is not the only consideration. Your job-posting should include all of the typical things such as desired technological-proficiencies, level of experience, and education, but the way that you describe the job can have a big impact on the types of developers you are likely to attract.  Take, for example, this excerpt from an actual job posting:

...seeking experienced front-end developers. This role is responsible for building world-class demonstration assets, prototype implementations of commerce solutions, executing on custom branded demonstrations and building the User Experience (UX) portion of proof-of-concepts. ...a driven team of creative individuals collaborating to bring the best commerce solutions to the marketplace. 

That posting sounds like a dream-come-true for a solution-provider, but it sounds like a nightmare for a dispassionate-programmer. If the poster was seeking a solution-provider, they probably found many good candidates. If, however, what they really needed was a dispassionate-programmer or a system-builder, they probably wondered why they didn't get any good responses.

Resume
Once you have the job posted, your next task is to try to determine the personality-type of each candidate that applies. While it's impossible to determine a personality-type from a resume alone, resumes can contain some clues. For instance, if a resume has grammatical mistakes, inconsistent formatting, or uses imprecise terminology, it's a pretty good indication that it was not written by a system-builder. If it lists experience with many high-level cutting-edge technologies, it was more likely written by a solution-provider. If, on the other hand, it shows lots of experience with embedded systems, RTOSs, and assembly languages, then the candidate is likely a puzzle-solver. If it shows a mid-career switch from some non-technical field, it's more likely that it was submitted by a dispassionate-programmer.

Interview
The best shot that you have of finding the right type of developer is by asking personality-probing questions during the interview.  Here are some example questions:

How and why did you become a software engineer?

Knowing the history of how someone became interested in software development is one of the best windows into their motivations and passions.  The distinction between a dispassionate-programmer and any of the other impassioned types is usually immediately clear.  An impassioned developer will light-up with excitement at the opportunity to describe their first projects that got them interested in programming.  Additionally, the thing that sparked their interest in the first place is often the very thing that they enjoy most.

What do you enjoy most/least about software development?  

What are your strengths/weaknesses as a software engineer? 

Answers to these questions are more difficult to judge because the interviewee will be reluctant to be entirely honest.  But, by asking both sides and by paying close attention both to what they say and don't say, answers to these questions can be very valuable, especially when compared with their answers to the other questions.

Have you ever created any projects or learned any technologies which were unrelated to work?

According to a recent survey, over 90% of the developer respondents worked on personal or open-source projects outside of work.  Since it wasn't a scientific poll, the results are probably skewed, but still, the results are pretty clear; many, if not most, developers recreationally have projects on the side.  Even if they never have worked on a project outside of work, most impassioned engineers will at least voice regret that they wanted to but didn't have the time.  A dispassionate-programmer, on the other hand, will look at you like you have two heads, as if to say "Why in the world would I work for free?"  If they have worked on any projects for fun, it's often a much bigger window into their passions than knowing the kinds of projects on which they were required to work by their employers.

Do you advocate any particular design-principles (e.g. SOLID, DRY, YAGNI, LoD)?

If the candidate answers this question affirmatively, regardless of which design-principles they prefer, you can be pretty certain that they are a system-builder.  Puzzle-solvers and dispassionate-programmers will be indifferent or ignorant on the topic, but solution-providers will often be actively against design-principles.

What’s more important, code-efficiency, or readability and maintainability?

 Everyone will, of course, answer, "Both."  But, if you probe a little further, you should be able to ascertain to which side they tend to lean.  If they are more concerned about efficiency, they are more likely to be a puzzle-solver.  If they don't care about readability and maintainability, they are certainly not a system-builder.

What does bad code look like?

This is a very interesting question which can tell you much about a developer's personality and philosophy, but it also has an honesty-problem.  Since the candidate doesn't know what your team's code looks like, they may be reluctant to be entirely forthcoming for fear of offending you.  Regardless of how truthful their answer is, you should be able to at least ascertain whether or not they have strong feelings about the topic.  Even if they are reluctant to share their strong feelings, it should be fairly obvious whether or not they have them.  If they don't have strong feelings, they are most likely a dispassionate-programmer or a puzzle-solver.  If they do have strong feelings, they are most likely a system-builder or a solution-provider.  If you are lucky enough to get someone who answers the question openly, their personality should be made all the more clear by whatever it is that they happen to say.

When deciding if you should use a third-party library or custom-create an in-house library, what factors do you consider?

This question, though narrow, is useful because no two personality-types are likely to answer it in the same way.  Puzzle-solvers will strongly prefer to develop in-house if possible.  System-builders will have a more cautious but measured approach.  Solution-providers will lean towards third-party if possible.  Dispassionate-programmers will want to let someone else make the decision.

Describe a situation where you were forced to, or felt the need to, cut corners.

 If they can't think of an example, they are probably a dispassionate-programmer.  However, if they can, it will be interesting to learn what kind of thing it is that they deem to be the cutting of a corner.  If they describe a situation where they took the high-level route rather than their preferred low-level one, they are likely a puzzle-solver.  If they describe a situation where they had to compromise the design in order to implement what they considered to be a hack, they are probably a system-builder.  But if they say that they had to skip implementing some cool feature that they wanted to incorporate, they are more likely a solution-provider.