Guidance on Technical Discussions

Before the interview

Practice, Practice and Practice. Eventhough, it is possible to study using materials on the internet, it would be good to
practice common problems using a pen and a paper, bounce ideas with colleagues/friends or seniors to understand trade-
offs, common pitfalls, correctness of code, edge cases etc.

During the interview:

System Design: We give candidates an ambiguous problem in one line to solve. We expect candidates to clarify
requirements, abstract out systems and design to bring customer value. For example, Design twitter can be the question
and the following questions are good clarifying questions to understand the scope of the system to be built along both
functional and Non-functional requirements and building an acceptable scope for the solution.

a) Who can post a tweet?

b) Who can read the tweet?
c) Will a tweet contain photos or videos?
d) Can a user follow another user?
e) Can a user ‘like’ a tweet?
f) What gets included in the user feed?
g) Is feed a list of tweets in chronological order?
h) Can a user search for tweets? Will there be support for hashtags?
i) Are we designing the client/server interaction or backend architecture or both?.
j) How many daily active users?

Once you clarify requirements, you need to look at building the system. Think about how you can split your system into 5-
7 high level blocks which can help clarify what you are building. Would be good to use meaningful abstractions to
communicate your design (for example, load balancers, horizontally scaled app servers etc, NoSQL DB, message
queues, rate limiters). You also need to proactively think about bottlenecks and unhappy scenarios and discuss with the
interviewer.

Sub-System Design: The interviewer will want to understand how a particular sub-system in the above design would be
build. For example, while designing twitter (above example), the interviewer would be interested in

a) Understanding how you are thinking about building the different components
b) How you would handle specific real world usecases like celebrities having million followers, ability to quickly
search the tweets across users with a common hash tag, storing massive amount of data, caching (which type of
cache and retention policies etc.
c) Evaluate design choices for building a particular sub system and why you chose to go with one design approach
vs the other. For example, SQL vs NoSQL DB etc. There is no correct answer, it depends about the requirements
clarified earlier and how you are able to solve for those requirements with the technology choice. Also, be flexible
if the original agreed upon requirements change at this point.

Low-level Design: Once you have evaluated and identified the technology stack, you can be asked to define the data
model or come up with a OO design or an API contract for one of the sub-systems. For example, you can be asked to
model the data and the data flows between systems by coming up with the different entities and how they interact with
other entities. Some examples could be User, Tweets, Follows, Favourities, Photos, Videos etc. Interviewer can ask you
to come up with classes to represent user follows with actual functionality or expose API endpoints for mobile apps or 3P
developers to integrate twitter functionality.

Coding, PS & Algo: We expect SDE III candidates to write code that a junior SDE at Amazon would be able to code. We
also look for code maintainability and better command over language given that the candidates are senior in the role. The
code needs to be well tested for correctness before presenting to the interviewer. The goal is for you to write code that is
as close to production ready and maintainable over time. Traversals for data structures like trees/graphs divide and
conquer. For example, your preparation has to focus on how and when to use an algorithmic technique than knowing the
technique. For example when to use memoization vs dynamic programming, depth first traversal vs breadth first traversal,
linear search vs binary search etc. Also, be prepared to convert your thoughts to code so whatever you suggest be
prepared to write code.
Data Structures: A lot of our work involves storing and providing access to data in efficient ways. You’ll be expected to
know the time/space complexity for common operations. Good to refresh on Binary trees, Hash tables, Linked lists,
Stacks, Queues, Graphs, time complexity, big-o notation.