I think it's possible--but there was an experiment someone ran a few years ago with a guy applying to jobs in both software development and management (while qualified for both and resumes optimized for each). One of the key differences that was found is that software developers essentially started out at zero and every wrong answer / misstep essentially reduced their score. For the management interviews, it was tougher to answer something wrong, but each good answer earned points.

It naturally results in software developers feeling like they blew it, but managers just wondering if they wowed them more than the other candidates. To me that suggests it's something more inherent to software developer interviewing than a frustration bias. If I had to guess, it's just that aspects of software development are more measurable than in other roles, and there's more genuine fear of hiring someone who can't fizzbuzz.

I remember one of the other key takeaways was that the manager role was treated more favorably--specifically that they apologized they could only offer some (reasonable) amount of relocation assistance while none was even offered in the developer role. It was theorized that managers were seen as an "in group" among other managers, but that was obviously just speculation.

I wasn't on HN at the time, so I can't confirm it was here. It was one of those blog posts / write-ups that made the rounds.

I always hear this fear proclaimed but have never heard an actual story of a candidate failing to fizzbuzz, would love to hear an anecdote or two from anyone who has one.

There's not much to say really. I think people for like me who get very nervous at live coding interviews, the variation between best and worst performance can be massive.

In every case it was because they over-complicated things. They came up with elaborate logic that they didn't need and then got lost and didn't quite get to a working implementation. Picture, say, starting to implement fizzbuzz using two tries and an associative array.

I would guess that a lot of the people I've seen bomb these kind of interview questions are actually good, capable programmers, but they just got overwhelmed by interview nerves and got lost.

They were great people, but couldn’t distinguish a string from an int.

I really cannot imagine why people have this behavior. I was often treated unfairly in life, so I try to architect systems that attempt to avoid my perceived unfairness so that the next generation does not have to suffer similarly (ideally in way for which correctness can be shown in a mathematically rigid way).

But seriously, I agree with the top comment about interviewing at Google, and as far as the military academy "hazing" it's generally misunderstood. It's very, very rare for an upperclassman at my particular school to be cruel in the movie-sense, or what I think is the stereotypical fraternity-sense. More common is an institionalized set of standards for the freshmen that may seem overly tough or even arbitrary but serve several purposes: a) they give the freshman a crash course in being accountable for details, b) they give the upperclassman a crash course in enforcing accountability and holding others to high standards, and c) they create a sense of shared hardship and camaraderie. These are actually all very important lessons before a second lieutenant takes on responsibility for decisions that could mean life or death for his or her soldiers (which, in the case of my graduating class, was a reality for us as quickly as 4 months after graduation). You have to force the upperclassmen to come out of their shells and make the freshmen wear their uniform correctly, or make their bed correctly, etc. so that when they graduate they will have the courage to tell their soldiers that they really do need to inspect the vehicles, or maintain the weapons, or wear their safety gear. It takes practice to be accountable for standards on a team. It's not supposed to be about making people suffer for the fun of it, but of course there are jerks everywhere.

That, in a nutshell, is why a lot of abnormal psychology is so very sticky. It's even worse than that, however. It's more that most people are just a tiny bit "like that," and no one thinks about it from that perspective.

Or in the words of the freemasons, order through chaos.

Once hurt, few seem to have enough integrity to break the loop; so it snow balls nicely all by itself.

In that moment, you face a choice. Either you do the same thing that was done to you, or you don't.

If you break with tradition and avoid doing whatever it is, you will end up asking yourself why, and you'll have to answer "because it was abusive". It some cases, that thought may be too horrible to even admit into your mind, or at least it's unpleasant enough that you prefer not to deal with it.

If you go the other way and stick with tradition, then you can just do whatever it is, and you can say this happened to me, it's normal, it's part of the natural cycle of things, etc.

Also, sometimes you are blindsided by this and don't realize you're making the choice until the moment it happens, so you don't have time to mentally prepare to do the harder thing.

Point being, it's not always sadism. Sometimes it's denial.

TLDR: The corollary of "that would be abusive" is "I've been abused". It hurts to confront that possibility, so people look for ways to deny it. And the organization offers them one.

