Design Engineer Interview Preparation: Connect Your Portfolio to Production UI Code

A design engineer interview should make one piece of work traceable from a user problem to a shipped interface: visual decision, component behavior, code boundary, accessibility, release, and feedback. A polished gallery does not show that chain. A repository full of components does not show why the interface was designed that way. Bring a small number of artifacts that connect both halves, then be precise about what you personally designed, implemented, and learned.

This article addresses the portfolio story around such work: how to prove that an interaction survived real users, data, devices, and code review. Ashby's public Design Engineer posting provides a detailed example of one employer's expectations; it is not a universal interview template.

What a design engineer portfolio must prove

The role sits across design and front-end engineering, but the mix varies by employer. In Ashby's Design Engineer posting, the team describes work on a mobile web redesign, composable design-system components, and improving the information hierarchy of a candidate-assessment view. The posting explicitly expects both visual craft and shipped code used by real people. It also says the process includes a work screen-share, a technical screen or design take-home, and discussions of a past design or design-system project. Those are Ashby's stated stages, not what every design engineer role will use.

The central portfolio question is therefore not “Is the screen beautiful?” It is “Can the candidate explain how this interface behaves, why its details matter, and what happened after it was implemented?” Choose a project with enough depth to answer that. A single scheduling control with complex states can be stronger than an expansive concept app that never handled loading, errors, keyboard use, or maintenance.

If your work has not shipped, say so. A prototype can still show strong taste, interaction thinking, and implementation skill, but it cannot support claims about production adoption or user outcomes. Label mock data, proposed flows, and simulated feedback. Interviewers can respect a clear boundary more than an inflated “impact” claim.

Select one project with a complete evidence chain

Rank candidate projects against six pieces of evidence: user problem, design alternatives, implemented behavior, code ownership, release context, and observed feedback. Pick one primary example where you can show most of the chain and one backup that demonstrates a different strength. Do not lead with the most visually striking page if the only implementation evidence is a static screenshot.

Consider an original scheduling example: a recruiter chooses interview slots across time zones, and a candidate sees available times. The visual surface is a compact calendar. The production problem includes stale availability, keyboard navigation, loading delays, conflicting holds, narrow screens, and locale-specific formatting. The portfolio can show how a design choice survives those states rather than only its default appearance.

Evidence stage	Artifact to show	Question it should answer
Problem	Brief, support signal, or observed workflow	Why was this worth changing?
Design	Two rejected alternatives and the chosen flow	What trade-off did you make?
Component	State and interaction contract	What can a user do in each state?
Code	Relevant implementation or review diff	Which part did you build and maintain?
Release	Test and rollout note	How did you know it was safe enough to ship?
Feedback	Usability finding or production observation	What changed after real use?

This trace table is the first topic-specific asset. Fill it with actual evidence, not aspirational descriptions. If you lack a measured improvement, discuss a concrete observation: a support ticket category fell, a confusing interaction surfaced in usability testing, or a keyboard path failed and was repaired. Do not invent percentages or claim that a design-system component “scaled” simply because it was reusable in theory.

Walk from pixels to interaction states

Show the default view, then the states that force engineering decisions. In the scheduling example: no slots, slots loading, slots available, slot selected, hold expired, save in progress, save failed, and success. Explain where the user's attention goes in each state. A skeleton might avoid layout shift but could imply availability before it is confirmed; a disabled button might hide why action is unavailable. These are design and code questions at once.

Choose one visual detail and explain its behavioral role. Perhaps a time-zone badge appears adjacent to every displayed slot, not only in the page header, because candidates compare several slots quickly. The implementation must format each slot consistently and handle a locale change. A portfolio story becomes stronger when the detail has a reason, a data contract, and a test. “I made it cleaner” does not tell the interviewer what changed for the user.

Ashby's posting describes flexible components for setup wizards and a mobile redesign informed by user conversations. The transferable lesson is not to copy those exact interfaces. It is to show how your own component boundary helped a product team move faster without flattening the experience into one rigid pattern. A component with twelve boolean props may be “reusable” yet difficult to understand. Explain the variation you allowed, the constraints you enforced, and a case you intentionally did not generalize.

Connect the design file to production code

Open the implementation at a meaningful point, not at the repository root. Show where the component receives data, owns local interaction state, renders semantic controls, and reports a user action. If the design system supplies tokens and primitives, identify what you reused versus added. If an engineer teammate wrote the code, clearly state your contribution: behavior spec, design review, accessibility testing, or pairing. Do not relabel another person's implementation as yours.

For a React scheduling control, stable identity matters. A slot keyed by display index can shift when availability refreshes, making selection appear to jump. React's state-preservation documentation explains how identity and position affect state. You do not need to deliver a lecture on reconciliation. Show the concrete bug: “A refresh inserted an earlier slot; we changed the identity to a stable slot ID and tested that the selected time remained selected or was explicitly invalidated.”

