undefined

points

[-]

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.

by psadauskas14 hours ago|

parent|

[-]

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.

by y1n012 hours ago|

parent|

[-]

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.

by throwaway27181819 hours ago|

prev|

[-]

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.

by strken18 hours ago|

parent|

[-]

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.

by pacman12818 hours ago|

parent|

prev|

[-]

Is it too much to ask for interviewers not to ask questions where the "right" answer is to give a BS answer?

by t4356210 hours ago|

parent|

[-]

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.

by pacman1286 hours ago|

parent|

[-]

I've been on both sides of the interviewing process and I agree with you.

It's the questions like "what is you greatest weakness?" that tick me off where an honest answer at most places will probably kill you chance of getting the job. Instead you are told that the "right" answer is to pose a strength as a weakness. I don't see the point of asking questions like these. What are you learning about the candidate from getting the expected BS response?

Ironically, I think having the self awareness to recognize your own weaknesses is a great strength, but this question subverts this.