The interview process involved an initial discussion with a Senior Engineering Manager, an HLD round, a take-home assignment, a review of the assignment, and a final round with the CTO.

Exploratory Call - Senior Engineering Manager

I began with an introductory call with a Senior Engineering Manager. We discussed my professional background, previous projects, current responsibilities, and reasons for exploring new opportunities.

I also learned more about the company, the team, and the expectations associated with the role.

Round 1: HLD

I was asked to design a job scheduling system that executes tasks at a specified future time, with a maximum delay of 10 seconds.

The discussion focused on the system's architecture and how scheduled jobs would be managed and executed within the required time window.

Take-Home Assignment (Distributed Priority Queue)

For the assignment, I had to implement a distributed priority queue.

I made the solution more complicated than it needed to be. Instead of starting with a simple in-memory queue running on a single node, I designed a gateway and distributed the queue across multiple nodes.

This introduced additional challenges, especially when handling concurrent operations. I ended up spending more effort managing the complexity of the architecture than necessary.

In hindsight, I should have started with a simpler implementation and added distribution only if the requirements called for it.

Round 2: Assignment Review

The discussion mainly revolved around:

• Thread safety and concurrent access

• Locking mechanisms

• Scaling the queue across multiple nodes

• Maximum achievable throughput

• Identifying performance bottlenecks

The interviewer expected me to understand the implementation in depth and justify the decisions I had made.

One thing I would do differently next time is benchmark the maximum throughput before the interview so I could support my performance claims with actual measurements.

Since I had introduced a distributed architecture, I also had to reason about concurrency issues that wouldn't have been as complicated in a single-node implementation.

Round 3: CTO Interview

The final round started with a discussion about my background and previous projects before moving into technical questions.

MongoDB and Database Architecture

I was asked why I had selected MongoDB over PostgreSQL for my use case and what factors influenced that decision.

Another question explored how MongoDB Atlas supports migration between AWS and GCP while maintaining zero downtime.

Data Aggregation Across Microservices

I was presented with a scenario involving two microservices: one returning user information and the other providing order details.

I was asked how I would combine the responses and expose the resulting data to consumers.

The discussion then became more challenging when I was asked how I would support filtering on the combined dataset.

This required me to consider where the aggregation and filtering logic should reside and how to handle data coming from independent services efficiently.

Final Result

I was ultimately rejected for the position, but I didn't receive any detailed feedback explaining the decision.

What I Learned

A few things stood out to me after going through this process:

• Keep the design aligned with the requirements. I could have avoided unnecessary complexity by starting with a single-node queue before considering a distributed solution.

• Prepare to defend every design choice. During assignment reviews, understanding concurrency, locking, and scaling in detail is just as important as completing the implementation.

• Validate performance claims. Benchmarking throughput beforehand would have helped me explain the system's actual capabilities more confidently.

• Think carefully about service boundaries. Combining and filtering data across microservices requires clear decisions about where aggregation should happen and what trade-offs that introduces.

Overall, the experience reminded me that senior engineering interviews are not just about building sophisticated systems. I also need to demonstrate sound judgment, understand the implications of my design choices, and explain the trade-offs clearly.

• Company: PhonePe

• Role: Software Engineer

• Experience: 3 years and 4 months

• Location: Bangalore

• Final Result: Selected

The interview process consisted of four rounds:

• Machine Coding

• Problem Solving and Data Structures

• System Design

• Hiring Manager

Round 1: Machine Coding (2 Hours)

I was asked to design a PhonePe Wallet System that would allow users to add money to their wallets and transfer funds between users. There were a few additional functional requirements, although I don't remember all of them now.

I had 1.5 hours to implement the solution, followed by a 30-minute code review. The review focused on my implementation and the overall design of the solution.

Result: Positive

Round 2: Problem Solving and Data Structures (1 Hour)

I was given two coding problems:

1. Minimum Window Substring: The problem involved a variation of the standard Minimum Window Substring problem. I don't remember the exact constraints.

