I recognize that I’m not perfect at interviewing and want to give people the opportunity to brag about themselves and express something I might have missed.
Most any engineer or developer above a junior level position should have at least one of these stories. It also gives you the chance to ask what they learned, how they fixed it, what resources they used, what they did to prevent it in the future, etc, etc, etc. It's also a really humbling moment to have to explain one of your failures and will show you a lot of the person's personality when they're explaining it.
The two big negatives I have seen with this question is either someone becoming combative as you ask more questions, or they go full 'used car salesman.' If either of those happen, you can safely run away screaming from the interview.
This is a gut/understanding question that is best given/asked by another technical user and has been a solid divining rod for interviews that I've done.
I have my own go-to example that I'll use if they give back your type of answer (which has happened). I messed up packaging a demo version of our software that almost sank a 300k sale (~5% of revenue on the P&L for that year).
Was I going to get fired? no Did 23 year old me think I might get fired? yes
Essentially it boils down to what's a large mistake you've made while employed (or otherwise) and how did you resolve it.
"If there was one problem here that you could snap your fingers and magically 'fix', what would it be?"
Then I usually follow-up asking what they consider the "fix" to be.
If there's a systemic problem at the company, usually the answers among the different employees will be quite similar. If I notice that, along with possibly similar solutions proposed, as I interview up the food chain I'll ask specifically about it. If I get a dismissive response, then I know to turn down any offer.
"There's a feature you and several other co-workers are building. The deadline is 3 days from now.
You and 'Co-worker A' are tasked in building a module of that feature. You've already written several classes and tried abstracting some repetitive parts that would allow you to hit the target deadline for the team.
However 'Co-worker A' has also worked on those same classes and wrote more methods that are too tightly coupled and doesn't read well underneath. He claims this is a better design than yours just to finish the feature and doesn't budge on changing it during code reviews.
How do handle this situation?"
I like this question since there's a wide range of answers of how people deal with conflict under pressure.
1. "What is the hardest thing you've ever done?"
The answer can be personal or professional. What the candidate accomplished isn't as important as how -- and why. What were the hurdles? What were the roadblocks? Did the candidate seek help? Does the candidate credit the people who helped?
The answer also can provide insight into how the candidate defines "hard," and how their perspective align with the challenges your business faces.
2. "When have you experienced stellar customer service, and how did that change how you deal with customers?"
This question is a great way to see how candidates define "stellar customer service" -- not just as they experience it, but also in the service they expect themselves to provide.
When interviewing someone senior, they'll ask back a lot of good questions. The good candidate tries to identify what props up the structure, whether it's code or certain people. Especially in a startup, where sometimes even the code owners forget that they have that big batch of unpaid technical debt.
The passive candidate is usually the ones we try to reject, because when something bad happens, they won't flag it, and when you don't ask them to do things, they just idle instead of improving random things.
I usually word this is a more "work-safe" way, but I find that this question has the benefit of both relaxing a candidate, and giving them a great opportunity to talk about their experiences without a filter. I usually follow-up with questions about the tech if it's not something I'm familiar with, and some questions around what they did to get around the issue, or what they'd do if they could change the particular bit of software.
"What's your least favorite feature of <language X> and why?" Where <language X> is obviously part of the tech stack that you're hiring for. You can tool the depth you're looking for in a response based on the level you're hiring for as well on this.
Don't even get me started on the GIL in python...
The answer will quickly reveal their methodology and how they approach a project. Generally people don't use tests when prototyping. Some people use tests when things break, others write tests before they code something.
Each type of response is appropriate for a specific role or business and that question is good at determining that.
I feel like answering that testing needs to be appropriate for the use case is the only "correct" answer to this question. If a candidate was overly dogmatic about one form of testing that would raise red flags for me.
Would it count if I had walked around the halls of the Pentagon, looking for good stuff that people had left out in the hallway (and therefore presumably excess and no longer wanted on their part), and then moved it to my office?
Or the time that the Team Chief of the Logistics Readiness Center in the National Military Command Center had locked himself out of his own office and didn’t remember the combination, and was supposed to be briefing the Chairman of the Joint Chiefs in five minutes? All I did was brute-force the combination, but I was able to do it quickly and he wasn’t too late to his briefing.
Examples of the kind of thing you would be looking for would be very useful.
“What’s one thing you wish you knew before you started here?”
Makes the interviewer think and its hard to BS, so you’ll usually get an memorable answer.
PS. we are small SAAS, hence any one's contribution can clearly be seen. (https://www.testinvite.com)
It was for an Engineering Project Manager role. Yep, got the role.
He asked what my biggest failure was and that was very jarring initially.
Interviews are effectively worthless for engineers. Figuring out where to eat isn’t.
Totally unreasonable and probably illegal, but still something that crosses my mind in interviews.