When we’re hiring designers we have different interview types that they go through. We’re trying to assess how designers apply craft, collaborate, manage ambiguity, leverage data for decisions, put the customer first, take ownership, and drive results. Different interviews focus on specific aspects, allowing the interviewers to deep dive into a topic.

Let’s talk about the Portfolio Review

We describe it as picking a specific project and preparing a 30-minute presentation to share deep details on the assignment. We ask you to pick a project that best demonstrates your full design process through to execution and impact. What many people take this to mean is walk us through your design process, showcasing one project.

But reviews like this tend to be pretty surface level. In 30 minutes you can only skate through the overall contours of a project from start to finish. Most candidates are picking a marquee project. It’s impressive, it was successful, it followed a standard design process. But this doesn’t help us understand who you are as a craftsperson.

What we want is a really focused deep dive (so keep it to one project so the context boot-up can be low). We want you to include only the appropriate aspects of your design process, but not everything. Share process only as much is needed to help us understand the problem, the constraints, and why your approach was the right one - but let’s focus on the design choices themselves.

We’re talking to you because we saw something in your experience and/or portfolio that gave us confidence that you might be right for our team: The quality of your artifacts was high, you have relevant domain experience, you solve hard problems in novel ways. Assume that we’re all using a similar process. We all know that you started with a problem, did some research, then brainstormed, then low-fi mocks, then high-fi and then a spec, and then some impact metrics.

In the portfolio review, we’re wanting to dig into your design. We want to see the parts we can’t see just by looking at a nice mock. We want to understand the thinking that went into a decision. We want to know what you fought for, what battles you lost, and why. What paths did you explore before taking the one that shipped?

These are some of the things we’re hoping to learn in our review:

Does this designer swing big enough to solve real problems?

We can learn this with a concise understanding of the problem – and the fit of the core solution to solving that problem. Point out explicitly how the problem and the solution are a good fit, maybe by contrasting solutions which were rejected. Tell us why this mattered.

What are the hard design choices/tradeoffs you had to make?

Tell us about a hard constraint that led to a compromised design solution that you can defend. Tell us about a tension you had to navigate and why you chose to land where you did with your design approach.

What technical or business considerations drove design choices?

Show designs and explain how the technical or business needs shaped them. Maybe you had to design around a limitation in the data, or a regulatory requirement shaped the flow. Maybe you had to use this particular pattern because it was part of the design system, but you would have liked to design something custom because it would have been more efficient for the user’s cognitive work - you went ahead and designed it anyway because you just needed to see it.

What technical or business constraints did you successfully push back on?

Share a specific example of a situation where you needed to push back to deliver a better experience. Who did you need to convince? What argument did you make? Did you have to build support to do something hard? Tell us about what it was and how you did it.

What’s a part of the design you have done differently? (Knowing what you know now.)

Every design could always be improved, especially with hindsight. Or maybe you discovered that users struggled with what you delivered, or you saw that the feature failed and it was tied to a battle you didn’t fight. We want to know if you can distance yourself enough from the work to see it objectively and to always see a way to make it better.

What did you learn about designing for this space that you didn’t know before?

Tell us something interesting that you learned along the way. Name a technology, design, user, or business insight that changed how you see things. Are you paying attention as you design? Are you internalizing and thinking about and evolving your craft as you work?

What battles did you lose?

Share an example of a design decision or pattern you aren't proud of and the story about why it still got included. What were the politics you had to navigate? Can you tolerate that there are many ways to make a decision and some of them aren’t in line with the perfect design, or the best experience for the user? Share how you work when other pressure forces decisions.

What battles did you not choose?

Can you pick a good fight, but also be a diplomat? What concessions did you make and why? Can you make good compromises?

Demonstrate your experience

Consider how the project and the work you share show the level of your experience in terms of scope, scale, and complexity. As candidate seniority increases, we expect to see evidence of projects which required more advanced skills, influence and craft to land successfully. We also expect to see a level of communication and storytelling that make these often complex projects understandable and compelling for people who aren’t familiar with them.

Consider if the work you’re showing and the narrative you’ve giving reflects your best work at the highest level of your capabilities. Choose projects that allow you to show your competency and excellence of craft, with examples that allow you to talk shop about the challenges, tradeoffs, and ultimate impact you hope to bring to your next role.