Mayank Kanoria

You’re in a system design interview at Meta (which owns both Instagram and WhatsApp). The interviewer leans in and asks: "Can you walk me through how the '24-hour stories' feature works on Instagram, and then explain why Instagram and WhatsApp handle story deletion so differently, even though they seem identical to users?" Here’s how you should break it down 👇 Both Instagram and WhatsApp have “stories” that auto-expire. But how they enforce that expiration and what “delete” actually means is very different. 1 . Instagram Stories  ➥What happens when you upload a story: – The app chops videos into 15-sec clips, uploads them to Instagram’s backend. –  Media is stored in “hot” object storage (think S3 bucket), labeled by region, user, and story ID. – Metadata (who posted, when, who can see it) saved in a database. – Your app gets a link (signed URL) to stream the story from Instagram’s servers. – When someone views your story, the app pulls media via CDN for smooth playback. (Stories are pre-fetched and cached for fast loading.) ➥ After 24 hours: + The database record is moved from active to archive table. + The media file’s storage class is switched from “hot” to “cold”, cheaper, but still accessible. + The story is no longer visible, but not deleted. ➥ Instagram uses old stories for: + Highlights + “On This Day” + AI/Ad training + Analytics + CDN cache is cleared (users can’t reload expired stories), but backend keeps the data. ➥ Key tech: + Object storage (AWS S3, Meta’s own) + CDN for fast delivery + TTL in database for auto-expiry in frontend + Archive for long-term storage 2. WhatsApp Status ➥ What happens when you upload a status: – The status is encrypted on your device (AES key only your phone knows). – Encrypted status is uploaded to WhatsApp’s servers in a special folder with your ID. – Metadata (user, expiry time, recipients) is saved in a temp database table. –When friends view your status, their app fetches and decrypts the blob using the key. ➥ Every few hours: + A background “sweeper” job scans for expired statuses. ➥ For each expired status: + Deletes metadata from the DB. +Triggers delete on the blob (media) in storage. +Wipes the decryption key from key vaults. + Client (your phone) deletes local cache. ➥ After this process: +There’s no media file, +No metadata, +No key, +Not even WhatsApp can recover it. ➥ Key tech: +Encrypted blob storage (end-to-end) +Temp metadata tables (expiry tracked with timestamps) +Scheduled “sweeper” jobs So, Instagram stories: Hidden after 24 hours, but stay in backend for features and analytics. WhatsApp status: Fully deleted after 24 hours, with all traces removed for real privacy. —-  P.S. Follow me for more system design insights and check out Layrs - the Leetcode of system design: layrs.me Built to help you crack interviews with: - 60+ problems - Interactive canvas - Instant feedback - Easy-to-hard learning flow Join our Discord: https://lnkd.in/gZbMvZfg

1,325

39 Comments

If I had a system design interview tomorrow at Google, this is exactly how I’d approach it.   (This framework helped me crack 3 FAANG+ companies in the past, including Amazon.)  Most engineers fail system design interviews not because they lack knowledge but because they lack structure.  You don’t need to memorize 100 architectures. You need a structured and easy-to-apply approach that works every time.  Here’s how I break it down:   1/ Clarify the Problem Before Writing Anything   - System design interviews aren’t about throwing buzzwords—they’re about trade-offs.   - Start with scoping → Are we designing just one feature or the entire system?   - Ask constraints upfront → How many users? Read/write ratio? Latency requirements?   - Define success criteria → What matters most? Scalability? Cost? Low-latency?  Most candidates assume things and jump into solutions.   I make sure I know what we’re solving before I even start.   2/ Define Functional & Non-Functional Requirements Clearly   - Functional: What features does the system need?   - Non-functional: What are the performance expectations?   - What’s the biggest technical challenge? (This helps guide the discussion.)  Example: If we’re designing YouTube, is the focus on video uploads, recommendations, or live streaming?   Each has a different set of constraints.   3/ Estimate the Scale & Plan Capacity Like an Engineer   - Users per second? Requests per second?   - Storage needs? If we store 10MB per user and have 100M users, what does that mean?   - Throughput? Can a single database handle the load, or do we need sharding?  Most candidates throw random numbers.   I do quick, back-of-the-envelope calculations to validate my assumptions.   4/ Break the System into Core Components (High-Level Design)   - Define the major building blocks → API Gateway, Load Balancer, Service Layers, Databases.   - Don’t overcomplicate. Simple and scalable always wins.   - Clearly define the interactions between services.  If I’m designing a messaging app, I break it down into:   — User Service (auth, profiles)   — Messaging Service (storing chats)   — Notification Service (real-time updates)   — Media Storage (for images, videos)  Each has different constraints, so I build around what’s most important.  Continued Here: https://lnkd.in/eiHQs-qT P.S. If you’re preparing for tech interviews or appearing soon for one as a SWE. Check out my book Awesome Tech Interviews. It will help you: — Learn techniques to win behavioral interviews — Learn DSA with a detailed 6-month roadmap — Build your foundations of System Design - all in one place. Along with 300+ free online resources. Digital copy: https://lnkd.in/efc7u85w Paperback (Available on Amazon internationally): https://lnkd.in/ePWCr74g

