PolicyBazaar Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about PolicyBazaar: it is a high-traffic consumer marketplace sitting on top of the slow, regulated, detail-heavy world of insurance.

• A single user journey touches quote generation across a dozen insurers, KYC, payment, and an IRDAI-regulated policy record that cannot be wrong.
• They want engineers who are fast and careful: a quote flow that loads in under two seconds but never loses a rupee, never double-charges a premium, never mishandles a policy document.
• Speed without correctness fails here. So does correctness that takes three weeks to ship.

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

Four main doors in, and they are not equal:

• Campus placements: tier-1 and strong tier-2 colleges.
• Off-campus: careers page and LinkedIn.
• Referrals: current engineers vouching for you.
• Sourcing: recruiters finding you on GitHub, LinkedIn, and coding platforms.

Referrals are the strongest door.

• A referral usually gets your resume read within days instead of sitting in a queue for weeks.
• The internal referral portal flags your application to the recruiter directly, so it skips the first automated filter.
• No contacts? Send a short, specific LinkedIn message to a PolicyBazaar engineer: name the exact role and req ID, attach your resume, and give one line on why you fit (for example, "I shipped a payments-retry service at X and want to work on PB's premium flows").
• Expect maybe one reply in five, so message ten people, not one. Polite and specific beats generic every time.

Resume rules. One page for anyone under ~6 years. Lead each bullet with impact, not task:

• Weak: "Worked on the payments module and fixed bugs."
• Strong: "Rebuilt the retry logic in the payment-confirmation service, cutting failed-transaction tickets by 38% and reclaiming ~₹4L/month in dropped renewals."

The whole trick:

• Numbers, a verb, and a business outcome in every bullet.
• No number means either find the number or cut the bullet.
• Three sharp bullets per role beat eight vague ones.

ATS keywords. Mirror the language of the job description.

• For a PolicyBazaar backend role that usually means: Java or Node.js, Spring Boot, microservices, REST APIs, SQL (MySQL/Postgres), Redis, Kafka, AWS, system design, and data structures.
• Put the real ones you have used near the top.
• Do not keyword-stuff things you cannot defend. The machine-coding round will expose it in ten minutes.

Online test. For many pipelines (especially campus and bulk off-campus), the first filter is a timed assessment, often on HackerRank or similar:

• 2-3 DSA problems and sometimes MCQs on CS fundamentals (OS, DBMS, networks, OOP).
• Partial scoring is common, so submit something that passes a few test cases even if you cannot get them all.
• Register early, test your webcam and compiler setup, treat it like a real round, because it is the gate to the human ones.
• A common cutoff is roughly 2 of 3 problems fully passing.

3The loop at a glance#

How the loop bends by level:

• Exact order and count vary by role and level.
• Freshers lean DSA-heavy: often two coding rounds and no system design.
• Mid and senior engineers get the machine-coding and system-design rounds that actually decide the level.
• An SDE-2 candidate who codes like an SDE-1 gets offered SDE-1, not rejected.
• The hiring-manager round is rarely a pure formality: a weak answer on ownership or data integrity can sink an otherwise strong loop.

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

PolicyBazaar's coding rounds sit in the medium-to-hard band and reuse a predictable set of patterns. Master the patterns and you recognize most problems in the first minute, which is the whole game under a clock.

The patterns they reuse:

• Arrays and hashing: two-sum variants, subarray sums, frequency maps, grouping.
• Two pointers and sliding window: longest substring without repeats, min window, container-with-water style.
• Strings: parsing, pattern matching, anagrams, encode/decode.
• Stacks and queues: valid parentheses, next-greater-element, monotonic stacks.
• Trees and BSTs: traversals, lowest common ancestor, level-order, validate BST.
• Graphs: BFS/DFS, connected components, topological sort, shortest path (Dijkstra).
• Dynamic programming: knapsack, longest common subsequence, coin change, grid paths.
• Heaps and intervals: top-K, merge intervals, meeting rooms.
• Binary search: on arrays and on the answer space.

How to practice:

• Work through roughly 120-150 curated problems rather than grinding 500 random ones.
• Do every major pattern until you can write the template from memory, cold, with no reference.
• Time yourself at 25-30 minutes per medium, because the real test is correctness under a clock, not whether you can eventually solve it.
• If you can only solve a pattern slowly, you have not learned it yet.

How to win the round:

1. Clarify first. Restate the problem in your own words, then ask about input size, data types, duplicates, empty inputs, negative numbers, and output format. Thirty seconds here prevents ten minutes in the wrong direction.
2. Think out loud. State a brute-force approach, give its complexity, then improve it. They score your reasoning, so a silent correct solution scores worse than a narrated near-miss.
3. Write clean code. Good names, small functions, no dead code. Clean beats clever every time.
4. State complexity. Always give time and space in Big-O and explain why, for example "O(n log n) because of the sort, O(n) extra space for the hashmap."
5. Test it yourself. Walk through a normal case, an edge case (empty, single element, overflow), and a tricky case before you say you are done. Catching your own bug out loud is one of the strongest signals you can send.

