Principal/Staff Offers Evaluation.. + Prep Strategy
Interviewed with lot of companies in last 2 months and narrowed it down to below 6 companies based on team, level & TC. Priority: Long term career growth, Scope of work, company culture. Company: Level TC: Base + Bonus + Equity (per yr) + Sign-On Team (if known) Meta: E6 743k: 251k + 20% + 347k + 95k Bootcamp Coinbase: Staff Software Engineer 708k: 237k + 15% + 400k + 15% Team matching in progress Snowflake: Senior Software Engineer II 712k: 260k + 15% + 413k Service Runtime team Uber: Staff Software Engineer 246k + 43k + 1.3M (4 yr, 35%, 25%, 20%, 15%) + 43k Michelangelo (ML/AI Infra) Salesforce: Principal Software Engineer 685k: 296k + 15% + 280k + 50k (1st yr) + 50k (2nd yr) Security LinkedIn: Staff Software Engineer 590k: 250k + 15% + 250k (+ Microsoft pro-rated bonus) Infrastructure team Excluding other offers as TC is relatively lower than above.. I am happy to answer any questions on process, preparation strategy and interviews but responses might be delayed.. Current: Microsoft (65) YOE: 10.5 TC: ~400k Thanks folks for the patience. As promised earlier, updating my overall preparation strategy with additional focus on System design. This might end up being a lot of content so will try to update in 3-4 iterations. I will try to cover the below: A. Overall Preparation Strategy B. System Design strategy C. Interview Experience/Tips ○ Applied for 9 companies -> 9 on-sites -> 7 offers. All these offers are Principal/Staff equivalent (except for LinkedIn which offered additional rounds in the end for Senior Staff based on interview performance, but I skipped it). ○ I am bad at negotiations, so I didn’t do it. I used to share the competing offers before any company shared their initial numbers, so they had to beat existing ones if they were really interested. 6 recruiters mentioned that they hit max comp for the level for the Seattle area (no idea if that's true). But this saved me a lot of time and effort. Not a recommendation but this is what I did. [A] Preparation Strategy: ○ Overall, it took me around ~4-5 months for preparation and couple of months for interviews, so this is more of a long-term strategy. If you have interviews coming up in a few weeks, this might not be well suited for you. Don’t stress too much on total duration, it all depends on your day-to-day workload, personal commitments, and your learning speed. ○ For L6/E6/Staff interviews, the focus is more on System design & Behavioral interviews. I will try to cover SD strategy in detail. Let me know in case you guys are interested in Behavioral/Coding strategies too. I can update later once I get time. ○ For breakup, I spent around ~2.5-3 months on SD and ~1.5-2 months on LC. I would advise reserving blocks of time (2 or 3 days to a week) and focus on one category at a time. You can categorize LC simply by topics. More on SD categorization later. I started with SD and moved on to LC only after SD was at ~80%. LC count in the end: 400 (20% easy, 70% med, 10% hard). ○ I prepared for behavioral questions only in the end during the interview days. I would strongly advise preparing for the behavioral stories beforehand as it could be time consuming and overwhelming in the end. I learnt it the hard way. ○ I created a detailed plan and schedule before starting any preparation. This not only helps in tracking your progress and providing motivation as you move forward but also with interview scheduling in the end. ○ I used to set aside 2-3 hours during weekdays (whenever possible) for the prep and larger chunks during weekends. During weekdays, try to push these hours during mornings rather than the end of the day to be more productive. [B] System Design Strategy: ○ I divided the system design preparation into 3 tracks: Track 1: Theory & Real life applications Track 2: System Design Interview Problems Track 3: Cloud Design Patterns and Solutions ○ You need both depth and breadth for SD interviews but depth is what would help justify your level and differentiate you from other applicants. Grokking SD Problems/Alex Xu is NOT going to help with that (IMHO). ○ Focus more on learning fundamentals and concepts and grasping how they are applied in real world systems. This is what Track 1 is all about. This would constitute 60-70% of your SD preparation. Just saying you would use Bigtable/Cassandra may not fly. Instead if you say, system requirements needs a database optimized for certain access patterns (range vs random, writes vs reads) leading to a specific storage engine choice (say LSTM), etc. and then listing some known implementations in market that fulfil those requirements, would create more impact. Start bottoms up with conceptual requirements (CAP, access patterns, transaction isolation, distributed transactions, data relationships, etc.) and conclude towards specific implementation (Bigtable, Cassandra, Spanner, etc.). ○ Another example would be let's say discussion is about web sockets as communication mechanism, most interviewers would expect you to discuss pros/cons with Long polling/SSE. But if you want to knock it out of the park, discuss its caveats (thundering herd on connection migrations, adding jitter to connection lifetimes - why ?, load balancer compatibility - L4/L7) and how will you scale (autoscale - open connections, non-blocking IO - IOCP/epoll ?) ○ Target Track 1 with learning mindset and Track 2 with interview mindset. ○ Best (and probably worst) part of SD interviews are that they are open ended and there is no wrong answer. You need to drive the interview end to end. Focus on highlighting depth of your knowledge & experience. More you know, easier it would be to justify your design choices (everything is a tradeoff). More you know, more confident you are diving into any aspect of the problem. Interviewers gauge what aspects and their depth pushes you out of your comfort zone. ○ Categorizing the resources into 3 buckets: Must, Recommended and Additional Reading. Try to target Must + Recommended at least. [B.1] Track 1: Theory & Real life applications: [B.1.1] Theory: Must: DDIA Must: Kleppmann Lecture series: https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB ○ Read DDIA end to end at least once. Highlight important stuff and make notes. You would end up referring back more often that you think. This will set the foundation with theoretical concepts which would all make sense when you learn about real world systems. ○ All concepts are important so go through it thoroughly. If it says Linearizability, Total Order broadcast and Consensus problems are equivalent to each other, understand why and how. Real world implementations like Spanner, Raft, etc. would be easier to grasp then. ○ Most important chapters: 2, 3, 5, 6, 7, 9, 11 [B.1.2] Whitepapers: Must: ○ Grokking Advanced System Design: https://www.educative.io/courses/grokking-adv-system-design-intvw ○ Memcache: https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf ○ Paxos: https://www.microsoft.com/en-us/research/uploads/prod/2016/12/paxos-simple-Copy.pdf ○ Raft: https://raft.github.io/raft.pdf Recommended: ○ TAO: https://www.usenix.org/system/files/conference/atc13/atc13-bronson.pdf ○ Azure Storage: https://sigops.org/s/conferences/sosp/2011/current/2011-Cascais/11-calder-online.pdf ○ Spanner: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf Additional Reading: ○ Zookeeper: https://www.usenix.org/legacy/event/atc10/tech/full_papers/Hunt.pdf ○ Lamport's Ordering paper: https://lamport.azurewebsites.net/pubs/time-clocks.pdf [B.1.3] System videos: Must: ○ Paxos: https://www.youtube.com/watch?v=d7nAGI_NZPk ○ Raft: https://www.youtube.com/watch?v=JEpsBg0AO6o , http://thesecretlivesofdata.com/raft/ ○ Zuul Push: https://www.youtube.com/watch?v=6w6E_B55p0E Recommended: ○ Fastly: https://www.infoq.com/presentations/health-distributed-system/ ○ Manhattan: https://blog.yugabyte.com/recap-the-distributed-database-behind-twitter/ ○ Twitter Timeline: https://www.infoq.com/presentations/Twitter-Timeline-Scalability/ ○ Slack: https://www.infoq.com/presentations/slack-scalability-2018/ ○ Dropbox: https://www.youtube.com/watch?v=PE4gwstWhmc ○ TAO: https://www.usenix.org/conference/atc13/technical-sessions/presentation/bronson ○ Memcache: https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nishtala ○ Streaming LinkedIn: https://www.youtube.com/watch?v=yqc3PPmHvrA ○ Facebook Live: https://www.youtube.com/watch?v=IO4teCbHvZw Additional Reading: ○ https://medium.com/@anilkkurmi/top-20-infoq-presentation-to-prepare-for-system-design-interview-ad218fab80dd Refer to Part II for the rest: https://www.teamblind.com/post/PrincipalStaff-Preparation-Strategy---II-GXqfWuRP Please DM or comment for any questions. I will try to answer eventually. EDITS: 1. Updated Meta numbers. 2. Updated final Uber numbers and breakup. 3. Updated Preparation Strategy - Iteration 1 4. Updated Preparation Strategy - Iteration 2 5. Updated couple of examples for Iteration 2 6. Updated the link for Part II. #meta #coinbase #uber #salesforce #microsoft #snowflake #linkedin #amazon #google #oracle #systemdesign #principal #interviews #e6 #l6
YouTube
YouTube
Medium
YouTube
Educative: Interactive Courses for Software Developers
InfoQ
Blind
YouTube
The Distributed SQL Blog
YouTube
InfoQ
YouTube
InfoQ
YouTubeWhat was your interview strategy? How’d you get multiple offers? How’d you set the timeline?
How was the interview experience and how did you prepare ?
Updated Preparation Strategy partially.. will get to rest soon..
Can you briefly tell your preparation for staff role. I have some interviews coming scared as f.
I’d go for Snowflake, lot of Google talent is moving to Snowflake. So you can be sure that the WLB won’t be bad, and the engineering bar will be high.
This. I hear Snowflake does good engineering work + wlb is good
685K at principal engineer at Salesforce is unheard of. Congrats op.
Yeah. Their initial offer was low.. post negotiation numbers are higher..
What did you do one week before an interview? Did you keep practicing random questions or had some strategy?
I don't think it's true.mostly fake data. Just look at levels fyi data, that's more accurate
Or maybe levels is outdated and/or has holes? That seems more likely based on offers I’ve received.
There's a good chance it's fake, but it _could_ be real. Regardless, I don't think this is a good place to learn whether _you're_ being paid market value. This type of thing is the whole reason levels.fyi shows you candles.
Congratulations! You are awesome. System design interview strategy please. Are you in Azure?
Thanks! Yes .
If meta interview was good, it can blowout all of these offers
Yes. Interviews were good. Recruiter mentioned they got all hires for E6 with some E7 signals.. so I am expecting high E6..
For Meta E6: 255k + (20%), 1.28m RSU (can be up to 1.4m for ML), 100k signon You are looking at a 656k - ish TC. (without counting the sign on), or 681K TC (if you count sign on over 4 years). They can go out of band sometimes, but it is rare.
Location for each one?
Seattle