I work as a software engineer, and I absolutely abhor these "brain teaser" style interview questions.
I agree, I call them "stump the chump". If there was any empirical research showing any any predictive power at all between the ability to answer these questions and future job performance I'd love to see it. If you screen for people who are good at answering stump the chump questions you'll end up with a company full of people who are good at stump the chump questions. If that's your industry, spectacular. Otherwise, ? In fact interviews themselves have empirically been shown to have shockingly little predictive value on job performance, we just flatter ourselves as interviewers into thinking we have this remarkable perception that allows us to determine a person's ability to do a complex job after spending an hour with them. The literature shows that interviews succeed only at very basic tasks like determining if a person can speak the workplace language fluently and is able to handle basic interactions with another human. That's it. So that's all I use them for.
The purpose of brain teaser type questions when I give them to candidates isn't really to see if they get the right answer but more so how they go about it and how they approach problems. A lot of these brain teasers aren't really the types to be quickly solved (unless the person has heard of it before in the past) but it does give insight into how people would approach a new problem. There are generally two types of programmers that I've dealt with in projects -- code monkeys and solution architects. Not everyone likes these type of questions, but I find them to be more valuable than asking someone to go up to a white board and write down a program from scratch.
I hear that a lot, and would buy it if there was any evidence for it. I happen to know a few folks whose brains are wired for this kind of thing and can do a great job of going through the approach and solving a novel version of such a problem. At least 2 of them would be the absolute last person in the world I'd hire as a software dev, they're an total mess when it comes to applying that same logic to real world problems. Until you show that people who can reason through an egg drop problem make good solution architects, you're testing for one thing while looking for another. Why not just test for what you want, and in the same manner that the person will work...in my company's case where-ever and whenever they want to over the next couple days on an actual problem we've had? That takes 5 minutes of my time to explain the problem, maybe 10 if they have questions. And a good developer will gladly put in a couple hours to come up with a good solution vs spending that same amount of time sending out resumes, composing cover letters, explaining the difference between C++ and C# to a headhunter, solving egg drop problems in interviews......
That's a fair question and I agree with you. Unfortunately, sometimes the people tasked with hiring others doesn't always know the full details of what the company wants. At one point in my career, I was asked to interview candidates for a new position opening up and I didn't get much info on what projects they would be working on -- it was upsetting to me because this was new management that had come in and the previous status quo had been thrown out the window. At the end of the day, I'm sure you can agree that when you interview people, you generally get a solid overall impression of that person after spending a couple of hours interviewing them. I've made errors in the past with hiring someone that was over-qualified and then they got bored and quit which ends up costing the company 5-10k in hiring expenses.
Many years back I was interviewed for a software development/network admin role in London. They allowed me to take the software portion of the test home (which included a bubble sort question in VB6). I got that job and enjoyed many years with the company. When I decided to leave and went through the process of interviewing candidates to replace me, I was gobsmacked at all the chancers and also how aggressive the recruiters were with their candidates! I bent the rules a bit in my initial interview but nowhere near the level of some of these clowns. The one guy said that my interview was the most difficult he had ever been through and I was not even doing anything to catch him out! In the meeting room we had a white board and I got the candidates to do all the talking, using diagrams to explain things. Thats the best way to gauge someone and you can usually tell really quickly who knows their shit and who doesn't. Some of these guys would pull in with MCSE, MSCD, CCNA and lots of other fancy jargon on their resumes. I would start by asking them to draw a diagram explaining the most efficient way to setup a network in support of our team of devs with Exchange, SQL servers, IIS, Firewall config, replication across our different sites, backups and whatever. I didnt care what they believed was right or wrong because there are many different ways to skin a cat, but I was interested in the thought process. Most of the 'qualified' ones crumbled, and I swear out of like 50 candidates only about 2 seemed to actually know there stuff.
Your flaw is disregarding people who have enough knowledge and expertise, maybe even more, but who do not have the communication/manipulation-skills that 2-5% of any population distribution possess.
Possibly. The role required good communication skills though as it was a pressure environment supporting a team of experienced developers. Introverts would have been trampled.