[wpietri]

> Some people are really good at interviewing and being charismatic enough to convince people to hire them.

Totally agreed. Traditional interview processes select for people who are good talkers. That doesn't correlate well with technical skill: you over-hire glib people and under-hire people who aren't. E.g., the shy, awkward, and anxiety-prone.

When I run an interview process, I focus on making it as much like real work as possible. Some pair programming, some technical discussion, some joint product collaboration and systems design. It's my firm belief that if we want to know if people can do a thing, we should try doing the thing with them. It's not perfect, but it's way better than asking people about their 10-year career plan or having them solve Mensa puzzles.

[Pokepokalypse]

>Traditional interview processes select for people who are good talkers. That doesn't correlate well with technical skill: you over-hire glib people and under-hire people who aren't. E.g., the shy, awkward, and anxiety-prone.

This is true: but "technical skill" is not the ONLY hiring criteria that should be considered. (I say this as a fairly shy, awkward and anxiety-prone person, who has had his share of interviews-gone-wrong).

I'd posit that you DO want to hire people who are good talkers, and are glib. They help build teams. They help with information flow. The greatest ideas in the world are worthless if they can't be executed by a team that doesn't understand them, and the person who came up with it can't communicate that idea effectively. One might say that that is what code is for. But that's not true. If code were to communicate between the developer and the machine, we'd all be writing in machine language. Code is a communication tool for developers to collaboratively tell the machine what to do. And that has to be supplemented by human, interpersonal skills. (especially when you have collaborators who are not coders, like business and finance people who organize the teams and manage projects and programs).

I like that you focus on pair programming. One horribly toxic factor I see at way too many places is where management pits programmers against each other like it's some kind of competitive sport, and collaboration is frowned upon because "if you can't figure it out by yourself, you're a burden on the rest of us".

[wpietri]

I am certainly not arguing for only hiring based on technical skill. Perhaps you didn't get the chance to read all of my comment, but I make it clear collaboration is important. I'm also not totally sure you know what glib means, so I'll just quote the definition here: "fluent and voluble but insincere and shallow".

Basically, I think workaday collaboration and communication is a pretty different skill than on-the-spot glibness. If I'm hiring a PR person or a press secretary, glibness is a valuable skill, because an important part of their job is to talk over people, to favor sounding good over consideration or substance. But for a software team, I value more substantial engagement and communication. So no, I'm happy to hire people who are not glib. Have done before, will do again. And for those who do happen to have the gift of gab, I want to be sure they have it in check and only deploy it when necessary. A colleague who can say, "I don't know" is way better than one who glibly avoids that out of pride.

[cutemonster]

> A colleague who can say, "I don't know" is way better than one who glibly avoids that out of pride

An interesting interview question could be to study the job applicant's background and then ask questions that, given the background, s/he doesn't know -- then, will s/he tell you this, or make up nonsense