Bajaj Finserv interview experiences from fresher drives

Bajaj Finserv’s fresher interview process often opens with a 2-3 hour API build task in a language you choose, which can set your tech track, then a coding or MCQ test, a technical interview and a 20-30 minute HR and culture round. Filtering rests on API competence, language and framework fundamentals and SQL, with little or no system design, and several campus accounts report same-day results.

Variance to expect: some Data Engineer cycles open with aptitude MCQs instead of an API build; pool drives (for example Bajaj Finserv Health) can add a Principal EM design conversation and a National Head TA close. Trust the drive college placement email over older PDFs. Practice building and explaining a working API in your chosen stack more than grinding hard DSA.

How Bajaj Finserv differs from typical campus product loops

• Round 1 is often a build/hit-API task, not a pure DSA contest - language choice can determine your later track.
• Little or no system design in classic fresher reports; filtering is API competence + language/framework fundamentals + SQL.
• Same-day or near-same-day results appear in multiple campus accounts.
• Pune relocation and Mon–Sat logistics show up early in HR.

Round-wise process

Real interview experiences

Bajaj Finserv’s campus process is unusual and worth knowing before you prep: multiple independent student write-ups describe the first round as a build task, not a DSA test - you are given an API specification and asked to actually hit or build an endpoint, in a language of your choice, over two to three hours. Only after that do you get a conventional coding/MCQ test, and in some cycles you are streamed into a technology track based on the language you used in round one.

Documented on-campus drive: Backend (Node.js) track

Source: GeeksforGeeks, Bajaj Finserv Backend Developer on-campus

A student who went through the on-campus drive for a Backend - Node.js role reported:

Round 1 (online, ~3 hours) - build an API using a backend framework, with JavaScript, Python, or Java as the preferred stack.

Round 2 (online, ~1 hour, HackerRank) - 17 Node.js questions plus one medium-hard programming question, and this round was restricted to Node.js only.

Round 3 (technical interview, ~1 hour, face to face)

• Self-introduction and a walkthrough of projects.
• Writing an AJAX method, and Node.js code for a GET request that fetches an employee by ID from MongoDB.
• Why Node.js is single-threaded and how it handles concurrency.
• What I/O means, and the drawback of Node.js (the expected answer being that it is unsuited to heavy computational work).

HR round (~15 minutes) - hobbies, family, willingness to relocate to Pune, and confirmation of a Monday-Saturday working week with a January 2023 start at the Pune office.

Outcome: offered an internship plus PPO, with results announced the same day.

Takeaways

• What decided it: Working API in Round 1 plus clear Node concurrency/I/O answers in the technical
• Common fail: Choosing a language you cannot defend under MongoDB/AJAX follow-ups
• How to practice: Build one CRUD API end-to-end; rehearse event loop and single-thread limitations aloud

Documented on-campus drive: Microservices-Java track

Source: GeeksforGeeks, Bajaj Finserv Software Developer on-campus

A second student (VIT Vellore, August drive, electronics background who moved into IT) reported a similar shape with different streaming:

• Round 1 (~2 hours): an API-based coding challenge, any language allowed.
• Round 2 (~1.5 hours): candidates were classified by the language they used in round one - this candidate landed in the Microservices-Java track. The round itself was an aptitude test plus two easy coding questions. Roughly 600 students cleared it.
• Round 3 (technical interview): around 250 sat it and about 130 cleared it, including this candidate. Background and resume projects (including how they solved the round 1 problem), then PUT vs POST, Java threading, collections, OOP, overriding vs overloading, SQL basics and a database project.
• Round 4 (HR, telephonic), then a confirmation call about the Pune location and whether candidates accepted the CTC. Everyone who cleared the technical round was selected for their assigned role.

What this means for prep: the reported fresher process has no system design round and very little algorithmic depth - the filtering happens on whether you can actually build and explain a working API, and then on language/framework fundamentals (Node.js event loop and concurrency, or Java threading and collections) plus SQL. Know your chosen stack properly rather than grinding hard DSA, be ready for Pune relocation to come up in HR, and expect fast turnarounds - both accounts report same-day or near-same-day results.

Takeaways

• What decided it: Language-streamed Round 2 plus solid Java OOP/SQL in technical; HR was largely logistics
• Common fail: Preparing only DSA while the track asks PUT vs POST, threading, and collections
• How to practice: Match prep to the language you used in Round 1; drill SQL joins and OOP contrasts

Documented on-campus drive: Data Engineer (2023)

Source: GeeksforGeeks, Bajaj Finserv on-campus 2023

A 2023 campus write-up from a Data Engineer applicant describes a 60% throughout eligibility bar and three stages before HR:

Round 1 - Aptitude (~30 MCQs): Quant, reasoning, verbal; roughly 200 of 1200 advanced.

