9 ms·

my two favorite questions for interviews: "what's the favorite bug you've ever fixed?" and "what's your strongest opinion in tech?" why? because they are op

my two favorite questions for interviews: "what's the favorite bug you've ever fixed?" and "what's your strongest opinion in tech?" why? because they are open answers and 99% of the time they bring really interesting discussions to the table, which can lead to understanding the candidate better. also, they are good filters: if they say "none" and "none", i know what to expect.

1337shadow 2y ago
I ask "what do you think about tests / what's your favorite test framework" and "what is your favorite os / what os do you use at home"
- teaearlgraycold 2y ago
  I like to do as much as possible in the type system so I can avoid writing tests.
MortyWaves 2y ago
I have a couple of favourite ones but one I always think of immediately is a time when I was tasked with fixing some dashboard. Sometimes students scores would be appearing as zero despite their average score being not zero. Turns out it was some very simple averaging that didn’t filter out tests with a score of zero. That zero would then basically poison the entire calculation and only produce zero. I don’t know how interesting that one is though.
- williamdclt 2y ago
  I'd follow-up with questions on how you debugged that, how you'd do it now, what tooling you were missing, the testing strategy that led to this... I'd say it can be pretty interesting
  - fernandotakai 2y ago
    you totally got it btw -- because questions should be conversation starters, not just "question -> answer" ad infinitum. when i ask about a bug, i just want to know how you go debugging, understanding logs, dealing with other frustrated developers... you know, how you deal with things in a day-to-day basis.
- shemnon42 2y ago
  The bug is never the interesting part. The follow on questions are where the data is. How did you find it? How did you fix it? What made it memorable? Did it change the way you code?
UncleOxidant 2y ago
> "what's the favorite bug you've ever fixed?" favorite is kind of odd phrasing because you're cursing the bug as you're chasing it. Maybe "what's the most elusive bug you've ever fixed?" would be better? Problem is that most of those situations were painful and I've generally blocked out the details now many years later so I'm not sure I'd have a lot to say other than cuss words.
- eyelidlessness 2y ago
  It’s great phrasing, if you’re filtering for people who enjoy solving problems. Many of my favorite parts of software development are the parts I curse while they’re challenging (if they’re challenging for good reason, or even just for amusing/absurd reasons).
  - UncleOxidant 2y ago
    Maybe better phrasing would be "what's the most satisfying bug you've fixed?" or "which bug after being fixed gave you the most satisfaction?"
- fatnoah 2y ago
  I definitely have a "favorite" but that's because it was my first user-facing race condition error in a picture messaging app where part of the resolution was an official letter to someone's spouse to explain that they image they received was not, in fact, the one that our user was trying to send to them.
- Brian_K_White 2y ago
  "favorite bug" is perfect. I don't know how any kind of problem solver in any field does not love it when they get really baffled and then solve it. My problem would just be remembering any particular example.
  - wat10000 2y ago
    Yeah, “bugs are so painful that I suppress the memory” is not someone I want to hire. I want people who get excited when you bring them a weird bug, and who have a depth of experience to bring in when debugging gets hard.
eyelidlessness 2y ago
The opinion question will probably tend to weed out good candidates too, however. Interviewers and interviewees being human and all, it can over-emphasize superficial disagreements, where those differences of opinion may actually be valuable to a team if they come up in a more relevant context.
- smithcoin 2y ago
  The point of the question is not to superficially disagree though, the point is to see somebody speak with passion about something they should have knowledge of.
  - wubrr 2y ago
    The longer I've been in tech and the more I learn, the less strong opinions I have. There are things you learn that should be done a certain way, but if the rationale behind that is strong/ubiquitous enough, it's not really an opinion any more. For example, I could say 'metrics/analytics/monitoring is super important... etc.' now the interviewer can decide to either agree with this fairly obvious/ubiquitous 'opinion', or decide this point is not interesting/controversial enough. Ultimately, I think it's a terrible question - there's no 'right' answer, and you're completely at the mercy of the interviewer's subjective opinions/feelings. If you want to hear about something the interviewee has passion/knowledge of - ask them about a project they worked on, what problems they ran into, what they learned, etc.
    - romanhn 2y ago
      This was similar to my reaction to that question, and how I'd respond to it in the interview (with curiosity around what they're trying to get out of it). It's not that I don't have strong opinions, but they are necessarily couched in context. Strong opinions lacking in context are a sign of a lack of experience. Sometimes unit tests are a must, and in other cases they are an absolute waste of time. Sometimes microservices are the right call, and others they are an unnecessary complexity. The more experience in this field I get, the more gray and amorphous my opinions become, and "it depends" is the default, if not interesting, answer.
