For candidates with a clear focus on a specific technology/library/framework/… I always ask "In which case would you not use that?".
Or a similar version of that question.
Like "For which kind of project would Angular be a bad architectural choice?".
Because one size never fits all and it's always a good discussion-starter.
I don't ask weird syntax-questions. It's just rude. It doesn't tell me anything at all about the person. It's exploiting their nervousness for no gain. I want to know if they will make the right calls, and produce working, readable and tested solutions. You know, the stuff that is not one google-search away.
100% agreed on this. All the "trick questions" in this thread are basically intended for the interviewer to flex on the candidate.
A better twist on these would be "You write this code, and instead of getting X behavior like you wanted, you get Y behavior. How would you go about debugging this?"
Plus, the questions about "When do you not use this" are also great, because not only do you weed out candidates that are fully invested in one popular thing, but you also get some information on their priorities in choosing a tool for a job.
Remember, interviewing is a two-way street. It's just as much about you assessing a prospective employer/boss as it is them assessing you.
If an interviewer tries to "catch you out" with some arbitrary, illegible code or tries to belittle you because you don't know answers to some esoteric problem then it says more about them and their approaches to work than it does about your knowledge/abilities.
Most def, it's more a conversation-starter, without a "right" answer. If they can argue their claim, perfect.
I think I could argue why React should always be used, sometimes be used, and never be used :-)
Absolutely. Evidence about ways of thinking/approaching a problem are much more revealing about a candidate than their ability to interpret obtuse code like a compiler.
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.