UX Designer (Junior Level) Interview Preparation Guide - FAANG Standards

Direct answer

Treat the time limit as a constraint on the answer itself: pick one project you can defend under open questioning, script a tight narrative arc (context, problem, key decisions, outcome) that fits the time, and spend at least as much prep time anticipating the panel's likely challenges as polishing the walkthrough itself.

How to plan it

• Pick the project by defensibility, not impressiveness: choose the one where you can answer "why," not just "what," for every major decision, because open Q&A after a timed presentation exists specifically to test that.
• Script to the clock: roughly 20% context and problem, 50% key decisions and trade-offs, 30% outcome and what you'd change, then rehearse against a timer. Cutting content is easier before the room than mid-sentence in it.
• Prepare a "resume-on-demand" structure: have 2 to 3 artifacts (a prototype, a chart, a metric snapshot) ready to pull up instantly if a question calls for evidence, rather than describing them from memory.
• Anticipate the panel's default questions: "why this approach and not an alternative" and "how do you know it worked" come up in almost every panel, have both answers ready before you start.
• The same shape holds whether the format is a live prototype walkthrough (design loops) or a 5-slide project summary (data-science loops): fixed time, one artifact, then open technical questioning.

Worked example (skeleton)

A 5-minute slot on a project where I owned a feature end-to-end. Script: 1 minute on the problem and constraint, 2.5 minutes on the two approaches I considered and why I picked one, 1.5 minutes on the result and what I'd change with more time. Result stated honestly: a usability test with 11 participants showed task completion move from 7 out of 11 to 10 out of 11 between the first and revised prototype, a count I can point to directly rather than a rounded percentage. I keep the clickable prototype and the raw test notes open in a second tab, so if the panel asks to see the failure case, I'm one click away instead of describing it verbally.

Trade-offs and pitfalls

• Over-preparing the walkthrough and under-preparing for questions is the most common failure, panels remember how you handled pushback more than how polished the script was.
• Picking the most visually impressive project instead of the one you can defend three questions deep leaves you exposed exactly when it matters most.
• Running over time because you tried to cover too much ground; a shorter, sharper story leaves more of the slot for what's actually being evaluated, live technical reasoning.

Direct Answer

Structure it with real STAR, but let the Result honestly show the negative outcome instead of quietly pivoting into a win, own the mistake without blaming circumstances or other people, and close with a genuine Reflection on what you learned or changed. The test here isn't whether you can recover cleanly, it's whether you can sit with an actual failure and show what you took from it.

How to Keep It an Honest Failure

• Pick a real mistake with a real cost: something that actually went wrong because of a decision or action of yours, not a "failure" that's secretly a disguised strength, like framing overwork as a shortcoming.
• State the Result as it actually happened: if the project was delayed, say it was delayed; if you shipped a bug, say what it broke. Resist the urge to soften the ending or immediately follow it with a recovery that erases the failure.
• Own it without deflecting: use "I" for the decision that went wrong, even when other factors contributed. "I underestimated how long the migration would take" lands better than "the timeline was unrealistic," even if both are partly true.
• Close with a genuine Reflection: name a specific behavior you changed afterward, not a vague sentiment. The more concrete the change, a new step in your process, a habit you built, a question you now ask upfront, the more it reads as a real lesson rather than an interview answer.

Worked Example

"I was leading a small migration and estimated it would take two weeks based on a similar project I'd done before. I didn't account for a set of legacy dependencies that turned out to be much harder to untangle, and the migration ended up taking five weeks, which pushed back a launch two other teams were waiting on. I should have spent a day auditing dependencies before committing to the estimate instead of pattern-matching to the last project. Since then, I build a short dependency-mapping step into any estimate I give for infrastructure work, and it's caught two similar surprises before they became commitments I couldn't hit."

Trade-offs and Pitfalls

• The most common failure mode is choosing a story that's too safe, something with no real stakes, which reads as evasive since the interviewer is specifically asking to see how you handle a genuine setback.
• A close second is ending on the failure without a Reflection, which leaves the story feeling unresolved rather than honest; the Reflection is what turns admitting a failure into a demonstrated capability.
• Blaming other people or circumstances, even truthfully, tends to undercut the story more than owning a mistake with shared causes; interviewers are listening for accountability, not a fully accurate root-cause analysis.

Direct Answer

