Working through design challenges in product design job interviews

Interviewing for a job can be stressful. For digital product designers there’s often added pressure of an on-the-spot design challenge: an exercise in which you’re tasked with walking through a design problem right then and there.

I used to fear the problem solving part of a product designer interview. Attempting to solve a problem in an hour, with unknown constraints, no preparation, and an often very vague objective? That’s a lot of pressure.

In addition to the anxiety these types of challenges would cause I struggled to understand the value of attempting to hack away at an impossible task—design an elevator for a building with an infinite number of floors—or something mundane and completely unrelated to what I’d actually be doing on the job—come up with a really interesting car stereo design. In some cases the challenge was about working on a real-life problem the business was already tackling, which felt like a lazy interview scenario at best.

After a few years of experience behind-the-scenes and dozens of successful interviews I now look forward to design challenges rather than viewing them as stress-inducing, irrelevant, and ultimately futile exercises.

I can see these challenges for what they really are: an opportunity to more authentically share—and reflect on—my problem solving process.

Design challenges are a highly effective way to get signal on skills that aren’t always evident in a portfolio: problem solving strategy, product thinking and scope analysis, communication, collaboration, prioritization, and so on.

Interviewers are looking for specific behaviors during these challenges:

  • Do you shy away from an ambiguous or daunting task or are you the type to dive right in?
  • Do you jump to conclusions or ask a lot of questions?
  • How thorough are you when exploring a problem or potential solution?
  • Do you ask to clarify objectives of the challenge and what the outcome might be, or make assumptions?
  • Do you suggest the most straightforward solution or try and push boundaries?
  • Do you doodle when you think or write or openly talk it through?
  • Can you effectively manage your time?
  • Can you lead a conversation?
  • Where do you ask for help?
  • How do you take direction?

A common trait many digital product designers share is our affinity for solving problems; the design challenge part of an interview is a lot like being given a crossword or a photo puzzle to solve as part of the interview process.

You can explore the problem however you want, and the solution doesn’t have to be perfect or ideal because you’re not expected to get it right anyway, your solution isn’t going to get built. The time is used as an exercise in paying attention to how you think, not whether you can solve an impossible or novel problem. The business wants to see how you think about problem spaces, not what you can imagine on your own, outside the expertise of the teams you would otherwise be working alongside if you actually had the job.

These activities are meant to be a fun challenges in problem solving, not some Herculean trial.

How to approach a design challenge

Let’s get one thing out of the way: there isn’t really a “trick” to solving design challenges, apart from: do what you’d do in every day life. How do you solve design problems?

  • Where do you start and how do you measure yourself along the way?
  • How do you leverage information, and how do you act when you don’t have it?
  • What types of questions do you ask at each stage of solving a problem?
  • How do you leverage the other person in the room?
  • How do you prioritize what’s in front of you?
  • Where do you get stuck and how do you keep momentum if you do?

If you don’t feel as though you have a clear process, that may be a sign you need to do a bit more work on developing yourself. Working on more projects, collaborating with others, reading-up on design and problem solving strategies.

Your approach for tackling design challenges is going to be mostly unique to you, however there are universal steps to solving problems which you’ll probably be familiar with. First identifying everything you know, then finding a way to figure out what you don’t yet know.

1. Align on the task at-hand

Before you do anything you’ll need to get alignment and agreement on the task. If you have any questions about the challenge, ask them before doing anything else. One question area you should absolutely get clarity on is the expected outcome of the challenge itself.

  • Is the interviewer looking for any behaviors or skills in-particular?
  • Are you expected to end with a single solution, or is it enough to land on one or two rough ideas?
  • Should you plan to solve the problem in some way, or simply work through it Is the interviewer acting in a collaborative role or merely as an observer?

Typically for design challenges you’ll have access to writing tools like sticky notes and paper or a whiteboard. If possible: write down the agreed upon outcome in big letters so you can be reminded of it throughout the exercise.

You can even come up with a bullet list of expectations and a high-level or stages for the challenge: define, understand, brainstorm, iterate and test, reflect.

If there are no additional questions about the challenge itself, you’re ready to start.

2. Identify everything you know

“A problem well stated is a problem half-solved.” — Charles Kettering.

When you first begin working on a design challenge you’ll want to consider everything you can be fairly certain about and everything you don’t know but might be able to find an answer to during the challenge.

  • If the interviewer is playing a collaborative role, ask about what you can be certain of and what you’ll have to assume?
  • What are the constraints? Should you invest time defining additional ones before diving in?
  • What type of person or customer matters most in the scenario and who matters least?
  • What are the business objectives in the scenario?
  • What hurdles might you be able to predict right away?

