Hey Radley,

If you're referring to the original post, mind identifying the design problem? Who are you solving the problem for?

I'm curious how you arrived to your conclusion.

Ray, thank you for chiming in.

I always find it's more beneficial to present the designs yourself instead of just handing them off.

I don't know of a designer who doesn't or would prefer to given such a tight window to complete this in.

Like yourself, I prefer to present my work instead of handing it off in a PDF or by way of a link. Presenting I think is an extremely important skill to have and get better at, for it's how you'll be relating to your teammates more than the aforementioned methods.

As a design lead, I want to know how you present your work, especially in the case that I may not have heard you go through your portfolio.

In the context of an interview, it's how designers assess those s/he'll be working with in terms of design critique within a working culture.

After phone/video screens, we pass along a design exercise asking you to identify problems instead of solving them. We use this to gain a better understanding of how you think and write about design; whether you can code, design UI, etc comes from a portfolio.

Thank you for the thoughtful reply and hiring process note.

"Design is as much about finding problems as it is solving them." is a quote I've used to define what we do.

Really excited to see what Github has been up to given the recent scaling of the design team. Side-note question: what do you think about Zenhub?

The truth is hiring is difficult and the time required for due diligence is the employers responsibility not the interviewee.

Thanks for your comment, Lee.

I think your comment raises the same concerns I had. This seemed like an exercise that less than four hours was invested to put together. To me, it says that the org values their time more than the designer's, therefore sending the wrong message as to how they value their talent.

Overall, it just is without regard or empathy for the person they are considering to hire.

I've been a part teams where the product owner commits so little to the scope or product definition (or general context) that it puts the responsibility on others to do more than their role requires. It can lead to the appearance of over-stepping boundaries and overall set a bad precedent within teams when others begin to pull up unnecessary slack.

If it becomes common practice, it can waste a ton of time attempting to arrive at some level of actionable clarity.

Hey Ben,

I think there are some assumptions that have coupled the exercise and Fran's comment. Not being condescending, but have you viewed the design exercise in the original post? Tried to walk through it or put yourself in the same situation?

Would you be privy to completing it for the sake of substantiating your comment?

If I were to reiterate the initial post, I'm curious how feasible this is for a designer to complete. I'm curious if this exercise is valuable to not only the company, but for the designer. What can be learned about the designer except that they are willing to make sacrifices to prove they have grit and can 'get the job done?' What does this particular exercise say to a designer about how the organization values its talent?

Since it (may seem) seems fair to you, how would you approach the exercise? If you run into any stumbling blocks, given a four day time frame, how would you complete it? Given all this, if it raises any flags for you, what are they?

After viewing the assignment, and if you find it to be unfair or unfeasible, how would you have replied?

Definitely not trying to be cynical here, but I think it's key to dial in on the initial post as a matter of practice and fact, weighing the situation of both designer and organization.

Definitely appreciate different points of view, so thanks for taking the time to engage the original post and other comments in a comment-reply.

Hey Ian, thank you.

One of the thoughts that crossed my mind was whether or not the exercise had been tested internally before it was assigned to me. For me, I was curious if these expectations had in fact been assessed by the lead him/herself and validated.

We're in an time where designers are asked to consider how they will measure the effectiveness of their work. It in some ways made me wonder whether or not this was how design functioned internally within the org.

It also had me wondering what is meant by 'an app?' Sketched, wire-framed and or prototyped? Again and to you and other's mention, it was definitely a bit broad and left me wondering where to start (or stop for that matter).

Thanks for taking time to think and comment.

I went through all of that only to be told that wanted to consider me for a different role, and that I would have to all of that over again.

Thank you for your comment, Brian. A couple things.

I was referred by a previous designer and my portfolio and CV went along with the referral and application.

My work was previewed and surveyed by the lead prior to them getting back in touch. I was interviewed by a visual designer, someone in HR and the lead designer there.

Prior to the design exercise, I'd say about six or so hours were engaged over the course of a week, which one would think is a fair amount of time to know whether or not a candidate will fair for the job.

But to your point, one does begin to add up their availability and time over the course of several interactions, especially when they feel they've gone well.

I think design (and coding) exercises are fair when considerate, but I also don't think they are reserved for every person.

If I'm referred someone, say a developer, by an esteemed colleague whom I can vouch for, I'd like conduct a different style of assessment, especially after viewing and digging their work. I might feel that putting them through a code challenge would be patronizing, especially if I know that they have worked on projects with a similar stack for similar use cases. I would likely probe them along the lines of more specific problems they solved and how they may have worked with others to solve them.

The key mention in all this is the acknowledgement and respect for other's time. It's valuable, not just to organizations, but especially to people who work in them. And I think if you're hiring a designer, consideration and empathy should be forward in any attempt to bring them on board. It's the lens in which we should be approaching our work.

Again, thanks for the comment(s).

Hey Cory. I think the assignment made it into my inbox on a Monday and was asked to be delivered by 8am Friday of the same week. So that's about four calendar days, but doesn't take into account any other obligations in flight. Thanks for your thoughtful comment.

Thank you, mate. Very thoughtful response.

Krishna, I'm terribly sorry that was your experience. All valid and an indicator that the problem is deeper than just the app, but who it connects on the other end. I'm curious if they'll get it right after having more knowledge of how there are people out there who just aren't with the program.