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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
Solid approach.
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.