Home/Insights/Design hiring 4 min read · Updated September 2026
DESIGN HIRING · PORTFOLIO REVIEW

Why Portfolios Lie: 3 Questions That Cut Through

Portfolios show final outputs, not design thinking. A stunning Dribbble case study tells you the designer can produce beautiful work; it tells you almost nothing about their process, their judgment under constraint, or how they behave in a team. Three questions cut through: what did you start with, what changed and why, and what would you do differently? The answers reveal the designer you are actually hiring.

PM
Pratik Mokashi
COO, Talhive · 40+ India mandates for US and EU clients
Key takeawaysThe whole piece in five lines
01Portfolios show final outputs, not the design thinking behind them.
02Ask what the designer started with: the problem as first stated and what they learned.
03Ask what changed most between first and final versions, and why.
04Ask what they would do differently; honest answers are among the highest-signal in the process.
05Look for shipped work, engineering collaboration and decisions made under constraint, not polish.
Discuss a mandate →

The best portfolio is not always the best designer.

Product design portfolios have become a genre of performance. Final screens are polished, narratives are edited, and messy process moments are invisible. Here is how to evaluate what is actually underneath.

The designer with the best portfolio is not always the best designer. They are often just the one who spent the most time on the case study.

If you have ten minutes before a hiring review, read only this.

A portfolio looks outstanding
Walk back to the brief
Polish can hide weak problem framing.
The case study has one clean path
Ask what changed and why
Real design work iterates.
Hiring managers are not designers
Use the three questions
They expose thinking, not presentation.

What portfolios show and what they hide.

PORTFOLIO SHOWSPORTFOLIO HIDES
Visual quality and craftDesign decisions made under constraints
Final deliverableHow many iterations it took and why
The scope as presentedWhat was cut and why
The design aloneHow the designer worked with PMs and engineers
Polished narrativeWhat went wrong and what they learned

Question 1: what did you start with?

Ask the designer to walk back to the beginning of any case study. What was the problem as first stated? What did they think it was before they did research? A designer who can articulate clearly how their understanding of the problem changed during the project is showing you real design process. One who goes straight from brief to solution skipped the thinking.

Planning a hire like this? Tell us the role and we will map the right approach within a week.

Book a consultation →

Question 2: what changed and why?

Design work produces iterations. What decision changed most significantly from the first version to the final one? Why? A designer with genuine process will have a clear, specific answer: a user research insight, a technical constraint, a business decision that shifted the scope. A designer who says 'we refined the visual direction' is describing polish, not design.

Question 3: what would you do differently?

The answer to this question is perhaps the highest-signal in a designer interview. Strong designers have clear, honest opinions about what their work missed or what they would approach differently with hindsight. A designer who says the project turned out well is either not reflective enough or not honest enough. Both are problems.

The design hiring practice uses these questions in every evaluation, alongside a live design exercise for senior hires and thorough reference checks with engineers who worked with the designer. Product designers in India are evaluated on the same rubric.

What to look for instead of polish.

Shipped product evidence
can you find the feature in the real product?
Engineering collaboration stories
how did the design change when engineering pushed back?
Decisions under constraint
what got cut and why?
Failure honesty
what did not work?

Portfolio evaluation is a skill that most non-design hiring managers underestimate. A strong visual impression is easy to achieve with the right tools and enough time; genuine design thinking is not. The design hiring practice evaluates candidates on process evidence and engineering credibility, not portfolio finish, and the hit rate on hires that stick is significantly higher as a result.

Where a specialist partner changes the outcome.

Portfolios reward presentation, so design hiring is easy to get wrong. A design-literate search partner evaluates thinking, collaboration and shipped work before you see a candidate.

Real mandates, real numbers.

CASE STUDYArya.ai, AI product companySPECIALIST SEARCH

Seven roles across data science, research, full stack engineering and UI/UX design. Each ran as its own specialist search with one hiring bar, rather than a single high-volume funnel.

ROLES CLOSED
7
INTERVIEW TO HIRE
4:1
OFFER ACCEPTANCE
100%
CASE STUDYketteQ, supply chain planning SaaSPRODUCT & ENGINEERING

Four senior seats across frontend engineering, data science, product management and Salesforce architecture, each needing a different mix of technical depth and product context.

ROLES CLOSED
4
AVERAGE TIME TO HIRE
30 days
OFFER ACCEPTANCE
100%

Building a design team that ships good work?

If you are hiring a first designer, a design leader or a specialist, we can show you the market and the right sequence for your team before any commercial conversation.

A senior team member responds within one business day. No pitch deck, no obligation.

Discuss your hiring plan →

Frequently asked questions.

Look for shipped product evidence, clear articulation of design decisions and why they changed, engineering collaboration stories, and honest reflection on what did not work. Polish is the weakest signal; process is the strongest.
What did you start with, what changed and why, and what would you do differently. These three reveal design process, judgment under constraint, and self-awareness.
It jumps from brief to beautiful final screens with no friction, no iteration, no failures, and no engineering involvement. Real product design work is messy; a perfectly smooth narrative usually means the mess has been edited out.
Yes, for senior hires. A short take-home on a real problem reveals thinking quality in a way that portfolio review cannot. Keep it to two to three hours and use the output as a debrief prompt.
It asks about what the designer actually did rather than what they would do. Hypothetical questions can be rehearsed; past behaviour with specificity cannot.