I find it distressing that more and more companies using personality tests in their interview process. My colleagues mentioned that they have seen this trend increase as well. They note that it is a convenient way to get around anti-discrimination laws because the results are hidden. I’m going to give a benefit of a doubt and not assume this practice is due to some sinister motive. I think a much simpler explanation is that hiring managers are trying to make their jobs easier.

Photo by Glenn Carstens-Peters

A personality test is easy to conduct. You get a candidate to answer some standardized questions. The answers are compiled into a set of scores for various traits. Anyone can pick the traits they think they want and pick a candidate that fits the mold. It is a lot more difficult to make this determination in the actual interview process so there is a huge temptation to simply rely on a test that has some authority behind it.

There is a much better way to determine a candidate’s qualifications however. Let’s look at some of the questions we would want a personality test to answer for us:

• Will a candidate get along with people?
• How does a candidate communicate?
• How does a candidate handle disagreements?
• How does a candidate handle new situations?
• Does a candidate learn from their mistakes?

All of these questions can be answered better with an open ended software design or architecture problem. I prefer to base these questions on a system the candidate will actually work with. Some examples are: running a data migration from legacy systems, implementing a new feature across the stack (frontend components, api endpoints, datastore used and/or database schema, etc.), or managing a pipeline of asynchronous jobs that had dependencies on each other.

The beauty of these types of questions is that they will inevitably result in a candidate having questions. The types of questions they ask will be an indicator for their technical ability. Plus, these questions will result in discussions between the interviewer and the candidate. That discussion will resemble the types of discussions development teams will have when building these systems for real. While the candidate’s behavior is modified because they are in an interview situation, this is as realistic a scenario we can get with what it will be like to actually work with this person. This answers how a candidate gets along with the specific people on our team and how well we can communicate with them. A standardized personality test can provide some insights on abstract traits, but not how well a candidate will mesh with the team members we have.

In addition, we can add things to our open ended problem to answer other questions about a candidate. Since an open ended problem is rarely a problem that has an answer which is 100% correct, we are free to disagree with a candidate regardless of their answer. The interviewer can propose a different approach to solving the problem and ask for the candidate’s opinion. Will they answer defensively or with arrogance? Or will they provide a neutral analysis of the trade offs between the two approaches? I don’t know a single development team where everyone agreed on everything 100% of the time. That makes this another realistic scenario we are evaluating a candidate with and seeing how they interact with our team.

And speaking of realistic scenarios, we can also add requirement changes to our open ended problem. How does a candidate respond here? Do they freeze? Do they focus on solving the new problem? Are they open about some of the regrets they have about their original design? Can they find a way to deliver on the new requirements with their existing design or do they think they need to rebuild everything? How a candidate handles this situation says more about their personality than any standardized test of abstract questions.

I’ve learned the hard way that abstract theoretical questions aren’t the best judge of engineering candidates. It’s why I never use standard algorithm questions in interviews anymore. Personality tests may test for something different, but they share the same fundamental problem with coding on a whiteboard. Neither are realistic representations of a candidate’s true ability. There are better alternatives. The open ended architecture/design problem is one, but there are others. And as with everything else, we should always strive to improve our interview techniques with even better alternatives.