I would push back hard on this question.
An interview question is a machine designed to extract a signal from a candidate. Let's examine the parts of this machine.
"The most" has already been commented on. Why is it important that the answer be the most interesting? Why are you asking the candidate to solve an optimization problem in your interview? If ...
1% of 100 users is a very different issue to 1% of 1,000,000 users - make your team and stakeholders aware of the issue (preferably in writing, with a defect report) and then they can make the decision on the priority / severity of the issue.
It might be a minor issue for you, but a huge issue for the company.
Some opinionated points from my experience, doing mostly development and operations with only a bit of QA and support, for the past few decades. Make of them as you will.
I don't think it matters if bugs are picked up during formal QA, or by developers doing other work, or even customers or consultants. They should be treated, mostly, the same. My opinion is ...
This is called Risk Analysis.
By the book, the over-simplified step is to analyze Impact x Frequency. Things that happen rarely but with huge impact can be prioritized, as well as things with little impact but too frequent.
For a deeper understanding, I would suggest watching Michael Bolton's talk on Risk Analysis. There he questions our biases that may ...
To be honest, I wouldn't be able to come up with any defect in particular.
If I were you, I'd rephrase my questions as situations, for example:
What actions would you take if you had to reopen a defect for the fifth time?
You need to retest a defect which has been resolved by a developer without any further comments or explanation. What actions would you ...
There's already 2 correct answers but I can't stress this enough.
You found a bug, you file a bug report.
It doesn't matter who it affects or how. It could conceivably affect 0 real users and still be a bug and you still file a bug report.
A QA's job is not to determine whether or how quickly bugs are fixed. A QA's job is to find bugs and make it known ...
The severity of a bug is a measure of how important the bug is to the end user: how much it breaks, how badly it breaks things, how difficult it is to get work done with this bug in place.
The priority of the bug is a measure of how important the bug is to the development team. This will take into effect the severity, but also the development time and ...
This is very common.
There are basically 3 parts to the problem:
Track stats to know when the backlog is getting worse or improving, week to week
Figure out what things you need to change to stop making it worse week to week
Clean up the backlog you created, bit by bit
I'll focus on part 3 - the cleanup - but ...
Take a deep breath
and look at the big picture
Talk to folks / your boss about standards. Have a meeting. Agree on standards including items such as special characters. Take short term initiatives this month to reduce long-term repetitive pain next year.
and allow for humans
I've lost track of the number of times I've: typed weird characters by ...
There is a third way, a middle of a road way, if you wish:
don't polute the backlog with many low priority bugs, but group them in an epic or a story that might hold them.
So, instead of having 20 low priority front end (for example) hot fixes that take 10 minutes coding each but you don't want to build a vesion for each of them, you can have a dedicated ...
I would say that product owner (or whoever ultimately decides what the team works on) can decide that some bugs will not be fixed for one reason or another. Then I would close those bugs documenting this fact so that later it is clear what has happened.
I wouldn't close them just based on time as I see it should be conscious decision to close them and time ...
I am terrible at recalling names, places, restaurants, and... bugs I have investigated. I usually ask my girlfriend or my friend to give me a name of a place we have been together or an actress in a movie with have seen. That's how my brain is wired. I don't like it but I get used to it. I guess some candidates might be like that.
But if you task me with ...
A generic answer is: It's contextual; the team and stakeholders (which is who understand better the context) should work towards finding a good way - and periodically analysis its efficacy and improve on it.
However, I see three major approaches. E.g.:
1 - The team defines strict rules for labels:
High: The user cannot use some feature
Medium: The user ...
One of the Context-Driven Testing principles is:
The product is a solution. If the problem isn’t solved, the product
Another way to say this is that software should work for its user, not for some generic/arbitrary/commonly-used set of definitions of how things should be.
When he says
Even if someone gives, the error message is ...
In addition to Michael Durrant's excellent answer and the equally good comments, I'd suggest you consider a few things:
If you have not already done so, devote some time to analysis of your bug backlog. You will probably find some combination of the following things:
The bugs cluster in certain areas of the application. These will typically be the areas ...
I go with reject and move-on.
The downside is that other folks and new folks will keep discovering the bug 'anew' and have to remember them in their head. Which sounds like a huge problem.
In practice I have found that the fear is worse than the reality. Also consider that in many systems the number of bugs based on the combination of different devices, ...
You deal with them the same way as any other bug report. Review the bug and decide what (if anything) to do about it.
If you decide to do nothing, tag it in the bug database with "won't fix" and add a description of a work-round, if available.
That doesn't "pollute" your backlog. When you have decided not to fix them they are no longer in ...
I was asked a question like this at my last interview, and it took me a bit of time to think back and come up with a good answer. This was partly due to a dearth of experience - at that time I had only held internship positions.
After I read your question, I repeated the exercise, trying to come up with my favorite bug in a span of time that would be ...
I would say such a question might spotlight how deep the candidate understands the technologies, analyze the root-causes and is able to troubleshoot issues.
As per my experience I can remember several interesting defects, but I consider them interesting because I did find the root-causes of them in code, or in environment or in human-factor etc.
If a ...
Bug severity is the impact bug will have on the system which is basically derived from but not limited to
The probability of the user getting the issue
Is there any easy workaround/How easily user can recover from the impact of the bug
The application under test (example: A bug of a status not updating in a certain rare scenario can be ...
I don't know if I'm just too literal, but when I get asked these sort of questions, I get hung up on the word "most". It's not too hard to come with a bug, but making sure that I've never seen any bugs that were more interesting is a tall order. So my advice would be to get rid of the word "most". Also, if you're looking for general aptitude rather than ...
I think it's an excellent question. I think it's likely to help you understand:
(a) what kind of technical challenges the interviewee is accustomed to dealing with. (Do they choose a programming problem, a human interface problem, or a systems architecture problem? Do they interpret "bug" to mean not meeting the spec, or not meeting the business ...
The first thing you want to do here is perform some bug triage. Problems your team finds during feature testing will be one of:
something introduced by the changes
something that was there before and doesn't have much if any impact on the changes
something that was there before and has a major negative impact on the changes
The developers in the team need ...
To expand on the other answers:
Note that something is a corner case - don't be afraid to note that an issue is a corner case and is being documented so that when a customer does encounter it, it's on record as a known issue and any workarounds are available.
Resist temptation - When you advocate for a corner case and are rejected, it can be very tempting ...
If you aren't getting good answers, then perhaps you can modify the question slightly to help the interviewee. The word "interesting" can be interpreted in so many different ways, and perhaps that is where your candidates are getting stuck?
Maybe you are looking for the "hardest to find" bug, maybe the "hardest to fix" bug, maybe the "most off the wall" ...
It's a great question because it separates code copiers/script kiddies from actual software engineers.
A well-known, very expensive piece of analytical software owned by a large company (I won't say their name, but their initials are I, B and M) would refuse to allow drill-down access to data via SSL.
The company isn't going to but another service ...
Personally, I ask the other team members if such and such a problem is something we even want to deal with. If we agree it's not, I don't bother opening a new bug because obviously no one cares and I don't like doing work that's considered useless.
I think what's important is that the team, the customer, or whoever decides what quality is with a concrete ...
I suggested this in the comments but figure it works just as well as an answer:
Keep the low priority bugs around, especially things that aren't hard to fix in principle. Use them as onboarding exercises for new people. They'll be just as good for learning codebases and team processes as anything else; delays from lack of experience won't disrupt anything ...
I would like to consider each of the cases separately:
Low Priority - Low priority bugs do not stay low priority always. They always have a tendency to become high priority if enough of the users complain (or a important customer raises it). Closing doesn't seem to be a good option.
Edge Cases - Remember Murphy's law. These tend to happen and they happen ...