My Associate SDE Interview at CarWale: A Story of Rejection and Key Learnings

Rejection can be tough, but it's also a powerful teacher. Recently, I had my very first interview for the Associate Software Development Engineer role at CarWale (CarTrade Tech). Unfortunately, I didn't make it through, but the experience was incredibly eye-opening, clearly showing me exactly where I stand and what I need to focus on for improvement.

My Introduction

I was naturally nervous but excited. As a final-year engineering student with a couple of internships and a passion for full-stack development, I thought I was well-prepared. I had practiced my introduction many times, but when the actual moment came, I realized I made a few critical mistakes:

• I made my introduction too long, trying to squeeze in every detail instead of keeping it concise and impactful.
• I focused too much on my achievements rather than explaining what I truly learned or contributed.
• My delivery sounded memorized instead of conversational and natural.

It was my first real interview, and my nervousness definitely showed.

Conceptual Questions

The interviewer began with some conceptual questions.

Question 1: “What is frontend, full-stack, and testing?” This should have been an easy start, but I struggled to give short, clear definitions despite having worked extensively in these areas. It taught me that knowing something and explaining it clearly under pressure are very different skills.

Question 2: “What is the difference between short polling, long polling, and WebSockets?” This question went much better. I managed to explain the differences clearly and even connected it to a project where I had implemented real-time updates using WebSockets. That felt like a small win.

The Coding Round

Next came the live coding tasks, which truly tested both my coding abilities and communication skills.

Challenge 1: Create a REST API Endpoint I successfully implemented the endpoint, ensuring proper status codes and functionality. However, during my explanation, I casually mentioned “MVC architecture.” The interviewer immediately asked me to explain the ‘M’ and ‘V’ components, and I completely blanked out. This taught me a golden rule: Never use a term unless you can explain it confidently.

Challenge 2: Binary Search I wrote the binary search code correctly. But when asked about the difference between mid = (l + r) / 2 and mid = l + (r - l) / 2, I couldn't provide an answer. Later, I realized the second version prevents integer overflow — a subtle but crucial detail that distinguishes a student coder from an interview-ready engineer.

Challenge 3: Rotate an Array K Times I started with a brute-force solution. The interviewers provided hints towards an optimal solution, and although I eventually reached it with their help, I couldn't figure it out on my own. It highlighted another major weakness: I was too focused on coding silently instead of thinking out loud and narrating my thought process.

The Outcome

I didn't make it through the interview. However, looking back, I now understand exactly why, and that clarity is the most valuable reward. This experience exposed the precise gap between being a good student developer and an industry-ready engineer. Now, I know exactly what to fix, and I'm already working on it. On to the next one! 🚀