[pvinis]

The way I think about that question, and in fact that's the question I have gotten many times, is "what's a technical problem that you solved and you are the most proud of?". In this question, 100% of developers have an answer. Everyone has done something that needed a bit of thinking or planning, and then they were proud of the execution. It can be the hello world in a new language or it could be building Facebook, or whatever else in between and beyond. If you think you don't have any of those, think again. Many times this answer changed during your time as a developer, but there is always at least one answer, no matter your level, experience, etc.

Personally, many times I answer with a time where I decided to re-engineer and rewrite a "snapping engine". It helped with snapping boxes together when they are close to each other in a 2d design application. Unexpectedly difficult to write with some features we wanted, but after a couple of iterations, I finished, and since then, new features and plugins worked perfectly and nicely together, and were easy to add and implement.

[BurningFrog]

> In this question, 100% of developers have an answer.

Sorry, I don't.

The story I would tell if asked this was solved by the guy I was pairing with. He knew about URL encoding images, which immediately solved something we could have worked for weeks on. I was very surprised and impressed. Of course, now that is part of my toolbox, and I wouldn't think much of solving something else this way.

Sometimes I solve problems easily that others find very hard. I'm glad I could help, but I don't go around feeling proud of how awesome I did that day. I just happened to know something others didn't yet.

This might sound like humblebragging, and perhaps it is. Just trying to explain why I have a hard time with this question.

[matthewowen]

How long have you been working for?

It just sounds kinda sad to say that you've never been proud of work you've done. I think if I was never proud of the work I'd done I wouldn't still be doing this job: a feeling of reward is important!

[HeyLaughingBoy]

Think of it this way: the question isn't for you, it's for the interviewer. He/she wants to know if you're smart enough to work for him. So answering that co-worker Paul had this problem that he'd been battling for days and then he finally came to you for help, and explaining how you helped him is a valid answer. It gives the interviewer the insight he's looking for and make you look good.

[cookiecaper]

I actually don't like this question. It's hard to decide.

If it's something too simple, you're going to be looked down on. If it's a clever hack around someone's bug, it's hard to really be proud of something that shouldn't have had to exist in the first place. If I say something from a long time ago, I may not remember enough details to answer follow-up questions. If my job is boring (hence interviewing for a new one), I may not have had any good "shining moments" recently.

As time goes on, stuff that used to seem or look cool can become embarrassing. I've seriously considered deleting some of the early stuff I have on Github even though it has relatively-a-lot-of-stars for something small and stupid.

Asking to be regaled by stories of tech heroism is also prone to sabotage, because it's easy to rehearse an impressive story. It doesn't necessarily indicate their ability to do things that are useful for the job; it just means they rehearsed a good story and prepared for some follow-ups specifically related to that.

In an interview, you're a lot better off asking questions that will require the respondent to formulate an answer right then and there v. something that they've rehearsed. You're also better off leaving the expectations of tech heroism behind.

"Rock star" job listings have more or less died out, but this is really just a lesser form of it. Typically you don't need or want a rock star. You want someone whose output is professional and consistent.

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