# Evan King Stories by Evan King on Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## New Grad to Staff at Meta in 3 years DevFeed: [New Grad to Staff at Meta in 3 years]() Original publisher: [Read original article]() Author: Evan King Published: 2024-12-12T05:46:36Z Content type: opinion Language: en Sources: [Evan King]() Topics: [Development](), [Meta]() Tags: [career](), [dev](), [manager](), [meta]() ### AI overview Evan King reflects on progressing from junior engineer to Staff at Meta in three years. He attributes the unusually rapid progression to favorable circumstances, including organizational growth and managerial support, as well as principles such as working efficiently, operating beyond one's level, sharing ideas without needing certainty, focusing on problems rather than technologies, and building goodwill. ### Source excerpt By Evan King, co-founder of hellointerview.com Junior to Staff at Meta in 3 years. That sentence raises eyebrows. I've dodged telling this story for years. Maybe it's the ex-athlete in me cringing at self-promotion, or maybe I'm just uncomfortable with attention I'm not sure I deserve. But after countless requests to share it, I figured it's worth putting out there -- even if it makes me squirm. Let's start with the reality check: I hit the timing jackpot. Right org, explosive growth phase, and a manager who saw something in me before I saw it myself. If you're looking for a pure meritocratic story, this isn't it. Nobody lands promotions this fast without the stars aligning. Still, there were patterns and principles that emerged -- insights that might be useful to others on their own paths. Looking back, six key principles had the largest effect on my career. First principle: Speed is your multiplier. Everyone talks about thinking bigger or making an impact, but none of that matters if you can't nail your core work faster than others. When you can complete your normal workload with 70% of your time, that extra 30% becomes your secret weapon. That's where the real growth happens. The second principle relies on the first: Keep your head up and your aperture wide. Use that extra bandwidth to operate like someone a level above you. As a junior dev, I studied what my teammates were doing, connecting dots they might have missed. At senior, I expanded that lens to sister teams. By Staff, I was thinking across entire organizations. Here's the third thing, and it's a liberating truth: No one has all the answers. Not your boss, not the VPs, not even the CEO. This isn't meant to dismiss their expertise -- I've learned invaluable lessons from every leader I've worked with. But realizing this freed me to put my ideas out there without the paralyzing weight of needing to be right. The fourth principle grounds everything else: focus on problems, not technologies. You don't need to be ## Big Tech's Money Paradox DevFeed: [Big Tech's Money Paradox]() Original publisher: [Read original article]() Author: Evan King Published: 2024-12-09T22:10:13Z Content type: opinion Language: en Sources: [Evan King]() Topics: [saving](), [Software]() Tags: [money](), [saving](), [tech]() ### AI overview An opinion essay argues that highly paid Big Tech engineers can become excessively focused on saving and optimizing investments, at the expense of happiness and relationships. Drawing on personal observations and a cited view from Arthur Brooks, it recommends balancing financial security with spending on shared experiences. ### Source excerpt Big Tech engineers making hundreds of thousands of dollars a year are the world's most anxious penny pinchers. I saw it every weekend while living in Seattle: software engineers making half a million dollars arguing over dinner bills down to the cent, cramming into someone's car to save $5 on an Uber, and pre-gaming at home to avoid $15 cocktails. All while making more money than we knew what to do with. It took moving to LA to realize just how weird this behavior is. Here, I've made friends outside the tech bubble -- people making significantly less than my Seattle circle, yet somehow living much richer lives. They grab the check without hesitation. Spring for concert tickets on a whim. Generally seem to enjoy their money rather than hoarding it like dragons guarding their gold. The contrast was jarring. In Seattle, we'd spend hours fine-tuning our investment strategies and debating the optimal savings rate. Every dollar spent was a dollar that could be invested, and we could calculate exactly how much we expected that dollar would be worth in 30 years. The engineer's mindset applied to lifestyle choices -- and it was making us miserable. I get it. We're analytical by nature. Tech attracts people who love watching numbers go up and to the right. But we're optimizing for the wrong variable. The proof is right there on Blind. Some of the unhappiest posts come from people making $1M/y who are stressed about not saving enough. They've solved the money problem but lost sight of the happiness equation. Arthur Brooks, a Harvard professor who studies the science of happiness, was asked a simple question: does money buy happiness? His answer was surprising. "Yes," he said. But it came with a crucial caveat: "yes, if that money is spent on experiences with the people you love." On the other hand, he found those hoarding money, regardless of how wealthy they were, were almost always the least happy. Here's what I've learned since leaving the tech bubble: investing in experience ## Design an Ad Click Aggregator DevFeed: [Design an Ad Click Aggregator]() Original publisher: [Read original article]() Author: Evan King Published: 2024-12-04T04:20:50Z Content type: tutorial Language: en Sources: [Evan King]() Topics: [data-processing](), [Requirements](), [Latency](), [realtime](), [Database]() Tags: [architecture](), [data-processing](), [database](), [latency](), [performance](), [query](), [realtime](), [requirements](), [scale]() ### AI overview A tutorial on designing an ad click aggregator. It defines functional and non-functional requirements, including advertiser metric queries, scalability, low-latency analytics, fault-tolerant and accurate collection, near-real-time availability, and idempotent click tracking. ### Source excerpt By a former Meta Staff engineer and Co-founder of hellointerview.comFinal DesignUnderstanding the Problem🖱 What is an Ad Click Aggregator An Ad Click Aggregator is a system that collects and aggregates data on ad clicks. It is used by advertisers to track the performance of their ads and optimize their campaigns. For our purposes, we will assume these are ads displayed on a website or app, like Facebook.Functional Requirements Core Requirements Users can click on an ad and be redirected to the advertiser's website Advertisers can query ad click metrics over time with a minimum granularity of 1 minute Below the line (out of scope): Ad targeting Ad serving Cross device tracking Integration with offline marketing channels Non-Functional Requirements Before we jump into our non-functional requirements, it's important to ask your interviewer about the scale of the system. For this design in particular, the scale will have a large impact on the database design and the overall architecture. We are going to design for a system that has 10M active ads and a peak of 10k clicks per second. The total number of clicks per day will be around 100M. With that in mind, let's document the non-functional requirements: Core Requirements Scalable to support a peak of 10k clicks per second Low latency analytics queries for advertisers (sub-second response time) Fault tolerant and accurate data collection. We should not lose any click data. As realtime as possible. Advertisers should be able to query data as soon as possible after the click. Idempotent click tracking. We should not count the same click multiple times. Below the line (out of scope): Fraud or spam detection Demographic and geo profiling of users Conversion tracking Here's how it might look on your whiteboard: The Set UpPlanning the Approach For this question, which is less of a user-facing product and more focused on data processing, we're going to follow the delivery framework outlined here, focusing on the system interfa ## Design a Ticket Booking Site Like Ticketmaster DevFeed: [Design a Ticket Booking Site Like Ticketmaster]() Original publisher: [Read original article]() Author: Evan King Published: 2024-11-27T05:34:17Z Content type: tutorial Language: en Sources: [Evan King]() Topics: [Requirements](), [Availability](), [consistency](), [Latency](), [Low Latency](), [Transactions](), [CI/CD]() Tags: [availability](), [booking](), [ci-cd](), [consistency](), [latency](), [low-latency](), [requirements](), [strategy]() ### AI overview A system-design tutorial for a Ticketmaster-like ticket booking site. It defines functional requirements for viewing, searching, and booking events, then outlines non-functional requirements including availability, consistency to prevent double booking, scalability, low-latency search, and high read throughput. ### Source excerpt With Ex-Meta Staff Engineer & co-founder of hellointerview.comUnderstanding the Problem🎟 What is Ticketmaster? Ticketmaster is an online platform that allows users to purchase tickets for concerts, sports events, theater, and other live entertainment.Functional Requirements Core Requirements Users should be able to view events Users should be able to search for events Users should be able to book tickets to events Below the line (out of scope): Users should be able to view their booked events Admins or event coordinators should be able to add events Popular events should have dynamic pricing Non-Functional Requirements Core Requirements The system should prioritize availability for searching & viewing events, but should prioritize consistency for booking events (no double booking) The system should be scalable and able to handle high throughput in the form of popular events (10 million users, one event) The system should have low latency search (< 500ms) The system is read heavy, and thus needs to be able to support high read throughput (100:1) Below the line (out of scope): The system should protect user data and adhere to GDPR The system should be fault tolerant The system should provide secure transactions for purchases The system should be well tested and easy to deploy (CI/CD pipelines) The system should have regular backups Here is how the requirements might look on the whiteboard: Adding features that are out of scope is a "nice to have". It shows product thinking and gives your interviewer a chance to help you reprioritize based on what they want to see in the interview. That said, it's very much a nice to have. If additional features are not coming to you quickly, don't waste your time and move on.Planning the Approach Before you move on to designing the system, it's important to start by taking a moment to plan your strategy. Fortunately, for these common user-facing product-style questions, the plan should be straightforward: build your design up sequent ## System Design Interview Framework DevFeed: [System Design Interview Framework]() Original publisher: [Read original article]() Author: Evan King Published: 2024-11-19T21:39:41Z Content type: tutorial Language: en Sources: [Evan King]() Topics: [Requirements](), [structure](), [systems](), [Framework](), [client]() Tags: [approach](), [framework](), [interview](), [requirements](), [structure](), [system-design-interview](), [systems]() ### AI overview A practical framework for system design interviews that emphasizes delivering a working system. It recommends spending about five minutes clarifying and prioritizing functional and non-functional requirements, with examples involving Twitter and a cache. ### Source excerpt From the co-founder of www.hellointerview.com The easiest way to sabotage your chances of getting an offer in your system design interview is to fail to deliver a working system. This is the most common reason that mid-level candidates fail these interviews. While a firm structure to your approach is important and your interviewer is not trained specifically to assess you on your delivery (often this gets bucketed into "communication"), in practice we've seen many candidates that perform significantly better by following a structure which both keeps them from getting stuck and ensures they deliver a working system. Requirements (~5 minutes) The goal of the requirements section is to get a clear understanding of the system that you are being asked to design. To do this, we suggest you break your requirements into two sections. 1) Functional Requirements Functional requirements are your "Users/Clients should be able to..." statements. These are the core features of your system and should be the first thing you discuss with your interviewer. Oftentimes this is a back and fourth with your interviewer. Ask targeted questions as if you were talking to a client, customer, or product manager ("does the system need to do X?", "what would happen if Y?") to arrive at a prioritized list of core features. For example, if you were designing a system like Twitter, you might have the following functional requirements: Users should be able to post tweets Users should be able to follow other users Users should be able to see tweets from users they follow A cache meanwhile might have requirements like: Clients should be able to insert items Clients should be able to set expirations Clients should be able to read items Keep your requirements targeted! The main objective in the remaining part of the interview is to develop a system that meets the requirements you've identified -- so it's crucial to be strategic in your prioritization. Many of these systems have hundreds of features, but it ## DynamoDB For System Design Interviews DevFeed: [DynamoDB For System Design Interviews]() Original publisher: [Read original article]() Author: Evan King Published: 2024-11-19T21:30:02Z Content type: tutorial Language: en Sources: [Evan King]() Topics: [DynamoDB](), [Amazon Web Services](), [NoSQL](), [Database](), [Transactions](), [Provisioning](), [Application Development](), [configuration](), [Learning](), [vendor lock-in]() Tags: [aws](), [configuration](), [data-storage](), [database](), [dynamodb](), [learning](), [nosql](), [provisioning](), [system-design-interview](), [transactions]() ### AI overview This tutorial explains DynamoDB for system design interviews. It covers DynamoDB's managed operation, scalability, key-value and NoSQL data model, transaction support, lack of open-source internals, and practical considerations including vendor lock-in and whether interviewers permit its use. ### Source excerpt By the Co-founder of www.hellointerview.comIntro DynamoDB is a fully-managed, highly scalable, key-value service provided by AWS. Cool, buzz-words. But what the hell does that mean and why does it matter? Fully-Managed -- This means that AWS takes care of all the operational aspects of the database. The fully-managed nature allows AWS to handle all operational tasks -- hardware provisioning, configuration, patching, and scaling -- freeing developers to concentrate on application development. Highly Scalable -- DynamoDB can handle massive amounts of data and traffic. It automatically scales up or down to adjust to your application's needs, without any downtime or performance degradation. Key-value -- DynamoDB is a NoSQL database, which means it doesn't use the traditional relational database model. Instead, it uses a key-value model that allows for flexible data storage and retrieval. The moral of the story is that DynamoDB is a super easy to use and can scale to support a wide variety of applications. For system design interviews in particular, it has just about everything you'd ever need from a database. It even supports transactions now! Which neutralizes one of the biggest criticisms of DynamoDB in the past. Importantly, DynamoDB is not open-source, so we can't as easily describe its internals like we did with breakdowns of open source technologies like Kafka and Redis. Instead, we'll focus more on you interact with it. In order to look under the hood, we'll rely on the limited information AWS provides via documentation and the DynamoDB Whitepaper. In this deep dive, we'll break down exactly what you need to know about DynamoDB in order to field any question about it in a system design interview. Along the way, you'll also acquire practical learning that you can later apply in your own projects. Let's break it down! Candidates often ask me, "am I even allowed to use DynamoDB in an interview?"The answer is simple, ask your interviewer! Many will say yes, and just expec ## Kafka for System Design Interviews DevFeed: [Kafka for System Design Interviews]() Original publisher: [Read original article]() Author: Evan King Published: 2024-07-01T03:18:09Z Content type: tutorial Language: en Sources: [Evan King]() Topics: [Kafka](), [Apache-Kafka](), [Event-Streaming](), [stream-processing](), [Scalability](), [data]() Tags: [apache-kafka](), [distributed](), [durability](), [google](), [high-performance](), [kafka](), [meta](), [open-source](), [real-time](), [scalability](), [stream-processing](), [system-design-interview]() ### AI overview A tutorial on Apache Kafka for system design interviews. It explains Kafka as an open-source distributed event streaming platform that can function as a message queue or stream processing system, then uses a real-time sports statistics example to discuss producers, consumers, scaling, and event ordering. ### Source excerpt By the Co-founder of www.hellointerview.comIntro There is a good chance you've heard of Kafka. It's popular. In fact, according to their website, it's used by 80% of the Fortune 100. If it's good enough to help scale the largest companies in the world, it's probably good enough for your next system design interview. In fact, it's one of the top 5 technologies we see used in design interviews. Apache Kafka is an open-source distributed event streaming platform that can be used either as a message queue or as a stream processing system. Kafka excels in delivering high performance, scalability, and durability. It's engineered to handle vast volumes of data in real-time, ensuring that no message is ever lost and that each piece of data is processed as swiftly as possible. In this deep dive, we're going to take a top down approach. Starting with a zoomed out view of Kafka and progressing into more and more detail. If you know the basics, feel free to skip ahead to the more advanced sections. A Motivating Example It's the World Cup (my personal favorite competition). And we run a website that provides real-time statistics on the matches. Each time a goal is scored, a player is booked, or a substitution is made, we want to update our website with the latest information. Events are placed on a queue when they occur. We call the server or process responsible for putting these events on the queue the producer. Downstream, we have a server that reads events off the queue and updates the website. We call this the consumer. Now, imagine the World Cup expanded from just the top 48 teams to a hypothetical 1,000-team tournament, and all the games are now played at the same time. The number of events has increased significantly, and our single server hosting the queue is struggling to keep up. Similarly, our consumer feels like it has its mouth under a firehose and is crashing under the load. We need to scale the system by adding more servers to distribute our queue. But how do we e ## Top Meta Software Engineer System Design & Product Architecture Interview Questions 2024 DevFeed: [Top Meta Software Engineer System Design & Product Architecture Interview Questions 2024]() Original publisher: [Read original article]() Author: Evan King Published: 2024-05-16T00:34:59Z Content type: tutorial Language: en Sources: [Evan King]() Topics: [Architecture & Design](), [Software](), [coding]() Tags: [architecture](), [architecture-design](), [blog-post](), [interview](), [interview-questions](), [interview-tips](), [meta](), [software-engineer](), [software-engineering](), [system-design-interview]() ### AI overview A former Meta Staff engineer and interviewer presents commonly asked Meta system design and product architecture interview questions. The article distinguishes the two interview types and advises readers to study the underlying concepts and problem-solving frameworks rather than memorize answers. ### Source excerpt I'll cut to the chase, my names Evan, I am a former Meta Staff engineer and interviewer. I've been putting together breakdowns of common problems asked across the top FAANGs. When it comes to the Meta design interview, they let you choose between a System Design interview and a Product Architecture interview. Not sure what the difference is? Checkout this blog post I wrote on the topic. But anyway, I know what you're here for. In my experience, here are the questions that are most commonly asked for each interview type. Read the linked breakdowns, definitely, but these aren't interviews where you can just memorize an answer key, so don't treat them as such. Use them to learn the underlying concepts and frameworks for tackling these types of problems. System Design Design an Ad Click Aggregator Design a Top K Service Design Memcached Design FB Live Comments Design TAO Design Uber Design Ticketmaster Design a Distributed Job Scheduler Product Architecture Design Ticketmaster Design Uber Design IG Auction Design Dropbox Design Newsfeed Design Facebook i18n Design Just the UX and APIs for Newsfeed Design Leetcode Design Messenger