Revolut Screening Call Prep

The 30 minutes, decoded

This is a recruiter screen, not a coding interview. Deniz's job is to answer three questions for the hiring manager:

Is the experience real? Can you talk about TypeScript, React, architecture and testing like someone who lived it — with concrete examples and numbers?
Will this person fit Revolut's intensity? Ownership, speed, "why" behind decisions, not just "what".
Are the logistics workable? Location/entity, salary expectations, notice period, English fluency.

You are not expected to solve anything live. You are expected to be specific, structured, and enthusiastic about Revolut in particular.

Their agenda → your plan

Segment	What they do	What you do
Intro + HR (10 min)	Intro, CV walk-through, motivation, logistics (location, salary, notice, timeline)	Deliver your 90-second pitch (memorized skeleton, not word-for-word). Have your salary line and logistics answers ready — see 💬 HR tab.
Background + scenario tech (10–15 min)	Scenario questions on TS / React / JS / architecture / testing: "tell me about a time…", "how would you approach…"	Answer in STAR shape, 60–90 seconds each. Always end with a measurable result and the why behind the choice. See ⚙️ and ⭐ tabs.
Your Q&A (5–7 min)	Answers your questions, explains next steps	Ask 2–3 prepared questions (❓ tab). Confirm next steps + timeline before hanging up.

Your unfair advantages — lead with these: ~a decade at one product company (Artlist) serving 10M+ creators · 90%+ test coverage across micro-frontends ("tests come with the feature, not after the bug report" — that sentence is made for Revolut) · 40% faster load times · design systems over one-off components · migrations invisible to users · side projects you own end-to-end (RetinaDesk, SalahClock, E-Bill) = product ownership proof.

The one logistics question you must get answered: you're in Bogura, Bangladesh. Revolut hires through legal entities in specific countries and many roles are "remote within X" or relocation-based. Ask early and calmly: "Could you clarify how the role is set up — is it remote from anywhere, tied to a specific entity/country, or is relocation part of the plan?" Better to know in call one than in week five.

Prep schedule (Jul 3 → Jul 9, ADHD-sized chunks)

