# An Interview with a Meta engineer

#### Watch someone solve the design live comments problem in an interview with a Meta engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Design Live Comments Feature: System Design Interview with a Meta Engineer - YouTube

### Interview Summary

**Problem type**  
Design Live Comments

**Interview question**  
Design a live comments feature. Live commenting is a feature that allows clients to publish real-time comments on live videos or pictures without the need to refresh or reload.

### Interview Feedback

**Feedback about Utilitarian Lemur (the interviewee)**  
**Advance this person to the next round?**  
No  
**How were their technical skills?**  
4/4  
**How was their problem solving ability?**  
3/4  
**What about their communication ability?**  
3/4

> Overall weak no hire as M1.
>
> ✅ What went well:
>
> 1. Good functional requirement
> 2. Good non-functional requirement and why they’re there
> 3. Good assumption read vs write ratio and calling out about hot spots (celebrities)
> 4. Good API design, lacking response
> 5. Decent data schema. Includes the “live” problem
> 6. Good data flow
> 7. Good component responsibilities
> 8. TC drove the discussion well
> 9. Core puzzle: talk about using push (websocket/long polling). Didn’t talk about the alternatives
> 10. Deep dive: talk about CAP theorem and how it applies in this app. And decided to go with high availability. But doesn’t tell us what is the implication on the system
> 11. Deep dive: talk about fail tolerance on storage
>
> ❌ What can be improved:
>
> 1. Spent 20 mins in functional + non-functional + numbers. Benchmark is 10 mins
> 2. Doesn’t really explain what non-functional mean. What’s the implications
> 3. Doesn’t really explain what the numbers mean. What’s the implications
> 4. Lack of tradeoffs discussion
> 5. Lack 2-3 more deep dives (DB choices, DB sizes, connection with choices numbers)
> 6. API lacks responses
>
> **Action items:**
>
> 1. Memorize all non-functional requirement possibilities, then just shoot them (yes, no)
> 
>    1. Reliability: 99.99% system availability
>    2. Scalability: can handle up and down traffic
>    3. Security: only one public endpoint. Code is executed safely
>    4. Durability: store data for 10 years
>    5. Latency: p95 200ms
>    6. High Availability vs Strong Consistency
> 2. Explain by use cases (read, end to end) vs by sections (API, then data schema, then high level design)
> 3. Don’t clarify, just shoot ahead. Let the interviewer disrupt you on checkpoints
> 4. Not all numbers are important. QPS is always important. Storage number is usually important.
> 5. Think about Core Puzzle, and at least make the tradeoff about Core Puzzle
>
> **Level implications:**
> 
> 1. E4 you have to do things right
> 2. E5 you have to do trade-offs (SQL vs NoSQL, core puzzle, push vs pull, REST vs GraphQL, sync vs async)
> 3. E6 you have to go deep (offline support, multi-language support, battery optimization)
> 4. E7 you have to impress (something that most people don’t know)
>
> ### Tips:
> 1. Easiest way to sound smart (and have an opportunity for deep-dive): user → LB → API gateway → service (don’t forget to mention API gateway)
>    1. API Gateway allows you to put these following deep dives: authentication, security, rate limiting, throttling, transformations, analytics and monitoring
> 2. Keep functional + non-functional + quantitative analysis down to 10 mins, no more than this.
> 3. On quantitative analysis, you can use quick numbers:
>    1. 1MB → 1e6
>    2. 1M DAU → 1e6
>    3. 1 day → 86400 sec → close to 100,000 sec → 1e5
>    4. Usage on computing QPS → 1M DAU → 1e6 / 1e5 → 10 request/sec.
>    5. Usage on computing storage -> 1M DAU * 1 MB * 5 years -> 1e6 * 1e6 * 5 * 400 -> 1e6 * 1e6 * 2e3 -> 2 * e15
> 4. You can talk high level design + API design + data schema + data flow at the same time. You can save 5-10 mins by doing this.
> 5. Persist all the discussion into writing/drawing. You don't know when your interviewer will actually get a chance to write your feedback.
> 6. Master your drawing tool. Practice with excalidraw (cuz Facebook uses excalidraw)
> 7. Stop at each milestone and ask questions: "Am I going in the right direction, or do you want me to go deep into somewhere else?"
> 8. Your biggest enemy is not your tech skill. It's usually time. Remember that you only have 35 mins.

**Feedback about Digital Cactus (the interviewer)**  
**Would you want to work with this person?**  
Yes  
**How excited would you be to work with them?**  
2/4  
**How good were the questions?**  
3/4  
**How helpful was your interviewer in guiding you to the solution(s)?**  
3/4

### Interview Transcript

... (transcript continues with detailed interaction between the interviewer and interviewee about the design of the live comments feature, including their approaches to functional requirements, non-functional requirements, and system design. The discussion includes deep dives into technical aspects such as data storage, API design, message queue handling, etc.)

### Summary of Key Points:

- The core design task was to facilitate real-time comments on live media without requiring a refresh of the page.
- Emphasis on both functional and non-functional requirements.
- Discussion of trade-offs in system design, particularly around consistency and availability.