I hear hella mixed things about both. For me, WLB > career growth > TC. I’m engaged and like to do good, focused work during normal hours, but I don’t like being pressured to work a million hours a week to avoid PIP. Uber - Team is growing, high value area - Con: was told it will be very busy, minimum (?) 50 hours/week for the foreseeable future. Concerned I’ll drown with the scope/ramp/hours - Con: The commute sucks (50% RTO) LinkedIn (Infra) - Team and tech is less interesting but commute is short (RTO Tues-Thurs starting October) - Con: Less clear info on current state of culture - Con: I have more belief in Uber’s business, not sure on LinkedIn’s long term growth prospects. Interested to hear thoughts on both. Uber TC can beat LinkedIn if I negotiate, but at this level of TC I don’t care much TC: 405k YOE: 8-9 ---------------- PREP ---------------- [Edit] Lots of people asking for prep advice, here are the deets... honestly, nothing special or anything you haven't already heard of. Just keep practicing and interviewing consistently. -- LC -- Start with topics from Neetcode 150 until you feel comfortable with them. If you don't feel comfortable with a topic, do a spike for a day: read about it, solve a bunch of problems, then continue to keep it fresh by keeping it in your rotation. Once none of the problems seem particularly surprising, do random LC from the Leetcode top 100, FB top 100, etc. I mostly did mediums, the occasional hard, most of which I didn't solve in a reasonable amount of time to be honest. The main thing is taking the few minutes at the beginning to really understand the question, hash out exactly what your solution will look like, and run it by the interviewer for a change in direction in case you've gone down the wrong path. -- SD -- SD interviews are a skill in themselves. Even if you have a lot of experience building distributed systems, having a consistent and reproducible system (heh) for doing these interviews is important. Use Alex Xu's second book to get the format down and refresh on a bunch of miscellaneous topics. The first book isn't nearly in-depth enough for senior or higher--maybe useful for ideas for things to practice designing. Even with the second, anything that doesn't go into enough detail--you should find a couple things every chapter, or more--write it down and research it later. Question claims the author makes. If they say "X is a good choice here", and they don't also answer WHY, look that thing up and make your own assessment. The interviewer may well ask you why you made that choice, and you should be able to explain that to them with an informed perspective. Once that's done, start doing "design X" on your own, 45-60 minutes. Then look up examples of that system and see how yours compares. If there's anything you felt unsure about, note it down and research it. You should be able to guesstimate what scale you can handle with an RDBMS and when you'd want to consider something else; you should understand WHY Cassandra comparatively performs so well with high write load (i.e. B-trees vs. LSM trees). It really helps if you find this stuff genuinely interesting; try to approach it out of personal interest rather than "stuff to memorize" and you'd be surprised at how often the knowledge comes up. Note that the overall idea here isn't just figuring out "what to remember to pass the interview", it's actually improving your knowledge and confidence. For these deeper details, consume SD talks and relevant books, such as the following: DDIA - Martin Kleppmann Database Internals - Alex Petrov USENIX - YouTube InfoQ - YouTube Also read company blogs: FB, Netflix, Uber, etc Some talks I have noted down https://www.youtube.com/watch?v=m4_7W4XzRgk https://www.youtube.com/watch?v=IO4teCbHvZw https://www.youtube.com/watch?v=sNIvHttFjdI https://www.youtube.com/watch?v=6w6E_B55p0E https://www.youtube.com/watch?v=7AO4t7G8Bmk https://www.youtube.com/watch?v=yqc3PPmHvrA https://www.youtube.com/watch?v=hnpzNAPiC0E https://www.youtube.com/watch?v=HuDJBTPdaOA https://www.youtube.com/watch?v=_BfMH4GQWnk -- Behavioral -- Honestly you just have to have some stories prepared and be able to speak to your experience. There's no secret here. If a HM asks you about a conflict you have at work, think of something, present the scenario, and present the solution. Overall, I'd recommend being solution and customer oriented no matter the question. I probably do the least prep for this, but did write down a number of things I could imagine coming up as well as write notes on previous projects in detail, so I wouldn't forget them, and even referenced them during interviews. Nobody seemed to mind. Even with the above I still got rejections, even for SD which is for sure my strongest. It's a numbers game, folks. Just focus on continuously improving, studying at a sustainable pace, staying consistent, and putting yourself out there. #offers #Offer EvaluationStreaming a Million Likes/Second: Real-Time Interactions on Live VideoYouTubeScaling Facebook Live Videos to a Billion UsersYouTubeScaling Push Messaging for Millions of Devices @NetflixYouTubeNSDI ’13 - Scaling Memcache at FacebookYouTubeUSENIX ATC ’13 - TAO: Facebook’s Distributed Data Store for the Social GraphYouTubeNetflix Networking: Beating the Speed of Light with Intelligent Request RoutingYouTubeScaling Instagram InfrastructureYouTubeCassandra Internals: The Read Path (Tyler Hobbs, DataStax) | Cassandra Summit 2016YouTubeCassandra at Instagram 2016 (Dikang Gu, Facebook) | Cassandra Summit 2016YouTubeSelect only one answerLinkedInStaff Software EngineerSeattle, WA, US • StaffTC: $510KUberStaff Software EngineerSeattle, WA, US • 5bTC: $501KRelated CompaniesHide company name0 credits left