Super.money Interviews

Simple Logging Library

Objective: Develop a basic logging library that can be used by applications to log messages. The library should handle message logging efficiently and reliably, offering basic configuration options.

Key Requirements: Driver Application should be able to Initialize the Library and log messages to the desired sink.

Logger has the following capabilities- Accepts messages from client(s) A logger would have one or more sinks associated with it. Supports defined message levels. Enriches message with current timestamp while directing message to a sink Logger is initialized with a configuration eg:logger name, sink(s), buffer size. Logger should support both sync and async logging. For Async logger buffer size would determine the maximum inflight messages. Messages must be ordered. Messages should reach the sink in the order they were sent. Should support writes from multiple-threads. There shouldn’t be any data loss.

Sink: There can be various types of sink (file, stdout, database).
Sink has a destination. For this round you may create STDOUT sink, which would print the message to the console. Sink has an associated log level. Any message with the level lower than the sink level should be discarded.

Message has content which is of type string has a level associated with it

Log level DEBUG, INFO, WARN, ERROR, FATAL ; in order of priority. ERROR has higher priority than INFO. Add test cases to demonstrate sync logging, async logging and concurrent logging requests

Sending messages Sink need not be mentioned while sending a message to the logger library. You specify message content and level while sending a message

Logger configuration (see sample below) Specifies all the details required to use the logger library. Library can accept one or more configuration for an application Example: time format logging level sink type Logger type sync/async details required for sink (eg file location)); this depends on sink type.

Sample Config: Ts_format: any format log_level:INFO logger_type:ASYNC buffer_size:25 sink_type:STDOUT

Sample Output Log Entry 03-01-2024-09-30-00 [INFO] This is a sample log message. Sample test case: Input: Configuration of the logger is console logging with Info level. log.info(“Info message”) log.warn(“Warn message”) log.debug(“Debug message”) log.error(“Error message”) Output: 03-01-2024-09-30-00 [INFO] Info message 03-01-2024-09-30-01 [WARN] Warn message 03-01-2024-09-30-02 [ERROR] Error message

Expectations and Guidelines

Create the sample data yourself. You can put it into a file, test case or main driver program itself. The code should be demo-able. Either by using the main driver program or test cases. The code should be modular. The code should have the basic OO design. Please do not jam in the responsibilities of one class into another. The code should be extensible. Wherever applicable, use interfaces and contracts between different methods. It should be easy to add/remove functionality without rewriting the entire codebase. The code should handle edge cases properly and fail gracefully. The code should be legible, readable and DRY. Database integration is not required. Please do not access the internet for anything EXCEPT syntax. You are free to use the language and IDE of your choice. The entire code should be your own.

Build a Stock Wishlist App with the following features:

1. A list of stocks where prices change at specific intervals
2. Ability to add/remove stocks from the wishlist
3. Set notification alerts when stock prices hit a user-defined threshold
4. Search functionality for stocks

Build an n x m grid. When a user clicks a cell, highlight the entire row and column in red.

Build a counter app where clicking "+" increments the value and also retains the previous values (used React hooks).

Covered topics like Virtual DOM, useLayoutEffect, lifecycle of useEffect, critical rendering path, web vitals (LCP, CLS, FID), and website/network optimizations.

Discussed functional & non-functional requirements. Discussion on architecture, MVC design, and high-level design of form. Small discussion on backend services. Schema design: faced a bit of difficulty in modeling ownership vs user responses, but handled other aspects confidently.

Typical HM round questions. Time when I lead my team. What are my expectations on work from super.money. He also discuss about the work and culture of super.money.

Design a logger library with different configurable destination options along with sync and async ways to write logs to the destination. It should support different log levels, buffer size for the async option, and formatting options. SOLID and OOD was expected, code should be running and testable. Handle everything in a multi-threaded environment.

Discussion on reducing API latency using caching techniques. Discussion of general approach to take to address API latency issues.

Design the leaderboard side of IPL fantasy league. T teams, 10M+ users, every user can build any team with 11 players, calculate per ball leaderboard based on fantasy points earned. Can assume we have a black box method to calculate per ball points, and we can query it to design our leaderboard. Expectations: DB design, optimised queries, API flow, expected async handling of updating huge number of users’ score calc and updates.

Design a price drop alert system for a travel website. Users can select data range and the threshold price for a location, notify them when the price drops below the value. The website depends on the data from external sources like agoda, mmt, expedia etc.

Design a logging library. Further requirements and context are provided in the attached document.

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.

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.

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

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.

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.