Comment by psadauskas
17 hours ago
I had an interview many years ago, that wasn't nearly as traumatic, but the interviewer asked me about my failures like 4 different ways.
- Tell me about a time you made a professional mistake. - Tell me about your biggest failure. - Tell me when you last shipped a bug. - Tell me when you took down production.
Never asked me about my accomplishments, or the positives. I'm prepared for being asked about making mistakes, and have a few examples ready to give depending on the job I'm interviewing for, but to get asked so many times in a row was just deflating.
I'm glad I didn't get that job.
I conducted a few hundred software engineering interviews while working for a non-tech corp. Aside from technical problem solving & programming interviews we'd also ask a few behavioural questions -- including asking about times where the candidate had made a mistake at work, or a time at work where they were very frustrated.
What we were looking for
- people unwilling to admit they'd ever made a mistake -- red flag
- people who could reflect on the situation and say what they'd do differently in the future
- ideally, people who could use their mistake / failure / bad situation as an example of how they then took initiative to improve things by doing blah blah blah
People who were able to give an ideal response had clearly practised for this kind of question & knew how to play this part of the interview game.
Behaviours valued by one type of potential employer may not be valued by another. Small businesses & startups might value folks who take initiative and have a bias for action. In contrast, regulated megacorps might value folks who are great at consulting stakeholders and getting buy in before making changes, and steer clear of people they believe will go off and do stuff unilaterally.
One rule of thumb for handling these kinds of behavioural questions is "STAR" -- situation, task, action, result. Use the prompt for the question as a way to pick an example, then figure out how to frame an answer that shows you doing something to improve the situation. There's a fair chance that your interviewers are trying to mash your response into a STAR format in their own notes, even if they don't hint for you to respond in this way.
Right, I'm aware, and like I said, I expect those questions, and I have several examples I'm prepared for, and can tailor it to the interviewer. Like if it was a devops role, I could talk about when I took down production and what I learned from it. Or I could talk about when I failed to properly manage a junior if the role was more management-oriented and what I learned from it. Or when I badly architected a feature, and what I learned from it, and so on.
What I _wasn't_ prepared for was 4+ of those questions in a row, and _zero_ questions about my experience, or strengths, or anything else. The questions were more of the type "when did you stop beating your wife?". In retrospect, I think the interviewer already had someone they wanted to hire, but were forced into it by HR due diligence or something.
Where I work we divide up topics and questions so we aren't all asking the same thing in an interview. This guy might have been given the "handling failures" scenario.
It's possible that's what happened here and the interviewer also just wasn't very good. Some people just really suck at interviewing.
I think a lot of technical people interpret interview questions literally. Like yes of course the prompt starts with a negative - but you don't actually have to answer the question fully and literally, this isn't a college exam.
You could for example start talking about how you thought something was a colossal failure only to realize looking back that it was an incredible learning experience and how sometimes the only way to learn big lessons like that is by trying the experiment. And how it's only a failure if you stop. But you kept going so it wasn't really a failure.
Honestly we should probably take a page out of politicians' or media trained people's playbooks and not even answer the question as asked but relentlessly steer towards what you really want to talk about.
I too am capable of waffling to an interviewer. My favourite "took down production" story is a segue into why, when your interns ask you to look over the command they're about to run against the prod environment because they're not 100% comfortable, you should do it, and a broader chat about infrastructure-as-code and review processes.
I don't think it's good practice for the interviewer to require the ability to dissemble from software engineers, though.
Is it too much to ask for interviewers not to ask questions where the "right" answer is to give a BS answer?
Interviewing is difficult IMO - asking imperfect people to judge imperfect people in a short time.
In my experience, which is not that great, it's the attitude that people have which is more important than the perfect answers. You're usually hiring for a team so someone who is prepared to be decent to others is essential and IMO their 10xness is much less important than this.
Then I want someone who is interested in computing or things in general - not purely motivated by the money. That sort of person who is going to try to do a good job for the sake of it and who wants to learn something new - who will be ok with doing things they're not yet experts at.
These 2 sort of areas are not easy to have together IMO. If I find people like this I am eager to work with them.
What I get from being the interviewee is that other people are not always looking for these characteristics. They're often looking for someone they can dominate. This is like my point about being part of a team but taken further obviously. In a team you cannot have everything your own way but you get to put your point across and see if you can convince others, as a peon in a feudal system you will have nothing your own way and must not only do but also say and pretend to think what you are told.
Bullshit is just really a test for whether you're amenable to being part of the propaganda. Some people have no trouble doing this but I think there's something about being a programmer that tends away from fakeness. That's not to say that we haven't got an overload of bullshitters but at the root you have to be able to make things that work.
1 reply →