[AMA] Interview tips after a recent round of offers (380~500k)
TLDR: Offers ranging 380k~500k from Facebook, Uber, and 2 other companies. Non-exceptional IC with 5 years of experience. Interview tips are nuanced and its your loss if you don’t read.
### About me ###
Software engineer with 5 yoe in the bay. B.Eng (not comp sci) in a well-known school. Mostly self-taught. Prior to G, worked at a couple startups. No specific expertise to brag about but I work harder than most, pick things up fast, and have good communication skills.
### Offers ###
Interviewed at Facebook, Lyft, Uber, and 3 other companies. Got senior-level (L5/E5) offers from Facebook, Uber, and 2 other companies. First year TC ranged from 380k~500k from both public and private companies, recurring TC ranged from 380k~450k. Breakdown was around 180~210 base, 500~800 equity, and 0~100 sign-on. No difference between private and public companies, surprisingly.
### Process/Scheduling ###
- Plan was to do 200 LC, 10 design/architecture, prepare answers for behavioral questions, and go through the designs of my old projects
- In reality I probably did closer to 150 LC (30/50/20 easy/med/hard) and 15 design/architecture. Most of my focus was on design/architecture and behavioral.
- Did mock interviews on interviewing.io, and a buddy who was also interviewing
- Got referrals on repher.me
- Scheduled phone screens during lunch hours, and scheduled onsites over span of 2 weeks with vacation days
- Whole process was 3 months, from when I started prepping to accepting the offer.
- Be goal-oriented (as opposed to schedule-oriented). Ex. "do 5 leetcode questions" is better than "do 2 hours of leetcode". Have measurable goals for prep.
### Interviews ###
- Told the recruiter I'm looking for senior positions. Was transparent about my level at G (L4), they did not care.
- Format is mostly the same, a mix of LC, practical coding problems, design/architecture, experience deep-dive, and behavioral.
- Practical coding problems is a recent trend. You can bring your own laptop, I recommend that you do. You can also search online during that round. I think they look for programming fluency, and signals for self-sufficiency.
- At senior level, design, experience deep-dive, behavioral are emphasized. Lyft has 2 design rounds. Most companies combine the deep-dive and behavioral rounds.
### Leetcode ###
- I've done 300 LC problems lifetime, so I only needed a refresher. The mental breakthrough happened for me when I hit 200 LC problems.
- Good set of questions: https://www.teamblind.com/article/New-Year-Gift---Curated-List-of-Top-100-LeetCode-Questions-to-Save-Your-Time-OaM1orEU
- Understand the problem through examples. Define the input/output. Try to find edge cases. Don't do this as a checkbox you're trying to check, the goal is to fully understand the problem.
- Find brute force immediately, and explain it to the interviewer. Don't look for the silver bullet. Often you can optimize the brute force to get a very good answer. Most companies don't care about getting the perfect answer, just a very reasonable one.
- Example: trapping rain water on LC. Brute force is to find the amount of water trapped at each index, by scanning for the largest values to the left and right. This is n^2. You notice that you are doing some redundant work in scanning the largest values on the left and right, so you cache it.
- When doing LC, I describe the solution in code comments. This was good practice for communication. Then I write the code and then try to optimize it. I peek at answers on LC Discuss liberally, after 30 min of trying.
- Use helper methods for trivial computations, tell the interviewer you will implement it later. You won't have to. Example: finding the min/max in an array, it’s too trivial. Readability is important. LC Discuss answers have shit readability.
- When testing the soln, use examples you discussed earlier. Often it's good to write out variables involved in the algorithm in a table format, and writing down the values as they are updated. Much like a debugger, but on a whiteboard.
### Design ###
- I used grokking and system design primer to start. They are surface-level. I recommend it as a starting point. Design prep involves a lot of googling.
- I watched some system design videos on Youtube, they are also surface-level. In fact I think most of them don't know what they're talking about (not naming names, but pretty much all of them). I liked this guy though: https://www.youtube.com/watch?v=iJLL-KPqBpM.
- Grokking recommends this structure: requirements, load estimation, API, data schema, high-level architecture, detailed component design, and scale. +1 on this.
- The problem with these contents is they spend too much time on high-level/drawing boxes, but when they go deeper they are not going deep enough, and tend to focus on the wrong things. I think most of the design discussion should be centered around API's.
- When you’re designing something at work, you mainly discuss the API's. Implementation details are done within the team or on your own. The API is where cross functional collaboration and discussions happen. Grokking and primer don’t cover API in enough detail.
- Write down each API and discuss the policies. For example, when designing a queue, you have enqueue/dequeue API’s. Does dequeue guarantee removal? It changes the implementation. How much load is on that API? Does the API guarantee freshness or not? Fire-and-forget? Blocking?
- From API discussions, the data schema, high-level architecture, and services should be easy to draw out. Data schema will roughly reflect the API request/responses, services will be scoped to support a set of functionally related API’s.
### Behavioral/Deep-dive ###
- Be honest about your shortcomings and failures. If you’ve never failed, you’re either inexperienced, unaware, or a liar. Never throw past teammates under the bus.
- This guy sums it up better than I can: https://www.youtube.com/watch?v=PJKYqLP6MRE
- Go through your past projects and gain a deep understanding of the entire project, beyond the scope that you were involved in. You’ll need to be able to explain it to someone as if they are a newcomer to the team.
### Negotiation ###
I didn't negotiate my offers beyond telling the recruiters what the other companies were offering me. This only worked because I interviewed companies that pay top of market earlier in the process (cannot disclose). I also let the recruiters know how much I was expecting, and disclosed my current level/comp when asked (L4 at Google, so it would not have helped my case).
I dislike most of the online advice that tells you to play a game against the recruiter. Recruiters are human. Full transparency, and being genuine with the recruiter has worked well for me. Try to not make it all about money. If all your questions/comments are around comp, it signals to the team that you're just interested in money, which certainly doesn't help your case.
### repher.me ###
As a closing note, you may have noticed me promoting my site on Blind. It was a side-project I made before I started interviewing. Hope you don't mind another plug. It's completely non-profit, and I made it for fun.