2. Job Sequencing Problem: I was asked to solve the classic scheduling and optimization problem.

Round 3: System Design (1 Hour)

I was asked to design a Customer Issue Resolution / Ticket Handling System, i covered both high-level design (HLD) and low-level design (LLD). I had to think through the system's overall architecture as well as its detailed components and interactions.

Round 4: Hiring Manager (1 Hour)

The round started with a deep dive into my projects, team, and day-to-day responsibilities, discussion mainly on the projects I had worked on.

The main areas of discussion were:

• Project decisions: The approaches I chose to solve different problems and why I preferred them over alternative solutions.

• Project impact: The outcomes and impact of my work.

• Engineering excellence: Tasks related to improving engineering practices and code quality.

• Design reviews: My involvement in design discussions and reviews.

• Career goals: My reasons for looking for a change and why I wanted to join PhonePe.

Final Outcome: Selected

I received the final confirmation four days after the interview process.

I have around 2 years of experience as a Java backend developer at a service-based company, recently i interviewed for the L4 Java Backend Engineer role at Target through an in-person hiring drive in Bangalore.

I applied through Target's careers portal and cleared the online assessment before attending the in-person interviews.

Online Assessment

I had to solve three coding problems during the assessment:

1. Task Scheduling Variation - Hard, involving Greedy and Priority Queue.

2. Array Problem

3. Topological Sort with Multi-Source BFS.

After clearing the assessment, I was invited to the in-person interview drive in Bangalore.

Round 1: Technical Interview

I started with a discussion about my current projects and the backend technologies I use in my work.

The main topics I covered were:

• Java fundamentals

• Spring Boot

• Kafka and messaging systems

• Database performance optimization

• Project-based scenarios and troubleshooting

Most of the questions were related to situations I had encountered in real projects. I had to explain how I approached different problems and why I chose particular solutions rather than simply recalling theoretical concepts.

I felt the discussion went well, and I received positive feedback.

Round 2: Projects, Pair Programming and Design Patterns

This round lasted approximately 85 minutes and was divided into three parts.

Project Discussion - 30 Minutes

I walked through my recent projects and explained the architecture, implementation choices, and reasoning behind my decisions. I also answered follow-up questions about the technical challenges I had encountered.

Pair Programming - 30 Minutes

I was given three bugs to identify and fix. I managed to resolve all three during the session.

The interviewer specifically appreciated my debugging ability and told me that my bug-fixing skills were very good.

Design Patterns - 30 Minutes

I was asked to implement two design patterns:

• Strategy Pattern: I used it to demonstrate how I could make behavior interchangeable and keep the implementation extensible.

• Factory Pattern: I discussed how I could simplify object creation and reduce dependencies on concrete implementations.

I completed the tasks and felt positive about how the round had gone.

However, when HR communicated the final decision, I was told that the interviewers had not found what they were looking for in this round, despite the positive feedback about my debugging skills.

Round 3: Hiring Manager

My hiring manager interview was initially scheduled for one hour but continued for approximately two hours.

One question that stood out to me was:

What problem existed before, and what problem does your solution solve?

I noticed that the discussion repeatedly returned to the reasoning behind my decisions, the alternatives I had considered, and the impact of my work.

Project Impact and Database Optimization

I discussed a project where I had contributed to reducing downtime by approximately 62%. I spent around ten minutes explaining the project and answering follow-up questions.

I then discussed database optimization, particularly when working with millions of rows.

The topics I covered included:

• Indexing and its impact on write performance

• Selecting only the columns required by a query

• Query optimizer hints

• Caching

• The N+1 query problem

• Database partitioning

• Sharding and replication, including their benefits, limitations, and use cases

When I explained my approach to partitioning, the hiring manager responded positively and said, “Exactly, I am looking for this from you.”

Security and Identity Management

