Navi Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Navi: it is a product-and-engineering-first fintech that builds its core stack in-house.

• Lending, UPI, health and life insurance, mutual funds: all on systems its own engineers own.
• That is why the machine-coding round is real. They are not hiring someone to pass a drill and then struggle to ship a working service.
• They are hiring someone who, on day 30, can be handed a half-built wallet feature and extend it without breaking the money.
• So expect a round where you build a small working system, with a main method that actually runs, not pseudocode on a whiteboard.

2Getting the call (the part most guides skip)#

A referral is the single highest-leverage move you have. Navi hires mostly off-campus and through referrals, with some campus hiring at top-tier colleges.

• A referral from a current engineer routes your resume past the generic applicant pile.
• It often triggers a direct assessment link within days, instead of weeks of silence or an auto-reject you never hear about.

How people actually get shortlisted at Navi:

• Referral: Find Navi engineers on LinkedIn. Send a short, specific note: what you build, one concrete thing you shipped, and one real reason Navi's problems interest you (UPI scale, in-house lending stack, insurance tech). Attach a clean one-page resume. Do not send a wall of text. A referral plus a tight resume is often enough to get the online assessment on its own.
• Careers page / off-campus drives: Navi posts SDE roles directly. Apply early, and tailor the resume to the exact stack in the JD: Java/Kotlin/Spring for backend, Kotlin/Jetpack for Android, Swift for iOS. A generic resume blended across three stacks reads as "no clear strength."
• Campus: If you are a student at a target college, the on-campus process starts with a coding test, then runs the same interview loop below.

Resume rules that matter here:

• One page. Impact-first bullets. Lead with the result, then the how. The reviewer spends maybe 20 seconds on the first pass; the first half of each bullet decides whether they read the second half.
• Quantify everything. Weak: "Built a payments API." Strong: "Built a Spring Boot payments reconciliation service handling 2M+ daily transactions, cutting settlement mismatches by 38% and manual ops time by 6 hours/day." The second version tells the reviewer you understand scale, correctness, and that someone was counting on your code.
• Show scale, latency, or money moved. Fintech reviewers care about correctness and throughput above all. A bullet that mentions idempotency, reconciliation, or p99 latency gets more attention than one that mentions a framework.

ATS / keyword hygiene:

• Mirror the JD. For backend include Java, Spring Boot, microservices, Kafka, PostgreSQL/MySQL, Redis, REST, AWS, distributed systems, concurrency. For Android include Kotlin, Jetpack, Coroutines, MVVM, REST.
• Keep every keyword truthful. Everything on that resume is fair game in the interview, and a backend interviewer will absolutely ask you to explain the Kafka line you wrote.

3The loop at a glance#

Read the loop as a sequence of gates, not a cumulative average:

• New grads may skip system design and get an extra coding or CS-fundamentals round instead.
• Senior candidates get a heavier design focus and sometimes two design discussions.
• The loop is sequenced, so a weak early coding round usually ends it before you ever reach machine coding.

4The coding / technical rounds, patterns, not problems#

Navi's coding rounds are medium-to-hard and pattern-driven. They do not ask obscure puzzles.

• They ask well-known patterns and expect a clean, optimal solution with correct complexity stated out loud.
• If you can recognize which pattern a problem belongs to in the first two minutes, you have already done half the work.

The recurring patterns:

• Arrays & two pointers / sliding window: subarray sums, longest-substring-without-repeat variants, max/min window problems, container-with-most-water style.
• Hashing & frequency maps: grouping anagrams, first-unique-character, count-based problems, two-sum family.
• Binary search: on sorted arrays, and on the answer space (minimize the maximum, allocate books, ship-within-D-days capacity, Koko-eating-bananas style rate problems).
• Trees & BSTs: traversals, lowest common ancestor, diameter, serialize/deserialize, BST validation, level-order with queue.
• Graphs: BFS/DFS, topological sort, connected components, shortest path (Dijkstra), Union-Find for cycle detection and grouping.
• Dynamic programming: 0/1 knapsack and variants, longest common/increasing subsequence, grid paths, partition / subset-sum, coin change.
• Heaps / priority queues: top-K elements, merge-K-sorted-lists, task scheduling, running median with two heaps.
• Stacks: next-greater-element, valid parentheses, monotonic stack for histogram-style problems.
• Recursion & backtracking: subsets, permutations, combination sum, N-queens, word search on a grid.