I interviewed maybe 3 or 4 years ago at Google. Definitely got some questions that were not remotely programming related, but were just hard problems that probably were awesome if you already knew the answer.

I recall one was something along the lines of "You're making a bet in the final round of Jeopardy. Presume that your opponent is going to bet optimally given your bet. How much will you bet?". No matter what I bet, he bets such that if he gets it right and I get it wrong, he wins by $1, etc. There were different cases to consider, but all the hard ones boiled down to what felt like a differential equations problem.

It wasn't a programming question; it was a logic brain teaser question. And the interviewer seemed to really enjoy himself.

Didn't get the job. I now ignore Google recruiter emails.

Arrogant? Maybe I am, a little, sure. But I don't spend my days remembers every minute detail of every technical documentation I've come across -- I can't remember everything! What I _do_ instead is remember _how to recall_ technical items in specific contexts to quickly refresh and remind myself when the time comes.

I don't come across _too_ many arrogant or clueless interviewers, but when I do I am genuinely surprised.

I had an interview there recently in NYC. I solved the guy's puzzle too quickly and I think that he thought that I'd prepped (I hadn't). Then we got started on a different problem and I tried to explain how it was a good example of "boolean blindness" and that using a specific form of dependent type was an ideal solution. He looked at me like I had two heads and smugly told me that it's impractical to solve problems this way (but it's a bog-standard type checking problem).

So yes, smart people, but you should know the bias that they have before you decide that you want to work there. It could very well be bad for your career if you _do_ get in.

I will say that out of my loop, there were only 2 interviewers that came across as intentionally mean, the rest were genuinely wanting to see how I solved problems and understand what my thought process was, which is what most interviewers should be attempting to assess.

The intentionally mean ones need to be culled from your interviewer pool though. Does it really do a service to Google or to the candidate to stump them, and also humiliate them for not knowing the answer you were hoping to get from them? There are ways to make a candidate feel good about failing an interview despite not making the hiring bar.

And remember, these candidates are still your customers, and human beings. They will remember how they were treated.

      number of people in the world
    / average number people per piano
    * average number of times a piano is tuned per year
    * average amount of hours to tune a piano
    / average number of hours a piano tuner works per day
    / average number of days a piano tuner works per year

       people
    -> pianos
    -> piano tunings per year
    -> hours spent tuning pianos per year
    -> workdays spent tuning pianos per year
    -> piano tuners

Just to plug in some random numbers, let's pick 7 billion people, 100 people per piano, 0.3 tunings per year, 1 hour to tune a piano, 3 hours of tuning per day and 100 days per year(I imagine it's part-time for most piano tuners...). We arrive at:

    7,000,000,000 / 100 * 0.3 * 1 / 3 / 100 == 70,000

I've never had one of these in an interview setting, but I imagine the important thing is to demonstrate the line of reasoning rather than actually arriving at a concrete number.

Might seem weird but it is massively useful. Having an educated estimate that is _only_ out by an order of magnitude is a massive improvement over wild-ass guesses that are 4-5 orders of magnitude off -- especially in systems design where over- or under-provisioning leads to millions wasted in effort.

BI had an article about it as recently as 2015. https://www.businessinsider.com/google-brain-teaser-intervie...

Depending on your applicant pool, that might be correlated with a protected class, like race, gender, or national origin.

That puts you in a mindset to run the interviewee through a gauntlet, partly as a ritual to show their desire to get in, and partly through a sense of duty to hire "only the best".

But hiring is not a filtering problem. It's a matching problem. And the more interviewers embrace that they're there to find the right people and to recruit them, not to filter people out, I think the more humane the interviews will be.

For a small company whose culture is in flux and needs the right person, it's absolutely a matching problem. You need to find the right person for the job, period.

At the scale of a company like Google, however, it's absolutely a filtering problem. First off, we're large enough that most (perhaps not all) people talented enough to clear our interviews will (given enough persistence) find a place where they can be happy and contribute. We can get away with not worrying about the subtleties of matching and instead only focus on technical skills.

Second off, the number of applications rejected for every hire is staggering, simply because of how many people apply. These numbers are fantasy, but imagine if you had to choose one person out of a hundred applicants, and you actually had the means to interview every single one. You're going to pay this person a quarter of a million dollars a year and aim to keep them for half a decade or more. The economically rational thing to do is be picky as all hell, and this is exactly how Google and friends do it.

That's a good point. It's hard to ignore just how many applicants you filter out in the hiring process. However, Google and Facebook are exceptions in terms of having a non-differentiated hiring test. They are very big exceptions, but still exceptions. They have a standard interview bar and matching with teams comes later. On the other hand, Microsoft, Apple, Amazon, Samsung, Adobe, etc. all hire for specific roles.

I think the way to reconcile the nuance I was getting at with "matching problem" is this: "picky as all hell" must still be fair and backed up by a clear idea of why your requirements are as tough as they are. When you see yourself as a gatekeeper you're more likely to lose sight of that.

Which is unfortunate. To measure something, it's necessary to test to the boundaries of its ability, which basically means crossing eventually into the realm of failure.

Too much of testing both in education and in job interviews is oriented to get a pass/fail result. Interviewers should understand that a good interview is not like this and should communicate this to the prospect: the goal is to measure your abilities and compare it to the needs of the position. Answering well for the most part, but not remembering some obscure academic topic or missing a particularly difficult part of a logic problem means that part of the interview helped find that boundary.

Honestly, if you answer 100% of the questions in the interview it means that they don't know how good you are, what they should pay you, or what you can expect to be challenged by in the job. They will want to know how much more they should offer and ask if they can take on much more difficult projects, but they don't know how much. That's an interview failure by the interviewers.

That's a very rare individual. I've been on both sides of the desk a lot, and I don't think I've ever run into anybody like that.

The much simpler explanation is that being an interviewer is hard and takes work and practice like any other skill. The problem is that nobody ever applies actual work to interviewing.

Did somebody let you watch their interviews before letting you interview somebody else? Did somebody watch your interview to give you advice for what you did wrong and right? Did you ever role play being an interviewer? Do your interviewers occasionally try to calibrate themselves to other interviewers?

I can count the number of people who can answer "yes" to even one of those questions on one hand without using a majority of the fingers--and that's over my entire career.

After doing my fair share of interviews and sitting through a ton of debriefs, I'm pretty convinced that getting hired boils down entirely to the loop you get. Some poor bastards get the wrong people -- people who either want to prove their smartness, or simply have out dated ideas -- and that's that. Didn't use inheritance in your system design? Well you got Bob instead of Joe. Bob loves old school OOP and thinks composition is a character flaw. If you got Joe, you'd be in, but... alas.

No amount of "calibration" solves bias.

Nah. I've interviewed at a lot of places where I sort of enjoy the opportunity to demonstrate my soft skills. I can't say I'm looking forward to my FB & Google interviews(quite the opposite). My Amazon interview experience absolutely sucked(not a single question relating to the job, stupid algorithm gotcha questions).

Most companies, IME, are much easier. For instance, there is a large media company which pays competitively to FANG companies and the only thing I need to do to prep for the interview is memorize the algorithmic cost and backing algorithms of the common C++ STL container classes. For my current job(arguably not the greatest gig), I had to demonstrate my knowledge of Python, C++, kernel programming and networking. I know those things, and enjoyed demonstrating that. I enjoyed talking about my past work. My biggest worry was choosing the button up shirt I was going to wear. That's how interviews should work.

My current gig interviews were all deep storage strategy conversations and hard in the sense of needing to show a lot of knowledge articulately. I left there feeling really good if exhausted.

My Google interviews were hard in the sense of embarrassing regurgitation and thinking nonsense on one's feet. Hard was being made to feel inferior.

I had an interview experience, where the interviewer was looking for a particular answer. I give him 3 answers to his design issue. Then the interviewer says he was looking for the 2nd answer I gave him, as if I didn't just say it.

It's one thing to reach and fail. It's another thing to be in a context where the truth of what you know doesn't even matter.

I think the next time I see it, I'm just going to question whether this is how they behave in their job too, even if it means ending the interview right there.

How is this distinguishable from the interviewer hearing something from the candidate where an understandable reaction is to stay silent and look dubious? I've had candidates try to tell me something like: a null pointer member of a struct in C++ takes up no data. The first part of what you described was my natural reaction, not a hazing strategy. (I then went on to ask if they were sure about that.)

The warm up question was difficult and I was completely embarrassed that I didn't some it right away. As I walked out I knew for certain that was not a warm up question and was pissed that he had consciously shaken my confidence right off the bat.

How do you know it wasn't just a badly written question? Interviewing is hard in the same way that teaching and writing is. It's hard to put yourself into another person's shoes. Never ascribe malice where incompetence is a sufficient explanation.

At least at google i got feedback, audi did not. No feedback after coding project and 2 interviews sucks hard...

As an interviewEE , though, feedback is essential to improving and definitely reduces the sting of a failed interview. (My sample size of both sucesses and failures is small but feels huge anyway).

I've been flat-out accused of cheating and bald-faced lying, on scant evidence, when I was clearly doing neither. I very strongly suspect that the interviewers were motivated by their ageist prejudices in that case. I also have a very strong feeling that your intuition about the interview process is correct. I've done a bit of introspection and realized that there is a bit of dark side in me which can come out in situations where I wield power.

Also, and this is probably more specific, there's a bit of a mythos around companies like Google and friends that have tough interviews and high standards: they hire the best people, they're doing the best work, they're the smartest, etc. I can tell you from experience, that mythos doesn't hold up once you're doing you day to day job. I've seen people with stunning credentials doing what most would consider exciting work become genuinely bored.

There's a class of real world activities of substance and significant consequence where one encounters, "long stretches of boredom, punctuated by moments of terror." Lots of development also falls into this category. You spend a half year, doing basically nothing but "fixing bugs in a CRUD app." Then, there's a high priority bug where error dialogs pop up for a whole bunch of high profile enraged users who quickly and definitively figure out they're being lied to by the system. The logs and HTTPS proxy captures tell you contradictory information, and you discover that some vital logging information is getting swallowed by lazy coding. Then the logging system goes down, staying down for weeks. On top of that, someone breaks the development debug build. All the while, director level execs are breathing down your neck. I'm not making this up. This actually happened to me.

Most of the time, the job can involve almost nothing, then all of a sudden, you need more than your wits about you. It's for times like that, that one seeks to hire people who can actually apply knowledge, as opposed to those who regurgitated it on an exam then promptly forgot it.

"Can you estimate Google AdWords revenue for Italy - B2B?"

(For the record, the person you originally responded to did not share that question with the intention of you actually trying to answer it. The point was the illustrate how ludicrous some of those questions are. You don't have access to any of the information that you mentioned in your response in the interview.)

“With ~50M people capable of clicking ads, and assuming they click one ad a day at 20cnt CPC, it would be around 3.6bn. I think my assumptions are on the high side, but order of magnitude is probably correct”

If done well, solving a problem (not a brain teaser) together can yield insight in how people approach new challenges.

If I’m hiring for someone to do what they already know this indeed not a useful question. on the other hand, if I expect the role to tackle various business problems as well I’m not sure what would be a much better way to get a sense on this. (Specifically because I’d want to discuss a not-too-complex problem that is outside your usual area of expertise)

In any case I don't think it is about the calculation or the final number. It's really the approach that you develop that's interesting.

I've seen this mostly used in (management)consulting though, where you actually are regularly expected to solve problems that you might not have deep understanding of. When I was interviewing developers I discussed how they would architect an application to solve a specific problem. It gives similar insight and is closer to the actual job.

The reason is that to many people (myself included) your answer above is nonsensical.

  “With ~50M people capable of clicking ads, and assuming they click one ad a day at 20cnt CPC, it would be around 3.6bn. I think my assumptions are on the high side, but order of magnitude is probably correct”  

I'm all for "first-principals based structured thinking" but asking someone to demonstrate that by generating a rudimentary formula, that won't survive any contact with reality, and populate it with almost completely random values, seems like a weird way to go about it.

E.g. someone who guesses "$3 billion" on only a gut feeling likely wouldn't be a strong hire even if the number is correct, while someone who can correctly decompose the final answer into its components and make reasonable estimates would be a much better candidate.

For estimation interview questions, and problem-solving questions more generally, a "structural" approach to breaking down problems is important because on the job the interviewee will need to be able to identify what levers are available to them.

The only thing changing are parameters.

EDIT: it was for the Search team, search spam prevention, can't remember role it's been 4-5 years, sorry.

I interviewed at Google earlier in my career. In one of the interviews, the interviewer asked me to recite/reconstruct off the top of my head the convex hull algorithm. I remembered the lectures in undergrad algo class where the professor talked about it. I remembered where in CLRS it was covered. I remembered the general outline (efficient algorithms are O(n log n), because you have to sort the points as one of the steps). But I was struggling to remember the details, because, you know, I hadn't worked on that sort of thing in several _years_.

So, the interviewer started pacing around the room, impatient that I couldn't remember the details (or recite in 10 minutes what it took a professor with notes 2 lectures to go through). He told me finally "We expect Google engineers to be able to solve problems. What if you were a Google engineer, and you had to solve this problem, what would you do?"

There is, of course, only one right answer to that question, which I provided: "I would look it up in a book. I know exactly where to find it." I wouldn't spend time trying to reinvent an algorithm that someone else had already thought of.

The interviewer did not like that answer. I did not get a job offer. Now that I interview candidates at a different large tech company, I make a point to not get hung up on things that are easily researchable.

Well... I might ask one of the other people on the team (or in the company) for some help. Because I'm probably going to ask one of them for a review (or someone else will review it anyway). No man is an island, etc.

What did Sergey and Larry do to solve these problems? They hired more people!

Expecting people to know and remember beyond the basics is simply ridiculous especially at the age of Google

Sounds more like he expects Google engineers to have perfect recall, rather than to be able to solve problems.

That's just a trivia question, nothing to do with problem solving.

It's not perfect, but it seems as close to the actual work experience they are interviewing for.

I interviewed at Facebook recently and was shocked when they used Coderpad but did not allow code execution. Threw me for a loop, because I like to decompose problems and test that everything is still working as I add to it, something this did not allow me to do. I consider that a GOOD quality, why prevent me from demonstrating it?

Failure come in three types - bad understanding (failure to understand the problem), bad planning (plan doesn't actually solve the problem), and bad implementation (failure to implement the plan correctly). The third type includes typos and off-by-one errors that I don't want the candidate to get hung up on. I might ask about an issue if I spot it, but if not I'd rather keep going on the more relevant parts of the solution.

Also, you can leave part of the solution in pseudocode without getting distracted by a bunch of squiggly underlines, and handwave away parts of the problem that we don't care about.

"I would Google it", and this time the answer is very corporate! Still not what's expected by the interview, but it would be funny to watch him argue that the main product of its employer is not qualified for the task.

Besides, I find it silly too to ask for details that are easily found in printed material, with less probability of mistake than remembering it.

At that point - he's talking to you as if he thinks you have the understanding of a child, basically.

There really is no positive recourse available other than to politely end the interview, and chalk up another day of your life (plus N days spent preparing) that you'll never get back.

Also add another factor - Google's approach is (or at least was) in the words of Google's big HR guy: "A good rule of thumb is to hire only people who are better than you." (https://www.businessinsider.com/how-google-hires-exceptional...) Such approach naturally brings out the worst in the people conducting the interview - their high opinion about themselves. Mix it in with the stuff you mentioned - buried frustration, latent meanness/"narcissism and sadism" - and you have the perfect "Google interview" :)

This also explains when people chew out service workers for petty things.

I worked retail management while finishing post-grad work to pay bills. People who were loud and awful always had something else in their lives that was making them mad - broken down car, not much money, shit job, etc - and they used the retail employee as a punching bag.

I never saw one person who was loud have a reason to be loud other than that. In 10 years.

I think it has more to do with impostor syndrome and a fear that a new person will expose them as the frauds they perceive themselves as.

In my experience, sometimes that fear is justified. The people whom I've run across who are the most condescending to engineers who "haven't proved themselves" often have the most lax coding standards on the team. They're often the ones who build Rube Goldberg programs and who never document their work - you can't be replaced if nobody knows how your core programs work.

Out of curiosity, how is this controlled?

If the committee sees a brainteasers, disagrees with a question, spots inconsistencies in the feedback, etc., they moderate their use of the feedback or ignore it altogether. There's also a mechanism to send feedback to the interviewer, which they can use to let them know a question is appropriate, banned due to having leaked, etc.