Show HN: Onsites.fyi - Curated Big Tech Interview Experiences | Hacker News Reader

Show HN: Onsites.fyi - Curated Big Tech Interview Experiences

onsites.fyi

187 pointsnisowa117 comments

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!

Open articleView on HN

Do note that these interview slates will vary depending on level of candidate experience.

At 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").

> 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...)

Not very much. There's an interview lead that is supposed to make sure no question overlaps happen. They will sometimes comment on the chosen question (e.g. asking an unrelated question to someone interviewing for a research position). In general I think this is pretty rare as it requires folks to care about their interview before it starts. :)

> I'm curious - how much up-front coordination is mandated?

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.

When interviews were actually in person, there would be a pass-along sheet where you would write down your question. Of course, that wasn't perfect (the comment I had about too many people asking BFS was from a pre-pandemic email thread).

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.

Nice, make your problem the interviewee's problem and waste more of everyone's time.

The arrogance of these companies makes me never want to work there. I did go through the Apple process once though and it was pretty much as described.

People that need jobs really shouldn't view this kind of approach as advice or relevant to them. I feel like that's often left out of these kind of takes.

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.

If you really need a job why would go go through these processes? They’re long and complicated and it’s basically a crapshoot anyway because they do it so badly. Even if you get it you’ll have no negotiating power so you’ll get screwed on comp.

Take a contract position or something else less hard to get, get more financially secure and then go for the faang role.

ideally things go perfectly all the time, but people sometimes make mistakes. what would you rather they do? pass on the candidate because they didn’t get enough data to support a hire? or give them more chances to demonstrate their capabilities?

I think the candidate should pass on the company. It's always good to provide a cost for their mistake. There is no job worth getting jerked around before they even start paying you.

They should do the right thing and if the candidate hit the bar on what was asked, however repetitive, they should get the offer.

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.

The problem is that a bad hire is really expensive to correct, and so traditionally Google's hiring process has erred on the side of being overly conservative. We've rejected some excellent engineers (or driven them away with the process overhead / delays) to instead pick up people who grinded leetcode for weeks on end or got lucky with an easy interview slate.

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.

Now you know, and you don't have to ever apply/interview there!

Google gets away with this because they pay so well. An hour of extra interviewing gets you an extra $400,000 a year. Show up to a 1 hour zoom meeting instead of having a long lunch, then put the money in your savings account (or in the stock market when savings accounts stop being so good) and retire at 35.

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.)

But you left?

My project got canceled, so I went somewhere else doing a similar project. Everyone phrases it like they avoid FAANG because of the interviews, and not what they'll be working on. If you don't like your project, fine, leave the money on the table. If you do like the project but are mad that they ask algorithms questions, I don't think that's a good enough reason to give up millions of dollars over the period of your career.

The Google interview has degraded in the last few years. When I interviewed 6 years ago as a fresh grad they flew me out to Seattle. Now I don’t believe you can go in person even if you want to on your own dime - at least not for the level I interviewed at when I got in a couple years ago (this was after Google’s supposed return-to-office).

Does a couple years ago = early 2021 during the pandemic?

Kinda of; that's why it changed but it never changed back.

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 prefer online. In person means using a whiteboard while online means using a laptop+ text editor.

Horrible. I’ve been doing software engineering for 12+ years and I’ve never had to pass leetcode questions. I have worked for 5 companies in total, and I think I have been in around 15-20 tech interviews in total as well. The interviews I passed didn’t ask me leetcode questions (I had to do take home assignments and system design). In my last interview they finally stop asking coding questions (staff position). No Faang companies, but tier 2 I’d say. Western Europe.

To expand.

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.

I'm glad that you have had this experience! However, passing leetcode questions will typically open up new job opportunities and increase total compensation.

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.

Leetcode interviews are for people who studied and practiced for Leetcode interviews specifically.

It doesn't have much to do with programming, and has almost zero to do with software engineering.

Lists, sets, graph traversals, parsing, knowing when to use hashmaps, using recursion, knowing when to use a priority queue don’t have much to do with programming or software engineering?