Why candidates fail this screen (so you won't)

Generic "why Revolut". "I want to work in fintech" is an instant yawn. Name products, name what impressed you, connect it to your work. (reported across interview guides — see Sources)
Not knowing the products. Revolut expects you to have explored what they build. The app isn't available in Bangladesh — say that honestly and show you did homework anyway (🏛️ tab has your script).
Vague answers with no numbers. Revolut is metrics-obsessed. Every story should end in a number: %, ms, users, coverage.
No "why" behind decisions. They flagged this in the email: product ownership = explain the reasoning, trade-offs, and what you'd do differently.
Rambling. 60–90 seconds per answer, then stop. It's fine to ask "want me to go deeper?"
Salary panic. Have a calm, prepared line (💬 tab). Never blurt a desperate low number, never refuse to engage.

The full Revolut frontend pipeline

Compiled from candidate reports (Taro, Glassdoor, Blind, interview guides — see 📚 Sources). Stage names/order vary slightly by team and region; your recruiter will confirm your exact track. Total timeline: typically 2–6 weeks, and Revolut moves fast between stages.

Recruiter screening call — YOU ARE HERE (Jul 9)

30 min video call. Background, motivation, logistics, scenario-flavoured technical questions on TS/React/JS/architecture/testing. Recruiter gauges culture fit and flags your profile to the hiring manager.

Reported: "intro call = general info + CV questions", salary expectations often asked here; some candidates got a ~15-min rapid tech-theory checklist inside this call.

Online assessment / take-home (varies by team)

Some tracks get a HackerRank-style test or a take-home task (reported ~4–8 hours of work, 5–7 day deadline). Frontend take-homes are typically a small React app with API integration. Treat it as production code: tests included, README, error states, accessibility.

Reported by ophyai guide + Blind posts; not all candidates get this stage.

Pairing session (live React coding)

Real-world task, e.g. "use a service API with authentication to display data in a React component" (actual reported task, Barcelona FE candidate, 2025). Expect: fetch + auth headers, loading/error/empty states, typing the response, componentizing, and writing tests. Candidates report failing for skipping tests even when told they're optional.

Taro FE experience report; Dataford guide stresses TDD emphasis.

Frontend system design

Design a feature at scale: architecture, state management, API contract, performance budgets, error handling, testing strategy, rollout/migration. Your Artlist micro-frontend + design-system experience is exactly this round's language.

Taro FE experience report (JS event loop and React internals questions also reported here).

Team fit / hiring manager round

45–60 min behavioral deep-dive: ownership stories, conflict, incidents, "never settle" moments, why Revolut again (deeper this time). STAR everything.

Reported consistently across guides and candidate posts.

After each stage, feedback tends to come fast (days, sometimes hours). If you pass the screen, ask Deniz exactly which stages your track has — teams differ, and knowing removes anxiety.

Reality check, said kindly: Revolut's bar is high and their process is demanding — candidate reports skew "difficult", and their culture is famously intense (Blind threads complain about work-life balance; Glassdoor is mixed). None of that is a reason to panic. It's a reason to be specific, test-obsessed, and honest — which is already how you work.

HR questions — with your answers drafted

These drafts are built from your CV. Personalize, then practice out loud — the skeleton matters, not the exact words.

“Tell me about yourself” — your 90-second pitch HR

Structure: present → proof → why here. Keep it under 2 minutes.

"I'm Parish, a senior frontend engineer from Bangladesh with about 10+ years building web applications, most of that decade at Artlist, where I helped grow the platform to over 10 million creators across Artlist and Artgrid. My core stack is React and TypeScript — I've owned frontend architecture there: we run micro-frontends with 90%+ test coverage, built a shared design system instead of one-off components, and I led performance work that cut load times by 40%. My working philosophy is that tests ship with the feature, not after the bug report, and that big migrations should be invisible to users. On the side I build my own products — RetinaDesk, SalahClock — so I'm used to owning the why of a product, not just the code. That product-ownership mindset is exactly why Revolut appeals to me, and I'd love to bring it to a product with Revolut's scale and pace."

Practice tip: memorize the 6 bold anchors (10+ years, Artlist 10M+, React/TS, 90% coverage, 40% faster, side products), not the sentences. If you blank, the anchors rebuild the pitch.

“Why Revolut?” — the make-or-break question HR

Reported repeatedly as a screen-killer when answered generically. Formula: specific product/engineering fact + connection to your experience + what you want to build.

"Three reasons. First, the product: Revolut isn't a bank with an app, it's an engineering company doing finance — 60M+ customers, dozens of products from multi-currency accounts to trading, shipped at a pace most banks can't imagine. Second, the engineering culture fits how I already work: you value testing and ownership — my teams held 90%+ coverage across micro-frontends because we treat tests as part of the feature. And third, scale: I've spent a decade making frontend fast and reliable for 10 million users at Artlist; I want my next decade to be at even bigger scale, on a product people trust with their money. Also, honestly — Revolut isn't available in Bangladesh yet, and researching it made me realize I'd love to help build the thing I can't yet use."

That last line turns your limitation into memorable enthusiasm. Verify the current customer number on revolut.com before the call (it was 50M+ in 2024 and has kept growing — say "60M+" only if the site confirms it, otherwise "over 50 million").

“Walk me through your CV / why did you leave (or want to leave)?” HR

Never badmouth. Frame as pull toward Revolut, not push away from anywhere.

"I spent most of a decade at Artlist growing with the platform — from feature work to owning architecture, performance, and testing standards. I'm proud of that. I'm now looking for the next level of scale and challenge, and fintech at Revolut's pace is exactly that. I'm fully available and can start [your notice/availability]."

If asked about freelancing (100+ Upwork/Fiverr clients, 5-star): frame it as range and client-facing communication skills, not divided attention: "it taught me to scope, communicate, and ship without hand-holding."

Salary expectations — your exact script HR

Recruiters often ask this in the first call. Revolut pays by location and level — and your location/entity situation is unresolved, so use that honestly as your anchor:

"Happy to talk numbers. Since compensation at Revolut is location-based and we haven't confirmed yet how the role would be set up for someone based in Bangladesh — remote, entity, or relocation — could you share the band for this role and setup? I'm confident we'll align if there's a mutual fit."

If they insist on a number first, give a researched range for the likely entity, framed as flexible: "Based on my research, senior frontend at Revolut in Europe lands somewhere around €80–130k total depending on country — if the role is set up differently for my location I'm open to calibrating. What matters most to me is the role and the level."

Data point (self-reported, verify)	Figure
Senior SWE total comp (levels.fyi, sparse data)	~$131k (≈$118k base + stock + bonus)
Mid-level SWE total comp (levels.fyi)	~$101k
SWE Spain median (levels.fyi)	~€106k (range ~€87–113k+)
UK senior band (ophyai guide, 2026)	£90–130k base / £120–180k total
One reported Spain senior offer (Blind)	~€82k base + equity
Recency-weighted SWE average (interviewquery)	~$112k base / ~$132k total

⚠️ All crowdsourced/self-reported, small samples, not Bangladesh-adjusted, and could not be independently verified during research. Use as orientation, not gospel. Equity: reportedly options, 4-year vest, 25% year one then monthly.

Never do: give your current/past salary as the anchor, apologize for your number, or say "whatever you think is fair."

“Where are you based? Are you open to relocation?” HR

"I'm based in Bogura, Bangladesh, GMT+6 — which overlaps well with European working hours. I'm set up for serious remote work and have worked async with distributed teams for years. I'm also genuinely open to discussing relocation if the role calls for it — I'd just want to understand the options. How is this role set up?"

Decide before the call what's actually true for you about relocation (open / open-with-family-considerations / not open) so you don't improvise a life decision under pressure. Any honest answer is fine; a flustered one isn't.

“What's your notice period / when can you start?” HR

Have the real number ready. If you're available now:

"I can start quickly — within [X weeks]. I'd just want [any real constraint] accounted for."

“Tell me about a time you worked under pressure” HR

Reported as a common screen question. Use STAR story #7 (deadline story, ⭐ tab). Keep it 60–90 seconds, end with the number.

“What do you know about Revolut?” HR

Your 3-fact answer lives in the 🏛️ tab. Don't recite ten facts — three good ones with a personal connection beat a Wikipedia dump.

“Do you have experience with fintech?” — handling the gap RISK

You don't have fintech on the CV. Bridge, don't apologize:

"Not banking specifically, but the hard parts transfer directly: at Artlist scale, correctness and trust were non-negotiable — payments and subscriptions flowed through our frontend, mistakes cost real money, and that's why I hold the bar of 90%+ test coverage and invisible migrations. Fintech raises the stakes further, which honestly is what attracts me — I'd rather work where quality engineering matters most. And E-Bill, one of my side projects, is billing-domain work I own end to end."

Scenario-based technical questions

In a recruiter screen these are talk-through questions, not live coding. The recruiter checks: does this person speak from experience, with reasoning? Structure every answer as context → decision → why → result. 60–90 seconds each.

Architecture (their explicit focus)

“Describe the architecture of a project you've worked on” TECH

"At Artlist we moved to a micro-frontend architecture as the platform and teams grew. The why: independent deployability — teams shipping search, player, and checkout couldn't be blocked by each other's release trains. We shared a design system so the seams were invisible to users, kept contracts between MFEs thin and typed, and enforced 90%+ test coverage per MFE so integration confidence didn't depend on manual QA. Trade-off we accepted: more infra complexity and bundle-duplication risk, which we managed with shared dependencies and performance budgets. Result: teams shipped independently and we cut load times 40% during the same period."

Be ready for the follow-up "what would you do differently?" — have one honest answer (e.g., "invest in the shared tooling/contract layer earlier; we paid integration tax before we standardized").

“How do you decide on state management?” TECH

"I start from the principle that most 'state problems' are actually server-cache problems — so data fetching goes through a query layer (React Query / SWR pattern) with caching and invalidation, not a global store. Truly global client state — auth, theme, feature flags — gets small dedicated stores or context. Local state stays local. I reach for heavier stores only when there's complex, shared, client-owned state, and I always ask: who owns this data, and how does it stay in sync with the server?"

“How would you keep a large frontend codebase maintainable?” TECH

Your four pillars, all backed by your CV: (1) design system over one-off components — consistency is architecture; (2) strict TypeScript at the boundaries — typed API contracts catch drift at compile time; (3) tests ship with the feature — 90%+ coverage isn't a metric goal, it's what lets you refactor fearlessly; (4) module boundaries that match team boundaries (micro-frontends when scale demands it).

“Tell me about a major migration you handled” TECH

Use STAR story #4. Key phrase from your own philosophy: "migrations should be transparent to users" — strangler-fig pattern, feature flags, incremental rollout, metrics watched at every step, rollback plan. Recruiters love hearing "rollback plan."

Testing (their explicit focus — and your superpower)

“What's your approach to testing?” TECH

"My rule is that tests come with the feature, not after the bug report. Concretely: unit tests for logic, React Testing Library for components — testing behavior users see, not implementation details — contract/integration tests at API boundaries, and a thin layer of E2E (Playwright/Cypress) for critical flows like checkout. We held 90%+ coverage across micro-frontends, but I care less about the number than about what it buys: the confidence to refactor and ship fast. Coverage is a floor, not a target."

If asked "isn't that slow?": "The opposite — it's what makes speed sustainable. Untested code is fast for a week and slow forever after."

“How do you decide what NOT to test?” TECH

Shows judgment: don't test implementation details (breaks on refactor), don't duplicate the type system's work, don't E2E everything (slow, flaky). Prioritize by risk: money paths and data-loss paths get the most layers.

React & JavaScript

“How did you make an app faster?” (their 40% question) TECH

"We treated page weight as a feature. The 40% load-time win came from measuring first — Core Web Vitals in the field, not just Lighthouse — then attacking the biggest costs: code-splitting by route and interaction, image optimization, trimming and deduplicating dependencies across micro-frontends, caching, and moving work off the critical path. The key discipline was a performance budget in CI so wins didn't erode."

Know your real specifics — replace/extend with what you actually did. The shape (measure → biggest lever → guard the win) is what they're grading.

“Explain the JavaScript event loop” (asked in Revolut FE interviews) TECH

The 30-second version: JS is single-threaded; the event loop pulls work from queues when the call stack is empty. Microtasks (promise callbacks, queueMicrotask) run to completion after each task, before the next macrotask (setTimeout, I/O) and before rendering. That's why a promise chain resolves before a setTimeout(0), and why long tasks block paint — the root of most UI jank. Practical use: break long work up (yield to the loop), keep the main thread free for input.

“Why TypeScript? When has it saved you?” TECH

Don't say "it catches typos." Say: typed API contracts catch backend/frontend drift at compile time; discriminated unions make illegal UI states unrepresentable (loading/error/success can't be mixed); refactors across a 10-year codebase become mechanical instead of terrifying. Have one concrete "TS caught this before prod" story ready.