shemnon42 2y ago
> "what's the favorite bug you've ever fixed?" I use a variant, "What's the most memorable bug you've fixed?" - and I use it as an indicator of maturity to distinguish L3 SwE from a L5+ SwE (google levels). First, there is the time-in-field aspect. Simply being in the field for a long time increases the amount of time you have to encounter a sleep-depriving bug. It can show tenacity. How did they find it? What did they have to do to reproduce it? Was it in prod, test, or dev? etc. It can show maturity. Why did it pass test? What tests were introduced to detect it? Was it a new class of bug that required new testing? Were you able to add lint rules to detect it? Did you ensure it was pushed properly to prod and do proper follow up. It can show autonomy. Did you update the testing procedures or just post a bug and hope the QA team fixed it? Did you meet with devops and share info on how to detect and mitigate it? Did you update the playbook at least? So many possible places to dig in to get the "hire" when the default answer is "no hire". And if you cannot find any, then that's confirmation of the default answer.
do_not_redeem 2y ago
> "what's the favorite bug you've ever fixed?" I'd be hard pressed to choose a "favorite" bug, let alone remember the details years later. I'm trying to build working software, and bugs are just obstacles on my path. I fix the bug and then move on to what I actually care about. That would be like asking a driver, "what's your favorite pothole you've ever driven over?"
- nkrisc 2y ago
  I think the question would have been better with “favorite” replaced with “most memorable” because I do have a most memorable pothole I hit.
  - josephg 2y ago
    Potato potahto. The point of any interview question is to get to know the candidate. Your interviewer won’t know what the perfect framing of any given question is for you personally. They just want you to tell them about yourself - in this case the prompt is to tell a story about an experience debugging. If you’re the candidate, practice reframing any question you get asked into the variant of the question that brings you the most alive. Your interviewer, and your career, will thank you.
  - Moru 2y ago
    When I was still driving to/from work every day I had every bump and pot hole mappend up in my brain. Here I need to be more to the middle line, there I go over on the left side and directly over to the right side as far as possible. And so on. Yes, it was a horrible road :-)
- fernandotakai 2y ago
  i disagree. i've been a dev for about 17 years now, and i remember a bunch of random stuff that i had to fix that were super interesting. and honestly, it's not about the specific answer: it's about creating enough conversation that you can understand the person. i usually use these two with senior+ engineers, but if i'm interviewing someone more junior, i will ask something different (like, what are you learning right now? what do you wanna understand over the next 12 months? is there anything that you currently do not like in tech?).
smithcoin 2y ago
I love these questions. I usually ask some variation of them. The other question I always ask is “What was your first job?” - the way they describe that experience can tell you a lot about a person.
jddj 2y ago
How quickly do people typically respond? I thought about both of these just now, and granted it's the end of a long day and I've never been good at favourite questions, but it took me a good few minutes to come up with what is probably my actual answer to the first question, and a good couple of minutes to surface anything at all. I've dealt with quite a range, too. Heisenbugs, compiler bugs on obscure c compilers, etc. But recalling them quickly is difficult. "What's your favourite problem that you've ever solved" brings things forth much more easily, but it's almost like bugs, once solved, don't get kept around in my easily accessible memory. Does that say anything about me, according to your filters?
- fernandotakai 2y ago
  the first one: depends on experience! i had a guy answer with a kernel nevel bug that honestly, i didn't understand the fix. the second one: i think most (if not all) developers have at least one strong opinion -- even if it's just "i don't like javascript". see, interviewing, for me, is not about right answers, it's about getting to know the person and getting to see how they approach different problems. these are just two of the things i might ask, depending on how everything is going. >Does that say anything about me, according to your filters? i don't know, i never saw your resume, i don't know your experience and we've never talked before. maybe it just means we have to have a 15min talk before i could ask those. and there's something i always tell every single candidate i've ever interviewed: there are no wrong answers -- if you don't know, you don't know.
  - mynameisvlad 2y ago
    > there's something i always tell every single candidate i've ever interviewed: there are no wrong answers That's just objectively bullshit. If you don't know something, you probably are going to be marked down compared to a candidate that does know it. Even in a subjective question, your answer depends entirely on your interviewer's subjectivity. One interviewer might find an answer good while another finds it lacking. Interviews are one of few places where there are very clearly wrong answers.
    - 2y ago
