How to hire Designers

While hiring for your designers, you should be able to distinguish (to a large extent) at the very beginning what kind of work that they have done, and what their strengths are. Most folks tend to sell to you that, they can do both. I am not a full believer in that yet. Talk to the candidates:

My lead designer and I used to have an intro call with every one of these candidates. You can figure out the ambiguity that I talk about (above) very easily in this call. Talk to them to get a feeling of whether they would fit in, into the culture. See if they can express themselves to you. They need not be eloquent (most aren't) but they need to get their point across. Sample project: Those, who pass the phone call, I had our lead designer send out a sample project to them. Depending on your timeline to hire, this can be as small as redesigning/reimagining a page on an existing app/website; to as big as redesigning a process (the payment flow for instance). We used to give adequate times for these. The smaller projects are 1-2 days, and the larger ones 3-4 days. There is a reason for this. Designers typically take time. One cannot push designers hard, like you can do to engineers. More number of hours does not equals more work, in the case of designers.

We also took a look at how these sample projects were submitted. It shows the seriousness of the candidate. There will be candidates who will submit PDFs. They will be some who will submit sketch files. And there will be some really good ones, who will give you an invision file, with sample click behavior and everything. In-house interview: For the in-house interview, the candidate should talk to one Product Manager (PM), one front end engineer, lead designer, and the hiring manager. If all goes well, one round with the HR.

You probably guessed why the above people were chosen to interact with the candidate. Yes. These are the guys who will be working with the designer. They are the stake holders. You need to know how the designer interacts with a PM and a front end developer. These are one of the touchiest relationships. The PM dreams of impossible stuff to design, and the front-end engineer would refuse to code it up. And the designer is stuck in the middle, typically. How assertive is the designer? How much data is being requested from the PM? Is the designer trying to understand why the front end engineer is saying, something is not possible?

The interview with the designer is typically to touch upon the technicalities. What are the tools he is familiar with? Is he an expert user? Or very novice. How well does he know his interaction design? A lot of this would have come through the sample project. Typically the lead designer (or me) would probe as to why the designer designed the sample project in a certain way. If there is any plagiarism or this was a fluke, this will come out now. History and lessons learnt: Contrary to what everyone thinks, the designers job is a very hard one - playing to the tunes of multiple people and scenarios. They have to walk a very thin line between being creative, and delivering within time pressures ; between making a noticeable change, and preserving your style guide ; between taking up a largish revamp of a page, and making a dozen tweaks for the short term ; taking a call between what the PM thinks, the designer thinks, and the customer perceives. I typically ask the designer, what are the lessons he has learnt on the job, while being a designer, and listen. I would expect some of these above thoughts to come out. If they did not, he has been too passive a member, and has not contributed enough. I probe into some of these thoughts, and see what are the learnings that the designer has been exposed to.