I mainly ask this of QA people when I interview them, but I have started adding it to my general interview questions.

Let's face it, if you have been coding long enough, and release your application to the world, there's a 100% chance at some point something will go wrong. It's part of life and it's nothing to be ashamed of.. most of the time.

The key to answering this question is address it honestly, but with all  "negative" questions, show what you have learned from it. For example, say you had an application launch, and when you turned it on, it didn't perform well because it was wildly successful. You could describe this, but make sure you say something like "now, before I launch, we create performance tests and build in performance indicators so we can detect these issues pre-launch, and monitor the application proactively." In a word --> what I learned from it.

One of my classic "flubs" was for an auction I wrote the software for. It was live on TV, and the client had me make a database change the night before going live, and we didn't get a chance to adequately test the change (which is to say, nothing more than my rudimentary testing, and my client just didn't have the time). As the auction commenced, the save method was failing on certain items, and I quickly saw the problem and fixed it LIVE on national TV. My lesson --> NEVER let a client tell me they don't have time to test, and no one even knew it was failing.

As an aside to this, the reason no one knew there was a problem is I had very good error handling/trapping and logging. The application adequately handled the issue, and I was able to monitor the application logs remotely, and immediately saw the problem and knew what the fix was.