wiredfool 2y ago
Chickens absorb wifi. (edit - favorite root cause of a reliability issue, not strongest held tech opinion)
the__alchemist 2y ago
I think these questions are both more of a filter for good storytellers than anything technical. Edit: Also, for people with good memories/fast recall.
- josephg 2y ago
  I agree - but it’s nice to have good communication skills on your team. I’ve performed over 400 technical interviews, and one of my big takeaways is that you want lots of different kinds of challenges for candidates. Programming. Knowledge tests. Debugging. Whiteboard problems. Story telling. And so on. I think this question is great, but a great interview should never lean too heavily on just one modality of assessment.
- Moru 2y ago
  Or in other words - A cultural fit.
CodeMage 2y ago
> "what's the favorite bug you've ever fixed?" Questions like this are why I'm beginning to dread the whole hiring process. It's a great question in some situations, but absolutely dreadful in others. If you catch me with it during a two-week sprint when I worked on an interesting bug, I'll have no problem answering it and the discussion will be fun for both of us. But if you catch me at a different moment, I'll draw a blank and start feeling pressured. Yeah, bugs can be extremely rewarding and interesting, but not everyone will find them memorable enough to be able to talk about them in the context of an interview question. For example, if you asked me that question right now, I would be hard-pressed to answer it. Sure, I've had interesting bugs, but I've spent the last several weeks leading a greenfield project and having to deal with project management bullshit I never signed up for in the first place, and interesting bugs are not in my "mental cache". Which brings me to my biggest gripe with this kind of question: people like to be reasonably prepared for an interview, and throwing this kind of unexpected question can make them feel bad. That doesn't mean that no one should ever ask questions like that. If the candidate explains that they can't think of the answer at the moment and why, and if the interviewer doesn't hold that against them (as long as the explanation is valid), then it's okay.
- fernandotakai 2y ago
  >That doesn't mean that no one should ever ask questions like that. If the candidate explains that they can't think of the answer at the moment and why, and if the interviewer doesn't hold that against them (as long as the explanation is valid), then it's okay. that's totally ok for me. that's why those are only two of the questions i usually ask, not all of them. i think saying "i don't know" is just as valid as any other thing. as i mentioned elsewhere in this thread, these questions are "conversations starters" and the good data comes from the subsequent questions. so if you said: "i can't come up with anything" i would probably ask about the last interesting project you worked on. or what was the last programming language you tried to learn. interviews are not only for probing for tech knowledge, they are also about getting to learn about each other :)
  - deleted 2y ago
    [deleted]
stronglikedan 2y ago
> if they say "none" and "none", i know what to expect. Something tells me this is not the case. I expect that you have passed up some very good developers, but it seems like that is not what you are looking for if those are the types of questions you're asking. Most people don't have a "strongest" or "favorite" anything.
nailer 2y ago
Those are excellent questions! I'm going to try and answer for the sake of chatting while I take a break: - "what's the favorite bug you've ever fixed?" A. I've gotten really good at identifying 'heisenbugs'. Ie where something randomly fails. I make a test suite to repeat something a hundred times and find out the failure ratio (eg, 30%). I then go looking for possible race conditions in the code and re-run the test till eg 30% drops to 0%. I've used this debugging pattern everywhere from frontend to infrastructure engineering. "what's your strongest opinion in tech?" A. 90s-style OOP is bad, Alan Kay's original concept was closer to the FP world's 'actor' model than it was 90s style OOP, and there is no reason to glue state to functions.

