The System Design interview is a relatively new type of interview for the front-end. However, it's been a default interview in Grammarly for quite a while. I will show an almost real-life example, and we will discuss what to pay attention to during such interviews.

1. 1

2. Oleksii Levzhynskyi
Tech Lead, Grammarly

3. The goal
● familiarize everyone with the system design interview
● share tips and intent of such an interview
● show that it’s not a rocket since ;)
3

4. 2. What is a System design interview?
Agenda
4
1. What are the typical interview types?
3. Example
4. Summary & Tips
4

5. Chapter 1.
What are the typical interview
types?
5

6. We’re hiring, everyone is hiring…
● hire the right people for the right positions
● meet the candidate with the company during the
interview
● hire for the long term
6

7. ● what kinds of interviews will there be?
● should I prepare anything for interviews?
Ask about interviews in advance?
7

8. Tech/Manager screen
Focus area (Front-End skills)
Computer science (coding)
System design for Front-End engineers
The typical interviews
Non-tech interviews
8

9. Chapter 2.
What is a System design
interview for Front-End
engineers?
9

10. 10

11. ●the architecture of the client
application
●stage management
●API (communication with back-end)
●error handling
●accessibility, performance, i18n
The difference with the system design interview for back-end
Front-end Back-End
- scalability (multi-reagan, db sharding)
- reliability
- API
- performance (the speed of the response/processing)
- processing cost
11
Black box

12. 12
● Problem-solving
○to see the bigger picture and then dig into smaller pieces
○to ask the right questions
○to spot the corner-cases
● Autonomy
○Ability to drive a solution to completion
● Tech Knowledge
○the actual understanding of design patterns and principles
○the understanding of the sense of front-end
12
What to pay attention to

13. Chapter 3.
The typical task (On Twitter
example)
13

14. 0. Initial intro and the question ~ 5 min
1. Requirements gathering ~ 5 min
2. The design phase ~ 25-30
3. The polishing phase, deep dive, etc ~ 20 min
The typical stages of a
System Design interview
14

15. Disclaimer
15
The proposed solution is biased and may not fit any other task. Use as a guideline is not the
only possible way of solving a System Design interview.

16. 16
Open-ended task:
Make a design for
Twitter!

17. Requirements: what should the system do
17
●Should we think about authorization flows?
○No, assume it’s already implemented.
●What is the first thing that user will see?
○Feed with the latest tweets and form to create a new tweet
●What other functionality should be implemented?
○Use should be able to see replies for single tweet

18. Requirements: what should the system do
18
●Should we show tweet with a replies in a pop-up or separate page?
○It doesn’t matter. What do you think?
●What is the content of the tweet?
○Let’s keep it simple - only text
●Do we need any validation for tweets?
○max 280 symbols

19. ●How much data should be shown to the user?
○50 tweets/replies per page
●Should we allow to load additional tweets/replies?
○50 per request
Requirements: data/performance contarains
19

20. ●Do we need to update the feed in real time?
○Not, it’s ok to update data with some meaningful interval (10s or so)
●Should we implement client caching or “offline” mode?
○No, but implement the “draft” mode for tweet form
Requirements: data/performance contarains
20

21. Requirements: data/performance contarains
21
●Should we account for fault tolerance, a11y, i18n?
○Fault tolerance and a11y, but think about high-level architecture first
●Should I use any specific framework to build a client?
○Of your choice

22. Non-functional requirements:
●Use pagination/infinite scroll to speed up
the page load
●Data should be updated periodically
(every 10s), don’t need to update it in
real-time
●Think about fault tolerance
●The system should be accessible
Functional requirements:
●User should be able to see feed
●User should be able to add new tweet
●User should be able to see tweets and
replies on a separate page
●Pagination for tweets/replies
1. Requirements
22

23. 23

24. 1. High-level diagram
2. Data model
3. API
2. The design phase
24

25. Whiteboard is a key instrument

26. Very high-level diagram
Client API Layer Server
26
26

27. : Would you like me to start from a client?
Very high-level diagram
Client API Layer Server
27
27

28. Focus on the bigger picture first
Then dig into details!
28

29. View layer
29

30. View layer
“Controller”
30

31. Bias detected! Should I use “controller”?
31
The goal is to show that the view will not be mixed with business and application logic.
“Controller”
MV*

32. View layer
“Controller” Client State
32

33. View layer
“Controller” Client State
Server
33

34. View layer
“Controller”
Feed Single tweet
Client State
New tweet
Server
34

35. View layer
Feed “Controller”
Feed Single post
Client State
New tweet
Tweet “Controller”
Server
35

36. 36

37. View layer
Feed “Controller”
Feed Single tweet
Client State
New tweet
Tweet “Controller”
Server
37

