Google admits brainteasers were useless for hiring (2013)
qz.com
qz.com
1. It's good that companies like Google are able to reassess their hiring policies and learn what works and what doesn't. It's easy to criticize companies for doing things that don't make sense or that we know to be bad, but often these things looked like good ideas at the outset and you need some amount of trying new things (many of which won't work out and may have negative consequences) in order to improve things.
2. The way hiring works in tech isn't really that bad. It doesn't really measure what matters for job performance but tech pays well and so many people want to do it that you need barriers to entry. The real losers of the hiring process are the companies that waste lots of money on inefficient hiring practices. If you compare the effort required to get a high paying tech job (really just doing practice problems for a few weeks/months) to any other high paying, professional field we have it much better.
As to "you don't have to do it again every time you switch jobs", nurses are often required to go through continuing education just to keep their licenses current. But making the jump from one type of nursing specialization to another, or even upgrading from an RN to a BSN (often required today if you want to keep your job - probably the exact same job that you've already been doing for ages) can be quite grueling - almost like starting over. In one recent case, a well-respected fellow nurse upgraded her education only to be to told that even that was no longer considered sufficient. She was already doing management-level work but didn't yet have the official title or the pay, and was told that she needed to go up an additional level in education in order to get that, so she just bailed - decades of experience walked out the door for no good reason.
I continue to be shocked that software developers aren't licensed at least like RNs or CPAs are.
I think it is generally accepted that licenses don't signify "quality".
What are you hoping to gain with a license? Some badge that somebody can show to a prospective employer, so that they don't quiz you on capabilities?
I think we can agree that the field and knowledge required to perform as an RN doesn't change that often and the same goes for CPAs. However, the world of software is changing constantly. How could a licensing process ever stay up to date? Sure we could just test CS fundamentals and give people a stamp -- essentially what a degree is supposed to do. But if you're a software developer, like myself, that has interviewed many people and been subjected to many interviews, I know it's not a perfect process, but I've come across people that have exaggerated their abilities on resumés. One of the great things about software is GitHub, Bitbucket, etc. Why? Because it sometimes provides a window into the work of a developer before they make it on-site. I'd be happy if the industry as a whole just accepted this as the resumé and leaving the in-person interview as one that's non-technical, save for maybe something like FizzBuzz.
From my perspective, I think the idea of licensing is just an okay process for other fields. Without an interval of re-testing, how can we ensure that service providers can still deliver? I have friends that work at medical centers with doctors that have been there for decades that seem to have forgotten a thing or two, but refuse to accept the answer to a symptom or problem that is fresh in a new or recent grad's mind that's had fatal consequences. It's sad.
What a great idea! Let's call it a degree
Admittedly, the data is a few years old (and I didn't want to pull the same data from the 2018 survey), but such a requirement would put many people out of a job. I also haven't seen any concrete data that would support any correlation between the efficacy of a software engineer and whether they had obtained a college degree, so this seems like a poor metric.
I share your incredulity regarding the lack of any sort of "occupational license" for the industry, though I remain unconvinced that instituting one would have a positive effect.
[1] : https://stackoverflow.blog/2016/10/07/do-developers-need-col...
As more recent examples, a few years back I took all three of the original free MOOCs from Stanford. In the ML class, Andrew Ng at one point said something like "If you've ever taken calculus then you will recognize this particular equation as being a derivative; otherwise don't worry about it because that's not really important." Later he said something similar about linear algebra and matrix multiplication. And indeed I had taken both calculus and linear algebra back in the day so I recognized what I was looking at, but it just wasn't important within the context of that advanced class.
I also took the Database MOOC, and during that the instructor taught quite a bit of formal database theory. (I forget the proper name for it.) But despite having worked with databases for decades now I've only seen such theory referenced maybe twice, and that just in passing, so it's hardly the "critical, need-to-know" stuff that the instructor insisted that it was.
Meanwhile, in the AI MOOC almost everything taught there was new to me, despite my having taken several AI classes back in the day; so basically zero overlap between then and now. (I did recognize some of the statistical stuff, though, from my statistics class way back when.) But will any of the new stuff ever be of any practical use to me? Probably not. Interesting certainly, but probably not at all practical.
So perhaps, California would have the highest standards with Google/Facebook employees pushing them to do so to create barriers to entry, but Mississippi would end up with the bare minimum.
I wouldn't find it terrible if Software Engineering were licensed, in the same way that law is---with the board consisting of prominent practicing members of the existing population, and all current members grandfathered in so it only affects upcoming generations.
But this is idle wishing: the current system likely has to much inertia for real change at this point.
Just pretend you went to law school and have to make monthly loan repayments each month. Put that money in bank account and you will have more than enough savings to take off work for a month every few years.
Median wage for programmers is nearly double the US median household income and has few barriers to entry. If the only downside is having to take a month off work every few years, I’m not complaining.
Edit to add: In general, I don't think our system has to be worse than all others for it to be worthwhile to consider what might be better.
It's a rigorous exam, but to me, this is so preferable to a 5 hour interview on differential equations, stats, and linear algebra every time you interview. And that's pretty much what we do in software, it's the equivalent of asking a senior actuary to do an integration by parts or a complex derivative at the whiteboard during an interview.
What I also like about this approach is that we'd avoid that situation where a cartel like the law schools can put a 150k, 3 year degree in between talented people and the profession they'd like to enter.
Another thing is that tech exams are very capricious - you can end up with a totally unqualified interviewer, there's really no quality control on the questions or how the exams are administered. A more formal exam could have a lot of benefits, though I do agree that a required long degree program that is $$ would do more harm than good.
EDIT: There's is something that causes me to question some of what I wrote above - I have grown wary of many of the people who want to regulate software as a profession. I'm still stinging a from my collisions with the test-driven development crowd dating back over the last decade. They really were saying that to merely question the value of the methodology should render you un-hireable. Imagine if they got control over formal licensing. I do shudder at the thought. When I think of that possibility, the Wild West approach, unsavory as it may be, seems more appealing.
It is a very different set of trade offs than what we have in CS, where companies are more than willing to take a chance on bright people with non traditional backgrounds, including people that never went to college or dropped out. As a lifelong self-learner, I’ve certainly appreciated the lack of “credentialism” at tech companies.
The one part of the PE thing that I would like to see borrowed is the exams. If all companies are just running everyone through the same kinds of general CS problems anyway, might as well save everyone time and improve consistency by making a standardized test.
A month off? I completed an MSCS (including a thesis) while working full time with two young children at home (my daughter was born in between my first and second year). I can't imagine educational/licensing requirements that would be more difficult than that; you can continue your education without dropping out entirely.
As for government work, I'm not sure where you got that idea from. I did government work for 14 years and never needed any certifications. If I had, the company would have paid for it and it would have been on company time.
Sure, there is some noise; papers get rejected where they should not have been. And other papers that should have been rejected, do get in, etc. However, by the time you're applying for a professorship, you're abilities should clearly shine through that noise.
I'm not intending this as an indictment against academia. They're faced with a hard problem: many more candidates than job openings. They couldn't possibly do whiteboard interviews like in software, just because of sheer logistics. I don't know how academia could do it differently. Software can do it better because there's a LOT more money in software.
Being smart and knowing your areas are only some of the requirements for being a professor. Having just those two is insufficient.
If you look at the batch of assistant professors that start every year at good schools, did they pick the wrong people?
There's no implication that the letters are obtained unfairly, but that doesn't necessarily mean that the resulting outcomes are fair. The point is that if you find yourself in a situation where you can't get hold of these things and yet you are, in fact, really good, there's nothing much you can do about it short of waiting a few more years and hoping to build up a better professional reputation. In contrast, you can just show up at a coding interview, demonstrate that you can in fact code (at whatever level is required), and land a job.
Case in point: I moved from academia to coding by doing this (without any relevant qualifications or having worked professionally as a software engineer). There is no equivalent progression for someone who wants to move to academia from coding.
Prestigious invited talks don't come out of the blue, but usually as a result of consistent work that people care about.
If a researcher can't get their papers published, in an activity where that is a key metric of success and the key communication medium, what's the basis of the 'really good' assessment?
Look at the list of keynote speakers at any major conference you understand. Are those the wrong speakers? Did they get this privilege unfairly?
Every job application process has its own kinds of luck and failure modes. The time scales of academia lead to very different distortions than those in software engineering.
I don't understand your rhetorical questions. Clearly, yes, conferences choose bad speakers sometimes.
I readily agree these selection processes are not perfect, and institutional nepotism in particular is an issue in academia.
You can get a coding job just by acing a coding interview (and having basic social/professional skills). So this part of your comment did appear to suggest that merely publishing papers can be sufficient to obtain an academic position.
What possible reason would I have to interview someone if they had neither relevant experience, nor a degree? Should I just ask random people I see on the street to come in for an interview?
If you're talking about people who have no experience in the sense that they've never written a line of code, then no, obviously not. But professional experience and relevant qualifications are not necessary.
As with any job application, you need to have something going for you. It just doesn't have to be any of those two things.
The other losers are people who have skills and aptitude that is actually needed, but don't have the thing that interview measures. Yet other losers are people forced who have to work with those who ace interviews and get rewarded, but are not actually good in actual work.
The side note is not just that hiring don't really measure what matters for job performance. It is also that companies themselves don't really seriously care about it nor spend time thinking about it. That affects not just hiring, but also promotions and other rewards. Which in turn causes additional problems and unhealthy workplaces (excessive crunch being one of those, huge amount of socialization that is expected in some companies another, ridiculous technological decisions too and so on and so forth).
But, I also think that it will end up split into different kinds of interviews for different positions. The older I am the more I believe that there is no single "good in tech" aptitude and that such notion is nonsense. Rather, different tech jobs require very different amounts of abstract thinking, logic, patience, memory, aesthetic feel, detailed knowledge of some sub-area, ability to communicate, self control, punctuality and so on and so forth.
You can be quite crappy at assembler and heavily talented for enterprise java for example. You can be good at smaller projects and completely fundamentally fail in large codebase many people situation.
I agree also in theory, but as you said there are vast differences in speciality. Some programmers are far more product focused and have an eye for design and communication, and some only do well when they're deep in the weeds of some obscure perf optimization. The latter gets hired quicker, while the former can often do a lot of useful things for an organization.
So here's the selfish-as-a-hiring-manager side of not liking the current style of interview questions: I don't want my bar to be so low that studying for a few weeks or months is all it takes.
One or two medium-level problems to make sure they're not full of shit about being able to write code at all, sure, but the rest is gonna be a lot more targeted to the role.
For anything non-trivial, as your code grows the amount of time required to understand it will grow too -- even if you're using "standard" frameworks, etc. -- because the business logic driving your design decisions is learned with experience. For example, we have a guy at our large company who's a terrible programmer but we keep him on the team (albeit somewhat quarantined) because he's been there forever and has enough institutional knowledge to be valuable.
As your systems grow even more, there will not be off-the-shelf solutions. You'll have to sit down and do some real-life architecting and that won't be learned in 2 weeks. Even if you could perfectly document all your systems and design intentions (you can't), well documented decisions still take time to be read and "soak in".
Or maybe it is easier in large code bases because the worst programmers fail? I don't know, I haven't worked with many tiny code bases.
The challenge I'm still facing is crafting interview questions that most effectively match those two-week impressions.
My issue with purely sticking to coding questions is that I've seen a handful of people study enough to nail those and then be completely uncreative or unmotivated beyond that. Specificity seems to be a key thing in other types of questions, to at least weed out the hopeless. You built this thing? You had that experience? Tell me the details. Tell me the details of those details. Etc.
One of the things making it hard is that the true standouts are rare enough that I've only hired a couple of them, so it's hard to find what's meaningfully shared between them that's identifiable in a single day.
I'm not sure how you could have confused what was posted, to be interpreted that way.
You made up a question that wasn't posted. Please re-read the thread. Please don't attribute your words to someone else. It's transparently dishonest.
* Electrical Engineer - 95,230 USD
* Chemical Engineer - 97,360 USD
* Mechanical Engineer - 83,590 USD
* Biomedical Engineer - 86,220 USD
Software engineers are paid well, but there are definitely other engineering fields beating them.
Petroleum engineers, on the other hand, make 100+k in pretty much any region.
The point of this final exercise was for me to talk through my thought process. It was a debugging problem, and I eventually succeeded, but not without fumbling around for 15 minutes or so. The solution was a stereotypical example of being "right in front of you", but the nature of this exercise threw me off. When I look back, the analogy that makes the most sense to me is the boxing glove wall from the TV show, Wipeout [1]. It's a simple problem of getting from point A to point B with the twist of getting punched in the face, or the stomach, or the leg, at seemingly arbitrary intervals. I can see this as a good simulation for the reality of an engineering job (being faced with unplanned interruptions and having to bounce back from them) but, at the same time, I've never had to verbally talk someone through every keystroke and mouse movement that I make while debugging. I was frustrated with the exercise and with my inability to immediately diagnose the issue. The interviewer was amazing at getting me back into the right mindset after noticing I had fallen off the wagon each time, which showed me just how good of a manager they were. However, the more I realized how terrible I was doing, the worse I performed. I left with the unmistakable feeling of dread having set-up camp in my stomach. Despite arriving at the solution, I knew I had blown that exercise.
In the end, I was turned down. The official reason was that another candidate had accepted an offer for the position, but the hiring manager also told me that my programming skills were perceived as sub-par due to the final exercise. They said I'd be a great fit culturally, and that their team enjoyed the conversations we had, but my Python skills just weren't good enough. Being someone that really identifies with their abilities as a programmer, with Python being my language of choice, this verdict has kept me awake at night. I'll never know if the actual reason was due to the other candidate accepting or due to me being my own worst enemy during the final exercise.
The tech hiring process is one of the only times I've gotten 100% of the problems correct yet still failed. Half of me says that's bad, but another part of me understands in situations that require context like mine above. It's not the manager's job to babysit me when I psych myself out, or when I'm having a bad day. Engineers need to be reliable and stable enough to work efficiently on their own. Had I been alone, I would have found the solution much quicker. But you're almost never alone in a real work environment. Some of these exercises are measuring much more than just algorithmic competency.
My hypothesis is that the bar is still too high and that if you have a basic technical baseline you'd still perform well regardless of your white-boarding abilities. Google could run this experiment and in fact they might already have enough data to answer it with a causal analysis.
The key issue is how do you define "performance" both in the interview and in your yearly review... nobody has a clue how to actually measure performance.
http://www.businessinsider.com/how-google-hires-people-2013-...
In this case though, how is 'lots of money' wasted? It seems that Google hired good candidates despite some of the questions being bad. I think the point here is that Google is looking to increase the efficiency in interviewing, but they're already at a high efficiency level anyway so they continue to be successful in attracting and keeping talent.
What if instead of reading resumes/interviews/whatever else they did they just put all the names into a hat and made offers to everyone selected? This is your baseline, does your process beat this? If not, you could save a lot of time/effort using the hat selection method. (note that it is possible to be worse than the hat method)
But on the off chance you're 8 years behind the times, it turns out that those infamous brainteasers were completely useless for hiring at Google.
I would even hypothesis that an ideal web community in the vein of reddit or HN is not completely void of reposts. There must be some ideal percentage that makes the site most useful/successful.
Don't know where on the number line those figures land, but sharing something that crosses my mind when I see a repost. HN seems to have a decently low number, IMO.
Fast forward to it today, we have huge amount of prep materials and prep schools, so it becomes hard to tell who's truly talent and who has great memory. Google doubled its workforce in the past three years from 35,000 people or so to 70,000 people. You just can't expect that everyone is passionate and talented about math or engineering. Besides, Google does not need too many of this kind of people either.
However, if a small company is tackling a hard problem that does require tons of math, computer science, or pure ingenuity. Hell ya, brainteasers can be of great help. They don't even need brainteasers, they can just directly ask math problems.
Yes, if the job requires tons of math, it makes sense to ask math questions, it doesn't necessarily mean that people who are good at brain teasers will be good at the job. According to the article, what google found in regards to asking brain teasers:
>...“We found that brainteasers are a complete waste of time,” Laszlo Bock, senior vice president of people operations at Google, told the New York Times. “They don’t predict anything. They serve primarily to make the interviewer feel smart.”
Weird tricks in bit manipulation, linked lists, array, hash problems etc. are all standard in interviewing and are still used, even at Google, at least 2 years ago, when I last interviewed there.
This works though as Google's, and the industry in general has a policy of rejecting candidates, rather than accepting them, because hiring is very risk-averse. Candidates switch jobs frequently at the beginning of their career and so there is a rotating pool of good candidates the companies can pick from.
Those are problems that you either know the "trick" or you don't.
The main problem with the majority of them is not the problem itself. The main problem is that originally they are meant to understand the process of problem solving of a candidate. However, as they are passed among interviewers, they become an "solved or not solved", because it is the path of least effort.
I once created a problem that I love to ask in my interviews, it deals with binary search to get the total elements from a list that is only avilable through a "broken" API. A lot of people I interviewed told me that they loved the question, however, when some colleagues started adopting it, I realized that they were basically expecting the specific answer they knew... when the real value of the exercise is to work with interviewees to "solve a problem together".
It is kinda at a certain level in your career you are expected to just know how to do it. For other skills like management, you at least have your peers who are doing the work day in day out, who you can learn from. Interviews are closed room, usually, though I have had some where one person was shadowing the interviewer.
Also, if you take a terrible interview, its not gonna really impact you. There is no performance report that'll negatively impact you. There will be another candidate, who you'll have a rapport with. Or someone else will interview someone else.
As you said in your anecdote about the binary search problem, not everyone is best at being an interviewer.
But aside from there being a dedicated person for interviewing for big companies, or outsourcing interviews for startups, I don't really see a solution. And outsourcing, whether internally or externally comes up with its own set of problems.
This is something that I have ameliorated in my teams in the following way: When an Engineer is going to start interviewing people he goes through the following process:
0. Before starting, we provide some guidance on what we look in interviews and what we ask (1 hour meeting with the new wannabe interviewer and the manager)
1. First he shadows an interview done by a Tech Lead or Sr. Engineer (those are the ones that generally do the interviews)
2. Then he does two interviews, where he asks the questions but is shadowed by a Tech Lead of Sr. Engineer. He gets feedback about his interviews and is asked to explain his feedback and we tune it to the expectations from the team.
3. Finally he starts interviewing people on his own.
This has worked well enough for me, specially once we had a shared GDocs with a) The list of questions to ask (along with notes on what to look for and how to guide guys) and b) A "competency matrix" ( like http://sijinjoseph.com/programmer-competency-matrix/ ) tailored to what we were looking for.
Finally, one of the things I always emphazise the people that is interviewing for my team, is to remember how they felt during interviews. And be aware that as interviewer ALWAYS you have the upper hand. I hate being interviewed, I hate the feeling there, and the fact that you have 60-90 mintues to demonstrate that you know what the company is choosing to ask you, without regards of all other stuff you know that will be useful for the position, but they don't ask. And the nerves.
With face-to-face tell them to bring their laptop or you can provide one, then explain a real actual hard problem you've solved or one of your colleagues has, that took roughly 2 hours, leave the room and let them try and solve it on their own accord without any pressure of people staring at them whilst coding. Come back and ask them to explain their solution and quiz them on different parts.
This has been by far the best test I've given that predicted real on job performance.
Is it just me? I feel like I've always had good reviews but I struggle to answer questions like these in interviews.
If you ever interview with me, be aware that I'm only allowed to asked from a pre-selected list of this type of question. PLEASE PLEASE PLEASE spend time thinking about your situations the day before! I expect to come with about 5 scenarios in mind that you can then twist to be the answer to the questions I ask. Come up with some situations in advance, you don't want to have to think of them on the spot. (actually you will have to think them up on the spot, once you get past the first question you will relax and be able to think on your feet better - for some questions a new situation will then occur to you on the spot)
I know you had to work with a difficult person in the past, remember something that happened. Don't make that person look too bad - you don't want to come as bitter so select a different situation if that might happen.
I know you had to make a decision without enough information. I know you had to do something controversial.
When I'm interviewing I'm only allowed to write down and consider The Situation/Task, your Action, and the Result. (This is called the STAR system, there are other variations) If you can make sure I clearly understand each that is to your benefit, though I will ask clarification questions to get that.
Research says that it is fairly easy to tell if someone is fabricating their situation (I've never caught someone, but I've only interviewed a couple people so my sample size is not significant). Thus I as an interviewer know you are telling me how you react to a real situation when under stress.
You have been in many situations over your life. Don't bring up ones you don't want to talk about.
I don't agree that it is easy to tell when someone is fabricating, if that someone is a proficient liar then it will be impossible, and that is the exact type of person you want to exclude from further consideration.
I'm not sure why I struggle to answer these questions. Maybe I could be better at telling stories.
On the other hand, I feel like it could be more to do with my ability to talk about myself. For example, when asked of my major achievements and challenges, I think of scenarios where we over came problems as a team. I think more in "we" than "I". I feel like many of these questions are looking for answers in the form of "I did all these amazing things".
Further to that, maybe I just don't rate myself as much as I should do. In the past, interviewers who spend the time to go deep have historically said something along the lines of "wow, you've done all this. Why didn't you tell me earlier". I had one person say "It's like getting blood out of a stone". So maybe I need to be more self-promotional. Gotta back yourself right?
Beware of this though. Some companies will say they value teams, but the reality is they do not. Others value it so highly they hide that, lest you hide that you don't work well with teams but need the job enough.
If you're someone who's been a technical manager for 5 years, and I'm asking you about, say, a time you had to give (or receive, for that matter) negative feedback, then if you've never had to do that I might question the breadth of your experience and readiness a bit.
I think the key here is to be very specific about the type of situation you're looking for, and to ask a bunch of them to get a broad look at the person's experience.
I actually like this type of question either as being interviewer or the interviewee. At least it allows me to demonstrate the thought process I put into a problem I actually encountered instead of talking about stuff I never had the need to do like a lot of algorithmic stuff.
They don't know what cache is or how to tell when you've run out of it; can't use pointers, can't write a loop; don't understand object lifetime or that objects have one; or think a null pointer is, or should be, the same as an empty string. (This last is most amazing because it seems to be official policy at Google!)
The elementary coding and debugging exercises that are so annoying are necessary because most candidates, by far, can't begin to do them -- MS:CS, real-time OS thesis project, and N years experience notwithstanding. What have these people been doing?
I have seen brainteasers used well, but only as a jumping-off point for a conversation that tends well away from the puzzle.
I used to use a design problem (no coding) that bright undergrads solved in two minutes, BSes in five, MSes in 20, and PhDs either never, or as fast as an undergrad. Everyone who solved it used identically the same hand gesture when describing the solution.
ITA Software used to publish great programming puzzles that you were invited to solve and send with a CV. (Google bought them out and eventually took down the puzzles, back in 2010, but they might still be in wayback). To learn how your solution compared to theirs, you had to send it! It might not work so well anymore, since everything gets posted nowadays.
Imagine a binary pass/fail test that determines your future, next to a suitcase full of cash, clock ticking, and another developer watching over your shoulder, also feeling smarter because they already know the answer. An answer they researched in solitude at a leisurely pace.
Conclusion: "We can't find any qualified people, there must be a shortage."
The timed HackerRank and such sucks though. Way too stressful. And easily subverted. They enforce fullscreen but you can just use another computer to look things up.
I wonder if, comparatively, other fields have as many "fakes" as I've seen try to get jobs in mine. I'd say 1/20 candidates I've interviewed aren't imbeciles.
Maybe I didn't write clearly enough, but the reason you are attracting so many "fakes" is that you are testing for "nerves of steel" rather than coding ability and misattributing a lack of the former with the latter.
We also guide them and give hints and encourage interaction, or if they need to think we leave them alone.
If that requires too strong of nerves, uh, oh well I guess. I don't know how else to judge their technical ability and soft skills.
My employer now works with contracting firms where about 80% of the candidates they send us are excellent and we hire. The interview is almost a formality. When we reject a candidate, it's usually because the candidate is a bad fit for the job. (Edit) The rejects are always very talented and would succeed in different assignments.
When we hire for employees through a recruiter, the process is much harder. Most of the candidates recruiters bring us are, to put it mildly, horrible and incompetent. (Edit) The recruiter doesn't really filter for competency.
The medical profession has an industry-wide certification process. I wish we had the same, because it would be easier to filter out the morons.
Most of the time, when a company needs to develop software, it doesn't make sense to hire all developers as on-site, full-time, permanent positions.
Some people are only hired for the project and go away when the project is done. Those people are hired through a contracting firm; and the contracting firm finds them employment when the project is complete.
For us, it's easier to "hire" through the contracting firm because they usually worked with each other in past projects. A recruiter has very little direct experience with a candidate.
Ironically, things would be easier if recruiters always sent us "formality" interviews and the contractors needed tighter screening. This is because it's easier to hire a contractor for 3 months and choose to renew the contract.
The title is disingenuous, and implies that Google switched tactics after finding out that these questions were not useful, whereas in reality Google never started doing it because they found that these questions were not useful.
(Source: I did interviews at Google pre-2013)
In the end every company becomes average because there is only so many people they can hire. This has nothing to do with brain teasers per se.
I’ve worked in tech for over 10 years and I have to say the places I did the best work are interviews I somewhat bombed. Not a surprise!
I would be interested in knowing if anyone is hiring based on ability to do Fermi problems. I see these as not being about knowing a "trick" but about knowing how to utilize your own knowledge, which is a much more general capability.
I've conducted loads of interviews at Google since 2012 and none have included a question like this from myself or any other hiring committee members. IMO the questions about what they do for fun are way better at determining if they'll fit and do well.
I've conducted loads of interviews at Google since 2012 and none have included a question like this from myself or any other hiring committee members.
Hm...Sounds like a paradox right?