COMPLETE INTERVIEW GUIDE

UX Writer: Tricky Interview Questions, Best Answers & Complete Interview Guide

By salarymarkets.io · Original preparation guide · General advice, not employer-verified questions

UX Writer interviews test much more than your ability to make a button label shorter. A strong portfolio gets attention, but hiring teams also want to understand how you diagnose a confusing experience, challenge a weak requirement and help a product team make decisions. Your reasoning matters as much as the finished words.

Expect to demonstrate three things together: craft (can you write clear, useful interface content?), judgment (can you balance user needs, business goals and risk?) and collaboration (can you influence design and engineering before the screen is ready for copy?). This guide prepares you for all three. Treat the model answers as approaches to adapt, not personal experiences or results to claim.

01Understanding the UX Writer role

A UX Writer designs the language people encounter while using a product or service. That includes navigation, labels, instructions, onboarding, errors, notifications and confirmation messages. The work is not simply polishing sentences: it involves deciding what information belongs in an experience, when someone needs it and what they should be able to do next.

Typical responsibilities include mapping content across user journeys, developing terminology, writing and testing interface copy, collaborating with designers and researchers, reviewing implementation, maintaining content guidelines and coordinating localization. Depending on the organization, the title may overlap with Content Designer, Product Writer or Content Strategist, so clarify the actual scope.

Common tools include Figma for interface work, shared documentation tools for decisions and guidelines, issue trackers for implementation and analytics or research platforms for evaluation. Writers may also work with content management systems, localization platforms and string repositories. Tool familiarity helps, but understanding how content moves from design into a working product matters more.

Average versus exceptional performance
Area	Average performer	Exceptional performer
Craft	Makes individual strings concise	Makes the entire journey understandable and actionable
Research	Relies on personal preferences	Uses user language, task evidence and explicit hypotheses
Collaboration	Waits for screens to be finished	Helps shape requirements, flows and content early
Systems	Solves each screen separately	Builds reusable terminology, patterns and governance
Risk	Checks spelling before handoff	Checks accuracy, accessibility, consent and recovery paths

The role changes with team size and product maturity. At a startup you may establish basic terminology while supporting several product areas; at an established company you may own a specific journey within a mature content system. Junior writers are usually evaluated on execution and learning, while senior writers are expected to influence strategy, resolve ambiguity and improve how teams work.

02What AI can and cannot do

AI can help UX writers explore language and maintain content, but fluent output is not evidence of a usable experience. Interviewers may ask where you use it, what information you share and how you verify the result.

What AI already does well

Generating draft alternatives from a clear brief
Suggesting shorter versions of repetitive interface copy
Flagging possible inconsistencies against supplied terminology
Organizing approved, de-identified notes into themes for review

Where AI helps but needs oversight

Tone adaptation, which can introduce inappropriate reassurance or humor
Localization drafts that may miss context, grammar or regional expectations
Content audits that can overlook hidden states and dynamic strings
Explanations of product behavior that must be checked against implementation

Where human judgment remains especially valuable

Deciding whether a confusing interaction needs redesign rather than new words
Interpreting research without inventing user needs
Balancing clarity, consent, business goals and legal obligations
Taking responsibility for sensitive messages and recovery guidance

Skills to develop now

Documented AI workflows with source checks and human approval
Data-handling practices that protect confidential and personal information
Evaluation of generated product responses, including uncertainty and failure
Content systems that provide reliable terminology and context
Research interpretation and product judgment beyond sentence editing

0316 tricky interview questions and strong answers

1. “Walk me through a portfolio piece where the writing did not solve the problem.”

Why they ask: They want to know whether you can recognize the limits of copy and learn without defending every decision.
A strong answer shows: An honest diagnosis, your specific contribution and evidence that shaped the next step.
Example answer: I'd choose a real example and explain the task, the original assumption and what the evidence showed. If people still misunderstood a requirement after a rewrite, I'd examine when that requirement appeared and whether the interaction made it visible. I'd distinguish the wording change from any later design change and only claim results we actually observed. The important lesson would be how I changed my approach, not how I made the original work sound successful.
Avoid: Inventing research results, disguising a success as a failure or insisting every usability problem is a copy problem.

2. “A product manager wants a more persuasive consent screen. How would you respond?”

