Microsoft SDE Intern Interview Experience
💼 LTIMindtree Interview Experience (On-Campus) | Fresher | 2026
Salesforce SMTS | Interview Experience | Rejected
JPMC | SDE2 (Associate) - Java Backend - Interview Experience + Compensation
Microsoft - SDE2 - Coding Round
Super.Money Machine Coding | SDE 1
Summary
I interviewed for an SDE 1 role at Super.Money, completing a 2-hour machine coding round focused on designing a logging library. I implemented the sync logger and partially demonstrated async logging, which led to an invitation for subsequent rounds.
Full Experience
It was a 2 hours session with the interviewer
- 15 min intro and problem discussion
- 1:30 hour - coding
- last 15-30 min discussion on the code and some questions around why you did what you did in the solution from Design patterns and Solid principles prespective
- round was taken by interview Vector for super money
My take
I was able to implement the sync logger, for the async logger i was not able to implement complete multi threaded code, but was able to implement and show that how if multiple threads called Async loger, how it would behave.
As this was for a SDE - 1 , I think the interviewer was satisfied with the code and I got invited to next rounds , which I have yet to give.
Interview Questions (1)
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.