38. View layer
Feeds “Controller”
Feed Single post
Client State
New post
Tweet “Controller”
Server
Application “Controller”
38

39. View layer
Feeds “Controller”
Feed Single post
Client State
New post
Tweet “Controller”
Server
Application “Controller”
39

40. : Am I missing anything?
40

41. {
user: { id: string, username: string, avatarURL: string }
}
Data model
41

42. {
user: { id: string, username: string, avatarURL: string }
feed: {
items: Array<{ id: string, content: string, likes: number }>,
}
}
Data model: Feed pagination?
42

43. {
user: { id: string, username: string, avatarURL: string }
feed: {
items: Array<{ id: string, content: string, likes: number }>,
lastItemTimestampt: number
},
}
Data model: Feed pagination
43

44. Data model: New tweet + validation
44
{
user: { id: string, username: string, avatarURL: string }
feed: {
items: Array<{ id: string, content: string, likes: number }>,
lastItemTimestamp: number
},
tweet: { content: string, status: ‘draft’ | ‘posting’ | ‘validationError’ }
}

45. : Am I on the right track?
45

46. View layer
Feeds “Controller”
Feed Single post
Client State
New post
Tweet “Controller”
Server
Application “Controller”
46
{
user: User
feed: Feed
tweet: NewTweet
}

47. 2. API
WS vs HTTP
47

48. 2. API
Client Server
48

49. 2. API
Client Server
←
Array<Tweet>
→ /feed; GET; { lastItemTimestamp?: number, count: number }
49

50. 2. API
Client Server
← Array<Tweet>
→ /feed; GET; { lastItemTimestamp?: number, count: number }
← { id: number, content: string, repliesCount: number, replies: Array<Reply>
}
→ /tweet; GET; { id: number}
50

51. 2. API
Client Server
← Array<Tweet>
→ /feed; GET; { lastItemTimestamp?: number, count: number }
← { id: number, content: string, repliesCount: number, replies: Array<Reply>
}
→ /tweet; GET; { id: number}
51
→ /replies; GET; { tweetId: number, lastItemTimestamp: number }
← Array<Replies>

52. 2. API
Client Server
→ /tweet; POST; { content: string }
← Array<Tweet>
→ /feed; GET; { lastItemTimestamp?: number, count: number }
← { id: number, content: string, repliesCount: number, replies: Array<Reply>
}
→ /tweet; GET; { id: number}
← Tweet
52
→ /replies; GET; { tweetId: number, lastItemTimestamp: number }
← Array<Replies>

53. : Does it make sense?
53

54. 2. Focus on the important areas of the product
1. Would you like me to focus on some specific
area?
3. Focus on your strengths
3. Deep dive
54

55. ●Error page for cases when tweet cannot be found, 500 from server or
●Retries policies
●“Notification” to say that something goes wrong
Deep dive: Error handling
55

56. ●Error page for cases when tweet cannot be found, 500 from server or
●Retries policies
●“Notification” to say that something goes wrong
●Service to observe the offline/online mode
Deep dive: Error handling
56
Feeds Controller Tweet Controller
Back end
Application controller
Connection Checker Middleware

57. Deep dive: a11y
57
What area of accessibility would we like to cover?

58. ● Keyboard accessible:
○ Tab order
○ Semantic elements
● Visually accessible:
○ Contrast, accessible fonts, no color-coding, etc
○ proper aria-labels
● Advanced: Screen reader support
● Testing
○ Unit tests with lighthouse + axe tools for automation testing
○ Manual tests for a11y scenarios
● Company-level base component library with a11y
● Company-wide processes:
○ a11y training for the team members
○ a11y-related page
● ….
Deep dive: a11y
58

59. : would you like me to focus on
something else?
: we’re done. Thank you!
59

60. View layer
Feeds “Controller”
Feed Single post
Client State
New post
Tweet “Controller”
Back end
Application “Controller”
60
{
user: User
feed: Feed
tweet: NewTweet
}
Error Page

61. Summary & Tips
61
61
●Spend time on requirements gathering.
●You're driving an interview and explaining every step.
●Don't rush if you know the solution. Or better, always build from scratch.
●Continuously check the status with the interviewer and the requirements.
●Don't overcomplicate things. Start high-level and drill-down.
●Check the time. It's better to skip some unclear areas rather than spend the whole
interview solving them.
●If you're stuck, ask for a tip.
●Focus on your strengths.

62. Resources
●What are Functional and Non-Functional Requirements and How to Document These
●How to design a Facebook in 30-minutes or Acing System Design Interview
●Frontend system design interviews - the definitive guide
62
62

63. How to Build a Productive Team
Grammarly stands
with Ukraine.
We invite you to do the same.
Here are some ways you
can help:

64. Thank you
64