Portfolio & Craft Review
Presenting your work so taste is undeniable
What a DE portfolio must prove
After this you can curate evidence of craft at the design/code seam.
Your portfolio has one job in this loop: prove you can take an interface from idea to shipped and from 90 to 100 yourself, in both Figma and code.
Cursor hires Design Engineers to live at the seam where design becomes production UI. The role description is explicit about it: translate Figma into pixel-perfect React/SolidJS, prototype interactions and own components end to end inside an Electron editor. A portfolio that reads like a visual designer's case-study deck misses the point. So does a GitHub of backend services with no surface anyone can feel.
The reviewer is asking a single question while you talk: would I trust this person to own the inline-diff UI or the agent panel and not embarrass us on the details? Everything you show is evidence for or against that.
Three things the work has to demonstratethe evidence triad
A component or design system you built: variant APIs, theming, composable primitives.
Proves you can contribute reusable parts to a library, not just one-off screens.
Something with real motion, state or input complexity: a drag surface, a virtualized list, a custom focus dance.
Proves you can build the kind of novel UI Cursor is still inventing.
One micro-interaction you sweated: easing curve, empty state, optical alignment, dark-mode contrast.
Proves the 90→100 instinct that separates a DE from a competent engineer.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
How hard the reviewer probes each signal - weight 5 is what makes or breaks the stage.
Notice what is missing from that list: ten of anything. Three deep pieces beat ten shallow ones because the reviewer probes depth and a thin piece collapses on the second question. Curate ruthlessly and cut work you cannot defend at the implementation level.
Make the code visible
A Design Engineer who only shows renders invites the worst suspicion in this role: that a designer handed you the visuals and an engineer wired them up. Close that door before it opens.
- Link the repo, a CodeSandbox or a live deploy for at least one piece - let them read your component API.
- Be ready to talk through the actual implementation: how state flows, where the animation runs, why the markup is shaped that way.
- If the code is closed-source, rebuild one interaction as a small public demo you fully own.
Open with a thirty-second map of your three pieces before you dive in: “I brought a design system I built, one genuinely hard interaction and a small detail I obsessed over.” It signals you curated on purpose and lets the reviewer steer toward what they care about most.
If you have anything IDE-adjacent - a code editor pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance., a terminal UI, a diff viewer, a command palette, a developer dashboard - lead with it or weave it in. Cursor invents interaction paradigms for developer tools, so adjacency to that world is a direct signal you understand the surface. No such work? Say so honestly and point to the transferable interaction craft instead.
Takeaway. Curate three deep pieces - a system, a hard interaction and a sweated detail - and make the code visible, not just the renders.
Self-check
QYou have ten solid projects. How many should you bring to a Cursor DE portfolio review and why?
Narrating decisions, not just outcomes
After this you can explain the WHY behind every interaction and visual choice.
Anyone can describe what they shipped. This review tests whether you can reconstruct the thinking that produced it - the constraints you were under and the options you killed.
The portfolio stage is design-engineer-specific for a reason. It probes taste and taste shows up not in the final pixels but in the decisions behind them. A polished result with no story reads as luck or as someone else's call. Narrate every piece as a decision, not a destination.
The five-beat frame for each piecestructure your walkthrough
- 1Problem. What was broken or missing, stated from the user's point of view in one sentence.
- 2Constraints. The real boundaries: deadline, browser support, an existing token system, a performance budget, a design you inherited.
- 3Options. Two or three approaches you actually weighed, with the tension between them.
- 4Decision. What you chose and the reasoning - aesthetic and technical together.
- 5Result. What shipped, what you measured if anything and the honest gap that remains.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Decision is the gate - it's where a Design Engineer earns the title by pairing taste with engineering.
The fourth beat is where Design Engineers earn the title. Pair the eye with the engineering: “I chose a spring over an ease-out because the panel can be interrupted mid-flight and a spring resolves gracefully from any velocity while a fixed easing snaps.” That single sentence shows both why it looks right and why it is built right.
Quantify the polish
Vague praise of your own work is worthless to a reviewer. Specifics are the proof. Compare these two ways of describing the same animation:
- Vague (reads as luck)
- “I made the transition smooth.”
- Specific (reads as craft)
- “I tuned the spring to ~0.7 damping so it settles without a visible bounce on a 120ms move.”
- Vague (reads as luck)
- “The spacing feels clean.”
- Specific (reads as craft)
- “I used a 4px base scale and optically nudged the icon 1px up because it sat heavy against the cap height.”
- Vague (reads as luck)
- “It performs well.”
- Specific (reads as craft)
- “I animated only transform and opacity to stay on the compositor and hold 60fps on a mid-tier laptop.”
- Vague (reads as luck)
- “The dark mode looks good.”
- Specific (reads as craft)
- “I raised the surface to a near-black, not pure black, so elevation shadows still read.”
| Vague (reads as luck) | Specific (reads as craft) |
|---|---|
| “I made the transition smooth.” | “I tuned the spring to ~0.7 damping so it settles without a visible bounce on a 120ms move.” |
| “The spacing feels clean.” | “I used a 4px base scale and optically nudged the icon 1px up because it sat heavy against the cap height.” |
| “It performs well.” | “I animated only transform and opacity to stay on the compositor and hold 60fps on a mid-tier laptop.” |
| “The dark mode looks good.” | “I raised the surface to a near-black, not pure black, so elevation shadows still read.” |
Numbers and named techniques turn a claim into evidence.
Show one true 90→100 story
Pick the most unglamorous detail you ever sweated and tell it proudly: the focus ring that had to survive keyboard and pointer entry, the empty state nobody asked for, the one-frame jank you chased through a profiler. The work most engineers skip is exactly the work Cursor is hiring this seat to do.
Truth-seeking is a named Cursor value and this stage tests it directly. Volunteer a trade-off you regret or something you would rebuild. Saying “I shipped this card stack with a CSS-only approach and it was the wrong call - it broke on focus order and I would reach for a headless primitive now” reads as confidence, not weakness. Pretending a piece is flawless reads as someone who cannot see their own bad ideas, which is the one thing they explicitly screen for.
“The constraint was that this panel could be dismissed while it was still animating in. An ease-out looked fine on the happy path but snapped if you interrupted it. I moved to a spring so it could reverse from any point in flight, tuned the damping until the reverse felt deliberate rather than springy and capped the duration so a fast user never waited on it.”
Takeaway. Tell every piece as problem → constraints → options → decision → result, quantify the polish and volunteer one trade-off you'd redo.
Self-check
Live craft critique
After this you can critique and improve UI on the spot.
Expect to be handed a UI - quite possibly a slice of Cursor's own - and asked what you'd change. This is taste under live pressure and a structure keeps you from rambling.
A loose “make it cleaner” answer is the failure mode here. It signals you react to surfaces rather than reason about them. Run a fixed pass instead, from the most consequential layer to the most cosmetic, so nothing important gets skipped and you never sound like you are guessing.
The critique ladderusability first, polish last
- Layer
- Usability
- What you're hunting for
- Can the user accomplish the task without confusion?
- Example specific fix
- “The primary action sits below the fold on a laptop; pin it to the panel footer.”
- Layer
- Hierarchy
- What you're hunting for
- Does the eye land where it should?
- Example specific fix
- “Two competing blues fight for attention; demote the secondary to a ghost button.”
- Layer
- Motion
- What you're hunting for
- Does movement clarify or distract?
- Example specific fix
- “The dropdown fades but doesn't move; add a 4px slide so it reads as emerging from the trigger.”
- Layer
- Polish
- What you're hunting for
- Spacing, alignment, typography, density.
- Example specific fix
- “Labels are baseline-misaligned with their inputs by ~2px; align to the text box, not the border.”
- Layer
- Accessibility
- What you're hunting for
- Keyboard, focus, contrast, ARIA.
- Example specific fix
- “Focus is invisible on dark surfaces; add a 2px ring that meets contrast against the panel.”
| Layer | What you're hunting for | Example specific fix |
|---|---|---|
| Usability | Can the user accomplish the task without confusion? | “The primary action sits below the fold on a laptop; pin it to the panel footer.” |
| Hierarchy | Does the eye land where it should? | “Two competing blues fight for attention; demote the secondary to a ghost button.” |
| Motion | Does movement clarify or distract? | “The dropdown fades but doesn't move; add a 4px slide so it reads as emerging from the trigger.” |
| Polish | Spacing, alignment, typography, density. | “Labels are baseline-misaligned with their inputs by ~2px; align to the text box, not the border.” |
| Accessibility | Keyboard, focus, contrast, ARIA. | “Focus is invisible on dark surfaces; add a 2px ring that meets contrast against the panel.” |
Walk top to bottom out loud; it shows method, not vibes.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Walk top to bottom out loud - most consequential first - so you reason about the UI instead of reacting to it.
Two rules keep each finding credible. Be specific enough that the team could open the file and make the change and propose the implementable fix rather than the aspiration. “Increase the gap between rows to 8px” beats “more breathing room.”
Respect the constraints you can't see
You are critiquing work real people shipped under pressure, possibly the people in the room. Lead with what's working before you cut and frame fixes as trade-offs rather than verdicts.
“This is wrong, the spacing is all over the place.”
Reads as someone who has never shipped under a deadline.
“The information density is strong here. If I owned it I'd unify the spacing to a 4px scale, though I'd want to know if the cramped rows were a deliberate density call first.”
Reads as a peer who respects the work and the unknowns.
The reviewer may push back or add context: “we actually had to support 14px because of a localization constraint.” The right move is to absorb it and revise on the spot - “that changes it; given that, I'd protect the line height instead and let the container grow.” Both halves matter. Have a real opinion and change it cleanly when the facts change. That is truth-seeking in miniature and it is exactly what the values round is also watching for.
Takeaway. Critique in a fixed order - usability → hierarchy → motion → polish → accessibility - with specific, shippable fixes and update your view when given new constraints.
Self-check
QDuring a live critique, which finding is strongest?
Presentation mechanics
After this you can deliver a tight, confident walkthrough.
Design Engineers show working things. A deck of screenshots quietly undercuts the one thing you're trying to prove - that this stuff is real and you built it.
The mechanics of the walkthrough are also a rehearsal for the 2-day trial's final presentation, where you stand up and show the team what you shipped. Treat this review as a dress run for that, because the format is nearly identical: what you built, the decisions behind it and what's next.
Run of showhow to spend the time
- 1Open with a 30-second map. Name your three pieces and what each proves so the reviewer can steer.
- 2Lead with the most impressive. Front-load your strongest interaction while attention is highest; don't save the best for a slot you might not reach.
- 3Demo live, narrate as you go. Click through the real thing, talking through the decision behind each beat rather than reading the screen.
- 4Pre-empt the obvious questions. Answer performance, accessibility and edge cases before they're asked.
- 5Leave room for questions. Time-box each piece so a third of the slot stays open for the conversation that actually reveals you.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The same arc as the 2-day trial's final presentation - treat this as the dress run.
Have the demos truly ready
A live demo that fails in the first minute spends your credibility before you've earned any. De-risk it like you'd de-risk a deploy.
- Run it locally and on a clean machine or browser the night before - no “it works on my setup” surprises.
- Have a hosted fallback URL in case the local build dies mid-session.
- Keep a short screen recording of the interaction as a last resort and say plainly that the live version is what you'd normally show.
Pre-empt the questions a DE always gets
- Performance
- “This animates transform/opacity only and holds 60fps on a mid-tier laptop.”
- Accessibility
- “It's keyboard-operable, focus is visible and the contrast clears AA on dark.”
- Edge cases
- “Here's the empty state, the long-content overflow and the interrupted-animation path.”
- Reuse
- “The component API takes a variant and a size; here's how a teammate would consume it.”
Volunteering these does two jobs at once. It answers the question and it proves you think about the unglamorous surfaces by default - the end-to-end ownership Cursor expects, where one person designs, builds, ships and supports the feature.
Do one full run on a screen recording and watch it back before the real thing. You will catch filler words, a piece that runs long and the spot where you bury the lede. One pass tightens the story more than re-reading your notes five times. Aim to cut the walkthrough to the point where every sentence either shows craft or sets up the next demo.
End each piece with a forward-looking line: “if I owned this for another week, I'd add reduced-motion support and virtualize the list past 200 rows.” It mirrors the trial's “what's next” beat, shows you see past the demo and signals the ownership instinct without you having to claim it.
Takeaway. Demo live (with a fallback), lead with your strongest piece, pre-empt the perf/a11y/edge-case questions and rehearse once on a recording.