Hi Taylor! Here's what we do. Two design challenges, less than an hour total. Done in the presence of one or two other co-workers (not just designers, but the people most likely to work the hire on a daily basis) who evaluate with a pre-created grading rubric (super important to avoid bias).
We have a few tests to choose from depending on the role, but here's my go-to default. Find a case study of an actual app design (e.g. any long-winded post on Medium lol) that spells out some random designer's process. The more obscure the better (this challenge is most effective if the candidates have never seen it before).
Give designers time to read the case study (e.g. 10-15 minutes) and take notes if they wish.
Then have the candidate present what they liked or disliked about the case study, and what they would've done differently. Finally, ask the candidate whether they would hire that designer at Lucid or not, and why.
I have to note we don't do any follow up questions except to clarify anything confusing the candidate said. We intentionally leave the like or dislike question open ended to let the candidate fill the space (and avoid poisoning the result with leading follow-ups).
This design challenge doesn't require a whiteboard, take home or any of that junk, but definitely will reveal how the candidate thinks on their feet, presents their case, and the type of designers they prefer to work with (or not). And this specific test takes 30 minutes.
Here's the important part, before you use the case study in interviews, have each of your designers take the test first! This will inform your grading rubric of things you should expect or not expect to hear, and help you see whether the case study is too hard or easy to evaluate.
Final note, the grading is done independently and alone. Only after grading do the co-workers share their opinions (again, to avoid influence and bias).
Hi Taylor! Here's what we do. Two design challenges, less than an hour total. Done in the presence of one or two other co-workers (not just designers, but the people most likely to work the hire on a daily basis) who evaluate with a pre-created grading rubric (super important to avoid bias).
We have a few tests to choose from depending on the role, but here's my go-to default. Find a case study of an actual app design (e.g. any long-winded post on Medium lol) that spells out some random designer's process. The more obscure the better (this challenge is most effective if the candidates have never seen it before).
Give designers time to read the case study (e.g. 10-15 minutes) and take notes if they wish.
Then have the candidate present what they liked or disliked about the case study, and what they would've done differently. Finally, ask the candidate whether they would hire that designer at Lucid or not, and why.
I have to note we don't do any follow up questions except to clarify anything confusing the candidate said. We intentionally leave the like or dislike question open ended to let the candidate fill the space (and avoid poisoning the result with leading follow-ups).
This design challenge doesn't require a whiteboard, take home or any of that junk, but definitely will reveal how the candidate thinks on their feet, presents their case, and the type of designers they prefer to work with (or not). And this specific test takes 30 minutes.
Here's the important part, before you use the case study in interviews, have each of your designers take the test first! This will inform your grading rubric of things you should expect or not expect to hear, and help you see whether the case study is too hard or easy to evaluate.
Final note, the grading is done independently and alone. Only after grading do the co-workers share their opinions (again, to avoid influence and bias).