1337shadow 2y ago

I ask "what do you think about tests / what's your favorite test framework" and "what is your favorite os / what os do you use at home"

teaearlgraycold 2y ago
I like to do as much as possible in the type system so I can avoid writing tests.

MortyWaves 2y ago

I have a couple of favourite ones but one I always think of immediately is a time when I was tasked with fixing some dashboard. Sometimes students scores would be appearing as zero despite their average score being not zero. Turns out it was some very simple averaging that didn’t filter out tests with a score of zero. That zero would then basically poison the entire calculation and only produce zero. I don’t know how interesting that one is though.

williamdclt 2y ago
I'd follow-up with questions on how you debugged that, how you'd do it now, what tooling you were missing, the testing strategy that led to this... I'd say it can be pretty interesting
- fernandotakai 2y ago
  you totally got it btw -- because questions should be conversation starters, not just "question -> answer" ad infinitum. when i ask about a bug, i just want to know how you go debugging, understanding logs, dealing with other frustrated developers... you know, how you deal with things in a day-to-day basis.
shemnon42 2y ago
The bug is never the interesting part. The follow on questions are where the data is. How did you find it? How did you fix it? What made it memorable? Did it change the way you code?

UncleOxidant 2y ago

> "what's the favorite bug you've ever fixed?" favorite is kind of odd phrasing because you're cursing the bug as you're chasing it. Maybe "what's the most elusive bug you've ever fixed?" would be better? Problem is that most of those situations were painful and I've generally blocked out the details now many years later so I'm not sure I'd have a lot to say other than cuss words.

eyelidlessness 2y ago
It’s great phrasing, if you’re filtering for people who enjoy solving problems. Many of my favorite parts of software development are the parts I curse while they’re challenging (if they’re challenging for good reason, or even just for amusing/absurd reasons).
- UncleOxidant 2y ago
  Maybe better phrasing would be "what's the most satisfying bug you've fixed?" or "which bug after being fixed gave you the most satisfaction?"
fatnoah 2y ago
I definitely have a "favorite" but that's because it was my first user-facing race condition error in a picture messaging app where part of the resolution was an official letter to someone's spouse to explain that they image they received was not, in fact, the one that our user was trying to send to them.
Brian_K_White 2y ago
"favorite bug" is perfect. I don't know how any kind of problem solver in any field does not love it when they get really baffled and then solve it. My problem would just be remembering any particular example.
- wat10000 2y ago
  Yeah, “bugs are so painful that I suppress the memory” is not someone I want to hire. I want people who get excited when you bring them a weird bug, and who have a depth of experience to bring in when debugging gets hard.

eyelidlessness 2y ago

The opinion question will probably tend to weed out good candidates too, however. Interviewers and interviewees being human and all, it can over-emphasize superficial disagreements, where those differences of opinion may actually be valuable to a team if they come up in a more relevant context.

smithcoin 2y ago
The point of the question is not to superficially disagree though, the point is to see somebody speak with passion about something they should have knowledge of.
- wubrr 2y ago
  The longer I've been in tech and the more I learn, the less strong opinions I have. There are things you learn that should be done a certain way, but if the rationale behind that is strong/ubiquitous enough, it's not really an opinion any more. For example, I could say 'metrics/analytics/monitoring is super important... etc.' now the interviewer can decide to either agree with this fairly obvious/ubiquitous 'opinion', or decide this point is not interesting/controversial enough. Ultimately, I think it's a terrible question - there's no 'right' answer, and you're completely at the mercy of the interviewer's subjective opinions/feelings. If you want to hear about something the interviewee has passion/knowledge of - ask them about a project they worked on, what problems they ran into, what they learned, etc.
  - romanhn 2y ago
    This was similar to my reaction to that question, and how I'd respond to it in the interview (with curiosity around what they're trying to get out of it). It's not that I don't have strong opinions, but they are necessarily couched in context. Strong opinions lacking in context are a sign of a lack of experience. Sometimes unit tests are a must, and in other cases they are an absolute waste of time. Sometimes microservices are the right call, and others they are an unnecessary complexity. The more experience in this field I get, the more gray and amorphous my opinions become, and "it depends" is the default, if not interesting, answer.