CS101 algorithms and data structures of course are relevant to programming.

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.

>But Leetcode interviews in practice aren't about knowing those.

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.

I'm interviewing for Staff level positions and this came in the email of one of the recruiters

> 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're probably making 3x less

and yet their quality of life is likely 5X higher

That is unknown, as people at FAANG in the US have a comparable quality of life as those in Western Europe, because the things people tout as European advantages like free healthcare and long paid vacations, FAANG workers in the US essentially already have. They are getting paid much more for a similar standard of living, which in turn decreases their retirement age, if they so choose.

Ultra mega cope. Many FAANG engineers are testing and vesting, doing almost no work while taking that money in

They are in tier 2 in europe, I'd be surprised if they are at 120k euro+ TC, regardless of level.

Leetcode didn't exist before "anti discrimination" laws. It was created specifically to give corps a legal barrier to defend against suit because the Fed wrote the law in such a way that you can easily and successfully sue any company for discrimination during the hiring process. So they filter out as hard as they can in a "neutral" way.

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.

To reiterate:

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.

This is true. And it's a bit frustrating because I have to take care of two young children when I'm off work, not grind leetcode. But maybe that's the point.

Its not as bad once you accept its memorization, and treat it like that.

Sadly not everyone is equally adept at memorization, so if you're solving for that as a hiring manager, you will only (mostly) appeal to this subset of people

Then they're probably not a good candidate for a high-paying, high-expectations job.

Thank you for pointing that out.

> Then they're probably not a good candidate for a high-paying, high-expectations job.