How to win the round (this matters as much as the solution):

1. Clarify first. Restate the problem in your own words. Confirm input ranges, edge cases (empty input, duplicates, negatives, integer overflow), and the expected output format. Ask about constraints explicitly, because n up to 10^3 versus 10^6 decides whether O(n^2) passes. Asking this shows you think about complexity before you code, not after.
2. Communicate the approach before coding. Say the brute force, state its complexity, then say your optimized idea and its complexity. Get a visible nod before you type a single line. Nothing wastes a round faster than coding 20 minutes of the wrong approach in silence.
3. Code cleanly. Good names, small helper functions, no dead code, no debugging prints left behind. Interviewers at a product company read your code the way they read a pull request. Messy-but-correct still costs you.
4. State complexity. Always give time and space, and justify them in one sentence each. "O(n) time because each element is pushed and popped once; O(n) space for the stack."
5. Test out loud. Dry-run one normal case and one edge case by hand, tracing variables. Catch your own bug before they point at it. Finding your own off-by-one is one of the strongest signals in the whole round.

How to practice:

• Do roughly 150 curated mediums spread across the patterns above, then 30-40 hards concentrated in DP, graphs, and trees, which is where Navi's follow-ups go deep.
• Practice on a plain editor while narrating out loud to an empty room. Silent grinding builds the solving muscle but not the communication muscle Navi actually scores.
• The people who fail here often solve the problem fine and still lose, because the interviewer could not follow the reasoning.

5Machine coding / LLD, the round that separates candidates#

This is the round most DSA-only candidates underestimate, and it often decides the loop.

• You are given a real-world problem and 60-90 minutes to build a working, runnable solution with clean object-oriented design.
• Think: a parking-lot system, a Splitwise / expense-sharing app, an in-memory key-value store with TTL, a rate limiter, a logging library, a cab-booking matcher, or a simplified payment-wallet with balances and transfers.
• That last one is very on-theme for a fintech, and a favorite here.

A framework that works under time pressure:

1. Clarify scope (5 min). Nail down the 3-4 core features you will actually build in the time. Say out loud which nice-to-haves you are deferring and why. Scoping down on purpose is a senior signal; trying to build everything and finishing nothing is the classic failure.
2. Model the domain (10 min). Identify entities (User, Account, Transaction, Wallet) and their relationships. Sketch the interfaces before the classes. For a wallet: a Wallet holds a balance, a Transaction records a transfer, a Ledger is the append-only record of truth.
3. Apply SOLID, lightly. Use interfaces for anything that could vary: payment method, matching strategy, storage backend. Favor composition over inheritance. Do not reach for ten design patterns. Reviewers punish gold-plating as hard as they punish sloppiness, because over-engineering in a money system is its own kind of bug.
4. Write runnable code. It must compile and run a main / driver that demonstrates the features end to end. Use in-memory data structures; no real database needed. If the interviewer cannot run it and see output, it did not happen.
5. Handle concurrency and edge cases where relevant: negative balances, insufficient funds, double-spend, concurrent transfers on the same account, invalid input. Fintech problems live and die on correctness. A wallet that lets balance go negative is an instant red flag at Navi specifically.
6. Leave seams for extension. Say out loud how you would add a new feature (a new payment method, a new split rule) without rewriting existing classes. That one sentence shows design maturity better than any pattern name.

What scoring actually favors:

