We've been interviewing for quite some time and I've been asking candidates:
What is the most interesting bug you've found in your career?
Either the most interesting, or the one they are proud of finding, or because it was challenging to reproduce, or the symptoms were unusual.
So far, not a lot of people could actually recall something during the interview. It is understandable that sometimes it's difficult to recall something not from the top of the head under the stress of an interview. We are not pushing hard on this, saying that it's okay if you cannot remember one now.
My thinking is that we can get some signal from the answer - it may provide insights into how critical, serious and diligent one is about the detected issues and give some idea about the ways of candidate's exploratory thinking.
But, is it overall an appropriate question to ask, is our motivating logic correct? Should I modify it or build on top of it adding some similar questions?
Addressing a comment:
what would be your own model answer?
Not sure about whether I can give a good "model" answer myself, but, I would highlight a few of the bugs and problems I've helped to discover trying to give samples from different projects and types of issues:
- interesting UI issue, this one is bit silly, I understand - but may help to "break the ice" during an interview. Once I've discovered that clicking on a certain button in one of our web applications behaved weirdly - the more often you've clicked the faster is started to rotate around it's initial position - not sure if it violated the Kepler's laws of Orbital Dynamics but that was a fun one
- SQL injection attack. Using
sqlmapand manual testing with PostMan, I've discovered that some of our API endpoints were vulnerable to SQL injection attacks. This allowed me to get access to the information I was not supposed to see and in other case put a serious load on the backend service (making it full scan a huge table)
I have some more examples from my experience along this line, but this is probably something I would love to hear in response. This would show that a candidate has experience with different types of testing, cares and knows about where lack of proper user input validation may lead, can and use tools to help out him/herself in testing, is capable of looking under the hood when needed..
But, I clearly understand, that is not an easy thing to do under the pressure, stress and time constraints of an interview.