Why they ask: This tests whether you can support business goals without weakening informed choice.
A strong answer shows: Ethical judgment, accurate explanations and a practical alternative.
Example answer: I'd clarify what permission is being requested, why it benefits the user and what happens if they decline. I'd make those consequences understandable and keep the choices honest rather than hiding refusal or implying the permission is mandatory. If adoption is low, I'd investigate timing and relevance before making the wording more forceful. I'd involve privacy or legal partners where necessary and evaluate comprehension alongside acceptance.
Avoid: Optimizing acceptance alone, using guilt or treating legal approval as proof that an experience is clear.

3. “Rewrite this button: Submit.”

Why they ask: A small task reveals whether you ask about context before reaching for a familiar rule.
A strong answer shows: Task understanding, accurate expectations and concise language.
Example answer: I'd first ask what happens after the click. Is someone sending an application, saving a draft or confirming a payment? The label should describe that action accurately. For an application that is immediately sent for review, I'd consider "Send application" and check that the surrounding content explains what follows. I wouldn't choose a stronger verb until I understood the actual behavior.
Avoid: Declaring that a word is always wrong or writing a label that promises an action the product does not perform.

4. “How do you know whether your copy worked?”

Why they ask: Employers need evaluation tied to user tasks, not just preferences or shorter text.
A strong answer shows: A hypothesis, appropriate evidence and realistic attribution.
Example answer: I start with the problem: perhaps people cannot tell whether a change has been saved. I'd assess whether they understand the status and can continue confidently, using task observation or comprehension testing. In production, I might also monitor repeated actions or relevant support contacts. I'd compare against a baseline and check for other changes before attributing an improvement to wording alone.
Avoid: Using conversion as the only measure or claiming that an entire product improvement came from one label.

5. “A designer says your explanation makes the screen too crowded. What do you do?”

Why they ask: This tests collaboration when content and layout expose competing needs.
A strong answer shows: Curiosity about the underlying problem and willingness to change the interaction.
Example answer: I'd ask which information people need to make the decision at that moment. We could remove duplication, move optional detail or disclose information progressively. But if the explanation concerns a charge or an irreversible action, hiding it would create a different problem. I'd work with the designer on the hierarchy and flow, then review the result in context rather than defending my paragraph.
Avoid: Treating every word as essential or cutting necessary information simply to fit the existing layout.

6. “How would you write an error when engineering cannot identify the exact cause?”

Why they ask: Error messages expose whether you value accuracy over confident-sounding reassurance.
A strong answer shows: Honest uncertainty, safe recovery and attention to system behavior.
Example answer: I'd establish what the system does know: whether the action completed, whether input was preserved and whether retrying is safe. Then I'd explain the problem at that level and offer a verified next step. If a payment status is uncertain, I wouldn't tell someone to try again until we know that cannot create a duplicate. I'd also raise missing error distinctions as a product issue rather than inventing a precise explanation.
Avoid: Blaming the user, exposing internal codes without help or promising that no data was lost without verification.

7. “Legal requires language that users struggle to understand. How would you handle it?”

Why they ask: They want someone who collaborates with specialists without abandoning clarity.
A strong answer shows: Respect for requirements and a distinction between mandated language and inherited wording.
Example answer: I'd ask which meaning must be preserved and whether any wording is legally fixed. With that understood, I'd propose plain-language alternatives or a clear explanation alongside required text. I'd review the whole presentation, including timing and hierarchy, so critical information is not technically present but practically hidden. Legal would validate the obligation; research and accessibility review would help evaluate understanding.
Avoid: Removing required language independently or assuming every sentence from a previous screen is non-negotiable.

8. “How do you prepare interface content for localization?”

Why they ask: Writing that works in one language can fail when translated or implemented elsewhere.
A strong answer shows: Context, flexible layouts and collaboration with language specialists.
Example answer: I'd provide the purpose, audience, screen context and any variables for each string. I'd avoid assembling sentences from fragments and flag pluralization, dates and other locale-sensitive elements. I'd work with design and engineering on expansion and layout behavior, then involve localization partners early. A character limit needs a reason and a fallback, not an assumption that every language can fit the English.
Avoid: Treating localization as word substitution or using unexplained abbreviations to solve layout constraints.

9. “What does accessibility mean in UX writing?”

Why they ask: They are looking for practical habits rather than a general statement about inclusion.
A strong answer shows: Clear structure, meaningful labels and awareness of implementation.
Example answer: I use familiar language, descriptive headings and links that make sense in context. I check that instructions do not depend only on color, position or visual appearance. I also work with design and engineering on accessible names, error identification and status announcements. The words in a design file are not enough; I want to review the implemented experience with appropriate accessibility checks.
Avoid: Equating accessibility with short sentences alone or claiming that copy review establishes full compliance.