3,442

120 Comments

Leetcode is dead. Maybe you heard about Roy Lee? He's a 21-year-old CS student at Columbia (well, for now) who developed an "undetectable" program that observes problems presented in your remote interview meeting and solves them on an overlay that only you can see. "Interview Coder" eats leetcode for breakfast. Roy used his tool in real interviews for positions at Meta, TikTok, and Amazon, and received offers. As soon as he came clean and started selling the tool, the offers were rescinded, though Roy told journalists that senior folks from large companies contacted him directly offering him jobs, no questions asked. Let's be clear: hiding a tool that's doing all the work for you and pretending that you did it is cheating. Secretly using your calculator watch to remember the decimal for 1/8th of an inch (it's 0.125 by the way) is also cheating. I thought I was pretty clever when I did it, though. But Roy has been outspoken in interviews that he believes that leetcode problems are pointless. It would be like judging someone's ability in journalism by how many jumping jacks they can do, he said on the Hard Fork podcast. I think he's right, and with this explosion of AI tools, he's more right than ever. The "intent" of leetcode is that candidates have internalized all of these algorithmic approaches and can dance through really challenging and arcane problems as a result. What is actually happening is that CS students are spending hundreds of hours on the leetcode site, memorizing the solutions to the problems in the hope that one will be asked verbatim (which they usually are). To my mind, this is like hiring whoever can remember the most digits of pi. The problem they're trying to solve is that they have too many candidates and since they already filtered down to the ones with the most prestigious degrees or most relevant experience, the last hurdle is "have you done hundreds of hours of unpaid labor to try to work here?" And now, in this age of ubiquitous, massive LLMs, we can see more clearly than ever that the king is not wearing any clothes. The way software interviews are carried out has always been just a little bit bonkers. I mean, really, writing code on a whiteboard is as representative of real programming ability as building a model airplane is of your ability to build a REAL airplane. We wouldn't ask a carpenter to demonstrate their ability to do the job without half of their actual tools, would we? Yet we do, all the time! These leetcode problems themselves are so far from what most programmers encounter in their entire careers, and then we expect candidates to solve them in a weird little web IDE with shitty autocomplete. I agree with Roy Lee, leetcode is cooked.

2,312

216 Comments

Imagine you just joined Google as an SWE. It’s your first week, and you’re overthinking everything. You’re surrounded by world-class engineers, new systems, and an overwhelming urge not to mess up. The pressure to prove yourself is real, and so is the anxiety…so what should you do? Over the years, I’ve moved across orgs, teams, and sometimes, entire companies. Here’s exactly what I did (and still do) to ramp up faster and enjoy the process without letting anxiety win → Don’t let yourself stay stuck. If you’re blocked for more than 30 minutes, ask for help. Share what you’ve tried, show initiative, and intent. → Read way more code than you’re assigned. Dive into related modules, historic PRs, and old design docs. The context you gain helps you spot patterns and avoid mistakes. ��� Ask about the story behind the system. Find out why things are built a certain way, what’s failed before, and what’s on the roadmap. Understanding the “why” beats memorizing the “what.” → Volunteer for unglamorous work. Take ownership of tests, docs, or nagging integration bugs. This is where you quietly learn the most and build your internal network. → Offer help before you’re an expert. Chime in when you see questions, review PRs, or share a script. Even small contributions get you noticed for the right reasons. → Connect with skip-levels and cross-team leads. Set up short intros to learn about the broader vision and team priorities. You’ll spot opportunities to add value beyond your immediate tasks. → Document what you learn as you go. Share notes, update READMEs, or post quick how-tos in team channels. Your future self and your teammates will thank you. → Shadow someone during incidents or launches. Sit in on debugging sessions or war rooms, even if you’re just observing. You’ll see how senior folks think, react, and communicate under pressure. → Keep a running list of “how did that break?” moments. Every time you see a system fail or a hotfix go live, dig in. Reverse-engineering past problems is the fastest way to understand the architecture. → Show up with curiosity and intent, every day. Don’t just tick off JIRA tickets. Look for the bigger picture. People notice when you genuinely want to learn and contribute, not just “do your job.” Some orgs assign mentors, some don’t. Either way, these habits put you in the driver’s seat. Ramping up is less about brilliance, more about consistent intent. And the ones who learn this early end up leading teams later.