Preparing for a customer architecture Q&A on data residency, backup restoration time, and disaster recovery means treating each topic as its own mini-pitch: one rehearsed sentence of concrete evidence you can say live without notes, backed by a document you can hand over afterward for anyone who wants to verify it in writing. The live answer earns trust in the room; the artifact earns trust with the customer's own compliance and security teams who were not in the room.

Structured Elaboration

For each of the three likely topics, prepare a single evidence sentence built the same way: name the specific mechanism, then the specific number or fact that proves it, never a vague assurance.

• Data residency: "Customer data for this deployment is stored and processed exclusively in the region you select at setup, and that region assignment is enforced at the infrastructure level, not just in configuration."
• Backup restoration time: "Backups run on a defined schedule and our tested restoration time for a full environment is within our stated recovery time objective, which we validate on a recurring cadence, not just at launch."
• Disaster recovery: "We maintain a documented failover plan to a separate availability zone, and it's exercised on a regular schedule rather than left untested until an actual incident forces it."

Each sentence follows the same shape: mechanism, then proof that the mechanism is actually verified, not merely designed. That second half is what separates a reassuring-sounding claim from real evidence, and it is what a technical customer is actually listening for.

Two supporting artifacts to attach after the meeting:

1. A data residency and compliance summary naming the specific regions supported, the certifications held, and how region enforcement works technically.
2. A disaster recovery and backup runbook summary naming the recovery time objective (RTO: how long a full restoration is expected to take) and recovery point objective (RPO: the maximum data loss allowed, measured in time, for example at most 15 minutes), the last tested failover date, and the escalation path during an actual incident.

Together these two documents cover all three live topics: the first answers data residency, the second answers both backup restoration time and disaster recovery, since they are typically governed by the same runbook.

Worked Example

In the actual Q&A: the customer asks, "How do we know our data never leaves the region we picked?" You give the rehearsed data residency sentence above, then add: "I'll send over our residency and compliance summary right after this, it has the exact certifications and enforcement mechanism in writing for your security team to review." That single follow-up line converts a live answer into a paper trail the customer's own compliance function can independently verify, which matters more to their sign-off than anything said out loud.

Trade-offs and Pitfalls

Answering with reassurance instead of a specific mechanism ("don't worry, we take security very seriously") is the most common failure and the fastest way to lose a technical customer's confidence, since it gives them nothing to verify. Overloading the live answer with the full contents of the artifact is the opposite failure: it turns a 20-second confident answer into a five-minute technical tangent that the room did not ask for. The rehearsed sentence exists precisely to prevent both: concrete enough to be real evidence, short enough to stay live, with the depth living in the artifact instead.

Goal and scope: rapidly validate whether explainability and user controls increase trust and perceived utility before committing engineering effort. Prototype objectives: (1) let users ask "Why this?" and adjust preferences, (2) show privacy controls and their effect on recommendations, (3) measure trust and acceptance.

Mock data and model outputs:

• Items: {id, title, category, score, top_features=[feature:weight], provenance: "collab_filtering/v1"}
• Example record: {id: 123, title: "Running Shoes", score: 0.87, top_features: ["previous purchase (+0.4)", "bought-by-similar-users (+0.3)", "search: 'trail' (+0.17)"], provenance: "hybrid-v0.3"}

Prototype types:

1. Clickable high-fidelity UI (Figma / HTML) with three panels:
   • Card: item, short rationale ("Because you viewed X; 87% match")
   • "Why this?" modal: shows top_features with a simple visual bar, a counterfactual toggle ("If I hide purchase history, show new recommendations"), a provenance badge and confidence score.
   • Privacy settings slide-in: toggle data sources (purchase history, browsing, social graph); shows the immediate simulated effect (score deltas and alternative items).

Worked narrative: what one user actually experiences
Sam sees the Running Shoes card in their feed with the short rationale visible. Curious, Sam taps "Why this?" and the modal opens, showing three bars: previous purchase contributes the most, followed by other shoppers with similar taste, followed by an old search for "trail." Sam flips the counterfactual toggle to hide purchase history, and the list instantly re-ranks in front of them, leaning more on the "bought-by-similar-users" signal instead. That instant, visible cause-and-effect is what builds or breaks trust, not the raw feature weights themselves; Sam either comes away trusting the recommendation more because they could see and adjust why it was there, or opens the privacy slide-in to actually turn off purchase history and see the recommendations change for real.

UX patterns and interactions:

• Progressive disclosure: short rationale on the card, deeper explainability in the modal.
• Counterfactual sliders: change the weight of a feature and re-rank the simulated list.
• Feedback actions: "Not relevant," "Prefer more like this," "Less like this."
• Trust badges and glossary links: human-readable definitions (what "confidence 0.87" means).