10. “How do you work when there is no research available?”

Why they ask: Teams need progress under uncertainty without unsupported claims about users.
A strong answer shows: Explicit assumptions, resourcefulness and a proportionate validation plan.
Example answer: I'd clarify the task and review available signals such as support themes, existing research and product behavior. I'd separate observations from assumptions and use established content patterns where appropriate. Then I'd propose the smallest useful validation step, such as a task walkthrough with relevant participants. If we must ship first, I'd document the uncertainty and agree what we will monitor afterward.
Avoid: Inventing a persona, presenting stakeholder opinions as research or refusing to proceed without an ideal study.

11. “Our brand voice is playful. Should our account suspension message be playful too?”

Why they ask: This tests whether you can distinguish a consistent voice from an unchanging tone.
A strong answer shows: Sensitivity to user circumstances and clear priorities.
Example answer: I'd keep the brand recognizable through direct, human language, but make the tone serious and respectful. Someone facing account suspension needs to understand what happened, what access remains and whether they can appeal. Humor could make the experience feel dismissive. I'd verify the explanation and recovery path with the policy team before refining the style.
Avoid: Applying personality mechanically or using warmth to obscure a consequential decision.

12. “Two teams use different names for the same feature. How would you resolve it?”

Why they ask: Terminology problems reveal whether you can think beyond an individual screen.
A strong answer shows: User-centered evaluation, cross-team alignment and maintenance.
Example answer: I'd map where each term appears and check whether the teams truly mean the same thing. Then I'd examine user language, existing mental models and any research before recommending a term. I'd involve the teams affected by a change, including support and localization, and document the decision with examples. The rollout needs an owner and a migration plan so the old term does not keep resurfacing.
Avoid: Choosing the term you personally prefer or publishing a glossary without arranging adoption.

13. “How do you prioritize when several teams need copy urgently?”

Why they ask: Hiring managers want reliable judgment under pressure, not a promise to do everything.
A strong answer shows: Risk-based prioritization, communication and sensible use of patterns.
Example answer: I'd compare user harm, launch dependencies, reach and the cost of delaying each request. A misleading payment confirmation would take priority over a cosmetic improvement. I'd make the trade-offs visible, agree priorities with the relevant leads and reuse established patterns where safe. If everything is labeled urgent, I'd ask for a shared decision rather than silently making commitments I cannot meet.
Avoid: Prioritizing the loudest stakeholder or treating every string as if it needs the same review effort.

14. “Would you use AI to write production interface copy?”

Why they ask: This tests practical adoption alongside privacy, accuracy and accountability.
A strong answer shows: A bounded workflow with human verification.
Example answer: I'd use an approved tool for exploration when the input is safe to share. I'd supply verified context and content rules, then review alternatives against the actual flow, product behavior and accessibility needs. I wouldn't upload confidential research or accept generated claims as facts. Production content would still follow normal review and implementation checks, with a person accountable for the final decision.
Avoid: Pasting output directly into production or describing prompting as a substitute for understanding the user task.

15. “How would you write for a feature that generates unreliable AI answers?”

Why they ask: AI product interfaces require expectation-setting without pretending that copy can fix model behavior.
A strong answer shows: Honest limitations, risk awareness and collaboration on product safeguards.
Example answer: I'd clarify the feature's intended use and the consequences of an incorrect answer. The interface should explain relevant limitations at the point of use and provide useful ways to verify, correct or report output. But a disclaimer is not a complete safeguard. I'd work with the team on evaluation, escalation and restrictions for high-risk use, and avoid language that implies unsupported certainty.
Avoid: Hiding limitations in terms, anthropomorphizing reliability or treating a warning as permission to ship unsafe behavior.

16. “What would your first 90 days look like?”

Why they ask: They want a realistic sequence for learning, contributing and building trust.
A strong answer shows: Listening first, targeted improvements and sustainable systems.
Example answer: I'd begin by learning the product, meeting partners and reviewing research, terminology and the path from design to release. Then I'd choose a well-scoped journey with a clear problem, establish how we will evaluate it and ship improvements with the team. As patterns emerge, I'd document reusable guidance and recommend priorities based on impact rather than proposing a complete rewrite immediately.
Avoid: Promising a new voice system before understanding the product or offering only an audit with no delivery plan.