Since I was interviewing for a Java backend role within Target's Cybersecurity/IAM team, I also discussed security concepts relevant to my banking-domain experience.

I answered questions about authentication versus authorization, JWT, encryption, and practical security scenarios.

I tried to connect these concepts to real-world applications rather than explaining them only in theoretical terms.

Messaging and Distributed Systems

I discussed the messaging technologies I had used in my projects and explained why I had chosen them.

The conversation covered:

• Why I used IBM MQ and the trade-offs involved

• Resilience patterns

• Circuit Breaker states and their behavior

• The Saga pattern

• Kafka and its role in my progress-tracking service

I also explained the problems these technologies addressed in my projects and how I had applied them.

Behavioral and Managerial Discussion

The hiring manager also asked me several questions about my working style and professional experience.

I discussed how I handle disagreements with a manager, measure my growth, manage tight deadlines, and balance my own deliverables against helping teammates.

Other questions covered why I wanted to join Target, why I was considering leaving my current organization, whether I had ever missed a deadline, and what feedback I had received about my communication.

I was also asked how I would handle a situation where I needed to deliver a service within two days and how I would support an upstream team facing an issue.

When asked about troubleshooting, I explained my usual process: checking logs and request-level behavior first, then investigating the application, database, gateway, and infrastructure as needed.

I rated my Java and Spring Boot skills at around 8 out of 10, while acknowledging that I still had room to improve.

Toward the end, the hiring manager explained some of the challenges I might encounter during my first 90 days and said the feedback would be shared with HR.

Final Result

I received a call from HR informing me that Target would not be moving forward with my application. I was told that my profile was not inclined for the role.

I was also informed that the second-round interview had not demonstrated what the interviewers were looking for, even though I had successfully fixed all three bugs and received positive feedback about my debugging skills.

I had felt reasonably confident after the first two rounds, and my conversation with the hiring manager had included several encouraging moments. However, I ultimately did not receive an offer.

I had 7+ years of experience and was working at a startup at the time.

The process consisted of an initial HR conversation followed by DSA and LLD technical discussions.

Round 1: HR Discussion

The first call was primarily an introductory conversation.

We discussed my professional background, previous projects, current responsibilities, and what I was looking for in my next opportunity.

The conversation was straightforward, and I moved ahead to the technical rounds.

Round 2: DSA

The next round focused on problem solving and data structures.

I was given a Longest Consecutive Sequence type problem and was asked to come up with an efficient solution rather than simply implementing the brute-force approach.

We discussed different ways to approach the problem, including the time and space complexity of each solution. I was able to work through the problem and explain the reasoning behind the final approach.

The interviewer also asked a few follow-up questions around edge cases and how the solution would behave with larger inputs.

This round went reasonably well, and I moved on to the LLD discussion.

Round 3: LLD - Rate Limiter

The next technical round started with a short introduction before moving into the main design problem.

I was asked to design a rate limiter that could apply different request limits to individual users.

Before starting the implementation, we discussed various rate-limiting algorithms and the situations where each one would be appropriate.

I decided to use the Sliding Window Counter approach.

The basic idea was to maintain request counts for the current and previous windows and calculate the effective request count using:

current_count + (previous_window_percentage × previous_count)

Where I Struggled

Although I understood the approach conceptually, I had difficulty translating the core algorithm into working code during the interview.

I haven't been writing this kind of low-level implementation manually as often since using AI coding tools such as Claude more regularly in my day-to-day work.

I was able to implement the user-specific threshold logic and several other parts of the rate limiter, but the central sliding-window calculation wasn't working correctly.

I spent the remaining time trying to fix the implementation, but I couldn't get it completely right before the round ended.

Looking back, I should probably have chosen the Sliding Log technique. It would have been somewhat easier for me to implement correctly under interview pressure, even though it has different memory and performance characteristics.

The interviewer asked if I had any questions at the end. By that point, I had a fairly good idea that the round hadn't gone well, so I didn't have any questions and wrapped up the call.