Round 2 - HackerEarth MCQs: 12 questions on Python, SQL, data, and cloud for the Data Engineer role; about 120 shortlisted.

Round 3 - Technical (~35-40 min): Resume walkthrough, DBMS/Java/OOP, medium DSA with approach discussion.

HR (~5 min): Relocation to Pune, basic logistics; roughly 20 offers across roles in that cycle. The author does not state their own result.

Takeaways

• What decided it: Aptitude + role MCQs (Python/SQL/data/cloud) before a fundamentals technical
• Common fail: Assuming every Bajaj Finserv drive starts with an API build - Data Engineer opened with aptitude
• How to practice: Confirm role pattern from the placement mail; revise SQL and DBMS for DE tracks

Documented pool campus: Bajaj Finserv Health (Associate Software Developer, 2026)

Source: Medium, Bajaj Finserv Health Associate Software Developer, Feb 2026

A candidate from an RGPV pool drive (Java / Spring Boot) reports a six-round plan, longer than the classic four-round campus loop:

• Home assessment (1 hour): build a basic Spring Boot project that calls a given API with name, email and enrollment number, uses the returned token to submit two SQL queries, then builds a JAR and pushes to GitHub. AI tools were allowed; working API integration mattered most.
• Onsite assessment (120 min): two DSA problems (easy and medium level, not LeetCode questions) plus ~25 Core Java MCQs
• Technical with a Principal Engineering Manager: microservices basics, paper design of an account-balance API (controller, service, repository, entity), @Autowired and dependency injection, a SQL JOIN, pagination (Pageable vs LIMIT/OFFSET). The author skipped the second technical round; others had two or three.
• HR (family, prior work, culture) and an online round with the National Head of Talent Acquisition on background, how they learned programming, communication and attitude, which the author found the most stressful
• Outcome (candidate-reported): selected; 6 chosen from 900+ who appeared. The post states a 6-month internship with a ₹44K stipend and a ₹12 LPA PPO; treat compensation as candidate-reported

Takeaways

• What decided it: Spring Boot/API home assessment plus DI, SQL JOIN, and pagination depth with a Principal EM
• Common fail: Stopping after campus-style four rounds when Health/pool drives add managerial closes
• How to practice: Paper-design a simple balance API; explain @Autowired and pagination trade-offs

Round structure varies by role and hiring cycle - Data Engineering and Full Stack tracks report different section mixes. Trust your drive’s placement email over any older summary.

Pre-interview checklist (Bajaj Finserv)

• Confirm whether Round 1 is an API build, aptitude, or role MCQ from the placement mail
• Practice one end-to-end API in the language you will use (Node or Java) including PUT vs POST
• Revise stack fundamentals: event loop / concurrency (Node) or threading/collections (Java) plus SQL joins
• Prepare Pune relocation and work-week answers honestly for HR
• Light DSA warm-up only: one medium problem, not a contest grind
• Know one resume project cold (queries, trade-offs, what you would rebuild)

Questions that come up often

Coding / technical

1. Design an LRU cache. Usually expects HashMap + doubly linked list
2. Implement a rate limiter. Usually expects sliding window / token bucket
3. Merge overlapping time intervals. Usually expects sort + sweep
4. Discussion on lending journeys and SQL, bottlenecks, failure modes, simple APIs
5. Detailed project discussion, architecture, hardest bug, what you would change

HR / behavioral

1. Why fintech / payments?
2. A production bug or outage you helped with
3. An integrity / pressure scenario
4. Joining timeline

Practical tips for Bajaj Finserv

• Clear the screening round first. Timed practice beats last-minute topic hopping.
• For domain questions, explain lending journeys in plain language, inputs, outputs, what breaks at scale.
• OOPs and SQL still open a lot of Bajaj Finserv panels. Do not skip fundamentals.
• HR answers should be concrete. One story with a result beats five slogans.

HR interview

After technical rounds, Bajaj Finserv usually closes with a short HR / hiring-manager conversation: motivation, location, notice period, and a couple of behavioral stories.

Sample answers for high-frequency questions

Q. How do you design an LRU cache with O(1) operations?
A. 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?
A. 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?
A. 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?
A. 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.
A. 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.

Tips from successful candidates

Sources

Cross-check the current drive mail for timings and role-specific sections.

• Backend Developer on-campus - GeeksforGeeks
• Software Developer on-campus - GeeksforGeeks
• On-campus 2023 (Data Engineer pattern) - GeeksforGeeks
• Internship experience - GeeksforGeeks
• Associate Software Developer pool drive - Medium

For the company overview, see the Bajaj Finserv hub. For behavioral frames, use the HR page. For OA drills, see Bajaj Finserv placement papers.

Similar companies

HDFC Bank · ICICI Bank · Paytm · Goldman Sachs · JP Morgan · Deutsche Bank