Treat interviewing as storytelling

The skills necessary to excel during an interview aren't necessarily the same skills required to excel at the job. Like any set of skills, some people are great at both, some are great at only one, and some are great at neither. So, how do we use interviews that test someone's interviewing skills to determine their job skills? The answer is to treat our interview questions as chapters in a story.

In this post, we will delve into how to design an interview so that we can find the people that are great at their jobs, not just great at interviewing.

The interview process described below is for hiring a domain expert developer rather than a general developer.

Possibilities

Candidates roughly fall into four buckets:

1. Great at interviewing, great at the job.
2. Great at interviewing, poor at the job.
3. Poor at interviewing, great at the job.
4. Poor at interviewing, poor at the job.

As you can see, we want to hire from buckets 1 and 3 while avoiding buckets 2 and 4.

But how?

What buckets 1 and 3 have in common is that the candidate is great at their job. To uncover those people in buckets 1 and 3, we need to design an interview process that closely simulates the actual job requirements.

Getting to know their technical skills

By connecting the questions we ask, we ensure that the outcome of the previous question affects the constraints applied to the next question. This connection between questions enables us to observe how the candidate adapts their solution to the changes introduced by each question.

Let's take building a social media feed as the overarching story and look at what the chapter questions might be:

1. How to display the feed?
2. How to fetch the feed?
3. How would you add support for offline browsing?
4. How to resolve a performance bug with the feed
5. How to test the feature?

The candidate might choose to discuss the following topics while answering the above questions:

1. Storyboards vs building the UI in code.
2. HTTP, WebSockets, JSON, Codable, pagination, etc.
3. Core Data, UserDefaults, Keychain, etc.
4. Multi-threading, image caching, cell reuse, etc.
5. Unit testing, dependency injection, working with a QA team, etc.

So if, for question 3, the candidate opts to use Core Data to persist data, we could then ask:

"So you used URLSession for fetching the feed, how would you store that feed in Core Data given URLSession returns on a background thread?"

Connecting choices made in question 2 with choices made in question 3.

The way a candidate answers these connection questions demonstrates how flexible they are regarding changing their solution to match the changing needs of the app.

Let them search

It's rare that, as developers, we pick up work and have all the necessary information at hand; instead, we often have to ask questions, investigate the code, and so on, to gain a clear understanding of how to solve the work we've been given. Each of the chapter questions should be deliberately vague and open-ended to simulate this experience. So, rather than trying to get the candidate to tell us our predefined correct answer, we instead explore their thinking and expertise through this vagueness, while seeing how they cope with ambiguity.

Building their confidence

In an ideal scenario, the candidate drives the conversation once the question has been asked. However, sometimes we need to encourage the candidate to open up and share their expertise by building their confidence during the interview.

We all like to be told we're doing a good job, but it would be super awkward to stop mid-interview to tell the candidate that. A more natural approach is to work that feedback into each question listed above, for example:

Okay, so we have our feed displayed in a table view with data pulled from an HTTP endpoint. However, we now want to show that data as soon as the app opens, without having to wait for the network call to return. How would you add this functionality?

A little long-winded, but by expanding each question with feedback, it creates a sense of momentum for the candidate.

Getting to know the person

Programming is all about trade-offs. Any half-decent developer spends a lot of time weighing up those trade-offs and discussing them with team members. The ability to communicate a possible solution and receive feedback is essential. We can test this ability by asking trade-off questions:

So you said you would use Storyboards rather than building the UI in code - could you contrast the two approaches?

By asking this question after the candidate has already chosen a certain technique or technology, we can see how they react to being challenged on their solution.

• Are they open to the other approach, or do they dismiss it out of hand?
• Do they get angry or annoyed by having their approach questioned?
• Do they detail their thinking and use the question as an opportunity to convince the interviewer?

You have to assume that when someone interviews, they are at their most receptive to others' ideas. If, during the interview, they become upset about being challenged on their solution, that is a major red flag 🚩. It's much easier to teach someone a technology than make them a team player.

Of course, don't go overboard with the challenge.

All over 🏁

By wrapping an interview into a story that better mimics our actual development process than traditional interviews with stand-alone questions, we can expose those candidates who are not only in bucket 1 but also in bucket 3, while weeding out those in bucket 2.