Another data point on industry hire in the bay ..great read :)
Found this post on Reddit and seems really helpful . Just posting it here .
Hi everyone, I just went through a round of interviews and wanted to share a data point. I wanted to share some interview tips that you may not have seen before. I'll also answer questions in AMA style.
I’m a software engineer with 4-5 years of experience in the bay area. Bachelor's degree in engineering at Waterloo. I don’t consider myself special talent, but I think I’m pretty good at interviewing. I've worked at a couple startups before joining G back in 2017. No specific expertise to brag about, but I have a good history of doing cross-stack work.
I interviewed at Airbnb, Facebook, Lyft, Uber, and 3 other companies. I received offers from Facebook, Lyft, Uber, and 2 other companies. First year total compensation ranged from 380k~500k from both public and private companies, 2nd year comp was around 400k for most of them. The offer numbers correlated with my interview performance, and from my research, it seems like some companies offer standardized offers to every candidate. Surprisingly the private companies did not beat out the public companies in equity package. Breakdown was around 180~210 base, 500~700 equity, and 0~100 sign-on.
I set a measurable goal for prep. 200 Leetcode questions, 10 system design problems, deep-dives of my past projects, and recollected my past experiences for behavioral questions.
Did mock interviews on interviewing.io throughout the process.
Got referrals on repher.me for the more obscure companies.
I had a buddy the entire process who was also looking to switch. He went from 85k to 300k TC (crazy). We did mock interviews everyday.
I did my phone screens during lunch hours, and scheduled onsites over span of 2 weeks, using all my vacation days :'(
Schedule the companies that you don't want in the beginning. I bombed my first interview lol.
It's common knowledge that you should prep for Leetcode-style questions, and system design if you're interviewing for senior positions. That's what I did 2 years ago to get into G, but the interview formats were slightly different this time around:
Phone screens were more difficult. I'm not sure if it's because I was being considered for senior positions. In one phone screen I had to explain what a BST was, implement algo to check if tree is BST, explain LRU cache, implement it, then design Twitter timeline. Every step of the way I had to give the tradeoffs and time/space complexity, as well as analysis of the design and writing/analyzing some SQL queries. 2 years ago I got mostly Easy/Medium Leetcode questions.
Practical coding was heavily emphasized. Almost every company I interviewed at had a practical coding round, where I was given a task (building a feature/scripting/debugging). You can bring your own laptop and I recommend that you do. You can also search the internet while coding. I think they look for fluency in programming, as well as how you break down problems. I say this because I got an offer despite not completing a task. I think this is a trend that will continue until proven to be ineffective.
is more important than design. Every company I interviewed did a deep-dive of my past projects and experience. Recruiters told me that this interview is more important for determining level than the design interview. I can see why. Most design interviews aren't conducted properly. Questions are often too large in scope and too much time is wasted in narrowing it down, and you only have 30~35 minutes when you account for the intro/closing. High-level ideas can be BS'd, and most of the interesting design decisions are lower-level. The level of depth is dependent on the interviewer's experience level, making it highly variable.
I've done around 300 Leetcode problems lifetime. This time around I did 200 but a lot of it was questions I've done before. Leetcode tips are all over the Internet, I'll leave some tips I haven't seen online.
Do these questions https://www.teamblind.com/article/New-Year-Gift---Curated-List-of-Top-100-LeetCode-Questions-to-Save-Your-Time-OaM1orEU
Find the brute force solution immediately, and tell the interviewer so that they know you're not an idiot. Too many candidates trip themselves up trying to find the silver bullet. Optimize the brute force solution if you can, and that will lead to a very good answer most of the time.
Example: trapping rain water on leetcode. The brute force solution 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. Then you optimize by caching the largest values to the left and right instead of scanning. Now it's linear. You know that it can’t be faster than linear because you need to look at each index.
Even when you’re peeking at Leetcode solutions, understand the brute force solution first and try to work your way up to the optimal solution. Jumping straight into the optimal solution without explaining the brute force solution will raise red flags. Readability is just as important as finding the very optimal solution. Solutions on Leetcode Discuss score low on readability.
Put trivial computations into helper methods that you tell the interviewer you will implement later. Generally they won’t ask you to implement these helper methods. For example, finding the min/max in an array, it’s so trivial that you don’t need to write out the whole method. It also shows that you are comfortable with translating ideas into code.
I used Grokking the system design interview on educative.io and system design primer on github. I recommend it, but these are surface level material and if you regurgitate the content you will fail. I recommend it as a starting point.
They recommend this structure: requirements, load estimation, API, data schema, high-level architecture, detailed component design, and scale. This is a good structure in my opinion.
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 personally believe the most important part of the design interview is the API.
Generally the interviewer will give you a problem definition and they’ll tell you the feature scope and maybe the usage characteristics (daily active users, for example). You should clarify until you understand the problem, don’t clarify for clarification sake.
I personally believe API is the most important part of a design interview, and no other content online will tell you this. Think about it, when you’re designing something at work, that’s the one thing everyone cares about. 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 that the same element will be dequeued on subsequent call or not? This changes the entire system. Let’s say you’re designing a sendMessage API for a chat app, who generates the message ID? Server or client (it should always be client btw, and think about why, it changes everything).
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.
"If you’ve never failed, you’re either inexperienced, a liar, or unaware" - somebody
Don’t be afraid to show your flaws. In fact this is where most candidates fail. Interviewers can tell if you’re BS-ing them. Be genuine.
If you’ve never failed/had a conflict/lost an argument, you’re either inexperienced, a liar, or unaware. All are bad signs. I was asked to provide a concrete example of a time I had a disagreement, and I told the interviewer about a time I disagreed with something and lost (they liked it).
This guy sums it up perfectly: https://www.youtube.com/watch?v=PJKYqLP6MRE
Go through your past projects and try to gain a deep understanding of the entire project, beyond the scope that you were involved in. Identify the key decisions you made, the high-level architecture, because you’ll need to be able to explain it to someone as if they are a newcomer to the team.
I believe there are 2 fundamentals of negotiation: knowing your market value, and having leverage.
Know your market value. Use levels.fyi, Blind, your network to find out how much market value you have. It's strongly correlated with your level of experience and the company you're interviewing for. Do not take low-balls. Do not ask for unreasonable amounts. I've seen people get offers rescinded for over-negotiating.
Have leverage. Competing offers, good job situation, 1 million dollars in the bank, those are all leverage. If you have no leverage, then you need to fake it. I don't recommend faking leverage, because if you were able to get one offer you can easily get another one.
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. 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.
I found that through preparing for interviews that I did become a better engineer. The process of preparing for interviews challenges your mental fortitude and time/stress management. Prepping for design interviews is not as simple as reading Grokking/design primer, you need to gain a fundamental understanding of every decision that’s being made in the design, and this requires a lot of digging through the internet for content. A lot of hate for Leetcode style interviews on this sub. Doing Leetcode doesn’t make you a better engineer, but it makes you a better coder. A big part of our job is translating ideas/thought into code, in a way that others can read it and understand it. Leetcode problems are challenging because they test your ability to generate the idea, and to translate ideas into code.