I've sat on both sides of the table. I've hired designers, been hired as a designer, and — the one that shook me most — gone through my first interview for a Head of Design role. I thought I was prepared. I had a polished portfolio, a clean deck, a strong narrative about team growth and design maturity. What I didn't have was the right mental model for what was actually being evaluated.
Here's what I wish someone had told me before I walked in.
They're Not Hiring a Designer
The first thing to internalise: when a company interviews for Head of Design, they are not hiring the best designer in the room. They are hiring someone to make design matter at the organisational level. That distinction sounds obvious until you're in the room and your instinct is to walk them through your craft decisions.
The panel — typically a CPO, CEO, or CTO — is running a different set of questions in their head:
- Can this person earn the trust of engineers and product managers who don't share their vocabulary?
- Will they push back on bad decisions, or paper over them with good-looking screens?
- Do they understand the business well enough to make tradeoffs — not just design tradeoffs — under pressure?
- Can they hire people better than themselves and not feel threatened?
None of those questions get answered by showing your Figma components. They get answered by how you talk about conflict, failure, and organisational dynamics.
The Specific Things I Got Wrong
I over-indexed on process. I came in with a tight story about double diamond, research cadence, design systems. All of it true. None of it what they needed to hear at that point in the conversation. They weren't doubting that I could run a design process — they were trying to figure out whether I could run a design function inside a company with competing priorities and limited patience for design rigour.
I also undersold the hard moments. When asked about a difficult stakeholder relationship, I gave a diplomatic answer that framed everything as ultimately collaborative. That's not dishonesty — it was how I remembered it. But the interviewer was listening for something else: evidence that I could name the friction, sit in it, and still move the work forward. Clean stories about messy situations read as either inexperience or evasion.
The third mistake: I hadn't thought hard enough about the business. I could speak fluently about design strategy, but when they asked how I'd prioritise the team's focus in a cost-cutting environment, I defaulted to design principles rather than business logic. That's the wrong register.
What to Prepare Instead
If I were doing it again, I'd restructure my preparation entirely around three areas:
- Influence without authority. Have two or three specific stories ready about times you changed something you didn't own. Not consensus-building — actually changing the direction of a product, a roadmap, a hire. The more specific the resistance you faced, the more credible the story.
- Hiring and team shaping. Know your hiring philosophy at a level of detail that surprises people. What do you look for beyond portfolio? How do you handle a team that inherited poor culture? How do you let someone go with dignity? These questions come up and they separate leaders from senior contributors.
- Business literacy. Read the company's recent investor materials, product announcements, or public earnings commentary before you go in. Understand where the revenue actually comes from. Have a point of view on where design fits into their growth model — not as a platitude, as a specific argument.
The role is fundamentally about translation — between design and the rest of the business, between what users need and what the company can execute, between long-term craft investment and short-term shipping pressure. The interview is just the first test of whether you can do that translation in real time, under scrutiny, with people who don't share your assumptions.
Prepare for that, and the portfolio almost takes care of itself.
