Storytelling tips for technical interviews

Humans love stories. We love telling them and we love reading, listening and watching them. Beyond entertainment, stories have allowed us to collaborate and build the world we live in today. Sapiens by Yuval Noah Harari talks in-depth about this.

Given the importance of stories to the human mind, it seems there is no better way to explore it. I would like to share my approach to interviews and to emphasize the importance of storytelling when interviewing candidates for technical positions. Although I assume these tips can also be applied to interviews for product managers, designers, etc.

You must assume the candidate will tell you the story you wish to hear; although most of the time, they won't. Unless they have done a lot of research, the candidate doesn't know the taste of their audience. In this case, you. They will need guidance and the first step is to let them know who is their audience.

The audience

Presenting yourself proves that you care enough about the candidate to let them know with whom they are going to spend the next hour. Knowing what the audience cares about will set the tone of the story.

I'm David. I'm a Product Engineer. After surviving many startups in Madrid I moved to Valencia. The sun, the beach, the city, the people and the raising tech and startup community brought me here. A few months ago, Creditas adopted me in order to improve the things that I'm supposedly good at: android, backend, leading teams and question Product Managers.

This is not your CV so you must do it under one minute. Prepare it beforehand. Don't improvise. Stick to what matters and be human; be real. Few storytellers succeed without speaking the truth. Mention what you like, what is important to you, what drives you and what motivated you to be where you are. Giving a lot of details about your technical experience maybe is irrelevant to the candidate's story.

World-building

In any agile Product Engineering team, you end up with some tasks that are pending to be done. Sometimes it is a ticket on a JIRA board; or just a post-it on the wall; or even a message in Slack from your Product Manager saying it is something urgent. Hopefully not... Anyway... It is a really long journey until a feature is in a machine in the vast wonders of the internet and somebody is using it. I would like you to take me into a journey that takes that feature from to-do to production.

Start the story at the point you think necessary, giving a recap on what happened until that point in which the story is taking place. The world that you are building in front of the candidate has rules that need to be respected. Mention them if they are important. It has characters that have some abilities and responsibilities. Mention them if they are important. It has a history that needs to be taken into account and it has momentum: a force in the direction the story is led.

The rhythm

You have a task waiting to be done. Maybe you go to a whiteboard with a colleague. How do you start?

The tempo of a story hugely affects how events are interpreted. You should care about the rhythm of the story down to the beat. Every step is an opportunity to go as deep into a topic as the candidate wants. The rhythm reveals what is important to them.

You have spent some time at the whiteboard exploring different solutions. Then you sit down in front of a keyboard and a monitor ready to pair program the hell out of it. How do you do that?

As a guide you should try to keep a constant tempo. Accelerate or decelerate slowly enough so the candidate has time to adapt.

Branches

The task is done. Or is it? Well, we know that at least the feature is programmed. It is coded. But that code can't stay on our machine forever. It's useless there since it doesn't bring any value to the user.

Think of any story as a tree. You start from the root and go up navigating it to the top. By the time the candidate completes the story, from thousand possible paths, only one is going to remain explored. The story always pushes the timeline forward. Flashbacks or jumping between branches is not a good idea because it will only add confusion and mental fatigue. That means you won't ask questions that don't have any relation between each other. So give them a transition and let the candidate explore the path they think is best.

Before deploying that code to production, maybe we should invite somebody to review it.

Sometimes there is something specific you want to hear about like testing strategies as “outside in or inside out”. So you will force the candidate to go into places that they were or were not intending to go. That's a forced branch. That's fine if it builds in the direction the story is leading to. You should keep the momentum the story already has and take advantage of it. Observe how the candidates handle the situation, how they get out of it and how they improvise.

Transitions and plot twists

You are almost there. The code is reviewed and the feature is tested in a staging environment. Now is time to deploy to production. And we want to do that smoothly and without friction. It's a good thing that we already have a solid CI/CD pipeline set in place that takes our code through different steps. I'm curious about haw all that works.

Transitions help the story advance in a certain direction. Most candidates don't know how the story is supposed to advance and what places they need to explore. Transitions shouldn't be drastic. They advance the story one tiny bit at a time. This gives the candidate time to adapt and be prepared to build the story further.

When we deploy to production, we hope everything will go well. And this time it seems everything has gone well. However the next day the Product Manager reports that there is a bug in the feature that you deployed. That is surprising but not unexpected. How do we hunt that bug down? What tools do we need?

Plot twists, on the other hand, take the candidate and put them in a completely new situation. Plot twists don’t change context completely. They build upon the context that the candidate already has but it doesn't take full advantage of the momentum of the story. Something unexpected but familiar has happened. Plot twists exist because you want to create conflict. A story is not interesting without conflict. Let the candidate explore that.

We know that products are not static, they evolve... Software is supposed to change. If it wasn't, it should be hardware. We need to be as lean as possible working in small feedback loops to be sure that what we do really adds value to the user. From an engineering perspective, the simplest setup for a digital product is to have a frontend client and a backend that serves a REST API. As our product evolves, our API will also evolve. Let's talk about what things must be taken into account when we evolve our API in such iterative ways.

Stories are continuous. Events don't just happen without any reason. Any event has a cause. We know and understand the reasons behind them and we are able to respond in a proper and proportional way. Transitions need to give enough context to understand why something is happening. Only then, the candidate will be able to respond in an appropriate way. You want the candidate to understand what you are asking. If the branch you want to explore opens a whole new world, the transition needs to be richer.

Levels of abstraction

After many iterations, our product is more successful than we ever imagined. The load on our services is increasing day by day. We are starting to see traffic spikes. What do we need to take into account and what do we need to do at this point?

The story starts at a very low level. Very specific. As the interview goes on and the story gets built, the mental fatigue increases. It is a good idea to go from specifics to more abstract topics. By the end it should only be about abstract concepts, ideas or conclusions.

Unfortunately you just have time to explore so much. But by the time the story is wrapping up, you should understand not only some of what the candidate knows, but you should also have connected with them at some level. Stories, good stories, make us crave for more. If that craving is present, then you have the answer you've been searhing for this whole hour.

A more humane way of driving interviews.