Here is the kind of clean, tested answer they want, for a classic sliding-window prompt:

def length_of_longest_substring(s: str) -> int:
    # longest substring with no repeating chars
    last_seen = {}
    start = 0
    best = 0
    for i, ch in enumerate(s):
        if ch in last_seen and last_seen[ch] >= start:
            start = last_seen[ch] + 1
        last_seen[ch] = i
        best = max(best, i - start + 1)
    return best
# O(n) time, O(min(n, charset)) space

5Machine-coding / low-level design#

This is often the deciding round at PolicyBazaar and similar product companies, and it is where under-prepared strong coders lose.

The setup:

• You get a real-ish problem: "design an in-memory ride-matching service," "build a parking-lot system," "model an insurance-quote comparison engine," "design a rate limiter," "build a splitwise-style expense sharer."
• You get roughly 90 minutes to produce working, runnable, well-structured code on your own machine or a shared editor.

They are grading five things:

• Does it compile and run.
• Is the class design clean (single responsibility, sensible interfaces).
• Did you pick the right data structures.
• Is it extensible without a rewrite.
• Did you handle edge cases.

What is not on that list: a fancy framework, a database, or a perfect UML diagram. Runnable beats impressive.

A framework that works:

1. Clarify scope (5 min). Nail down the exact in-scope features. Cut everything not asked for. A working subset beats a half-built everything, and they respect a candidate who says "I will skip refunds to get the core flow running first."
2. Model the entities (10 min). Name your core classes and their relationships. For an insurance-quote engine that might be Customer, Policy, Quote, Insurer, QuoteComparator.
3. Define interfaces (10 min). Sketch the public methods before writing bodies. Program to interfaces so you can swap implementations, for example a PricingStrategy interface so term and health insurance price differently.
4. Build the happy path (40 min). Get one end-to-end flow working and runnable. Compiling code you can demo is worth more than elegant code that does not run.
5. Handle edge cases and refactor (15 min). Null inputs, empty collections, concurrency if asked. Apply SOLID where it genuinely helps. Do not over-engineer with five design patterns nobody asked for.
6. Demo (10 min). Run it with sample input and narrate what each step proves.

For SDE-2+ roles you also get a system design round. Use a clean structure:

1. Clarify functional and non-functional requirements and scale.
2. Estimate traffic and storage.
3. Define the API.
4. Sketch the high-level architecture.
5. Design the data model.
6. Go deep on one or two components.
7. Discuss bottlenecks, caching, and failure handling.

Classic PolicyBazaar-flavored prompts:

• Design an insurance-quote comparison platform.
• A notification/reminder system for policy renewals.
• A payment-processing pipeline with retries and idempotency.
• A URL shortener or rate limiter as warm-ups.
• A search/filter service over millions of policies.

Always talk trade-offs out loud (consistency versus availability, SQL versus NoSQL, sync versus async), because trade-off reasoning is what separates levels.

A quote-comparison sketch looks roughly like this, and drawing it fast buys you time to talk trade-offs:

The point to make out loud:

• Insurer APIs are slow and flaky, so you fan out async, cache aggressively, and show partial results as quotes arrive instead of blocking on the slowest insurer.
• That single insight signals you understand the domain, not just the diagram.

6Behavioral and culture fit#

PolicyBazaar and the broader PB Fintech group lean on a few consistent themes rather than a famous named framework. Expect the culture round to probe:

• Customer-first thinking: they sell trust in a category most people are skeptical of.
• Ownership and bias for action: startup-paced, you own your feature end to end, there is no hand-off team to blame.
• Integrity with data and money: non-negotiable in regulated fintech.
• Collaboration across product, business, and tech.
• Learning agility: the regulatory and product rules change often, so yesterday's design can be wrong today.

How to prepare:

• Write 6-8 STAR stories (Situation, Task, Action, Result) and rehearse until they are tight and specific.
• Cover: a hard bug you owned, a conflict you resolved, a deadline you hit under pressure, a time you improved something nobody asked you to, and a failure you learned from.
• Always end with a measurable result, and say "I" not "we" when describing your own action.

One worked STAR example:

• Situation: Our policy-renewal reminder emails were going out late, and renewal conversion had dropped two quarters running.
• Task: I owned the reminder service and was asked to find and fix the delay without a full rewrite.
• Action: I traced it to a synchronous batch job that re-queried every active policy each run and timed out under load. I moved the sends onto an async queue (Kafka), added idempotency keys so a retry never double-sends, and scheduled reminders off a pre-computed renewal-date index instead of a full table scan.
• Result: Reminder latency dropped from hours to under two minutes, double-send complaints went to zero, and renewal conversion from reminders rose 17% over the next quarter.

