

Interviewing the “Passé” Way, For a Reason
source link: https://no-kill-switch.ghost.io/interviewing-the-passe-way-for-a-reason/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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.
Recommend
-
42
After almost three years at Jobr/Monster, I have decided to leave to pursue a different opportunity. This gave me the chance t...
-
42
Hello everyone, my name is Atomic Artichoke, and I’m the newest employee of the interviewing.io team, having joined a couple months ago as a Data Scientist. Atomic Artichoke isn’t my real name, of course. That’s...
-
67
Jacob Schatz (@jakecodes) is a staff engineer over at GitLab and was kind enough to share how he conducts job interviews for technical positions and his thinking process for them. Technical interviews are talked about oft...
-
24
Responses You have 2 free member-only stories left this month.
-
11
Hello! I just finished interviewing with Google and wanted to quickly catch you up on so...
-
13
Good insight on interviewing programmers Kaushik Gopal If you’re in the business of hiring programmers, the article linked is a must read. It’s concise and a gold read. No excuse for...
-
6
This blog post is about to show a new way of writing web pages (blogs, tutorials, documentation…) about Reason. What is Reason? Reason is not a new language; it’s a new...
-
11
Six Tips for Interviewing Software Engineers When You Aren't Technical Mar 10, 2020 Interviewing engineers when you aren't one is a regular human resources task that tends to give non technical folk fits and f...
-
4
Tech Interviewing is Broken - A Suggestion Dec 18, 2016 So Medium this morning tells me that person X is following me, I forget who – that was on my phone and I'm writing on my lapto...
-
8
What Is Pixel Pass and Is It the Best Way to Buy a Pixel 6? By Alvin Wanjala Published 5 hours ago Pixel Pass bundles Google's l...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK