Interview questions for an Android engineer.

The questions.

1. 01

   situational medium · design-disagreement

   A designer sends you a design that's beautiful but unaccessible. Walk me through what you do.

   Strong answer

   Doesn't just implement it silently. Doesn't reject outright. Proposes a specific accessible variant that keeps the intent. Learns the designer's reasoning first.

   Weak answer

   Either implements it badly or escalates to management.
2. 02

   communication medium · explaining

   Explain hydration mismatches to a backend engineer who writes mostly Python.

   Strong answer

   Concrete example. No React-specific jargon that doesn't translate. Uses an analogy the listener gets.

   Weak answer

   Talks about virtual DOM reconciliation and loses the listener.
3. 03

   technical medium · build-tools

   What actually happens when you run `npm run build` on a React app?

   Strong answer

   Bundler walks the dep graph from entry. Tree-shakes. Minifies. Code-splits. Outputs hashed assets. Generates manifest. Knows webpack/vite/esbuild by more than name.

   Weak answer

   'It makes the code smaller.' Doesn't understand the pipeline.
4. 04

   technical medium · forms

   Design a form validation UX. What do you get wrong if you validate on blur vs on submit vs as-you-type?

   Strong answer

   Knows the UX research: as-you-type is annoying before user finishes, submit is late. Hybrid: validate on blur AFTER first submit attempt. Accessibility: announce errors properly.

   Weak answer

   'We'll validate on submit.' Or validates every keystroke without understanding why that's bad.
5. 05

   technical baseline · css

   When would you use CSS Grid vs Flexbox?

   Strong answer

   Grid for 2D layouts, Flexbox for 1D. Knows they compose. Not dogmatic.

   Weak answer

   'I just use whichever I'm used to.' No sense of when each is right.
6. 06

   technical medium · performance

   Your page's Largest Contentful Paint is 4.2s. Users are complaining. Where do you start?

   Strong answer

   Measures before guessing — Lighthouse, RUM data. Investigates render-blocking resources, image sizes, critical CSS, TTFB. Considers SSR/prerender if relevant.

   Weak answer

   Adds lazy-loading everywhere without measuring. Or 'we'll upgrade the CDN.'
7. 07

   technical hard · accessibility

   Audit this button: `<div class='btn' onclick='submit()'>Save</div>`. What's wrong, in priority order?

   Strong answer

   Not keyboard-reachable. Not semantic (screen readers skip it). No focus ring. onclick-only breaks JS-disabled edge cases. Mentions ARIA only as last resort, not first.

   Weak answer

   Only mentions ARIA. Doesn't notice keyboard/focus issues.
8. 08

   experience baseline · resume-probe

   You shipped a redesign of X. What was measurably better after — and how did you measure it?

   Strong answer

   Specific metric (conversion, bounce, time-on-page). Honest about what got worse. Follow-up iterations based on data.

   Weak answer

   'Users liked it more.' No metric. No follow-up.
9. 09

   technical medium · state-management

   React app, 50 components, you're picking a state management approach. Walk me through the decision.

   Strong answer

   Starts with React's built-in primitives (useState, useContext). Only reaches for Zustand / Redux / Jotai when the shape of state justifies it. Discusses server-state separately (React Query / SWR).

   Weak answer

   Picks Redux by default. Or goes 'useContext for everything' at scale.
10. 10

    culture medium · shipping

    Product wants to ship a feature that's 'good enough.' You see 3 accessibility issues that'll affect 5% of users. What do you do?

    Strong answer

    Weighs cost vs user impact. Communicates trade-off clearly, doesn't just block. Fixes what's easy now, files specific follow-ups for the rest.

    Weak answer

    Either blocks the ship until perfect, or ships with known issues silently.