惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Google DeepMind News
Google DeepMind News
博客园_首页
aimingoo的专栏
aimingoo的专栏
IT之家
IT之家
美团技术团队
GbyAI
GbyAI
博客园 - 司徒正美
Recent Commits to openclaw:main
Recent Commits to openclaw:main
www.infosecurity-magazine.com
www.infosecurity-magazine.com
S
Security @ Cisco Blogs
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Jina AI
Jina AI
The Cloudflare Blog
O
OpenAI News
雷峰网
雷峰网
P
Proofpoint News Feed
Google DeepMind News
Google DeepMind News
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
F
Fortinet All Blogs
量子位
C
CERT Recently Published Vulnerability Notes
V
V2EX
J
Java Code Geeks
H
Help Net Security
小众软件
小众软件
H
Hacker News: Front Page
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
T
Tor Project blog
Y
Y Combinator Blog
Spread Privacy
Spread Privacy
Martin Fowler
Martin Fowler
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Scott Helme
Scott Helme
N
News | PayPal Newsroom
Vercel News
Vercel News
爱范儿
爱范儿
TaoSecurity Blog
TaoSecurity Blog
Webroot Blog
Webroot Blog
博客园 - 叶小钗
T
Threat Research - Cisco Blogs
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
N
Netflix TechBlog - Medium
宝玉的分享
宝玉的分享
G
GRAHAM CLULEY
MyScale Blog
MyScale Blog
Security Archives - TechRepublic
Security Archives - TechRepublic
L
Lohrmann on Cybersecurity
阮一峰的网络日志
阮一峰的网络日志
V
Visual Studio Blog
S
Schneier on Security

Arpit Bhayani

Temporal Primer - Building Long-Running Systems What Matters in Production RAG Structure of Every LLM Chat How LLMs Really Work Your Monolith Is Already A Distributed System Databases Were Not Designed For This BM25 JOIN Algorithms Venting at Work Comes at a Reputation Cost Why Half Your Skills Expire Every Few Years Multi-Paxos - Consensus in Distributed Databases MySQL Replication Internals Bloom Filters When You Increase Kafka Partitions Product Quantization The Q, K, V Matrices The Day I Accidentally Deleted Production How LLM Inference Works What are Blocking Queues and Why We Need Them Heartbeats in Distributed Systems How Writes Work in Apache Cassandra Redis Replication Internals How to Handle Arrogant Colleagues at Work How Does a CDN Handle Content Replication You Can't Fix Everything on Day One When Emotions Spill Over at Work Why gRPC Uses HTTP2 Meetings With No Agenda Are a Waste of Time Career Longevity Beats Constant Job Hopping Stay Relevant at Higher Salary Levels Why Distributed Systems Need Consensus Algorithms Like Raft Why Do Databases Deadlock and How Do They Resolve It Why and How Cache Locality Can Make Your Code Faster Why Eventual Consistency is Preferred in Distributed Systems Why does DNS use both UDP and TCP Should You Do a Master's My Honest Take Empathy Makes Great Engineers Unstoppable Good Mentors Build People, Not Just Skills Why You Should Always Have Back-Burner Projects Before You Push Back, Know What You're Standing On Be the One They Can Count On How Much Are People Willing to Bet on You How to Get Leadership to Say Yes to Your Project Don't Let Your Best Ideas Die in Silence Be the Person Everyone Wants to Work With The XY Problem and How to Avoid It The Startup Hiring Lie Nobody Talks About You Won't Be Promoted Unless You Ask It's Not Enough to be Right; Learn to be Heard No One Ships Great Software Alone You Don't Win by Proving Others Wrong Appreciate Generously; It Costs Nothing, But Builds Everything Your Soft Skills Aren't Soft at All Before you form an opinion, experience it Why You Need Both Curiosity and Action to Thrive A Daily Worklog Changed Everything How We Handle Mistakes Defines Us Own Your Mistakes Don't Wait. Step Up. Temporary Fixes Are Permanent Why Interviews Are Biased And What Sets You Apart Saying 'This isn't my problem' is actually the problem How to Write Effective OKRs Never Lose a Battle due to Miscommunication When In Doubt, Code It Out How to Follow Up Without Annoying People Lead Projects That Land, Execution Over Everything Abstract Thinking Will Define Your Next Decade We Engineers Suck at Task Estimation Shiny Obect Syndrome in Tech When to Change Jobs - The 3P Framework Comfort and Competition - Know When to Switch Gears Paper Notes - On-demand Container Loading in AWS Lambda Paper Notes - SQL Has Problems. We Can Fix Them Pipe Syntax In SQL Paper Notes - NanoLog - A Nanosecond Scale Logging System Don't Wait, Learn - The Best Resource is Mythical Paper Notes - WTF - The Who to Follow Service at Twitter The Unexpected Benefit of Reading Random Engineering Articles Roadmaps Are Limiting Your Growth Stop Leaving Money on the Table - Negotiate Your Job Offer Never Bad-Mouth Your Past Employers Show You're a Culture Fit Quantify your resume, Know Your Numbers The Importance of Being Likeable in Interviews Questions to Ask Your Interviewer How to Build Trust Through Collaboration Do This, Once You Are Out of the Interview Cycle Stop Pitching Ideas, Start Pitching Projects Read Those Design Docs, Even the Ones That Seem Irrelevant The Best Engineering Lessons Happen During Outages Great Engineers Start Broad LLM Summaries are Ruining Your Learning Title Inflation At Work, Find Your Own Projects 6 Simple Strategies to Cracking Any Tech Interview How to Remain Unblocked Solving the Knapsack Problem with Evolutionary Algorithms Generating Pseudorandom Numbers with LFSR Local vs Global Indexes in Partitioned Databases Partitioning Data - Range, Hash, and When to Use Them
Turn System Design Interviews into Discussions
Arpit Bhayani · 2024-05-06 · via Arpit Bhayani

System design interviews can be tricky because the discussions are always open-ended. Instead of getting overwhelmed, here is a structured approach that you can use to put your best foot forward and crack it with ease.

  1. understand the problem statement: 3 to 4 minutes

Instead of jumping into designing the system from the word go, spend the first few minutes understanding the problem statement, and asking clarifying questions to understand the context, constraints, and expectations.

  1. design a day-0 solution: 5 to 7 minutes

Now take 5-7 minutes to design a simple, naive, unoptimized day-0 solution. It is okay if this design is not scalable, available, or fault-tolerant With this the interviewer

  • will have a fair bit of idea about your approach,
  • can tell you if you are on the right track or not
  • or if you should be focussing on a specific component more
  1. improve your design: 15 minutes

Now for each component in your system, assume it in different scenarios - large number of requests, system crash, network failures, etc. and see how your system behaves. Rearchitect it to handle the failure cases gracefully, and add new components if required.

  1. ask the interviewer for any follow-up questions: 8 minutes

Allow the interviewer to ask you follow-up questions about your system and you provide him/her with justifications for your design and trade-offs you took. This segment is important because it just turned your interview into a discussion.

  1. go into finer details: 8 minutes

Depending on the conversation and expectations, touch upon the finer implementation details like handling concurrency, streaming responses, transient failures, etc. This is where you showcase that you know what you are talking about.

This is how I always spend 40-45 minutes during the System Design interviews I appear in. Hope this helps you crack your next one.