[scryder]

I think you may be overthinking how seriously your interlocuters take interpreting the behavioral questions.

The vast majority of CS interview questions are really just one or both of two categories:

1. Say something entertaining or that makes me like you.

2. Say something that proves you're competent so if I like you it's not a hard sell to hire you.

When you read this hard into a question that can in this framework be reworded "talk about stuff you programmed that you thought was mentally interesting when you made it", they truly only are thinking about your skills at the most basic surface level, they really just want to let you gush for a minute.

Even in the most embarrassing code you've written there are dumb bugs and little moments of triumph, and they're begging you to share some of the juicy details, of which I'm fairly sure every programmer has a few they can recall.

If you have no example of work you've done you can gush over, then yeah it's a problem, but to me this is a sign that the only truly wrong answer is NO answer or trying to fake a modicum of passion by gushing about something you actually don't care about, and THEN sounding wooden when doing so, because if you didn't come off as wooden, even this would be sufficient.

[cookiecaper]

Right, I actually agree. I said in another comment that these questions are lazy interviewing, because it's just the interviewer saying "Well? Amuse me."

But it's still difficult to say I'm "proud" of something that I don't really think warrants pride. Just have to steel up and go in there ready to talk about something dumb I guess.

The things I'm actually proud of are things that don't look impressive to the outside. To me, the gold standard contribution is surgical, precise, and simple. It may only be 20 lines of code but it operates within the framework of the existing stuff, doesn't break the tests, etc. That sounds like "routine work" to me.

These people want to hear about atom bombs because they leave a cool looking mushroom cloud, but the professional shouldn't have to go nuclear -- and they shouldn't be proud of it when they do.

I guess the core issue is that if someone is asking this question, it signals that we're not really on the same wavelength. At least, it seems to signal that, because I assume they're saying "OK, please wow me now." Good work is quiet and consistent, usually not astonishing.

If the candidate is the author of some bona fide, actually-used open-source software (not GitHub vanity projects), that could qualify as something that looks impressive and is also probably objectively worth being proud of, but few people would meet this description.

Of course, in reality, the signal is really "I have no idea how to interview someone, please make this easy for me." If you interpret it that way and ignore the actual question posed, I guess it becomes easy; just say something that sounds like a vague answer, and then speak for 2 minutes+ about why you're probably the best choice.

[eropple]

This feels pretty pessimistic to me. A "professional" (and I only half-mean the scare quotes, I think I am one) is able to often do some pretty transformative stuff that's worth being proud of while not setting off The Bomb. I can truthfully and accurately say that I reduced one employer's deployment time of their services from six hours to six minutes with no loss of safety or increased risk--I hacked through an accretion of technical debt (after building out testing to ensure that I didn't change any functionality) that had just plain grown because nobody else had had time to pull it out and replace it with a more scalable, long-term solution! I'm pretty proud of that. And two orders of magnitude on a deploy will wow folks who've ever been personally faced with the bigger one.

(One of the other ones I'm more amused than proud of, though, is saving a client ten times the money they paid me because I happened to know about the existence of AWS D2 instances...)

Your concluding point is well-taken, though, because most people don't know how to interview and they're basically asking you to sell yourself for them. But I don't think the question is as problematic under the hood as you're framing it.

[cookiecaper]

Yeah, those wins are great. It's really about the level of detail that you assume they want. "I improved the deployment time" is an effect of a technical change, not a technical change in itself. There are a lot of people who could improve the deployment time just by switching to a faster build backend or doing some other small change that has big dividends. Is that a "technical accomplishment"? Sure, and it has big wins, but if the answer is just "I installed Jenkins" then it kind of takes the oomph out.

And big wins like that are usually compacted pretty early on. If you can get orders of magnitude improvements left and right, it means that something about the company's management is off.

It's also not a good question for an interview because it's a hard basis for comparisons. Perhaps another candidate knew how to improve the build/deployment pipeline, but he was blocked by political interference. He wouldn't be able to say "I sped up the pipeline 6x.", but he could talk about his plans to do so with a question more oriented to the task, e.g., "How would you build your dream deployment pipeline?"

That's what I mean when I say they're looking for something spectacular. Some people can say they saved their company or made a change with massive ripple effects, which is not necessarily aligned with the technical difficulty of that change and may cause some candidates to elide mention of it entirely, and some people can't make such big assertions, not because they're not skilled enough, but because the opportunity and/or priority wasn't there.

If you want to know about business gains and side effects of technical work, ask "How did your work help your employer?" If you want to know about technical work itself, ask relevant lines of questioning.

Anyway, I think we're basically splitting hairs here. It's just about what level you're choosing to process the question on, and it seems everyone agrees that it's best to take a very superficial interpretation and allow them to inquire further as necessary. I just don't think it's a good interview question.

[pvinis]

Some interviewers think like that, with this "wow me now" attitude. These are the bad interviewers, and honestly I don't much care about the answer given to them. The one losing is the company by not hiring me because I didn't "wow them" by their standards, and in the end I would like to work there.

But there are many interviewers that don't expect to hear the atom bombs, or the circus acts, or whatever else. They actually want to hear about something you did, finished, and then a feeling of accomplishment came over you. They are also developers. They want to know a bit more about you. And these are the people I would like to work with.

Bottom line, there are worst questions that are asked during interviews :P.

[SilasX]

But that reveals why it's such a bad question: they just have to prepare in advance and think of a problem scenario that sounds interesting and panders you, and recite it at that question. Even a faker can do that, but a legit programmer that needs a few minutes to get thinking (and hasn't come up with a cookie-cutter answer in advance) will stumble at.

[HeyLaughingBoy]

But who cares that it's a bad question. The point is that it was asked and you should either answer it, evade it skilfully, or find a tactful way to decline to answer.

[cookiecaper]

The poster asserted that "100% of developers have an answer" to this question. We're discussing why some developers may not have a good or immediate answer, and why the question is not as good as he asserts.

[pvinis]

Well, I don't know about how good this question is, but it is one that gets asked a lot. And I do still think that 100% of developers have an answer, because I am sure every developer has felt proud about something he did, no matter the size, otherwise why would they still be a developer?

[SilasX]

Sure, I wasn't speaking to that issue, only to the parent's attempt to justify it as a good question.