[berdon]

That's a myopic and emotionally charged way of looking at it.

When I interview people, I ask straight forward, probing questions looking for how the candidate approaches the problem and the path they take to the solution. I don't ask trick questions, I don't mislead the candidate, and I help them as much as I can to get to a solution on their own. However, I look for and probe for information throughout the process. It's relatively easy to discern whether someone knows what they're talking about and can apply it versus someone who crammed for the interview. Moreover, if someone did cram for the interview and was able to apply the knowledge that quickly - great, I want to work with people like that.

Had someone asked me to implement a JSON parser in brainfuck - I would have got up and left. More generally - if someone asks me to use a _specific_ language in an interview; it's not someplace aware enough to know that 99% of the time the language is unimportant and not somewhere I want to work.

With all that being said - technical interviews are not "the worst thing ever". They serve a vitally important task of ensuring I work with competent and personable people.

[optimuspaul]

> That's a myopic and emotionally charged way of looking at it.

sure is emotionally charged, but I don't know that it is myopic. I have thought many many years about the contents of a technical interview. Taking a step back from the argument I recall decades ago noticing that, I believe it was the bureau of labor statics, software programmers are considered "unskilled technical labor." I was initially offended by this. I have now come to the realization that this is generally true. Skill is not required to make software, nearly anyone can do it. Leading back to the argument though, what makes someone good at being a software developer is not technical skills. It is general competency, critical thinking, and being a good communicator.

> Had someone asked me to implement a JSON parser in brainfuck - I would have got up and left. More generally - if someone asks me to use a _specific_ language in an interview; it's not someplace aware enough to know that 99% of the time the language is unimportant and not somewhere I want to work.

to be fair that wasn't the exact request. It was more along the lines of "using whatever (approved) language you'd like, implement x with that assumption that your base language can only loop and increment." x in this case was something like do division. Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.

> With all that being said - technical interviews are not "the worst thing ever". They serve a vitally important task of ensuring I work with competent and personable people.

was definitely hyperbole, but my point is that a technical interview doesn't serve the purpose that you lay out for them being vitally important. A non-technical interview is far better and easier to evaluate a persons competency, problem solving, communication, and "personable people".

Point being an entry level person with competency and problem solving skills can be taught technical skills very quickly and/or learn as they go. Non-entry level, well, their resume should tell you they have the technical skills assuming their references check out. So I really think we should stop wasting time and talent on "technical interviews"

[berdon]

> to be fair that wasn't the exact request. It was more along the lines of "using whatever (approved) language you'd like, implement x with that assumption that your base language can only loop and increment." x in this case was something like do division. Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.

This sounds like a great interview question. It calls on the candidate to show they understand what a turning complete system is and then put that knowledge into practice to create the fundamental building blocks that are normally given to you.

You used hyperbole to make it out to be something it definitely wasn't.

> Which I know is possible, but also something I would never need to do and as such the solution wasn't immediately available to my brain.

In fact, you do need to do it, you needed to do it for an interview. The fact that you see it that way might underscore a personality trait that the interviewers might not have liked. Thus giving credence to the interview process immediately.

> A non-technical interview is far better and easier to evaluate a persons competency, problem solving, communication, and "personable people".

No it's not. It's far better at providing a "comfortable" place for someone to chat without actually proving anything. A good technical interview is problem solving _with_ time to chat and prove understanding of concepts.

> Point being an entry level person with competency and problem solving skills can be taught technical skills very quickly and/or learn as they go.

This is clearly false otherwise we wouldn't be starved for competent technical candidates. There're thousands of companies looking for qualified candidates and they can't find them.

> their resume should tell you they have the technical skills assuming their references check out. So I really think we should stop wasting time and talent on "technical interviews"

Resumes are worthless - doubly so now that politicians have made lying OK. The majority of people I've interviewed lied on their resumes, either as small white lies, or as large ones. And personal references are also garbage - there was a recent radio host that called random numbers and asked for a "reference" for a candidate they were interviewing. People went out of their way to talk up the fictional candidate.

> Leading back to the argument though, what makes someone good at being a software developer is not technical skills. It is general competency, critical thinking, and being a good communicator.

Yes to critical thinking and communication. You just aren't going to get a good read on a candidate without asking thought-invoking questions. You've either never had a good interview or you don't interview well and disparage the process to feel better.