> Does that say anything about me, according to your filters?

Honestly, it says more about the question than anything else.

A sibling comment suggested "most memorable" which I almost immediately had a good, engaging answer for.

We don't tend to associate positive feelings (favorite) with negative things (bugs, which sure are not always negative but usually are) so it's harder for our brains to decide on something being "good enough" to meet that bar.

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.

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.

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

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

I think the question would have been better with “favorite” replaced with “most memorable” because I do have a most memorable pothole I hit.

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.

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

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

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.

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

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.

All questions like this are really saying “tell me about yourself as an engineer. Here’s a prompt.”

“What’s the most elusive bug you’ve ever fixed?” is a worse question, because it tells me less about you as an engineer, and more about the specific problems you’ve worked on. It’s a worse question to get to the heart of who you are - which is the whole point.

And, because the point is to get to know the person, you have way more breadth in your answer than you think. “Well, I don’t have a favorite bug. I hate all bugs. But I do remember a bug so horrible it took down our site at least once a day for a month…”. This is a fantastic answer - since it answers the real question underneath, of who you are.

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

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.

Or in other words - A cultural fit.

>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 :)

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

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?

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

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.