One of my favorite questions is, "Tell me about the best bug you've ever found."
It's a great touchstone. Sure, it's subjective, but it gives valuable insight into someone's level of skill, how they approach problems, how they do diagnosis, and so on. Are they scientific? Do they hate on people and their code? Do they follow through with testing?
I've gotten answers ranging from "I don't know" (which is a fail, by the way) to full-stack expositions that boil down to bad code generated by the compiler, to someone finding and solving a fundamental design problem in a years-long project.
Any sufficiently senior engineer will have a tale of a bug that they tell in the circle around the campfire when the kids are tucked away (and probably still listening anyway). And if you're not a seasoned vet, I'd still like to hear about the race condition / double free / syntax error that took you a while to find.
I think when you're just starting that first race condition or memory management issue are exciting. After a while it's not that exciting any more. I got asked that question and the first thing that popped to my mind was a very unexciting bug I was chasing in legacy code I was maintaining. I don't think the interviewer liked that answer because it was mostly grunt work and not some some amazing feat of engineering.
I don't think it's a particularly good open ended question for more experienced developers and an interview is not a camp fire circle... It could be part of an investigation in some past project, e.g. what problems did you have and how did you solve them...
I've had this question asked of me before, and it seems valuable for the same reason as the question on the article: It's an opportunity to show passion/enthusiasm for programming work. I think even novice programmers who love to code will have that one bug that got them. Even if the story is anticlimactic ("I missed a semicolon"). iMo, explaining how they got to that conclusion in a logical, positive way, didn't give up or just copy/paste the answer, and ultimately moved on in the project with a new lesson in syntax is the real "passing answer."
It's a great touchstone. Sure, it's subjective, but it gives valuable insight into someone's level of skill, how they approach problems, how they do diagnosis, and so on. Are they scientific? Do they hate on people and their code? Do they follow through with testing?
I've gotten answers ranging from "I don't know" (which is a fail, by the way) to full-stack expositions that boil down to bad code generated by the compiler, to someone finding and solving a fundamental design problem in a years-long project.
Any sufficiently senior engineer will have a tale of a bug that they tell in the circle around the campfire when the kids are tucked away (and probably still listening anyway). And if you're not a seasoned vet, I'd still like to hear about the race condition / double free / syntax error that took you a while to find.