If the problem is founded in real life, ask if the team has already tackled the problem before and if so: are there any learnings that can be shared from their efforts?

Write everything asked and answered down. Draw if you have to. Half the time you spend on the challenge should be asking questions, writing down assumptions, and aligning on definitions/goals with the other person in the room.

You want to develop as clear an understanding as possible about what the problem is you’re attempting to solve, why it’s a problem, and what you might be able to do to resolve it.

Once you’ve asked as many questions as you can and gotten as many answers as realistically possible, you’re ready to ideate.

3. Begin exploring what you don’t know

What can you do with what you now know? How might you begin finding answers to the things you don’t?

Focus on diverging ideas first by exploring the extreme ends of the landscape you defined in the previous stage: go as far into one extreme possible solution as you can, then jump to the other end of the spectrum and do the opposite. Repeat until you begin to formulate a more realistic vision of a possible solution.

  • If you know the problem primarily affects a certain type of person, what’s their “user journey” look like and how can a digital product influence that experience?
  • Are any existing solutions you can reference for guidance?
  • What might possible new solutions look like or how might they behave?
  • Where might new solutions fail and where will they succeed?
  • What trade-offs are you going to have to consider while working toward a solution?
  • What edge-cases can you think of?
  • What tools or resources might you leverge in building out solutions?
  • How does technology play a role in the problem you’re exploring, and what facets of digital tools can help create a solution to the problem?

During the ideation stage it’s good to again bring in the interviewer, if they are playing a collaborative role and not merely there to observe. Make the activity into a brainstorm and utilize the interviewer for feedback, for coming up with ideas, or for flagging things you might have missed (it’s totally ok to say: “What am I overlooking?” and “Does this feel like a good direction to you?”).

Remember to always tie what you’re doing back to the expected outcome of the challenge and the problem being solved.

After a reasonable amount of time you’ll want to start converging on ideas. Looking at the most likely solutions or the ideas that get you as close as possible to the expected goal. Start narrowing down some of your explorations and explaining why you’re doing so: “Concept A is strong in this one area, and concept B is strong in this other place, I want to briefly explore what would happen if we focused on the best traits of each as a single possible solution.”

As you progress through a problem it’s vital to communicate your thoughts and rationale.

If you’re drawing something on the board: explain why. If you’re going to ignore a potential problem or drawback to a solution, state as much (you don’t even need to explain why, this is all make-believe anyway and the goal is to progress toward solving a problem). Talk about your thinking, where you’re getting stuck, how you want to proceed. When in doubt: ask if you’re providing enough detail or if you need to be more transparent.

Eventually you’ll land on a place where a reasonable solution will need to be decided on or time will be out. In either case: you should end the challenge by having asked numerous questions, attempted to answer as many as you possibly can (or theorize what answers might look like), and finally be ready to reflect on the challenge before concluding.

4. Reflect on the challenge

With a few minutes to spare, take time to reflect out loud.

  • Did you solve the problem or prompt?
  • Are you happy with where you ended up or dissatisfied?
  • What would you change in your process or approach for next time?
  • What surprised you about your approach and what felt normal?

Interviewers want to see self-awareness and reflection, as both are important traits of a good problem solver.

If you bounced around too many ideas unrelated to the primary problem, if you were unable to pursue important questions, if you failed to address a question or concern, what would you do differently if you had to do it all again?

That’s pretty much it.

Before you know it the 45 minutes or hour will have passed and you’ll have a whiteboard or stacks of paper filled with words and drawings and some semblance of a solution to a problem nobody expected you to fully resolve in the first place.

If you had a week, or month, or year to solve the problem, it’s expected you’d make more progress than you ever will in a design challenge. On the job: you’d have more time to invest in understanding the problem and potential solutions, you’d have many expert partners and resources to help you along the way.

The design challenge is a highly condensed format of the day-to-day work you might do as a product designer, so nobody expects you to come up with an ideal solution or to demonstrate a perfect process from understanding to building. Coming up with a great solution is simply a bonus in the evaluation process of interviewing.

When you go into a design interview and see something about a challenge or exercise on the schedule, remember it’s a good opportunity to have some fun, explore a problem space you may not be familiar with, and where you’ll get a chance to work on a problem nobody expects you to really solve.

Author: Tanner Christensen

Collect by: uxfree.com

Comment

Top