Hacker News Reader

I just answer these things honestly: "gosh, ehm, I'm having a hard time thinking of a specific thing right now", and then turn around the question to answer something slightly different, for example a particular difficult bug that I might remember, or a somewhat (not necessarily "most") interesting or difficult thing I fixed recently (and is thus fresh in memory, stressing this is just something I did recently).

They don't really care what the most interesting bug is anyway, they just want to have a conversation surrounding bugs. You can also turn it to "well, in general [..]".

Also don't be afraid to say "ehm, let me think for a second", instead of feeling obliged to answer right away.

The risk is remembering the wrong one.

I usually ask them to answer the questions back to me to see if it inspires a memory, and to give me some time to think about what mine was.

Edit: I say something along the lines of "Oof you put me on the spot now haha. What was one of yours? Maybe something comes back to me when I hear you"

I think people generally ask that in hopes to break the ice or to connect with the other person. So, either they will answer and it might nudge a memory (if they prepared/remember) or they'll blank as well and you'll have a laugh over the question and move on.

It's an interview, not an interogation! I know your livelihood depends on it, but being natural/relaxed helps your odds IMO; as it's less likely you'll get flustered or tilted. I realise this is easier said than done as I'm also plagued with anxieties and phobias, but I never saw interviewing as a stressful situation. At best, you get a job, at worst you forget about eachother in a few days lol.

Sometimes I get the feeling that the interview questions are (consciously or unconsciously) optimized to find people who know when to lie (and lie convincingly) to inquisitor types.

Surprise, your boss' boss just decided to drop in and is asking your new guy some pointed questions about the deadline. ~Tada~, the IRS is sending someone over who wants to interview a few people. Oops, that lawyer that your clients hired are going around and subpoenaing previous employees.

"So, uh, we need you to tell us your biggest weakness. And bonus points if by the end of your story the entire interview team is crying from laughing so hard."

So ideally, the most interesting bug story response would be a story about how awesome you are at finding bugs that are introduced by other organizations than the one you were working in AND make the listener like you.

* Look this candidate can fix bugs. * Look this candidate knows not to talk about the dirty secrets of the org they are (were) a part of. And is able to defect blame to another entity. * Look this candidate makes questioners like them which will hopefully keep too much scrutiny from being applied to them.

You know you can prepare for the interview?

Like write down 5-10 of these questions and answers that are somewhat common.

Write down some anecdote and more or less use the same all the time.

The same with telling about yourself write down 5-10 sentences and use that every time. Of course you probably have to update it from time to time but remember that you don't have to come up with everything on the spot.

You might not get exact same questions but if you have some things written down you can still start by rehearsed anecdote to get yourself going. Because if it is open ended question it might be more important to keep conversation going than "being correct" on your answer.

To me, it looks like questions about things like "most interesting bug" are unintentionally going to be biased towards more junior developers. Once you have a lot of experience under your belt, bugs and fixes sort of all look the same. They're no longer novel. I don't know how I'm supposed to wade through 20 years of experience and recall "the most interesting bug I ever fixed". Now, if I had 2-5 years of experience, that would likely be super easy to recall.

My experience is exactly the opposite: I've never met a senior engineer who wouldn't have one of those bizarre bug debugging / implementation stories.

Such a 'senior' engineer then has not encountered sufficient bizarre bugs. Or more likely he had rehearsed it sufficiently (for a whole bunch of reasons) and you bought into it :)

Yeaaaah. I got nailed with something like this too. I actually started talking about one bug and kind of confused it with another similar bug. I probably sounded like a moron or a liar and they passed.

Was a shame. But I guess I should really rehearse my "STAR" stories :-|

Make something up. Piece together the various details of different bugs you solved in your career or that you were vaguely involved in the solution to something reasonably impressive and coherent. If you are a skilled developer you will be able to make the story convincing. Unless you happened to rehearse your answer to that specific question beforehand, there is no way to reliably deliver a good performance on questions like these. You always have the plausible deniability of "oh, this stuff happened years ago, so I'm a bit fuzzy on the details."