Adapt these examples to your real experience — never invent results you can't discuss in detail.

04Practical tests and real-world challenges

Rewrite a difficult product flow

Evaluated: Task understanding, content hierarchy, edge cases and the reasoning behind your choices.
Approach: Read the brief, identify the user's goal and state assumptions. Review the sequence before rewriting individual strings, then cover errors, loading and completion where relevant.
Excellent looks like: Clear copy in context, accurate next steps and a concise explanation of any interaction changes needed.
Common mistakes: Polishing isolated labels, ignoring product behavior or delivering an unexplained list of alternatives.

Content critique and evaluation plan

Evaluated: Your ability to distinguish observed problems from hypotheses and prioritize useful changes.
Approach: Identify the task, explain likely friction and rank issues by consequence. Suggest focused revisions and how you would test comprehension or task success.
Excellent looks like: A balanced critique that acknowledges strengths, labels uncertainty and connects recommendations to evidence.
Common mistakes: Presenting taste as fact, inventing user feedback or proposing an experiment without a clear question.

Portfolio review presentation

Evaluated: Ownership, collaboration, product judgment and honest interpretation of outcomes.
Approach: Choose a focused set of cases and explain the problem, constraints, your contribution, alternatives and what happened. Anonymize confidential material and separate shipped work from concepts.
Excellent looks like: A coherent decision story with real artifacts, appropriate evidence and thoughtful limitations.
Common mistakes: Showing only final screens, taking credit for team decisions or inventing metrics to make the work appear stronger.

0510 ways to stand out

Bring a short product critique with specific observations and clearly labeled hypotheses.
Show before-and-after content in its full flow, not only as isolated strings.
Label your exact contribution and name the collaborators who shaped each case.
Explain the evidence behind decisions and distinguish measured outcomes from assumptions.
Include a reusable pattern, terminology decision or guideline that helped others work.
Show how you considered errors, empty states, permissions and recovery.
Prepare a small speculative example for the employer and clearly mark it as unvalidated.
Explain your AI workflow, including data restrictions and human review.
Connect writing decisions to user tasks and business goals without overstating attribution.
Follow up with a concise recap and any relevant material you promised.

0610 questions to ask your interviewer

What would make this hire successful after six months? — Reveals expectations, scope and how performance is assessed.
When does a writer usually join a product project? — Shows whether the role shapes experiences or mainly edits finished screens.
How do content decisions reach production? — Uncovers implementation ownership, tooling and quality checks.
What research and customer feedback can writers access? — Reveals how decisions are grounded in evidence.
How are disagreements about language resolved? — Clarifies decision rights and collaboration culture.
Which user journeys most need attention? — Identifies meaningful opportunities and current pain points.
Who owns terminology and content patterns? — Reveals the maturity and maintenance of the content system.
How do you handle AI tools and confidential information? — Shows awareness of governance and practical risks.
How do writers partner with localization and accessibility specialists? — Clarifies whether inclusive design is built into the process.
How have writers developed their careers here? — Reveals mentorship, progression and opportunities beyond production volume.

07Interview expectations by company type

These categories overlap, and every employer is different. Use them as typical patterns, not universal rules.

Startup: Pre-seed to Seed

Priorities: Finding product clarity quickly while establishing basic language and trust.
How the role differs: You may cover product flows, terminology, support content and some marketing work.
Evaluated skills: Independence, prioritization, direct customer learning and comfort with incomplete requirements.

Q1. We have no content guidelines. Where do you start?
Review the core user task, agree essential terminology and document a few useful patterns while improving the live experience.
Q2. How do you validate copy without a research team?
Use available customer conversations and support evidence, label assumptions and arrange focused task checks with relevant users.
Q3. Can you write our website too?
Clarify the expected scope and priorities, then agree how product and marketing work will share capacity.

Prepare: Study the core product journey and bring a lean plan for improving its most consequential friction.
Avoid: Proposing a large governance program before demonstrating practical value.
Smart question: “Which product decisions would I help shape, and which writing responsibilities sit outside the product?”

Startup: Series A to C

Priorities: Supporting growth while making language and workflows more consistent.
How the role differs: Partnering with several product teams and establishing patterns that reduce repeated decisions.
Evaluated skills: Cross-functional influence, content systems and thoughtful measurement.

