A reasonable question. But if you really need to reject the candidate (for instance, if you're attempting to resist, or provide cover for resisting, someone brought in e.g. by the bad kind of nepotism), no matter how much they talk about how it led them to build systems to prevent similar disasters, as an interviewer you can selectively choose to focus on the mindset that led them to break the system in the first place.
In general, though, if you're looking for ways to disqualify a candidate based on other than merit, you should examine your own biases against the candidate. Don't be evil.
We had a real need for batch queries, so I built a declarative batch query mechanism for our in-house ORM. To do this, we needed to make actual objects representing database relations. Unfortunately, the "collections of lambdas" we were using as an ORM had started getting polluted with buisness logic. So I used a parser/rewrite engine to match the un-polluted DB transformation lambdas and to substitute DB column and relation objects implementing the same logic in the un-polluted lambdas.
I checked in a massive change affecting 2500 of the ~5000 lambdas, syntactically matching the logic in all 2500 of those with the parser framework, and then also vetted everything by hand. I was 100% sure the logic was duplicated exactly. This would allow us to introduce the objects, and it would also stop the march of business logic into the DB framework. Everything checked out in QA, so we moved it to production.
Production immediately came to a screeching halt. However, in under an hour, I discovered that a coworker had polluted an even lower level of the ORM framework with business logic. (The code that called the lambdas in the first place.) We replicated that logic in the new framework, and everything worked 100%. I also came out a huge hero in the end, because the batch query mechanism I introduced reduced the average number of queries for opening a portfolio from ~2500 to only 50, and because it was declarative, it could be reused by any programmer very easily.
"I see. So you failed to communicate effectively with a coworker, which resulted in an hour of downtime. I didn't hear you mention anything about seeing this as a problem, let alone addressing it. Thanks for your time."
The villagers came and saw that he was wounded. So they started to take pieces of his packing, of his motorcycle and even his expensive wrist watch. He laid there in pain outside the village for several hours as none of the natives helped him. Until another white motorcyclist came and helped him up on his bike and drove him to a hospital. The end.
To this date I have nfc why he told me this story or why he thought it was relevant in a developer interview. Fairly sure it was an elaborate test though with only bad answers possible.
We are looking for a lot of experience in the latest version using the latest testing and development practices. We don't want to hire people with bad habits.
An interviewer doesn't really have to ask you anything. They can just decide on the basis of what you didn't say instead.
"When asked about his JS experience, he mentioned Y without mentioning X."
A more interesting question would be, can you think of a double bind that allows the interviewer to take either side without looking like a hypocrite over multiple interviews?
Yes => We cannot hire you
No => Liar! We cannot hire you.
See Gattaca for a vision of this possible future ;)
• What's your favorite color?
• What are your weaknesses?
• What are your strengths?
• When's the last time you did something unethical?
