What is the best interview question you have asked/have been asked? It can be either technical or professional. If possible please provide what you are looking for in a response from a candidate.
“Is there anything I didn’t ask that you wish I had?”
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.
"What's something that you f*'d up on where you thought you might be fired for it?"
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.
Well aren't you lucky! And in my experience with this question, there's a big difference between "felt fireable" and "is fireable", which also gives insight.
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.
So, this is from the other side of the table. Every place I interview, with every person who interviews me (phone and in-person), I always ask:
"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.
A deadline 3 days from now and we're still discussing how we're going to approach it? Does it need to be in production? Does it need to be tested and deployed? I think I'd first inform our stakeholders that we've got a delay and are not going to make the deadline unless we drop this feature.
Cool question, I would probably agree just to get the feature out (if it's really essential) but at the condition that the first thing that will be done after release is to change those methods otherwise it will never be 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.
Not a single question, but I find the best thing to do is just have a discussion on the software architecture, business problems, organization chart, etc.
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.
"Tell me about a time when technology really pissed you off"
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.
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.
> Each type of response is appropriate for a specific role or business
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.
I like the YC question: please tell me about the time you most successfully hacked some (non-computer) system to your advantage? In my team I place high value on resourcefulness, and seeing whether people can come up with solutions rather than deferring to their superiors with every difficult situation.
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.
Remember that interviews are also castings for new teammates so present yourself as a person they would like to spend time with. So asking people that you will be probably working closely with about their hobbies and interests is a good way to find connection with them.
"How do you think your contribution to the business can be calculated? Please make me a step by step calculation so that hiring you is actually a good decision for our business"
What? The implication of interviews are worthless for finding the best senior engineers is not to hire random people off the street. It's to hire people based on their previous work, reputation and recommendations.
Aaaah no, no no no. Hiring based on reputation and recommendations is also terrible, and not just because it's tautological; it also doesn't work. The industry is full of people with sterling reputations gradually failing upwards.
I used to joke that a candidate should drive the group to lunch. There was a correlation between someone’s coding style and the way they drove a car in heavy traffic with others in the car.
Totally unreasonable and probably illegal, but still something that crosses my mind in interviews.
"What's your developer story?". Like, I ask them how they ended up being a developer. Not something that helps me judge them, but the stories sometimes are pretty interesting and sometimes shows if someone really loves their job, or are a developer just for the sake of working.
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.