Comprehensive Interview Preparation Guide: Junior UI Designer (FAANG Standard)

Direct answer
A critique session works when it has a repeatable structure (clear roles, a timeboxed agenda, an artifact everyone has seen in advance, and a required output) and explicit ground rules that separate feedback on the work from judgment of the person. Structure removes ambiguity about what is supposed to happen; the ground rules are what make people willing to say what they actually think.

Structured elaboration

Roles

• Presenter: owns the artifact, states the problem and the specific question they want answered (not "what do you think" but "does this navigation pattern confuse first-time users").
• Facilitator: keeps time, enforces the ground rules, and makes sure the session ends with decisions, not just opinions.
• Recorder: captures feedback as concrete items (issue, owner, priority) rather than a transcript of the conversation.
• Participants: at least one engineer for feasibility and one researcher or data owner when the discussion depends on evidence, plus two to four other reviewers.

Timeboxed agenda (40-60 minutes)

The range comes straight out of the table: every segment at its low end is a 40-minute tight version, every segment at its high end is a 60-minute full one. That matters when you are handed a fixed slot. In a 45-minute room I spend the five minutes above the floor on structured feedback rather than the walkthrough, because the walkthrough is the part that can be compressed by sharing the artifact in advance, and the feedback block is the only segment the session actually exists for. In a 30-minute room the honest move is to cut the number of questions asked, not to shave every segment proportionally, since a five-minute feedback block produces reactions rather than critique.

Artifact type scales with the question: low-fidelity sketches or flows when validating direction, an interactive prototype or annotated screens when the question is about interaction detail, a short research summary when the question is whether the evidence supports the direction at all.

Expected outcome: not "the room liked it." Every session closes with one of keep, change, or run an experiment, a prioritized list of action items with a named owner and a date, and, when the decision is uncertain, the metric that will tell you whether it worked. I log these in a shared tracker so follow-through is visible instead of implied.

Psychological safety, concretely: it is not "be nice." It means people feel safe enough to point out a real problem and safe enough to admit their own work has weaknesses, which produces both better decisions and more empathy, since the team is looking at the work through the user's eyes instead of defending their own choices. I build it with three mechanics: ground rules stated at the top of every session, most importantly "critique the work, not the person" ("I notice new users hesitate here" instead of "this is wrong") and "park anything outside today's question" so scope creep does not turn into a personal argument about unrelated choices; the presenter opening by naming their own known weak spots, which signals that flagging problems is expected rather than an attack; and the facilitator actively inviting quieter voices so the loudest opinion in the room does not become the default decision.

Worked example
For a weekly critique on a subscription checkout flow, the presenter opens with: "I'm testing whether removing the second confirmation step increases completion without users feeling rushed; give me feedback on the pacing, not the visual style." After the walkthrough, one reviewer observes that a security-conscious user might not notice their card was already saved. That becomes a logged action item ("add a visible saved-card confirmation, owner: presenter, due: next session"), not a live redesign debate.

Trade-offs and pitfalls
A short session with no artifact shared in advance turns into unfocused chatter with no output. Skipping the timebox lets the most senior or loudest person's opinion dominate, which is the opposite of the goal. Rotating the facilitator role spreads ownership and avoids one person controlling every decision, but it costs ramp-up time for whoever is new to the role. The most common failure is capturing feedback with no accountable owner and date: the room feels productive, nothing actually changes, and the next session loses credibility.

Overview (approach)
I frame this as a design problem: show how the UI communicates state, allows safe offline interaction, and surfaces retry/queue status so users stay confident. I prototype interactions for fast, slow, and offline networks, then validate with usability testing and analytics.

Prototyping and tooling

