I've done a small project for 2 companies I interviewed with. One paid me for my time, the other didn't.

One project was an issue the company had already solved. They didn't give me a timeframe or pay me.

The other I had an 8-hour workday in the office to complete the exercise and they compensated me for the time. I liked this better for the obvious reason ($), but also because I had a set timeline to achieve a goal.

I've experienced this on both sides. While interviewing a few years ago, I experienced some who did white-board exercises and others who did a trial project. The only company who paid me was Stack Overflow, who I work for now.

As a Senior Product Designer I help the team identify potential projects for designers we're interviewing. A quick background on our hiring process:

1. Our Creative Director reviews all resumes.
2. Any candidates he deems having potential, he circulates to the rest of the team for review. Mainly it's a yes/no. The CD isn't beholden to the team's feedback, but he considers it.
3. Any candidates deemed worth calling back, our People team will reach out to and field the first interview.
4. Candidates will generally interview with at least 4-5 people before progressing to a trial project. They'll interview with other design team members, PMs, and developers. At any point anyone can NO HIRE anyone.
5. If candidates get through the interviews, we give them a paid trial project at their current freelancing rate for 10-15 hours. At least that's the ideal. The last few hires we've given them 2 trial projects: 1 more of a visual design test and 1 more of a UX/product design test.
6. If the trial project goes well, the candidate then interviews with a VP or the CEO.
7. If that goes well, an offer is extended.

I've been involved mostly in formulating the UX/product design tests. Our process is still rather new here, but we approach trial projects like we would any other project. We identify a something we would actually work on. We provide a project brief, a chance for the designer to ask questions, and a way for the designer to ask questions and solicit feedback throughout the process.

On that last point: that's big. It's highly unlikely someone will pitch you an idea in 10-15 hours that will blow you away. The tests are largely a way for us to get a feel for a person and how they work. A candidate wouldn't make it to a design test if we didn't already think they were smart, talented, or capable enough for the position. Now we're testing each other out. How communicative are they? Are they asking the right questions? Are they pushing beyond the main idea (i.e. do they solve the problem only or do they solve the problem and see the next 2-3 steps the solution potentially provides)?

It's a long process. Hires take about 2.5-3 months to come on board. Yet we're really pleased with the net result so far. Since January 2014 we've hired 4 designers using this approach. All 4 are still on the team. All 4 are super talented.

PS. We're hiring.

There are a lot of good suggestions on this thread. Since you’re focused on mobile UI this is what I’ve done in the past.

I ask candidates to show me an existing app on their phone or tablet that has substandard UI (or room for improvement), take a few screen shots, then show how AND why they would redesign those screens with the existing screen and candidate mockup redesign side by side.

The "existing app" part is important, because I'll often put candidates on the spot during an interview to make them name an app right away. It's to see how good they are at evaluating the apps on their own device, and how quickly they can communicate UI deficiencies. It also gives some insight into how much they actually use mobile apps and are familiar with best-practice design patterns.

It’s important to ask this during the interview, so the candidate doesn’t have time to search for an answer on Google.

Historically, strong UI designer candidates will take a minute to think (I tell them to take as much time as you want), look at their phone, find at least one app right away to complain about, and zero in on how they would fix it. Less strong candidates tend to avoid diving into specifics when put on the spot.

At the end of the interview, if they’re still in the running, I’ll ask them to mock up that screen or two in Photoshop or Sketch, with a short one-paragraph design brief to justify/explain the changes made to the UI. Definitely never more than two screens (I usually say pick the screen with the worst UI), and I’ll try to time box them so they don’t spend more than two hours overall.

When evaluating, the redesigned screen gives me a sense of their visual design kung fu and aesthetic tendencies against a time restraint, while the design brief shows their analytical thinking skills.

Hope that helps. Good luck!

We use trial projects in all of our hiring activities -- not only for designers and developers, but also for support staff like marketing, accounting, admin assistants.

Our design challenge/trial project has been the same for the past few years. We send the designer a creative brief for a mobile application (we use the same one each time) and ask them to do wireframes and 1 or 2 visual design mockups of key interfaces. We designed the challenge so it could be completed to a reasonable degree in roughly 8 hours; many candidates choose to put in more time (16-20) and come up with knockout results.

We do not pay for trial projects; however the project is near the end of a mulit-step interview process and we only issue a trial project if we feel that the candidate is a very strong contender and likely to succeed. It's not worth their time or ours, otherwise.

We have a rubric that we use to score projects. This is helpful for evaluating candidates against one another, and also for comparing challenges over time (i.e. how does candidate x stack up against candidate y from a year ago??) The rubric isn't the be-all-end-all, but it's helpful to have a standard to evaluate against, rather than just gut feeling.

We make sure candidates know that the trial challenge will only be used for the purposes of evaluating their skill, that we will not be using any part of it in current or future client work.

I've done this a few times in the past, when hiring people at former jobs, and using an already-solved task has many advantages (some of them already mentioned here):

• gives the candidate a good idea of the kind of work the company does
• gives candidates a clear picture of what you're expecting them to deliver (I would always show/send them the finished work as part of the briefing)
• you can tell them how much time it took, as opposed to a random estimation for a new task (I've seen companies sending out "exercises" that were supposed to take a few hours which were impossible to solve in less than a few days)
• makes it clear that you're not using them as cheap/easy labour
• lets you know how they work when not starting from scratch (I've seen many designers fail at this, which for me is a must-have skill when working on client projects)
• also lets you see how the previous work influences their own (you can actually file this under 'advantages' or 'disadvantages', but I tend to like designers that have a certain ability to "forget" what they've seen and come up with fresh approaches : )

Of course, using a brand new task has its own advantages, but unless you can bring the candidates in-house for a "guest star" collaboration (a few days in the office, working with the actual team on real problems) I'd go with the solved task approach as a first filter.

Hope it helps!

I find the whiteboard process yields better results than throwing something over the wall.

How the candidate thinks through a problem (and what initial assumptions they make / questions they ask) is almost more important to understand than what they actually produce.

You can conduct equally as effective whiteboarding sessions over distance using a combination of tools like Skype/Hangouts and a collab-drawing tool like Twiddla.

Unless it's only an hour or 2, or occurs during the interview, I would highly recommend paying for the time. Even if it's just a minimal hourly rate. Speaking as someone who has done trial projects, the longer one's that didn't pay anything left me feeling rotten about the company.

I've seen it done before, it can be really useful because some people's value isn't always immediately obvious in an interview. For something as collaborative as design, you need to know how well someone will work with the team. Sometimes someone will be relatively quiet but offer thoughtful, useful insight - and that doesn't always come out in an interview.

Something like a paid project over a couple of weeks is a good way to trial someone. Something that can be finished in that time is good - say, a pitch, or a short strategy piece, or some high-level concepts.

If I was looking for a job, I'd love to see what kind of stuff the company actually works on, as opposed to some theoretical exercise. I'd give them perhaps a small challenge you've already solved in the past, or a less urgent task from your current backlog.