709

52 Comments

Once you’ve worked long enough as an SWE (spent 8 years like me), facing every disaster you can imagine and been humbled by every sort of problem at companies like Meta, Google, LinkedIn, and Amazon. As a Software Engineer, I want to tell you that your fundamentals set the tone for your career. It’s never about how many frameworks you know. → It has and always will be about how quickly you adapt to new ones. It’s never about writing the most lines of code. → It has and always will be about writing code that’s easy to read, debug, and maintain. It’s never about building the fanciest system from day one. → It has and always will be about solving the actual problem and scaling only when needed. It’s never about acing every interview or online test. → It has and always will be about solving problems nobody saw coming—while under pressure. It’s never about holding a prestigious job title. → It has and always will be about the impact you create for your team and customers. It’s never about being the smartest person in the room. → It has and always will be about helping others get better alongside you. It’s never about knowing every tool out there. → It has and always will be about picking the right tool for the job, even if it’s not trendy. It’s never about chasing 100% code coverage. → It has and always will be about understanding what’s truly critical to test. It’s never about running after every shiny new technology. → It has and always will be about mastering the basics that never go out of style. It’s never about perfection on the first try. → It has and always will be about getting feedback, iterating, and learning as you go. No matter where you work or how senior you get, the engineers who last are the ones who stay grounded in the basics, solve real problems, and help others win. That’s what sets you apart.

194

24 Comments

I’ve been a SWE for the last 6+ years of my life. If I had to start all over again, I wouldn’t really invest in a course or resources without exploring by myself first. Here are 33 free roadmaps you can use today to start in any field in software engineering & crush it! 1. Backend Roadmap: https://roadmap.sh/backend & Frontend Roadmap: https://lnkd.in/dfk4-pa9 2. Full Stack Roadmap: https://lnkd.in/dRjCeDde 3. JavaScript Roadmap: https://lnkd.in/dA4ucqzz 4. TypeScript Roadmap: https://lnkd.in/dYdd4te4 5. React Roadmap: https://roadmap.sh/react 6. React Native Roadmap: https://lnkd.in/dBG72tqu 7. Vue Roadmap: https://roadmap.sh/vue 8. Angular Roadmap: https://roadmap.sh/angular 9. Node.js Roadmap: https://roadmap.sh/nodejs 10. CS Fundamentals Roadmap: https://lnkd.in/d7iDtkm6 11. GraphQL Roadmap: https://roadmap.sh/graphql 12. Rust Roadmap: https://roadmap.sh/rust 13. Go Roadmap: https://roadmap.sh/golang 14. C++ Roadmap: https://roadmap.sh/cpp 15. Java Roadmap: https://roadmap.sh/java 16. Spring Boot Roadmap: https://lnkd.in/dYRPibvp 17. ASP.NET Core Roadmap: https://lnkd.in/dfFXSAgZ 18. Software Architect Roadmap: https://lnkd.in/dDtNN-ch 19. Software Design and Architecture Roadmap: https://lnkd.in/dUHYkH95 20. System Design Roadmap: https://lnkd.in/d3S79YVJ 21. PostgreSQL Roadmap: https://lnkd.in/d8aTRkBD 22. SQL Roadmap: https://roadmap.sh/sql 23. MongoDB Roadmap: https://roadmap.sh/mongodb 24. AI and Data Scientist Roadmap: https://lnkd.in/dv7Tj4ft 25. Python Roadmap: https://roadmap.sh/python 26. Prompt Engineering Roadmap: https://lnkd.in/diZ2U4dG 27. DevOps Roadmap: https://roadmap.sh/devops 28. Docker Roadmap: https://roadmap.sh/docker 29. Kubernetes Roadmap: https://lnkd.in/dVGxcMKQ 30. Android Roadmap: https://roadmap.sh/android 31. Flutter Roadmap: https://roadmap.sh/flutter 32. UX Design Roadmap: https://lnkd.in/dWXzZgqu 33. Design System Roadmap: https://lnkd.in/dasuSJfZ

