Comment by throwaway271818
18 hours ago
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.
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.