Why I don't do design tasks when applying for a job
I’ve been designing for fourteen years. I have a portfolio. I have case studies. I have Figma files you can open right now and see exactly how I think, how I name things, how I structure a project from brief to handoff. And yet, sometimes, a company will ask me to spend a weekend solving a hypothetical problem for free before they’ll consider hiring me.
I say no. Not because I think my ideas are too precious to share. I have ideas every day. Most of them are bad. The good ones only become good after weeks of context, research, and conversations I couldn’t possibly have during a design task.
I say no because the exercise itself tells me something about the company. And it’s usually not something good.
What they actually test
A design task tests how quickly you can produce polished work with almost no information. No access to users. No understanding of technical constraints. No business context beyond a one-paragraph brief. No collaboration with the people who’ll actually build the thing.
Peter Merholz wrote about this in Org Design for Design Orgs: the artificial constraints of design exercises bias toward facile problem-solving. You end up rewarding designers who can make something look right in four hours, not designers who can make something be right over four months.
Sean Filiatrault’s team at Clio found the same thing. Their in-person challenge consistently favoured fast thinkers and penalised introspective ones. They were evaluating confidence and speed rather than depth and judgment. So they dropped it.
That’s not how design works. Not the kind I do, anyway.
What they miss
The things that actually matter in a working relationship don’t show up in a take-home exercise. How someone communicates during a project. How they handle feedback that contradicts their thinking. How they organise a file so a developer can use it six months later without a phone call.
Eric Wienke made this point well: his team at AppDynamics hired over twenty designers without a single take-home assignment. A good portfolio already shows you how a designer thinks. If you can’t assess that from their existing work, the problem is your interview process, not their portfolio.
And there’s the fairness problem that nobody wants to talk about. Take-home tasks favour candidates with the most free time, not the most talent. A single parent working full time will produce something very different from a recent graduate with nothing else on. You’re not comparing skill. You’re comparing circumstances.
What I offer instead
When someone asks me to do a design task, I offer an alternative. Open my portfolio. Pick a project. I’ll walk you through it in as much detail as you want. The decisions, the dead ends, the things I’d change if I did it again. That conversation tells you more about how I work than any hypothetical wireframe could.
Better still, open my Figma file. Look at the layers. Look at how the pages are structured. Look at whether things are named properly or called ‘Rectangle 42’. I wrote about how I structure mine. That’s not a performance. That’s how I actually work, every day, on real projects.
If you need something more hands-on, I’m open to a paid trial day. I’ll work on a real problem with your team, in your tools, at your pace. You’ll learn more in eight hours of actual collaboration than you would from a weekend of unpaid guesswork. And I’ll learn whether I actually want to work with you, which matters just as much.
Joel Marsh made a fair counterpoint: if your ideas are worth stealing, you’re worth hiring. I don’t disagree. But the issue was never about theft. It’s that the format is broken. You’re evaluating a designer’s ability to work alone, under pressure, with no context, on a fake problem. That’s not a useful signal. It’s a stress test dressed up as a design exercise.
The one exception
I’ll do a design task if it’s narrow, specific, and addresses a genuine gap in my portfolio. If you need someone who can design data-heavy dashboards and my portfolio doesn’t show that, fair enough. Give me a focused exercise that tests that specific skill. Keep it under two hours. Be clear about what you’re evaluating and why.
What I won’t do is a broad end-to-end scenario where you hand me a vague brief and expect a polished solution by Monday. That’s not an interview. That’s unpaid work with uncertain returns, and it tells you almost nothing about what I’d actually be like to work with.
Filiatrault’s team at Clio replaced their design challenge with deeper portfolio reviews and structured interviews. They found it more fair, more consistent, and better at identifying good designers. Wienke’s team at AppDynamics never used one in the first place and still built a strong design org. The pattern is clear. You don’t need the task. You need better questions.
If you’re a hiring manager still relying on take-home exercises, ask yourself what you’re actually learning from them. Then ask yourself what you’re losing. The experienced designers who see the exercise on Glassdoor and quietly move on to the next opportunity. You’ll never know they were there.
Skip the task. Open my portfolio instead.
