[TheCowboy]

This is a good question if your goal is to hire people who can talk a good talk about an unverified favorite project. It also assumes that someone has a clear favorite project ready to discuss. People who do not are put at a disadvantage. (Though I do understand this question is well-intentioned.)

The article doesn't really justify the process people go through as a good one. People who think they have a good approach to interviewing, but their sample size is too small to back it up or worse, present an opportunity to people who are good at telling stories but may not have the skills to go along with the story in the end. People who hire based on the story-telling experience will eventually get burned.

I think someone should read this and feel a little worried. This is story-telling. People who might argue that telling a story is being able to communicate---it's merely one form of communication of many that are needed depending on the work environment, and results in a blind spot for your team's hiring process.

[existencebox]

Having done many interviews, mentored interns and full employees, I'd argue storytelling is a _key aspect_ of performing our job in a larger team. Perhaps I'm being too liberal in my definitions, but I see substantial overlap between "talk about your last project" (and then digging into pitfalls, hacks, workarounds, conflicts; and mind you, I don't mean just PASSION projects, literally any work prior one can speak fluently on) and "tell me how you want to spec this architecture; why".

Much of how we discuss what we do can't be empirically precise, unambiguous, and scientific. Certainly the more social and abstract aspects of our jobs begin to sound, as you put it, like storytelling.

(To be clear, it's far from the only thing I look for, and can be taught/learned to a degree, but I consider it as a key skill in the broader bucket of "communication"; alongside problem solving and base competencies. And like programming itself, having some experience helps.)

[0xcde4c3db]

> I see substantial overlap between "talk about your last project" [...] and "tell me how you want to spec this architecture; why".

A major difference is that some people have deficiencies in autobiographical memory. This can make telling the story of a past project vastly more difficult than talking about a subject of current focus. An extreme case was recently described in Wired [1], but the ability is generally more of a spectrum.

[1] https://www.wired.com/2016/04/susie-mckinnon-autobiographica...

[TheCowboy]

As I mentioned, this is playing into the fallacy that telling a story during the interview is equivalent to the communication skills required for performing the job.

It confuses story-telling performance during an interview, and the stresses of a success/fail situation, with the type required to perform real work.

Mistaking "overlap" for all-encompassing. Sure, there's overlap. There's overlap in being able to type up a coherent response to a post on Hacker News, but it doesn't make me more qualified for your position.

It fails because it assumes that the candidate has a single defined favorite project. If you try to make the question more broad, then it becomes so open-ended that it is hard to equally compare candidates on it. It becomes random chance that a candidate discusses a project in a way conducive to doing the job. Where if more precise or structured, it might weed out people who can talk passionately about a personal project from those who can constructively explain to a manager the challenges of a project.

It also starts stretching it into saying that everything is story-telling so as to make the term meaningless. I agree it is to some degree, but it's important to try to stick with meaningful mental models that can make predictive assessments about candidates.

The huge problem is there are people without the skills who can tell a good story. This process let's these people through, while ignoring good candidates who may not perform well on this interview question.

[eropple]

I'm sympathetic to most of what you're saying, but:

> It fails because it assumes that the candidate has a single defined favorite project.

I...kinda don't want to work with somebody who can't read between the lines and pick one of their favorite projects when a question like this comes up. Social signaling and parsing are important to a comfortable and pleasant work environment.

[scient]

All I see here is excuses. A good software engineer has to be able to communicate freely and be confident and decisive in what they say. Asking a question like this expresses all of these things, and being an experienced interviewer also allows you to notice when its a little forced (when a person is very introverted), or when they are making stuff up (thats why you ask more specific follow up questions) etc.

I see more people having the skills but not being able to tell the story or communicate in a meaningful way. Seems to be a huge deal with software engineers, the communication piece is just disregarded in most cases. Thats when you end up with engineers who are locked away in their own rooms and not put in contact with any external stakeholders.

[TheCowboy]

To be a good engineer requires a number of skills. You named one. Knowing what arbitrary conclusion a random interviewer wants to hear and will draw is not one of those.

You can be a great communicator AND frequently not answer this question in a way that an interviewer wants to hear. There are more excuses for bad interview practices than anything else here.

People vastly overestimate their ability to detect lying and shouldn't rely on that. How do you know when someone fooled you? You don't. Why risk that when there are alternative and better methods?

Many engineers don't realize they are self-rationalizing their own interview process without any rigorous evidence. This is the opposite of good engineering.

[BurningFrog]

Being able to discuss design is an essential skill for programmers. This question gives you a chance to display that.

[TheCowboy]

This question too easily gives people a chance to NOT display that they can discuss design. But the question is not opaque if that is the goal. Look at all the responses to me from people deriving vastly different (flawed) conclusions.

The same vastly different interpretation of what you want to hear is going to happen with candidates. You're exhibiting poor communication if that is want you want to discuss.

[beamatronic]

I ask a slight variation, tell me about a project that you worked on that you enjoyed or are proud of. If they can't answer this it makes me wonder if they don't enjoy anything or are not proud of anything.

[TheCowboy]

"Makes me more wonder" is a euphemism for "makes me doubt their qualifications and abilities".

Some people are humble about their work and abilities. They will never exhibit open pride. Or they don't want to bullshit people and blow smoke up someone's rear. Some may want to switch jobs because they are forced to do poor work and know they shouldn't feel proud about that.

This is probably a 'flaw' I have, but I'm aware of it that I know what I'm expected to sound like when asked this question. Now I'm put in a position where I am being dishonest. You're now testing my ability to BS you to get what I want, and by my nature I am already uncomfortable with BS'ing people.

Now compare this to the person who is too incompetent to not feel pride in the shoddy work they do.

Now the enjoyment part. I can talk about this extensively, but enjoyment is subjective. I could enjoy working on something because of the challenge of the problem, or because I was part of a great team, but it still doesn't speak to my ability to perform the job you have.

[scient]

I don't see this as being humble, I see this as a lack of confidence in their skills and abilities and achievements. These same people, for the same reasons, are adverse to avoid making decisions and second guess their work, which causes delays and communication problems.

Instead of trying to make this into an excuse of being humble, it should be acknowledged as a lack of a certain important trait.

[gknoy]

> I see this as a lack of confidence in their skills and abilities and achievements

Given that imposter syndrome is well-documented in our industry, it's quite possible that I've done cool things, or impressive things, but not realize that they are cool or impressive because I am in awe of the awesome developers I work with.

Combine that with most of my work being something like "I added new features in our Ember app, and fixed bugs in the UI and backend", and it often is easy to feel like the day-to-day work I do isn't awesome, even if what I am building is (IMO) pretty cool.

[scient]

But if you think the stuff you work on is cool, why can't you express that feeling by telling it to someone else? Because you lack the confidence in your work, which is the exact problem.

The interviewer should not change here, you should change to be able to convey your work and why you think its cool etc. Thats exactly what the interviewer is looking for.

[Verdex_2]

I'm 30% through writing a 10-20K word blog series about something that I've been working on for the last 6-8 years. I've probably written ~5K words already on blogs unrelated to my series where I'm kicking around the ideas that went into my project. Finally, the project probably isn't that interesting unless you've encountered a very specific type of problem before. Which means I probably should put in another 5-10K words to market it.

Sometimes it's not about confidence. Sometimes it's about complex social dynamics and how people react to suddenly being thrown into the deep end of a domain that's completely new to them.

"Tell me about a technical challenge that won't make me feel inadequate or be difficult to follow. Don't make it too simple though because then I'll think you're an idiot."

Ah yes, just be confident. That's the ticket.

[braveo]

No, they're honest.

It's amazing to watch you bend over backwards to try and vilify a person who simply strives for accuracy.

[ryandrake]

I've never thought that was a fair question, because it's actually pretty rare to be able to work on something you enjoy and end up proud of. The way I see it, one of the reasons I'm interviewing with you is that I hope that the best of my career is ahead of me, and that the project I'm most proud of is the one I'll be working on next.

[eropple]

I ask a variant of this question when I interview, and if you said this? I mean, people vary, but I think this is a totally valid and good answer. Because I have a lot of shitty gigs in my past, too--the signal that "I'm moving on because I want to work on things I'm proud of" is a pretty powerful one. (It's gotten me gigs before, too.)

[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.