PolicyBazaar Software Development Engineer (SDE) Interview Experience | DSA, Core CS & System Design

• Company: PolicyBazaar
• Role: Software Development Engineer (SDE)
• Interview Mode: Remote
• Difficulty Level: Medium
• Total Rounds: 3
• Interview Timeline: 2–3 Weeks
• Application Method: Email
• Result: Rejected

Recently, I interviewed with PolicyBazaar for a Software Development Engineer (SDE) role. The overall interview process was well-structured and primarily focused on evaluating problem-solving skills, computer science fundamentals and system design knowledge. Although I couldn't convert the opportunity into an offer, the experience was highly educational and helped me identify areas where I could improve.

Unlike interviews that focus solely on coding, this process assessed multiple dimensions of software engineering. From fundamental concepts like Object-Oriented  Programming, DBMS and Operating Systems to practical coding questions and a production-oriented system design discussion, every round tested a different aspect of software development.

Here's a detailed breakdown of each interview round and my experience.

Round 1 : Online Assessment (Core CS Fundamentals)

Duration: 60 Minutes

Difficulty: Medium

Mode: Remote

The first round was an online assessment consisting entirely of multiple-choice questions. There were no coding problems in this round, but the questions required a solid understanding of computer science fundamentals.

The assessment primarily focused on topics that every software engineer is expected to know. Instead of asking deep theoretical questions, most questions tested practical understanding and logical reasoning.

The major topics included:

• Object-Oriented Programming (OOP)
• SQL and DBMS
• Operating Systems
• Output prediction
• Pseudocode-based reasoning

The OOP questions covered concepts like inheritance, abstraction, polymorphism, encapsulation, constructors, interfaces and method overriding. Some questions required identifying the correct implementation, while others tested conceptual clarity through code snippets.

The SQL section mainly contained query-based questions involving joins, grouping, aggregate functions, primary keys, foreign keys and normalization. There were also a few output prediction questions where the final result of a query had to be determined without executing it.

The Operating Systems questions revolved around processes, threads, synchronization, scheduling algorithms, deadlocks and memory management. Most of these were conceptual and straightforward if the fundamentals were clear.

Another interesting section included pseudocode-based questions. These required analyzing small pieces of logic and predicting the final output. Although they looked simple, many involved tricky edge cases that tested careful observation rather than memorization.

Overall, the assessment wasn't particularly difficult, but it rewarded candidates who had revised the basics thoroughly. Since there was no negative marking, I attempted every question.

Topics Asked

• Object-Oriented Programming
• SQL Queries
• DBMS Concepts
• Operating Systems
• Output Prediction
• Pseudocode-based Questions

My Preparation

For this round, I revised the majority of my core CS subjects using concise one-shot YouTube videos. Rather than reading lengthy textbooks, I focused on refreshing important concepts and practicing MCQs from previous interview experiences. This strategy worked well because the questions emphasized conceptual understanding rather than advanced theory.

Round 2 : Technical Coding Interview

Duration: 60 Minutes

Difficulty: Medium

Mode: Remote

The second round was a live coding interview where the interviewer presented two Data Structures and Algorithms problems. Before writing any code, I was expected to explain my thought process, discuss different approaches, analyze complexities and only then proceed with implementation.

The interviewer paid close attention to communication. Instead of immediately jumping into coding, I first clarified the problem statement, discussed edge cases and explained why a particular solution would be optimal. This collaborative discussion seemed to be appreciated and helped create a positive flow throughout the interview.

Problem 1 : Remove Duplicates from Sorted Array

The first problem was the classic Remove Duplicates from Sorted Array. Since the input array was already sorted, I immediately recognized that duplicate elements would always appear next to each other. Instead of using an additional data structure like a HashSet, I explained that the sorted property allows us to solve the problem in-place using the Two Pointer technique.

My approach involved maintaining two pointers:

• One pointer traversed every element in the array.
• The second pointer tracked the position where the next unique element should be placed.

Whenever a new unique value was encountered, I copied it to the write pointer and advanced it. This allowed the array to be modified in-place while maintaining O(1) extra space.

The interviewer asked why this solution was better than using a HashSet. I explained that although a HashSet would also eliminate duplicates, it would require additional memory, whereas the Two Pointer solution achieves the same result using constant extra space.

public class Solution
{
    public int RemoveDuplicates(int[] nums)
    {
        if (nums == null || nums.Length == 0)
            return 0;
        int write = 1;
        for (int read = 1; read < nums.Length; read++)
        {
            if (nums[read] != nums[read - 1])
            {
                nums[write] = nums[read];
                write++;
            }
        }
        return write;
    }
}

After discussing the approach, I implemented the solution and walked through a dry run to verify its correctness.

Problem 2 : Copy List with Random Pointer

The second problem was considerably more interesting. I was given a singly linked list where each node contains:

• A next pointer pointing to the next node in the list.
• A random pointer which can point to any node in the list or null.

The task was to create a deep copy of the linked list.

A deep copy means:

• Every node in the new list must be a completely new object.
• The next structure must be preserved.
• The random pointer relationships must also be preserved.
• No node in the copied list should reference any node from the original list.

Example Original List:

A → B → C
|    |    |
↓    ↓    ↓
C    A    B

