Make correctness visible. Show what happens when a banking request arrives twice, times out or competes with another update. A small solution with explicit rules gives you concrete tradeoffs to discuss.
The Investments & Savings posting names Kotlin, Kafka, AWS and container tooling. Its interview list supplies the stages below. Use the practice prompts to explain state changes and test evolving requirements; they are editorial exercises.
Prepare for collaboration as well as correctness. Rehearse a coding task with another person adding a constraint halfway through. Explain the invariant, preserve useful tests and describe the trade-off before changing the implementation.
Follow one transfer request. A customer initiates it, a service records it and another system confirms an outcome. Ask:
- Identity: Which customer and request does this action belong to?
- State: Is the result pending, accepted, settled or rejected?
- Evidence: What durable record proves the transition happened?
These are exercise assumptions, not N26’s internal design.
Recruiter conversation
officialThe posting begins with a recruiter screen.
What to demonstrate
- Relevance: Connect one backend project to a clear user problem.
- Scope: Explain what you owned, including delivery or support.
How to prepare
- Prepare a ninety-second project introduction.
- List the team, level and working constraints you need to understand.
Codility assessment
officialA Codility test appears in the official sequence.
- Format
- Codility test
What to demonstrate
- Correctness: Handle empty input, duplicates and boundary values.
- Efficiency: Explain the cost of the operations you choose.
How to prepare
- Solve a small array or map problem without relying on hidden assumptions.
- Run your own failing cases before submitting the happy path.
Pair coding
officialThe next listed stage is pair coding.
- Format
- Pair coding
What to demonstrate
- Communication: Describe the invariant before changing the implementation.
- Adaptation: Incorporate a new requirement without discarding working tests.
How to prepare
- Rehearse with someone who adds one constraint midway through.
- Pause to explain a failing test before attempting a fix.
System design
officialSystems design is listed separately from coding.
What to demonstrate
- Boundaries: Separate durable state from messages and external side effects.
- Recovery: Identify what a client can do after losing a response.
How to prepare
- Sketch the transfer exercise and walk through two crash points.
- Choose one latency measure and one correctness measure.
Behavioral discussion
officialThe role’s published list ends with a behavioral interview.
What to demonstrate
- Judgment: Describe an alternative you rejected and the evidence behind that choice.
- Ownership: Explain how you helped a stalled project move forward.
How to prepare
- Prepare stories about a release, a disagreement and an incident.
- State your individual contribution without taking credit for the whole team.
PracHub editorial advice for the preparation topics above.
Saying a timeout means failure
Separate uncertainty from rejection. A lost response does not prove that a transaction failed. Offer a stable request ID and a way to inspect its durable status.
Optimizing before defining the window
Write the boundary rule. For a rolling statistic, decide whether events exactly at the lower bound count. Test that boundary before discussing performance.
Promising exactly-once behavior without a boundary
Name what is protected. A unique database key can prevent duplicate records; it does not automatically prevent a second external payment.
Going silent during pair coding
Make decisions audible. Explain your next check, accept corrections and summarize what changed. A collaborator should be able to follow the solution.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Maintain a rolling transaction total
Task: Given events in nondecreasing integer-second order, maintain the sum of signed minor-unit amounts in (now − window, now]. Reject nonpositive window sizes. Explain the memory bound.
Approach
- Expire first: Remove events at or before the lower bound.
- Track the sum: Add each arrival once and subtract it once on expiry.
Worked solution 35 min
- Invariant: The deque contains exactly the events inside the current window. The running sum equals those events’ amounts.
- Cost: Each event enters and leaves once, giving amortized O(1) work per arrival and O(k) memory for k retained events.
- Limit: This teaching implementation assumes one ordered stream; it is not a distributed aggregation service.
from collections import deque
class RollingTotal:
def __init__(self, window):
if type(window) is not int or window <= 0:
raise ValueError("positive integer window required")
self.window, self.events, self.total = window, deque(), 0
self.last = None
def add(self, now, amount):
if type(now) is not int or type(amount) is not int:
raise ValueError("integer timestamp and minor units required")
if self.last is not None and now < self.last:
raise ValueError("events must be ordered")
while self.events and self.events[0][0] <= now - self.window:
self.total -= self.events.popleft()[1]
self.events.append((now, amount))
self.total += amount
self.last = now
return self.total
r = RollingTotal(10)
assert [r.add(t, a) for t, a in [(0,100),(5,-20),(10,7)]] == [100,80,-13]
Scroll sideways to view long lines.
Follow-up
- How would late or out-of-order events change the data structure?
Find the first unique reference
Task: Return the first reference that appears exactly once in an ordered list. Preserve input order and return None when every reference repeats.
Approach
- Count: Build frequencies in one pass.
- Select: Scan the original sequence for the earliest count of one.
Follow-up
- What changes when the input is an unbounded stream?
Merge overlapping maintenance windows
Task: Merge half-open intervals on one service’s timeline. State whether touching windows should merge; invalid intervals must be rejected.
Approach
- Sort: Order by start, then end.
- Extend: Merge against only the last output interval; document your adjacency policy.
Follow-up
- How would you keep separate results for different regions?
Count recent transaction notifications
Given nondecreasing integer timestamps, count events in (now − 10, now]. Each event counts once. The clock can advance without a new event; an event at the lower boundary has expired.
Which events still count?
The left boundary is excluded; the right boundary is included. Drag past an event to see it enter, then expire 10 seconds later.
See the event values
- At 0s: +1 — expired
- At 5s: +1 — in window
- At 10s: +1 — in window
- At 14s: +1 — not arrived
- At 19s: +1 — not arrived
Synthetic transaction notifications at 0, 5, 10, 14 and 19 seconds, each with weight one. Drag the clock: at 10 seconds only 5 and 10 count; at 30 seconds none remain. The lower boundary is excluded.
Approach
- Keep a deque and remove timestamps at or before now − 10 before reporting a count. Equal timestamps represent distinct events unless a separate event ID says otherwise.
- Expose both add(time) and count(now). Reject a backward clock and document the O(k) retained-event memory cost. Each event is inserted and removed once, giving amortized O(1) updates.
Follow-up
- How would late arrivals, multiple producers or a per-customer limit change the contract?
Calculate posted movement by account
Task: For a UTC day, report each account and currency’s net posted amount, including accounts without movements. Amounts are signed integer minor units.
Approach
- Filter within aggregation: Exclude pending events and use a half-open day.
- Keep empty accounts: Left join totals onto the account table.
Worked solution 35 min
- Model: One account row fixes its currency; movement amounts use that currency’s minor units.
- Query: Aggregate before joining. UTC boundaries exclude the following midnight and pending events.
- Verify: An account with no qualifying movements must return zero, not disappear.
CREATE TABLE accounts (id TEXT PRIMARY KEY, currency TEXT);
CREATE TABLE movements (account_id TEXT, amount_minor INTEGER, status TEXT, at TEXT);
INSERT INTO accounts VALUES ('a','EUR'),('b','GBP');
INSERT INTO movements VALUES
('a',100,'posted','2026-09-01T00:00:00Z'),
('a',-30,'posted','2026-09-01T12:00:00Z'),
('a',500,'pending','2026-09-01T13:00:00Z'),
('b',900,'posted','2026-09-02T00:00:00Z');
WITH totals AS (
SELECT account_id, SUM(amount_minor) AS net
FROM movements
WHERE status='posted' AND at >= '2026-09-01T00:00:00Z'
AND at < '2026-09-02T00:00:00Z'
GROUP BY account_id
)
SELECT a.id, a.currency, COALESCE(t.net,0)
FROM accounts a LEFT JOIN totals t ON t.account_id=a.id
ORDER BY a.id;
Scroll sideways to view long lines.
Follow-up
- How would you support a customer’s local reporting day?
Find transfers waiting for settlement
Task: Find accepted transfers with no settlement event before a fixed cutoff. Multiple status events must not duplicate a transfer in the result.
Approach
- Define identity: Match on the durable transfer key.
- Use NOT EXISTS: Test absence of settlement rather than joining every event.
Follow-up
- How would reversals affect the meaning of settled?
Design a retry-safe transfer request
Task: Design an API that accepts a transfer request, survives a lost response and coordinates with an external processor. Do not assume the processor guarantees idempotency.
Approach
- Persist intent: Record the authenticated account, request key and input fingerprint.
- Reconcile uncertainty: Represent pending external outcomes explicitly.
Worked solution 50 min
- Accept: Authorize the account, validate amount and currency, and persist a unique request key with a fingerprint.
- Commit: Store the transfer intent and an outbox record together. A repeated matching key returns the same operation.
- Dispatch: Retry delivery safely. Use a processor idempotency key if supported; otherwise reconcile an uncertain attempt before resending.
- Recover: Keep unknown outcomes pending and expose a status endpoint. Do not convert uncertainty into a second transfer.
Follow-up
- What happens when the processor succeeds but your status update fails?
Deliver a transaction status feed
Task: Let a mobile client reconnect and catch up on transaction status changes. Customers must only see their own events, including when a cache is involved.
Approach
- Authorize: Scope every subscription and history query to the customer.
- Resume: Use a durable cursor with a recovery path for expired history.
Follow-up
- When should the client refresh a snapshot instead of replaying events?
Fix a lost update in a balance check
Task: Two concurrent withdrawals both read a balance of 100 and each accept 80. Explain the bug and protect the update without trusting a client-side check.
Approach
- Reproduce: Interleave both reads before either write.
- Make it atomic: Apply the balance condition inside the database update and inspect affected rows.
Worked solution 35 min
- Repair: Move the sufficiency test into the UPDATE. Only a successful affected-row count authorizes the debit.
- Bound the claim: This protects one balance row, not a whole payment workflow. Use a transaction, ledger entries and request deduplication for that.
- Observe: The sequential fixture demonstrates the predicate. Verify concurrent behavior in your production database separately.
CREATE TABLE balances (account_id TEXT PRIMARY KEY, minor INTEGER NOT NULL);
INSERT INTO balances VALUES ('a',100);
UPDATE balances SET minor=minor-80
WHERE account_id='a' AND minor>=80;
SELECT changes();
UPDATE balances SET minor=minor-80
WHERE account_id='a' AND minor>=80;
SELECT changes();
SELECT minor FROM balances WHERE account_id='a';
Scroll sideways to view long lines.
Follow-up
- Which additional constraints are needed for a complete transfer ledger?
Created by PracHub using the role requirements and exercises in this guide. This is a suggested practice schedule, not an N26 recommendation or hiring timeline. Adapt the order and pace to your experience and interview date.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Understand the role
- Read the linked role posting and match three requirements to your own projects.
- Choose the skills you need to refresh before your interview.
Deliverable: A short role-to-project map
02Refresh coding fundamentals
- Solve the unique-reference prompt and test empty input and duplicates.
- Explain time and space complexity aloud.
Deliverable: A tested solution and a clear explanation
Practice prompt ↗03Practise collaborative coding
- Work through the rolling-total prompt with a partner, or narrate your decisions aloud.
- Add a boundary case and explain how it changes your implementation.
Deliverable: An invariant, tests and notes on one improvement
Practice prompt ↗04Reason about system failures
- Sketch the transfer API exercise.
- Walk through a lost response and a repeated request; explain how you would recover.
Deliverable: A design sketch with explicit failure paths
Practice prompt ↗05Debug and review data handling
- Trace the double-debit example and identify the unsafe interleaving.
- Optional SQL practice: try daily totals if querying is relevant to your role; SQL is not a confirmed separate N26 interview round.
Deliverable: A bug explanation and a regression test
Practice prompt ↗Practice prompt ↗06Prepare evidence-led stories
- Choose a real release decision and an incident you helped resolve.
- Outline your action, the evidence and what you learned.
Deliverable: Two concise stories with your contribution made clear
Practice prompt ↗Practice prompt ↗07Rehearse and choose next steps
- Run a short mock combining a coding explanation with a design discussion.
- Revisit your weakest topic and write questions to ask the team.
Deliverable: A focused review sheet and your next practice priority
Expand any day for tasks and deliverables. Your progress is saved on this device.
Choose a real project. Explain your decision, the evidence behind it and what you learned.
Explain a release you slowed down
Task: Describe a real case where a correctness risk changed a release decision. Show the evidence, the people involved and the cost of waiting.
Approach
- Be specific: Name the failing scenario and the user consequence.
- Own the choice: Explain your recommendation, the decision and the follow-through.
Follow-up
- What evidence would have made you ship earlier?
Resolve an architecture disagreement
Task: Tell a story about disagreeing over a service boundary or data model. Explain how you tested the competing assumptions.
Approach
- Compare: State both options fairly.
- Decide: Describe the experiment or constraint that broke the tie.
Follow-up
- What did the rejected option do better?
Lead a useful incident follow-up
Task: Describe an incident you helped resolve. Separate immediate recovery from the later change that prevented recurrence.
Approach
- Build a timeline: Include detection, mitigation and verification.
- Close the loop: Name an owner and a measurable check for the follow-up.
Follow-up
- What remained uncertain after service recovered?
- 01
Choose examples you can discuss without sharing confidential customer data.
Must I use Kotlin in every exercise?
The role prefers Kotlin. Python makes these algorithms easy to run; translate them into your permitted assessment language.
N26 — Backend Engineer, Investments & Savings ↗How long does each round take?
The linked posting lists stages without durations. Use the schedule supplied for your exact role; this guide does not assign a duration to those stages.
N26 — Backend Engineer, Investments & Savings ↗Are these actual N26 questions?
No. These are original preparation exercises. Reported interview details are attributed separately, and the linked practice bank covers Software Engineer questions across companies.
Can I run the examples locally?
Yes. The SQL fixtures run in SQLite and the coding example uses Python’s standard library. They demonstrate contracts and results; concurrency needs separate database testing.
Are these verified company interview questions?
These are PracHub practice exercises informed by the supplied guide themes and official product context. They include original constraints and worked solutions; they are not an independently verified list of questions asked by the employer.
Why include SQL alongside coding and design?
SQL is supplemental practice for inspecting system state and checking invariants. Its inclusion does not mean every role has a SQL interview. Prioritize the skills in your exact opening.
How should I use the seven-day checklist?
Attempt each task before opening its solution. Save one artifact per session, such as a tested function, fixture or failure timeline. Repeat weak areas and adjust the pace instead of treating seven days as a readiness guarantee.
Sources & methodology 4 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub — Software Engineer practice ↗
Cross-company practice destination; not evidence of employer questions.
platform · Accessed 2026-09-20 - 02PostgreSQL — Transaction isolation ↗
Technical reference for concurrency discussions; sample SQL fixtures use SQLite.
official · Accessed 2026-09-20 - 03N26 — Backend Engineer, Investments & Savings ↗
Role-specific stack and five named interview stages; no stage durations stated.
official · Accessed 2026-09-20 - 04N26 — Careers and product context ↗
Mobile banking, savings and investing product context.
official · Accessed 2026-09-20