5 interviews, 5 offers

I studied/did phone interviews over a span on 3 months. I took the last two weeks off work to focus on the last bit of prep I wanted to do + the on-sites themselves. My prep over those few months: 1. ~350 LC questions - ~80-90 easy, 200+ mediums, and ~50-60 hards. During the latter part of my prep, I focused mainly on mediums and solving them in ~20-30 minutes. At the end I was in the 15-20 minute range for solving mediums. My strategy was to study areas that I was uncomfortable with (for me, it start with sliding window, then improving trees, then graph, then DP). It feels nice to solve problems you already know how to do, but you won't be improving. Your main focus should be getting a good breadth of knowledge, then going with depth if you have time. As a follow up, during my first month and a half of prep, I just worked on the most frequently asked questions. Then as on-sites approached, I went into more company specific questions such as top 50 questions from X company, and if you have LC premium on the top bar if you go to "Explore" > "Interview", there are company specific guides. If you're in a rush, here's a list that's popular on Blind: https://leetcode.com/list/xi4ci4ig/ Create a template for each type of problems/approach; having a template for DFS, BFS, binary search, etc. helps a lot, since you don't have to think of an approach mid-interview and it'll be second nature when you're typing out the solutions. Templates help with speed and correctness of the code. Some of the templates I used are: - sliding window - topological sort - graph/tree traversal - trie - prefix sum - DFS recursive and iterative; DFS + memoization - BFS - backtracking Example template for topological sort: - I wrote from scratch without checking my notes/debugging it, so please don't use this unless you double check its correctness foo( ... ) { // Create map of node and connections // key is node, value is array of neighbouring nodes const connections = {} // do work to create connects map // Traverse the map // traversed map is used to keep track of nodes already traversed // without having to check order array // O(1) check in traversed instead of O(n) checking order array const order = [], traversed = {} for( let i = 0; i < node.length; i++) { if (!traverse(i,connections,order,traversed)) { return [] } } // order needs to be reversed since the first things written // into the array are the leaves return order.reverse() } traverse(node,connections,order,traversed,visited={}) { // visited is used to determine cycles if (traversed[node]) { return true } if (visited[node]) { return false } visited[node] = true for(let i = 0; i < connections[node].length; i++) { const connectedTo = connections[i] if (!traverse(connectedTo,connections,order,traversed,visited)) { return false } } order.push(node) traversed[node] = true visited[node] = false return true } ---------------- End of topological sort template --------------- Along with having problem templates, have a template for approaching the problem. Mine was: - ask clarifying questions, find edge cases, ask the input/output of the problem, etc - if possible discuss different approaches, and ask your interviewer which way they prefer you to go. Eg. I could do binary search instead of sorting, which would have faster runtime, but it would take longer to code. Is it okay if I code the solution using sorting and implement the binary search method if I have time? - come up with the approach and have a high level plan - once you and the interview agree on an approach, code away Edit: After writing that topological sort template from scratch, I remembered that a very important thing especially for G/FB is to be able to verify/debug your code without compiling it. You will not be compiling your code in most interviews, so make sure you step through it with sample inputs. Debugging is an extremely important step, especially for G/FB. 2. I spent a few days on LP/behavioural questions. I've always done well on these so I didn't put much effort into them. 3. System design - read all of the system design primer (https://github.com/donnemartin/system-design-primer), parts of DDIA, and a lot of youtube videos about system design. At a minimum, you should go through the WHOLE system design primer. If you're pressed for time, I don't recommend reading the whole DDIA book, but I would recommend reading parts of it if you want to dig a bit deeper on specific components. After reading the system design primer, you should understand the following: - CAP theorem: Availability vs Consistency - Caching strategies; in-memory DBs, application caching - Databases: NoSQL vs Relational DBs - Scaling: how to handle growth from 100 users to 100 million, how to handle consistent vs spiky traffic - Synchronous vs Async processing - System components such as reverse proxies/load balancers, DNS, CDNs - Communication: TCP/UDP, polling, websockets - Fault tolerance strategies Watch mock system design interviews on Youtube, and follow their work flow. This helped me create the template I used for system design questions. My strategy was to cover the following: - function reqs (ask for priority features) - non-functional reqs (availability vs consistency, latency, throughput/QPS, durability, traffic distribution, API pattern (read or write heavy), testing/deployment/monitoring (optional)) - data (1. estimate the data that's going through your system, 2. high-level of the DB schema) - api (optional) - system design (drawing of the architecture) Similar to preparing for LC you need to prepare breadth for system design. You should know how to design different systems such as chat applications (Whatsapp, FB messenger), social media (Instagram and Twitter timelines), streaming/content delivery (Youtube, Netflix), search/index-related applications (text-based search such as Twitter search function, and location-based such as Uber Eats search), transactions (bank systems). More importantly, you should understand the emphasis of each system and know the design pattern around it. Chat applications and social media apps are read-heavy, so how do you design your DB/cache system to support those reads. How do you deliver content to social media timelines, what's your fan-out strategy for the content? How do you index searchable content to delivery the most relevant content to users (searching for a specific tweet, or searching for nearby restaurants of a specific cuisine)? How do you guarantee that you don't double spend money in your bank account, and what are the trade-offs for that guarantee? When you're designing different components ALWAYS mention the alternatives, and why you decided to go with the design that you did. Example discussion topics; Why did you choose relational vs non-relational DB? Why Postgres vs MySQL? What type of load-balancer would you need - why layer 4 vs layer 7, why a hardware vs software LB? Why would you choose a cache-aside strategy vs a write-through strategy? What benefits does a message queue/pipeline give you, and what are the cons? What are the pros and cons of a CDN, and how can you minimize the cost of using one? What's your replication and/or sharding strategy? How will you index the data (there are different approaches for geospatial vs text data)? 4. Mock interviews - I did about 10 interviews (5 coding, 5 system design) on interviewing.io. It was expensive, but it was well worth the money. If you plan on doing mock system designs I recommend doing a generic one instead of a company specific one (Google/FB charge a $50+ premium), but for mock coding interviews it helps to do company specific ones, especially G/FB as the interviewers could give you tips on the actual coding interview structure. I had five onsite interviews over the span of seven days; I started in the middle of the week, and had the weekend to recoup a bit before wrapping up my final interviews. I felt I did really well on every single onsite, but I managed to not do as well as I'd like on one interview per onsite. Offers, all of the offers are for E4/L4 equivalent in Seattle. I plan on staying with my next company for at least 3 years (ie. I want to get promoted to senior and further). * TC numbers assume no stock growth 5. Practice talking to yourself like you would in an interview. Talk through your LC questions and your thought process. Ask questions out loud when gather system design requirements, talk through the pros and cons of design choices. During the interviews, I'm consistently talking about what I'm doing. Thinking out loud is the best thing you can do, since your interviewer can follow your train of thought and possibly guide you in the right direction if you're heading the wrong way. There are a few times that the interview said "You don't need to code that part cause I already know you can do it/I understand your logic" which saves you valuable minutes during interviews. ------------------------------------------------ 1. Facebook - my FB recruiter was amazing, and was very transparent and forthcoming with updates/information. From what she said, and what I've seen online, this is the max E4 offer in Seattle. E4: 169k base, 70k sign on, 365k RSUs, 10% annual bonus. Y1: ~350k, Y2: ~300k, Y3: ~328K, Y4: ~354K, Total Y1-4: ~1331K * Assuming 3% annual base increase, 80k/year refreshers, 10% bonus + no cap on base salary + annual refreshers + better career growth potential - team tbd during bootcamp ------------------------------------------------ 2. Amazon - initial verbal offer was for 315k TC. My recruiter was also very transparent, and knew I would be shopping around other offers, so he gave me a verbal offer two weeks before the written. I was told that the max offer for L5s is ~270k, but I was able to get an exception. I got matched with an amazing team. L5: 160k base, first year bonus - 160k + 50k additional bonus/second year - 110k, 95 RSUs (~320/330k). Y1: ~380k, Y2: ~330k, Y3/Y4: ~292k, Total Y1-4: ~1287K * Assuming 0% base increase(160k cap), no refreshers, no bonus (I assume I would be near or at the TC target for L5) + high sign-on bonuses + imo higher stock growth potential than FB or G + remote team, I really like the team I'm matched with - base salary capped at 160k - no annual refreshers, at least for L5 ------------------------------------------------ 3. Google - not sure how willing they are to negotiate, but this offer was after I already gave them my FB and Amazon offers. L4: 165k base, 50k sign on, 295k RSUs, 15% annual bonus. First year TC ~320-330k Y1: ~340K, Y2: ~316K, Y3: ~308K, Y4: ~303K, Total Y1-4: ~1267K * Assuming 3% annual base increase, 80k/year refreshers, 15% bonus + name recognition + WLB - slower career progression vs FB/Amazon ------------------------------------------------ 4. (Edit: company is Airbnb) I don't have concrete numbers yet, and I'll share the company/offer when I get it. But the company is FAANG-equivalent and should be around low-300s ------------------------------------------------ 5. Start up - low-200s base + options Is Google willing to negotiate further? Which offer would you take? Current TC: SDE2, low 200s, 6YOE EDIT: I took the FB offer :) #facebook #google #amazon #airbnb

Favorite - LeetCode

LeetCode

Free, anonymous technical interview practice with engineers from Google, Facebook, and more

interviewing.io