Validation plan and experiments:

• Moderated usability sessions (10-15 target users): task-based (discover, ask why, change privacy).
• A/B prototype test (N=200): baseline recommendations vs the prototype with explainability and controls.

Metrics for trust and utility:

• Quantitative:
  • Acceptance rate (click-through on recommended items).
  • Change in engagement after control use (CTR, click-through rate, meaning the percentage of shown items someone actually clicks; plus conversion).
  • Control adoption rate (fraction of users who change settings).
  • Reduction in "I don't trust this" responses (survey).
  • Post-task System Trust Score (a Likert-scale rating, a numbered agree/disagree scale, collected right after the task).
  • Time-to-decision (lower is clearer).
• Qualitative:
  • Explainability clarity (7-point scale).
  • Behavioral intent (willingness to share data).
  • Thematic feedback (confusion points, desired controls).

Stakeholder artifacts:

• Prototype demo and interaction script.
• Mock dataset and API contract (fields, semantics).
• Success criteria: greater than 10% lift in acceptance or a +1 point trust score; at least 20% of users willing to use the controls.
• Engineering handoff: prioritized minimal APIs (getRecommendations with provenance and top_features; applyPrivacyMask).

Trade-offs and risk mitigation:

• Avoid exposing raw model internals; translate weights into human terms, as in Sam's example above.
• Use simulated re-ranking for immediate feedback to avoid backend cost.
• Privacy-first defaults; record consent flows during the prototype.

This approach lets product, design, and engineering validate that explainability and controls actually change behavior and trust before full implementation, and yields concrete metrics and API requirements for the next phase.

Direct answer. Embedding accessibility into how a company builds product, rather than layering it on as a pre-release check, means changing the artifacts teams already use: story templates, definition-of-done, design-review checklists, and CI gates, so accessibility is enforced by the existing workflow rather than by a separate, easily-skipped review step.

Definition-of-done and story templates. Add "meets AA acceptance criteria" as a literal checklist item on every user-facing story template, alongside functional acceptance criteria, so a story genuinely cannot be marked done without it being considered, not appended as an afterthought ticket filed after the feature ships.

Design reviews and developer handoff. Design review includes contrast, focus-indicator, and non-color-redundancy checks as standard agenda items, the same way a design review already checks responsive breakpoints; handoff artifacts (Figma specs, tickets) include the specific accessibility acceptance criteria for that component (expected ARIA roles, keyboard behavior) so engineering doesn't have to reverse-engineer intent.

