Loading…
Real-world interview experiences, recruiter conversations, technical discussions, career reflections, and lessons learned while navigating software engineering opportunities.
June 5, 2026
NetApp Interview Experience: An Honest Conversation About Experience, Growth, and Expectations Today I had an interesting conversation with someone from NetApp. The opportunity came through a referral, and from the moment the call started, I could tell this wasn't going to be one of those scripted recruiter conversations. The interviewer was direct, practical, and focused on understanding what I had actually built throughout my career. Tell me about yourself The first question was simple. "Tell me about yourself." I explained that I am a Full Stack Engineer with around eight years of experience building web applications and SaaS products. Over the years, I've worked across different domains, building products from the ground up and helping teams deliver software that solves real business problems. Instead of spending too much time on titles or buzzwords, I focused on the kind of work I've been doing throughout my career. What SaaS products have you built? The next question came immediately. "What SaaS applications have you built?" I spoke about one of the more interesting products I worked on—a facility management platform called Pinch, built for residential communities in Gurgaon. To make the concept easier to understand, I explained that it was somewhat similar to MyGate. The platform helped communities manage visitors, maintenance activities, resident communication, and operational workflows. The discussion wasn't about technical jargon. It was about understanding whether I had experience building software that real users depended on every day. Walking Through My Career Journey The conversation then shifted to my professional journey. I talked about where I started and how my career evolved—from my time at Vawsum to my current role at Unify. Rather than listing companies, I explained how each role contributed to my growth as an engineer. Every product, team, and challenge taught me something different about software development, architecture, and working with customers. The Microservices Question One of the questions was about microservices experience. "Have you worked with microservices?" I answered honestly. I told him that I had built one application using a microservices architecture, but most of my experience has been in building and maintaining larger applications that did not necessarily require a microservices approach. I didn't want to exaggerate my experience. Technical interviews often reward confidence, but long-term careers are built on credibility. It felt better to be transparent about what I had actually done rather than claim expertise I didn't possess. Discussing Personal Projects The conversation became much more engaging when he asked about personal projects. I spoke about one of my recent projects: Blog MCP. Instead of focusing only on the technical implementation, I explained why I built it. For me, personal projects are rarely about showcasing technology. They are usually an attempt to solve a problem, explore a new idea, or learn something deeply. Blog MCP came from a desire to experiment with AI-assisted content creation and publishing workflows while understanding how modern AI systems can interact with external tools. The project allowed me to combine software engineering, automation, AI, and product thinking into something tangible. I think this part of the conversation resonated more because it revealed how I think as an engineer outside of day-to-day work responsibilities. The Reality Check Toward the end of the discussion, he gave me straightforward feedback. He mentioned that he wasn't yet comfortable referring me for the Technical Lead role. At first glance, some people might see that as a rejection. I didn't. Instead, he said he could arrange a conversation for an IC2 (Individual Contributor) role. I appreciated the honesty. Sometimes the most valuable feedback isn't hearing "yes." It's understanding where someone believes your current profile fits and what gaps you need to close to reach the next level. He also asked about my current compensation, which is a fairly standard part of these discussions. My Takeaway I told him that I was open to the IC2 conversation. My reasoning was simple. If there's an opportunity to learn, understand the expectations of a company like NetApp, and identify areas where I need to grow, why not take the conversation? Not every interview needs to result in an offer. Sometimes interviews act as mirrors. They show you how the market views your experience, where your strengths are, and what skills you need to develop next. This call felt less like an evaluation and more like an honest assessment of where I currently stand. And that's valuable information for any engineer trying to grow.
June 5, 2026
Amura Health Interview Experience: The Most Unexpected Rejection Came After the Call Recently, I received a call regarding a Senior Engineer opportunity at Amura Health, a company based in Chennai. The conversation itself wasn't particularly unusual at first. In fact, it started exactly the way most recruiter calls do. What made the experience memorable was how unexpectedly it ended. The Spam Call That Wasn't Spam When my phone rang, I almost ignored it. The caller ID on my phone had actually marked the number as spam. Normally, that's not the best first impression when you're trying to recruit someone. Fortunately, I picked up. The caller introduced herself and explained that she was reaching out regarding a Senior Engineer position at Amura Health. The Usual Career Conversation The first part of the discussion was fairly standard. She asked me to introduce myself and walk through my professional journey. I spoke about my background as a Full Stack Engineer, the products I had worked on, and the progression of my career across different companies and projects. As the conversation continued, I got the feeling that she wasn't particularly technical, which is completely normal for many HR and recruiting roles. Most of the discussion revolved around experience, responsibilities, and previous work. Then Came the Surprise The next part caught my attention. She explained that the role was completely work from office. Not hybrid. Not flexible. Not occasionally in office. Completely work from office. Then came another detail. It was a six-day work week. That definitely wasn't something I hear very often anymore. The company also expected relocation to Chennai if selected. Naturally, I asked about relocation assistance. The answer surprised me again. There wasn't a relocation package or bonus. Instead, they would provide contacts and references for people who could help find accommodation nearby. I appreciated the honesty, even though it wasn't exactly what I expected to hear. We also discussed my current compensation and expected compensation, and the conversation moved forward. HR Asking Technical Questions? Then something unexpected happened. The recruiter started asking technical questions. Over the years, I've noticed that recruiters are becoming increasingly comfortable asking basic technical screening questions before forwarding candidates to engineering teams. Still, I wasn't expecting system design style questions during an HR screening call. Why is the application opening slowly? Her first question was straightforward. "Suppose an application is opening slowly. How would you debug it?" I explained that the first step would be identifying where the bottleneck exists. If API responses are slow, that immediately impacts the user experience. Depending on the situation, introducing a caching layer could significantly reduce response times and decrease load on backend services. If the slowdown originates from the database, I would investigate query performance, indexing strategies, execution plans, and data access patterns. The goal is always to identify the actual bottleneck before attempting a solution. How do you prevent the database from crashing under heavy traffic? The second question was even more interesting. "What would you do if too many requests were causing the database to crash?" I explained that one approach is to control how traffic reaches the database rather than allowing unlimited requests to hit it directly. Message queues can help absorb traffic spikes and smooth out workloads. Connection pooling ensures applications reuse database connections efficiently instead of creating excessive connections under load. Combined with rate limiting, caching, and proper architecture, these approaches help protect databases from becoming overwhelmed. The answer seemed to satisfy her. The Next Round Sounded Unusual Toward the end of the conversation, she informed me that the next round would be technical. That sounded normal. Then she mentioned something that felt a little unusual. The technical round would also happen over a regular phone call. Not a video meeting. Not a coding platform. Not a screen-sharing session. Just another phone call. At that point I remember thinking, "That's interesting." Still, I agreed. Every company has its own hiring process, and I was curious to see where this would lead. The Rejection That Arrived Before the Next Round A while later, I received an email. The message was brief. The company had decided not to move forward with my profile at this time. And just like that, the process ended. No technical round. No follow-up discussion. No additional evaluation. Just a rejection email after a conversation that had sounded reasonably positive. My Takeaway What made this experience memorable wasn't the rejection itself. Rejections are part of every engineer's career. What stood out was how quickly the direction changed. One moment we were discussing future interview rounds, and the next moment the process was over. Perhaps another candidate was a stronger fit. Perhaps the compensation expectations didn't align. Perhaps they were looking for a different background entirely. The reality is that candidates rarely get complete visibility into hiring decisions. What I took away from the experience was a reminder that interview outcomes are not always predictable. A conversation can feel positive and still end with a rejection. A difficult interview can sometimes result in an offer. The best approach is to treat every interview as an opportunity to learn, communicate clearly, and move on to the next opportunity regardless of the outcome. Sometimes the most interesting interview stories are not the ones that lead to offers—they're the ones that leave you wondering what happened.