What’s all this about interviews, anyway?
For the past two years, I’ve navigated the traditional job search process, interviewing for roles across the design spectrum—Product Designer, UX Researcher, Design Engineer, and more. Along the way, a strange theme emerged: interviewees are expected to be experts at being interviewed, while interviewers rarely are. Often, the people tasked with hiring haven’t dedicated themselves to the art of interviewing; they’ve spent their careers doing their actual jobs, whether that’s designing, managing products, or programming.
It’s nearly impossible to correctly judge a person’s capabilities through a simple conversation, but some are better equipped for it than others. Great interviewers know which questions to ask and how to infer the right information—a skill that can be taught through clear guidelines and training.
Unfortunately, I rarely felt interviewers truly understood my strengths, capabilities, or unique caveats. Standard interviews heavily rely on self-reporting through open-ended questions. Anyone involved in design thinking knows that self-reporting is inherently distorted; you have to dig into the user’s (or candidate’s) underlying intents. While some senior leaders that I have talked with have mastered the real-time digestion of information required to ask insightful follow-ups, most interviewers simply don’t have the time or need to hone this specific skill.
What is it about take-home tasks, anyway?
Take-home tasks are arguably a better metric than solving LeetCode problems on the spot, yet they still fail to capture the realities of real work. The design thinking process heavily emphasizes iteration and the humbling pursuit of learning about an unknown user. A one-off task—usually improving an existing screen or mocking up something from scratch—completely strips away this iterative context.
Because these tasks cannot capture the weeks-long process of identifying the correct problem, evaluation often devolves into nitpicking minor UI or UX details. While those details matter, they are the least important aspect of a typical 8-hour testing window. In agile environments, getting a proof of concept to work and elicit real reactions is far more valuable.
With this in mind, design and system architecture whiteboarding serve as much better proxies for a candidate’s actual skills. Interviewers can intentionally omit key details, prompting the candidate to engage in dialogue, clarify assumptions, and ask the right questions to drive the design direction. Ultimately, this reveals far more about how a person works than a polished take-home task ever could.