Q1. How do you support more teams without reviewing every string?
Create tested patterns, clear guidance and review tiers based on risk, with an escalation path for unfamiliar cases.
Q2. How would you improve onboarding?
Identify where people struggle to reach value, examine the interaction and test focused changes rather than adding more explanation automatically.
Q3. How do you handle changing features?
Maintain shared terminology, track dependencies and agree when content must be reviewed again before release.

Prepare: Bring examples of reusable systems and explain how teams adopted them.
Avoid: Showing only polished screens without discussing scale or implementation.
Smart question: “Where is inconsistent content currently slowing growth or creating support work?”

Startup: Pre-IPO

Priorities: Consistency, accountable claims and reliable review as scrutiny increases.
How the role differs: Working across mature product teams with legal, privacy and communications partners.
Evaluated skills: Risk assessment, documentation and stakeholder alignment.

Q1. How do you manage required reviews?
Identify reviewers early, make the decision needed explicit and reserve time for implementation checks.
Q2. How do you avoid unsupported product claims?
Verify capabilities with accountable owners and remove promises that the actual experience cannot support.
Q3. How do you keep reviews from becoming endless?
Separate factual approval from style feedback, consolidate comments and establish a clear final decision-maker.

Prepare: Review public product language, trust information and the company's main user journeys.
Avoid: Treating compliance as an inconvenience or assuming polished wording guarantees accuracy.
Smart question: “Which content decisions require specialist approval, and who owns the final call?”

Large Business: Global

Priorities: Coherent experiences across languages, markets and product families.
How the role differs: Creating source content and patterns in partnership with regional and localization teams.
Evaluated skills: Internationalization awareness, terminology governance and asynchronous collaboration.

Q1. How do you write for multiple markets?
Use clear source content, document context and involve local specialists before treating a pattern as universal.
Q2. What if a translated label does not fit?
Review layout flexibility and meaning with the language team rather than forcing an abbreviation.
Q3. How do you maintain shared terminology?
Define ownership, document approved concepts and allow justified regional differences with clear records.

Prepare: Compare available regional experiences and note questions rather than assuming differences are errors.
Avoid: Treating English as the default mental model for every audience.
Smart question: “How are global consistency and regional authority balanced?”

Large Business: Regional

Priorities: Regional relevance within a broader product and brand system.
How the role differs: Adapting shared journeys to regional language, requirements and customer expectations.
Evaluated skills: Local insight, negotiation and careful adaptation.

Q1. How would you adapt a global onboarding flow?
Preserve the core task while checking local terminology, required information and familiar formats with regional partners.
Q2. What if global terminology confuses local customers?
Bring evidence, explain the consequence and propose a documented exception or shared terminology change.
Q3. How do you evaluate regional improvements?
Use relevant regional baselines and account for differences in audience and product availability.

Prepare: Research the region's product offering, customer needs and support language.
Avoid: Assuming regional adaptation means translation alone.
Smart question: “Which content decisions can this team make independently?”

Large Business: Local

Priorities: Clear local service experiences that remain consistent with company standards.
How the role differs: Supporting local digital journeys and their handoff to staff or physical locations.
Evaluated skills: Service awareness, practical collaboration and customer-centered language.

Q1. How would you improve an appointment flow?
Clarify availability, location, preparation and confirmation, then verify that the actual service matches those promises.
Q2. How do you balance local needs with corporate patterns?
Reuse established patterns where they work and document local requirements where they do not.
Q3. How do you work with frontline staff?
Learn the questions they handle and check whether interface guidance matches real procedures.

Prepare: Review the local service journey, including what happens after the digital interaction.
Avoid: Optimizing the screen while ignoring the offline experience.
Smart question: “Where do customers most often need staff help after using the product?”

Nonprofit Organization

Priorities: Mission access, dignity, trust and responsible use of limited resources.
How the role differs: Supporting service applications, donations, volunteering and communication with people seeking help.
Evaluated skills: Plain language, sensitive content, consent awareness and prioritization.

Q1. How would you write an eligibility message?
Explain the relevant criteria clearly, avoid blame and provide verified alternatives when someone cannot proceed.
Q2. How do you improve donation conversion ethically?
Clarify impact, payment terms and recurring choices without guilt, hidden defaults or unsupported claims.
Q3. How do you prioritize with limited capacity?
Start with barriers that prevent people from accessing services and reuse accessible patterns where possible.

Prepare: Understand the mission and distinguish the needs of donors from those of service users.
Avoid: Using pity-driven language or treating every audience as a fundraising prospect.
Smart question: “How do people who use your services influence content decisions?”

