I understand the value of doing a good match between a company and the various candidates. It is a very old problem (not only in modern workplace) which needs solution, thus every help is acceptable.
Though, you seriously need to…
Yeap, I said it. Apart from the fact that most software engineers hate exaggeration in the job adverts (like hackers, 100x engineers etc) here is why you should avoid it:
Even the creators of the language, sometimes claim they don’t know everything. I couldn’t find the original link but even the creator of C++ says he knows at max a 70% of the language he created. Here is a quora reference though.
Another example, more pragmatic is Guido van Rossum, the creator of Python. He recently stepped down from the day to day management, so there is a strong chance in a few years, he is not aware of all minor details.
And finally, people that are real gurus on something, in my personal experience, are extremely humble as well and will never admit having excellent knowledge. They don’t need their words to prove something. Their success screams for them, instead.
Socrates one of the most charismatic and highly intelligent people ever walked on this planet, was always saying that if he knows one thing, it is that he knows nothing. Why do you think you can do better with your candidates?
Even if such engineers exist and are willing to interview with your company (let’s be honest, they probably not looking for a new), do you realize that they will probably have extremely high standards?
Not only in terms of salary, but also in terms of working conditions, company technical competency, technical and personal quality of colleagues, tolerance on technical debt etc. Are you confident you can provide those?
Let’s say you managed to get the excellent-knowledge-guy for an interview. If his skills are excellent, how will be able to verify how good he is? You can surely confirm he is great, but what about excellence?
Unless you are creating…a collection of excellent software engineers, this is impossible by definition.
Of course, you deserve to hire great people which happen to be great engineers. So, what to do instead?
Do you mean to ask for a minimum set of experience years? This is not a bad metric, though, years of experience say nothing about the value of the software engineer.
Do you count the years, based on 8-hour working days? What about those who have a regular job in the morning and work on their startup during the nights? Do they have twice the years of experience?
How do you compare someone who has 10 years of i.e Ruby and does the same thing day-in, day-out and someone who has built 5 highly successful open source projects in the 3 different languages?
I believe you should give some flexibility on who can apply (discourage junior people, if you are looking for an architect), and ignore false-positive metrics.
Do have a system to filter out the good ones, based on more objective criteria (code challenges, designing a software system on a whiteboard etc).
A good starting point would be to define the ideal candidate having worked, with a certain family of software eg one where he was focusing on high-performance computer vision libraries. Or whatever suits your case.
But clarify that if the profile of the candidate is not ideal, according to the advert, you are happy to give him a chance to prove himself. Don’t disqualify people based on silly criteria.
Knowledge of languages say very little about a person competency, years of experience can be a false-positive metric.
That deserves a section or maybe an article on its own. Though, in a nutshell, an engineer with a great portfolio shows 4 things:
Never ignore a candidate who has invested a significant amount of time, building a related to your needs portfolio.
Thank you for reading this article. Technical recruitment has done great steps during the previous years. There are still out-of-tune-stuff though, but things are getting better and hopefully, they will continue to do so.
If you have any questions or comments, feel free to write them below.
Originally published at perigk.github.io.