algorithm/tech-interview-handbook
1
0
Fork 0
mirror of https://github.com/yangshun/tech-interview-handbook.git synced 2025-07-28 04:33:42 +08:00
Code Issues Packages Projects Releases Wiki Activity

Squash commit

Browse Source
This commit is contained in:
Tay Yang Shun
2017-09-20 15:27:28 +08:00
commit 2182a70770
70 changed files with 5486 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

94
design/README.md Normal file
View File

@ -0,0 +1,94 @@
Design Questions
==
## Guides
- https://github.com/donnemartin/system-design-primer
- https://github.com/checkcheckzz/system-design-interview
- https://github.com/shashank88/system_design
- https://gist.github.com/vasanthk/485d1c25737e8e72759f
- http://www.puncsky.com/blog/2016/02/14/crack-the-system-design-interview/
- https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/
- http://blog.gainlo.co/index.php/2017/04/13/system-design-interviews-part-ii-complete-guide-google-interview-preparation/
## Flow
#### A. Understand the problem and scope
- Define the use cases, with interviewer's help.
- Suggest additional features.
- Remove items that interviewer deems out of scope.
- Assume high availability is required, add as a use case.
#### B. Think about constraints
- Ask how many requests per month.
- Ask how many requests per second (they may volunteer it or make you do the math).
- Estimate reads vs. writes percentage.
- Keep 80/20 rule in mind when estimating.
- How much data written per second.
- Total storage required over 5 years.
- How much data reads per second.
#### C. Abstract design
- Layers (service, data, caching).
- Infrastructure: load balancing, messaging.
- Rough overview of any key algorithm that drives the service.
- Consider bottlenecks and determine solutions.
Source: https://github.com/jwasham/coding-interview-university#system-design-scalability-data-handling
## Grading Rubrics
- Problem Solving - How systematic is your approach to solving the problem step-by-step? Break down a problem into its core components.
- Communication - How well do you explain your idea and communicate it with others?
- Evaluation - How do you evaluate your system? Are you aware of the trade-offs made? How can you optimize it?
- Estimation - How fast does your system need to be? How much space does it need? How much load will it experience?
## Specific Topics
- URL Shortener
- http://stackoverflow.com/questions/742013/how-to-code-a-url-shortener
- http://blog.gainlo.co/index.php/2016/03/08/system-design-interview-question-create-tinyurl-system/
- https://www.interviewcake.com/question/python/url-shortener
- Collaborative Editor
- http://blog.gainlo.co/index.php/2016/03/22/system-design-interview-question-how-to-design-google-docs/
- Photo Sharing App
- http://blog.gainlo.co/index.php/2016/03/01/system-design-interview-question-create-a-photo-sharing-app/
- Social Network Feed
- http://blog.gainlo.co/index.php/2016/02/17/system-design-interview-question-how-to-design-twitter-part-1/
- http://blog.gainlo.co/index.php/2016/02/24/system-design-interview-question-how-to-design-twitter-part-2/
- http://blog.gainlo.co/index.php/2016/03/29/design-news-feed-system-part-1-system-design-interview-questions/
- Trending Algorithm
- http://blog.gainlo.co/index.php/2016/05/03/how-to-design-a-trending-algorithm-for-twitter/
- Facebook Chat
- http://blog.gainlo.co/index.php/2016/04/19/design-facebook-chat-function/
- Key Value Store
- http://blog.gainlo.co/index.php/2016/06/14/design-a-key-value-store-part-i/
- http://blog.gainlo.co/index.php/2016/06/21/design-key-value-store-part-ii/
- Recommendation System
- http://blog.gainlo.co/index.php/2016/05/24/design-a-recommendation-system/
- Cache System
- http://blog.gainlo.co/index.php/2016/05/17/design-a-cache-system/
- E-commerce Website
- http://blog.gainlo.co/index.php/2016/08/22/design-ecommerce-website-part/
- http://blog.gainlo.co/index.php/2016/08/28/design-ecommerce-website-part-ii/
- Web Crawler
- http://blog.gainlo.co/index.php/2016/06/29/build-web-crawler/
- http://www.makeuseof.com/tag/how-do-search-engines-work-makeuseof-explains/
- https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch/answer/Chris-Heller
- YouTube
- http://blog.gainlo.co/index.php/2016/10/22/design-youtube-part/
- http://blog.gainlo.co/index.php/2016/11/04/design-youtube-part-ii/
- Hit Counter
- http://blog.gainlo.co/index.php/2016/09/12/dropbox-interview-design-hit-counter/
- Facebook Graph Search
- Design [Lyft Line](https://www.lyft.com/line).
- Design a promo code system (with same promo code, randomly generated promo code, and promo code with conditions).
- Model a university.
- How would you implement Pacman?
- Sketch out an implementation of Asteroids.
- Implement a spell checker.
- Design the rubik cube.
- Design a high-level interface to be used for card games (e.g. poker, blackjack etc).

108
design/collaborative-editor.md Normal file
View File

@ -0,0 +1,108 @@
Collaborative Document Editor
==
## Variants
- Design Google docs.
- Design a collaborative code editor like Coderpad/Codepile.
- Design a collaborative markdown editor.
## Requirements Gathering
- What is the intended platform?
- Web
- What features are required?
- Creating a document
- Editing a document
- Sharing a document
- Bonus features
- Document revisions and reverting
- Searching
- Commenting
- Chatting
- Executing code (in the case of code editor)
- What is in a document?
- Text
- Images
- Which metrics should we optimize for?
- Loading time
- Synchronization
- Throughput
## Core Components
- Front end
- WebSockets/long polling for real-time communication between front end and back end.
- Back end services behind a reverse proxy.
- Reverse proxy will proxy the requests to the right server.
- Split into a few services for different purposes.
- The benefit of this is that each service can use different languages that best suits its purpose.
- API servers for non-collaborative features and endpoints.
- Ruby/Rails/Django for the server that deals with CRUD operations on data models where performance is not that crucial.
- WebSocket servers for handling document edits and publishing updates to listeners.
- Possibly Node/Golang for WebSocket server which will need high performance as updates are frequent.
- Task queue to persist document updates to the database.
- ELB in front of back end servers.
- MySQL database.
- S3 and CDN for images.
## Data Modeling
- What kind of database to use?
- Data is quite structured. Would go with SQL.
- Design the necessary tables, its columns and its relations.
- `users`
- `id`
- `name`
- `document`
- `id`
- `owner_id`
- `permissions`
- `id`
- `name`
- `document_permissions`
- `id`
- `document_id`
- `user_id`
## Collaborative Editing - Client
- Upon loading of the page and document, the client should connect to the WebSocket server over the WebSocket protocol `ws://`.
- Upon connection, perform a time sync with the server, possibly via Network Time Protocol (NTP).
- The most straightforward way is to send the whole updated document content to the back end, and all users currently viewing the document will receive the updated document. However, there are a few problems with this approach:
- Race condition. If two users editing the document at the same time, the last one to edit will overwrite the changes by the previous user. One workaround is to lock the document when a user is currently editing it, but that will not make it real-time collaborative.
- A large payload (the whole document) is being sent to servers and published to users on each change, and the user is likely to already have most of the content. A lot of redundant data being sent.
- A feasible approach would be to use operational transforms and send just the action deltas to the back end. The back end publishes the action deltas to the listeners. What is considered an action delta?
- (a) Changing a character/word, (b) inserting a character/word/image, (c) deleting a character/word.
- With this approach, the payload will contain only small amount of data, such as (a) type of change, (b) character/word, (c) position in document: line/column, (d) timestamp. Why is the timestamp needed? Read on to find out.
- Updates can also be throttled and batched, to avoid flooding the web server with requests. For example, if a user inserts a
## Back End
The back end is split into a few portions: WebSocket server for receiving and broadcasting document updates, CRUD server for reading and writing non-document-related data, and a task queue for persistence of the document.
## WebSocket Server
- Languages and frameworks that support async requests and non-blocking I/O will be suitable for the collaborative editor server. Node and Golang comes to my mind.
- However, the WebSocket server is not stateless, so is it not that straightforward to scale horizontally. One approach would be for a Load Balancer to use Redis to maintain a map of the client to the WebSocket server instance IP, such that subsequent requests from the same client will be routed to the same server.
- Each document corresponds to a room (more of namespace). Users can subscribe to the events happening within a room.
- When a action delta is being received, blast it out to the listeners within the room and add it to the task queue.
## CRUD Server
- Provides APIs for reading and writing non-document-related data, such as users, permissions.
## Task Queue + Worker Service
- Worker service retrieves messages from the task queue and writes the updated documents to the database in an async fashion.
- Batch the actions together and perform one larger write that consists of multiple actions. For example, instead of persisting to the database once per addition of a word, combine these additions and write them into the database at once.
- Publish the save completion event to the WebSocket server to be published to the listeners, informing that the latest version of the document is being saved.
- Benefit of using a task queue is that as the amount of tasks in the queue goes up, we can scale up the number of worker services to clear the backlog of work faster.
## Document Persistence
TODO
###### References
- http://blog.gainlo.co/index.php/2016/03/22/system-design-interview-question-how-to-design-google-docs/

164
design/news-feed.md Normal file
View File

@ -0,0 +1,164 @@
News Feed
==
## Variants
- Design Facebook news feed.
- Design Twitter news feed.
- Design Quora feed.
- Design Instagram feed.
## Requirements Gathering
- What is the intended platform?
- Mobile (mobile web or native)? Web? Desktop?
- What features are required?
- CRUD posts.
- Commenting on posts.
- Sharing posts.
- Trending posts?
- Tag people?
- Hashtags?
- What is in a news feed post?
- Author.
- Content.
- Media.
- Tags?
- Hashtags?
- Comments/Replies.
- Operations:
- CRUD
- Commenting/replying to a post.
- What is in a news feed?
- Sequence of posts.
- Query pattern: query for a user's ranked news feed.
- Operations:
- Append - Fetch more posts.
- Delete - I don't want to see this.
- Which metrics should we optimize for?
- User retention.
- Ads revenue.
- Fast loading time.
- Bandwidth.
- Server costs.
## Core Components
TODO
## Data modeling
- What kind of database to use?
- Data is quite structured. Would go with SQL.
- Design the necessary tables, its columns and its relations.
- `users`
- `posts`
- `likes`
- `follows`
- `comments`
> There are two basic objects: user and feed. For user object, we can store userID, name, registration date and so on so forth. And for feed object, there are feedId, feedType, content, metadata etc., which should support images and videos as well.
>
> If we are using a relational database, we also need to model two relations: user-feed relation and friend relation. The former is pretty straightforward. We can create a user-feed table that stores userID and corresponding feedID. For a single user, it can contain multiple entries if he has published many feeds.
>
> For friend relation, adjacency list is one of the most common approaches. If we see all the users as nodes in a giant graph, edges that connect nodes denote friend relation. We can use a friend table that contains two userIDs in each entry to model the edge (friend relation). By doing this, most operations are quite convenient like fetch all friends of a user, check if two people are friends.
>
> The system will first get all userIDs of friends from friend table. Then it fetches all feedIDs for each friend from user-feed table. Finally, feed content is fetched based on feedID from feed table. You can see that we need to perform 3 joins, which can affect performance.
>
> A common optimization is to store feed content together with feedID in user-feed table so that we don’t need to join the feed table any more. This approach is called denormalization, which means by adding redundant data, we can optimize the read performance (reducing the number of joins).
>
> The disadvantages are obvious:
> - Data redundancy. We are storing redundant data, which occupies storage space (classic time-space trade-off).
> - Data consistency. Whenever we update a feed, we need to update both feed table and user-feed table. Otherwise, there is data inconsistency. This increases the complexity of the system.
> - Remember that there’s no one approach always better than the other (normalization vs denormalization). It’s a matter of whether you want to optimize for read or write.
## Feed Display
- The most straightforward way is to fetch posts from all the people you follow and render them sorted by time.
- There can be many posts to fetch. How many posts should you fetch?
- What are the pagination approaches and the pros and cons of each approach?
- Offset by page size
- Offset by time
- What data should the post contain when you initially fetch them?
- Lazy loading approach for loading associated data: media, comments, people who liked the post.
- Media
- If the post contains media such as images and videos, how should they be handled? Should they be loaded on the spot?
- A better way would be to fetch images only when they are about to enter the viewport.
- Videos should not autoplay. Only fetch the thumbnail for the video, and only play the video when user clicks play.
- If the content is being refetched, the media should be cached and not fetched over the wire again. This is especially important on mobile connections where data can be expensive.
- Comments
- Should you fetch all the comments for a post? For posts by celebrities, they can contain a few hundred or thousand comments.
- Maybe fetch the top few comments and display them under the post, and the user is given the choice to "show all comments".
- How does the user request for new content?
- Infinite scrolling.
- User has to tap next page.
## Feed Ranking
- First select features/signals that are relevant and then figure out how to combine them to calculate a final score.
- How do you show the relevant posts that the user is interested in?
- Chronological - While a chronological approach works, it may not be the most engaging approach. For example, if a person posts 30 times within the last hour, his followers will have their news feed clogged up with his posts. Maybe set a cap on the number of time a person's posts can appear within the feed.
- Popularity - How many likes and comments does the post have? Does the user usually like posts by that person?
- How do you determine which are the more important posts? A user might be more interested in a few-hour old post from a good friend than a very recent post from an acquaintance.
- A common strategy is to calculate a post score based on various features and rank posts by its score.
- Prior to 2013, Facebook was using the [EdgeRank](https://www.wikiwand.com/en/EdgeRank) algorithm to determine what articles should be displayed in a user's News Feed.
- Edge Rank basically is using three signals: affinity score, edge weight and time decay.
- Affinity score (u) - For each news feed, affinity score evaluates how close you are with this user. For instance, you are more likely to care about feed from your close friends instead of someone you just met once.
- Edge weight (e) - Edge weight basically reflects importance of each edge. For instance, comments are worth more than likes.
- Time decay (d) - The older the story, the less likely users find it interesting.
- Affinity score
- Various factors can be used to reflect how close two people are. First of all, explicit interactions like comment, like, tag, share, click etc. are strong signals we should use. Apparently, each type of interaction should have different weight. For instance, comments should be worth much more than likes.
- Secondly, we should also track the time factor. Perhaps you used to interact with a friend quite a lot, but less frequent recently. In this case, we should lower the affinity score. So for each interaction, we should also put the time decay factor.
- A good ranking system can improve some core metrics - user retention, ads revenue, etc.
## Feed Publishing
TODO. Refer to http://blog.gainlo.co/index.php/2016/04/05/design-news-feed-system-part-2/.
## Additional Features
#### Tagging feature
- Have a `tags` table that stores the relation between a post and the people tagged in it.
#### Sharing feature
- Add a column to `posts` table called `original_post_id`.
- What should happen when the original post is deleted?
- The shared `posts` have to be deleted too.
#### Notifications feature
- When should notifications happen?
- Can the user subscribe to only certain types of notifications?
#### Trending feature
- What constitutes trending? What signals would you look at? What weight would you give to each signal?
- Most frequent hashtags over the last N hours.
- Hottest search queries.
- Fetch the recent most popular feeds and extract some common words or phrases.
#### Search feature
- How would you index the data?
## Scalability
- Master-slave replication.
- Write to master database and read from replica databases/in-memory data store.
- Post contents are being read more than they are updated. It is acceptable to have a slight lag between a user updating a post and followers seeing the updated content. Tweets are not even editable.
- Data for real-time queries should be in memory, disk is for writes only.
- Pre-computation offline.
- Tracking number of likes and comments.
- Expensive to do a `COUNT` on the `likes` and `comments` for a post.
- Use Redis/Memcached for keeping track of how many likes/comments a post has. Increment when there's new activity, decrement when someone unlikes/deletes the comment.
- Load balancer in front of your API servers.
- Partitioning the data.
###### References
- [Design News Feed System (Part 1)](http://blog.gainlo.co/index.php/2016/03/29/design-news-feed-system-part-1-system-design-interview-questions/)
- [Design News Feed System (Part 1)](http://blog.gainlo.co/index.php/2016/04/05/design-news-feed-system-part-2/)
- [Etsy Activity Feeds Architecture](https://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture)
- [Big Data in Real-Time at Twitter](https://www.slideshare.net/nkallen/q-con-3770885)

6
design/search-engine.md Normal file
View File

@ -0,0 +1,6 @@
Search Engine
==
###### References
- [How Do Search Engines Work?](http://www.makeuseof.com/tag/how-do-search-engines-work-makeuseof-explains/)