1,047

45 Comments

Ever wonder how Google handles billions of searches in seconds, or how Netflix instantly recommends the next show you’ll love? During a system design interview, I was asked, “How would you architect something like Google Search so it can process that much data so quickly?” I gave an answer but halfway through, I realized I didn’t actually understand it deeply. So I decided to find out by building my own version. Introducing Mini MapReduce, a web app that simulates how large-scale systems break big jobs into smaller parallel tasks, similar to Google’s distributed infrastructure. It splits any text into shards, counts words in parallel, and then combines the results in real time with progress tracking and word-frequency analysis. Behind the scenes, it handles concurrent shard execution, async progress updates, and persistent storage using Next.js, React, TypeScript, Prisma, PostgreSQL, Tailwind CSS, and an S3-compatible storage layer. It’s a working demonstration of concepts like parallelism, task coordination, and data reduction which are the same principles that power large-scale systems. This project helped me deepen my understanding of large-scale processing and concurrency. Try it here: mini-map-reduce.vercel.app You can click “Run Shakespeare Demo” or paste your favorite song lyrics to see which words dominate. Building this taught me a lot about distributed systems and the complexity behind everyday tech we use. Open to feedback or thoughts from anyone who enjoys large-scale or full-stack engineering!

133

11 Comments

Everyone's telling me llms can't write good code as if that's the norm and every engineer is Hemingway behind the keyboard. Barely-working-stitched-together solutions are predominantly what I've seen in the last 10 years. Good code has always been the outlier. We'll be doing more code reviews than writing as time passes and recognizing good code is more important than ever. We say that we read way more code than we write. And I think the difference will become even more disproportional as llms get integrated into our day-to-day work.

105

85 Comments

🚫 Hot take: LeetCode-style interviews are a terrible way to evaluate engineers—especially at startups. At smaller companies, we’re not hiring people to invert binary trees in isolation. We’re hiring folks who: ✅ Take pride in what they build ✅ Think creatively under constraints ✅ Communicate clearly and collaborate well ✅ Know what they don’t know—and are eager to learn Honestly, one of my favorite things to hear in an interview is: “I’m not sure—I’d want to dig into that a bit more.” That’s not a red flag. That’s self-awareness. That’s a growth mindset. Pretending to know everything? That’s a much bigger problem on the job. I get why big companies rely on leet code and algorithm puzzles. When you have 1,000+ applicants, it’s a fast way to reduce queue depth. But let’s not pretend it’s testing real-world engineering skill. It often just filters for who studied the right patterns… or who bought the right cheat sheet. Sure, we expect you to be intimate and familiar with the programming languages and libraries we use, but that doesn't mean you have to write recursive functions to generate Fibonacci series while we stare at you over zoom. We’re not screening college students for textbook retention. We’re hiring professionals to solve real, ambiguous, evolving problems. At startups, the work is messy, high-impact, and constantly changing. Success looks like learning fast, adapting, and building something great—not solving a trick question under a timer. We don’t need stunt coders. We need thoughtful builders who care.

73

23 Comments

