My Interview Process

As Zello’s first in-house designer, I helped to define and formalize our interview process. Years before we had a recruiting team, AG and I sat down together to define our product designer interview process. With Dell’s and Meta’s^[1] processes lukewarm under memory’s heat lamp, I was falsely confidence that I knew what I was doing.

Fortunately, we lucked into some great candidates. I believe—and could be misremembering—that we started interviewing late Q3 or early Q4 2017, and signed Amy Roberts for a January 2018 start date. Amy stuck around for a little under two years and did a stellar job bringing our Android app to Material 2, and then designing our Emergency Alerts feature.

Amy decided to pursue further opportunities at Signal when Zello decided to shift focus from our Consumer to B2B offerings in mid 2019, and so we were back to recruiting. I was living in Belgium at this point, and I believe we didn’t yet have in-house recruiters. I recall joining 11pm local interviews, rationalizing that I’d be back in Austin a few months later. We were met with good fortune again in finding Matt McDaniel, whose recent work on Stride and earlier Hipchat were directly relevant to Zello’s clarified direction. Matt was responsible for extensive work on our Desktop app, which sawn his stewardship following an inaugural design sprint from Amy and preceding my Q1 2021 refresh.

Since then, I’ve hired two product designers, hired a design engineer, onboarded a junior PD from our Product Advocates, inherited a ridiculously talented visual designer, and manage the team. While the stages and broad strokes from the following process apply to diverse design roles, these specific exercises and competencies specifically pertain to product designers.

Today’s process

While the interview process has changed significantly over time, the exercises have only been further practiced, and we’ve deepened our sense of signal. In 2017 I couldn’t have told you what a “competency” was beyond work assessments and highly subjective assessments of soft skills, whereas nowadays… I’m working on it. Then and now I prefer to judge a designer by the intersection of their portfolio and self-description, but can tailor my takeaways for those who prefer the descriptive or others preferring the deductive.

I’ve always used this same stable of exercises to assess applicants, an while the order and occasionally instructions have changed, the exercises are more or less unchanged.^[2]

This process ideally takes under three weeks with up to a week to review the initial application, scheduling two screening calls the next week, and scheduling an onsite the following week.

The application and portfolio

Depending on a role’s seniority, we have a hard check against years’ experience. We may also limit applications to those authorized to work in the US, and those willing to work in a hybrid or in-house position in Austin. I then review applications and advance those who meet our design standards, taking specific note of balance between aesthetic sense, platform knowledge,^[3] pattern knowledge, research, prototyping, and influences. I also keep an eye out for how a candidate describes themselves, to later get a feel for their polished and prepared tone as opposed to their live presentation.

This is a candidate’s opportunity to present their best work in a controlled scenario, and so I look for candidates who put their best foot forward. Lastly, many portfolios focus on process over outcomes. While process matters, process is not the deliverable—outcomes are. Hook me, show me what you affected, tell me why it matters and why it’s good, and then show how you arrived there. Show me the paths you could’ve taken and why instead you landed on this outcome. When discussing your work— in your portfolio and later—describe your team and influences, and send a strong signal on the importance of collaboration and knowledge-sharing.^[4]

Screenings

When a portfolio checks out, a recruiter and I separately interview a candidate. There’s a high-enough rate of misalignment between application and reality that we’ve occasionally has a nontrivial drop-off rate following the recruiter interview. Then, I like having an opportunity to get to know a candidate myself before reaching formal exercises.

Recruiter interview

Once I advance these candidates, they proceed to a recruiter interview to confirm further fit with the specific job description. Barring a misalignment between application and discussion—or aggressively unpleasant conversation—folks move on from here to a hiring manager interview with me, where I further investigate a candidate’s self-description.

Hiring manager interview

