SDE is an acronym for Software Development Engineer. At super.
money, SDE-3s are senior engineers who
own a functional area - from product conception to its delivery to customers. You are expected to design
and code independently in multiple tech components related to your functional area. You must also
develop a deep understanding of non-functional requirements, such as reliability and availability, scale,
horizontal scalability, etc., over time and make tech stack decisions accordingly. You are expected to
actively mentor junior engineers. You own the code base quality.
INTERVIEW PROCESS
● Machine Coding
● Problem Solving & Data Structure
● Design & Architecture
● Hiring Manager
TIPS: To approach this problem statement, identify the core entities at play, come up with the right roles
and responsibilities for each entity/class, have the right abstractions around the various component
interactions (e.g., for the scope of this problem, you may want to store the messages in some in-memory
data-structure. Also, you’re expected to abstract this storage component).
Error Handling - Identify the failure scenarios, necessary validations and come up with the right
error-handling mechanism (custom or appropriate exceptions, error codes, details, etc.). Language
Proficiency - You’re free to choose the language of your choice, But use the appropriate language
constructs wherever applicable. Functional Correctness and Completeness - Identify the crux of the
problem, and ensure that you’re able to code for it. In this given problem, the crux is build a capability to
parallelly push the messages to multiple subscribers. Code Hygiene - Your code should be readable,
modular, and testable.
ROUND 2.2: PROBLEM SOLVING & DATA STRUCTURE (60 MINUTES)
You'll be given 2 or 3 problems. For each problem, you are expected to break down the problem into
multiple sub-problems and solve them using your expertise in data structures and algorithms. For some
parts of a problem, you will be asked to provide pseudo-codes. These problems are 'close to real-world' in
nature with multiple acceptable solutions, hence, there is no 'single expected answer'. Good knowledge of
data structures is a must. The interviewer will assess you on your skill in applying multiple data structures
(including Queues, Heaps, Graphs, Trees, Hash Tables, etc.) to solve the problem. You’ll also be assessed
on your ability to bring clarity to a problem statement by asking the right questions, and also whether you
can proceed with the solution of the discussed problem by applying the right data structures wherever
possible. You may be asked questions related to the internal implementation of these data structures.
ROUND 2.3: DESIGN & ARCHITECTURE (90 MINUTES)
In this round, 1 or 2 real-world problems would be discussed with you with a strong focus on design and
architecture. You are expected to provide a solution with multiple components and provide class design,
REST/RPC interface design and software architecture (logical view and deployment view). Your solution
is expected to work in a distributed environment, leverage parallelism wherever possible and handle
concurrency. You can use a white board with markers or white papers with a pen to explain/draw your
design/architecture. Both approaches are equally acceptable. You are strongly encouraged to come up
with multiple possible approaches, weigh pros and cons and take an opinionated view.
LOW LEVEL DESIGN
Logical View For the above-discussed problem space and previously agreed business flows, come up with
a logical view which comprises the below sections: Domain Entity Identification: Identify the key domain
entities and their value objects. Roles and Responsibilities: Assign roles and responsibilities to each of
the identified entities. Relationship and Association: Identify the relationship between entities and
association between entities
Some tips that will come in handy: Use the board, preferably, to draw UML diagrams for the identified
entities and their relationships. Keep out the implementation.
Process View API Design: Come up with APIs which will be exposed for consumption (need not be
RESTful) Sample Prototyping: Give prototype for some of the identified APIs (Params ..) E.g.: List
getUsers(userId, userType, QueryParams<>) throws UserNotFoundException Conventions: Talk about
your conventions on prototyping and API Design
HIGH LEVEL DESIGN
Identify the components by their functionality, characterize the components from their NFR point-of-view
(i.e., function of components like Low Latent Key-Value Store, etc.), talk about their interactions (e.g.,
WebService, DataStore, Cache, Queue, etc.) and preferred approaches for interactions (Sync, Async, Job,
etc.).
TIPS: Use the board to draw functional components with appropriate shapes and their interactions
ROUND 2.4: HIRING MANAGER DISCUSSION (60 MINUTES)
The intent of this round is to evaluate your team fitment based on your experience, interests and
strengths demonstrated across other rounds. In this round, you’ll be interacting with your potential team
leader/hiring manager who will try to get to know you better in order to make an
informed choice that we hire the right person for the right job.
The interviewer will try to understand your aspirations, inspirations and motivations, self-awareness,
leadership ability, stakeholder management, strengths and weaknesses, etc.
You can also expect questions around some of the competencies which you would have been
evaluated in previous rounds. Think of this round as a summary of all the discussions that you have had
during the day.