• Clean class boundaries, correct behavior, readable code, and honest trade-off talk, not the fanciest pattern.
• If you run out of time, a smaller fully-working system beats a large broken one every single time.
• A wallet that does deposit, transfer, and balance correctly beats a half-built one with five entities and no working path.

For senior candidates (SDE-2/3), system design joins the loop. Use a crisp framework and do not skip the early steps to rush to boxes:

1. Clarify functional and non-functional requirements: QPS, read/write ratio, latency targets, consistency needs, data retention.
2. Estimate scale with back-of-envelope math: throughput per second, storage per year, peak-versus-average multiplier.
3. Define the API: endpoints, request/response shapes, error cases.
4. Design the data model and pick stores: SQL for money and strong consistency, NoSQL or cache for scale and speed. Say why for each.
5. Draw the high-level architecture: clients, load balancer, services, queues, databases, cache.
6. Deep-dive one or two components and discuss bottlenecks, sharding, replication, idempotency, and failure handling. This is where senior candidates earn or lose the round.

Classic prompts in Navi's domain: design a payment or UPI transaction flow, a wallet and ledger system, a notification service, a rate limiter, a URL shortener, a feed, or a KYC document pipeline.

• For anything involving money, always speak to idempotency, exactly-once semantics, consistency, auditability, and reconciliation.
• Those are the exact words that tell the interviewer you have thought about money systems before, not just CRUD apps.
• If you design a payment flow and never once say "idempotency key," a Navi interviewer notices.

6Behavioral & culture fit#

Navi's engineering culture centers on ownership, speed, first-principles problem solving, customer obsession, and simplicity.

• They want builders who take end-to-end responsibility.
• They want people who move fast without breaking trust. This is regulated money, and a lost rupee is a real person's lost rupee.
• They want engineers who keep systems simple instead of clever.
• The hiring-manager round is probing one thing: do you drive outcomes, or do you just close tickets someone else scoped for you?

Write 5-6 STAR stories in advance so you are not inventing them live:

• A hard bug you owned end to end.
• A project you drove from idea to ship.
• A disagreement you resolved with a teammate.
• A time you shipped fast under ambiguity.
• A failure you actually learned from.
• Each one must end with a measurable result, not "and it went well."

One full worked STAR example:

Situation: Our checkout service was timing out during peak sale traffic, and about 4% of payment attempts were failing silently.

Task: As the owning engineer, I had to cut the failure rate below 1% within the two-week run-up to the next sale.

Action: I traced the failures to synchronous calls to a slow downstream ledger service that held DB connections open under load. I introduced an async write path with a Kafka queue for the ledger update, made the payment write idempotent using a request key so retries could not double-charge, and added a circuit breaker with retry-with-backoff. I load-tested at 3x expected peak before rollout.

Result: Payment failures dropped from 4% to 0.3%, p99 checkout latency fell from 2.1s to 640ms, and the next sale processed 2.4M transactions with zero payment incidents.

Why that example lands:

• Ownership language throughout ("I traced," "I introduced").
• Fintech-correct reasoning (idempotency, async, reconciliation).
• A hard number at the end.
• If your story ends without a number, keep digging until you find one, even an estimate with how you arrived at it.

7Your prep plan#

4-week plan (recommended):

• Week 1: Re-learn patterns: arrays, hashing, two pointers, sliding window, stacks, binary search. 40 mediums. Revise time/space complexity until stating it is automatic.
• Week 2: Trees, graphs, heaps, recursion/backtracking. 40 problems. Start narrating every solution out loud, even the easy ones, so narration becomes a habit and not a performance.
• Week 3: DP deep dive plus 2-3 full machine-coding builds (parking lot, Splitwise, wallet), each one compiling and running a demo. Learn SOLID by applying it, not by reading about it. SDE-2+: add system design basics and the fintech vocabulary.
• Week 4: Mock interviews with a real person, 20 hards, write your 6 STAR stories out in full, review fintech design patterns (idempotency, ledgers, rate limiting, reconciliation). Rest the day before. A tired brain loses more points than one missing pattern.

