The interview process consists of one screening and four rounds: 1. Hackerrank test (camera required): This part was smooth and well-structured. My test involved four questions: one “complete the code” task, one SQL aggregation question, and two LeetCode-style medium problems. 2. Technical Interview: The job description emphasized deep experience with event-driven architectures, Kafka, distributed systems, and general JVM-language backend development. Based on that, I expected the technical round to explore real engineering scenarios, trade-offs, design discussions, and my experience building such systems. The interviewers did touch on topics like Kafka, event-driven architecture, databases, observability, and CI/CD, but almost entirely through surface-level theoretical questions rather than digging into real-world experience. The only section where they probed deeply was JVM internals — specifically trivia-style questions about object allocation, the heap, and which objects get garbage collected in a short code snippet. What makes this more concerning is the feedback I received afterward: they explicitly said my event-driven and distributed systems knowledge was strong (the very skills highlighted in the job description), but rejected me due to a lack of depth in JVM internals. This is puzzling, because low-level JVM behavior of that sort is not typically part of daily work for senior backend engineers unless the role is explicitly focused on performance internals. The mismatch between what the role advertised and what the interview prioritized was significant. The technical assessment seemed weighted toward JVM trivia rather than the practical engineering skills needed to build and scale event-driven systems. Candidates should be aware that despite the job description, the evaluation criteria may lean heavily on detailed JVM internals rather than the applied, senior-level architectural and systems knowledge the role appears to require.