Strong candidates don’t start drawing

I’ve run design challenges as part of the interview process across 20+ hires — co-ops, product designers, senior designers, researchers, and managers. The most common failure I’ve seen isn’t weak craft, nerves, or unfamiliarity with the tools. It’s picking up the marker before asking a single question.

I want to explain what’s actually being tested in a design challenge — because I don’t think most candidates know. And if you’re preparing for one, this might be the most useful thing you read before walking in.

The brief is vague on purpose

The brief we use is a single sentence: “We’d like you to design a parking lot for us.” That’s it. No users defined. No site described. No constraints offered. The candidate gets the sentence, a whiteboard or shared digital canvas, and about 15–30 minutes.

The vagueness isn’t an oversight. It’s the entire design of the challenge.

The scenario has a real answer behind it — a rest stop off a highway serving everything from motorcycles to commercial trucks, with safety considerations, spatial constraints, and accessibility requirements that only surface through questions. There’s genuine complexity hidden in a simple prompt. But that complexity only becomes available to the candidate if they ask for it.

What the candidate does in the first two minutes tells me almost everything I need to know.

What I’ve actually watched happen

I’ve watched candidates start drawing immediately. Rows of identical parking spaces, a central entrance, maybe some trees. Organized, confident, fluent with the tools. And completely wrong — because they’ve designed a shopping mall parking lot for a highway rest stop that needs to accommodate semi trucks.

They designed the wrong thing with complete confidence. No amount of craft rescued it.

I’ve also watched candidates set the marker down, turn to the panel, and ask: “Who is going to be using this space?” Then: “What’s the context — is this a commercial lot, a rest stop, something else?” Then: “Are there any accessibility or safety requirements I should know about?”

Those candidates hadn’t drawn a single line. But they were already ahead.

What the challenge is actually testing

The challenge isn’t a test of how well you draw, how fast you work, or whether you arrived at a “correct” answer. There isn’t one. It’s a compressed version of the first conversation that should happen on every real design project.

Every project starts with an open-ended brief. Every project has hidden constraints. Every project has users whose context you don’t fully know yet. The question is whether you know how to start — whether you establish context before committing to a direction, or whether you jump to solutions because the blank whiteboard makes you uncomfortable.

That habit — assuming vs. asking — shows up in real work too. Designers who assume produce work that gets revised repeatedly. Designers who ask produce work that holds up.

A structure that works

Strong candidates tend to move through a consistent rhythm, even if they’ve never been taught it explicitly. Here it is made explicit.

Step 1 — Ask questions before you touch the whiteboard

Ask about the goal. Ask about the users and their context. Ask about constraints — site, time, budget, any relevant details. Write the answers down on the board as you receive them. This isn’t stalling — it’s the work. The panel expects it. A candidate who skips this step and starts drawing has already told me something important.

Step 2 — Define the users briefly

Before drawing, name the user types you’re designing for. What are their key behaviours, needs, and constraints? State your assumptions out loud. “I’m assuming this lot needs to serve both passenger vehicles and larger commercial trucks — is that right?” That question alone demonstrates more design maturity than a perfectly rendered sketch.

Step 3 — Write out the key steps or a user story

Before drawing screens or layouts, sketch the flow in words. What sequence does a user move through? What does the design need to support at each step? A written user story keeps you from drawing the wrong view and gives the panel something to follow as you work.

Step 4 — Draw the one or two most informative views

Not every state. Not a complete system. The views that communicate the most. Draw slowly and clearly — a clean, readable sketch signals more competence than a fast, messy one. Label everything. Think aloud while you draw. The panel can’t evaluate reasoning they can’t hear.

Step 5 — Summarize and reflect

When you wrap up, briefly review what you built and the reasoning behind it. Mention what you’d explore with more time. Call out weaknesses or assumptions you’d want to validate. This last step separates candidates who can think from candidates who can also communicate their thinking — which is the version that works in a real team.

The mistake I see most often

It’s not sloppy drawings. It’s silence. Working without narrating. Thinking without communicating.

In a real team, no one can evaluate reasoning they can’t hear. A candidate who completes a beautiful sketch in silence has shown me craft. A candidate who talks through their decisions while sketching has shown me how they’d work on Tuesday afternoon when the PM and a developer are watching over their shoulder.

The other one I see: getting defensive when the panel asks questions. “Why did you put the entrance there?” is not a criticism. It’s an invitation to think out loud. The right response isn’t to defend the decision — it’s to engage with it. Strong candidates say “That’s a good point — I could also see it working this way...” That’s senior design thinking.

What this means for how you prepare

Don’t practice drawing faster. Practice asking better questions. Practice thinking out loud. Practice wrapping up by calling out what you’d do differently.

The challenge isn’t trying to trick you. The panel isn’t hoping you fail. We genuinely want to see how you think — because how you think in the challenge is how you’ll think on the job.

One more thing: the brief will be vague. That’s not a mistake. It’s the brief. What you do with an ambiguous prompt is exactly what you’ll be asked to do when a product manager walks over and says: “Users are complaining about this flow. Can you look at it?” with no further context. Starting with questions isn’t a technique to use in interviews. It’s a habit worth building for the whole career.