Government

Priorities: Public access, accuracy, accessibility and procedural accountability.
How the role differs: Helping people understand requirements and complete public-service tasks.
Evaluated skills: Plain language, policy interpretation and documented review.

Q1. How do you simplify policy content?
Work with policy owners to explain actions and consequences clearly without changing the underlying requirement.
Q2. How do you support people unfamiliar with the process?
Explain necessary terms, show requirements before they block progress and provide clear help routes.
Q3. How do you handle an urgent service update?
Confirm the authoritative source, coordinate approval and update affected guidance consistently.

Prepare: Review the agency's services, public language and applicable accessibility requirements.
Avoid: Using promotional language where people need neutral, actionable information.
Smart question: “How are policy accuracy and user comprehension checked before publication?”

Fortune 500

Priorities: Reliable experiences across complex portfolios, teams and governance structures.
How the role differs: Owning content within a product area while coordinating with established design and content systems.
Evaluated skills: Influence, systems thinking, implementation discipline and organizational navigation.

Q1. How do you manage conflicting stakeholder feedback?
Clarify the user task and decision criteria, distinguish requirements from preferences and use an agreed decision-maker.
Q2. How do you improve a legacy experience?
Map dependencies, prioritize consequential issues and plan incremental changes with the teams responsible for implementation.
Q3. How do you demonstrate value?
Connect work to agreed user and business outcomes while distinguishing content contributions from broader product changes.

Prepare: Study the relevant product division rather than relying only on corporate brand knowledge.
Avoid: Underestimating implementation dependencies or presenting governance as something to bypass.
Smart question: “How does this role work with central content leadership and embedded product teams?”

Small Business

Priorities: Practical improvements that help customers complete tasks and reduce avoidable support.
How the role differs: Often combining interface writing with help content, transactional messages and website work.
Evaluated skills: Versatility, scope management and direct customer understanding.

Q1. Where would you start improving our product?
Find the customer task with the clearest friction and business consequence, then propose a focused, achievable improvement.
Q2. How do you keep content consistent without specialist tools?
Maintain a lightweight shared source for terms, patterns and decisions with a clear owner.
Q3. How would you know the work helped?
Review task completion, relevant inquiries and customer feedback against an agreed baseline.

Prepare: Bring a realistic example tied to the business's actual customer journey.
Avoid: Proposing an elaborate content program without clear implementation capacity.
Smart question: “Which customer questions consume the most time today?”

08Compensation and salary negotiation

UX Writer compensation varies by location, seniority, industry and scope. Ownership of strategy, content systems, regulated experiences, localization or team leadership can affect how a role is leveled. Employment type also matters, particularly when comparing permanent work with contract engagements.

Research current market information for your location and compare responsibilities, not just titles. UX Writer, Content Designer and Product Content Strategist roles may overlap, but some positions focus on execution while others include research, strategy or management. Review the employer's published range where available.

When asked for expectations, ground your response in the role's scope and relevant market evidence rather than your current pay. If responsibilities are still unclear, ask about level, ownership and the approved compensation range before committing to a target. Explain how your experience matches the work being requested.

Evaluate the whole package: base pay, bonus, equity, benefits, leave, flexibility, equipment, learning support and career progression. For contract work, clarify payment terms, revision expectations, intellectual property and access to tools. Negotiate respectfully using scope and evidence rather than unsupported comparisons.

09Final interview preparation checklist

One week before

Review the employer's core product journeys
Select portfolio cases with clear ownership and honest evidence
Prepare examples of disagreement, uncertainty and learning
Research role scope and compensation in your location

One day before

Test portfolio links and prepare an offline backup
Remove confidential information and label speculative work
Confirm the interview format and exercise expectations
Prepare product observations and questions for the team

During the interview

Ask about the user task before rewriting
Explain assumptions, trade-offs and alternatives
Separate your contribution from the team's work
Be precise about what evidence does and does not show

Immediately afterward

Send a concise thank-you note
Share any promised, appropriately cleared materials
Record questions that need stronger examples
Reflect on scope, collaboration and overall fit

Five essential takeaways

Show how you solve user problems, not only how you polish sentences.
Explain the evidence and uncertainty behind your decisions.
Treat accessibility, consent and accurate expectations as part of the craft.
Demonstrate systems and collaboration that help content reach production reliably.
Tailor your preparation to the employer's product, users and operating constraints.

All interview guides