About five years ago, I had a junior engineer on my team who was brilliant but struggled so much he was about to have a low performance review. Let’s call him Anthony He was fresh out of college and eager to prove himself, but his code reviews often came back with extensive feedback. The root of the issue wasn’t his intelligence or effort it was his approach. Anthony had this habit of jumping straight into the deep end. He wanted his code to be optimized, elegant, and perfect from day one. But in that pursuit, he often got stuck either over-engineering a solution or ending up with something too complex to debug. Deadlines were slipping, and his confidence was taking a hit. One day, during a particularly rough code review, I pulled him aside and shared a principle that had profoundly shaped my own career: “Make it work, make it right, make it fast.” I explained it like this: 1. Make it work – First, solve the problem. Forget about how pretty or efficient your code is. Focus on meeting the acceptance criteria. If it doesn’t work, nothing else matters. 2. Make it right – Once it works, step back. Refactor the code, and make it clean, modular, and maintainable. Code is for humans who’ll work with it in the future. 3. Make it fast – Finally, if performance is critical, optimize. But don’t sacrifice clarity or maintainability for marginal speed gains. The next sprint, he followed this approach on a tricky API integration task. When we reviewed his work, the difference was night and day. Not only had he delivered on time, but the code was a joy to read. Even he admitted it was the least stressful sprint he’d had in months. Six months later, Anthony came to me and said, “That principle you shared, it’s changed everything. Thank you for pulling me aside that day.” Today, Anthony is a senior engineer leading his team, mentoring others, and applying the same principle that once helped him. We’re still on good terms though he moved to another org. Sometimes, the most impactful advice is the simplest. As engineers, we often get caught up in trying to do everything perfectly all at once But stepping back and breaking it into manageable steps can make all the difference.

2,159

78 Comments

