Question 1

Introduce yourself and walk us through your portfolio. What are you most proud of?

Accepted Answer

Background → Design philosophy → 1 highlight project → Connect to the role you're applying for. This is the opening question, but for designers it's tied to your portfolio - this is where you make an incredibly strong first impression. Don't walk through every project (boring!). Instead: start with a brief design philosophy ('I believe good design is design users don't notice they're using'), then zoom into your proudest project. Tell the story: how you received the brief, what user research insight you found, how your solution differed from the initial approach, and what measurable results it delivered. Example: 'My proudest project was redesigning a checkout flow for an e-commerce app. User testing revealed 60% drop-off at the address input step. I redesigned it with auto-fill + map picker, and conversion increased 35%.' Keep it to 3-4 minutes. Tip: Open your portfolio on a LARGE screen (laptop, not phone) and make sure all links work before the interview.

Question 2

Tell me about a project where you applied Design Thinking end-to-end. What did you do at each phase?

Accepted Answer

Empathize → Define → Ideate → Prototype → Test, with specific deliverables at each phase. This tests whether you truly LIVE Design Thinking or just read about it. Biggest mistake: describing a textbook-perfect process - nobody believes that. Tell the MESSY parts too. Example: 'Empathize - I interviewed 12 users, but initial insights were biased because I only talked to power users. Had to go back and interview 8 new users. Define - from affinity mapping, I extracted 3 key pain points but the team argued about priority, so we used dot voting. Ideate - Crazy 8s session with PM and dev, generated 24 ideas, filtered down to 3. Prototype - built an interactive Figma prototype in 2 days, NOT pixel-perfect - just enough to test. Test - 5 usability tests revealed 2 of 3 concepts failed because users couldn't understand the navigation. Went back to iterate on concept 3.' A story with struggles is believable - don't be afraid to mention process failures.

Question 3

Tell me about a time you had to defend a design decision to stakeholders or your team. What happened?

Accepted Answer

STAR: Context → Design decision → Pushback → Evidence you used → Outcome. This is crucial because it separates 'order-taking designers' from 'opinionated designers.' A common situation in Vietnam: PM or CEO wants to add features/elements to the UI that you know will cause cognitive overload. Great story structure: 'PM wanted to add an ad banner on the checkout page for ad revenue. I objected, fearing conversion impact. Instead of saying 'it looks bad,' I pulled data: checkout pages with ads see ~12% conversion decline (Baymard Institute research). I ran a quick A/B concept test on Maze with 20 users - 16/20 ignored the ad or felt disturbed. Presented data to PM, proposed alternative: post-purchase thank-you page for ads since the user already converted. PM agreed, ad revenue still hit 80% of target without hurting conversion.' Key: Use DATA and USER EVIDENCE, not ego or personal taste.

Question 4

How did you conduct user research in your most recent project? What methods, how many participants, and what were the key insights?

Accepted Answer

Research plan → Method selection rationale → Execution details → Synthesis → How insights shaped design. This immediately exposes whether a designer actually does research or just talks about it. I meet many candidates who say 'I do user research' but when probed, it's just checking GA data or reading app store reviews - that's secondary research, not primary. Be specific: 'For a fintech app onboarding redesign, I chose mixed methods: (1) Contextual inquiry - observed 5 users opening accounts at their homes, discovered they stopped at eKYC because they were afraid to photograph their ID. (2) Survey of 200 users who abandoned onboarding - 43% said 'I don't trust the app with my information.' (3) Competitive analysis of 5 other fintech apps for eKYC handling.' Key insight: Trust gap, not usability. Solution: security badges, social proof ('2 million people verified'), and allowing users to skip eKYC to explore first. Onboarding completion rose from 35% to 58%. Numbers matter - 5 users is fine for usability testing (Nielsen), but surveys need 100+ responses for statistical confidence.

Question 5

Have you built or contributed to a Design System? Describe how you organized components and ensured consistency.

Accepted Answer