“How do you handle errors and edge cases in a React app?” TECH

Error boundaries per feature region (one widget failing shouldn't kill the page), typed error states in the data layer (every fetch has loading/error/empty designed, not just success), user-facing fallbacks with retry, and reporting (Sentry-style) so errors are seen, not just caught. In fintech framing: "an error the user can't recover from is a support ticket; an error we don't observe is a risk."

Product ownership (their explicit focus)

“Tell me about a technical decision you made and the WHY behind it” CULTURE

This is the "Product Ownership" test from the email. Pick ONE decision (design system, micro-frontends, or a migration) and narrate: the user/business problem → options considered → trade-offs → decision → measured outcome → what you'd change now. That last part matters: owning a decision includes owning its flaws.

"When we kept rebuilding similar components per team, I pushed for a design system. The why wasn't aesthetics — it was speed and trust: every one-off component is a future bug and an inconsistent user experience. The trade-off was upfront cost and governance overhead. We measured adoption and time-to-ship for new features, both moved the right way. What I'd do differently: version it properly from day one — our first breaking change was more painful than it needed to be."

“Have you ever pushed back on a product requirement?” CULTURE

Use STAR #6. Formula they want: you disagreed with data or user impact, not taste; you committed fully once decided; the outcome taught something. "Disagree and commit" is the phrase to embody (no need to say it like a buzzword).

Your STAR story bank

Situation (1 sentence) → Task (1 sentence) → Action (3–4 sentences, "I" not "we" for your parts) → Result (number!). Target 60–90 seconds spoken. The skeletons below are built from your CV — fill the [brackets] with your real details, then practice out loud. One story can serve many questions; the mapping table shows how.

Coverage map — 8 stories cover ~every behavioral question

If they ask about…	Use story
Impact / achievement you're proud of / performance	#1 Performance
Quality / testing / preventing bugs	#2 Testing culture
Architecture / influence / long-term thinking	#3 Design system or #5 Micro-frontends
Risk / complex project / planning	#4 Invisible migration
Disagreement / conflict / pushing back	#6 Pushback
Pressure / deadline / prioritization	#7 Deadline
Failure / mistake / what you learned	#8 Mistake
Ownership / initiative / building products	#9 Side project (bonus)

#1 — The 40% performance win SIGNATURE

S: "Artlist serves 10M+ creators; load times were hurting [conversion/engagement — your real metric]."
T: "I [led/owned] the effort to make the platform measurably faster."
A: "I started with field data, not guesses — [your real tools]. Biggest levers turned out to be [code splitting / images / dependency weight / …]. I [your 2–3 concrete actions]. Then I locked the wins in with a performance budget in CI."
R: "40% faster load times, and [business effect if you have one]. The budget meant it stayed fast."

#2 — 90% coverage across micro-frontends SIGNATURE

S: "As we split into micro-frontends, integration bugs and QA load were the risk."
T: "Make quality automatic instead of heroic."
A: "I championed 'tests come with the feature, not after the bug report' — [how you made it stick: PR gates? templates? pairing? review culture?]. RTL for behavior, contract tests at MFE boundaries, E2E only for money paths."
R: "90%+ coverage held across micro-frontends, [fewer regressions / faster releases / fearless refactors — your real outcome]."

#3 — Design system over one-off components

S: "Teams were rebuilding similar UI; inconsistency and duplicated bugs."
T: "Establish a shared design system."
A: "[Your role: proposed? built core? governance model? tokens? docs?] The hard part was adoption — [how you won teams over]."
R: "[Adoption %, time-to-ship change, consistency win]. Lesson I own: version it from day one."

#4 — The invisible migration

S: "[The real migration: framework upgrade? MFE split? Next.js? — pick your biggest]."
T: "Migrate with zero user-visible disruption on a 10M-user platform."
A: "Strangler-fig / incremental: [flags, parallel run, metrics watched, rollback plan — your specifics]."
R: "Shipped over [timeframe] with [zero downtime / no support-ticket spike]. Users never noticed — which was the whole point."

#5 — Micro-frontends at scale

S: "Growing teams blocked on each other's releases."
T: "Enable independent shipping without fragmenting UX."
A: "[Your architecture decisions: boundaries, shared deps, contracts, the design-system glue]."
R: "[Deploy frequency / team autonomy outcome]. Honest trade-off I'd flag: [infra complexity / bundle discipline]."

#6 — Pushing back (conflict)

Pick a real disagreement — with PM, designer, or engineer. Crucial shape: you argued from data/user impact, you stayed respectful, and either (a) you were right and the metric proved it, or (b) you were overruled, committed fully, and learned something. Both endings are strong; a story where you're just right and everyone claps is weaker than one with a real lesson.

[Write yours: S/T/A/R in 4 lines]

#7 — Deadline under pressure

Freelance life gave you plenty of these (100+ clients). Shape: scope was impossible → you cut ruthlessly to what mattered for the user → communicated early, not at the deadline → shipped the core, scheduled the rest. The skill on display is prioritization + communication, not heroic all-nighters (Revolut has enough of those; they hire to reduce them).

[Write yours]

#8 — A mistake you own

Everyone gets this question eventually. Rules: a real mistake (not "I care too much"), caught/fixed by you, followed by a system change so it can't recur — that last part is what separates seniors. Given your philosophy, a great arc is: "the bug that taught me tests come with the feature."

[Write yours]

#9 — Bonus: RetinaDesk / SalahClock (product ownership proof)

When they probe "product ownership," nothing beats "I build and run my own products." Shape: saw a real user problem → decided scope yourself → built, shipped, maintained → real users/feedback. One tight paragraph on RetinaDesk (why it exists, what you learned about users) is a memorable differentiator — most candidates have zero of these.

ADHD tip for stories: don't memorize prose. For each story memorize a 4-word skeleton (e.g., "slow → measured → split → 40%"). Under stress you keep the skeleton even if the words wobble — and the words always come back from the skeleton.

Revolut: the company & how to speak their language

Company snapshot (verify big numbers on revolut.com before the call)

Founded 2015, London, by Nikolay Storonsky & Vlad Yatsenko. Started as a travel FX card, now a global financial "super app".
Customers: passed 50M in late 2024, has continued growing since (check current figure — they publish it proudly).
Products: multi-currency accounts & cards, FX, stock/crypto/commodity trading, savings, credit, insurance, business banking (Revolut Business), Revolut <18 for kids, eSIMs, travel booking. The breadth is the point — a super app.
UK banking licence secured 2024 (restricted, then mobilizing) — a landmark after a long wait; big valuation growth since (reported $45B in 2024, higher in later secondaries — say "one of the most valuable fintechs in the world" and you're safely correct).
Engineering: known for high hiring bar, data-driven decisions, fast shipping, strong internal tooling. Frontend is React/TypeScript territory.

Values — and what each means in an interview answer

Value	What it means	How you show it
Get It Done	Bias to shipping; done > perfect-someday	Stories end with "shipped" + a number, not "we planned to…"
Deviate	Question defaults; 10x over +10%	Your MFE + design-system calls were deviations from "just keep adding code". Say why the default was wrong.
Never Settle	Raise the bar continuously	Performance budgets in CI, coverage as a floor not a trophy — you literally do this.
Think Deeper	First-principles, data over opinions	"I measured before optimizing" / "we argued with data, not taste".
Dream Team	A-players, high ownership, low ego; underperformance isn't carried	Talk about raising others (review culture, test culture you spread) and owning outcomes end-to-end.

Wording of the value set varies by year/page ("Deliver WOW" appears in some versions); the themes above are stable. Don't recite values robotically — embody one per story.

The "app not available in Bangladesh" script

Revolut doesn't operate in Bangladesh, so you can't just sign up. Do this homework instead, then own it:

Watch 2–3 recent YouTube walkthroughs of the app (search "Revolut app tour 2026") — know the home screen, cards, trading, and payments flows visually.
Read the Revolut blog/newsroom for 2 recent launches (5 minutes) so you can name something current.
Skim app-store reviews to know what users praise (speed, UX) and complain about (support, account freezes) — knowing the criticism too reads as "thinks deeper."

"Revolut isn't available in Bangladesh yet, so I couldn't open an account — but I've studied the product through walkthroughs and your launches, and [specific observation, e.g., 'the way trading, FX, and everyday spending live one tap apart is a frontend architecture achievement as much as a product one']. Frankly, working on a product I'm waiting to be able to use is part of the appeal."

Culture intensity — eyes open: Revolut's pace is real: candidate and employee reports consistently describe high expectations, metrics-driven performance management, and demanding workloads. If asked "are you comfortable with a high-intensity environment?", your honest bridge: a decade of product work plus 100+ freelance clients means you're self-managing and delivery-driven — and you keep quality high under speed because of your test discipline. (Also genuinely reflect before later rounds: it's a real trade-off, and it's okay to probe it in YOUR questions.)

Rapid-fire drill

The screen may include a quick tech-theory checklist (reported by past FE candidates). These are 20–40 second answers. Click to reveal — try answering out loud first. One pass Tue, shaky-only pass Wed.

JavaScript

Event loop: why does a resolved promise's .then run before setTimeout(fn, 0)?

Promise callbacks are microtasks; setTimeout schedules a macrotask. After the current stack empties, the entire microtask queue drains before the next macrotask (and before rendering). Practical: heavy microtask chains can also block paint — yield with setTimeout/scheduler when doing long work.

What's a closure, and one real place you rely on them?

A function retaining access to its defining scope after that scope exits. Real uses: React hooks (every render's handlers close over that render's props/state — also the source of "stale closure" bugs in useEffect), debounce/throttle utilities, module patterns.

var vs let/const; hoisting in one breath

var: function-scoped, hoisted initialized-as-undefined. let/const: block-scoped, hoisted but in the temporal dead zone until declaration. const forbids reassignment (not mutation). Modern code: const by default, let when reassigning, var never.

Promises vs async/await — what's actually different?

Nothing at runtime — async/await is syntax over promises. Differences that matter: readability of sequential logic, try/catch error handling, and the foot-gun of accidentally serializing independent work (use Promise.all for parallel). Know Promise.all vs allSettled vs race.

How does `this` get bound?

By call-site: method call → the object; plain call → undefined (strict); new → the instance; call/apply/bind → explicit. Arrow functions don't bind their own `this` — they inherit lexically, which is why they're the default for callbacks.

Debounce vs throttle — when each?

Debounce: fire after quiet period — search-as-you-type, resize end. Throttle: fire at most every N ms — scroll handlers, drag position updates. Both keep the main thread and network sane.

React

What actually happens when state updates? (reconciliation)

React re-runs the component, produces a new element tree, diffs it against the previous one (keys identify list items), and commits minimal DOM mutations. Re-render ≠ DOM update. Since React 18, updates are batched and concurrent features let React interrupt low-priority renders.

Why do list keys matter — and why is index a bad key?

Keys tell the diff which items are *the same* across renders. Index keys lie when the list reorders/inserts — state and DOM get matched to the wrong item (classic: input text jumping rows). Use stable IDs.

useMemo/useCallback — when, and when NOT?

They stabilize references so memoized children / effect deps don't churn. Use for expensive computation or referential stability crossing a memo boundary. Don't sprinkle by default — they add cost and noise. Measure first (Profiler), memo second. (React 19's compiler automates much of this — mentioning that signals currency.)

Context vs a state library?

Context is dependency injection, not a state manager — every consumer re-renders on value change. Fine for slow-changing globals (theme, auth). For frequently-updating shared state use a store with selective subscription (Zustand/Redux/Jotai), and for server data a query cache — most "global state" is really server cache.

Controlled vs uncontrolled inputs?

Controlled: React state is the source of truth (validation, formatting — right for fintech forms). Uncontrolled: DOM holds it, read via ref (cheaper for simple/perf-hot forms; form libraries like react-hook-form use this under the hood).

What are error boundaries and their limits?

Components that catch render-phase errors in their subtree and show a fallback. They don't catch async/event-handler errors — those need try/catch + reporting. Place per feature region so one widget can't blank the page.

SSR / Next.js — why, and what changed lately?

SSR: faster first paint + SEO; hydration attaches interactivity. Next.js adds routing, data fetching, ISR. Recent shift: React Server Components — components that run only server-side, shrinking client JS; client components opt in with "use client". Trade-off talk: caching complexity, infra weight.

TypeScript

any vs unknown?

any opts out of checking entirely (contagiously). unknown is the safe top type — you must narrow before use. Rule: API boundaries return unknown (then validate/narrow, e.g. zod), any is a code smell.

Discriminated unions — your favorite pattern, why?

A shared literal field ("status") lets the compiler narrow: {status:'loading'} | {status:'error', error} | {status:'success', data}. Illegal states (success without data) become unrepresentable, and switch exhaustiveness (never check) catches unhandled cases at compile time. Perfect for async UI state.

Generics in one practical example

A typed fetch wrapper: async function get<T>(url: string): Promise<T> — one function, every call site fully typed. Or a generic usePagination<T>(items: T[]) hook. The point: write logic once, keep types flowing through.

type vs interface?

Mostly interchangeable for objects. interface: declaration merging, extends — conventional for public/object shapes. type: unions, intersections, mapped/conditional types, primitives. Team consistency matters more than the choice; know both.

Name 4 utility types you actually use

Partial<T> (update payloads), Pick/Omit (deriving component props from domain types), Record<K,V> (lookup maps), ReturnType<typeof fn> (keeping types DRY with implementations). Bonus: Readonly, Awaited.

Testing

Testing pyramid vs trophy — your take?

Pyramid: many unit, fewer integration, few E2E. Trophy (Kent C. Dodds): weight integration tests most — they catch real bugs at reasonable cost. My practice: RTL integration-style component tests as the core, units for pure logic, E2E only for critical money paths. Confidence per maintenance-dollar is the metric.

What does React Testing Library test, philosophically?

Behavior a user perceives — queries by role/label/text, interactions via userEvent — not implementation details (state names, instance methods). Result: refactors don't break tests unless behavior actually changed. "The more your tests resemble how software is used, the more confidence they give."

What do you mock, and what do you refuse to mock?

Mock the network boundary (MSW — mock service worker — so code exercises real fetch paths), time, and randomness. Avoid mocking your own modules — that welds tests to implementation. Refuse to mock so much that the test proves nothing.

How do you keep E2E tests from being flaky?

Few and focused (critical flows), test-ids or role queries, auto-waiting assertions (Playwright), isolated seeded data per run, retries as signal-not-bandage — a retried-green test gets investigated. Quarantine lane so flakes don't block deploys while being fixed.

Architecture & performance

Micro-frontends: 30-second pitch + biggest downside

Split the frontend along team/domain boundaries so teams deploy independently — org scalability. Downsides I manage: dependency duplication (shared deps/module federation), UX fragmentation (design system as the glue), and cross-MFE contracts (thin, typed, versioned). Not for small teams — it's a solution to an org problem, not a code problem.

Core Web Vitals — name them and one fix each

LCP (largest contentful paint ≤2.5s): preload hero image/font, cut render-blocking. INP (interaction to next paint ≤200ms): break long tasks, less main-thread JS. CLS (layout shift ≤0.1): reserve space for images/ads/fonts. Measure in the field (real users), not just lab.

How do you stop a fast site from getting slow again?

Performance budgets enforced in CI (bundle size, LCP thresholds), field monitoring with alerts, and treating page weight as a feature in review — a PR that adds 200KB needs the same justification as one that adds a database. Culture beats one-off heroics.

How would you architect a dashboard showing live financial data?

(Fintech-flavored, worth rehearsing.) WebSocket/SSE for streams with reconnect + backoff; server cache (React Query) for reference data; virtualized lists for large tables; optimistic UI only where reversible — money mutations get confirmed-state UI; discriminated-union state so stale/live/error are visually distinct; error boundaries per widget; number formatting via Intl. Test the reconnect and error paths hardest.

AI-assisted development (increasingly asked in 2026)

How do you use AI tools without shipping slop?

It's on your CV, so have a crisp take: AI accelerates the typing, not the judgment — I use it for scaffolding, tests, migrations, and exploring unfamiliar APIs, but architecture, review, and the "why" stay human. My test discipline is the safety net that makes AI speed safe: generated code passes the same coverage bar as hand-written.

Your 5–7 minutes: questions to ask Deniz

Pick 2–3. Asking about the process and team reads as serious; asking only about perks reads as not. The starred ones also get you information you genuinely need.

★ Must-ask (logistics you need)

"How is this role set up for someone based in Bangladesh — remote-from-anywhere, tied to an entity, or relocation? What have you done for candidates in similar situations?"
"What do the next stages look like for this exact role, and what's the typical timeline?" (Confirms the pipeline; shows you plan.)

Strong signals

"What does the frontend stack look like on this team — and what's the biggest frontend challenge they're tackling this year?"
"How do frontend engineers at Revolut influence product decisions? The role emphasizes product ownership — what does that look like day to day?"
"How is engineering quality maintained at Revolut's shipping pace — what's the testing and review culture like?" (This one lets YOU shine: whatever the answer, you can connect it to your 90% coverage practice.)
"What separates people who thrive at Revolut in their first six months from those who struggle?"

Skip for now

Salary detail beyond the band (you'll negotiate later, from strength), vacation/perks, "is work-life balance bad?" (probe intensity via the "thrive in six months" question instead — same info, better look).

Close the call like a pro: "Thanks Deniz — this confirmed my interest. What are the next steps, and is there anything else you need from me?" Then send a short thank-you email the same day (template in ✅ Day-Of).

ADHD & panic toolkit

You told me two things: ADHD, and panic sometimes. Neither is a weakness in this interview — unmanaged surprise is. So we remove surprise.

Reframe first

This is a conversation with a recruiter who wants you to succeed — Deniz gets credit for finding good candidates. They are on your side.
A screening call is pass/fail on basics, not a genius test. You have 10+ years of receipts. The bar here is "credible, clear, keen" — you exceed it.
Worst realistic case: you don't advance, you've lost 30 minutes and gained a rehearsal. Your life in Bogura is identical either way. Truly.

Panic protocol — practice ONCE before the call so it's automatic

Physiological sigh (fastest known downshift): two quick inhales through the nose, one long slow exhale through the mouth. Repeat ×3. Usable on camera — it looks like a thoughtful breath.
Buy time with a prepared phrase (memorize both):
"That's a good question — give me a second to pick the best example." "Let me think about that for a moment, I want to give you a real answer rather than a generic one." Interviewers consistently rate a 5-second pause HIGHER than instant rambling. Silence feels 10× longer to you than to them.
Ground with your skeleton: glance at your cheat sheet (totally legitimate on a video call), find the 4-word story skeleton, start talking from the skeleton.
If you lose the thread mid-answer: "Let me land that point simply: the result was [number]." Ending on the result rescues any wandering answer.
If you genuinely blank: "I'm blanking on the best example — can we come back to that one?" Recruiters grant this without a second thought. Coming back to it later shows composure, not weakness.

ADHD-specific tactics for the call

Externalize your memory. Cheat sheet printed or on a second screen: pitch anchors, 8 story skeletons, salary line, your 3 questions. Glancing at notes on a call is normal professional behavior.
The 60–90 second rule fights over-talking. If you tend to spiral into detail: answer, hit the result, then ask — "want me to go deeper on any part?" That hands the steering wheel back and reads as considerate, not scattered.
One tab open. Phone face-down in another room. Remove every notification source; a single Slack ping can cost you a whole thought.
Body doubles the brain: sit at a proper desk, shoes on, water within reach. Sounds silly; works.
Time distortion insurance: the call is 30 min + possible 10–15 extension. Block 90 minutes so there is zero clock anxiety. Set one silent alarm for 10 minutes before.
Hyperfocus is your superpower here: when the tech questions start, that's YOUR territory — let yourself enjoy it. Enthusiasm is the most under-rated interview signal.
Don't disclose ADHD in a screening call. Not because it's shameful — because a 30-min screen is the wrong venue and it can't be processed fairly there. Accommodations conversations belong post-offer if you want them.

The night before & morning of

Stop preparing by Wed evening. Cramming past that point trades calm for marginal facts — bad trade.
Sleep matters more than one more drill pass. Screens off a bit earlier than usual.
Morning: normal routine, real food, a walk if you can. One cheat-sheet read. One physiological-sigh practice. Done.
2:00 PM is a good slot for you — no early-morning fog. Eat lunch by 1:00 so you're not hungry or heavy.

If panic hits mid-call anyway: it passes in 60–90 seconds if you don't fight it. Sigh-breathe, use a buy-time phrase, look at the skeleton, keep your voice slow. You have survived every previous panic at a 100% rate. This one too.

Day-of checklist — Thursday, July 9

Confirm the time zone. Open the calendar invite and verify it says 2:00 PM Dhaka (GMT+6). (2:00 PM Dhaka = 9:00 AM London / 10:00 AM most of EU.) Mismatched time zones kill more interviews than hard questions.
Google Meet link opens; camera + mic tested in Meet itself (meet.google.com has a green-room check).
Laptop plugged in. Browser: one window, the Meet tab + cheat sheet tab only. All notifications off (macOS: Focus mode).
Backup plan ready: phone charged with Meet app installed + mobile hotspot tested, in case power/internet drops (load-shedding insurance). If it drops mid-call: rejoin from phone, then a one-line apology and move on — handled calmly, it's a non-event.
Light on your face (window in front of you, not behind). Tidy-enough background or blur.
Cheat sheet printed or on screen. Water. Phone (other one) in another room.
90-minute calendar block. Bathroom before. Joined the Meet 3–4 minutes early.
Smile when you say hello. First 10 seconds set the tone, and warmth is memorable.

During-call micro-rules

Answers: 60–90 seconds, end on a number, offer to go deeper.
Write down each question keyword as it's asked (paper next to you) — kills the "wait, what was the question?" spiral.
It's a conversation: brief acknowledgments ("that makes sense", "good question") keep it human.
Before goodbye: next steps + timeline + "anything else you need from me?"

Same-day follow-up email (send within a few hours)

Subject: Thank you — Frontend Engineer screening call

Hi Deniz,

Thank you for the conversation today — it confirmed my enthusiasm for the Frontend Engineer role. The emphasis on [something they actually said — testing culture / product ownership / the team's current challenge] maps directly to how I've worked for the past decade at Artlist, and I'd be excited to bring that to Revolut.

Looking forward to the next steps you outlined. If anything else is needed from my side, I'm happy to provide it.

Best regards,
Parish Khan

Replace the bracket with a real detail from the call — that one line is what makes it land.

If you need to reschedule (illness, power emergency)

Email as early as humanly possible, propose 2–3 concrete alternative slots, keep it to two sentences. Recruiters reschedule constantly; late no-shows are the only real sin.

One-page cheat sheet

Keep this open (or printed) during the call. Printing this page prints only the sheet.

PITCH ANCHORS (90 sec)

10+ yrs · Artlist ~decade · 10M+ creators (Artlist + Artgrid)
React + TypeScript · frontend architecture owner
90%+ test coverage across micro-frontends — "tests come with the feature, not after the bug report"
40% faster load times · page weight is a feature
Design system > one-off components · migrations invisible to users
Own products: RetinaDesk, SalahClock, E-Bill → product ownership

STORY SKELETONS

#1 PERF: slow → measured → split/optimized → 40% + CI budget
#2 TEST: MFE risk → tests-with-feature culture → 90%+ held
#3 DESIGN SYS: duplication → shared system → adoption → version-from-day-1 lesson
#4 MIGRATION: [yours] → flags/incremental/rollback → zero user impact
#5 MFE: teams blocked → split by domain → independent deploys
#6 PUSHBACK: [yours] — data not taste → committed → lesson
#7 DEADLINE: [yours] — cut scope → communicated early → shipped core
#8 MISTAKE: [yours] — owned it → system change so it can't recur

WHY REVOLUT (3 beats)

Engineering company doing finance · 50M+ customers · super-app breadth
Their testing/ownership culture = how I already work
Next scale level + "want to build the product I can't yet use in Bangladesh"

SALARY LINE

"Location-based comp + my setup unconfirmed → could you share the band?" If pushed: "research says senior FE Europe ≈ €80–130k total; open to calibrating by location."

MY QUESTIONS

Role setup for Bangladesh: remote / entity / relocation?
Next stages + timeline for this exact role?
Biggest frontend challenge this year / what does product ownership look like day-to-day?

PANIC PROTOCOL

Double-inhale, long exhale ×3 · "Good question — let me pick the best example."
Lost? → "The result was [number]." · Blank? → "Can we come back to that one?"
Pause > ramble. Silence feels 10× longer to you than to them.

MICRO-RULES

60–90 sec answers · end on a number · "want me to go deeper?"
Note each question keyword on paper · smile at hello · confirm next steps at close

Sources & honesty notes

Read this once: Interview-process intel is inherently crowdsourced — candidate reports, salary self-reports, and third-party guides. During research, automated cross-verification couldn't complete (usage limits), so treat specifics (stage order, salary figures, timelines) as well-sourced orientation, not guarantees. Your single best source of truth is Deniz — the pipeline questions in the ❓ tab exist precisely to confirm your track.

Primary references used

Taro — Revolut Frontend Engineer interview experience (Barcelona, 2025) — first-hand FE pipeline: recruiter call → pairing (React + authenticated API) → FE system design → team fit; event-loop question reported.
Dataford — Revolut SWE interview guide — 3–5 week / 4-round structure, TDD emphasis in live coding, "skipping tests fails candidates," behavioral themes.
OphyAI — Revolut interview process 2026 — recruiter-screen expectations ("why Revolut" specificity), take-home format, failure reasons, UK comp bands.
Interview Query — Revolut guide + SWE guide — screening call content, comp averages, 2–4 week timeline.
levels.fyi — Revolut SWE salaries — self-reported comp (sparse; FE-specific page is masked), equity vesting notes.
Blind — Revolut posts — HackerRank reports, difficulty sentiment, location-based comp anecdotes, culture-intensity complaints.
Glassdoor — Revolut Frontend Developer interviews — recruiter call described as "general info + CV questions"; ~15-min tech-theory checklist reports. (Glassdoor blocks automated reading — skim it manually if you want raw reports.)
Revolut — official culture page (values wording) and revolut.com — verify current customer count before the call.
STAR method — the exact page Deniz linked you — read it once; they told you they'll grade with it.

What I could NOT confirm — ask Deniz instead

Whether YOUR track includes a HackerRank/take-home stage (varies by team).
How Revolut engages candidates based in Bangladesh (entity/remote/relocation).
Current comp band for this specific role and location.
Exact number of technical rounds for this role.