Accessibility champions. A trained champion embedded in each product team (not a single central team reviewing everything, which doesn't scale and creates a bottleneck) owns local review and is the first escalation point before a central accessibility team gets involved, keeping expertise close to where decisions actually get made.

CI gating and hiring/training. Automated CI checks catch structural regressions before merge; role-specific training equips engineers and designers to self-catch issues before that gate, and ongoing hiring brings in deeper expertise for what training alone can't cover.

Worked example: an agile team currently treating accessibility as a post-release checkbox. The concrete first change is adding the definition-of-done checklist item and a lightweight "accessibility acceptance criteria" field to the story template used by that specific team's next sprint planning session, not a company-wide rollout on day one; prove the pattern works for one team, then propagate it, since a mandate imposed without a working example tends to be treated as bureaucracy rather than adopted in practice.

Trade-offs and pitfalls. A common half-measure is adding the definition-of-done item without any enforcement mechanism behind it (no CI gate, no review checklist), which produces the appearance of a process change with none of the actual behavior change; the artifacts need teeth, usually the CI gate, or they get silently ignored under deadline pressure.

Overview (goal)
Design a metadata schema and taxonomy that supports precise recommendations and advanced search while aligning with UX needs: discoverability, predictable navigation, and minimal cognitive load for content creators.

Types of metadata

• Categories (broad, multi-level): product, help, tutorial. Used for navigation and faceted search.
• Tags (flat, user-facing): micro-topics surfaced in UI as chips.
• Entities: canonical people/brands/APIs stored with IDs for entity-driven recommendations.
• Author & role: contributor metadata for credibility filters.
• Intent: task vs. research vs. problem-solve (enum) to match goal-oriented journeys.
• Reading level & format: beginner/intermediate/expert; article, video, checklist. For personalization.

Modeling relationships

• Hierarchies: tree for categories (parent/child) with inheritance of policy.
• Synonym groups & redirects: map equivalent tags to canonical terms; maintain alias list.
• Related content graph: weighted edges, a stronger link between two pieces of content the more often they're read together, cited together, or share an entity (co-read, cite, entity overlap), for recommendations.

Concrete example
An article titled "Debugging Slow SQL Joins" gets tagged: category = Engineering > Databases, tags = ["SQL", "performance", "joins"], entity = "PostgreSQL" (canonical ID postgresql-001), author = J. Rivera (Senior Engineer), intent = problem-solve, reading level = intermediate. Because it shares the PostgreSQL entity and is frequently read alongside "Indexing Strategies for Postgres," the two articles get a weighted edge between them, so a reader finishing one sees the other recommended.

Operationalization / capture

• Integrate metadata UI into CMS: required fields with smart defaults, autocomplete from controlled vocabularies, entity-picker with validation.
• Guided metadata: creators answer intent and audience questions; system suggests tags via NLP (natural-language processing, software that reads the draft text and suggests likely tags) + manual confirm.
• Validation rules: schema enforcement, tag limits, conflict warnings.
• Training & governance: onboarding, style guide, change log, metadata steward role; periodic audits and analytics on tag usage and search performance.

UX considerations

• Minimal friction: inline help, examples, presets.
• Transparency: preview how metadata affects findability/recommendations.
• Feedback loop: surface search/recommendation metrics to creators to refine tagging.

Situation: On one project, engineering and design were operating in separate lanes, which caused late feedback and rework.

Task: I needed to rebuild trust and unblock delivery without turning the problem into a blame conversation.

Action: I set up joint working sessions where both teams reviewed the same problem statement and success criteria. I also introduced a shared definition of done so we were clear about what “ready” meant before handoff. To build trust, I made sure both sides had equal airtime, captured decisions in writing, and followed through on small commitments quickly. After that, I kept the collaboration healthy with regular check-ins, shared demos, and a single place to track open questions.

Result: The teams started catching issues earlier, handoffs became smoother, and there was less tension around ownership. The biggest lesson was that silos break down faster when people share context and make small reliable commitments over time.

Direct answer

Treat this as a structured build, not a straight redraw: set up the file's page skeleton first, extract every repeated pattern, the progress bar, the card lists, the CTA (call-to-action, the primary button prompting the user's next step) variations, into reusable components and variants before building any of the six actual screens, assemble the screens from those pieces, wire a prototype for testing, and document naming and versioning so collaborators can follow the work as it evolves.

Structured elaboration

