Revolut Frontend Interview Questions

What this measures

Request-state modelling, error handling that is explicit rather than swallowed, TypeScript at the boundary, pace under a clock, and whether the first ten minutes go to the contract or to folder structure.

Clarify first

• Confirm the response shape, what an empty result looks like, and which failures are in scope: network, non-200 status, malformed data.
• Confirm how the interviewer wants errors surfaced at the fetch boundary, and whether tests are expected inside the hour.

Strong answer should cover

• Hold the request in one discriminated union, loading, success with data, empty and error with a message, so no two states can be true at once.
• Type the response once at the fetch boundary, narrow unknown errors to a message, and never let `any` reach the component.
• Render the loading state before the request resolves, then branch on the status alone; show rows only on success.
• Guard stale responses with a cleanup flag, and add one test per state if time remains, starting with the error path.

What this measures

Collaboration under observation, where auth and transport concerns live, request cancellation and timeouts, and how you explain trade-offs while typing.

Clarify first

• Confirm how the token is provided, how long it lives and what the API returns when it is missing or expired.
• Confirm whether a shared fetch wrapper or a data-fetching library is acceptable, or whether the interviewer wants plain `fetch`.

Strong answer should cover

• Put the auth header, the timeout and the JSON parsing in one small wrapper so the component only sees typed data or a typed error.
• Abort the request on unmount or when the inputs change, and treat a 401 as a distinct state with a distinct message.
• Narrate the plan before coding and after each step; ask for the next requirement as soon as the current one works.
• Keep the component declarative: it renders from the request state and never builds headers itself.

What this measures

Clean fundamentals under a clock, reading a problem statement precisely, handling edge cases without prompting, and knowing when to move on.

Clarify first

• Read every constraint and sample before coding; note input sizes, ties and empty inputs explicitly.
• Decide the order: bank the two easier tasks first, then spend the remaining time on the third.

Strong answer should cover

• Write a brute-force version that passes the samples, then improve it only if the constraints demand it.
• Use a sliding window or a map-based count where the statement asks about contiguous ranges or frequencies, and state the complexity in a comment.
• Handle empty input, a single element and duplicates before polishing names.
• Leave the hardest task with a correct partial solution rather than an elegant incomplete one.

What this measures

Whether you can state fundamentals plainly to a listener who is checking answers against a list, without jargon they cannot verify and without drifting into unrelated detail.

Clarify first

• Ask whether a short definition or an example is preferred; an example usually shows understanding fastest.
• Confirm which framework the role uses before answering the rendering question.

Strong answer should cover

• Reconciliation: React compares the new element tree with the previous one and updates only the DOM nodes whose type or props changed, matching list children by key.
• Microtasks run to completion after the current task and before the next macrotask, so a resolved promise callback runs before a zero-delay timeout.
• The DOM tree is the in-memory tree of nodes that the browser builds from the HTML; scripts read and change it, and the browser renders from it.
• Add one concrete example per answer, for example a list rendered with index keys or a `setTimeout` versus `Promise.then` ordering.

What this measures

Product thinking, API design from the point of view of the client, idempotency and retry rules for actions that move money, and how you reason about partial failure.

Clarify first

• Confirm the scope: one feature or several, which clients consume the API, and whether the design should cover the services or only the contracts.
• Confirm the consistency expectation: can the user see a pending state, or must every screen reflect the final result?

Strong answer should cover

• Start from the user flow and write the API contracts as the client needs them: request and response shapes, the error codes the UI branches on, and pagination where lists grow.
• Give every action that changes money an idempotency key and define what the client shows while it is pending and after a timeout.
• Separate read models from write actions so the screens stay fast while the actions stay safe.
• Name the failure cases out loud: the request that times out after the server committed, the duplicate tap, the stale cached view.