New Relic Backend Interview Experience (SSE | 4 YOE)
Hi everyone! I recently interviewed with New Relic for a Senior Software Engineer (Backend) role. I wanted to share my interview experience and the types of discussions that took place. Hopefully, this helps others preparing for similar backend engineering interviews.
Round 1 - Coding(DSA)
The first round consisted of two coding questions.
Before getting into the questions, I would like to mention that the interviewer made the experience really enjoyable. He was very approachable and encouraged discussion throughout the interview. Rather than expecting the perfect solution immediately, he provided subtle hints whenever I got stuck and guided me in the right direction without giving away the answer. It genuinely felt like he had a deep understanding of algorithms and problem-solving, and the discussion was more collaborative than stressful. It was one of the best coding interview experiences I've had.
Question 1:
Implement a method to perform basic string compression by counting consecutive repeated characters.
If the compressed string is not smaller than the original string, return the original string.
The discussion focused on:
Time and Space Complexity
Edge cases
Code optimization
Question 2:
Find the length of the Longest Increasing Path in a Matrix.
Constraints:
Move only in four directions (Up, Down, Left, Right).
No diagonal movement.
No wrap-around.
The interviewer expected a DFS-based approach initially and later asked me to optimize and execute it.
Round 2 - Distributed Systems Design
The second round was communicated as an HLD/LLD interview. However, the discussion turned out to be centered around designing a distributed event-processing system rather than a conventional HLD or LLD exercise.
The interviewer first explained how distributed tracing works in observability platforms and then introduced the problem.
Problem Statement
Design a system that consumes trace events from Kafka and processes all events belonging to the same trace together.
Assumptions provided during the discussion:
Events are received through Kafka.
Every event contains a traceId.
Events belonging to the same trace share the same traceId.
A trace can last from a few seconds to several hours.
The actual processing logic is not important; assume there is a method that processes all events of a trace together.
The discussion then evolved around:
Grouping events by traceId
Whether an in-memory approach would scale
Using an external datastore for trace state
Memory constraints with long-running traces
Determining when a trace is complete
Retrieving grouped events for processing
Handling traces that may run for hours
Trade-offs between different design approaches
Throughout the discussion, the interviewer consistently steered the conversation back to the core problem of event grouping and trace lifecycle management, rather than focusing on Kafka APIs or the downstream processing itself. While the outcome wasn't what I had hoped for, I genuinely enjoyed the discussion and came away with a much better understanding of how to approach distributed systems and stateful stream-processing problems.
My biggest takeaway from this interview was that not every design round follows a traditional HLD or LLD format. Sometimes, interviewers are more interested in how you reason about ambiguity, scalability, and state management than in the final architecture itself.
Thank you for reading!