Comedian Daniel Tosh had a bit about people that claimed to be smart, it's just that they were just bad at taking tests. He said, "oh, so you struggle with the part where we find out what you actually know?"
I hear a lot of complaints about the "typical" software engineering hiring process, and it usually comes from the people that don't do well within the current system. Could the process be improved? Almost certainly, I don't think that anyone thinks that this is an absolutely perfect way to hire people. But it is an undeniable fact that some people pass this interview process; software companies do fill positions with this process.
So that kind of makes me think that many of the complaints are from people that wouldn't cut it at a high-pressure tech company and would be better off coding internal software for a non-tech corporation. I'm sure that the hiring process at Kroger (the grocery store) is much lower pressure than Google's. Google might not need you to code some efficient algorithm to search a b-tree every day, but they pay top dollar and can rightly expect that their software engineers can come up with efficient and creative solutions to hard problems without dragging the rest of their team down.
People are completing 500+ problems on leetcode before heading into interviews at google. Don't believe me? Go read the teamblind forums. People might spend six months studying, after which they pass a bunch of interviews and get good comp. Getting just one offer from a FAANG company often doesnt pay well enough, you need multiple competing ones.
If you think this has anything to do with incompetent people complaining, then you arent reading into the situation.
I will add that one can pass these interviews without extensive preparation, but it makes it alot harder when those around you are willing to spend ridiculous amounts of time studying.
Then its working. Big companies love it when people spend time studying for their interview process. It shows commitment and means that person will feel like they "earned" that job, and should stay longer.
This reduces churn, which is the thing they screening out the most.
To the big tech companies, this isnt a problem, its a sign of success.
Think how whiny this sounds to any law firm/medical practice. People spend years studying/preparing/working for free to get an internship. And yet, most software devs are still payed better.
Lol doctors change jobs and get jobs with relative ease compared to us software engineers. They go work part time at this clinic or that clinic quite frequently.
When I studied for my google interview back in 2011 I learned tons of new things which I used professionally at google and beyond. But I’ll concede that it was before leetcode (although i did casually compete on topcoder just for fun) so I mainly read up on areas where I knew I had blind spots.
I'm imagining it's going to bite these people on the backend later in life when they sacrificed everything for their careers and potentially missed other major life milestones: cultivating a relationship, starting a family, etc. I know not everyone spends 6 months getting into Google, but there are so many other companies that will take you without 6 months of preparation. If career is the only thing that gives you meaning in life, sure, but I'd rather not put all my eggs in one basket.
I used to think that until I heard of people with far less experience than me getting paid $400k total comp at these places because they can ace the interview and get competing options. That's worth putting 6 months of work in.
Yeah, once you're in, it's cushy, for sure. But that's not the full story. You're likely going to have to move to the bay area to make $400k kind of money. Are you willing to forego living near family, friends? Plenty of people do, but time gets more valuable when you have less of it left.
For one thing 6 months is definitely the high end of prep time. Even so, spending your evenings studying for one 6 month period in no way precludes you from ever dating or marrying or having children.
This is anecdotal, but most of the people I know at Google and other FAANGs did not spend that much time preparing for their interviews, if they even bothered to prepare at all...
Maybe some people do that - I didn't do a single interview question prepping for a Google interview; just read through the topics they suggested reviewing, looked up the concepts I hadn't seen before, and did the interviews.
having just recently (in the last 2 weeks) completed >100 problems on leetcode i can affirmatively tell you that it's not actually that difficult to game this system. i read elements of programming interviews (took about a month of a couple of hours a day) and then just blitzgrieged leetcode. this was all in prep for a FAANG internship tech screen i had yesterday. it went well (not perfect but well).
but it is true that these questions bear no resemblance to software engineering so it does feel silly going through the process.
The people complaining are usually the ones who can't just prep for algorithmic interviews with a couple hours a day of effort for a month.
Which makes the algorithmic interview a relatively good filter - ability to learn something difficult quickly is a very important skill at high performance software companies.
When you're paying someone to solve problems for 40 hours a week, assessing them based off if they're willing to do that in their free time seems naive. It's surely a safe option, but you'll miss a ton of qualified talent, and potentially not grow fast enough because of your hyper-idealistic expectations for what it means to be a software engineer.
Speaking as a parent, the idea of having “a couple hours of free time per day for a month” to learn difficult new material is laughable, and it has nothing to do with intellectual ability.
Then try 1 hour every day for 3 months, or 1 hour every 2 days for 6 months, or whatever you can fit into your schedule. Do you really have no time at all after your kid(s) go to sleep? I prepared and interviewed with a 1 year old at home, it was challenging but doable. Your situation might be more complex than mine though, I wouldn't know.
How about taking a few days off to prepare for interviews?
I mean, you're going to spend 4-5 hours per day for each of your onsite interviews (plus an hour or two each for recruiter calls, phone screens, etc.), so if you have zero free time, interview prep is probably the least of your problems...
Tosh's joke ignores that people can struggle with recall and on-the-spot test taking stress, while performing quite well at whatever the test is assessing. When studies have been done on interviewing, nothing has shown that inducing stress is ever helpful, unless the interview is for a job that requires on-the-spot stress, such as interviewing to become a police officer.
To me, here is the actual problem that I see cropping up. FAANG companies have enough volume of applications per position that they can afford to have a system that will strongly prefer false negatives over false positives, so they are willing to err on the side of, "We'll just hire people who can pass our realtime CS-grad battery and sadly say goodbye to equally good candidates who cannot." Ok, FAANG companies can do that as long as they are eyes-open about the situation. Where things screw up is that companies that are not FAANG companies do not understand that, and end up aping the FAANG interview techniques when they do not have the same applicant volume. This starves them of talent, and also leads to good applicants getting rejected by non-FAANG companies.
Really makes me sad to see startups trying to compete with the same talent profile as google: as a small company you need every edge and chasing after the same candidates receiving fat offers from FAANG is not the way.
Yep, I think that the guy who you replied didn't work out that it was a joke. I am not really sure how anyone who has spent time in the real world thinks that tests are effective.
Look at Korea. They torture their kids, and are they smashing the world economically? Nope, economy still totally reliant on chaebols, almost no innovation, GDP per capita is actually quite low for such high levels of human capital. I have seen this in financial services...firms that hire teams of PHds get nowhere (one place even has their own postgrad institute at Oxford...still get shitty returns year after year).
I don't think tests are bad at all, I am not saying they aren't useful...but they optimise for stuff that doesn't always work in the real world. And, unf, hiring is one of those things that is just very hard...trying to uncover talent by doing these tests where everyone knows (roughly) what is going to be asked, and people are just preparing with rote study...that doesn't sound like you are actually trying to uncover talent. It sounds like you have decided hiring is hard, and you don't have anyone who can hire...but if you are Facebook and you are hiring thousands of programmers, statistically you aren't hiring the best of the best so...maybe it doesn't matter.
The ability to acquire and apply technical knowledge, and ability to demonstrate random technical knowledge under time pressure, in a foreign environment, while other people are watching and judging you, are orthogonal skills and many engineers are great at the former and terrible at the latter.
There's also a ton of opinion and taste involved in software engineering, which can bias the interviewer's view of someone's technical ability. Not to mention all the unconscious biases against people who don't "fit the description" of a typical software engineer demographically.
The Googles of the world limit their own potential by rejecting many talented people who couldn't make it through their hiring filter for reasons that have nothing to do with their actual ability to build software. Then they express angst over how difficult it is to fill positions. It's a self-inflicted problem, and a hard one to solve. It's probably impossible to design a theoretically perfectly fair hiring process without also solving all causes of inequality in society generally. But it can be made better and more fair than it is, and many companies and applicants aren't satisfied with the existing hiring processes, so they are making efforts to change the situation, as they should.
Time pressure, foreign environments, and people watching/judging your work are all exactly the things that happen when you're developing stuff that hasn't been done. You run into problems. You find out that requirements or an API spec weren't perfectly written and have to deal with change. You have to work with other people, and they will judge you.
Hard coding exercises with a time limit that have an answer that can't be found on Stack Overflow do a pretty good job of simulating real world job pressures in a controlled environment so they can fairly rank order candidates.
The technical interviewers that might be biased against you are either the exact people that will have to work with you, or at least they fit in the same company. If they don't like you during the hiring interview, they won't like working with you.
Alphabet's market cap is literally a trillion dollars, so I'd love to hear about how they should stop limiting themselves and start hiring people that can't finish an ill-defined task with a deadline looming and other people waiting for you to finish your module.
The market will eventually shift and they will not see it as they are not in touch of reality and everyone there are in the same bubble. It will be something you can not fix with money.
But the questions are not "stuff that hasn't been done." They just test whether you've memorized the answer that took someone far more than 15 minutes to find.
On HN, it's not ok to bring in someone else's personal details as ammunition in an argument. That's a form of personal attack and a steep drop in how users here need to treat each other.
https://news.ycombinator.com/item?id=22334315 ("Looking through your LinkedIn/comments is low effort and confirmed my suspicions of you being whatever the inverse of Dunning–Kruger is") was even worse. Please don't post like that here, no matter how right you are or feel you are.
Surely is relevant when the person is commenting on the experience of something when they've never experienced it.
I'm all for dogs on the internet but no point in accepting dogs commenting on the life of cats whilst strongly giving the impression that they too are cats.
I understand the annoyance, but the problem is that we don't have access to anything like the precision necessary to make such calls well on the internet. There is (vastly) too little information, too many opportunities to get it wrong, and the damage caused by getting it wrong is too great to be worth the risk. Therefore it's the better part of valour just to not go there.
Even getting it right doesn't help, because it will encourage other people to pull the same stunt themselves, get it wrong, and cause damage. We just need to not go there as a community.
I never claimed to work at a FAANG company, but I must have hit a nerve if people are going through the effort of looking at my LinkedIn profile and looking at more than the first page of my comments.
Believe it or not, you don't need to have passed the tests or have software development experience to make the observation that people complaining about a process are the ones that don't perform well. I've written and graded many exams, but only ever received complaints from students with C- grades or lower. Funny how that works.
And it's not like software engineering is some magical pony that is different from other white collar jobs. To get into my current PhD program I had to interview with multiple people, take a 4-hour written exam, do a week-long exam at home, and I wasn't compensated for my time. So I'm not that sympathetic to people that complain about tech job interviews.
I've held many other white collar jobs in my career. Software engineering is different, the interviews are at least an order of magnitude harder.
Google knows and admits that their process has flaws and their HR team does internal studies on it. Just because Google does something, and Google is big, doesn't mean what they do is optimal.
> Believe it or not, you don't need to have passed the tests or have software development experience to make the observation that people complaining about a process are the ones that don't perform well
Actually you do.. It's one thing if you are upset about people questioning your credibility, but you are being disingenuous by making blanket statements with 0 credibility or evidence to back it up.
> only ever received complaints from students with C- grades or lower
I'm not sure what this has to do with anything being discussed. Are you implying that people with decades of experience being weeded out by these interviews somehow equate to C- grades?
By your definition, ideal0227 and mxcl are subpar.
> Google might not need you to code some efficient algorithm to search a b-tree every day, but they pay top dollar and can rightly expect that their software engineers can come up with efficient and creative solutions to hard problems without dragging the rest of their team down.
This is a non-sequitur. Being able to write good software has nothing to do with reading cracking the coding interview and practicing leetcode for an interview in an environment that bears no resemblance to how work is actually done.
But hey, that's fine—they just leave good talent for others to hire.
It still tests something. As long as it tests something, it is useful. If the candidates were stupid, they would not be able to play this (intrinsically pointless) Red Queen game.
Google has strong data that it does predict job performance, better than GPA, college degree and so on. What are your aggregate data showing that Google is wrong on this?
Does it? Because their strong data haven't helped them not screw up their messenger space. Or to have a fast email web client. Indeed, they seem to be going backwards on that chart.
They flopped on wave and Google plus, hard. Those are the kinds of mistakes that kill most companies. Even Google glass still somewhat rankles and has left me with no confidence in any of their consumer things.
And I say this as a happy Google fi user. In that I'm not convinced any alternative is worth moving to. Still can't fathom why Android is wasting fully half of my storage for "system".
I'm not claiming they are crap. But I do have a hard time making all the things they do that are beyond the industry. Other than spend a ton of money.
> their strong data haven't helped them not screw up their messenger space. Or to have a fast email web client.
That second example seems to invalidate your whole point, doesn't it? Yeah, they've had flops, but gmail has been an outrageous success, to the extent that more than a decade after launch it completely dominates internet email. I mean, yeah, I'm sure it could be faster (not a user, which makes me painfully aware of how rare my condition is!). But clearly they're doing this product "right" for any reasonable definition you want to use.
Gmail, the client, has gotten noticeably worse as the years have gone on, sadly. It is laughable how long I have to wait for the page to come up just so I can start drafting an email to my wife.
I don’t think those products failed due to poor engineering, google just hasn’t been great at social (if you don’t count YouTube). Other companies which use the same interview techniques are winning in those exact product spaces.
But, then what are they succeeding at? If engineering hasn't helped them not kill most of their products, what is it helping do?
And again, it is more than just social. ChomeOS? Even still a thing? How is android wear doing nowadays?
Again, I'm not claiming they are bad at engineering. I honestly don't feel qualified to judge. But I don't know that they are qualified to judge success of new hire, either. Their main success seems to be to simply suffocate the talent pipelines of the industry by hiring the top talent first. But not by actually using it.
> "If engineering hasn't helped them not kill most of their products, what is it helping do?"
Engineering does not set direction, they just build what they're told to. There are entire product management, market research, and similar teams that help senior management decide what to build. This is the case at most large software companies.
Yes, direction can be set independent of engineering. But a string of failures, at best, shows a string of misused engineering resources. Which just leads back to my challenge of why do they think they know what a successfull candidate is?
I'm questioning if they really know what good engineering is. I'm not saying they are bad at it. Those are two different claims
That they are the default entry to the web is their main asset. Agreed. Their search is good enough, and they are good at monetizing the top boxes of their search results. Really good.
That said, most of their engineering hires are not working on that. And they have a string of unfocused attempts at entering markets that smacks of not having a good sense of how to use engineering in a field. Basically, of they can't recreate the field, they give up. Rather quickly. That isn't engineering. That is just brash spending of money.
Why not both? It was a poor usage of engineering effort to try and recreate a field, instead of leveraging some assets and building on what they actually had.
It isn't like reader died alone. They had buzz going, which did a decent job of linking reader and Gmail. That is solid engineering. Instead, they have constantly tried to recreate Gmail to kill it. Wave? Plus? Inbox? I'm sure there are others.
Not defending Google, but this is dangerous myopia:
> Those are the kinds of mistakes that kill most companies.
All companies make big mistakes and burn lots of money on failed projects. The difference between a medium-sized company and a huge company is that a huge one can absorb the cost of failure, shrug and carry on. Medium-sized one will indeed die.
The difference between a large company and a huge company is that while both can survive the cost of a failed megaproject, for a large company the failure is probably enough to warrant a rethink and change in strategy. A huge company knows (from their aggregate financial metrics, of course) that what they are doing is right and proper, and will take the failure as just one more datapoint.
The moral is that there is no moral. (Or if we're talking business, morals.) Wild success begets arrogance, which begets organisational cargo-culting.
I'm not sure what the debate is. I'm all for changing strategies. My claim is that they don't have data on success from engineering. As evidenced by every pivot they have done being driven as much from marketing as technical.
Chrome, as an example, had a ton of marketing push behind it. Still some solid engineering, but not really any better than Firefox. Wasn't really any better than edge, but ms decided to drop the push for their own tech.
So, my question is what engineering successes do they have to back up their data on what will succeed?
I think you could pull in some of the ml work they are doing. Not sure how much data they actually have there, though.
My understanding is that they stopped asking brain teasers because they found no correlation with job performance. Which is good because for awhile it seemed like other companies were cargo culting questions like “why are manhole covers round”
What is "job performance"? I assume job performance in this case means getting promotions or good reviews. How well correlated are promotions to actual ability? In my experience they are mostly just political.
Google's 2013 study called Project Oxygen says different, "The seven top characteristics of success at Google are all soft skills: being a good coach; communicating and listening well; possessing insights into others (including others different values and points of view); having empathy toward and being supportive of one’s colleagues; being a good critical thinker and problem solver; and being able to make connections across complex ideas."
> But it is an undeniable fact that some people pass this interview process; software companies do fill positions with this process.
This argument is devoid of logic.
We could have an interview process where everyone runs a 100 meter dash and the fastest get hired. Some people would pass this interview process and get hired.
It's obvious that running fast is not a great predictor of success at software development. It's not obvious that passing l33tcode interview questions is a bad predictor of success; but it's not obvious that it's a good one, either.
You haven't made an argument for either case, here. Personally, I don't think it tests for much that Raven's Progressive Matrices wouldn't cover; but that's illegal, because it's too obvious.
I'm bad at taking tests. I'm also bad at playing guitar when someone is looking or even when recording myself (and pretty good when playing without anyone looking). I get anxious and self-conscious and that gets in the way of good public performance. This does not translate to public speaking - I'm pretty good at that, and I'm not afraid of audiences of just about any size - my largest so far was ~1K people.
I somehow managed to get a masters degree from the top engineering school in my country (with honors), and get hired at MS and Google, and a handful of other places, but that was in spite of my interview performance, not because of it. I've also failed a lot of interviews. I literally look and sound like an idiot when adrenalin kicks in, which for me it does at the most inopportune moments.
I very strongly suspect that there are _a lot_ of people who suffer from this. You can recognize them when they on the one hand have an illustrious resume and on the other suck pretty bad on simple coding problems. Those things are supposed to be mutually exclusive, and they usually are, except when the person's blood is full of adrenalin and they end up on the wrong end of fight-or-flight response.
If I spent 7 years as a SWE on high profile teams at Google it's pretty clear I know how to code, even if my interview performance on your Leetcode problem is not excellent. My C++ and systems design will likely be way better than all of your existing engineers, in a non-interview context, just because I've done a ton of both in an environment which expects excellence in both, and won't let you commit code if it sucks. 5 years after leaving I have not worked anywhere where this wasn't the case.
This is not the same, BTW, as "high pressure" usually encountered in the work environment. I can deal with that just fine. And I can code whatever algorithm you like in that environment, no problem. So I doubt a high pressure interview is terribly predictive of performance under "normal" levels of stress, too.
I'm the exact same in the guitar department, play a riff for 5 mins flawlessly, try to record it as a 10 second clip (or even try to put it on a looper), fuck up a couple notes in.
I also interview badly frequently but not due to poor test performance but due to my demeanor in an inherently awkward situation.
As I perform more and more, I realize the hard part is getting out of my own way. I fumble and stutter playing something when I try to think about what I'm doing, trying too hard to make it good.
I'm at my best when my conscious mind doesn't really know what I'm doing, and I trust the musical muscle to do what I feel which produces more emotional, more compelling music
You just described me haha. In my Google phone screen, I fumbled around on solving an easy-moderate problem - so much so that when it ended, I felt that there was no way even I would hire me. And once it ended, I wrote the code for it in probably 10 minutes. Also, arranging it so that it was the first in the loop did not help either. The only good thing about the process was that the recruiter was nice about the whole debacle and did not make me feel too embarrassed.
Reducing the emphasis on thinking out-loud every single one of your thoughts might have helped. I'm not the type of person who can verbalize everything and moreover, it's too slow and prone to errors. Perhaps I should have fought back and asked for the interviewer to be quiet and also let me be quiet for a while.
Also, the absolute requirement that any of your workings should be done only on the shared Google doc seems like an overkill. There are a lot of times when I wanted to quickly note down / draw something on the notebook I had but couldn't.
Unless your job is coding novel algorithm implementations under strict deadlines without a computer, how does answering this question in a job interview prove or disprove your efficacy in the actual position? It only proves you're good at interviewing, which, if you think about it, is not a desirable skill in your new hire 6-12 months down the road.
I see it as an IQ test. Official IQ tests are illegal for hiring of course. So they use algorithms instead. Not justifying it, but that’s the only logical answer I can think of.
Had to look this up, since I hadn't heard of IQ tests being illegal. It seems to me that a domain specific IQ test should be perfectly fine to use.
AFAICT the origin of this is a case from the 70s [1] where it was ruled against the use of IQ tests at a particular company. The reason was that the IQ test did not reflect an actual business need, but it made it harder for black people to qualify.
So making an intelligence test that actually relates to the work at hand, such as testing the ability to design algorithms as a programmer or the ability to comprehend text for a journalist, seems like more than just a workaround, it's a way to actually follow the intent of the ruling.
Just remember that Herbert Hoover was a terrible test taker. His colleagues vouched for his brilliance because they read his previous work and thought he was a genius. It turned out he was the type to spend a lot of time revising his answers until they were perfect, so under any sort of timed test he would fail, including his entrance exam into Stanford.
I'm only sharing that factoid because I find it interesting. Maybe Herbert was a terrible engineer by today's standards. He almost certainly wouldn't be president today for completely different reasons, but would he be have been accepted into Stanford? Would he even make it as an engineer? I don't know--certainly not if we put as much weight as we do on tests.
I’m a senior engineer with 20 years experience, I just delivered kubernetes into production at a Fortune 500 company. We wrote our own provisioner in go and our own controllers and built a system to manage add-ons. I know pretty much everything about running a cluster and have knowledge of most of the popular tools you’d install on a cluster.
I applied for a job at a Silicon Valley company to work on their kubernetes team. They talked to me for five minutes about anything related to my current job and spent 2 hours asking me to solve algo questions from cracking the coding interview. The experience was so bad that I basically am refusing to do any more interviews that require coding.
The hiring process at Google has a different function at a start up. Google needs to weed out hundreds, thousands of applicants and the good jobs people tend to want to stay in. Google needs to filter more than it needs to hire. I don't know why people see being rejected for a job at Google as a testament to their worth as a programmer.
People who see their worth as a programmer in creating good valuable software and are willing to sacrifice a lot for it tend to make startups. People who want to mark their skills as a programmer in receiving a large number of skills and working their way up to the top of the tree tend to join a large corp.
I don't get this comparative, 'my job is tougher' mindset. Resting your families' livelihood on the back of your startup programming skills is as pressure filled as being the backbone of a highly strung project in the heights of a large corp.
When the startup wins, the large corp licenses it. When the large corp wins, it opens an API to the smaller devs. Too much sour grapes around lately.
In regards to the Tosh quote, how many people at FAANG companies are using most of these tested skills in their day-to-day jobs, ever? This isn't about testing useful domain knowledge (except for the handful of people working on core algorithmic problems).
To a point these questions are an intelligence test but I see them mostly as a form of gatekeeping, seeing how many hoops people will jump through to land a job there. Most decent coders COULD pick up the knowledge to pass but not all of them want to, need to or are willing to grind through the test prep stuff just for the chance. And filtering for THAT has value because people won't grind through the process are less likely to hack it being smaller cogs in these behomoths.
I think the biggest value of the leetcode process is to rub off competent programmers who need to feel like their code is meaningful. Obviously many people produce meaningful code at FAANG corps, but working at a huge company means your code has a decent chance of never see the light of day or get chopped after 2 years, or be thrown out in some new broad initiative...
It is an effective filter for finding people who don't need external motivation to keep plugging on ahead. It is an important distinction because those types will likely flame out or start to wilt after a few projects of coding into the void.
It's worse than that, those "algorithmic" interviews are testing IQ, more-so than knowledge. The hard knowledge that is tested is pretty much only the syntax of the programming language candidate decides to solve the interview question with.
I put "algorithmic" in question marks, because those aren't even that hard as problems in programming contests or questions from uni comp sci coursework. For a phone screen with an online doc, it can be even something concrete, maybe implement a simple feature of a text editor (does not have to be as complex as the online doc the interview is in - it's important that the subject matter is easy to understand).
For an onsite interview, it would be something not likely to have been practiced in advance (questions leaked to websites get banned). Still, it would be something that reasonably fits in RAM, so there's no need to use a database or any networking technology (we can discuss those, too, just not necessarily request to use it in code - similarly, it may be taken for granted that the input data will be valid and there's no need to code defensively, the interview duration time is kinda fixed).
But as a policy we don't tell the candidates what their mistakes were, so those who failed may never know what they were up to. Goes without saying, we get to interview software engineers from different backgrounds - physics PhD s, or high-school IMO medalists, too.
I think there's truth to what you're saying, but I also think it screens out a lot of false negatives (which is kind of its intent since they'd rather that than false positives).
For me personally the process gives me a lot of anxiety/fear to the point where I won't do them even when I know I want to. I suspect a lot of the negative sentiment around interviews or talk about their 'ineffectiveness' is just this fear being poorly interpreted.
I think the technical interview process is also just a separate skill to master that has some overlap with programming, but is mostly getting good at leetcode style problems. It reminds me of things like the SAT for college.
There's a lot of failure necessary most of the time to succeed that I think scares people away because they do one and fail and then think they're not good or smart enough. I think I did ten different phone screens and three or four on sites before getting hired by a famous company. Some of those I totally bombed and others went really well - there's a randomness to it depending on the question you get and the specific interviewer.
I wish this wasn't the case and things were better because it'd be really fun to work on interesting projects with different people at different companies, but the barrier to changing is so tedious it's often better to stay put at a local maximum.
I suck at those interviews but here's a few real life job situations I've been in:
- sitting at my desk with the board of directors on speakerphone. They asked questions, I wrote SQL to find answers, while they tried to come up with a way to stop the company going bankrupt. Small company, I was basically the one guy who knew how the database linked together.
- sitting across the hall from a room full of support people while they went completely insane trying to answer the phones, and I tried to stay cool and calm while peer-coding with two others trying to get the system back up and running.
- having literal truckloads of garbage sitting in a queue while I debugged software that linked number plate recognition systems to a weighbridge and boom gate.
- being "that guy" who kept pushing for an early performance test. Eventually we did one. It went spectacularly badly. Some people wanted to blame me, because I was the one responsible (for the test).
In other words, being able to cope with "completely unexpected interview questions" and being able to cope with "code I wrote has gone wrong" are different skills.
I hear a lot of complaints about the "typical" software engineering hiring process, and it usually comes from the people that don't do well within the current system. Could the process be improved? Almost certainly, I don't think that anyone thinks that this is an absolutely perfect way to hire people. But it is an undeniable fact that some people pass this interview process; software companies do fill positions with this process.
So that kind of makes me think that many of the complaints are from people that wouldn't cut it at a high-pressure tech company and would be better off coding internal software for a non-tech corporation. I'm sure that the hiring process at Kroger (the grocery store) is much lower pressure than Google's. Google might not need you to code some efficient algorithm to search a b-tree every day, but they pay top dollar and can rightly expect that their software engineers can come up with efficient and creative solutions to hard problems without dragging the rest of their team down.