Final Result

I received the rejection the following day.

The main lesson I took away from this interview was that senior-level interviews test more than conceptual knowledge. Being able to implement the underlying logic yourself, reason through trade-offs, and choose an approach that you can confidently execute under time constraints is equally important.

For me, it was also a reminder that while AI tools can make day-to-day development much faster, it is still important to regularly practice writing core algorithms and logic from scratch.

Recently went through the hiring process for a Backend Engineer / SDE-1 position at District by Zomato.

I had around one year of internship experience at the time of the interview.

There were two technical discussions. Both were fairly interactive.

Round 1 - Problem Solving + Backend

The interview began with a DSA problem based on an integer array and a given value k.

The task was to determine the maximum-length contiguous segment in which the frequency of every number stays within k.

I approached it using a two-pointer/sliding-window technique combined with a hashmap. After explaining the idea, I walked through an example and discussed the complexity before implementing the solution in C++.

The conversation then shifted towards backend engineering. A lot of the questions were connected to technologies and concepts mentioned in my resume.

Discussed topics such as:

• How PostgreSQL indexes affect query performance

• Identifying slow queries using EXPLAIN ANALYZE

• Reducing database overhead through batching

• Differences between stateful and stateless services

• Designing REST endpoints that return large datasets

• Choosing between Kafka and SQS

• Partitioning and message ordering in Kafka

• Handling duplicate messages safely

• Monitoring services with Prometheus and Grafana

• Problems caused by high-cardinality metrics

The interesting part was the depth of the discussion. Whenever I mentioned an approach, the interviewer usually followed up with questions around the reasoning behind it, possible alternatives, and what could happen under higher load.

The conversation was comfortable overall, and I was given enough time to explain my thought process rather than having to rush through the answers.

Round 2 - API Design + Implementation

The second round focused heavily on backend design.

The initial requirement was to build an API that could return a user's District Money transaction history with pagination.

i used different ways of handling pagination and discussed the trade-offs between offset-based and cursor-based approaches.

For the cursor approach, we considered using createdAt together with transactionId so that the position within the result set could be tracked reliably. This also led to a discussion around suitable composite indexes, request/response structure, and the SQL required to retrieve the data efficiently.

Then the interviewer introduced another constraint: the transactions were distributed across three separate tables.

That changed the design discussion considerably, talked about:

• Whether JOIN or UNION ALL would be appropriate

• Fetching records independently from each table

• Combining the results within the application

• Maintaining ordering across multiple sources

• Continuing pagination correctly after merging the datasets

• The behavior of the solution as the volume increased

The round also required actual implementation. I had to write the backend logic as well as the SQL, rather than stopping at an architectural explanation.

At one point, the interviewer asked:

Apart from offset and cursor, what other way can you paginate?

I wasn't able to come up with another option immediately. The interviewer mentioned page-number pagination.

I explained that page-number pagination is generally implemented using an offset internally, where the offset can be calculated as:

(page - 1) × limit

I still wasn't completely sure what distinction the interviewer was looking for, but it was an interesting discussion.

The Part I Struggled With

The biggest challenge for me was the implementation itself.

The interviewer expected the code to be written cleanly and independently, without using an AI coding assistant. That's where I realized I had become somewhat dependent on AI-assisted development in my regular workflow.

Without those tools, my implementation wasn't as clean or structured as I wanted it to be.

That was probably the most useful takeaway from the process for me. AI can make development significantly faster, but it's still important to stay comfortable with writing, structuring, and debugging code independently when the situation demands it.

Result

I was not able to clear the process and was rejected after the second round.

I interviewed for the IC2 Software Engineer position at ServiceNow with close to 2 years of experience.

The complete process moved very quickly, with everything from the initial recruiter conversation to the offer being completed within four days.

The interviews covered a mix of DSA, project discussions, low-level design, and managerial conversations.

Offer Details

• Experience: 2 years 2 months

• Position: IC2 Software Engineer

