[dahart]

My anecdata with hundreds of interviews over the years is that getting people to talk about their projects is the single best/fastest way to verify their involvement and knowledge of the projects they list on their resume. When someone can't elaborate on what they did and why, or what problems motivated their work and what they learned, it's a strong indicator that they are puffing up the projects/keywords on their resume (which is super common) but didn't actually learn much.

Moreover, getting people talking is a great way, in my experience, of identifying strong thinkers, strong coders, and strong experience. It helps you see someone's personality, it helps you literally get to know them. I can't think of any reasons why I would worry about that before hiring someone. I would worry about not doing it.

I would like to know what you would offer as a better alternative approach? Do you prefer the idea of coding questions to stories?

[TheCowboy]

What percentage of bad hires result from your approach vs. other approaches you've tried that have failed? If you even did know that, how is this not randomness in a small sample?

This ignores the problem that if someone can elaborate, it's not necessarily an indicator. It can just mean that someone can BS well. Relaying too many specific details can actually be an indicator that someone is not telling the truth.

"Getting people talking" is really the only way you can identify these things during an interview. And this is not the same as telling a good story. And now you have to demonstrate that this results in job performance.

On here, tptacek has exhaustively described an alternative approach: https://news.ycombinator.com/item?id=9159557

[dahart]

I've never hired someone who's been fired, and I've had to fire other people's hires, so I think my process works okay on some empirical level. I do not defend my approach as scientific or perfect; it's not, and I never claimed it was. But I have verified my approach by asking follow up questions with people who seem to signal they're inflating the importance of items on their resume, and found that my detector was working.

> Relaying too many specific details can actually be an indicator that someone is not telling the truth.

This is actually not true and has been scientifically demonstrated. I listened to a podcast about this, and lies come out with a measurably, detectably reduced vocabulary versus true stories. Let me see if I can find a link to it...

But I also don't care whether it's true because your base assumption is that you shouldn't trust anything anyone says. My experience is the polar opposite: most people interviewing for jobs aren't primarily bullshitting, they are by and large telling the truth, and all I need to do is determine which candidates are better than other candidates, not which ones are lying.

Most of the resume inflation I've seen isn't a case of intentional BSing, it's a case of inexperienced people not knowing how little they know, and assuming that a month of JS or SQL during a summer internship puts them in roughly the same camp as someone who's done it for 5-10 years.

Talking that out with people has and continues to give me a pretty good idea of what they know and don't know.

BTW, I don't see anywhere that @tptacek is countering what I've said. If you read what he said, he mentions using conversation to filter people multiples times. Here, for example: https://news.ycombinator.com/item?id=9159959

No interview process is scientific and perfect, and you shouldn't expect them to be, that is unrealistic. There's nothing wrong with realizing it's a social activity and not an algorithm, that it's an art and not a science. Learning how to be good in interviews by understanding what interviewers are looking for is part of your job, not a way to gamify the system and trick people into hiring you. Another part is being a good coder. Both are important.