Welcome to Code Chatter, your go-to series for conversational coding insights. What makes this series of questions different from all the others? Well, truth be told, not much, but they're still thought-provoking and fun. Join us as we explore the coding world, one witty question at a time.
If you've been involved in hiring decisions, what factors have typically influenced your choices in selecting candidates?
Follow the DEVteam for more discussions and online camaraderie!
Top comments (2)
That would be more than enough for the topic for a TED talk but let's try.
Debate hugely in advance with what your 4-5 hiring criterias will be.
Not 12 criterias
Not hiring criterias that you thought on the fly like "the guy is not using the right dependency injection framework" or "he has an hotmail adress, that doesn't look professional".
During the interview don't allow yourself to be distracted
Remember that your job is to evaluate the hiring criterias.
Your evaluation is the proof you have done a good job
A proof that you have done a good job is that instead of something super vague
"not our level of quality"
"I don't feel it"
You need to be able to give an objective evaluation of those hiring criterias.
If you can't, your colleagues need to challenge you.
If your criterias are the same than everyone else they are bad
Forget criteria like "he must come from a top school".
Don't try to be like others, there are already others being like them, only you can be you.
The question is what are the most important criterias for your specific companies for this specific role.
Find the hiring criterias in your own stories
Let say you are hiring a junior.
Remember with as much details as possible crucial moments where you realized
So what was the quality or the default at stake in this story ?
That's how you find out what the real criterias are.
In terms of criteria, I typically look for the learner and/or mentor: someone who can give me a reasonable answer to "what do you do to keep improving your skills?" Something indicating a proactive approach scores up (reading blogs/books, learning for fun, or simply keeping up with a fun practical podcast, even if not dev-related) ; something passive like "I learn from the tasks I'm given" scores down (as opposed to "I was given task X, and I thought hey I should also learn about Y to support it" which actually scores up for me...).
In the line of "we can teach technical skills, you must bring the right attitude," I did come up with this double question for interview (I've only been involved in a couple of interview processes though):
In the first, it might be interesting to see whether they highlight status or skills/attitude, but mainly the question serves as a set up for the second one.
The second one looks to see if the person can 1/ keep to the technicalities, and not lambast a person, and 2/ whether they can stay professional in a critique. Bonus points if they can do both, and identify how they tried to resolve the problem. Interview is conclusive if they stoop to name-calling and/or outright blame.
I did come across one post that claimed a litmus-test-question for all situations:
The post contended that the interesting thing will be whether they talk more about improving their higher-ups' status, or whether they focus on how they helped improve their juniors' progression. Are they a mentor (good for your team) or a climber (will leave your team pretty sharpish).
2 cents for your penny 🪙 🪙