• Base Salary: ₹26 LPA

• Annual Bonus: ₹2.6 LPA

• Total Cash: ~₹30 LPA

• RSUs: $30,000 over 4 years

• Final Outcome: Selected

The complete process was wrapped up quickly:

• Day 1: Recruiter Screening

• Day 2: Technical Round 1

• Day 3: Technical Round 2 + Managerial Round

• Day 4: Offer Confirmation

Recruiter Screening

The initial conversation was mainly about my professional background.

Discussion on my previous experience, current responsibilities, projects, compensation expectations, notice period, and my exposure to DSA and problem solving.

After clearing the screening, I moved to the technical rounds.

Technical Round 1: DSA + Projects

The interviewer began by discussing the projects I had worked on recently. The conversation went beyond a basic resume walkthrough and included questions about my contributions and technical decisions.

The coding section covered:

• LRU Cache - implementation and design discussion

• A Sliding Window based problem

• A Graph based problem

I was able to solve the coding questions and explain the reasoning and complexity of my solutions.

Feedback: Strong Hire

Technical Round 2: Project + DSA + LLD

The second technical round involved a much deeper discussion around my previous work.

The interviewer explored:

• System architecture

• Technology choices

• Scalability

• Design trade-offs

• Production issues

• Possible improvements to the existing systems

The DSA portion involved a Priority Queue / Heap-based problem, which I completed in around 10 minutes.

LLD: Food Delivery System

For the LLD portion, I was asked to design a food delivery platform similar to Zomato or Swiggy.

The discussion covered:

• Restaurant, customer, delivery partner, and order entities

• Restaurant and menu management

• Order placement and status transitions

• API design

• Database structure

• Assigning delivery partners to orders

• Handling multiple concurrent order requests

• Race conditions during order assignment

• Maintaining consistency across order states

We also discussed how the design could be extended as the number of users, restaurants, and orders increased.

No implementation was required; the focus was on the overall object model, responsibilities, and design decisions.

Feedback: Strong Hire

Managerial Round

The final discussion was with the hiring manager.

Since the technical feedback from the previous rounds was already positive, this round focused more on understanding my overall experience and working style.

We discussed:

• Projects I had worked on

• Technical decisions I had made

• Ownership and responsibilities

• Difficult production problems

• Team collaboration

• Career goals

• Behavioral and managerial situations

The conversation was fairly open and focused on how I approach engineering problems and work with a team.

The following day, I received a call confirming that I had cleared the interview process, followed by the official offer letter.

Background

• Company: CoinDCX

• Role: SDE 3

• Experience: 7+ years

• Current Organization: Startup

• College: Tier-1

• Current Compensation: ₹60L Base + ₹5L Bonus + ESOPs

DSA Round

Discussion was on problem solving and consisted of two questions.

The first was based on the idea of Wiggle Sort, although it wasn't the standard version of the problem. The solution involved identifying and counting valleys within a wiggle-sort pattern.

The second problem was:

Find all subsequences of a given string.

I solved this using backtracking, exploring the possible choices at each position to generate the required subsequences.
Similar Pattern problem:

LLD

The problem was to design a Crypto Matching Engine.

The discussion focused on structuring the system and thinking through how the different components of a matching engine would interact.

What's Next?

According to HR, the remaining stages will be conducted from the office.

The upcoming rounds are expected to cover:

• HLD / System Design

• Managerial discussion

At the moment, I’m waiting for the next round.

I participated in Slice’s on-campus hiring process for the SDE-1 Backend Intern and FTE role.

Online Assessment

The process started with an online assessment consisting of two coding problems with a total time limit of 90 minutes.

Both problems were around the medium difficulty level, so managing time and getting both solutions working within the given window was important.

Round 1: AI-Assisted Machine Coding

Duration: 75 minutes

This round was quite different from a traditional DSA interview. The focus was on building a working backend project from scratch rather than solving individual algorithmic problems.

