Practising Empathy in Technical Interviews
I would like to propose an experiment for improving the effectiveness of technical interviews: developing empathy for the candidate through a dedicated listening session. Previously, I shared my thoughts on incorporating code review in technical interviews as a means of developing empathy, to increase the effectiveness of the interview and to improve the experience for both the interviewer and the candidate. Now, I would like to explore the idea of developing empathy for an interviewee more explicitly.
Politics aside, technical interviewing reminds me of Donald Rumsfeld's famous quote regarding unknown unknowns:
...as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don't know we don't know...it is the latter category that tend to be the difficult ones.
Most technical interviews, especially in the early stages, focus on known knowns, attempting to evaluate the candidate's knowledge of data structures, algorithms, languages, frameworks—things that people assume are important and easy to assess. These known knowns, however, have little bearing on the overall impact this person may have on your organization. Most interviews also involve known unknowns, like trying to assess how good a candidate is at learning new things and solving novel problems. An organization interviewing for a skill set that they do not have, but know that they need, like someone skilled in software security or performance monitoring, also falls into the category of interviewing for known unknowns. The assessment of known unknowns is, perhaps, more difficult, but it may also be more effective, since you are focusing on what this person can accomplish, not just on what they have encountered and can recall. But how do you interview for the unknown unknowns—ideas, approaches, skills that this person might bring your organization that you don't even know exist, or that the person hasn't yet developed, and, therefore, you can't appreciate the potential impact?
If you are hiring a contractor, you are likely interviewing for a very specific expertise, like experience in a particular language or platform, or vendor-specific protocols or APIs, to meet well-defined objectives. For the vast majority of technical interviews, however, the objective is to identify people that are good at learning new things and good at solving problems. The languages, frameworks, and technologies that they will use today may not be the same ones they'll use next month or next year. Or even if they are, they will include new functionality, or evolving concerns in terms of security, performance, scalability, and so on. The teams and projects this person will be a part of will also evolve over time, along with the objectives of the organization.
To incorporate unknown unknowns into a technical interview, what about dedicating time exclusively for developing empathy for a candidate? Listening and establishing an appreciation for not just what they know or have accomplished, but understanding their thinking, motivations, preferences, and experiences, how they evolved, and how this person might impact your organization?
I was inspired by this idea after reading Indi Young's book Practical Empathy. The book focuses on product development. Indi argues that conventional product development focuses too narrowly on ideas and solutions. She presents techniques for developing empathy for people first, in order to understand their thinking and perspectives, and to expand your own thinking, to ultimately build better products and relationships. This book reminded me of technical interviewing. Instead of focusing on objectives and filtering out candidates early-on based on known knowns, a technical interview dedicated to developing empathy for the candidate may be a way to find a more diverse set of candidates, expand the thinking of your organization, and build better products, services, and teams.
Indi introduces her book as follows.
This book is not about the kind of empathy where you feel the same emotions as another person. It's about understanding how another person thinks—what's going on inside her head and heart. And most importantly, It's about acknowledging her reasoning and emotions as valid, even if they differ from your own understanding.
There are many different kinds of empathy and it is important to define which type of empathy I am talking about here. Indi highlights four different types. Mirrored empathy involves mirroring the physical emotions of another person, like returning a smile or a glare. It is purely affectual and is one of our earliest forms of communication and connection—think of a mother mirroring the smile of her baby. Personal distress is the sharp emotion we feel when we see someone else in distress and imagine what it would be like to be in that same situation—seeing someone fall, for example. Emotional empathy is about feeling the same emotion another person is feeling—sharing the excitement of your friend landing a new job. These three forms of empathy are illuminating and powerful, but they are fleeting in that you can't make them happen—they happen to you. Because you can't make this kind of connection happen on demand, you can't practise it, or incorporate it reliably into your day-to-day work. Cognitive empathy, however, is about understanding what went through a person's mind as they worked toward a particular intent or purpose. This type of empathy can be incorporated into your work, because it is repeatable and can be practised.
Many people understand cognitive empathy simply as walking in someone else's shoes—trying to understand how a person will act or react in a certain scenario. This, however, is applying empathy. In order to apply empathy, you first need to develop it. Many people apply empathy based on assumptions and conclusions and skip entirely the development of empathy. To develop empathy you have to listen. You have to get beyond the person's opinions and preferences, and understand how they formed instead. You need to understand the person's guiding principles.
Doesn't this sound like most technical interviews? We deliver judgment based on our assumptions and conclusions, limited by our own experiences, rather than really understanding the thinking, perspectives, motivations, and experiences of the candidate. We filter out many candidates on this basis early-on. We don't expand our thinking. We also make demographic assumptions—because you are of this demographic, we conclude that you behave in a certain way—perhaps without even realizing it.
Take, for example, the ubiquitous programming assignment used to assess the candidate's technical ability. Often, judgments are made based purely on observation, without discussing the assignment with the candidate, or developing any empathy for the candidate. We discount the solution because it doesn't solve the problem as we understand it, or it doesn't scale, etc., without understanding the thinking, assumptions, constraints, and experiences that lead the candidate to that particular solution. Did the candidate even understand the problem the same way we do? It is the thinking that we should be evaluating the candidate on, not the solution in isolation. The solution might not be optimal or even correct, but if the candidate can appreciate this as their experience evolves, should that disqualify them? We don't want to just hire candidates that think like us and know how to solve the same problems that we already know how to solve.
A Listening Session
Product development often focuses on iterating the think-make-check cycle popularized by "Lean UX". Indi argues that this methodology can become focused too narrowly around a particular idea or solution. She encourages listening, developing empathy, then applying empathy, as a means to improve the think part of the cycle, introducing more ideas and ideas that are more fundamental.
Developing empathy comes from listening and requires uncovering meaning. Many conversations we have are only surface deep. Our words and means of communication are imprecise. Our conversations usually focus on emotions, opinions, and preferences, and change depending on who we are talking to. At this level, we cannot derive cognitive empathy. Instead of taking what we hear at face value and drawing our own conclusions, we need to go deeper and find out the reasoning, reactions, and philosophies that motivate the other person. This is the focus of a listening session.
A listening session should be performed one-on-one and start with a broad intention or purpose that the person has been involved with. Beyond this, Indi discourages additional preparation. You have no idea where this conversation will lead and you want to be shown new and interesting perspectives. This means no list of predefined questions.
The most important thing is to keep your attention on what the person is saying and not be distracted by your own reactions, judgments, responses, and opinions. It is also important to be supportive of the speaker so they feel safe and trust you with their inner thoughts and reasoning. You should be present in the conversation and never cause doubt or worry. You should resist injecting your own ideas or stories, or even words that the speaker hasn't used, just let the the speaker keep choosing the direction of the conversation.
You want to look for thought processes, decision-making, motivations, rationalizations, indecision. Don't make assumptions about what the speaker means. Instead, use this as an opportunity to dig deeper and understand more, by asking open questions like:
- "What do you mean?"
- “What were you thinking when you made that decision?”
- “Tell me your thinking there.”
Notice that these questions use very few words and do not lead the speaker in terms of intent, purpose, or motivation. In order to avoid controlling the conversation, avoid changing directions abruptly, or even saying things like "OK, great".
During the listening session, Indi discourages note taking, because it distracts from listening to the speaker, but also because it usually involves synthesis and this is to be avoided until after the session. After the session, Indi encourages making summaries and developing patterns. She even suggest sitting with these summaries for some time in order to let the ideas develop. This is a way to add more voices, to help see problems differently and to find solutions inductively, rather than deductively.
Too often, we filter out good people early in the technical interview process, based on our flawed evaluation of known knowns, or because we fail to appreciate that this person thinks differently than us. Perhaps we've even shared similar experiences, but we lack a common vocabulary for relating these experiences. We are likely to hire people that think like ourselves and we fail to expand the ideas that inform our organization. I think we should take inspiration from Indi Young and dedicate an interview or two in the process to developing empathy for the candidate, through a dedicated listening session, as a means of understanding the candidate better, and to introduce more ideas and a more diverse set of people into our organizations. Ultimately, this will make our organizations more effective. In my next article, I will explore what this interview might look like.