Make the number defensible:

• Numbers make the story land.
• Pick results you can actually defend under follow-ups, because they will ask "how did you measure that 17%" and a made-up number falls apart.

7Your prep plan#

4-week plan

• Week 1: Arrays, hashing, two pointers, sliding window, strings. ~5 problems/day. Re-write templates from memory.
• Week 2: Stacks, queues, trees, BSTs, graphs (BFS/DFS, topo sort). Start one machine-coding problem end to end.
• Week 3: DP, heaps, intervals, binary search. Two full machine-coding builds (parking lot, rate limiter). Begin system design basics.
• Week 4: Mixed timed mocks, 2-3 system-design prompts, write and rehearse all STAR stories, polish resume.

2-week plan

• Week 1: Blitz the top patterns, arrays/hashing, sliding window, trees, graphs, DP, 6-8 problems/day, timed.
• Week 2: One machine-coding build, two system-design prompts, STAR stories, two full mock loops.

2-day crash plan

• Day 1: Re-solve 15-20 problems across your weakest patterns. Redo the two-pointer, BFS/DFS, and DP templates until they are automatic.
• Day 2: One machine-coding dry run (parking lot or splitwise), one system-design walkthrough out loud, write your three strongest STAR stories, re-read the job description.

8Why people get rejected at PolicyBazaar#

1. Silent coding. Correct answer, zero explanation, the interviewer cannot score your reasoning, and you look lucky rather than good.
2. Untested code. Declaring "done" without running an edge case, then the interviewer finds the bug for you. In a money-handling company that single move reads as careless.
3. Machine-coding that does not run. Over-engineered class hierarchies with nothing demoable at the 90-minute mark. A perfect design on paper that does not compile scores below an ugly thing that works.
4. No trade-off thinking in design. Naming technologies without explaining why, "I would use Kafka" with no reason behind it and no idea what breaks if you remove it.
5. No product curiosity. Treating an insurance-fintech role like a generic CRUD job, asking nothing about customers, renewals, premiums, or money flow. Interviewers here notice.
6. Weak behavioral answers. Vague "we" stories with no personal action and no numbers, which read as borrowed credit.

9The offer, comp and negotiation#

Indian SDE compensation at PolicyBazaar typically breaks into base salary, an annual performance bonus, and sometimes ESOPs or RSUs at senior levels (PB Fintech is publicly listed, so equity has a real, tradeable value).

Rough 2026 total-comp ranges:

• SDE-1: ~₹12-22 LPA.
• SDE-2: ~₹22-40 LPA.
• SDE-3/Lead: ~₹40-65+ LPA.
• Varies with location, interview performance, and competing offers.
• A big chunk of the senior number can be variable and ESOP, so always separate fixed from the headline.

Negotiation tips:

1. Get a competing offer if you can. One genuine alternative offer is the single biggest lever on your number. Be honest about it, do not bluff, because recruiters here talk to each other and a caught bluff costs you goodwill.
2. Negotiate the whole package. If base is capped by band, push on joining bonus, ESOPs, or level. Ask explicitly which lever has room, recruiters will usually tell you.
3. Anchor to level, not just number. If your machine-coding and design rounds went well, make the case for the higher band. The level drives every future raise more than the starting figure does, so an SDE-2 title is worth more over three years than a slightly higher SDE-1 base.

Before you accept:

• Always get the final offer in writing.
• Confirm the fixed-versus-variable split.
• Ask what the variable has historically paid out, not just the on-paper target.

10FAQ#

Q: How hard is the DSA at PolicyBazaar? Medium to hard. If you can reliably solve LeetCode-medium problems in ~25 minutes and handle the occasional hard, you are in range.

Q: Do I need to know their tech stack exactly? No. Strong fundamentals in one backend stack (Java/Spring or Node) plus SQL and basic distributed-systems concepts matter more than matching their exact tools. They would rather hire a strong Java engineer who can learn their stack than someone who memorized buzzwords.

Q: Is the machine-coding round really that important? Yes. For product and mid-senior roles it is often the round that sets your level. Practice building small, complete, runnable apps from scratch, not just solving puzzles. If you only grind LeetCode and skip this, you will underperform your level.

Q: How long does the process take? Usually 2-4 weeks from first round to offer, though it can compress for urgent roles or stretch around holidays and approvals.

Q: What should I ask my interviewers? Ask about the product area you would own, how they handle scale and reliability for money flows, team structure, and what success looks like in the first six months. Thoughtful questions read as genuine interest, and in a trust-first fintech that matters more than you would expect.

Want this turned into a personalized, dated prep schedule built around your interview date and your weak spots? Map your available days to the 4-week plan above and start with the pattern you fear most.