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