Interview experience
Bajaj Finserv Interview Questions and Answers (2026)
Overview
Section titled “Overview”Bajaj Finserv’s fresher loop is a tight 4-stage process where the technical rounds consistently pull DSA problems (LRU cache, rate limiters) into a lending-domain conversation - loan journeys, SQL data modelling, Java backends - rather than testing DSA and domain knowledge separately.
Bajaj Finserv interview process at a glance
Section titled “Bajaj Finserv interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 90 min | Coding (DSA) + sometimes MCQs |
| Technical Round 1 | 45-60 min | DSA + backend / lending concepts |
| Technical Round 2 | 45-60 min | System design (lending / ledger) |
| HR / Culture | 20-30 min | Motivation, integrity, relocation |
Online Assessment
Section titled “Online Assessment”A 90-minute timed coding test, usually on HackerRank or a similar platform. Clean, fully-passing solutions beat partially-clever ones - the shortlist bar rewards correctness and completion over elegance.
Common questions
- Merge overlapping time intervals (sort + sweep)
- Array/string manipulation problems at medium difficulty
- Occasional CS-fundamentals MCQs alongside the coding problems
Technical Round 1
Section titled “Technical Round 1”Opens with a DSA coding problem, then moves into backend and lending-domain concepts - candidates consistently report being asked to explain loan-application journeys or SQL data modelling in plain terms, plus a detailed walkthrough of a resume project.
Common questions
- Design an LRU cache (expected: HashMap + doubly linked list, with follow-up on complexity/edge cases)
- Implement a rate limiter (sliding window or token bucket)
- Walk through a lending journey or SQL schema - inputs, outputs, what breaks at scale
- Your project’s architecture, hardest bug, and what you’d rebuild
Technical Round 2
Section titled “Technical Round 2”System-design focused, usually scoped around lending or ledger-style systems rather than a generic prompt - data consistency and failure modes come up even at fresher depth.
Common questions
- Design a loan-application tracking system - how do you model state transitions?
- Discuss failure modes for a lending workflow and how you’d detect/recover from them
- Simple bottleneck and scaling questions on a ledger or transaction-history system
Round-by-round narratives are on the Bajaj Finserv interview experience page.
HR / Culture round
Section titled “HR / Culture round”A closing 20-30 minute conversation on motivation, integrity, and logistics. Concrete answers with a clear result outperform generic slogans here.
Common questions
- Why fintech / why Bajaj Finserv specifically?
- Tell me about a production bug or outage you helped with
- Describe an integrity or pressure scenario you’ve faced
- What’s your joining timeline?
Sample answer frameworks for each of these are on the Bajaj Finserv HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How do you design an LRU cache with O(1) operations?
Pair a HashMap with a doubly linked list. The map stores key to node, and the list orders nodes by recency with the most recent at the head and the eviction candidate at the tail. A get looks the node up in the map and unlinks and re-inserts it at the head, both O(1) because the node holds pointers to its neighbours. A put either refreshes an existing node or inserts a new head node, evicting the tail and removing its key from the map once the size exceeds capacity. Use sentinel head and tail nodes so you never write null checks in the unlink path, which is where most live-coding attempts break.
Q: How would you implement a rate limiter for a loan-application API?
Token bucket is the standard choice: each customer or API key has a bucket refilled at a steady rate up to a cap, and a request either takes a token or is rejected with HTTP 429. It permits a short burst - useful when a user retries a stuck application - while bounding the sustained rate. A fixed-window counter is easier but allows double the limit across a window boundary, so a sliding-window counter is the usual fix. Across multiple app servers the counter must live in Redis and be updated with an atomic INCR plus expiry or a Lua script, otherwise concurrent requests each read a stale count and all pass.
Q: How do you merge overlapping time intervals?
Sort the intervals by start time, then sweep once holding a current interval. If the next start is less than or equal to the current end the two overlap, so set the current end to the larger of the two ends; otherwise emit the current interval and start a new one from the next. Emit the last interval after the loop ends. The cost is O(n log n) dominated by the sort, with O(n) output space. Decide up front whether touching intervals like 1 to 3 and 3 to 5 count as overlapping, because that boundary case is what interviewers probe.
Q: How would you model the state transitions of a loan application?
Treat it as an explicit finite state machine rather than boolean flags. Define states such as DRAFT, SUBMITTED, KYC_PENDING, UNDER_UNDERWRITING, APPROVED, REJECTED, DISBURSED and CLOSED, and store the allowed transitions in a table or enum map so an illegal jump - say SUBMITTED straight to DISBURSED - is rejected at the service layer. Keep the current state on the application row for fast queries and write every change to an append-only status-history table with the actor, timestamp and reason, which gives you an audit trail regulators expect. Guard each transition with an optimistic-locking version column so two concurrent updates cannot both move the application.
Q: Write a SQL query to find customers with more than one active loan.
Group the loan table by customer and filter with HAVING, since WHERE runs before aggregation: SELECT customer_id, COUNT(*) AS active_loans FROM loans WHERE status = 'ACTIVE' GROUP BY customer_id HAVING COUNT(*) > 1 ORDER BY active_loans DESC; The WHERE clause narrows rows to active loans first, the GROUP BY collapses them per customer, and HAVING applies the post-aggregation filter. For this to be fast on a large lending book you want a composite index on customer_id and status so the database can satisfy the filter and grouping from the index rather than scanning the table.
Q: What are the ACID properties and why do they matter in a ledger system?
Atomicity means a transaction applies fully or not at all, so a disbursal that debits one account and credits another can never leave half the entry written. Consistency means every committed transaction moves the database from one valid state to another, respecting constraints such as a balance that must never go negative. Isolation means concurrent transactions do not see each other’s partial work, which prevents two simultaneous withdrawals from both reading the same starting balance. Durability means a committed transaction survives a crash because it is written to the write-ahead log before acknowledgement. In a lending ledger these are non-negotiable, which is why money movement stays in a relational database even when other services do not.
Q: How do you make a payment or disbursal API idempotent?
Require the client to send an idempotency key - typically a UUID generated once per logical attempt - and store it in a table with a unique constraint alongside the resulting response. On each request, insert the key inside the same transaction as the money movement: if the insert succeeds you perform the operation, and if it violates the unique constraint you return the stored response instead of processing again. This matters because network timeouts make retries inevitable, and without it a retried disbursal pays the customer twice. Keep keys for a bounded window, and always scope them to the caller so two clients cannot collide.
Q: How is EMI calculated on a loan?
EMI equals P times r times (1 plus r) to the power n, divided by (1 plus r) to the power n minus 1, where P is the principal, n is the number of monthly instalments, and r is the monthly interest rate - that is, the annual rate divided by 12 and by 100. For a 1,00,000 rupee loan at 12 percent annual over 12 months, r is 0.01 and the EMI comes to about 8,885 rupees. The instalment stays constant, but its split shifts: early EMIs are mostly interest since interest is charged on the outstanding balance, and the principal share grows each month, which is why prepaying early saves far more interest than prepaying late.
Frequently asked questions about Bajaj Finserv interviews
Section titled “Frequently asked questions about Bajaj Finserv interviews”What is the Bajaj Finserv interview process for freshers?
Bajaj Finserv’s SDE/Backend Engineer process for freshers typically runs 4 stages: 1. Online Assessment (90 min) - DSA coding, sometimes with MCQs. 2. Technical Round 1 (45-60 min) - DSA plus backend/lending-domain concepts. 3. Technical Round 2 (45-60 min) - system design, often framed around lending or ledger-style systems. 4. HR/Culture (20-30 min) - motivation, integrity, relocation. Timeline is usually 2-4 weeks from application to offer for campus drives.
What questions are asked in Bajaj Finserv interviews?
Common coding questions include designing an LRU cache (HashMap + doubly linked list), implementing a rate limiter (sliding window or token bucket), and merging overlapping time intervals (sort + sweep). Technical rounds also probe domain concepts specific to Bajaj Finserv’s lending business - loan-application journeys, SQL data modelling, and Java backend fundamentals - in plain-language terms rather than buzzwords. HR rounds ask why fintech/lending, and about a production bug or outage you helped with.
How many rounds are there in the Bajaj Finserv interview?
Bajaj Finserv typically runs 4 stages: an Online Assessment, two Technical Rounds (DSA+domain, then system design), and an HR/Culture round. Some drives merge HR into the second technical round instead of running it separately - confirm the exact structure from your placement cell.
What is the Bajaj Finserv technical interview like?
Technical Round 1 (45-60 min) mixes a DSA coding problem with backend/lending-domain discussion - candidates report being asked to design an LRU cache or a rate limiter, followed by a plain-language discussion of lending journeys and SQL data modelling. Technical Round 2 shifts to system design, often centered on lending or ledger-style systems (data consistency, failure modes at fresher depth). Both rounds also include a detailed project discussion covering stack choices and the hardest bug you’ve debugged.
How should I prepare for Bajaj Finserv interviews?
Clear the OA with clean, fully-passing solutions rather than partial cleverness - timed practice beats last-minute topic-hopping. Revise OOPs and SQL, since fundamentals questions open a lot of Bajaj Finserv panels. For domain questions, be ready to explain lending journeys in plain language (inputs, outputs, what breaks at scale) rather than reciting buzzwords. Prepare one detailed project story (architecture, hardest bug, what you’d rebuild) and concrete HR answers - one story with a clear result beats several vague claims.
What mistakes do candidates commonly make in Bajaj Finserv interviews?
Coding before clarifying constraints, treating the HR round as a formality, and reaching for system-design jargon without a simple, concrete bottleneck story. Candidate reports consistently note that a coherent explanation of lending-journey trade-offs beats a high CGPA paired with weak communication.