Guides / Cracking Interviews

How do I prepare for design and dev interviews?

What companies actually evaluate, and how to prepare for every interview format you will meet.

4 min read • Updated September 2026

What companies actually want

The biggest misconception: companies hire the most skilled person. They do not. They hire the person who demonstrates they can think through problems, explain their reasoning, and work well with a team.

For designers, process beats pixels. A rough wireframe with a clear story of how you found the problem, explored options, and iterated is worth more than a gorgeous shot with no explanation.

For developers, most product companies test practical building over algorithmic wizardry: can you build a feature end to end, read existing code, debug under pressure, and explain a technical decision to a non-technical teammate?

And cultural fit is a real criterion, especially at small companies where the question in the interviewer's head is "do I want to sit next to this person every day?" Genuine curiosity regularly beats arrogant brilliance.

The portfolio walkthrough

Almost every design interview includes 15 to 20 minutes of you presenting two or three projects. This is where interviews are won and lost.

Structure each project as a story: context in thirty seconds, the problem in a minute, process for three or four, solution for two, impact and learnings for one.

The biggest mistake is too many projects with too little depth. Five projects in fifteen minutes means three minutes each, which means just showing screens. Two projects with deep storytelling wins.

Practice out loud, timed, at least five times. Record yourself and watch it back. If they gave you fifteen minutes, finish in thirteen. And prepare for follow-ups on every project: why this layout, how you handled disagreement, what you would change. If you cannot answer those, cut that project.

Design challenges

Three formats, three strategies.

  • Live whiteboard (30 to 60 minutes). Talk the entire time; they are watching your brain work. Clarify the prompt first, sketch a user flow before any screens, draw fast and ugly, explain every decision as you make it.
  • Timed remote (a few hours). Thinking over polish. Spend the first half hour planning and the last hour writing up your decisions. A clear rationale document with average screens beats beautiful screens with no reasoning.
  • Take-home (days). Do not overwork it. If they say four to six hours, do not spend twenty. Scope ruthlessly: pick the core flow, go deep, state what you cut and why.

Across all three, the solution is roughly 40 percent of the evaluation and the reasoning is 60.

Technical interviews for developers

Startups lean practical; big international companies lean algorithmic. Prepare for the one you are actually facing.

  • For algorithm rounds: a few core patterns cover most questions: arrays and hashmaps, two pointers and sliding windows, trees and graphs, basic dynamic programming, binary search variants. Grind a structured problem list for two to three months.
  • For practical rounds ("build a small app with auth in 45 minutes"): the prep is having built many small projects from scratch, so setup, docs, and debugging are muscle memory.
  • For system design: know databases, caching, load balancing, API design, and the standard tradeoffs, and practice narrating a design out loud.
  • Live coding: clarify before coding, state your approach first, start brute force and then optimise. A working slow solution beats a broken clever one. Test with examples out loud.

Behavioral questions and the offer

Use STAR for every behavioral answer: situation in two sentences, your task, the actions you specifically took (most of the answer), and the result, with numbers when you have them. Under two minutes each.

Prepare five or six real stories that flex to different questions. One event that went sideways can answer failure, teamwork, and pressure, depending on which part you tell. Specific stories tell them who you are; generic answers tell them nothing.

When the offer comes:

  • Never give the first number. Ask for the budgeted range. If pushed, give a range whose bottom is your real target.
  • Negotiate the whole package: equipment, learning budget, remote days, bonuses.
  • Never accept on the spot. "Can I take a day to review?" is standard and expected, even for a dream job.
  • Keep interviewing until a contract is signed.

Your next steps

  1. Today: pick your two strongest projects and write each one's story: context, problem, process, solution, impact. Time yourself at under seven minutes each.
  2. This week: write five STAR stories and map each to the questions it can answer. Research the company properly: product, recent changes, competitors, stack.
  3. With two weeks or more: developers, a daily problem-list habit or two small builds in the company's stack. Designers, two practice challenges with a hard time limit.
  4. Night before: stop preparing. Review once, check your setup if remote, sleep. The difference between rested and exhausted shows within five minutes.
  5. After: a thank-you note within a day, referencing something specific. One follow-up if a week passes.

This guide comes from chapter 3 of my journey. That page holds the receipts.

Still stuck? The guides are general. Your situation is not.