• High-fidelity prototypes in Figma plus interactive states (Variants/Prototype links).
• Micro-interactions and timeline testing in ProtoPie or Framer to simulate delayed responses, progress spinners, optimistic updates, and queued items.
• Developer-side mock APIs: MSW (Mock Service Worker, which intercepts the app's real network requests in the browser and returns fake responses) for web, or Mockoon/JSON Server as simpler alternatives to vary latency and HTTP errors.
• Network throttling via Chrome DevTools or Charles Proxy to emulate 3G, high latency, packet loss, and offline.
• Of this list, the two worth knowing well for an interview are MSW, since it intercepts requests the same way the real app will hit them, making it the most realistic web option, and Chrome DevTools throttling, since it is built into the browser with zero setup; Mockoon, JSON Server, and Charles Proxy are fine to name as examples but less critical to have hands-on depth with.

Design patterns to prototype

• Optimistic updates with a reversible UI (show a "saving..." pill and undo) for fast perceived performance.
• Queued actions list: a persistent UI drawer showing pending actions, retry/cancel buttons, and an ETA.
• Exponential backoff retry visuals (each retry waits longer than the last): a toast with a retry countdown and a manual "Retry now."
• Offline state: a clear banner, disabled inputs where necessary, and the ability to queue writes with a clear affordance (cloud icon plus queue count).
• Error messaging: concise, actionable copy; inline errors for field-level problems; global toasts for system errors.

Testing and validation

• Scripted usability tests: give tasks under simulated conditions (slow/offline) and observe task completion, confusion, and recovery.
• Capture metrics: time-to-complete, error rates, number of manual retries, abandonment. Use analytics events for queued actions, retry clicks, and dismissals.
• Qualitative capture: session recordings, moderated interviews, and a SUS (System Usability Scale, a standard 10-question survey producing a 0-100 usability score) or qualitative rating after each condition to gather emotional response to the degraded flows.

Hand-off

• Provide a designer's spec: states, copy variants, animations, accessibility notes, and the API contract for queued actions (status, id, error codes). Include edge cases (merge conflicts, failed dependencies) and recommended telemetry events for monitoring.

Direct answer

Five Whys is a chain of "why" questions that walks from an observed symptom to a plausible underlying cause. Used well on a metric like this, it turns "people cancel at two weeks" into a specific, testable hypothesis about what's missing in that window, rather than stopping at the first plausible-sounding answer.

Structured elaboration

• Each "why" should answer the previous statement directly, in one causal step, not jump levels or restate the symptom in different words.
• Five Whys produces a single causal chain, but real product problems usually have more than one cause. Treat the output as a hypothesis to confirm with data, not a verdict.
• Stop when you hit something the team can actually act on: a process, a design choice, a missing signal. Stopping at "users are impatient" isn't actionable; stopping at "onboarding doesn't get them to a specific moment of value" is.
• Anchor each "why" to an existing signal where possible (funnel data, support tickets, cancellation survey text) instead of pure speculation.

Worked example: subscription cancels around two weeks

1. Why do users cancel around two weeks in? Because that's roughly when the free-trial-to-paid charge posts, so it's the first moment they consciously re-evaluate the subscription.
2. Why does re-evaluating at that moment lead to canceling rather than continuing? Because by then they haven't yet done the thing the product is actually for, so there's nothing concrete to weigh against the charge.
3. Why haven't they done the core thing yet? Because the path from signup to that first meaningful use isn't sequenced. It's discoverable, but nothing in the product actively walks them there.
4. Why isn't it sequenced? Because onboarding was built to explain features, not to get one specific outcome achieved in the first session.
5. Why does onboarding optimize for feature explanation instead of a first outcome? Because it predates the current pricing model and was never revisited once the trial-to-paid moment became the point where users decide.

Plausible root cause: the two-week cancel spike lines up with the trial-to-paid charge, and users hit that decision point without having reached the product's core value yet, because onboarding teaches features rather than driving one outcome.

What to test to confirm it: this is a hypothesis until it's checked against data that already exists. Pull the cohort of users who canceled in the trial-to-paid window and check, from existing product analytics, whether they disproportionately had not completed the core activation event before canceling, compared against the completion rate for users who converted. If cancelers completed that event at a meaningfully lower rate, the hypothesis holds and the fix is an onboarding and activation problem. If completion rates look similar between the two groups, the chain above is wrong and the real driver is something else (price sensitivity, a specific broken feature, a competitor offer), which needs its own Five Whys starting from that data.

Trade-offs and pitfalls

• The biggest failure mode is stopping at the first answer that sounds right and happens to confirm what the team already believed. Force at least one alternate chain before committing to a root cause.
• Five Whys assumes one dominant cause. If the data check above shows activation completion isn't actually different between cancelers and converters, don't force the chain to still be true; that's a signal to start over from a different why.
• It's a synthesis tool for framing a hypothesis fast, not a substitute for confirming it. Shipping a fix based on the chain alone, without the data check, risks solving a plausible-sounding problem instead of the real one.

Direct answer

State it as: "Among users who signed up by email in the past 14 days, onboarding completion fell from 80% to 60% after the new onboarding flow shipped; we want completion back above 80% within [N] weeks, measured as sessions that reach the 'setup complete' event." That single sentence names the target user, the current state, the desired state, a timeframe, and the metric that will tell you when the problem is solved.

Structured elaboration

A well-formed problem statement carries five load-bearing parts, and a statement missing any one of them invites the wrong kind of solution:

1. Target user - not "users" in general, but the specific segment the data is about (email sign-ups in the last 14 days, not all users). Naming the wrong segment sends the team investigating a population that was never affected.
2. Current state - the measured baseline, with enough specificity to be re-derived by someone else (80% completion, this cohort, this date range).
3. Desired state - what "fixed" looks like, ideally the prior baseline unless there is a reason to target something else.
4. Timeframe - both the window the drop was observed over and the window you're giving yourself to fix it. Without a fix-by timeframe, "reduce this" never gets prioritized against other work.
5. Metric - the exact signal you'll watch, defined precisely enough that two people computing it independently get the same number.

Two things a problem statement should NOT do: it should not name a cause ("completion fell because the new flow is confusing") and it should not name a solution ("we need to simplify onboarding"). Both foreclose investigation before it starts. The statement's job is to make the gap undeniable and measurable, not to explain it.

Worked example

Given the scenario: baseline is 80%, current is 60%, a 20 percentage-point drop, among the email-signup cohort, in the 14 days since the new flow shipped. The statement: "Onboarding completion among email-signup users has fallen from 80% to 60% in the 14 days since the new onboarding flow launched; we want to recover to at least 80% within 3 weeks, measured as the share of that cohort reaching the account-setup-complete event within 24 hours of signup." Note what's absent: no claim about WHY it dropped (a new step added friction, a bug, a segment mix shift) and no proposed fix. Those come after this statement, once investigation starts.

The same five components (target user, current state, desired state, timeframe, metric) transfer directly whether the trigger is a product metric, a data-science churn model, or a machine-learning (ML) launch: an ML repeat-purchase-drop variant of this exact scenario needs the identical five parts, just with an ML-specific metric (a model's tracked outcome) standing in for the product metric.

Trade-offs and pitfalls

The most common failure is writing a statement that is really a solution in disguise ("we need to add a progress bar to onboarding"), which locks the team onto one hypothesis before anyone has checked whether it's the right one. The second most common failure is omitting the timeframe: a problem statement without a "by when" for the desired state reads as aspirational rather than actionable, and competes poorly against work that does have a deadline. A statement that is too broad ("improve onboarding") fails the same test as no statement at all: it can't be disproven, so nobody can ever confirm it's solved.

Executive brief — Prioritize accessibility despite short-term revenue concerns

Thesis (one line)
Designing to meet accessibility standards (WCAG 2.1 AA) is not just a moral or legal choice — it’s a product decision that reduces risk, expands market reach, and strengthens brand equity. Short-term revenue impacts can be mitigated; long-term value outweighs them.

User impact

• Improves usability for 1 in 4 adults with temporary, permanent, or situational disabilities (vision, motor, cognitive).
• Benefits all users: clearer information hierarchy, larger clickable targets, better color contrast, keyboard and voice navigation.
• Example: implementing accessible forms reduced abandonment by 18% in a prior product I designed.

Business risks if we don’t

• Legal exposure: class-action and ADA complaints carry high costs and injunctions.
• Market loss: excludes ~25% of potential customers and caretakers who influence purchases.
• Reputation damage: negative press and social amplification decreases lifetime value.

Mitigations to limit short-term revenue impact

• Phased approach: prioritize high-traffic conversion flows (checkout, onboarding) first.
• Parallel A/B tests: measure lift from accessibility changes on conversion and retention.
• Cost-efficient patterns: use design-system tokens, component-level accessibility fixes to scale.
• Cross-functional sprints with engineering to reduce rework and delivery cost.
• Short-term incentives: targeted promotions for newly accessible features to recoup revenue.

Long-term value

• Increases TAM and retention; accessible products show higher NPS and lower support costs.
• Speeds product development by creating robust, reusable components.
• Lowers legal and reputational risk; supports enterprise sales where accessibility is a procurement requirement.

Recommendation: approve prioritized accessibility roadmap focusing on conversion-critical paths, measure KPIs (conversion, support volume, NPS), and revisit revenue forecasts after initial rollout (8–12 weeks).

Direct answer

I shipped a change to a signup flow that looked correct in every test environment but broke for users on a specific combination of browser and network condition we hadn't covered, and it was a customer, not our monitoring, who found it first, mid-demo, which made the failure both technical and painfully visible. Working out why it failed meant separating the actual technical root cause from the process gap that let it ship at all, and the fix that stuck was the one that closed the process gap, not just the code.

What happened and how I investigated

The change passed our automated tests and looked fine in manual quality testing, but broke for a subset of users because of an interaction between a caching layer and a redirect that only showed up under a specific, uncommon network condition. It surfaced when a prospective customer hit it during a live demo, which told me something important on its own: our alerting wasn't watching for this failure mode at all, so if the customer hadn't hit it live, it could have persisted undetected. Rather than just fixing the immediate bug, I traced two separate things: the technical root cause, the caching and redirect interaction, and the process gap, which was that our test matrix didn't cover that network condition and our monitoring had no signal that would have caught it in production either.

What I said and to whom, while it was still broken

As soon as I confirmed the cause, I told my manager and the account team handling that customer directly, with the specific technical explanation and an honest estimate of the fix timeline, rather than a vague "we're looking into it." That let the account team manage the customer conversation with real information instead of a placeholder.

What changed as a result

The immediate fix addressed the caching and redirect bug. The change that outlived the incident was adding the specific network condition to our test matrix and adding a monitoring alert for that class of redirect failure, so the next similar bug would be caught by our own systems instead of by a customer mid-demo. I also flagged that our sign-off process treated "tests pass" as equivalent to "ready to ship" with no explicit check for untested conditions, which is a narrower and more honest description of what our tests actually covered.

Trade-offs and pitfalls

The pitfall is stopping at the technical fix and treating the incident as resolved, when the more durable failure was the process gap that let something with an untested condition ship in the first place. A failure caught by monitoring and one caught by a customer can share the identical root cause, but they are different signals about how much your detection is actually covering.

Direct answer

Expect a director managing three to five team leads or senior individual contributors directly, a total team of roughly 15 to 30 people split into several smaller pods (small, semi-autonomous sub-teams, each owning a specific area of the product) each with its own lead, and a mission written as a narrower slice of company strategy the director is accountable for, not the company's mission as a whole. Those two numbers are linked rather than independent guesses: a line manager's practical span is roughly five to eight direct reports, so three to four pods at that size is exactly what puts the total in the 15 to 30 range, and the director's own span sits at the low end of that same band because each of their reports carries a whole pod's worth of context rather than one person's.

Structured elaboration

• Typical roles and titles: Director, then three to five Engineering Managers or Staff/Senior individual contributors as pod leads, then each pod's own engineers (a mix of junior through senior), often with an embedded or partner product manager per pod and sometimes a shared designer or data scientist across pods.
• On-call ownership (on-call: a rotation where a specific person is responsible for responding to production issues outside normal hours): at a mid-stage company this is usually owned at the pod level, each pod is responsible for the on-call rotation for the systems it built, with the director accountable for the aggregate reliability picture across pods, not for running the rotation itself.
• Connecting mission to business objectives: a director's mission is usually one level of translation down from a company-level goal. A company objective like "grow enterprise revenue" becomes a team mission like "reduce enterprise onboarding time," something concrete enough that individual project work can be traced back to it directly.
• How to sanity-check your own numbers out loud: multiply, do not guess. Pods of five to eight, times the three to four pods one director can carry, gives 15 to 30 people. If the size you quote and the structure you describe do not multiply out to each other, an interviewer who does that arithmetic in their head has just found the seam in your answer.

Worked example

A Platform Engineering org at a roughly 600-person B2B software company, reporting to a Director of Platform Engineering. Composition: three pods, "Provisioning," "Observability," and "Cost and Capacity," of five to seven engineers each, so roughly 18 engineers plus the three pod leads plus the director, about 22 people in total, which lands in the middle of the 15 to 30 range above. Each pod runs its own on-call rotation, with the director reviewing an aggregate reliability report across pods monthly. Mission: the company's stated goal is to support fast customer growth without proportional infrastructure cost growth, which becomes the Platform org's mission of cutting provisioning time per new customer environment while holding infra cost per customer roughly flat, a line that's specific enough you could plausibly hear it stated in an actual interview.

Trade-offs and pitfalls

The most common error is assuming a flat structure, everyone reporting straight to the director. Once one person's direct reports pass the top of that five-to-eight span, roughly eight to ten people, it stops scaling and a middle layer of leads appears; leaving that layer out of your answer reads as inexperienced. The second most common error is quoting a headcount range and a pod structure that quietly contradict each other, which is easy to do because each half sounds reasonable on its own. It's also worth not just restating the org chart on its own, connecting the composition back to the mission is the part an interviewer is actually listening for.

Direct answer

A promise made in a sales conversation isn't automatically a commitment the roadmap has to honor, but it also isn't something to dismiss by pointing at process. The job is to find out quickly how big the ask actually is, then either fold it into already-planned work, offer something narrower that satisfies the intent, or explain clearly why it can't happen and what happens instead, rather than letting 'the process says no' be the whole answer.

Structured elaboration

1. Get the real scope fast

Find out exactly what was promised and how technically involved it is. A quick conversation with sales and a fast technical read often turns 'they promised a change' into either 'this is a config toggle' or 'this touches several systems,' and those two cases should be handled completely differently.

2. Route by size, honestly

Small, low-risk asks can go through a lightweight fast-track with the right owner's sign-off. Larger asks go through normal prioritization, with the customer commitment logged as one input among others, not an automatic override of everything else on the roadmap.

3. The urgent-and-risky variant: when the fix means a breaking contract change

Sometimes the promise is a customer-facing bug fix, and fixing it correctly requires a breaking API contract change that frontend and mobile integrations depend on. Other systems, like the mobile app, expect the API to hand back data in an exact, agreed shape (that agreed shape is the contract); changing that shape without warning breaks them, because their code is written to read the old shape and has no way to interpret the new one. Here the stakes shift: this isn't a process-bypass question anymore, it's a technical breakage risk question. The right move is to check who else depends on the contract, see whether the fix can ship as an additive, non-breaking change instead (meaning something new is added without touching what already works, so nothing that currently depends on the contract is disturbed), and if a break is genuinely unavoidable, version it and coordinate a migration window with every dependent integration before flipping it, rather than shipping it hot for one customer's benefit while breaking others silently.

4. The reverse-direction variant: when the roadmap deprioritizes something already promised

Sometimes there's no new promise to accommodate at all; instead, a roadmap shift deprioritizes a feature that was already promised to enterprise customers. Here the job isn't to accommodate a new ad hoc promise, it's to build a walk-back communication plan: get ahead of it with the account team before the customer notices the date has slipped, be specific about the new timeline or an alternative that addresses the underlying need, and give the customer-facing team language they can actually use, rather than leaving them to explain a surprise on their own.

5. Close the loop both ways

Tell the customer-facing team what was decided and why. Tell the team that owns the process whether the promise revealed a real gap worth fixing, such as a fast-track path that didn't exist yet, or a case where sales needs earlier visibility into technical constraints before a call.

Worked example

A rep promises a customer a small label change during a renewal call. A quick check shows it's a low-risk config change, so it ships that week through the lightweight path with the account owner's sign-off, and the exception gets logged. Contrast that with a case where a rep promises a fix to a data-export bug, and fixing it correctly means changing the shape of a public API response that a mobile app and two partner integrations depend on. Instead of pushing a fast fix, the team ships an additive new field alongside the old one, migrates the highest-risk integration first behind a feature flag (a toggle that turns the new behavior on for one group at a time, so it can be tested on a small slice before everyone gets it), and only removes the old field once every consumer has moved over, later than the customer originally hoped, but without breaking anyone else in the meantime. Separately, when a previously promised enterprise feature gets bumped by a roadmap shift, the team gives the account manager a specific revised date and a smaller interim capability to offer, so the customer hears a plan instead of discovering the slip on their own.

Trade-offs and pitfalls

• Using process purely as a shield, with no real attempt to find a legitimate fast path, damages trust with both sales and the customer for no real safety gain.
• Letting one ad hoc exception become the unwritten template invites every future promise to bypass prioritization; log exceptions and periodically check whether the process itself needs a documented fast lane instead.
• Treating a breaking-change fix as a normal prioritization question, rather than a dependency-risk question, is how a favor to one customer quietly breaks several others.
• Not looping back to ask why sales made a promise outside the guardrails in the first place means the same collision happens again on the next renewal call.

An 8-point grid is a discipline where every spacing and sizing value, padding, margins, element widths and heights, is chosen as a multiple of 8 pixels (with an occasional 4px half-step allowed for small details), so every measurement in the interface lands on a shared, predictable grid instead of arbitrary pixel values.

Why 8 specifically

Eight divides evenly by 2 many times over, which means it scales cleanly across the pixel densities modern screens use (1x, 2x, 3x) without producing blurry, sub-pixel values, and it divides evenly into common icon and touch-target sizes (16, 24, 32, 40), so icons and spacing naturally line up with each other.

Applying it across breakpoints

The grid itself doesn't change between mobile, tablet, and desktop, what changes is which values on that shared 8-based scale get used where. Mobile layouts lean on the smaller steps (8, 16, 24) to conserve limited screen space, while desktop layouts lean on the larger steps (32, 48, 64) since there's more room to give elements breathing space. A button's internal padding might stay fixed at 16px across all three, since a touch target doesn't need to grow with screen size, while the gap between major sections might go from 24px on mobile to 48px on desktop.

A worked example

A button at 40px tall (8 times 5) with 16px horizontal padding (8 times 2); a card with 24px internal padding (8 times 3) and a 16px gap between cards in a grid.

Elements that don't cleanly fit the grid

The important move here is to separate two things that get lumped together, because they have different rules.

Optical nudges are not spacing values. An icon that needs to sit 2px off-center to look optically balanced is correcting a shape's own visual center against its bounding box, not choosing a gap between two elements. That correction can be 1px or 2px or whatever the eye actually needs, and it does not belong on the spacing scale at all, because nobody else ever has to pick that number: it is baked into the icon or the component once and never re-decided. Optical alignment, what actually looks centered or balanced to the eye, is allowed to override strict mathematical alignment when the two disagree, since the grid exists to serve visual consistency, not the other way around. Trying to force a 2px nudge onto a 4px half-step would double the correction and overshoot in the same direction, which is worse than the original problem.

Spacing and sizing values do have to come from the scale, and the 4px half-step is part of that scale. This is where the modal case actually lives, and it is worth being precise about it, because "24px is cramped, 32px is slightly too loose" is a diagnosis whose midpoint is 28px, and 28 is 4 times 7, a legitimate 4px half-step, not a rogue number. So the honest options are:

• Accept 32 and change the content instead. If 32px only feels loose because the modal's own type or line-height is a bit tight inside it, the padding was never the real problem. This is usually the right first check, and it keeps the scale at its coarsest, most memorable form.
• Promote 28 to a named step. If a genuine, recurring class of component needs the value between 24 and 32, add 28 as a documented half-step with a stated purpose ("modal and dialog inner padding") and use it consistently everywhere that class appears. A 4px half-step that is written down and reused is part of the system.

What is actually forbidden is neither 28 nor 32; it is an undocumented one-off. Typing 28px into a single modal because it looked better that afternoon, with nothing recording the decision, is the failure mode, because the next person reads it as drift and either "corrects" it to 24 or copies it somewhere it doesn't belong. The test is not "is this number a multiple of 8", it is "can someone else reproduce this choice from a written rule". A documented 28px step passes that test; an unexplained 28px does not, and neither does an unexplained 32px chosen because it was nearer to the multiple.

The pitfall to avoid

The system erodes from the middle, not the edges. Nobody ships a 37px padding; they ship a plausible-looking 28 or 20 with no note attached, and six months later the scale has quietly become "any multiple of 4, roughly", at which point it has stopped constraining anything. Keeping the exception list short and written down is what preserves the value of the grid, far more than refusing half-steps on principle.

Quick answer

Build the pitch in three beats and keep it under two minutes: (1) your foundation, what you studied and where your interest formed, (2) your proof, one or two internships or personal projects described as decisions you made rather than tools you touched, and (3) your direction, what you want to grow into next, tied to this role. Skip the full chronology of every class and club.

How to build it

The three-beat skeleton

1. Foundation (10-15 seconds): degree, concentration or focus area, and the one-sentence version of why it interests you.
2. Proof (60-90 seconds): pick one internship and one project, or two internships if you have them. For each, say the problem, what you actually did, and what you decided or learned, not a list of tools.
3. Direction (10-15 seconds): the specific thing you want to build skill in next, tied to something you know about this role or team.

Filling the gap when internships are short or few

A personal project can carry as much weight as an internship if you describe it the same way: a real problem, a choice made under a constraint (time, data, tooling), and what changed because of it. Treat "I built X" as an incomplete sentence; the interview-relevant version is "I built X because Y, and I picked approach A over B for reason Z."

What to leave out

Don't list every course, every tool on your resume, or every project you've touched. Pick the one or two artifacts you can go two levels deeper on if asked, and let the rest sit in your resume for the interviewer to raise if they want it.

Worked example

Skeleton, swap in your own focus area: "I studied [your focus area] and got interested in it through a course project where [one-sentence hook]. During an internship at [type of employer, e.g. a small logistics startup] I owned [a specific task], which meant choosing between [option A] and [option B]. On the side, I built [a personal project] to teach myself [a skill], and turned a manual step that used to take a few hours into something that runs in a couple of minutes. Going forward I want to get better at [a skill relevant to the role], which is part of why this role caught my attention."

Filled illustration: "I studied information systems and got interested in it through a course project where I had to untangle a spreadsheet of messy survey responses into something the class could actually present. During an internship at a small logistics startup I owned cleaning and organizing the weekly shipment-tracking data, which meant choosing between writing a one-off script to fix that week's problem or building something reusable the team could run themselves; I went with the reusable version. On the side, I built a small scheduling tool to teach myself basic scripting, and turned a manual step that used to take a few hours into something that runs in a couple of minutes. Going forward I want to get better at working with larger, messier datasets, which is part of why this role caught my attention."

Trade-offs and pitfalls

Reciting the resume top to bottom instead of picking two strong artifacts is the most common failure at this level; it turns a pitch into a list. A close second is describing a class project as if it were a production system without naming its real scope (how big or small it actually was, and how much responsibility it carried); a semester project with no real users is fine to mention, just say so. Leaving out the direction beat makes a candidate sound passive rather than curious. Going past two minutes because every project felt worth including is a length problem, not a content problem: cut, don't rush.