Our view at OSAM is simple: a test task can be useful, but only at the right moment and at the right size. Done well, it helps both sides. Done badly, it’s disrespectful to the designer and tells you more about the company than about the candidate.
Here’s how we think a test task should work, and how to spot one that doesn’t.
Never as the first step
Sending a test task right after someone applies is, frankly, a bit rude. The designer hasn’t talked to anyone yet, doesn’t know the team or the product, and is already being asked to invest hours of work. It also tells candidates the company would rather filter people by unpaid effort than spend thirty minutes getting to know them.
In an ideal process, the order looks like this:
- Screening with HR. A short conversation about experience, expectations and fit.
- Interview with a designer from the team. They look at your portfolio, ask about your decisions and see how you think and communicate.
- Test task. Only now, and only if it’s needed.
By the time someone reaches step three, a designer on the team already likes their portfolio and they’ve shown they’re easy to talk to. The test task then has one clear purpose: to see how the person actually works through a real problem. Not to sort through a hundred strangers.
Real tasks or invented ones?
Some companies give candidates a task taken straight from their own projects. There’s a real upside to that: it shows much better how a designer will fit into the team’s style, product and way of working. An invented brief about a fictional coffee app can’t tell you that.
The downside is just as real. Being asked to solve an actual problem from a live product, for free, can feel suspicious. Is this a test, or is the company collecting free design work from a dozen candidates?
There’s no universal answer here. It comes down to whether you trust the company. A few things can help you decide:
- Has the company been open about its process and timeline?
- Did you already have real conversations with real people there?
- Is the task small and clearly a sample, or is it a full feature they’d obviously ship?
- Do they explain how your work will be used, and that it won’t be used without your agreement?
If the task feels like a genuine sample of the job, it’s usually fine. If it feels like you’re doing their sprint for them, trust that feeling.
Size matters more than anything
This is the part we feel most strongly about. A test task should never take more than one or two days of work.
Asking for three app screens, a web version, a presentation, a logo and a set of mockups "to make sure you can do everything" is simply nonsense. Nobody learns anything from a candidate’s week of unpaid exhaustion that they couldn’t learn from a fraction of it.
Here’s what’s actually enough: one app screen plus a short note explaining the design decisions.
That single screen already tells you a lot:
- Whether the designer knows the core principles of interface design.
- Whether they get sizes, spacing and platform conventions right.
- How they use auto layout and components.
- How they work inside the design tool.
- What research they did on the topic.
And the note is where the real gold is. In it, the designer can explain why they made each choice, what they considered and rejected, and what they would add with more time. That shows their thinking, which is exactly what you’re hiring for. One thoughtful screen with a clear explanation says more than ten polished screens with no story.
Red flags: when a test task crosses the line
Unfortunately, the small, well-placed test task is rare in practice. Much more often, companies overdo it: a huge brief, a week of careful pixel-pushing, ten app screens for no clear reason. Watch out for:
- A test before anyone has spoken to you. You’re being filtered, not considered.
- A scope bigger than one or two days. Multiple platforms, full flows, branding on top.
- Vague success criteria. If they can’t say what they’re evaluating, they don’t know either.
- A real feature with a tight deadline. Especially if it looks exactly like something on their roadmap.
- No feedback afterwards. You spent days on it and got silence or a one-line rejection.
If you see these signs, you have options. You can politely ask to reduce the scope ("Could I do one key screen and explain the rest in a note?"), ask whether the task is paid, offer a walkthrough of a similar project from your portfolio instead, or decline. Turning down an abusive test task isn’t losing an offer. Often it’s dodging a company that would treat your time the same way after you’re hired.
How to nail a good test task
When the test task is fair, small and comes at the right stage, it’s your chance to stand out. A few tips:
- Clarify before you start. Ask what they’re evaluating and how much time they expect. Good companies are happy to answer.
- Do a little research. Look at the product, its users and its competitors. Even an hour of research shows up in the result.
- Go for depth, not volume. One screen done thoughtfully beats five done in a hurry.
- Keep the file clean. Named layers, components, auto layout. Reviewers will open your file, not just look at the export.
- Write the note. Explain your choices, the trade-offs and what you’d do next. This is where you show you think like a product designer.
- Respect the time limit. Going far beyond the expected scope doesn’t impress. Being able to prioritize does.