When it comes to recruitment interviews, there's an overwhelmingly popular opinion (on the Internet) that one should test candidates in conditions that do resemble real-life work scenarios as much as possible. Tasks & challenges should mimic the ones that the candidate would face in her/his daily work. Everything else ("how many golf balls would fit into Opel Corsa?") is the subject of laughter and mockery.
I dare to disagree. My interviews are nothing like real work (but TBH we have a final stage of a "trial day" within the actual team, mainly to check the chemistry between a potential new-joiner and the team members and to give her/him a chance to verify what we've said about the company).
Why to go against the trend?
A recruitment interview is a freaking intense experience. We have a strictly limited time - we can't build full context to get someone up-to-speed with the product details, local specifics, whole workflow, etc. Of course, we can try easy, shallow, "mundane" scenario, but let's face the truth - we need to evaluate candidate's capability to tackle TRULY demanding stuff (most likely 10% of the actual work (s)he'll perform - but that part truly makes the difference).
The purpose of the interview is not to emulate work 1:1, but to answer certain questions: about particular personality traits, attitude, aptitude, mindset. Technical skills can always be taught later - if someone has a matching motivation, proper engineering foundation, is bright enough and has an ability of structured abstract thinking.
Show me your brain
That's why my interviews are aimed to check how does the individual think (instead of verifying her/his memorization skills). How does (s)he approach problems, split them, classify them, explore possible solutions? When does (s)he abandon the path that doesn't look promising anymore? Is (s)he able to effectively share her/his thoughts (verbally, graphically, in code)? What about focus - does (s)he navigate in terms of a given goal or roam chaotically around? And in the end ... is (s)he actually having fun (when solving challenging problems)?
Call me old-fashioned, but I do ask abstract questions as well. The problems candidates are facing at my interviews usually have NOTHING in common with the company's domain, BUT they have a super-low entry level (e.g. they are about common problems everyone encounters every day): building up the context takes seconds (literally), so the candidate can focus on tackling the problem, not understanding its basics. They also share one another characteristic: they are picked to be unique, intriguing and memorable - so regardless of the outcome (whether the candidate joins us or not), our interview remains an interesting experience in her/his memory.
And how does it work?
There are ones who are surprised and do criticize such a form of the interview. They usually ask whether these exercises truly represent the everyday problems of this organization. Some even get irritated (very few) - but no-one has asked to stop the interview prematurely.
Honestly, I don't mind. These days candidates get very picky - they have so many offers available in the market, that the less gritty ones don't even want to participate in the interview that exposes them to the challenges out of their comfort zone (e.g. which is - syntactical language problems or knowing the specifics of the framework). It's their right, but it also means they are definitely not the people I'm looking for.
P.S. Of course, sometimes (rarely) I look for a high level of expertise within a specific technological niche - that requires a different assessment and it's a completely separate topic.
from Hacker News https://ift.tt/3fhjQ4l
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.