Try to find an angle that the listener might find interesting, rather than trying to puff it up to make it sound as cool as possible.<p>For instance:
I was working with the development team for Time.com to fix a major security vulnerability. It basically took 3 days of staying up all night debugging and going back and forth with their team, and we finally found it - some dumbass included a javascript library that has a well known bug hidden in a minified mess.<p>Why is this bad? Namedropping (time.com), puffing it up to sound bigger than it is (debugging something for three days is perfectly normal, if you're staying up all night then it's down to your own poor time management), name calling and blaming others (the dumbass), jargon (javascript library, minified), assuming knowledge that there's no reason for them to have (well-known).<p>Instead: I got to work with one of our really big clients to figure out a security vulnerability that was really stumping everyone. We spent a couple of days debugging it, so that's probably why I've had my head in a cloud lately because I've just been thinking about it non-stop. In the end, we found a bug hidden in a really big block of third party code that's written in a way that makes it very tough for humans to read it, but luckily it's a known bug that some other company had documented, and someone found a blog post about it that let us connect up the dots. All six of us working on it were really relieved when we figured it out!<p>Why better - gives credit to others, explains why it was difficult, doesn't use any technical language, leaves openings for more questions (why is the code hard for humans to read? who was the big client?), doesn't try to exaggerate the severity of it.