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

I've been in tech for almost 20 years now. I've worked in all sorts of industries, small companies, start-ups, big companies, you name it and I've been there. I'm currently in FAANG. I've been tech lead, in management, and even offered c-level positions in the past. There has not been a single time in my entire career where such a thing was even remotely true. Having been the interviewer before on many occasions, if I heard a candidate speak this way, I would absolutely not hire them regardless of how well they performed otherwise. This reeks of "I can't work well with others, so it's my way or the highway". It's very toxic and I question if you're trolling at this point.

I could imagine a team that needed it, but most professional programming work does not require this level of memorization, I'd have to see the job description to know which side to take in this argument.

I'd rather the candidate shows an acquaintance with profiling and debugging tooling. If they're good with those they'll figure out which data structures aren't a good fit once it starts to matter.

Learning some numbers and names by rote doesn't mean you actually understand the trade-offs they imply.

The size of primitives in bytes is something that will rarely matter and when it does, you can look it up.

This is asinine.

How often has the size of a primitive come up in day to day programming in say... The last month?

When has one of your developers ever had to use this information to the point where it had to be memorized?

Especially when it's literally a 1 second search away.

Sure, though I'd ask more open ended questions about a problem to see where they go with it.

Maybe they land on using something like a debugger or wireshark or strace or whatever makes sense to dig into whatever horrible voodoo is plaguing them. The important thing is that they are creative and experienced at questioning or confirming their priors and eliminating thousands of paper cuts and yak barber shops for themselves, their team, and their organization, so that collectively everyone is enabled to operate at a high-level instead of everyone constantly bushwhacking their way toward eventual failure.

That’s the recruiter’s job, not the interviewing engineer’s. Once a candidate gets time with an engineer, the assumption should be that they are at least kind of good, and not an outright fraud. A good enough fraud might get through this, but a genuinely good engineer might not get through the nano questions.

> Agreed. What are the questions you ask to determine their detective abilities?

in my experience, talking to a candidate across a couple of rounds and asking some generic question that can create discussions, will get some answers. sometimes, designing a system together can help a lot (as always reminding the candidate that there are no wrong answers).

at the end of the day, interviewing is a flawed process and you will get it wrong -- the question i don't see being asked is: what do you do if you get wrong?

My interview at Atomwise introduced me to a fun way: pick a Stack Overflow question that includes some code, use the dev-tools to nuke any answers, and print the question (player's choice about leaving any clarifying comments intact). Then have said candidate answer the question for you. Obviously it requires some curation to find the not-facepalm-stupid questions, but I'd bet there are plenty in each language

It can show the ability to read code, experience with any language or framework footguns, how to work with a malspecified problem (it is S.O. after all), etc, depending on the kinds of risks the screen is trying to drive down in your specific team

Yep. 20 years ago it would show that the OP is at a stage where they love what Ruby is doing with code readability and cool ActiveSupport mixins etc. but maybe hasn't considered there are some performance limitations that hit a lot of the early Ruby success stories, now it would show a more experienced engineer that is aware of those nuances.

I've been the guy who nailed it, and I've also been the guy who proves that frauds are everywhere and resumes are meaningless because he can't do FizzBuzz.[0]

I'm not doubting there are people who apply and just aren't qualified. But if your evidence that there's a ton of fraud is coming from a fraud detector which keeps finding fraud, confirming that you need the fraud detector, and showing you how good it is at finding fraud, how would you detect if it was finding fraud that isn't there?

[0] https://news.ycombinator.com/item?id=16915511