We discuss a candidate’s path to design, and the different types of projects they’ve taken on and platforms they’ve worked on. We discuss examples of helpful and unhelpful feedback, and how a candidate navigates contradiction and ambiguity. We discuss a candidate’s process, which I use to passively gauge deliverables and processes a candidate considers foundational or auxiliary. I don’t like to ask the immediate question I’m seeking when there’s often a performatively right answer, so one uses other questions to paint the surrounding terrain. Ask anyone and they’ll tell you that collaboration is good, but ask them about their process and you can judge the degree to which they consider collaboration a way of working versus simply accepting feedback versus the occasional and proud lone wolf.^[5] I like to additionally ask a candidate about risky decisions and compromises they’ve made—it’s a potentially leading opportunity to over-index on collaboration, but I often find candidates swerve in the other direction and describe conflict and internal politics. I try to get a feel for where a candidate’s process ends — do they work with dev in implementation? Do they track success metrics and reintegrate learnings in their next work? Do they simply move to the next project, washing their hands? Lastly, the candidate has fifteen to twenty minutes of the hour to ask me questions about the role and company.

I aim to learn what drives a candidate, what it’s like to work with them, what value and deliverables they bring to the table without coaching, and their aptitude for flexibility and learning new processes.

Onsite exercises

Following successful screens, our recruiter schedules an onsite interview and arranges candidate travel. We also email the candidate detailed descriptions of the day’s sessions. I brought three of these five to the table back when first writing our process in 2017, and they continue to highlight talent now.

Panel portfolio critique

A candidate is instructed to prepare a deck walking us through two or three hand-picked projects, hooking us with outcomes and then walking us through narrative. While an online portfolio casts a wide net, a candidate can now tailor their case studies to Zello. We want to see what decisions were made, which options discounted, and why. We want to see the processes used to make decisions. We want to see one’s work from visual design through systems, competitive analysis, research, user testing, and handoff. We want to hear what you learned, what you would’ve done differently, and how you grew from those learnings. Like earlier, we look for signal on cross-functional collaboration. Newly, we see how a candidate thinks on their feet during each projects’ critique.

Design challenge

Or, “whiteboard exercise.” A cross-functional panels of PMs and designers provide the candidate with a prompt, and the candidate leads a collaborative session in which they show us what we have to gain by working with them. This is a chance to demonstrate discovery and facilitatory processes, and show one’s process from discovery through design. While the portfolio review demonstrate completed work and relies on self-narration, the design challenge asks a candidate to demonstrate their process.

Many take this as an opportunity to lead us through their unique work, or to go into the cave and come back out with an opaque solution. I’ve softened over the last few years, and now prompt candidates when their exercise veers too far from collaborative. Despite that, candidates prone to isolation still find ways to avoid collaboration.

Third-party critique

By this point, a candidate’s demonstrated their own work, and shown us their collaborative process live. This exercise surfaces a candidate’s ability to turn a critical^[6] eye towards a third-party product^[7] and describe it as a product designer. For candidates skewed towards UX from UI and Visual, or towards Research from UX, or more generally lacking in any specific speciality, this is an opportunity to show what while you’ve done that work less, you understand its principles and can both observe and discuss. We want to hear candidates describe what’s before them as visual designers, and UI and UX designers, but also in terms of user personas, growth, cultural influences, monetization, and business goals. I want to hear a candidate separate themselves from the user in the same way that we are not our user. This exercise further surfaces ego, but in a different way than the other two. There’s a world of difference between “I wonder if they did X because of Y”, “why did they do X??”, and “X is awful; I’d do Z instead.”

Cross-functional interview

We try to keep the previous three exercises in order, but may fit this cross functional discussion—and another break—in-between the previous sessions. This session is a reality check on a candidate’s developer handoff and overlap, often conducted by one of our engineering managers. Beforehand I’ve explored these topics with a candidate, but they’re not my focus.

Executive interview

Nowadays, candidates meet with our COO for further conversation. Bruce is ridiculously discerning, and I’ve found his insights on candidate motivations and growth to be remarkable. I personally have a difficult time pulling myself out of the weeds of a candidate’s work, and this session helps me to align at a high level.

What’s next?

Following the onsite, we make our decision, and move forward.

Reflections

I’ve kept my three exercises through different iterations of our recruiting team. With their feedback, I’ve had to further figure out which parts of the process matter most to me. Some recruiters want to avoid lengthier sessions whereas others prefer longer days if fewer. I’ve seen other roles come and go that push for a unified recruiting process across jobs and to the exclusion of specialty-specific exercises, but we’ve stuck it out—like engineers benefit from pair programming sessions and code challenges, designers need skill evaluations.

And if any of this describes you, I’m hiring.