4 ms·

> "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

> "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?).
plasticchris 2y ago
My favorites were from back when I would get them from product teams that had already had a good crack at them, with fixes like painting the device black, learning a new algorithm, modifying the os core, and so on. Didn’t always succeed but it was great fun. I once found a bug in golang, memorable but less fun as it got fixed right away after I reported it.
josephg 2y ago
Bugs in nontrivial software aren’t potholes. They’re more like sinkholes. Seemingly small inconveniences can open up to a much more interesting world underneath. About 20 years ago when I was still in school I remember a bug in C++ that took me a whole week to find, where I was accidentally returning a pointer to a local variable. The embarrassing thing was that the compiler warned me about it, but I was so laser focussed on finding why my program was crashing that I decided to leave fixing the compiler warnings til later. About 10 years ago I spent 3 months on and off trying to track down a memory leak in a nodejs server process. I can’t remember what the fix was - I’m sure it was something stupid. But along the way I learned to connect the chrome dev tools to nodejs and I figured out how to use heap snapshot diffing, and what roots are, and how V8 thinks about memory. I still use that knowledge to this day. I could tell lots of stories like this. That time I left a debugging statement in some performance critical code and for 3 months it ran 20x slower than it should have. How a diffing function actually needed to be a 3 way diff to function correctly - else some weird corner cases would cause problems. And so on. Do you seriously not have interesting stories? Are you just not curious when things go wrong, why they go wrong? This sounds like a great interview question to weed out people who don’t have any passion to become excellent engineers.
- foldr 2y ago
  It’s more of a memory test than anything. I can easily believe that some people happen to remember bugs in more detail than others, for whatever reason. I’m not sure it makes sense to draw inferences from this about their ability as engineers.
  - josephg 2y ago
    It sounds harsh to say this, but why not? All else being equal, I’d rather hire & work with engineers with a good memory for engineering. Your brain remembers things that you think about a lot, or that had a strong emotional experience. That’s how memory works. People who think a lot about engineering become better engineers.
    - foldr 2y ago
gopalv 2y ago
> That would be like asking a driver, "what's your favorite pothole you've ever driven over?" The bugs that matter aren't potholes, they're trails with no markers, cut by someone you don't know who has left the organization years ago. This is more like "What was your harder part of the Rubicon trail?" I spent 7 months debugging a single issue which happened once a billion requests across 100k web servers or so. For those 7 months, most machines did a hard restart every 4 hours and the bug never reproduces, so I didn't even know if I fixed it until I had enough confidence to turn that restart loop off. Finding the issue had a fork of valgrind in the middle, found a CPU errata with AMD hardware when 2 locks placed in the same cache line (but not all failing machines had that CPU version), found a "bug" in UFS FreeBSD where deleting a file + recreating it uses the same inode id (not a bug, but not how linux worked) The fix was 2 lines. Your answer is not the wrong answer, but the bugs that you encounter in the wild is often like a tiger hunt in a jungle, alone.
1337shadow 2y ago
I remember when we were using an experimental SDN router, it was 0'ing the MAC address field in the packets, pretty fun to debug
- nailer 2y ago
  Oooooh that reminds me of when Realtek printed a bunch of NICs with identical MACs.
ryukoposting 2y ago
I disagree. One of the coolest things I ever made professionally was born from the need to fix several deeply interconnected bugs.
AnimalMuppet 2y ago
Most bugs, once you fix them, are "oh, that was so five minutes ago". A few bugs are really interesting. I can still describe my most interesting bug, in detail, and it was about 13 years ago.

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?).

plasticchris 2y ago

My favorites were from back when I would get them from product teams that had already had a good crack at them, with fixes like painting the device black, learning a new algorithm, modifying the os core, and so on. Didn’t always succeed but it was great fun. I once found a bug in golang, memorable but less fun as it got fixed right away after I reported it.

josephg 2y ago

Bugs in nontrivial software aren’t potholes. They’re more like sinkholes. Seemingly small inconveniences can open up to a much more interesting world underneath. About 20 years ago when I was still in school I remember a bug in C++ that took me a whole week to find, where I was accidentally returning a pointer to a local variable. The embarrassing thing was that the compiler warned me about it, but I was so laser focussed on finding why my program was crashing that I decided to leave fixing the compiler warnings til later. About 10 years ago I spent 3 months on and off trying to track down a memory leak in a nodejs server process. I can’t remember what the fix was - I’m sure it was something stupid. But along the way I learned to connect the chrome dev tools to nodejs and I figured out how to use heap snapshot diffing, and what roots are, and how V8 thinks about memory. I still use that knowledge to this day. I could tell lots of stories like this. That time I left a debugging statement in some performance critical code and for 3 months it ran 20x slower than it should have. How a diffing function actually needed to be a 3 way diff to function correctly - else some weird corner cases would cause problems. And so on. Do you seriously not have interesting stories? Are you just not curious when things go wrong, why they go wrong? This sounds like a great interview question to weed out people who don’t have any passion to become excellent engineers.

foldr 2y ago
It’s more of a memory test than anything. I can easily believe that some people happen to remember bugs in more detail than others, for whatever reason. I’m not sure it makes sense to draw inferences from this about their ability as engineers.
- josephg 2y ago
  It sounds harsh to say this, but why not? All else being equal, I’d rather hire & work with engineers with a good memory for engineering. Your brain remembers things that you think about a lot, or that had a strong emotional experience. That’s how memory works. People who think a lot about engineering become better engineers.
  - foldr 2y ago

gopalv 2y ago

> That would be like asking a driver, "what's your favorite pothole you've ever driven over?" The bugs that matter aren't potholes, they're trails with no markers, cut by someone you don't know who has left the organization years ago. This is more like "What was your harder part of the Rubicon trail?" I spent 7 months debugging a single issue which happened once a billion requests across 100k web servers or so. For those 7 months, most machines did a hard restart every 4 hours and the bug never reproduces, so I didn't even know if I fixed it until I had enough confidence to turn that restart loop off. Finding the issue had a fork of valgrind in the middle, found a CPU errata with AMD hardware when 2 locks placed in the same cache line (but not all failing machines had that CPU version), found a "bug" in UFS FreeBSD where deleting a file + recreating it uses the same inode id (not a bug, but not how linux worked) The fix was 2 lines. Your answer is not the wrong answer, but the bugs that you encounter in the wild is often like a tiger hunt in a jungle, alone.

1337shadow 2y ago

I remember when we were using an experimental SDN router, it was 0'ing the MAC address field in the packets, pretty fun to debug

nailer 2y ago
Oooooh that reminds me of when Realtek printed a bunch of NICs with identical MACs.

ryukoposting 2y ago

I disagree. One of the coolest things I ever made professionally was born from the need to fix several deeply interconnected bugs.

AnimalMuppet 2y ago

Most bugs, once you fix them, are "oh, that was so five minutes ago". A few bugs are really interesting. I can still describe my most interesting bug, in detail, and it was about 13 years ago.