This is a tough question to answer because it really makes me stretch my brain to find something good.
But this comes to mind: If you are asked a coding question that is trivia you'd always Google while on the job: Maybe you can have the courage to say you'd Google for that answer! But to make it be known that you aren't dodging the question, follow up in the same breath with something that demonstrates that you understand the underlying principle.
The question was loaded or lazy. Recognize the game and reply as such, and hopefully without coming off as overly arrogant in the process.
(Sorry if that was a bit off base with the question, but it's all I could think of)
Not off base at all Ben! That's exactly the kind of stuff this discussion is for!
My favorite relates to a friend of mine, although it's not exactly a pointless question that it relates to.
A few years back my friend was interviewing for a mechanical engineering position at a manufacturing company. About 10 minutes into the interview, he was asked to model a part in AutoCAD based on an actual physical sample of the part together with a simple description. He read through the description, spent about two or three minutes examining the sample part, and then caught the interviewer completely off guard when he asked whether the sample part or the description should be considered the authoritative source of information. He had, somehow without even picking up any of the tools on the desk before him, noticed that the part was made of a completely different type of steel than the description called for, and was a few tenths of an inch too short in one dimension compared to the description. He got hired on the spot.
Thanks for sharing! Talk about unequivocally proving you're the person for the job!
Interviewer: "This will miss the mark and not work"
"Oh yeah? How much of a pay raise do I get when it does work?"
How do I apply this technique to my next interview?
Sounds to me like Austin's friend was able to take advantage of a rather unique situation where the interviewer was under-prepared and/or hadn't themselves taken the time to answer the question they asked beforehand. I would say to apply this yourself, ask excellent questions, carefully examine the criteria and parameters of their "gotcha" or "skill-testing" question, and make sure you are extremely well prepared and hope you get an interviewer that is not as prepared as they should be (happens more often than you'd think.) A lot of interviewers are engineers themselves and are taking time away from solving business problems to propose the technical equivalent of Reader's Digest riddles to candidates. If you see an opening like this, take it and hope they appreciate the cajones it takes to call them out like that.
Barring that? No clue 😜😜😜
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.