I have spent the last decade arguing with leaders, managers, peers, and juniors about how important maintaining a high quality codebase is for driving feature work forward. [cue my past coworkers rolling their eyes because I've actually been really annoying about it]. I have cared so much about creating systems that allow product engineers to write high quality code efficiently that I've dedicated my career to it. I have been told many times "if you want to get promoted, focus on being a product engineer, not an infrastructure engineer." But AI is causing these norms to shift, from my vantage point. It feels as if overnight, one's ability to write, and one's ability to understand and apply business context has gone from severely undervalued to crucial. Now, companies are rushing to build guardrails into their systems to prevent AI from going off the rails. Now, suddenly, test coverage, types, and CI systems are considered important. Google's new AI guidance to software engineers emphasizes “'maintaining rigor' across code review, security, and maintenance." It makes me wonder why we're willing to focus on building high quality systems when it helps the machines, but not when it helps the people. https://lnkd.in/eyKhEZx3

119

8 Comments

How long does it really take to reach Senior as a FAANG Software Engineer? Looking at US FAANG SWE salary submissions to Levels.fyi from the past two years reveals some interesting patterns in the path to Senior Engineer and how it compares industry-wide. Across all companies in our database (not just FAANG), the average SWE reaches Senior at around 8.6 years of experience. We roughly calculated this by looking at the total “Years of Experience” of our US SWE submissions and subtracting the “Years at Level” value from it to approximate when someone was hired or promoted into Senior. So how does FAANG compare? - Amazon: Slower to promote. Even with 10–12 years in the industry, only ~50% are Senior+. A big reason is Amazon’s hiring approach, where many mid-career engineers come in at L5 (SDE II). That creates a large pool of experienced engineers who may sit at L5 for years, making the climb to Senior look slower. - Google & Apple: Faster paths, with most engineers Senior by 7–9 YoE. - Netflix: Almost everyone with 10+ YoE is already Senior, reflecting their flatter org structure and strong bias toward hiring directly into senior roles. Very few engineers with significant experience show up below Senior in our data. - Meta: Falls somewhere in between, with a wider spread of outcomes. Taken together, FAANG engineers tend to reach Senior a bit faster than the **industry-wide 8.6-year average**. But the differences across companies are stark. Some ladders are structured to get you there in under a decade, while others keep a broad mid-level population for much longer. Check out more here: https://lnkd.in/gNAuv-gC

243

4 Comments

A few years ago, I coached a senior software engineer targeting roles at Meta, Amazon, and Netflix. I was coaching him on system design.10 minutes into the first mock interview, I understood exactly where the problem was. He wasn’t struggling because he didn’t know system design.   He’d built real systems. He understood CAP theorem, consistency models, and caching inside out. But when the interview started… he froze. He jumped straight into the database schema.   Without any clarification or constraints.   There was no talk about users, scale, latency, or trade-offs. I stopped him and asked why he started with database design and didn’t clarify. Silence. → Most engineers don’t fail system design interviews because they lack knowledge.  They fail because they lack structure.   They’ve read the books. Watched the videos.   But never practiced how to think out loud in real time. That’s what mock interviews fix. They: – Show you how you handle ambiguity.   – Train you to slow down and ask the right questions.   – Reveal blind spots in how you approach problems.   – Help you structure, prioritize, and explain under pressure. We did 3 more mocks.   He rewired his thinking.   Learned to lead the conversation.   And within a month, cracked the Meta interview. System design is not giving the perfect answer.   It’s about communicating your thinking, calmly, and with confidence. Don’t wait till the interview to discover your gaps. Practice like it’s real.   So when it’s real, it feels like practice.

198

7 Comments

🐵 🦁 Depending on who you talk to their experience "vibe coding" is very different. Someone with no technical background is vibe coding in the dark. But someone who knows how to get the most out of the LLMs is using "context engineering" to augment their code. It drives me nuts when people confuse one with another. 🔸 Vibe Coding is not engineering. It’s brute-force prompting without systems thinking. It delivers dopamine, not durability. 🔸 Context Engineering is the real craft. It requires upfront structure: architecture, requirements, success metrics, and scoped prompts. This is what gives AI the ability to reason and ship production-grade code. And precisely how the experts use AI to build products. 🔸 Most enterprise pilots fail because they confuse vibes with viability. A hacked-together Lovable prototype is not a system. When it's time to ship, it breaks against the walls of compliance, security, and integration. 🔸 Engineers reject vibe-coded outputs. Not because they’re anti-AI. But because the code lacks structure, style, and traceability. No serious dev adopts spaghetti. 🔸 Creativity needs constraints. If you want to build real things with LLMs, you don’t need more vibes. You need better context. Link: https://lnkd.in/gdxUthwW #vibecoding #lovable #ai #contextengineering #artificialintelligence

55

7 Comments

YouTube can teach you to code. Google can teach you to code. Even ChatGPT can teach you. As a senior engineer with over 8 years of experience… I don’t mind if a junior engineer on my team isn’t a coding genius. But what no tutorial can teach is how to work well with others. Or how to think like an engineer. Or how to stay calm under pressure when prod is down. That’s what makes someone truly valuable on a team. Not just what you know, but how you work, how you learn, and how you show up. So if you’re early in your journey, focus on these things: ✅ asking good questions ✅ being curious about how things work ✅ communicating clearly especially when things break ✅ not being afraid to say “I don’t know” and then go figure it out ✅ taking ownership, initiative, and having a not-giving-up attitude That’s how great engineers are built.

326

23 Comments

Work trials trend for senior engineering roles in SF: Absolutely unacceptable or the best thing since the sliced (gluten free) bread? --> My take based doing 5 paid work trials within 1 month last year: Before I decided to take my current job, I spent ~10 weeks in the fall intense recruiting. I had ~45 coffee chats, 10 serious processes, and in the end I was deciding in between a couple of offers. Since then a couple of friends (both hiring & recruiting) have reached out to hear about my experience and one of the things consistently standing out as a novelty has been the concept of a work trial. My 5 insights from the 5 work trials I've done: 1️⃣ The Ultimate Show Don’t Tell There’s only so much you can learn about someone when looking at their resume or interviewing them. Meanwhile sometimes you can tell after a few hours, it’s; if it’s a match or not 2️⃣ More Common & Critical for small companies The cost of hiring a wrong person decreases substantially as you move from 5–> 50 —> 500 etc - if you want to join a pre-seed - Series A company in SF, 30-50% of engineering roles will have a work trial. 3️⃣ There’s a limit on how senior hired you can get this way: It screens for commitment: but you can also just get desperation, there are other ways how you can screen for that that do not require people with jobs sacrifices their vacation days 4️⃣ Tech enablement AND smooth onboarding AND decent pay is critical for the candidate experience Setting up my profile in Rippling was pretty standard, it compressed the onboarding time and I quite enjoyed most of the work I did during those trials. But it was work and it was paid (for Sr Engineering roles $100-150/ hour; = ~pro-rated an acceptable base salary) 5️⃣ For me personally, it was a good experience (with an asterisk) + Get an insider feel for multiple companies within a short period of time. + More satisfying and hands-on than interviewing alone. - Tough to manage the awkwardness once I knew this is not for me yet there were still days in the work contract. - I wouldn't have been able to do that, if I had a full time job while going through the process. And ultimately, I still decided to take the plunge with a company where I didn’t get to do a work trials (but did 22 hours of interviews instead 😅). *** I post weekly about my current experience as an engineer building in AI x voice space & early startup employee in San Francisco. Next week I'll dive into the kinks of employee stock options and the related mistakes I wish I WOULDN'T have done. Follow me for more.

34

8 Comments