Audit → Token system (colors, typography, spacing) → Component architecture → Documentation → Governance. Design System is one of the most valued skills for mid-senior designers in Vietnam in 2026. Don't just say 'I created a component library in Figma.' Go deeper: (1) Audit: Start by screenshotting the entire product, grouping patterns, finding inconsistencies (e.g., 12 different blue shades, 5 different button styles). (2) Token system: Foundation layer - color tokens (primary, secondary, semantic: success/warning/error), typography scale (heading 1-6, body, caption), spacing scale (4px base unit). (3) Component architecture: Atomic Design - atoms (button, input, icon), molecules (search bar, form field), organisms (header, card, modal). In Figma: use variants for states (default, hover, active, disabled), component properties for text/boolean. (4) Documentation: Each component has usage guidelines, do's and don'ts. (5) Governance: Process for requesting new components, review cycle. Big bonus if you discuss syncing with the dev component library (Storybook) - that shows you think beyond the Figma file.

Question 6

How do you handle accessibility in your designs? Give a specific example of balancing aesthetics with WCAG compliance.

Accepted Answer

WCAG principles (POUR) → Specific example → Tools used → Impact. Accessibility is increasingly important in Vietnam, especially for products targeting international markets or fintech (regulatory requirements). Don't just say 'I use 4.5:1 contrast ratio' - tell a real story. Example: 'When designing a banking app, the brand color was light blue (#67B8F5) on white - looked great but contrast was only 2.8:1, failing WCAG AA. Marketing didn't want to change the brand color. I proposed: keep the brand color for decorative elements (illustrations, background accents) but use a darker variant (#1A73E8, contrast 4.6:1) for interactive elements (buttons, links, text). Result: brand identity preserved, all actionable elements pass WCAG AA.' Tools: Stark plugin in Figma, axe DevTools for browser review. Beyond contrast, mention: keyboard navigation, screen reader labels, focus indicators, touch target size (44x44px minimum). Designers who can discuss cognitive accessibility (reducing cognitive load for already-stressed users in healthcare/finance apps) make a very strong impression.

Question 7

How do you use data to inform design decisions? Give an example where data changed your initial design direction.

Accepted Answer

Quantitative data (analytics) + Qualitative data (research) → Insight → Design pivot → Measured outcome. Data-informed design (NOT data-driven - design also needs intuition) is the skill that separates junior from senior designers. Example story: 'I was redesigning the product listing page for an e-commerce app. My gut said: adding more complex filters would help users find products faster. But Hotjar heatmaps showed only 8% of users used filters, 70% scrolled straight down. GA showed average time on page was 45 seconds - too short for complex filters. Insight: Users were browsing, not searching. Pivot: Instead of complex filters, I designed quick filter chips (tappable tags) + improved product cards with more visual info (larger images, prominent price + discount, rating). Result: product page views from listing increased 22%, add-to-cart up 15%.' Beyond Hotjar and GA, you should know: Mixpanel/Amplitude (event tracking), FullStory (session replay), Maze (remote usability testing), and how to read funnel analysis.

Question 8

You're asked to design a complex feature with only 3 days. How would you approach it?

Accepted Answer

Scope negotiation → Time-boxing → Design sprint lite → Leverage existing patterns → Communicate trade-offs. This happens VERY frequently at Vietnamese startups - tight deadlines, unclear scope. Good approach: Day 1 (Understand + Sketch): Spend 2 hours aligning with PM on scope - what's MUST HAVE vs NICE TO HAVE for v1. Sketch wireframes on paper or low-fi Figma - fast, rough, but enough to communicate the idea. Quick review with PM end of day. Day 2 (Design): Leverage existing design system components - this is where a design system proves its value. Mid-fi mockup for happy path + 2-3 most critical edge cases. End of day: review with dev to check feasibility early. Day 3 (Polish + Handoff): High-fi for key screens, prepare handoff specs. Document assumptions and unhandled edge cases - create tickets for v1.1. Key trade-off: DON'T aim for perfectionism in 3 days. Ship good enough, iterate later. A designer who says 'I need 2 more weeks' without proposing alternatives will be rated poorly - deadline is a constraint, creativity is how you work within constraints.

Question 9

A developer implements your design but the result looks very different from the mockup. What do you do?

Accepted Answer

Assess gap → Root cause analysis → Collaborative fix → Process improvement. This is a classic designer-developer pain point. Mistake: pointing at the dev and saying 'it's all wrong, redo it.' Right approach: First, ASSESS: Where are the differences? Spacing, color, typography, or behavior/interaction? What affects UX vs what's just pixel-level? Then ROOT CAUSE: (1) Unclear handoff (my fault) - Figma file missing specs, no redlines, prototype doesn't cover interactions. (2) Technical constraint (shared issue) - CSS limitation, third-party component doesn't support custom styling. (3) Dev ignored specs (dev's issue) - need to sit down and re-align. COLLABORATIVE FIX: Open Figma next to the browser, go through each difference. Critical ones (affect usability): fix immediately. Minor ones (2px spacing): log as tech debt, fix later. PROCESS IMPROVEMENT: Next time, add a design review checkpoint BEFORE dev merges the PR. Or pair design-dev sessions for complex interactions. A real story will always be stronger than theory - tell about a specific time you handled this.

Question 10

Here's the main screen of app X (interviewer shows screenshot). If you had to redesign it, how would you approach it?

Accepted Answer

Heuristic evaluation → User problems hypothesis → Information architecture review → Wireframe sketch → Validation plan. This is a common 'whiteboard challenge' - don't panic, show your process not just results. Step 1: DON'T start drawing immediately. Ask the interviewer: 'Who are the target users? What's the main business goal? Any data on current pain points?' If no data, state your assumptions. Step 2: Quick heuristic evaluation using Nielsen's 10 principles - identify 3-5 key issues: navigation confusion, information overload, unclear CTA hierarchy, etc. Step 3: Sketch 2-3 directions on paper/whiteboard, explain the rationale for each approach. Step 4: Pick 1 direction, add more detail, explain how you'd validate (usability test, A/B test, tree testing for IA). The interviewer doesn't expect a masterpiece in 15-20 minutes - they want to see HOW YOU THINK: Do you ask the right questions? How do you structure the problem? Do you balance user needs with business goals? Do you mention validation?

Question 11

Design an onboarding flow for a personal finance app, knowing that 60% of users drop off before completing registration.

Accepted Answer

Drop-off analysis → Progressive disclosure → Trust building → Minimal viable onboarding → Success metrics. This case study is very relevant for Vietnamese fintech. Don't jump to wireframes - analyze the problem first. Where does the 60% drop-off happen? Hypothetical funnel: Download (100%) → Open app (80%) → Start registration (50%) → KYC step (30%) → Complete (40%). Biggest drop at KYC - related to TRUST. Approach: (1) Progressive disclosure: Don't ask for all info upfront. Let users explore the app first (features, demo data), then request registration when they see value. (2) Social login: Reduce friction - Google/Facebook sign-in instead of long forms. (3) Gradual KYC: Only require phone number for basic features, ask for ID when users want to transfer money (higher motivation at that point). (4) Trust signals: 'Licensed by State Bank of Vietnam,' '256-bit encryption,' registered user count. (5) Micro-rewards: After each step, show progress bar + benefit unlock ('Complete step 3 to unlock expense tracking'). Sketch 5-7 key screens, explain transitions. Metric: Target reducing drop-off from 60% to 35%.

Question 12

What keeps you passionate about design after all these years? Where does your design inspiration come from?

Accepted Answer

Personal story → Evolution of your 'why' → Current inspiration sources → Future aspiration. This sounds simple but reveals a lot about who you are. Don't give cliches like 'I love being creative' or 'I want to help users.' Tell a REAL STORY. Example: 'I got into design because I liked drawing and making things look beautiful. The turning point was designing an app for a hospital - I watched elderly patients struggle to book appointments on the app, hands shaking, poor eyesight, and I realized design isn't just about beauty - it's ACCESSIBILITY, EMPATHY, helping people complete something important without needing help.' Inspiration sources: don't just say Dribbble or Behance (too generic). Be specific: podcasts (Design Better, Wireframe), books (Don't Make Me Think, Refactoring UI), communities (UXVN, Figma Community), or even non-design inspiration - architecture, nature, how a restaurant menu is organized. Great closing: 'I still get excited every time I see a user navigate my product without any instructions - that's when I know I did it right.'

Question 13

What are your salary expectations?

Accepted Answer

Market benchmark → Skill premium (design system, research, prototyping) → Total compensation → Flexibility. Reference salary ranges for UX/UI Designer in Vietnam as of Aug 2026: Junior (0-2 years): 12-20M VND/month, Mid (2-4 years): 20-40M VND/month, Senior (4-7 years): 35-70M VND/month, Lead/Head of Design: 60-120M+ VND/month. Product Designers typically earn 15-25% more than pure UI Designers at the same level. Note: Agency designers usually earn 10-20% less than in-house, but gain more diverse portfolios. How to answer: 'With 3 years of experience and skills including user research, design system, and prototyping, I expect a 28-38M total package range for a mid-level position. I also value benefits like learning budget, conference attendance, and flexible working.' Designer-specific tip: if you have additional skills in motion design, micro-interactions, or basic front-end (HTML/CSS), those are premium skills worth mentioning in negotiation. Designers who can code can ask for 15-20% more than pure designers. Disclaimer: These figures are reference data as of Aug 2026; check latest sources from UXVN Salary Report, TopCV, or Glassdoor VN.

Question 14

How do you prefer to receive design feedback? How do you react to harsh critique?

Accepted Answer

Feedback preferences → Separation of ego from work → Growth mindset example → Team dynamics. This is a key culture fit question because designers often have emotional attachment to their work - and critique can feel personal. Be honest but not dramatic. Good: 'I prefer feedback that's specific and actionable - for example, 'the CTA button blends into the background due to low contrast' is much more useful than 'it doesn't look right.' I also prefer feedback early rather than late - reviewing at wireframe stage saves a lot of effort vs fixing at high-fi.' On harsh critique: 'Honestly, it stings at first - that's a natural reaction. But I've learned a trick: breathe, write down the feedback, then revisit it after 30 minutes with a fresher mind. Usually 70% of harsh feedback has valid points. Once a stakeholder said 'this design looks amateur' - instead of getting defensive, I asked 'specifically what part feels unprofessional?' and that feedback led to a genuine improvement.' Avoid: Saying 'I accept all feedback' (sounds fake) or 'I don't like being critiqued' (red flag).

Question 15

Do you have any questions for us?

Accepted Answer

3 questions: Design process/maturity → Team structure → Growth/Tools. Like with PM, this is a chance to show professionalism and genuine interest. Quality questions for designers: (1) Design maturity: 'Where is the design team on the Nielsen-Norman UX maturity model? Is there dedicated research ops or do designers run their own research?' - shows strategic thinking about design practice. (2) Team structure: 'Are designers embedded in product squads or in a centralized design team? What's the designer-to-developer ratio?' - shows you care about real collaboration dynamics. (3) Tools & growth: 'How does the team handle Figma version control? Is there a shared design system and who maintains it?' - practical question showing you're ready to contribute immediately. (4) Bonus: 'Are there regular design critique sessions? I really value a culture of frequent feedback.' AVOID asking: 'Will I have to do graphic design?' (sounds like you're afraid of work), or questions too far from the role (company 5-year strategy).

Question 16

Describe your Figma workflow: how you organize files, use auto layout, variants, and prepare handoff for developers.

Accepted Answer

File structure → Naming convention → Auto layout usage → Component variants → Dev mode/handoff specs. Figma proficiency is table stakes for Vietnamese designers in 2026 - but how you organize files reveals a lot about systematic thinking. File structure: Project → File per feature/epic → Pages: Cover, Research, Wireframes, Design, Prototype, Handoff, Archive. Naming: Components use slash notation (Button/Primary/Large, Button/Primary/Small). Meaningful frame naming (Login_Screen_Default, Login_Screen_Error). Auto layout: MUST use for all components - no fixed width/height unless there's a reason. Auto layout enables responsive design, helps devs understand spacing logic, easier to maintain. Variants: A button component should have variants for: Type (primary, secondary, ghost), Size (S, M, L), State (default, hover, active, disabled, loading). Use component properties for icon swap, text label. Handoff: Figma Dev Mode for spacing/color/typography specs. Prototype for interactions. Annotation component for behavior notes ('Tap outside modal -> dismiss', 'Error clears when user starts typing again'). I often fail candidates whose Figma files have layers named 'Frame 247', 'Rectangle 18' - that's a red flag for sloppiness.