Use this guide to prepare for Frontend or Mobile Engineer interviews, with a focus on html, react, css. Explain your reasoning and connect it to experience you can substantiate.
These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
HTML
React
CSS
Kotlin
Tooling standardisation
Next.js
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
Technical · Fresher
1. Why use semantic HTML elements instead of making every control a div?
Answer guide
Elements like button, nav, main and form carry built-in meaning and behaviour. A native button is focusable, works with Enter and Space, and is announced to screen readers as a button, whereas a clickable div needs tabindex, key handlers and ARIA roles added by hand, and it is easy to miss one. Semantic markup also helps search engines understand page structure and makes the code easier to read and maintain. Use ARIA only to fill gaps, not to replace proper elements. I would check with keyboard-only navigation and a screen reader.
What this question explores
Awareness that semantic HTML gives accessibility and keyboard behaviour for free, and that div-only pages cost more.
Common mistakes
Saying it only matters for search engines and ignoring accessibility.
Building a clickable div with a click handler and assuming keyboard users are covered.
Practise a follow-up
What does the first rule of ARIA say about when to use it?
How would you make a custom dropdown usable with the keyboard only?
Put in state only the smallest set of values that can change and cannot be worked out from something else, such as the text in an input, a selected item ID or whether a panel is open. Anything that can be calculated from state or props, for example a filtered list, a total or a full name, should be computed during rendering, because storing a copy creates two sources of truth that fall out of step. Do not store props or values that never change. Ask of each candidate: is it passed from a parent, does it stay the same, or can it be computed?
What this question explores
Ability to keep state minimal and derive the rest, avoiding duplicated or out-of-sync data.
Common mistakes
Copying props into state so the component ignores later updates from its parent.
Storing derived values such as totals or filtered lists in state and syncing them manually.
Practise a follow-up
Why is mutating a state array directly a problem in React?
When would you lift state up to a parent rather than keep it local?
3. How would you diagnose a layout that breaks on narrow screens?
Answer guide
I start by reproducing the problem in browser dev tools with device mode at the failing width, then inspect which element overflows or wraps badly, looking at computed width, margins, padding and any fixed widths or long unbreakable strings. I fix the component's sizing rules first, preferring flexible units and minmax over hard-coded values, and add a media or container query only if the layout truly needs to change. Then I resize through a range of widths, not just one phone size, and confirm there is no horizontal scroll.
What this question explores
A methodical debugging approach to responsive layout rather than trial and error with breakpoints.
Common mistakes
Adding a media query for one device width instead of finding the underlying sizing rule.
Ignoring min-width and overflow behaviour of flex or grid children.
Practise a follow-up
Why can a flex child refuse to shrink below its content width, and what fixes it?
When would you choose a container query rather than a viewport media query?
4. How would you expose loading, content and error states from a Kotlin repository to a UI?
Answer guide
Model the screen as a small typed state, for example loading, content with data, and error with a message, so the UI has to handle every case and cannot show a half state. The repository exposes it through a Flow that the UI collects in a lifecycle-aware way, so collection stops when the screen is not visible and cancellation flows through to the network call. Keep the repository or database as the single source of truth and let the UI only render. Separate one-time events like navigation from state, since state is replayed to new collectors and events should not be.
What this question explores
Whether you design clear UI state models with lifecycle-aware streams and a single source of truth.
Common mistakes
Uses several nullable fields such as data and error, which allow impossible combinations.
Sends one-time events through the same state stream, so they replay after rotation.
Practise a follow-up
How would you avoid replaying a one-time navigation event?
How would you show cached content while a refresh is loading?
5. How would you standardise frontend tooling across eight teams that each chose their own build setup, without killing their autonomy?
Answer guide
I would start by understanding why teams chose differently and what pain they have, then define a small paved road: a supported template with build, lint, test and deploy configured well, that is easier to adopt than to avoid. Standards are mandatory only where they cut real risk, such as security scanning, accessibility checks and performance budgets, while internals like state libraries stay a team decision within guidelines. I would form a small group with representatives from teams to own it, migrate teams gradually, and measure outcomes such as build time and onboarding time, so adoption is driven by benefits.
What this question explores
Whether you can balance consistency and team autonomy through enabling platforms, selective mandates and measured outcomes.
Common mistakes
Mandating one stack from the top without hearing the teams' needs.
Standardising everything, including choices that carry no real risk.
Practise a follow-up
How would you handle a team that refuses to migrate?
6. How would you decide whether data should be fetched on the server or in a client component?
Answer guide
Fetch on the server when the data needs secrets, is close to the database, benefits from caching, or should be present in the first HTML for speed and search engines. A common design is to fetch the initial data in a server component and pass it to a small client component that handles interaction. Server fetching keeps API keys out of the browser and reduces JavaScript sent. The cost is less immediate interactivity and caching rules to understand. Check the framework documentation for your version, because caching defaults have changed between releases.
What this question explores
Ability to choose where data fetching belongs by weighing security, performance and interactivity.
Common mistakes
Fetching everything in client components, exposing keys and delaying first content.
Making everything server-rendered, then struggling to support interactive filters and live updates.
Practise a follow-up
How would you keep a private API key out of client bundles in a Next.js app?
What determines whether a fetched result is cached or refetched, and how do you control it?
7. How would you avoid leaking a subscription in an Angular component?
Answer guide
Any subscription to a long-lived observable, such as an interval, a store or a websocket, keeps running after the component is destroyed unless it is released, which leaks memory and can update dead views. The cleanest option is to let the template handle it with the async pipe, which unsubscribes automatically. HTTP calls that complete on their own are usually not a problem. The trade-off is that manual unsubscribing is easy to forget, so I prefer the declarative approach and confirm with a heap snapshot after navigating away repeatedly.
What this question explores
Awareness of observable lifetimes in Angular and use of declarative cleanup rather than manual bookkeeping.
Common mistakes
Subscribing in ngOnInit to long-lived streams and never unsubscribing.
Unsubscribing manually in some places but forgetting others, with no consistent pattern.
Practise a follow-up
Which observables need cleanup and which complete by themselves?
What are the pros and cons of the async pipe compared with subscribing in the component class?
8. How do computed properties differ from watchers in Vue?
Answer guide
A computed property derives a value from reactive data, is cached, and recalculates only when its dependencies change, so it is ideal for things shown in the template such as a filtered list or full name. Computed values should be pure, with no side effects, while watchers are where asynchronous or imperative work belongs. A common mistake is using a watcher to copy one value into another, which computed handles more simply and with fewer bugs. I pick computed first and reach for a watcher only when something outside the component must be triggered.
What this question explores
Whether you can separate derived state from side effects in Vue's reactivity model.
Common mistakes
Using a watcher to update a second variable that a computed property could produce.
Putting side effects, such as API calls or mutations, inside a computed property.
Practise a follow-up
Why is a computed property cached, and when does it recompute?
How would you debounce a watcher that calls a search API?
9. How does Svelte update a UI when component state changes?
Answer guide
In Svelte, a compiler turns your component into code that updates the DOM directly when state changes, so there is no virtual DOM diffing at runtime. Assigning to a reactive variable, or updating a rune-based state value in current versions, marks the dependent parts of the template as needing an update, and only those parts are changed. The pitfall is mutating things in ways the compiler cannot see, depending on the version's rules. Because syntax has changed across major versions, I check the documentation for the version in use and confirm updates in the browser.
What this question explores
Understanding of compile-time reactivity and how to structure state so updates stay predictable.
Common mistakes
Saying Svelte uses a virtual DOM in the same way React does.
Storing duplicated derived values and manually syncing them instead of deriving them from source state.
Practise a follow-up
What changes when you move from older reactive statements to runes in newer Svelte versions?
How would you share state between two distant components in Svelte?
10. What tradeoff comes with utility classes in Tailwind CSS?
Answer guide
Utility classes let you style directly in the markup with small single-purpose classes, which speeds up work, avoids naming things, keeps styles near the element and produces a small stylesheet since unused classes are removed. The cost is long class lists that repeat and hide intent, and inconsistent values if each developer picks their own spacing or colours. Use apply sparingly. In a team I would agree on conventions and use a formatter for class ordering. The decision rule is to extract a component when you copy a group of classes a third time.
What this question explores
Balanced view of Tailwind's speed against readability and consistency, with sensible ways to manage repetition.
Common mistakes
Saying utility classes are always cleaner and ignoring long, repeated class strings.
Overusing apply to recreate traditional CSS classes and losing the benefits of utilities.
Practise a follow-up
When would you extract a component instead of using apply in Tailwind?
How do design tokens in the Tailwind configuration help a team stay consistent?
11. How would you keep a Flutter screen responsive during expensive parsing?
Answer guide
Flutter draws the interface on the UI isolate, so long parsing there freezes animations and taps. Move the CPU-heavy work to another isolate, for instance with the compute helper or Isolate.run in current versions, and pass back only the parsed result. Meanwhile show a loading state and a clear error state, and cancel or ignore results if the user leaves the screen. Measure with the performance tools first, because parsing is not always the culprit, and rebuilding a huge widget tree can also cause jank.
What this question explores
Whether you understand Flutter's single UI isolate and can offload work sensibly while handling loading, errors and measurement.
Common mistakes
They wrap the parsing in async and await, believing this alone moves the work off the UI thread.
They optimise the parser blindly and never profile to see whether rebuilds are the actual bottleneck.
Practise a follow-up
What limits exist on the data you can pass between isolates?
How would you show progress or cancel the parsing if the user navigates away?
12. A React Native list stutters on a low-end phone. What would you inspect?
Answer guide
On a low-end phone I would profile before touching code, watching both the JavaScript thread and the UI thread to see which one drops frames. Common causes are rows that rerender needlessly, heavy work inside render functions, oversized images and poorly tuned virtualised list settings such as window size or item layout hints. Memoise rows, keep stable keys and resize images. Always test a release build on a genuinely weak device, since debug builds are far slower and can mislead you into blaming the bridge.
What this question explores
Whether you diagnose list jank methodically across threads and devices instead of guessing or trusting a debug build.
Common mistakes
They measure performance in a debug build on a fast emulator and conclude the list is fine.
They blame the bridge or the framework immediately without profiling rerenders and image sizes.
Practise a follow-up
How does virtualisation reduce work, and what settings would you tune first?
What would you do if the jank only appears while images are loading?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.