Async behavior matters too. If two availability requests race, the older response can overwrite the newer one. Show the request ownership or cancellation policy and what the interface displays while it resolves. If the slot disappears between selection and confirmation, do not silently submit a stale ID. Explain the error copy, focus target, and retry path. A design engineer's code review should recognize that these are user-experience defects, not just backend edge cases.

Demonstrate accessibility as interaction quality

Choose the appropriate native control before adding ARIA. For a searchable selection widget, the W3C's combobox pattern describes keyboard interactions and semantics, but it is a pattern to implement and test—not a badge earned by adding a role attribute. In a portfolio walkthrough, explain how Tab reaches the control, how arrow keys navigate options, how Enter commits, how Escape dismisses, and where focus goes after an error. If the interface is a calendar grid rather than a combobox, say why its behavior differs.

Test the actual interaction path with a keyboard and a screen reader where possible. A focus outline that disappears on mouse click may be fine; a focus indicator absent for keyboard use is not. A modal that traps focus must also restore focus to a sensible trigger on close. Responsive checks should cover zoom and narrow widths, not only a 390-pixel screenshot. The interesting portfolio material is often the defect you found and the compromise you made to repair it.

Motion is another design-engineering boundary. MDN documents the prefers-reduced-motion media feature. If a slot-selection animation conveys order or success, explain what remains understandable when nonessential motion is reduced. Avoid saying “accessible” merely because the CSS has one media query; show the before-and-after user path and where you tested it.

Explain design-system judgment, not component inventory

Interviewers may ask whether a one-off improvement belongs in the design system. Work through three options: keep it local, extract a primitive, or create a product-specific pattern with shared parts. The decision depends on repeat demand, semantics, ownership, and change cost. Do not generalize a unique recruiter scheduling flow into a “universal workflow component” after one use. Equally, do not duplicate the same focus and validation behavior across four teams.

In your case study, show one interface that became easier because of a shared component and one edge case the shared component could not support. Explain how you handled both. A useful design-system contract includes states, API, examples, keyboard behavior, visual tokens, and known limits. A screenshot library without those details creates the appearance of consistency while shifting behavioral work onto every consuming team.

Ashby's published examples make this especially concrete: its design engineers build composable components while still doing bespoke design work for product teams. That is a company-specific role signal. In another employer's interview, ask how design-system ownership is divided and whether the role ships product features directly. Use the answer to choose the portfolio example most relevant to that team.

Prepare a screen-share walkthrough with productive stops

Plan a ten-minute path you can shorten. Start with the user problem and what you owned. Show the shipped or working interface at normal size. Pause at one decision the mockup cannot explain, such as handling expired availability. Open the specific code or design spec that implements it. Show an accessibility or test artifact. End with observed feedback and what you would change next. Do not scroll through 40 frames while narrating a polished timeline.

Make links and demos resilient. Have a local video or screenshots if a staging site requires credentials, and do not expose customer data. If a live demo fails, use the failure to show your diagnostic method and the boundary of what you can verify. If your repository is private, prepare a permissible redacted diff or pseudocode-level architecture explanation rather than copying proprietary code into a public portfolio.

Practice interruptions. “What would happen if this API returns out of order?” should take you to a concrete state decision. “Why wasn't this a native select?” should take you to user needs and the additional accessibility responsibility you accepted. “What changed after launch?” should take you to observed evidence, not design intent. A case study that survives those stops feels like production work.

Practice five production-UI questions

Use each linked title to rehearse a different part of the portfolio-to-code bridge.

Question	Practice focus	Portfolio connection
Build an Accessible Recursive Expand-and-Collapse Tree in React	Keyboard and state	Show behavior beyond a static design frame
Debug and optimize React performance issues	Measured performance	Separate an observed bottleneck from aesthetic smoothness
Design a reusable React comment component	Component boundaries	Explain reusable behavior versus product-specific layout
Plan Testing and Deployment for a React Feature	Release quality	Connect a visual change to tests and rollback
Build an Interactive Filtered Tree View	Async visibility and focus	Explain what happens when data removes the active item

After each answer, add one actual artifact from your portfolio: a diff, a test, a design state, a support observation, or a release note. This habit turns generic interview practice into evidence about your work.

Close with the part only you can defend

Before interviewing, write three short statements for your main project: “I chose this interaction because…,” “I implemented or specified this behavior by…,” and “After release, I learned….” If one line is empty, find evidence or choose a different project. The objective is not to present a flawless process. It is to show an honest path from product need to usable, maintainable code.

For an Ashby interview, the official role description should guide which examples you foreground. For other employers, reread their own posting and invitation.

Sources and Further Reading

• Ashby Design Engineer role and published interview process
• W3C ARIA Authoring Practices combobox pattern
• React documentation on preserving and resetting state
• MDN documentation for prefers-reduced-motion

Research note: Sources were checked on September 27, 2026. Ashby is a documented example, not a universal design-engineer interview process. The scheduling-control case is an original practice example.