[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

By your logic every software engineer job across the entire org at a company like Google/Amazon/Meta have the same requirements, exact same problems, etc.

This is absolutely the point. All these interviews are checking is "does this person spend all of their free time on a task we assign to them, no matter how boring". Or, "do they go above and beyond".

For many, it's much easier to understand than it is to memorize.

Is it too much to hope that those companies will all go out of business, and every person who was a part of creating this ridiculous theatre will be bankrupted?

Someone is going to take you seriously.

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.

People need to know the truth that these "genius" engineers at Meta/FAANG are mostly getting in by memorizing. They try interviewing at five top companies. One of those interviews they will absolutely crush, and then will get an offer at 400k+.

When you say "memorize" what do you mean?

You mean that they remember common patterns to solve problems? Or they memorize questions verbatim?

People are going on leetcode.com, they find the company they are interviewing for, they remove all questions more than a year or two old, then they sort by frequency. They start memorizing the most frequent questions first. Then they pass the interview. There are other forums with question banks, but I wont get into that

For example, if asked "how would you detect a cycle in a linked list?" you might memorise "Tortoise and hare algorithm, two pointers one slow and one fast, fast overtaking slow indicates the presence of a cycle"

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.

That's a funny example, because once in an interview I had exactly that question and the week before I saw tortoise and hair.

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"

Memorizing questions verbatim means that you will often get questions that require only a single line change in your solution.

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.

Speed matters. So what if you just can't be fast? What if you have dyslexia? Then what are you supposed to do?

> So what if you just can't be fast?

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.

Oh cool. So the ADA doesn't apply to this industry huh.

It actually does apply.

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.

Lol wtf are you talking about. There is no way you can memorize 2000 Leetcode questions.

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.

But i passed both of those interviews without having seen a single question before.

Congratulations, doesnt change the approach for people that are struggling to pass

Can we not advertise that cesspool of a company?

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.

What's the context of this? Placing travelers in dangerous scenarios?

I am almost certain those questions do exist on certain websites - you’re just not looking in the right language.

They mostly get in by cheating. A lot of people, even before ChatGPT cheated in college, cheated on their FAANg interview, and then still get promoted later since none of that shit matters and their promotion criteria is on if the button is moved 3CM correctly or not in some app that will be killed in 5 months anyway

OP didn't say to never learn it. They said just cram it in for the interview.

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.

The interviews I had at Apple were surprisingly straightforward compared to those at many other tech companies. I didn’t find the need to memorize anything, in part because I knew the concepts they were questioning me about after putting them in practice during the last decade of work, but also because the questions were quite straightforward, almost akin to general knowledge, for example:

• 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 technically impossible based on the interviewing style. I would have unquestionably accepted that job if it weren’t for the fact that I needed additional income to continue providing for my extended family and covering my mortgage.

In conclusion, if you decide to memorize LeetCode problems, ensure that you also grasp the underlying concepts. Unless all your interviewers are gullible, it will become quite apparent if you're just mechanically writing code without a genuine understanding of the problem or the interview's objectives.

This simply doesn't work without grinding, and grinding happens to be sufficient (whereas understanding is not).

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.

If you do this and I am the one interviewing you, I will fail you. I will figure out what you actually do/don't know and if you are incapable of performing at the applied level, I will fail you.

Thats fine, but the majority of engineers at Meta/Google will be impressed

This needs a [citation needed] sort of flag.

I think the strategy they are describing is to just memorize a bunch of stuff, and then interview until an interviewer happens to not catch on. Either they’ll get someone less prudent than you, or, I mean, you can’t possibly test everything, right?

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 recently stumbled upon an interviewer that asks "what will happen to this algorithm if I delete these 2 lines of code?" (the interviewee is the author) and deletes happen on simple if-else condition that maintains useful invariants and the interviewer said it eliminates most candidates.

I guess that's how memorization works.

I'm telling you, most candidates at Meta that got in and are making 400k+ sat in a room and memorized question by question. People need to know how they are getting hired. They are MEMORIZING the question bank.

This happened to me for meta. Saw the qs on Glassdoor, memorized, and passed with flying colors. Did not take the job. I was astounded that they asked the same question, word for word.

Yeah its appalling the general software engineering population doesnt know this yet

Most of them cheated, they didn’t actually memorize all that leetcode. Ive personally witnessed candidates at my own university successfully cheat on FAANg interviews which later landed them successful jobs/internehips

How can you chat in an (in person, I assume) interview??

In person interviews aren't a thing anymore. Instead it is all "virtual onsite".

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.

While this advice may work for some FAANG companies, I can assure you this won’t work for Google, especially at higher levels. You won’t find their questions in any public test bank online (trust me, I searched after my interviews).

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.

Google I have heard is a bit tougher. No worries, theres ten other companies that just want memorization that pay better than google.

At most of the companies I’ve interviewed at (except Google as you note), the hiring manager and principal engineer didn’t understand system design themselves. They only understood how to pattern match against a regurgitated answer.

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…

Very open ended question that requires clarification. Interviewing is about asking questions too.

Of course, it was a conversation and the engineer was happy to let me go in depth on storage after we discussed and dismissed other areas, like the front end, integrations, native apps which were not related to infrastructure.

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 this won’t work for Google

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.

To be clear, GP didn't mention designing a perfect system but providing perfect answers, which probably includes mentioning tradeoffs or being prepared to answer questions about them.

I don't think this is very good advice. Enough of the companies that believe in testing by algorithms are smart enough to change their questions slightly for each candidate.

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.

A former colleague of mine is at Meta thanks to this exact strategy. There are also apparently leaked question banks available to facilitate the process!

I've been compiling lists from interview experiences and there aren't many repeated problems. I don't think this advice scales. However, I haven't seen any material that will teach you how to come up with the trick to cracking a problem you've never seen before. The best approach seems to be learn patterns and if you're stuck ask for hints. Doing mock interviews to get used to the format is also very helpful.

I mean you still need to learn the material but you cannot pass these interviews without memorizing.

It is unfortunate that the situation has come to this for hiring in the tech industry but it is the reality.

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.

Back/forward navigation is broken. Lots of "Application error: a server-side exception has occurred (see the server logs for more information)." No footnote describing who owns the site, what the terms of use and privacy are, so I would frankly never trust it with any of my personal data.

I am very comfortable with algorithmic and system design questions. However, what I am struggling with is articulating past experiences. Throughout my last 5 years at my previous employer, I didn't jot down in my personal notes any accomplishments or technical designs. And my memory is so rusty now that I have a hard time reciting them. I understand this is squarely my fault. Wondering if you have any advice on approaching my next job? (senior / manager role)

write them down before you start interviewing. flesh them out over time as you remember more details. focus on the most valuable experiences, ie the ones that had the most challenges (organizational > technical for senior/management roles) or were the best learning experiences.

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.

The title is misleading. When someone says they offer “curated experiences” I assume they actually host and run activities. Like, if a company advertised “curated travel experiences”, I’d expect to be able to book a trip with them.

It seems like you might have a misunderstanding of what "curated" means. To quote the dictionary: "selected, organized, and presented using professional or expert knowledge." A museum is curated not because someone guides you through it and talks about things, it's curated because someone specifically took the time and effort to decide what to put out on display and what to omit.

So it looks like all big tech interview pipelines are more or the less the same? Fascinating and also probably indicative of something weird. If you are building a hiring pipeline, please do NOT copy this awful approach. These companies can get away with it due to their prestige, top percentage compensation, and need to easily filter hundreds of thousands of applicants. You should instead treat your applicants like humans, look at their past work, and actually express genuine interest in them and have a real conversation.

I think this is valuable, but at least for Google and Netflix they were extremely straightforward about their interview process and were even happy to give tips on how to prep.

I've 20 yrs of work experience in small to large tech companies and thinking of switching to a new company. Even I'm expected to be swift with leetcode style questions. Now, it's not like I can't do it; I've been an IC for most of my career and have a good background in DS and algo (Master in CS), but it takes time and effort and above all it's terribly boring. I've practiced 200 questions (including 150 from neetcode.io) so far but still don't have the confidence because I need to resolve them; repetition is the key. If you lose touch for even 2 weeks due to work/family commitments, you lose the streak/form. It's particularly tough for senior people. Some say, move to management, but then this is first not a good reason to move to mgmt, and secondly, if you think you can escape leetcode by moving to mgmt, you're in a shock.

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.

How many of these companies actually conduct in-person "onsites" anymore? I would guess most of these are still remote — granted, I haven't done the interview circuit in a couple years now. It would be cool to have some kind of indicator for which companies are doing in-person and which ones remote.

Why just the big tech companies? Quite a lot of smaller companies and startups have 4-6 step interview chains that burn just as much time. Although they're less commonly centered specifically around leetcode, they're often even more offensively stretched out and laborious.

Agreed, we're starting with a few big tech companies for quality > quantity. We will gradually add more companies based on demand.

Feel free to suggest companies here: https://www.onsites.fyi/submit#suggestForm

Don’t candidates have to sign NDAs to not reveal problems? How do you get away with posting potential IP violation, especially system design questions. Genuinely curious on this - is it legally allowed?

This is basically only valid for software engineering FYI - a Data Science/Applied science interview is going to be very different. And probably differ from team to team with much higher variance!

The filter seems to be broken. I searched for L5 system design and got L4 in the results, which was actually an L3 at the time of hire.

For anyone in hiring, for new grads how important are internships ?

Seems like its practically required at this point

Do it for your own good. You will get an idea of what working in industry is like, and perhaps the name of a reputable company on your resume.

I am not going to reject a qualified student out of hand for not having done an internship.

My observation has essentially been all the random complaining you see online where “entry level requires experience,” which seems counterintuitive at first, is not counterintuitive if you consider than internships are really that pre-experience that “entry level” requires. So my unpopular opinion, and what I’ve observed in real life as being on the hiring committee or panel at top companies has been that for new grads top internships are an even more important signal than top schools.

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.

Finally, the actual AAMMG, not some weird companies.

(They needed Netflix so it wasn’t a slur)

Thanks a lot for this

How valuble

Looks like we killed it. I clicked apple and got "Application error: a server-side exception has occurred (see the server logs for more information). Digest: 2825624865"

I still dont see how its any different from glassdoor

For developers it's best to focus on top 5 tech companies that everyone else mimics.

This is only one of a lot of strategies though, essentially playing the lottery.

Reply on news.ycombinator.com