← Interview experiences
Rejected

Software Engineer at Practo

Difficulty
Process took
1-2 Weeks
Rounds
3
Format
Remote
Applied via
Company Website

How it went

  • Don’t take rejection personally, sometimes it is about fit, not just skills. It is okay to be disappointed, but try to learn from every interview.

What they would tell you

  • Don’t take rejection personally, sometimes it is about fit, not just skills. It is okay to be disappointed, but try to learn from every interview.

How to prepare

I waited for a few days, hoping for good news. Instead, I got a short email, rejected No explanation, no feedback

Round by round

  1. 1

    Technical Round 160 min

    The recruiter scheduled a video call for the first round. I was nervous, but I told myself to stay calm. The interviewer started with a quick hello and explained the format: two coding problems. First one was Maximum Subarray, I remembered the standard approach (Kadane’s algorithm), explained it step by step, and wrote the code. The second problem was an easy array-based question, similar to what you see on Leetcode. It didn’t slow me down. I finished both quickly, and the interviewer seemed happy with my answers.

  2. 2

    Technical Interview60 min

    The first part was DSA again Next, he asked about design patterns. I explained the **Strategy Pattern, **wrote a simple example in Java. Then, he asked a few questions about Java 8 Streams and Lambdas. I gave examples of filtering, mapping, and collecting data using streams, which I use at work, so this part felt natural. Finally, he threw in a couple of **SQL queries, **mainly around joins and aggregations. I wrote them out and explained how I’d optimize them if the table got bigger. Honestly, this was a fun round. I liked that it wasn’t only about coding but also about real-world Java and database knowledge.

  3. 3

    System Design60 min

    The interviewer asked me to design a notification service that could handle emails, SMS, app notifications I started by listing the RESTful APIs I’d need send, schedule, check status, and maybe a retry. Then drew out a database schema with users, notifications, status logs, and so on. I talked about indexing and sharding for scale. Next, I described the flow a load balancer takes requests, routes them to microservices, which then publish to Kafka topics. Each channel (email, SMS, etc.) gets processed by its own set of consumers, which can auto-scale if the load increases. The interviewer asked some follow-ups: What happens if Kafka goes down? How do I ensure the system tolerates failures? I did my best, but I’m sure I missed a few things, real systems are always more complex than whiteboard diagrams. I was proud of my effort. I tried to cover all the bases, but I know there were places I could have gone deeper or been clearer.

What came up

MediumRemote5+ years

A candidate-reported account, lightly edited. Interview processes change by team and date.

Sources