A lot of FAANG engineers seem to report that the interview was the hardest thing that they've done, harder than anything they do as part of their actual job.
It's probably not that the leetcode problems are ultra hard to solve (though they can be). It's also the combination of the artificial time constraint and the high pressure interview setting - which is a very different kind of pressure than you typically experience on the job.
FAANG guy here, interviews are hard in that they have absolutely nothing to do with your day-to-day job. If I were to go through the interviews again right now I'd make a massive fool of myself. I'd say it's basically common knowledge that prior to making any hops, you've got to take at least a month or two to grind leetcode problems so that you're back in that head space where you can solve pointless problems with high efficiency.
Interviews are also hard (as I frequently comment around here) because, once you've seen how the sausage gets made, you realize it's basically still a crap shoot which comes down to the loop you get. If you get an unlucky roll and end up with the personality type which views interviews as a chance to show how much more clever they are than everyone, then you've already failed. Their ego is tied to their "high bar" and impossible question set, and you're just fodder for them to show off that "high personal bar" during the de-brief.
As a younger developer I was part of a 3 person team that was interviewing people at a telecom. I mostly kept quiet and observed since it was the first time I'd done this but we had one member of the team who was bent on trying to show how smart he was.
My absolute favorite interview of the group, a guy who ended up getting hired elsewhere, was the most calm and professional developer I'd ever been around. Sitting in the room, I felt like he was interviewing us rather than the other way around. It was just in the way that he carried himself, answered questions.
And then the guy on our team started asking questions. The gentleman we were interviewing, rather than answer, kept calmly asking more questions of him instead.
- Can you describe the situation where this would be used?
No
- Have you ever run into an issue like this before that could be an example?
No
- How do I know that by solving this problem we would be addressing the business or customer problem?
We don't
- Then shouldn't I be solving questions related to the work?
...
I loved that guy. Wish we could have hired him because I really wanted to work with him.
I try to use problems that I encountered and solved during my daily work in my interviews, and generally the experience is better for both me and the candidate when the problem is more relevant.
Many interviewers don't do this because it's often difficult to distill the most interesting problems down to something that would fit within the time allotted for the interview, and also there are candidates who prefer abstract textbook-style problems.
Yeah all my most interesting problems are solved by carefully reading logs and the code that wrote them, stepping through code in a debugger, working on small repros, and eventually hitting some eureka, often after a couple days of dedicated effort. This would be a poor interview technique, though it would have great signal.
A web startup I joined years ago hired this way. The "main" technical interview was pairing with one of the devs to fix a toy broken service. In my case, this went fullstack from client bugs to backend bugs to sql/orm bugs as well as "make a page to show a list of things". They weren't so formal as to have a coded up modular interview system or anything, but I always enjoyed that one the most because it was closest to the job.
Amazon calls that the STAR method, Situation, Task, Action, Result. Combined with real world experience / examples can be powerful during interviews. Especially during interviews with people not knowing this method.
> I stopped an interview once. I told the guy I didn't think I'd be a good fit for the organization, and maybe we should save ourselves some time.
I've done this a few times, each time from a startup that reached out to me asking me if I'd come in to talk to them, and then would throw me into their coding challenges immediately. Like whoa hold on there, I don't even know what you do, why are you asking me to do a coding challenge before we've even figured out if there is a fit for me technically and I figure out what it is you're trying to solve.
I once passed some take-home test from a small startup. They then requested a further take-home which a) would be monitored (it was a remote position) and b) would require some six to eight hours and c) would have to be done over the weekend. There had been no contact with anyone at that point other than passing the initial test, and no discussion of salary, benefits, etc.
I've rarely used unprofessional language in job application emails, but on that occasion I pretty much told them to take their no-name little company and shove it.
This seems to be another example of the trend to AI based hiring, where the candidate interacts with zero humans until they have invested a huge amount of time and energy[0]. Good on you for telling them off.
I asked some of my interviewers, who had been around their companies for a while, if the interviews were as tough when they got hired, I think a few said said no it was easier, and iirc one said when they got hired they just shot the shit for a while and got hired right away, but he joined before the company was acquired by a FANG.
Good call on the dice roll. Spent months prepping for the FB interview and got an engineer who seemed to be having a bad day or was just bored. I knew both problems but they derailed me on whether you can uniquely identify objects in JS with no additional id assigned. I told them you can’t as there’s no pointers or memory addresses in JS. They didn’t believe me and literally spent multiple minutes googling things to prove me wrong. And then rejected me after I still finished the second problem in the 7 minutes remaining. Nevermind they were looking at their phone multiple times during the interview lol
Demoralizing as all hell. Thankfully I had multiple mocks with FB engineers who told me I did great so I know it really was just bad luck that the real phone screen was a dud.
Ugh, that's terrible. I had a similar situation when I started interviewing after my startup failed. It was with a major energy company for an Angular developer role. The interviews were going really well until the final interview when they asked me to do some live coding. This led to a 15 minute discussion about 5 minutes into the session about whether JS had while loops. The developer testing me was absolutely convinced that JS had no while or do/while loops and refused to move on from that point. Their loss.
It amazes me more people don't see this. Virgin in the UK looked into the data and found a bad candidate experience was significantly impacting their bottom line, just in actual candidates cancelling their service within 30 days of a bad candidate experience.
They didn't even need to look at word of mouth impact to see a material hit on their customer retention, in a sector where churn is costly. They went on a crusade to improve, and now find candidates for jobs are net promoters, and their customer acquisition cost via candidates is lower than normal advertising(!)
I think some of the big tech companies simply don't care about their reputation at either micro or macro level, and nobody wants to call out that kind of toxic behaviour as they're all "part of the club".
This is actually a big thing we invest in at my current company: candidate experience and consequently a high Glassdoor rating. After focusing on it for years the company has one of the top ratings on Glassdoor (top 100 or 200 I forget). It’s a big differentiator when you’re not a big company and not a recognized brand. I think for FAANG companies they can get away with it because despite a poor experience, the actual job and pay/perks they offer are extremely desirable. Sad because, like you say, it’s not hard to see and make an impact on improving.
In my experience Glassdoor doesn’t mean shit. The single most dysfunctional, toxic work environment I’ve ever been in had - and still has - a high (>4) rating on Glassdoor. I won’t get into details but I was miserable and left after two months. They said all the right things during the interview but the reality was vastly different. The non-disparagement clause I had to sign on my way out was the icing on the cake. No wonder they have such a high rating if you’re not allowed to be honest about your experience.
At an employer prior to that, I saw first hand how companies were able to get negative but true reviews taken down almost as soon as they were posted. There was high turnover at that place and a lot of people were truthful in their reviews of the company. The Glassdoor rating was far higher than they deserved until they went under.
Im short, I’m sure you think you’ve got a great work environment, but I’ve been burned by bullshit Glassdoor reviews and I doubt I’m the only one.
That’s fair. It’s a metric so it doesn’t surprise me that it’s game-able like others. I guess as a candidate you have to use it as one data point. It’s tough because even interviewing as a candidate and asking lots of culture questions you only get, what, like 20 mns of questions answered? Before you commit to 40 hours a week? Sorry to hear you got burned. Toxic work environments are such a drain on life.
Well on the opposite side of the table are the people who start arguing with me during the interview (and twice even after the interview).
I generally try to help everyone as much as I can during interviews, because honestly this is taking time away from my other work and I'd nothing better than to hire you, but sometimes it's just to much.
Sometimes interviews are just part of “following the process” when someone who knows someone is going to get the job anyway, but still they have to follow the process so everything looks normal. These things are not so cut and dry and objective as you would like to believe. I wouldn’t sweat it.
That's a bugger :/ Regarding uniquely identifying objects, if we can compare objects by reference, doesn't it count as unique identifying? E.g. let a = { }; let a2 = a; let b = { }; a === a2, but b !== a2 .
In this case it was a problem about creating a deep copy of nodes in a graph. My “easy” approach involved using a map with the key being a reference to the original A and the value being the copy A* OR adding matching ids to A and A* and use a map to go from A to A*. They said no mutations to the original objects (ids are out the window) and then that led to the quibbling over addresses because you can’t use an object reference as a key in a map in JS (it’ll just stringify it in the map).
(I’m half hoping that after typing this out someone will reply with some data structure I’m unaware of that would allow you to uniquely map the reference of an object to an arbitrary value.)
My beef with the leetcode interviews is that, IMO, they're in no way reflective of what you're actually going to do, and yet the interviewer often acts like it's a perfect barometer. One misstep or quibble and you're out.
I remember when a former colleague wanted my input on his interview question which was basically, "Write the algorithm for product recommendations." (eg, like Netflix's movie recommender.) Despite repeated warnings, he went ahead with that question only to come back and admit, "Yeah, that wasn't at all good." Imagine what the poor guy or gal on the other side of the table had to go through.
I don't know what the right answer is to interviewing, but my take is that I would prefer to work with someone who I can get along with, have real human conversations, and become good collaborators -- even if they're not ace coders. That measurement seems glaringly missing from too many interviews.
I've consulted with quite a few companies on their interview process. Almost all of them had adopted Leetcode style interviews. My first question to the team always is: what exactly are you evaluating when you interview someone?
And I rarely get an answer that makes sense. Instead I get mostly rationalizations for Leetcode. The thing is I recognize those rationalizations because I was certainly guilty of it in the past ("We're evaluating intellectual curiosity" is one I cringe at now).
The real problem from my perspective is that most teams have never taken the time to really think about and identify the underlying principles about how they want to work. We go through a process of defining those principles and all of a sudden the interview gets a lot clearer. Do you value the highest quality code? Do you value getting things into the world quickly and then iterate towards the final solution? Is security always at the front of your mind?
Getting really specific about what exactly being "excellent" means to a team is really critical.
Because then you can design an interview process that actually selects for those things. I've never had a team define "the ability to solve leetcode problems under pressure quickly" as an endpoint they actually care about. Some teams continue to use leetcode, but only as a small part of the process with problems that ARE actually directed at what they care about. Having been through a bunch of interviews in my 25 year career I instantly know when a team has actually done the work to design a good interview process (which has been far too rare in my experience).
It’s hard to admit that they don’t actually know how to evaluate people well and instead implement an absurd level of inefficient gatekeeping. The same reason some jobs only hire people with degrees even if it’s not necessary or the degree is irrelevant.
Leetcode interviews don't test if you're a good software developer, they test whether you're capable of becoming a good developer. The skills required to succeed at leetcode basically come down to 1. willing to spend 100 hours studying/practicing 2. Baseline critical thinking skills. Throw in some behavioral to make sure they can communicate and those are basically the skills needed to become a decent developer.
Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?
or trying to glean proprietary information out of others?
> Wasn't there also an issue with companies trying to interview people and asking them questions like that, not as a way to hire anyone but as a free way to get smart people to solve some of their software problems?
It's a struggle between fitting the interview to real-world situations vs making it seem like the candidate is doing work for the company.
I feel like a good situation might be actual problems previously encountered with the technology being assessed during the interview that would've required you to have collaborated with someone who is also experienced in that technology to help you solve them.
Maybe the best way to do this is when the situation is proposed to the candidate, make it clear that the answer is already known and put it in an envelope (physical or digital), which will be referred to when it's solved or the candidate hits a dead-end.
I don't think anyone cares if you can actually solve the problem. They are looking to see how you perform under pressure (not because the job is necessarily stressful, but because we can learn a lot about a person's true personality when they are under pressure), how good you are at problem solving, whether you actually know anything about coding or are just BSing, etc.
"but because we can learn a lot about a person's true personality when they are under pressure"
Do you have a source for this? I can't help but think about the person in this clip: https://www.youtube.com/watch?v=LlCEmPF4-V0. You think you can learn much about her from that interaction?
Just being IN the interview to begin with is likely to be higher pressure than any sane or sustainable working environment would be.
I've interviewed people who didn't know the answer to some of these tech questions, and honestly, I was more impressed by them calming saying "I'm not sure on this one, I would probably need to go look it up".
I used to be quite stressed-out by job interviews, until I realised a small crucial thing... If you're interviewing while employed (which, to be fair, is not a luxury everyone has), the absolute WORST outcome of that interview is "I am given an offer".
Why worst? If you're not given an offer, nothing changes. You've spent somewhere between 45 minutes and a day, got some interview practice and all is basically status quo. But, if you're given an offer, you are now faced with having to weigh the pros and cons of accepting it.
This is the ideal, and the original point of such questions (I was at a FAANG and interviewing candidates when they started becoming popular), but the inevitable result is that the test becomes interpreted more literally as it becomes more common.
While what you say is the ideal situation, I think being able to get the optimal solution and giving at least a halfway decent explanation about why it works is the #1 most important thing (along with just plain old not being a jerk).
I acknowledge there are some situations where you might pass the interview even without arriving at the optimal solution, but those are probably the exceptions.
When I'll be preparing for the next interview rounds in my career, I'll make note of some problems that are both short/easy to explain, and have really interesting optimisations that are almost impossible to come up with on the spot (unless you've done a lot of similar stuff or that exact problem before). Then, when the interview is (nearly) over and it's my time to ask the interviewers something, I'll drop one of those in their lap to see how they react, and if they can come up with something that's not laughably stupid/inefficient. My point being that, if they're not capable of solving problems like that under intense time pressure, they're not up to the task of interviewing someone else on them. If they do give a good response, kudos to them, I'll be impressed.
Though I think my expectation is that they'll get annoyed and stop the "interview".
If you did this to me during an interview, I would try as best as I could to give you an answer in the 5 or so minutes left of the interview. Then, in my feedback, I would strongly recommend not hiring you as a bad personality fit.
I also don't really ask "trick" questions (I try to select questions based on what the CV indicates would be a strong area for the specific candidate), the closest I get to that is probably when it comes to service monitoring (where the exact final answer is less interesting than the process of getting there).
My reply was only intended for "trick" questions that have absolutely no relevance for the day to day job of 99% of Software Engineers. And that's exactly because those trick questions tend to be more about the "exact final answer" than about the process, so my point was about figuring out if the interviewer actually has a grasp of those sort of problems in general or if they memorised a good solution and are milking that for all it's worth.
And I do know that almost any interviewer would reject me based on that, but I think it's worth letting them feel the burn they try to inflict themselves.
Right, but you can't become a doctor without spending many thousands of hours and hundreds of thousands of dollars gaining credentials. But you can become a highly compensated software engineer by spending a miserable day answering pointless questions on a whiteboard. I would personally prefer the credentialing approach because at this point it would be easy for me to get the credentials. But the low barrier to entry also has advantages.
For that matter, I'm not sure that the way medical education is done is something to aspire to. Years and years of exhausting sleepless tedious grind, at the expense of any instruction on deductive thinking or bedside manner; if at the end of it all they can't even draw the Krebs cycle from memory, then what the hell is the point?
Ha! My hobby is pharmacology and I’m always having to refresh myself on various steps of Krebs. We need a Ninja Nerd[0] for CS I guess, I’ve found it incredible.
> interviews are hard in that they have absolutely nothing to do with your day-to-day job
I often wonder why this is legal, especially given the legal concept of disparate impact. It's basically just a disguised test of some combo of IQ + free time + willingness to grind dubiously useful information
I think it's only a matter of time until the extreme disparity between the candidates that pass this filter (mostly white and asian men below age 35) vs the applicant pool is used in a legal challenge about whether these tests are really looking for bona fide occupational requirements.
Because any software person will tell you these tests are extremely detached from the requirements of the job.
It seems like it would be an open and shut case if not for the army of lawyers employed by the likes of Google.
I think such a challenge would fail in any reasonable legal system. HN seems to be talking itself into a belief that these interviews have no relationship to actual programming work, but that's not the case and plenty of experienced engineers would step up to defend algorithmic questions if it ever moved beyond bellyaching in blog posts.
Of course the USA is ever more extreme and crazy when it comes to identity politics, so ago knows if the justice system is still reasonable in this regard. But I'd really enjoy watching people argue in front of a judge that working with tree structures is extremely irrelevant to programming.
There's some truth to this, but it's also true that when someone with many years of experience and a long history of top performance ratings and promotions has to take a week or two off to study in order to do the test, that it indicates the test is not well targeted to the job.
I find this interesting, because I feel every time I visit a Silicon Valley tech company’s office, I’m surprised by how diverse the employees working there are. Yes I know certain groups are still more represented than others.
But it’s still more diverse in contrast to the companies I’ve worked at (non-tech old school companies in finance, etc), where the tech employees tend to fall into a much narrower stereotype.
> I often wonder why this is legal, especially given the legal concept of disparate impact
“Not yet challenged” and “legal” aren’t exactly the same thing. Straight up IQ tests are probably more defensoble than leetcode for lots of positions for which leetcode interviews are used. But people have heard the popular misrepresentation of Duke Energy (“it’s illegal to use IQ tests”) more than they’ve heard the actual disparate impact rule, and that seems to be true on both sides of thr interview table.
Regarding getting a "bad" interviewer - what makes this worse is you're rolling the dice multiple times.
I've had several interviews where everything seemed to go well, but one (out of say, 4/5) interviewer just seemed to be hostile from the moment they walk into the room.
The core money-making algorithms don't take many human bodies to develop. At Google, 500-600 researchers and core algo developers likely do most of the heavy lifting.
Otherwise, 90%+ of their developers are likely solving routine problems.
Although, most of them likely convince themselves that only the "chosen ones" among mankind can do what they do.
The reality is that most of software, even at the FAANGs, does not require the type of interview questions these teams enjoy asking.
FWIW, I don't think most people at big companies are at all convinced that they are the "chosen ones". I think they are glad to have good jobs that have a higher than average potential to contribute to projects that are useful to people.
Anecdotal counterpoint: Passing FAANG-style technical interviews are the easiest thing I've done.
Learning new frameworks and coding standards, surviving code review, dealing with difficult team members, dealing with ever-moving business goals, and just about every other aspect of work, including the coding, has been harder.
I admit that I have never had to invert a link list as part of my work (Graph traversals I definitely had to do, actually). But I have had to submit to arbitrary technical demands and to learn and use technical materials I did not enjoy or agree with architecturally in order to successfully complete projects. So in that, studying and practicing to pass the technical screen is similar to the job. Employers want someone who is able to (sometimes!) bite their tongue and just do the work assigned.
I think the rationale at the scale of this point in FAANG is to hire as many people as possible and see who can't hack it (pun intended). In the early days, they had to be more choosy about narrowing the talent pipeline with harder interviews.
Actually, I remember one IT-style interview 12-ish years ago with a certain FAANG that shall go nameless that had this sorta narcissistic/sorta dumb hiring manager, whose profile picture was a shirtless muscles pool pose, believed that a technology I inherited and was forced to use was an interview deal-breaker. And, at the time, I was at an IT department at Big Name university down the street where there were much more complicated and interesting things going on, like remotely uninfecting and patching worm-laden systems and putting together a fully-redundant/HA VMware cluster that had an FC SAN and blade servers (the thing back then).
FAANG has a system for firing people who can't cope with the complexity of the job. There is a huge survivors bios. To be a FAANG engineer you need to be able to pass the interview and have the skills (mostly people skills) to navigate a large system.
Surely companies account for this in their interview teams? Or are they just haplessly floating on the narrowly applied intelligence of their workers? (Or something else, not suggesting a divalency).
I don't know if it's true but during a video talk there was a story that a team of googlers were secretly given their own feedback ratings and they didn't hire themselves.
Amazon introduced the notion of a “bar raiser” who expects a candidate to be stronger than 50% of the staff. It’s sort of appealing, but if your attrition is unbiased (you lose equal numbers of strong and weak staff) the right edge of the bell curve seems too small to keep up with it.
Its also a different kind of problem. Its not really problem solving, though it masquerades as such. Its memorization. Plain and simple, you know the techniques or you don't. Studying at length for those kinds of problems is extremely unfulfilling, especially for curious minds who have long realized there are far more actually interesting and useful problems to solve out there than there is time left to live. And yet, here we all are jumping through hoops because nobody has figured out how to test for real job skills.
It isn't pure problem solving but it also isn't memorization "plain and simple". It's a mix. It's unlikely you'll see exactly the same question as one you studied. The problem solving portion is figuring out how to apply one of the techniques you've learned to a novel problem.
I say "plain and simple" because IME people tend to overestimate the novelty of problems and underestimate the impact of "memorized" problems for solving new ones. 3 months of studying for an interview, while extremely annoying, is generally speaking a pretty small amount of time needed to cover a field as vast and complex as DS&A. And yet it is more than sufficient for most because there's extremely little novelty in the problems being asked. They want you to solve classic algorithms, but either dont' want to tell you so or (more commonly, IME) don't realize they are asking classic algorithm problems and only think they are asking some novel problem. Even "simple" techniques will be impossible for a person to solve in an interview setting, and yet if they've seen it before the interviewer will think they are a brilliant programmer. Its a memorization game even though it doesn't directly look like one. IMHO.
I think the argument is that recognizing the algorithm part through the (usually thin) facade is very easy, once you know the (common) DS&A questions well. I.e. there is a lot of challenge in learning the algorithms, and little to no challenge in recognizing it through the problem. Examples where a person knows the underlying DS&A very well but is unable to recognize the nature of the problem would be a great counter argument.
Not just FAANG jobs. In almost every job I've ever had, the interview was by far the hardest part. There's such an enormous stream of candidates, and no baseline "bar exam" to qualify people, so companies have to make the interview bar extremely high in order to be able to manage the candidate flow and sufficiently minimize false positives.
I'd guess 99% of engineers never have to do CS trivia as part of their day-to-day job.
I've been on interviews at some companies that have no brand name recognition/prestige, and probably do not have legions of candidates trying to get in. But they've thrown me harder leetcode questions than FAANG.
It's a bit perverse but the problem is that hiring people who can't do the job well is much worse for a company like that than it is for a big company with lots of slack in the system. Not only do they have to pay a person that isn't contributing enough, but the more senior folks on the team have to spend more time mentoring, so it's a double drain. This drives the process toward a higher bar after getting burned a few times.
I like to ask simple questions, and then dig further into once they answered it correctly. You would be surprised how many ex-employees from FAANG like companies fail it.
Simple questions, as in simple leetcode questions?
FWIW, most FAANG employees seem to admit that if they had to redo their interview, odds are they're more likely to fail than pass. Goes to show how much luck is involved in the process.
I think it's gotten harder too. Maybe in the past it really was about trying to see how the candidate thinks and solve problems. But now it seems like all all of that is secondary to getting the optimal solution. Two of my friends in Google who got in ~10 years ago say that it's definitely gotten harder from what they see.
> There's such an enormous stream of candidates, and no baseline "bar exam" to qualify people
That could be trivially fixed tomorrow, either by universities or (better) by an accredited certification body.
I mean, I'm sure there weren't bar exams for lawyers and professionals either, at some point in history. What prevents us from creating one for sw developers? As long as it didn't require additional attainments just to sit for it (i.e. you should not need a university degree), it would make the whole process more efficient for literally thousands of companies.
There's a significant number of employed, productive engineers that are apprehensive about passing such a test. They will fight tooth-and-nail to prevent any gatekeeping to the field. Personally, I would be happy to have my salary double overnight.
What do you think a cs degree is? We don't use them as automatic proof of competence because lots of people get good degrees but cannot program, or enter the field in other ways but can.
As you state yourself, cs degrees fail at being proof of competence. They are too long, expensive, and unfocused. Hence why we really could use something else, simpler and more accessible.
Yeah, but which institutions would design such exams? CS degrees aren't ideal but at least they're designed by people who have CS training and are programmers. If a government decided to set such an exam it'd probably end up requiring some sort of certification in enterprise .NET development.
Maybe. I agree that's a strong argument, but I think for both accountancy and law the standards are in both cases defined by governments, as the professions are largely about ensuring compliance with what governments require. The professional certifications can thus be just checking your knowledge of what the rules say, without getting into the question of whether the rules are correct.
In software it's not like that. There are very few laws on the book about how to write software, so there's no single authority that defines the right answer or the scope of reasonable questions. It's far more open. Even just picking a set of programming concepts would immediately cause controversy. Like, should monads and type-classes be a part of the professional qualifications? Most programmer would say no, because Haskell isn't widely used in industry. But CS degrees do sometimes test people on that sort of thing!
This seems like a decent point for accounting but not really for law. Certifying a lawyer is not just about a finite set of things they have to know, it's about fundamentals and the ability to ingest facts and form an argument. Similar to your Haskell point, there are parts of the law that not all lawyers need to know, but are expected to be able to figure out as needed and the certification aims to check for that ability.
(Also, in both cases, the government hires members of the profession to define the standards.)
I'm convinced we could have a bar exam for software engineering, but I'm not at all convinced that we should. It would make my life easier personally, but it would keep a bunch of people who followed less traditional paths out of the industry and I think that would be bad.
Google projects on Github are a good reflection of it. The code quality of these projects sometimes. You wouldn't be able to get away with that in smaller companies.
Oh I agree, but yes, I think it's the giant amount of pressure and negligible room for error that makes it so hard, rather than the difficulty of the material.
It's probably not that the leetcode problems are ultra hard to solve (though they can be). It's also the combination of the artificial time constraint and the high pressure interview setting - which is a very different kind of pressure than you typically experience on the job.