Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: