super.money | SDE3 | Banglore | January 2025 [Passed]

super.money logo
super.money
SDE 3bangloreOffer
February 18, 202573 reads

Summary

I recently interviewed for an SDE 3 role at super.money in Bangalore and received a positive verdict, resulting in an offer for an SDE-2 position. The overall experience was very supportive and focused on collaborative discussions.

Full Experience

I recently had an interview opportunity for an SDE 3 role at super.money in Bangalore. The entire process was quite positive and consisted of five rounds, covering various aspects of software engineering.

Round 1: Data Structures & Problem Solving

This round focused on my problem-solving abilities and understanding of data management. I was asked about:

  • Database Migration: How to migrate data from one database to another with minimal downtime, discussing strategies and tools involved.
  • Oncall Scenario: An API SLA breach (>100ms) where I had to outline the steps to investigate, diagnose, and mitigate the issue.

Round 2: High-Level Design (HLD)

In this round, the task was to design an online chess system. The interviewer specifically wanted me to focus on the matchmaking component, emphasizing a First-Come, First-Served (FCFS) approach.

Round 3: Machine Coding

This was an implementation-heavy round where I had to build a Pub-Sub (Publisher-Subscriber) library. The requirements were quite detailed and included:

  1. The library needed to clearly define `Topic`, `Publisher`, and `Consumer` entities, allowing publishers to send messages to a topic and multiple consumers to subscribe.
  2. Support for multiple consumers and publishers per topic.
  3. Functionality to manage topics, including creating and deleting them.
  4. Consumers should be able to consume messages as they are received.
  5. The ability to publish messages in parallel.
  6. Robust and graceful exception handling.
  7. Implementation of offset management for consumers.
  8. Topics should have a maximum retention period for messages.
  9. [Bonus-1] The ability to reset offset and replay messages from a particular offset.
  10. [Bonus-2] Visibility into consumer/topic status based on last offset read or lag.

Round 4: Low-Level Design (LLD)

For this round, I was asked to design Google Calendar from a low-level perspective. This involved outlining API endpoints, discussing suitable design patterns, and defining the classes and their interactions within the system.

Round 5: Project Deep Dive [Hiring Manager]

The final round was with the Hiring Manager, where we discussed my past projects in detail. This included exploring the technical challenges I faced, the solutions I implemented, and the impact of my work.

Overall, it was a very positive experience. Each interviewer was supportive and helpful throughout the process. They were open to listening to my thoughts and encouraged discussions rather than just evaluating answers. I received a verdict of Hire for SDE-2, which I consider a positive outcome.

Interview Questions (5)

Q1
Database Migration with Minimal Downtime
Other

Discuss how to migrate data from one database to another while ensuring minimal downtime during the migration process. Focus on strategies, tools, and best practices.

Q2
API SLA Breach Investigation and Mitigation
Other

Describe the steps you would take to investigate, diagnose, and mitigate an API SLA breach where the response time exceeds 100ms. Detail the tools, metrics, and procedures you would follow.

Q3
Design Online Chess Matchmaking (FCFS)
System DesignHard

Design an online chess system, with a specific focus on the matchmaking component. The matchmaking should follow a First-Come, First-Served (FCFS) principle.

Q4
Design and Build a Pub-Sub Library
Data Structures & AlgorithmsHard

Design and implement a Pub-Sub (Publisher-Subscriber) library with the following core capabilities:

  1. Core Components: The library must clearly define the concepts of a Topic, Publisher, and Consumer. A publisher sends messages to a topic, and multiple consumers can receive messages from that topic.
  2. Many-to-Many Relationship: Support for multiple consumers and multiple publishers per topic.
  3. Topic Management: Ability to manage topics, including creating and deleting them dynamically.
  4. Message Consumption: Consumers should actively receive messages published to their subscribed topics.
  5. Parallel Publishing: The library should support publishers sending messages in parallel.
  6. Exception Handling: Robust and graceful handling of exceptions within the library.
  7. Offset Management: Implement offset management for consumers to track their progress in reading messages from a topic.
  8. Message Retention: Topics should have a configurable maximum retention period, after which messages are automatically deleted.
  9. [Bonus-1] Offset Reset and Replay: Ability for consumers to reset their offset and replay messages from a specific point.
  10. [Bonus-2] Visibility: Provide mechanisms for visibility into consumer and topic status, such as last read offset or lag.
Q5
Low-Level Design of Google Calendar
System DesignHard

Perform a Low-Level Design (LLD) for a system similar to Google Calendar. Focus on defining key API endpoints, choosing appropriate design patterns, and outlining the primary classes and their interactions.

Discussion (0)

Share your thoughts and ask questions

Join the Discussion

Sign in with Google to share your thoughts and ask questions

No comments yet

Be the first to share your thoughts and start the discussion!