You know, I was nodding my head in agreement as I read this when something occurred to me.

This all requires that the interviewer be willing to interact deeply with the candidate. Our profession has a (well deserved, I think) reputation for having a high percentage of people who really don't like interacting with others on a peer level.

Is it likely that a large part of the problem is that we have people doing interviews who really shouldn't be? I mean, if your typical response to talking to another technical person is immediately to try to one-up them, then you're going to be a really shitty interviewer. And that's exactly the personality type I see being described over and over in these anecdotes.

> if your typical response to talking to another technical person is immediately to try to one-up them

The psychological reality behind all this is even worse.

The interviewer is not looking for new colleagues, he is looking to improve his own self-esteem and rank. The reward for rejecting a candidate is a feeling of superiority and an appearance of being irreplaceable.

The interviewer and the candidate have opposing goals, and the interviewer can randomly change the rules at any point.

Ugh, that's horrifying. I don't think I've been the interviewer and not felt the exact opposite, like "I'm desperate to have more people on the team ASAP; do we satisfice here and make it work or hold out?"

But then I've always been interviewing for my own future colleagues/boss/reports. I guess the dynamics could be different if you're in a huge company and just generically interviewing for new cogs that might get slotted anywhere.

I'm in semiconductor design not software but my goal is always "I've got way too much work, is this person good enough that after a few months of training they will be able to do some of my work so I can get more sleep?"

If the person is smarter than me even better! Instead of spending time teaching them maybe I can learn from them and get into their network so that if I ever need a job in the future they can help me out.

this is very well put, indeed both parties are set up to fail: - the interviewer has an incentive to fail the candidate, whereas the interest of the employer is to actually hire someone eventually.. - the interviewee is rated on something that has little resemblance to the actual job (difficult to succeed when you're not told what the admission criteria are...).

Not sure about English, but in my language we have a saying "The fish stinks from the head"

I can tell you, with quite substantial sample size from me directly and from people I deeply trust that every time we encountered an interview like this, we later found out that the company culture was really bad.

Those are not the kind of people you want to work with.

> Not sure about English, but in my language we have a saying "The fish stinks from the head"

English has this expression too, except it's "The fish rots from the head". (Which, when you think about it, makes more sense.) What's your first language?

For clarity, is the "like this" in your comment referring to brain teaser technical one-upmanship interviews, or the less structured style that is focused on getting to know the person and having them describe in their own words the projects in their past?

I was referring to this:

> I had a similar interview with a different company last year. Three guys and me on a Zoom call with me sharing my screen trying to solve a coding problem that in no way resembled anything I have ever encountered in my 25 year career. When I got stuck they just stared at me. They would not give me any hints whatsoever. They just stared at me.

Some years back I wrote a post about interviewing, from the point of view of the _interviewer_. I emphasised that during the interview, the candidate is the most important person in the world.

It only later dawned to me that our industry has a non-trivial fraction of people for whom empathy is a foreign concept. They're not sociopaths, because those folks can at least feign empathy - we're talking about individuals who can't see themselves in another person's situation at all. On top of that, we don't really provide actual interview training to engineers either. Out of all the people I personally know in London, only one (1) has received formal interview training.

Is it any wonder that the interview gauntlet is such an awful experience for pretty much everyone?

> I've never understood the heavy emphasis on in-interview coding or brain teasers.

Here's why https://blog.codinghorror.com/why-cant-programmers-program/

I guess, but I would hope that kind of thing could/would be smoked out in the course of a discussion following these kinds of prompts:

- Tell us about the approach you took with the take-home coding challenge. Why did you break up the functionality in the way that you did (modules/classes/functions)? What kinds of constraints or requirements would cause you to make a different call here?

- Tell us a debugging war story. What was the bug, how did you discover it and come to eventually understand the root cause? Any challenges with reproduction? What steps were taken to prevent it from happening again?

- Pick a feature of XXX programming language and explain how it contrasts with approaches taken in other languages. What do you like about it? It is more productive, efficient, safer, more explicit? What are the tradeoffs and how do you balance these? What kinds of projects would have you prioritizing using a language/ecosystem with this capability?

Someone incapable of writing a fizzbuzz program is not going to be able to bluff their way through an interview like this. Obviously you need to be committed to listening and exploring the space with the other person as opposed to flexing and looking for the "right" answer, but that's just part of the discipline of being a good interviewer and not a jackass.

I have found that a 30-minute discussion on a random variety of technical topics (including questions such as those posted above) is sufficient to determine whether someone has required technical expertise.

Coding exercises entirely miss the point, because writing code is the easy part. The hard part about good software engineering is being able to rapidly acquire problem domain expertise and knowing which engineering design choices enable rapid, scalable, and maintainable development to solve the problem. That's why companies using code exercises to screen candidates are generally not worth the interviewee's time to work for - it indicates that the interviewers don't understand the problem domain, either, and (by extension) that company is mired in mediocrity.

I've had code exercise interviews. I'm quite happy that I have never had to work for one of the companies that used them. I have never given a code exercise interview, and I've been quite pleased with the candidates that have responded and worked with me.

That seems like a reasonable approach if you have the right skills for it. My problem with such an approach would be that I'd not feel comfortable to make an overall evaluation of a person based on a short interaction. Having a clear cut process with well defined metrics provides me with more confidence that I'm evaluating candidates fairly. Without it I'd be worried that my rating would be too biased by superficial stuff like how they dress etc. Something that at least in psychology research seem to mbe a lot more common than many people think. In general, looking too much at cultural fit would feel I'd risk "hiring my friends" rather than based on what value they could contribute.

That is a risk, definitely. And I think that kind of thing is probably in part why Google and others who followed them ended up where they did— wanting a system that was completely impersonal, quantifiable, and which could be said to be 100% meritocratic.

Which is noble, I suppose. But clearly lots of people still felt that it was unfair and alienating; closer in spirit to a hazing than a good-faith evaluation.