Framework of Thinking - Explaining
Here is some note about the way you need to think, guidance for clear communication.
1. Thinking Framework
1.1. Talk to yourself
-
When talk to yourself, you can use “Ti” to analyze and dive deep analyze more and more ?
-
Solution: You can ask questions from A, to B, to C,… wandering around anything as long as you satisfy to understand everything deeply.
=> The reason you want is to understand knowledge, and inteligence and ability are your pivot.
1.2. Talk to others
- Remember: Other people have different learning curve, they only understand your idea by their learning rate
=> So if they are consume information slower than your delivery speed, they do not understand you. And of course, if they are interviewer or higher title people, it is likely difficult for them to acknowledge that they are wrong or they do not more inteligence than you => they judge you can not explain idea clearly.
- Solution: You must follow a “template” when talking with people, adjust the template with different people.
2. Apply for answering questions
2.1. Dive deep
-
Result
-
Why
-
Worst case
-
Alernative flow
2.2. Storytelling - STAR Method
-
Situation
-
Task
-
Action
-
Result
2.3. Small talk
-
Find someone that match with your personality => FIND COMMON THINGS.
-
Dive deep into the common story => Make them MAKE DECISION BY THEIR OWN.
-
More action when interact with others, not only think.
3. Template for Coding Interview
3.1. Template
-
Understand the problem that you solved: Do not need to find solution is normal, used more time to think => let interviewer to interact to fix your misunderstandings.
-
Ask clarify questions: ask for some question about contrains, duplicates, empty case, negative number, time and space complexity expected.
-
Work through example: Random as much as example possible => interviewer can correct your mistakes.
-
Brainstorm 2-3 solutions: naive solutions, optimized solution, compare the time and space complexity for considering optimization => let interviewer to interact to fix your misunderstandings.
-
Implement solution: now to implement this => Code clean, optimized, syntactically correct solution => Real and runnable, correct code.
-
Test your code: walk-through to the code to dry run, and debug testcases in step 3.
3.3. Apply AI to brainstorm and reinforce each steps
4. Template for System Design
Write with 3 main priority in each category, focus on main ideas for the interview, more details in flow (service call service call infras) and dive deep in pros, cons, how to choose solution.
- Functional requirements
- Brainstorm about 3 requirements
- Non-functional requirements
- Discuss non-FP based on FP
- Availability, Scalability, Performance
- Example
- Availability » Consistency
- The system should be able to scale to support 100M+ DAU (Daily Active Users)
- The system should be low latency, rendering feeds in under 200ms
- Estimate
- Example
- Daily active user
- Action per user
- How long you store data
- Read: Write ratio
- Daily active user (number of users and interaction read:write)
- DAU × actions_per_user_per_day = total_requests/day.
- RPS = total_requests ÷ (24 * 3600).
- Storage (number of items)
- total_records = DAU × records_per_user (if applicable).
- total_storage = total_records × avg_record_size.
- Example Assumptions:
- 300 million monthly active users
- 50% of users use Twitter daily.
- Users post 2 tweets per day on average.
- 10% of tweets contain media.
- Data is stored for 5 years.
- Estimations:
- Example:
- QPS: (daily_active_user _ action / 24 _ 3600)
- Storage: (daily_active_user _ action _ 1MB * time_store)
- Query per second (QPS) estimate:
- Daily active users (DAU) = 300 million * 50% = 150 million
- Tweets QPS = 150 million * 2 tweets / 24 hour / 3600 seconds = ~3500
- Peek QPS = 2 * QPS = ~7000
- Example:
- We will only estimate media storage here. Average tweet size:
- tweet_id 64 bytes
- text 140 bytes
- media 1 MB
- Media storage: 150 million _ 2 _ 10% * 1 MB = 30 TB per day
- 5-year media storage: 30 TB _ 365 _ 5 = ~55 PB
- Example
- API Design
- Input, Output
- Endpoint
- Data Model
- Schema of entity
- Explain the description of each field
- High-level design
- Data flow for each Functional Requirement: FP 1, FP2,…
- Visualize the markdown high level design, example
┌────────────────────────────────────┐ │ Mobile Apps │ │ (Rider / Driver Applications) │ └────────────────────────────────────┘ │ ▼ ┌────────────────────────────────┐ │ API Gateway / LB │ └────────────────────────────────┘ │ ┌──────────────────────────────────┼────────────────────────────────────┐ ▼ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ Fare Service │ │ Trip Service │ │ Search Service │ │ (FP1) │ │ Request/Status │ │ POI Search │ └──────────────────┘ └──────────────────┘ └──────────────────┘ │ │ ▲ │ │ │ │ │ ▼ ▼ │ ▼ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ Routing Service │ │ Matching Engine │ <── driver pings │ Geospatial Index │ │ (ETA, distance) │ │ (FP3) │ (FP3) │ (RedisGeo/Tile38)│ └──────────────────┘ └──────────────────┘ └──────────────────┘ │ │ │ ▼ │ ┌──────────────────┐ │ │ Notification Svc │───► APNs/FCM (Push) │ └──────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────────────────┐ │ Data Storage & State │ ├───────────────────────────────────────────────────────────────────────────┤ │ • Redis Cluster (Live Trip State, Matching State, Driver Status) │ │ • SQL DB (Postgres/CockroachDB) — Durable Trip Records, Payments │ │ • Kafka / Event Bus — Events: ride.requested / accepted / completed │ │ • Object Storage (S3/GCS) — Map tiles, logs │ └───────────────────────────────────────────────────────────────────────────┘ - What each components do
- Detailed each requirement FP1, FP2, FP3 (Explain more details)
- Option 1
- How: Data flow
- Pros
- Cons
- Why to choose
- Short Example
- Option 2
- Option 1
- Find bottlenecks and solution for FP1, FP2, FP3
- Brainstorm bottlenecks | Constraint | Typical Bottleneck | How to Spot | | ——————– | —————————– | ————————————- | | QPS / Throughput | DB writes, queues | Estimate expected QPS vs max capacity | | Latency | Synchronous I/O, API chaining | Count service hops, network calls | | Availability | Single point failures | Check if component can fail alone | | Storage / Growth | DB size, partitioning | Estimate data scale over time |
- How: Data flow
- Pros
- Cons
- Why to choose ?
- Short Example
- Scaling Patterns: Scaling reads, scaling writes, real-time updates, Consistent, Availability, Performance… Give example for edge cases
Notes:
- Prior to complete design for all requirements.
- Show 2 3 options and compare pros, cons, decision skills.
- Dive deep bottlenecks ⇒ Find in user requirements
5. Template for Behaviour Interview
Link: https://anduckhmt146.site/leadership-amazon/
6. Template for Computer Science Interview
-
Application.
-
OS.
-
Network.
7. Template for follow-up questions
-
What is theory, e.g. HTTP and HTTPS. ?
-
What is it used in practice ?
-
Have you used in your work ?