Pages to create: "00 Cover" (a brief describing the flow and its status), "01 Wireframe reference" (the hand-drawn sketches brought in for traceability, so reviewers can compare final screens back against the original intent), "02 Components" (extracted reusable pieces), "03 Onboarding flow" (the six final screens in sequence), "04 Prototype" (a copy wired for testing, kept separate so click-through hotspots don't clutter the production screens), "05 Archive."

Identifying and extracting reusable components: read through all six steps before building any of them and list what recurs. In this flow that's the progress bar (present on all six, with a different step highlighted each time), the card lists (recurring wherever the flow presents selectable options), and the CTA variations (a primary "Continue" versus a secondary "Skip" versus a disabled state before a required field is filled). Each becomes one real component with variant properties instead of six independently drawn copies: a progress-bar component with a step property (1 through 6), a card component with a selected/unselected property, and a CTA button with state (default, disabled) and type (primary, secondary) properties.

Auto Layout decisions: the progress bar itself is built with Auto Layout (Figma's layout system where a frame automatically resizes, spaces, and aligns its children as content changes, instead of every element being positioned by hand) so its segments space evenly regardless of step count; each card in a list is its own Auto Layout frame so its height adapts to variable text length instead of clipping; the CTA area at the bottom of each screen uses Auto Layout with alignment set to pin the button to the bottom edge consistently across all six screens, even when the content above it varies in length.

Assembling the six screens: each screen frame pulls the shared components as instances (the progress bar set to that step's value, whichever card or CTA state matches that step), so a later change to a base component, tightening the CTA button's corner radius, for example, propagates to all six screens automatically instead of requiring six manual edits.

Prototype plan for testing: wire the six frames in sequence, a "Continue" hotspot advancing forward and a "Back" or "Skip" path where relevant, and include the states that matter for the study, such as an error state if a step requires a note about a missing field. Keep the prototype in its own page or file copy so temporary interactions added just for the test session don't end up shipping. Plan the test around a small number of specific tasks (complete onboarding as a first-time user, back out and resume from a middle step) rather than open-ended exploration, so results are comparable across participants.

Naming and versioning: name the six screens by step and purpose ("01 Welcome," "02 Permissions," through "06 Confirmation") rather than by number alone; name components using a component/property/value convention (progress-bar/step, card/selected, cta/primary/disabled); version the flow with a named save point right before a testing round ("v1 for usability test, [date]"), so the exact version participants actually saw can always be recovered even after the working file has moved on.

Worked example

Steps 1 and 3 both use the card component to present two choices with different copy; because the card is a real component with a variant property rather than a redrawn shape each time, updating its corner radius once on the base component updates it everywhere it's used across all six screens. The progress-bar instance on step 3 is the same base component as step 1, with only its step property changed from 1 to 3, so its Auto Layout spacing never has to be manually recreated. In the prototype, step 1's primary CTA links to step 2, a back arrow links backward, and a disabled-state CTA on a later step becomes enabled only once the participant fills a required field, letting the moderator actually observe whether people notice why the button isn't responding.

Trade-offs and pitfalls

Redrawing each of the six screens by eye before extracting the shared pieces feels faster on day one, since the wireframes already show what each screen looks like, but it creates six independently diverging copies of the same progress bar and card, meaning any later change needs six edits instead of one; extract first even though it feels slower. Letting states or hotspots added only for the usability test creep into the production onboarding-flow page blurs the split between disposable testing artifacts and shippable work, so keep that boundary explicit. Skipping the versioned save point before a test round means an in-flight edit can silently change what a participant actually saw, undermining any attempt to explain a confusing result afterward.

Direct answer

I'd treat apparent contradiction as a segmentation signal first, not noise to average away. Most quotes that seem to conflict resolve once you check whether they're actually coming from different user segments or different contexts, rather than genuinely opposed opinions from the same kind of user in the same situation.

Structured elaboration

Coding evidence. Build a codebook with explicit, shared definitions, and code with at least two people so individual bias doesn't drive the categorization. Tag every quote with the participant's segment (device, tenure, role) and session context, not just its content, because the segment tag is what turns "contradiction" into "explanation" later.

Weighting evidence. Coding tells you what each piece of evidence SAYS; weighting decides how much it counts, and skipping it is how a synthesis ends up ruled by whoever was most quotable. Weight each piece on four things, recorded as a column next to the code, not held in someone's head:

• Directness. Observed behaviour outranks self-report, and self-report outranks recalled report. Watching someone fail a task is stronger evidence than them telling you afterwards that it was confusing, which is stronger than them remembering last month.
• Independence. Two participants recruited from the same customer, the same forum thread, or the same support escalation are close to one data point, not two. Count independent SOURCES, not raw quote volume, or a single loud account gets counted five times.
• Task relevance. A comment made while doing the real task in scope beats an unprompted aside about a different part of the product, even when the aside is more vivid.
• Corroboration across method. A code that also moves a telemetry number weighs more than one that exists only in the transcripts, because the two methods have different blind spots.
  In practice that means a coded theme carries a weight, not just a count, and the write-up reports both, "12 quotes from 9 independent accounts, 7 of them observed rather than reported, corroborated by telemetry," so a reader can see why one theme outranks another instead of assuming the bigger tally wins. The one weighting input to refuse is seniority of the speaker: how senior a participant is inside their own company says nothing about how representative their experience of the interface is.

Resolving contradictions. Split apparent conflicts into three buckets: segment-driven (different users, both correct for their own segment), context-driven (the same user, describing a different task or moment), and genuine noise (a one-off, small-sample artifact). Then re-cut the telemetry PER SEGMENT rather than pooled; high variance in a pooled number is itself often a clue that two distinct groups are being averaged together.

Presenting uncertainty. Attach a confidence label (High, Medium, Low) to each finding based on how many independent sources agree and whether it holds up once segmented, and say explicitly what's still unknown rather than smoothing everything into a single confident story.

Deciding on bounded follow-up experiments. Prioritize by impact times confidence times feasibility, and pick a small, named set (two to three), each designed to resolve one specific open contradiction rather than a general "let's research more."

Worked example

A synthesis document has 24 participant quotes about a new filter interface: 9 call it confusing, 8 call it a clear improvement, 7 are neutral. Pooled telemetry shows filter usage ranging from 12% to 61% across sessions, high variance that reads, at first glance, as noisy and hard to trust.

Segmenting by device changes the picture entirely. Of 14 desktop participants, average filter usage is 54%; of 10 mobile participants, it's 18%. Re-checking the quotes against device: 8 of the 9 "confusing" quotes came from mobile participants, and 7 of the 8 "improvement" quotes came from desktop participants. This isn't a genuine contradiction, it's two separate, true stories: the redesign works on desktop and regresses on mobile, most likely a tap-target or visibility problem on small screens.

The weights, not just the counts, are what make the mobile finding the stronger of the two. The 8 mobile "confusing" quotes come from 8 separately recruited participants rather than several people at one account, 6 of the 8 are tied to an observed failure in the session rather than a general opinion, and the theme is corroborated by an independent method, the 18% usage figure from telemetry. The desktop "improvement" theme has 7 quotes but they are almost all self-reported preference at the end of the session rather than observed behaviour, and its telemetry corroboration is the same number that a novelty effect would also produce. Same order of quote count, materially different weight, and that gap is exactly what the confidence labels below are recording.

Confidence levels: High that mobile has a real usability problem (8 of 10 mobile participants plus the telemetry both point the same direction). Medium that the desktop improvement is causal rather than a short-term novelty effect (it needs a controlled comparison to confirm). Two bounded follow-ups are prioritized: a moderated usability test with 6 mobile participants targeting the filter's tap targets and visibility, and a controlled experiment on desktop that runs long enough to rule out a novelty effect before crediting the redesign with the improvement.

Trade-offs and pitfalls

• Averaging contradictory quotes into a single "mixed signal" summary is the most common and most damaging shortcut; it erases exactly the segment split that would have made the finding actionable.
• It's easy to over-trust the most articulate or most senior-sounding quotes over a quieter majority saying something less quotable but more representative. Recording a weight per coded theme, rather than only a count, is the concrete defence: it forces the question "how many INDEPENDENT sources is this, and did we watch it happen or were we told about it" every time, instead of once, at the end, when the narrative has already formed.
• Running too many follow-up experiments at once dilutes attention and budget; a bounded, prioritized set beats a broad research agenda every time.
• Some contradictions genuinely don't resolve even after segmenting; naming that honestly as unresolved is more useful to stakeholders than forcing a false resolution to look thorough.

Direct answer

Timebox roughly six to eight total hours of prep across the two days, front-loading breadth (company, product, team) on day one and narrowing to role-specific depth and a same-day source check on day two, then walk in with three concrete deliverables: a one-page brief, a short ranked list of open questions, and one specific, current observation you can offer unprompted.

Structured elaboration

A sample timeboxed plan:

• Hours 1-2 (Day 1): company fundamentals, product, business model, recent news or funding, from the company site plus one or two independent articles.
• Hours 3-4 (Day 1): team and role specifics, a deep read of the job posting, LinkedIn for the hiring manager and current team members, the engineering or product blog if one exists.
• Hours 5-6 (Day 2): operational signals, public GitHub, app store or review sites, a status page, anything hinting at pain points.
• Hour 7 (Day 2, morning of): a live-source check, since something can change in the last 48 hours (a launch, an outage, a leadership change), and citing something that already changed is worse than not mentioning it at all.
• Hour 8: synthesis, actually writing the one-pager and the ranked question list.

Deliverables: a one-page brief (mission, likely composition, top challenges), three to five ranked open questions you'd actually ask, and one specific, current observation that proves the research is fresh rather than generic.

Worked example

Interviewing Wednesday for a Data Engineer role. Monday evening: two hours on the company site plus an article about a recent funding round. Tuesday lunch: two hours on the job posting, which repeatedly mentions "streaming pipelines," plus the hiring manager's LinkedIn, which shows a recent post about migrating off a legacy extract-transform-load (ETL, the process of pulling data from a source, transforming it, and loading it into a destination system) tool. Tuesday evening: two hours on their public GitHub, a data-quality library with recent active commits, and review sites, where a recurring theme is "great team, tooling is dated." Wednesday morning: a quick check for anything new (nothing has changed) plus writing the brief. You walk in with the brief, a ranked question list (the streaming migration's timeline first, current data-quality monitoring second), and a specific observation: noticing a recent commit adding schema validation to that data-quality library, and asking whether it's related to the ETL migration.

Trade-offs and pitfalls

The most common failure is spending all the time on breadth and none on synthesis, ending up with a lot of facts and no point of view, so timebox the synthesis step explicitly rather than letting it get crowded out. Don't manufacture a specific observation to sound prepared if you genuinely didn't find one, admitting you focused your limited time elsewhere is stronger than a vague, generic comment.