A brief guide on technical hiring
In my 10+ years of software engineering, having been through hundreds of interviews with technical recruiters, hiring managers and peers, I've had the chance to see many different hiring processes.
Sadly, I've witnessed first hand that besides some glorious exceptions, there's widespread confusion on how to conduct an interview, and especially a technical one.
Poor technical interviewing & hiring processes have numerous negative consequences such as poor hires, missing out on great talent, negative company reviews on company review platforms or the network effect of poor recommendations etc.
Whether you're developer, a recruiter, or just curious, here's my non-exhaustive list of things to keep in mind:
Don't
ask the candidate to complete a take-home assignment as a strict evaluation step, especially before even a first HR screening call
Fortunately this has began to fade away (and if you come across it as a candidate, run). Sending a coding challenge to a candidate you haven't even met is a big red flag (for them, but for your process as well). It is supposed to delegate some of the recruiters work onto the applicant, but it does so poorly. It also feels like culture and personality are a 2nd class citizen criteria. Most importantly, it is inefficient and largely non-representative of someones' technical skills.
Do
provide the coding challenge as preparation material for the next step
If the first cultural fit call is a yes from HR/tech), plan a pair programming session with your engineering team (whoever is doing the tech screening). Provide a problem you will work on during the call in advance giving the candidate the chance to 'warm up'. It’s optional. Have a look at it, code a bit, or not, no obligations there.
I hear you asking "Why provide the questions in advance, giving the candidate the chance to prepare, wouldn't that mean they can find all the answers beforehand and memorize them?"
During a hiring process you need to "extract" the maximum amount of information for the candidates' skills, in the minimum amount of time possible. Having the basis of a "challenge" (an application, a script, a UI) complete in advance ('async') gives you ample time during the call to ask more pertinent/targeted and ultimately advanced questions. It also reduces candidate stress, helping them to demonstrate the full range of their abilities during the call.
example: The pair programming session can be used to discuss the candidate's choices (why did you use local state and events vs a State Management solution, why did you go for the factory pattern vs the builder pattern). This way you get a better, deeper understanding of their skillset and background, instead of losing time setting up boilerplate copy-paste code anyone can generate in minutes.
Don't
Try to defeat the candidate
Quoting Jake Archibald, ex-Google Chrome architect,
"The candidate is competing against other candidates indirectly, they're not competing against you"
领英推荐
It's hard to make some people get this. Often engineers see the interview as a chance to prove themselves by making the candidate look bad. They're converting the process to a pissing contest, a quiz of pointless trivia. Remove these folks from the hiring process IMMEDIATELLY. (I'd even go as far as saying remove these people from your company). Your goal should be to build a technical discussion where you use real use-cases from day to day problems and discuss possible solutions. That will indirectly give you the chance to discuss code but based on actual real-life examples.
Do
Help the candidate perform, it’s to your benefit
The first and most important job of the interviewer is to help the candidate perform at their best and showcase as much of their skills as possible. Some of the best hiring processes I've been in ensured the candidate was prepared with actual material, book suggestions or blog recommendations. Some of the nicest pair programming screening calls I've had were the ones where the fellow developer helped me complete a challenge by unblocking me from a dead-end with a tip or an idea. (the fact that you can't remember a function signature by heart doesn't mean you're a bad developer for christ's sake). Big part of our job is to being able to FIND the solution to a problem. (yes, I'm claiming that being able to read documentation, looking on search engines or SO using the proper tags, queries and digging through hundreds of results is a skill that's worth assessing)
example: explicitly ask the candidates to open up API documentation, Programming Language References, or other resources while you’re having the call. if you see the candidate get stuck with one point in the challenge, find a way to help them move to the next step without giving away the solution. if you see the candidate struggle, don’t act frustrated or impatient. pair programming with someone you don’t know is by default awkward. make it as pleasant and as casual as you can. Provide good tooling for the candidate to feel comfortable with ( they can use their own code editor / IDE and share screen or use the VSCode live share feature )
Don’t
Send a generic rejection letter, or worse, no answer at all.
I’m not even sure why we need to explain this.
No one is happy when receiving a rejection, and sometimes HR is also not comfortable sending one, but it's inevitable to happen.
Do
Provide detailed feedback, via a call if the candidate went far in the process
Devoting hours in technical challenges, calls and screenings should at least be 'rewarded' with an honest, constructive, helpful feedback. The feedback should be areas to improve, what went well, what didn't go as well, or potentially other positions/levels in the company the candidate would be more fitting for. (example, you're applying for Lead but you maybe be a fit for a Senior role with the possibility to grow - several people would accept an offer like that).
How detailed the feedback should be, is analogous to the time the candidate invested in the hiring process. Someone who had 4 calls and reached the end of a pipeline, would deserve a phone call, which is more personal, and more casual as opposed to an email template.
example: I’ve gotten some excellent recommendations, I recall someone pointing me to codewars.com to sharpen my skills when I was starting out. If you use a scoreboard where each skill is assessed separately, you can communicate the good and the not so good areas. you might be also be open in saying ‘your profile is great but we have no role for you now’ (it sucks a bit, but at least it’s honest)
Bonus don'ts