shemnon42 2y ago

> "what's the favorite bug you've ever fixed?" I use a variant, "What's the most memorable bug you've fixed?" - and I use it as an indicator of maturity to distinguish L3 SwE from a L5+ SwE (google levels). First, there is the time-in-field aspect. Simply being in the field for a long time increases the amount of time you have to encounter a sleep-depriving bug. It can show tenacity. How did they find it? What did they have to do to reproduce it? Was it in prod, test, or dev? etc. It can show maturity. Why did it pass test? What tests were introduced to detect it? Was it a new class of bug that required new testing? Were you able to add lint rules to detect it? Did you ensure it was pushed properly to prod and do proper follow up. It can show autonomy. Did you update the testing procedures or just post a bug and hope the QA team fixed it? Did you meet with devops and share info on how to detect and mitigate it? Did you update the playbook at least? So many possible places to dig in to get the "hire" when the default answer is "no hire". And if you cannot find any, then that's confirmation of the default answer.

do_not_redeem 2y ago

> "what's the favorite bug you've ever fixed?" I'd be hard pressed to choose a "favorite" bug, let alone remember the details years later. I'm trying to build working software, and bugs are just obstacles on my path. I fix the bug and then move on to what I actually care about. That would be like asking a driver, "what's your favorite pothole you've ever driven over?"

nkrisc 2y ago
I think the question would have been better with “favorite” replaced with “most memorable” because I do have a most memorable pothole I hit.
- josephg 2y ago
  Potato potahto. The point of any interview question is to get to know the candidate. Your interviewer won’t know what the perfect framing of any given question is for you personally. They just want you to tell them about yourself - in this case the prompt is to tell a story about an experience debugging. If you’re the candidate, practice reframing any question you get asked into the variant of the question that brings you the most alive. Your interviewer, and your career, will thank you.
- Moru 2y ago
  When I was still driving to/from work every day I had every bump and pot hole mappend up in my brain. Here I need to be more to the middle line, there I go over on the left side and directly over to the right side as far as possible. And so on. Yes, it was a horrible road :-)
fernandotakai 2y ago
i disagree. i've been a dev for about 17 years now, and i remember a bunch of random stuff that i had to fix that were super interesting. and honestly, it's not about the specific answer: it's about creating enough conversation that you can understand the person. i usually use these two with senior+ engineers, but if i'm interviewing someone more junior, i will ask something different (like, what are you learning right now? what do you wanna understand over the next 12 months? is there anything that you currently do not like in tech?).

smithcoin 2y ago

I love these questions. I usually ask some variation of them. The other question I always ask is “What was your first job?” - the way they describe that experience can tell you a lot about a person.

jddj 2y ago

How quickly do people typically respond? I thought about both of these just now, and granted it's the end of a long day and I've never been good at favourite questions, but it took me a good few minutes to come up with what is probably my actual answer to the first question, and a good couple of minutes to surface anything at all. I've dealt with quite a range, too. Heisenbugs, compiler bugs on obscure c compilers, etc. But recalling them quickly is difficult. "What's your favourite problem that you've ever solved" brings things forth much more easily, but it's almost like bugs, once solved, don't get kept around in my easily accessible memory. Does that say anything about me, according to your filters?

