Show HN: Onsites.fyi - Curated Big Tech Interview Experiences (onsites.fyi)
Hi HN!
While Glassdoor and other employment discussion boards offer valuable interview experience data, navigating it to prepare for interviews can be difficult.
Onsites.fyi curates interview experiences and insights from Big Tech hiring across various positions and levels.
Our collection currently includes interview experiences from top-tier companies like Apple, Google, Meta, Microsoft, and Amazon.
Reviewing real interview experiences (rounds, questions, format) of others could be an invaluable preparation tool for interviews.
Try it out and please share any feedback!
135 comments
[ 3.2 ms ] story [ 199 ms ] threadAt Google, we generally do not ask system design interviews of new grads / entry-level candidates. It's pretty rare for mid-level candidates (L4), and expected for senior and up (L5+).
Also, there are situations where candidates may have an extra interview added to their slate. One common reason for this: the hiring committee doesn't have enough signal because the interviewers don't coordinate appropriately, and end up asking heavily overlapping questions (e.g. 3 questions that basically reduce to "use DFS").
I'm curious - how much up-front coordination is mandated? Plenty of the interview loops I've done agree in advance to the exact set of questions we'll ask during an onsite specifically to avoid problems like this (which of course causes other problems...)
None is mandated.
It's incredibly rare (maybe 5%) to also be requested to put your question into a spreadsheet (that all the interviewers can see) to avoid any overlap pre-interview. Post-interview you have to submit what question you asked into the official (not a spreadsheet) tool.
These days, the actual process is confusing at best (and wildly inconsistent across interviewers, as it's dependent on what the recruiter sets up), so it shouldn't be surprising that it's rarely used if ever.
To be clear: I don't actually know what the rate is of candidates being asked to come back for an extra interview. My understanding is that it's always been a last-resort option, but it'd be one of the more common reasons if the candidate actually made it to the slate of "in-person" interviews, and then needed to come back for another one.
For anybody that needs reminding:
Companies' abrasive or uncoordinated interview processes likely has nothing to do with your experience in your team on the company.
Your manager's uncollaborative behavior may have nothing to do with your day to day, or mental health on the job.
Ignoring or leaving any of these companies because you considered any one behavior a red flag is a privileged take for people that have trust funds, masquarading their version of life as normal.
Take a contract position or something else less hard to get, get more financially secure and then go for the faang role.
As to "not enough data"... how exactly? If there is a list of things to check off that is to be distributed amongst the interviewing team, there should never be an issue. If people are winging it and just happen to ask repetitive questions then everyone asked what they needed to know and signal should be there.
It sounds like Google's process is fundamentally buggy. They should fix that.
Unfortunately, it's really hard to quantify exactly what's broken about the interview process in a way that justifies (to the appropriate individuals!) upending the status quo. You and I can both complain about how this is terrible for candidate experience and for hiring the best talent, but that's not going to change anything.
I left Google for a startup and got basically half the total compensation. 6 years after leaving, I am making about what I did at Google 5 years ago and 2 "levels" lower. If I stayed at Google, I'd be making about $800,000 a year.
You should really really ignore the distasteful feeling about being grilled by a bunch of strangers and just do it. (I actually really enjoyed my Google interviews. Problems I hadn't seen before that I came up with interesting solutions to.)
I'm kind of surprised that its impossible to do it locally at all. I know one time I was interviewing at FaceBook and I asked to do the phone screen in-person and they let me (I lived near the office).
I guess it depends on the company, as well. I have no idea what engineers at faang do. I can tell you what I have been doing the last decade:
- decide what kind of db we should use for our next product. Usually a relational one is good enough, although sometimes document or graph ones are needed
- DDD. Or at least I try. Our engineers are able to understand the business and relate terms of the problem domain with ones in the solution domain
- identify race conditions. Phantom reads? Those suck, but I keep them out of my codebases
- maintenance of public APIs. From authN, to authZ, and keeping backwards compatibility as much as possible
- observability, monitoring, slas, slos, slis
- debugging distributed systems and distributed monoliths
- splitting monoliths into microservices because “why not”, and later regret and start with monoliths again for fresh products
- decoupling services by using tools like kafka and debezium
- mentoring and couching
- helping PMs, POs and business people to build products on time
- a large etc
You know what I have never done? Invert a binary tree. I have read the Cormen book; it’s just that if the company I’m going to work on is all about the things I have mentioned above, then asking leetcode questions is a red flag.
Anecdotally, I actually find it a good filtering signal for top talent. That is, all the best engineers I've worked with have always been able to crush leetcode interview questions, even if they find the questions annoying.
I think it is probably only a good filter if truly trying to hire the top 1% of engineers. Almost nobody is though, as is evident from their undifferentiated pay scale.
It doesn't have much to do with programming, and has almost zero to do with software engineering.
But Leetcode interviews in practice aren't about knowing those.
If they were, people would not prep for months specifically for Leetcode, and FAANG recruiters wouldn't advise spending months rehearsing for those (for everyone from undergrads with CS101 fresh in mind, to senior engineers who routinely use those in real-world situations).
Prep with titles like "Cracking the Coding Interview" aren't about understanding or practicing software engineering. They're about passing fratbro pledge hazing rituals.
I'm going to guess about 85% of leetcode questions that are asked by top copmanies fall into the CS101 algorithms and data structures bucket. Seriously you can go to leetcode right now and look at Meta's most common interview questions and almost all of them are basic data structure questions.
I'm not saying passing the interviews are easy. You definitely have to practice coding fast (at least, I did!).
Sure the questions may have a twist, but most of the time there's no esoteric weird algorithms.
> For the technical interview, visit leetcode.com and do practice questions at a medium/hard difficulty in Algorithm, Data Structures, and Object-Oriented categories to help prepare.
I guess for some of us there is no escaping leetcode.
You can see the effect in realtime. Google products are worse than they were 10 years ago when they have good devs that cared. They left and now it's just gears in a machine someone else made.
Ignore all study materials. Go to leetcode.com and literally memorize the most common questions for the company you are interviewing at. This is what your competition is doing. DO NOT LEARN THE MATERIAL. Just memorize it
Do the same thing for system design. Memorize the answers word for word. DO NOT LEARN THE MATERIAL.
The highest paid tech jobs go to candidates that regurgitate perfect answers to interview questions. Anyone claiming otherwise is lying or doesnt understand whats going on.
Thank you for pointing that out.
[Citation needed]
Memorization isn't the one variable we should be solving for. God forbid people take notes in meetings as opposed to remembering every word that was said
Don't memorize it, learn it, become good at it.
No matter how much you memorize, there's going to be something you don't. But I think you know that.
You mean that they remember common patterns to solve problems? Or they memorize questions verbatim?
A person with a deep passion for algorithms might be tempted to try to solve it themselves before checking the answer - which can be a time consuming business. Time your competitors have used to memorised the answers to 25 more questions.
ldjkfkdsjnv has exaggerated a bit, to be provocative - but I've certainly had interviewers ask me questions that stumped the greatest minds in computer science for 25+ years; I don't know what they were expecting if not memorisation.
But that wasn't FAANG that's pretty exceptional.... Most stuff is DFS, memorization, etc... Things that are good principles and don't have "this one weird trick"
Furthermore, if you have a memorized solution, you can spit that out in 5 minutes, and then spend the next 30 minutes trying to figure out the slight change that you need to do to make it work for the minor change that was made.
Speed matters. And having stuff memorized makes everything else easier.
Then I guess you won't be very good at interviewing.
> Then what are you supposed to do?
Get better or give up. Your choice.
You'd have to request reasonable accommodations if you have a provable and medically documented disorder.
But also it would depend. A company is allowed to not hire someone if the person is not able to do the work. A company is only required to give reasonable accommodations.
When I interviewed at a google and netflix, not one of the coding questions were on any site (leetcode or hackerrank). After the interviews I wanted to look at the solutions afterwords so I searched for them, couldn't find anything.
It was only microsoft that would ask the common canned questions.
They are a pile of trash who are more than happy to place travelers in dangerous scenarios, while moving refund goalposts down the infinitely+long field.
Any mention of the company is advertising, whether you want to believe it or not.
Once you get the job, sure learn it. Unless your job doesn't require it or you're not that interested.
But, online we need to be pedantic. That's rule 1.
• What is an SSL certificate? Follow up question: What is inside them?
• How would you go about designing a modern NTP to sync a fleet of local-first systems?
• Do you see a security problem with this code? If yes, what is it and how would you fix it?
• Same question as above but with twelve different pieces of code, each one more complicated than the previous one.
• What would you consider Personal Identifying Information (PII) in a food delivery app?
• Explain XSS, SQL, XSRF…
• Hashing vs. Encryption
• How to protect customers from phishing attacks?
• Say you discover a data leak, for example, a backup in a public S3 bucket. Communicate leak or not? If yes, who will you communicate with? How will you communicate?
• Improve event processing logic and performance of the following Java application. Our company revolves around processing events, quickly. Implement the alarm system to monitor incoming events for any delays in processing events by other event processors. (If you find it surprising that Apple uses Java, I share that sentiment. Interestingly, I opted for Go instead of Java to solve the problem during the interview, and the interviewers were pleased to explore a new programming language. I believe this aspect earned me some additional points.)
• Design a table booking system for a restaurant (database, API endpoints, etc.)
• A continuous integration (CI) build step fails (in tests), what do you do?
• What is your ideal Developer→Customer feedback loop? Realistically, what would a bad one look like?
• How would you design macOS Photos.app? (The best part of the interview was a discussion about what to do with content that is out of view and the performance implications of different solutions.)
• Third-party company wants Apple’s data to show ads. What do you do? (The obvious answer is you don’t give the raw data to them, but if you have to, how do you anonymize it?)
• so on and so forth.
There was this interviewer who appeared to be commited to ask me one hundred questions in the span of an hour, and while I didn’t count, I think we got pretty close to a hundred. The questions started at an easy level, for example, what is HTML, and increased in complexity every five minutes or so. Fortunately, I realize what type of interview this was and proceeded to give very one-sentence answers, sometimes just 2-3 words before jumping to the next question. One of the funniest, craziest, most exhausting, but somehow rewarding interviews I have ever had in my whole career. At times I thought the interviewer was some sort of artificial intelligence and the webcam was fake. Later, I met the interviewer in person and we became friends.
Now, having become an insider, I can attest that it’s acceptable to some extent to memorize responses for coding exercises and rehearse answers for behavioral questions. As you rightly point out, many other candidates engage in these practices as well. However, if a candidate’s proficiency is limited to merely regurgitating code without a genuine understanding and, consequently, an ability to articulate the underlying concepts in both the programming and behavioral interviews, that candidate is likely to face failure.
Before landing the job at Apple, I was also in the interview process for a position at Microsoft. The nature of the work appeared to be significantly more fulfilling than what I currently have. The level of technical expertise required during the interviews was remarkable, with the two medium and hard level LeetCode-style questions being the relatively easier segment. Memorizing answers was...
You aren't just supposed to solve a problem (and can't think back to your college years, pull out your copy of CLRS, or whatever). You are supposed to rapidly pattern-match to a specific problem type, and implement. You only have 20-30 minutes (because the rest of the hour gets eaten up by small talk) and this includes testing. Anyone who thinks they can do this with just their knowledge of algorithms without any grinding is in for a shock.
I have no idea if this really works though, it seems insanely tedious and also there aren’t that many companies to roll the dice at.
I guess that's how memorization works.
There are lots of ways to cheat in those contexts. The most obvious way that is close to undetectable would be having a second person looking up the answers, and telling them to the candidate, while the interview is happening.
Also, a good system design interview isn’t about designing a “perfect” system (hint: there isn’t one), it’s about defending a reasonably considered design.
Google’s system design interview very closely approximates my day-to-day experience designing solutions with my teammates.
Case in point, when asked how I’d build Slack, I spent most of the time on data persistence because slack stores all data forever even on the free plan. I got rejected because, “we don’t care how they store data.”
Ok, but that’s still a key part of the system design…
We also covered other areas like messaging, authentication, authorization, read / write paths, etc… so it was very strange to get the response from the senior manager I got.
I can assure you that it absolutely does work at Google.
I've done multiple interviews at Google, and have received a job offer from them, and every question I got asked was one that I had heard of before. (This was for an L4 position, so mid level. Also, it doesn't matter what happens at L6 or higher, as that is comparative rare for almost anyone who is doing interview practice).
Maybe your question is super secret, but the vast majority of other people's questions are not.
I'm not sure, however, what if anything testing by algorithms proves. Sure, you should know how and when to use them like I know how and when to use different blades of a saw. Nobody has ever asked me to tell them how the saw gets made though. The things that matter to me as a Senior+ engineer these days are:
- Do you know how and when to use various algorithms
- Are you going to conform to a given code bases styling and standards
- Do you know how to properly test a given piece of functionality
- Do you know how to interrogate the debugger to find answers to your own questions
- Do you know commonly accepted standards and where to find them
- Are you going to over engineer and completely pollute the code base with unmaintainable code or infrastructure
Algorithms and systems design test for only one of the above. If we ever get a tech union algorithm interviews are on a top five of things I'd like them to do away with.
Success in interviews often stems from a combination of preparation methods and understanding deeply what you're being interviewed for.
With Onsites.fyi, our goal is to provide those insights and data points so you can prioritize those high-impact topics and focus on deeply learning the material rather than an aimless review of everything.
This is the key to standing out in today's competitive job market.
Seems like its practically required at this point
I am not going to reject a qualified student out of hand for not having done an internship.
That is, when hiring a new grad for an L3 spot or whatever, assuming they met the bar for the interview and in fact did an interview, first we look at interview performance, then internships (with an internship at our company with a successful outcome being the best), then school, then recommendations from current employees. Typically someone needs to have a good interview and one or more of the other things, more if less good at interview, potentially only one if outstanding at interview.
taking the time to do this ahead of your job search will help you surface those memories when you need to talk about them, much like the leetcode grinding people talk about.
Feel free to suggest companies here: https://www.onsites.fyi/submit#suggestForm
Our industry is in a weird phase. I undersand that it's difficult to weed out thousands of candidates without these tests and quite frankly these tests are independent of the domain you work in which can be both good and bad.