Expected Output: Copied List:

A' → B' → C'
|     |     |
↓     ↓     ↓
C'    A'    B'

My Initial Approach (HashMap)

Initially, I mentioned the standard HashMap-based solution, where:

• First pass: create a copy of each node and store mapping {original → copy}
• Second pass: assign next and random pointers using the map

This approach is easy to implement but requires:

• O(n) extra space

Optimized Approach (No Extra Space)

The interviewer then asked whether we could solve it without using extra space. I explained the optimized three-step interleaving approach:

Step 1: Interleave copied nodes

Insert copied nodes immediately after their original nodes.

• A → A' → B → B' → C → C'

Step 2: Assign random pointers

Since each copy is next to its original node:

• copy.random = original.random.next

This works because:

• original.random points to some node X
• X’s copy is always X.next

Step 3: Separate the lists

Restore the original list and extract the copied list as an independent structure.

// Definition for a Node.
public class Node
{
   public int val;
   public Node next;
   public Node random;

   public Node(int _val)
   {
       val = _val;
       next = null;
       random = null;
   }
}

public class Solution
{
   public Node CopyRandomList(Node head)
   {
       if (head == null)
           return null;
       // Step 1: Insert copied nodes after original nodes
       Node current = head;

       while (current != null)
       {
           Node copy = new Node(current.val);
           copy.next = current.next;
           current.next = copy;

           current = copy.next;
       }
       // Step 2: Assign random pointers for copied nodes
       current = head;

       while (current != null)
       {
           if (current.random != null)
           {
               current.next.random = current.random.next;
           }
           current = current.next.next;
       }

       // Step 3: Separate the two lists
       current = head;
       Node dummy = new Node(0);
       Node copyCurrent = dummy;

       while (current != null)
       {
           Node copy = current.next;
           current.next = copy.next;   // restore original list
           copyCurrent.next = copy;    // build copied list
           copyCurrent = copy;
           current = current.next;
       }

       return dummy.next;
   }
}

Round 3 : System Design + Managerial Discussion

Duration: 60 Minutes

Difficulty: Hard

The final round was significantly different from the previous ones. Instead of writing code, the discussion focused on system design, software architecture, previous projects and behavioral questions.

The primary design question was: Design a Flight Booking System.

Rather than expecting a perfect architecture, the interviewer was more interested in understanding my design thought process.

I began by gathering requirements and identifying the core functionalities such as searching flights, viewing seat availability, booking tickets, making payments, cancellations and notifications. From there, I gradually broke the system into smaller services, including:

• User Service
• Flight Search Service
• Booking Service
• Payment Service
• Notification Service

The discussion then shifted toward scalability. The interviewer asked several follow-up questions, including:

• How would you prevent two users from booking the same seat?
• What happens if the payment succeeds but the booking fails?
• How would you handle payment failures?
• How would the system behave during heavy traffic?
• Where would caching improve performance?
• Which database would you choose and why?

These questions transformed the conversation into a real architecture review rather than a textbook system design interview.

A significant portion of the round also involved discussing my previous projects. The interviewer asked why certain architectural decisions were made, what design patterns were used, how application performance was improved and how I handled production-level challenges.

Finally, the interview concluded with several behavioral questions about teamwork, leadership, ownership, conflict resolution and handling tight deadlines.

Overall Experience

Overall, I found the interview process to be balanced and practical. Each round evaluated a different skill set, ensuring that candidates possessed not only coding abilities but also strong fundamentals, communication skills, architectural thinking and problem-solving capabilities.

The coding questions were standard interview problems, but the interviewers placed considerable emphasis on explaining the reasoning behind each solution rather than simply producing working code. Similarly, the system design round focused less on memorizing architectures and more on making thoughtful design decisions while discussing scalability, reliability and trade-offs.

Although I wasn't selected, the experience highlighted several areas where I could improve, particularly in articulating design decisions and discussing trade-offs more confidently.

Preparation Tips

If you're preparing for a PolicyBazaar SDE interview, here's what I'd recommend:

• Build a strong foundation in Object-Oriented Programming, DBMS, Operating Systems and SQL.
• Practice common array, linked list, tree, graph and dynamic programming problems on LeetCode.
• Always explain your approach before writing code.
• Learn to analyze time and space complexity for every solution.
• Revise common output prediction and pseudocode questions.
• Prepare your projects thoroughly, as interviewers often explore implementation details.
• For System Design, focus on requirement gathering, scalability, caching, database selection and discussing trade-offs rather than memorizing diagrams.

Final Thoughts

Although I received a rejection, I consider this interview a valuable learning experience. The process reinforced that clearing software engineering interviews requires much more than solving coding problems. Companies look for engineers who can communicate effectively, justify technical decisions, understand computer science fundamentals and design systems that can scale in production.

One of the biggest lessons I learned was that interviewers appreciate candidates who think out loud. Explaining assumptions, discussing alternatives and reasoning through trade-offs often leaves a stronger impression than simply arriving at the correct answer.

If you're preparing for PolicyBazaar or similar product-based companies, focus equally on DSA, core CS concepts, project discussions and system design. A balanced preparation strategy will significantly improve your chances of success.

Recommended Interview Experience