Don’t be distracted with additional features

• 1: Gather Requirements
  • functional requirement timing: 2 minutes
  • non-functional requirement timing: 3-5 minutes
• 2: Design API 3-5 minutes
• 3: Define higi level diagram 5-7 minutes
• 4: Define schema and data structure 5-7 minutes
• 5: end to end flow 2-3 minutes

# Gather requirements

• who is it for, and why do we need to build it?
• what are the features we need to solve the users’ problem

# non functional requirements

• scale
  • high qps
  • high storage and bandwidth
• accuracy
• response time and latency constraint
• freshness
  • real time
  • near real time
  • batch processing
• druability

# High Level Diagram Design

• define the client for an API
• define the next sets of logical blocks
• repeat step 1 for the next API

# Discussion Point

• Latency
• High QPS
• Bursty of the API
• Slow, Low bandwidth. Congested Network
• Query Optimization

# Solution Discussion

• identify and articulate the problem
• come up with potential solutions
• discuss the trade-off
• take a stance on your preference
• active discussion with the interviewer

# interviewer perspective

# rubic examples for each section

Functional requirement gathering

• no hire
  • the candidate didn’t ask any clarifying questions after the question
  • the candidate had a difficult time understanding the problem statement and still could not continue after multiple hints
  • the candidate kept discussing different features and failed to elaborate on the technical details
• level 2
  • the candidate could come up with some features but was a bit murky about the user story. For example, “for google photo design, the candidate asked if we needed to display the photos but didn’t come up with the wireframe on how to display the photos”
  • the candidate considered some cases and rushed into the next section. For example, “For google photo design, the candidate asked good questions about the photo upload feature but didn’t talk about how the user should view the photos”
  • the candidate was able to come up with important features with a little bit of guidance
• level 3
  • the candidate interacted well with the interviewer and was very clear on the steps of the user experiences
  • the candidate considered the important features and narrowed down to a few requirements to focus on for the interview
  • the candidate did not need any hints or guidance from the interviewer

Non functional requirement gathering

• no hire
  • the candidate didn’t ask any clarifying questions about the design constraint and the performance requirements and did not understand the scalability design
  • the cnadidate said some words about consistency, availability and reliability, but did not understand how to relate the qualities to the end user experience
• level 2
  • the candidate asked some important questions about non-functional requirements but also missed some. However, as the candidate proceeded throughout the interview, they were able to identify them
• level 3
  • the candidate listed most of the important design constraints and qualities for the design question and occasionally used them throughout the design pdcisions to make the final recommendation
• level 4
  • the candidate raised all the critical design constraints and qualities for the question and used those qualiteis throughout the interview to make design decisions and trade-offs

API Design

• no hire
  • the candidate missed some of the critical APIs for the system
  • the API design the candidate came up with wouldn’t work after multiple hints
  • the API was highly inefficient, and the candidate failed to see the issues after hints
• level 2
  • the candidate could come up with a reasonable and efficient API design after some guidance and immediately understood the issues and course correct
  • the candidate was initially murky after some important components of the API and missed some important inputs or outputs, but the candidate could come up with the correct details after pointing them out
• level 3
  • the candidate was able to come up with an efficient API without much guidance and suggested some ways the API could be improved and be more extensible
  • the candidate needed little guidance on some of the trade-offs for the API
• level 4
  • the candidate could develop an efficient API with no guidance, proactively listed out all the major trade-offs, and proposed alternative solutions for major trade-offs if the requirements were to change

High level diagram

• no hire
  • the candidate missed most of the major components of the architecture
  • the candidate had difficulty connecting the major components
  • the architecture the candidate came up with would not satisfy the requirements
  • most of the architecture diagrams and data flows were unclear. Once the interviewer pointed out the issues, the candidate was still unable to provide more clarity
• level 2
  • the candidate identified most of the components needed for the system but realized some guidance to fill in some of the gaps
  • the candidate introduced components without discussing the whys but was able to course-correct quickly after some hints
  • the initially designed architecture had some issues, but the candidate could address the issue once the interviewer pointed out the problems
  • some of the diagrams and data flow were slightly murkly, but the candidate could improve upon them
• level 3
  • the candidate identified most of the major components necessary for the system and identified some of the major trade-offs to discuss in the deep dives section
  • the candidate understood most of the reasons why the components are necessary for the requirements and articulated the reasons well
• level 4
  • the candidate identified all the major components needed for the system and identified all the major trade-offs associatd with the design
  • the candidate understood why some components are needed and not needed and were every cost-aware and able to remove elements that were not needed

Data structure and schema

• no hire
  • the candidate had a very difficult time coming up with a schema and was often incorrect
  • the selected data structures and schema were inefficient and would not work. The candidate didn’t understand why, even with guidance
  • the candidate failed to discuss the trade-offs of the proposed solution
• level 2
  • the candidate was able to come up with a reasonable alternative but required guidance on another solution
  • the candidate came up with a schema design but didn’t self-identify some of the trade-offs associated with the design. However, with some hints, the candidate was able to address the issue
• level 3
  • the candidate was able to develop reasonable schema designs and proposed some of the trade-offs associated with the design, but missed a couple of important points. however, with a small nudge, the candidate was able to address them
• level 4
  • the candidate could come up with reasonable and efficient schema designs and the trade-offs associated with them. by identifying the issues, the candidate was able to propose solutions to address those issues
  • the candidate was very detailed on connecting how the chosen data structures and schema relate to the user experiences and proposed potential trade-offs that the candidate needed to address

deep dives

• no hire
  • the candidate was stuck after a high-level diagram, and the candidate thought the design was complete and trivial
  • the candidate failed to understand how high traffic and volume of data would impact their initial design
  • the candidate had a significant knowledge gap in how some of the fundamental technicals work
  • the candidate could not go beyond the buzzwords and failed to understand the internals and whys of the proposed solutions
• level 2
  • the candidate could self-identify some of the bottlenecks but required some guidance on the solutions and trade-offs
  • the cnadidate could come up with solutions and trade-offs but didn’t identify some of the critical risks. however, the candidate was able to understand the issue and propose a reasonable solution after some guidance
• level 3
  • the candidate was able to identify most, if not all, the bottlenecks and was able to provide most of the important pros and cons to the alternative solutions
  • the candidate was able to identify the bottlenecks, but some of the bottlenecks weren’t significant or important enough to discuss
  • the candidate was able to provide most of the important technical details but required a little guidance on some details
• level 4
  • the candidate self-identified all the critical bottlenecks, proposed reasonable solutions with their pros and cons, and picked a final recommendation knowing the trade-offs
  • the candidate could provide enough technical details relevant to the requirements and comminucated how that impacts the solutions and the trade-offs
  • the candidate could prioritize the right areas of discussion for most critical bottlenecks