fernandotakai 2y ago
the first one: depends on experience! i had a guy answer with a kernel nevel bug that honestly, i didn't understand the fix. the second one: i think most (if not all) developers have at least one strong opinion -- even if it's just "i don't like javascript". see, interviewing, for me, is not about right answers, it's about getting to know the person and getting to see how they approach different problems. these are just two of the things i might ask, depending on how everything is going. >Does that say anything about me, according to your filters? i don't know, i never saw your resume, i don't know your experience and we've never talked before. maybe it just means we have to have a 15min talk before i could ask those. and there's something i always tell every single candidate i've ever interviewed: there are no wrong answers -- if you don't know, you don't know.
- mynameisvlad 2y ago
  > there's something i always tell every single candidate i've ever interviewed: there are no wrong answers That's just objectively bullshit. If you don't know something, you probably are going to be marked down compared to a candidate that does know it. Even in a subjective question, your answer depends entirely on your interviewer's subjectivity. One interviewer might find an answer good while another finds it lacking. Interviews are one of few places where there are very clearly wrong answers.
  - 2y ago

wiredfool 2y ago

Chickens absorb wifi. (edit - favorite root cause of a reliability issue, not strongest held tech opinion)

the__alchemist 2y ago

I think these questions are both more of a filter for good storytellers than anything technical. Edit: Also, for people with good memories/fast recall.

josephg 2y ago
I agree - but it’s nice to have good communication skills on your team. I’ve performed over 400 technical interviews, and one of my big takeaways is that you want lots of different kinds of challenges for candidates. Programming. Knowledge tests. Debugging. Whiteboard problems. Story telling. And so on. I think this question is great, but a great interview should never lean too heavily on just one modality of assessment.
Moru 2y ago
Or in other words - A cultural fit.

CodeMage 2y ago

> "what's the favorite bug you've ever fixed?" Questions like this are why I'm beginning to dread the whole hiring process. It's a great question in some situations, but absolutely dreadful in others. If you catch me with it during a two-week sprint when I worked on an interesting bug, I'll have no problem answering it and the discussion will be fun for both of us. But if you catch me at a different moment, I'll draw a blank and start feeling pressured. Yeah, bugs can be extremely rewarding and interesting, but not everyone will find them memorable enough to be able to talk about them in the context of an interview question. For example, if you asked me that question right now, I would be hard-pressed to answer it. Sure, I've had interesting bugs, but I've spent the last several weeks leading a greenfield project and having to deal with project management bullshit I never signed up for in the first place, and interesting bugs are not in my "mental cache". Which brings me to my biggest gripe with this kind of question: people like to be reasonably prepared for an interview, and throwing this kind of unexpected question can make them feel bad. That doesn't mean that no one should ever ask questions like that. If the candidate explains that they can't think of the answer at the moment and why, and if the interviewer doesn't hold that against them (as long as the explanation is valid), then it's okay.

fernandotakai 2y ago
>That doesn't mean that no one should ever ask questions like that. If the candidate explains that they can't think of the answer at the moment and why, and if the interviewer doesn't hold that against them (as long as the explanation is valid), then it's okay. that's totally ok for me. that's why those are only two of the questions i usually ask, not all of them. i think saying "i don't know" is just as valid as any other thing. as i mentioned elsewhere in this thread, these questions are "conversations starters" and the good data comes from the subsequent questions. so if you said: "i can't come up with anything" i would probably ask about the last interesting project you worked on. or what was the last programming language you tried to learn. interviews are not only for probing for tech knowledge, they are also about getting to learn about each other :)
- deleted 2y ago
  [deleted]

stronglikedan 2y ago

> if they say "none" and "none", i know what to expect. Something tells me this is not the case. I expect that you have passed up some very good developers, but it seems like that is not what you are looking for if those are the types of questions you're asking. Most people don't have a "strongest" or "favorite" anything.

nailer 2y ago

Those are excellent questions! I'm going to try and answer for the sake of chatting while I take a break: - "what's the favorite bug you've ever fixed?" A. I've gotten really good at identifying 'heisenbugs'. Ie where something randomly fails. I make a test suite to repeat something a hundred times and find out the failure ratio (eg, 30%). I then go looking for possible race conditions in the code and re-run the test till eg 30% drops to 0%. I've used this debugging pattern everywhere from frontend to infrastructure engineering. "what's your strongest opinion in tech?" A. 90s-style OOP is bad, Alan Kay's original concept was closer to the FP world's 'actor' model than it was 90s style OOP, and there is no reason to glue state to functions.