2-week plan:

• Days 1-5: Core patterns, 50 mediums, narrate everything.
• Days 6-9: Trees, graphs, DP, 2 machine-coding builds that actually run.
• Days 10-12: System design (if senior), 15 hards.
• Days 13-14: Mocks + STAR stories + light revision.

2-day crash plan:

• Day 1 AM: Patterns cheat-sheet + 10 fast mediums across arrays, strings, trees.
• Day 1 PM: One full machine-coding build end to end; review SOLID; skim one design template.
• Day 2 AM: 8 graph/DP problems; re-do any you missed cold.
• Day 2 PM: Write 4 STAR stories, dry-run the "walk me through a project" answer out loud, sleep well.

8Why people get rejected at Navi#

1. Silent coding. The interviewer cannot see your reasoning, so a correct answer with no narration still reads as weak. They are scoring communication as much as the code.
2. Brute force with no path to optimal. Starting with brute force is fine and even smart. Stopping there, with no discussion of how to get to O(n log n), is fatal.
3. Machine-coding code that does not run. A broken build or an over-engineered design with no working path loses to a smaller system that compiles and demos. Finishing matters.
4. Weak correctness on money logic. Missing idempotency, double-spend protection, or negative-balance handling is disqualifying at a fintech. This is the single most Navi-specific failure mode.
5. Hand-wavy system design. Buzzwords with no concrete data model, no numbers, no trade-offs, and no failure handling. Saying "we'll just add Kafka" without explaining what it buys you reads as cargo-culting.
6. No ownership in behavioral answers. Describing tasks you were assigned instead of outcomes you drove signals a ticket-closer, not a builder. "We decided" instead of "I decided" repeated across every story gives it away.

9The offer, comp & negotiation#

Navi pays competitively for the Indian market. The structure is fixed base + annual variable/performance bonus + ESOPs.

• Equity is a meaningful part of the package, especially at senior levels, so do not read only the fixed number.
• Rough 2026 ranges:
• SDE-1: ₹18-32L total
• SDE-2: ₹35-55L total
• SDE-3 / Senior: ₹55-90L+ total
• Exact numbers vary with interview performance, your current compensation, and the level you land at.

Negotiation tips for Navi's context:

1. Anchor on a competing offer or a strong current package. A written counter-offer is the strongest lever you have. Always share the full breakup (fixed + variable + stock), not just the headline, so they are comparing apples to apples.
2. Negotiate level, not just money. Being placed at SDE-2 versus SDE-1 moves your comp far more than any base bump, and it compounds every year after. If your scope and ownership justify the higher level, make the case with concrete evidence from your work, not just a request.
3. Clarify the ESOP details: strike price, vesting schedule, and the current valuation basis. Get these in writing so you can value the equity realistically instead of treating a big headline number as cash in hand.

10FAQ#

Q: Is Navi's interview more DSA or more design? A: Both, weighted by level. New grads face mostly DSA plus a machine-coding round. SDE-2 and above get real system design and deeper LLD, often with more follow-up pressure.

Q: What language should I use? A: Use your strongest. Backend roles lean Java/Kotlin; most interviewers accept any mainstream language for DSA. For machine coding, pick a language you can structure cleanly with OOP, because the whole round is about structure.

Q: How hard is the DSA level? A: Medium to hard. They expect optimized solutions and correct complexity stated out loud, not just a brute force that happens to pass the small test cases.

Q: Do I really need to prepare for machine coding? A: Yes. It is often the deciding round and the one DSA-only candidates fail cold. Build 2-3 full mini-systems, each compiling and running a demo, before your loop. Do not just read about SOLID.

Q: How long until I hear back? A: Usually within a few days to two weeks per stage. A referral plus prompt scheduling on your end can compress the whole loop to 2-3 weeks.

Want this turned into a personalized, dated prep schedule around your actual interview date? Build your plan and walk in knowing exactly what to study each day.