Tech Industry
9h
1943
Job market is brutal for SWEs 🥲
India
Yesterday
405
Modi is at least honest on Media that it is not neutral but Godi media
Tech Industry
14h
402
H1B ruined everything. Both for Americans and for the Countries where people came from?
Personal Finance
19h
671
Here are three stats about how your money is increasingly useless after the most recent inflation report
Health & Wellness
20h
788
Misdiagnosed As a Child
Long post alert. This post is about my interview experience, some offer details, and most importantly some tips for interview prep for Senior and Staff level roles. I interviewed for Staff+ EM roles(M1). My time to give back to the blind community that helped me negotiate offers (thanks to the people who answered tons of questions on DMs for me!) I will be fudging some details for privacy reasons, but overall the details are not too far off. YOE: 8ish. Currently at an EM at a big tech (not META or FANG). ex FAANG(two of the FAANGs with a longer tenure at one of them) I targeted only startups and some non-faangs. Had enough experience with “brand names” and fangs in general. Wanted to try something more fun. The post has three parts. 1. Context about interviews and offers. This is not to brag, but to share some insights. Skip this part if not relevant. 2. Interview tips. This part is about what worked for me and what did not work for me. 3. System design interview tips. Part - 1: Interview journey and offers. I made up my mind to switch jobs due to the stock crash. I started prep in Jan of this year and gave interviews in early March. I had close to 4 interviews lined up and went to the onsite stage at all of them and I could not convert a single one of them! SNAP - Reject after onsite rounds. (In hindsight, soo glad this did not work out) Rippling - Reject after the initial phone screen (I Was asked an LC hard question for an Engineering leadership role. Didn’t really care about this, since the role was not a good fit for me) “Hot Fintech” company (Spend management/Credit Card) - Reject after onsite. This is the only rejection that really hurt because it was a role that would have been very good for my career trajectory. After all the rejects, I took a pause and stopped interview prepping. Clearly, I was doing something wrong. After some analysis, I figured out that I had to: 1. Get much better at System Design interviews to crack Staff+ level EM roles. 2. Get much better at giving polished answers for behavioral interviews. So after taking a break, I started the prep again for round 2 of interviewing. This round of interviews went well. Results: Offers: 1. Databricks - Offer - 750k to 800k (As I said I won’t be giving out exact numbers) 2. Plaid - Offer. (Good interview experience) 3. Series C startup (ML platform) - Offer. 4. Series C startup . (Best offer of the lot by a wide margin) 5. City storage systems - Offer. (Weird backvesting schedule. Did not get good vibes) Rejects/Dropped out: 1. “Another Hot fintech company” (Spend management/Credit Card) - Reject after phone screen. Fumbled a bit during one answer. 2. Instacart - Senior EM role - Role got closed after clearing the HM screen. I went with the M2 role from the Series C startup because it was a good fit for me in terms of product, comp, and career growth etc. I cannot reveal more information. #engineering Part - 2 Interview tips 1. When you start interviewing, expect your first few interviews to bomb. It is extremely important to first interview with companies you are NOT interested in. This was a mistake I made. I would say line up onsite rounds with at-least two companies you are not interested in. You will learn a ton. After each interview, immediately note down the questions you were asked. This will help with the prep for your target companies. 2. Spend money on taking mock interviews. Very very important for system design rounds and behavioral rounds. It was only after taking mock interviews for various EM interview rounds, that I realized that my answers did not follow a clear STAR pattern and that my answers were too long. The feedback I got from my mock interviewers was priceless and made all the difference for round 2 of the interviews. I used igotanoffer.com to book mock interviews for EM behavioral interviews. Even Staff SWE interviews have a heavy emphasis on behavioral rounds, so spend the money! For EMs, each mock interview should focus on one topic - Hiring, People management or cross-functional collaboration, etc. 3. Presentation / Project retrospective round: An increasingly common round for EM roles at many companies - Airbnb, Databricks, etc. Some tips to nail this round - 1) Focus on a large scope project. Something that is at the Staff level. The project should be at the system level, not a feature level. 2) Have diagrams that you can walk through. 3) Be clear about the role you played (TL/EM etc). 4) Have slides for the following areas - learnings, challenges - technical, organizational, and people management. 5) Start off by explaining the problem space clearly. Describe why it was important to build this system and how it tied to the business priorities. 6) Talk about the tradeoffs you made - technical and also management. One of the key things being evaluated is your ability to make tradeoffs, so think about this beforehand and have slides ready. You cannot make this up on the fly! 4. Tips for behavioral interviews: Keep your answers short. Practice in front of a mirror or just take a lot of mock interviews. 3 to 5 minutes max per answer. Stop in between your answer and ask your interviewer if they have any questions or if they understand what you have said so far. Don’t keep talking and talking without checking in. This was an area where I had to practice a lot and fortunately got better. Again take mock interviews for detailed feedback. If you all have any questions, post in the comments below. I will try to answer if there aren’t too many questions. Part 3 System design interview tips. **Material** I used Alex Wu’s System Design Interview book Volume 1 and Volume 2. It is currently the best resource in the market IMO. But the book makes a tradeoff between the number of questions (a lot of questions in volume 1 and 2 combined) and the depth of coverage for each question. Particularly in volume 1, the solutions don’t have enough depth. Overall, the book gave a good understanding of how to approach system design interviews, but it was not enough to feel confident about answering any system design question reasonably well. I did have to do a lot of self-directed ready to be able to perform well in interviews. **General framework:** 1. Ask a lot of clarifying Questions. Use the “Why, What, When, Who, Where, How,” framework as a prompt to come up with questions. Example: Design an API for a weather monitoring system. Questions: What does this system do exactly? Who uses this system (enterprise customers or SMBs or regular people)? What is the scale at which this system operates? How frequently should we gather weather information? Who is sending the weather data? 2. Define both functional and non-functional requirements. Prioritize them as P0, P1 etc. Not explicitly defining non-functional requirements is a negative. Non functional requirements are low latency, high throughput, HA, Fault tolerant, etc. When possible define SLAs. Example: For a key value store, low latency is a must. SLA can be latency for reads is under 10 ms. 3. Start off the data model and then decide the storage layer. This is an exhaustive topic, but you should be familiar with the Relation data model(which most people are), one Document data model (Mongo DB), and Cassandra (for fast writes and leaderless replication). Read chapter 3 on Designing data-intensive applications(pure gold) and then Cassandra, MongoDB data modeling documentation. 4. Define the API spec. Become familiar with REST, GraphQL, and RPC API architectures. When going with REST, mention why you are going with REST. Don’t just jump to designing REST APIs. Making nuanced tradeoffs is the thing that will help you land Staff SWE roles. Most of the times, you will end of using REST or GraphQL. I almost always used REST in my interviews. Define the endpoints from the perspective of the end user. Reference the P0 functional requirements you came up with to check that your APIs cover all the use cases if needed. Topics to learn about in REST architecture include rate limiting strategies, security considerations, pagination strategies (offset vs cursor) etc. 5. High-level system design. Take a look at your requirements again and identify the system flows. For a weather station API, you need an ingestion flow to get and store data and you need a consumption flow for users to query and consume the weather data. Don’t complicate the system at this stage. Keep things high level and secure buy-in from the interviewer. 6. System deep dive. Now, start diving deep into the “system flows” you identified above. Consider scale, failure modes, reliability, latency, etc. Do you need to introduce message queues? Become familiar with a simple point-to-point messaging system(Redis) and pub-sub messaging system (Kafka). Do you need caching? What is the caching strategy? Take charge of the interview! Don’t expect your interviewer to tell you what to do. Check-in regularly to see if the interviewer has any questions - “Does this make sense? Do you have any questions about the decisions I have made ?” 7. Capacity planning. For each service/micro-service you have identified, scale the number of API servers, cache servers, and DB servers based on the throughput expected and storage requirements. 8. Some rough numbers to help the calculations. For a single commodity server - 9. 1 TB GB of ram, 10 TB of disk, 50k WebSockets, 32 cores, 8 threads per core. Assume we allocate only 70% of capacity to hold some buffer for spikes. 10. One thread can serve one API request at a time. Assume API processing time: 100ms. The number of requests that one thread can serve per second: 10. the total number of threads in one server: 250 (32 cores * 8 threads per core). total number of requests per second that one server can handle: 2500. Discounted number assuming we operate at 50% CPU capacity to handle unexpected spikes: ~ 1000 Meta tips: 1. Do a lot of mock interviews. This will expose your weak areas. My weak area was storage systems. So I focussed on learning about NoSQL data models. In my experience being familiar with one document model, one write-optimized stores like Cassandra, key-value stores, and a relational store is sufficient. Never came across a problem that needed graph DBs. 2. I used an iPad with Pencil and the screen mirrored on my laptop. This worked out really well and was better than using any drawing tool with my mouse. Thanks for reading! If you have any questions about interview prep, post in the comments below. I will try my best to answer as many as I can. #software #swe #em #offer #interview #systemdesign #tips #staff #senior #tech
Congratulations!
That's awesome and Wholesome. Congratulations OP!
OP you're amazing! Thanks for giving back
I've seen plenty of series c startups flamed out. I would've picked Databricks
Going in with my eyes open. Thanks for the advice.
Valuable content on blind... it must be april fools!
Great tips.. Congratulations . I just joined Meta as an E5 and choose one of the Ads team . Can you give any tips ? :D
Depends on what you career goals are
Thanks OP. Can 100 percent confirm you're right about behavioral interviews. I got downleveled because of them. Do you have tips on how effectively strip a STAR example of details? I sometimes write them up, and they are still too long, but I don't quite see what parts I can drop and not loose context. Maybe in these cases I should look for simpler examples? Do you have an example of an initial answer to a STAR question, i.e. before the interviewer asks additional questions? E.g., imagine your question is "What is the most complex bug your solved?"
First set the context and then jump to the situation. Focus on one situation instead of talking about multiple situations at once. Then describe the tasks. I typically say “given this situation, here’s what I had to do -“. The n summarize the top actions you took. You can mention 3 actions you took. 3 is a magic number for these type of answers and is used frequently for MCK consultants in slide decks. It makes it easy to remember when you answer in 3 points. Then finally summarize the result along with a benchmark so that the interviewer can actually understand the impact of what you did. Eg: unit testing coverage goal was 50% but we actually ended up at 65%
Congrats on your offers. And extra thanks for giving back.
Kudos OP. Finally a sensible non trash post! Bookmarked it.