The official guidelines were shared only two days before the interview. We were allowed to use any programming language and could choose in-memory storage, SQLite, MongoDB, or a similar setup depending on the problem.

Chat-based AI tools were also permitted, but the screen had to be shared throughout the round. Agentic tools were not allowed.

For my round, I was asked to build a Parking Lot Management System.

The problem involved designing the core entities and implementing functionality around:

• Vehicle entry and exit

• Parking slot allocation

• Different vehicle types

• Availability and slot management

• Handling the overall flow through a working application

From what I discussed with friends who were part of the same campus drive, some other problems:

• Personal Finance Tracker - users, transactions, income/expense summaries and REST APIs

• Student Attendance System - teacher/student roles and authentication

• Movie Booking System - shows, seat selection, booking and seat-level concurrency

• Spending Limits Service - in-memory implementation with per-transaction limits, rolling 24-hour limits, rolling 1-hour transaction counts, and APIs such as authorize and getUsage

The main thing being evaluated seemed to be how well you could translate requirements into a working implementation while making reasonable design decisions.

Round 2: Hiring Manager

Duration: 45 minutes

The final round was mostly conversational and focused heavily on my resume and previous projects.

The interviewer started with a brief introduction and then picked areas from my resume for a deeper discussion. Some of the discussion revolved around:

• Project architecture and design decisions

• Why I chose a particular technology stack

• How different components of the system work

• What happens when multiple requests access the system concurrently

• How I would improve or redesign parts of my projects

• Why I chose backend engineering

• Why I wanted to join Slice

• How I currently use AI in my development workflow

There were quite a few follow-up questions, so having a clear understanding of everything mentioned on the resume was important.

Offer

I received an offer for a 6-month internship from January to June 2027 with a stipend of approximately ₹1 lakh per month.

The internship also comes with an FTE opportunity based on performance, with the first-year compensation being around ₹36 LPA.

I got this question in my Amazon OA and wasn't able to solve it during the test. Sharing it here in case someone can explain the optimal approach.

Problem

You are given:

• An array shipmentOrder of length n

• shipmentOrder is a permutation of numbers from 1 to n

• An integer windowSize

You have to perform the following operation exactly once:

1. Choose any contiguous subarray of length windowSize.

2. Sort that subarray in ascending order.

3. Keep all other elements unchanged.

Your goal is to find the lexicographically largest array possible after performing this operation.

An array is lexicographically larger if, at the first position where two arrays differ, it has the larger value.

Example

shipmentOrder = [5, 1, 4, 3, 2]
windowSize = 3

There are 3 possible windows:

Choose index 1:

[5, 1, 4] → [1, 4, 5]

Result: [1, 4, 5, 3, 2]

Choose index 2:

[1, 4, 3] → [1, 3, 4]

Result: [5, 1, 3, 4, 2]

Choose index 3:

[4, 3, 2] → [2, 3, 4]

Result: [5, 1, 2, 3, 4]

Now compare the three results:

[1, 4, 5, 3, 2]
[5, 1, 3, 4, 2]
[5, 1, 2, 3, 4]

The lexicographically largest array is:

[5, 1, 3, 4, 2]

Another Example

shipmentOrder = [5, 4, 3, 2, 1]
windowSize = 3

Possible results:

Choose 1 → [3, 4, 5, 2, 1]
Choose 2 → [5, 2, 3, 4, 1]
Choose 3 → [5, 4, 1, 2, 3]

The answer is:

[5, 4, 1, 2, 3]

because it preserves the longest possible prefix [5, 4].

Constraints

1 <= windowSize <= n <= 2 * 10^5
shipmentOrder is a permutation of [1, 2, ..., n]

Function

maximizeShipmentOrder(shipmentOrder, windowSize)

Return the lexicographically largest array that can be obtained.

I couldn't figure out an efficient approach for n up to 2 * 10^5.

Can anyone explain the optimal approach or provide a solution?