5 ms·

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 mo

by pvinis 9y ago

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.

cookiecaper 9y ago
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 9y ago
  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 9y ago
    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.
BurningFrog 9y ago
> 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 9y ago
  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 9y ago
  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.

by pvinis 9y ago

cookiecaper 9y ago

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 9y ago
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 9y ago
  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.

BurningFrog 9y ago

> 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 9y ago
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 9y ago
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.