Man-function or stop hiring technology
I did not think that I would be going to write an article about this, and especially not on Habr, but, as they say, “something needs to be done about it”. Got sick.
During the 10 years of my career, first as a System Administrator, then a System Engineer and DevOps, being a simple executor, technical and team lead, I visited and conducted dozens of interviews with companies of different sizes in different countries and took part in forming requirements when searching for employees and ... guys, hiring is dark.
I think that the style and way of hiring that lives and flourishes now harms both employees and companies.
I'll try to explain why.
It all depends on the plane in which to consider this issue.
From a business point of view, an employer is looking for a unit that can perform the required functions at minimal cost.
At the level of department heads, deputy directors, etc. the requirements are somewhat changing and detailed - they need a person whose salary is within the budget, which can be found on the market with available funds and who will fulfill the tasks that his manager will set for him in the interests of the business.
At this level, the specific money that the business is willing to pay for the job is usually determined, and HRH comes out of this level to find an employee who fits the criteria, and then those candidates who have passed the first filters come for an interview.
That's all about this is to talk.
In order to run the recruitment, you need to know who to look for.
For this, the requirements for candidates applying for a vacancy are formed.
In large companies, for the sake of standardization, there is also a list of “how to conduct interviews” rules and even internal trainings with the assignment of the title “licensed interviewer”.
And it all works disgusting.
Depending on the structure of the company and the competence of managers, the list of requirements is formed in styles ranging from “we need a frontend programmer, usual requirements”, to “we need a frontend programmer with knowledge of <list of 30 items> , work experience of at least 23 months and mandatory experience in FMCG companies for at least 2 years . "
Sometimes even technically competent employees are recruited who are given the task “to form a complete list of skills and technologies that you use in writing”, and all this with some adjustments leaves for the vacancy in the “requirements” block.
In even rarer cases, the task “form a test to check the necessary knowledge” comes in, which gives rise to various test tasks on Hackerrank, consisting of tasks infinitely far from workers.
Whatever approach to the formation of requirements from this range is used - it does not work well.
The technology stack in the industry is huge.
More than you can submit or write in the requirements (although there are three-page listings of requirements).
Moreover, the stack in the company will also change sooner or later.
The leaders will change, the software platform will change, a new vendor with a profitable offer will come.
But the people - will remain. If they don’t escape or don’t have to fire them, they are not able to perform new functions.
The desire for formalization is understandable. It is psychologically safe and relieves pressure from the head.
But it interferes with hiring and further work .
Specialists in hiring miss a huge number of talented people simply because they did not match the keywords.
Look at LinkedIn with his “you have 27% of skills with this job.” Or on the first page of the issuance of HH / Indeed / Glassdoor, for vacancies with foot-jacketed requirements and knowledge of technology.
Following the rules, interviewers ask delusional questions , realizing that they have nothing to do with future tasks. Most often, they themselves do not know any answers except those written in the questionnaire and will not understand the correct answer if it is non-standard.
Especially when the company has many specialists with different specializations, and the rules and questions are the same for everyone.
Without following the rules, interviewers begin to rely on their own, perhaps very specific knowledge and ask questions that again, in no way help determine how a person will perform the tasks that will be in front of him.
It may be from another project to develop a specific system, it can (not) love ML very much, it can (not) love Go / Python / Perl / C # / C ++ / C / Java / Scala, despise or adore Puppet / Salt / CFEngint / Chef etc.
Just because he is a man and he has nothing to rely on, except for his own experience and taste.
Such job interviews are stressful for everyone involved.
Most of the interviewers are still unpleasant to write negative reviews on candidates. The impression of candidates after such interviews is also far from positive. Managers are upset that the vacancy is not closed, HRy are forced to send more and more letters and messages, wondering what the candidate provided by them didn’t fit, because "it fits the requirements perfectly."
These problems arise from the fact that the employee search system is designed to find not a good employee with a head, but a certain function, trying to describe it through the maximum number of requirements.
Lists, keywords, tags, lists of questions for interviews in the style of "how many arguments the substring function takes" - they spoil everything.
Such a selection system, on the one hand, generates professional “interviewers” who fall into positions that objectively do not pull, on the other hand, prevent normal specialists from coming to the company and bringing many benefits to it, because they used Puppet instead of Salt, wrote in Python 2.7 instead of 3.5, they used Symphony instead of Laravel, Docker, not RKT, Docker Swarm, not Kubernetes or etcd, not Consul.
All tools are changed and replaced.
After 1-2 years, the current knowledge of the tools will be irrelevant; after 5 years, no one will remember the majority. Everything will have to change, the function of the employee may also change with the environment and projects.
In the overwhelming majority of companies there are no tasks where you need to know 8 sorting algorithms and remember all the Spring Boot Core functions or what npm libraries he knows.
It makes no difference what configuration management the person knows at the start or how many arguments to java he remembers.
If a person knows how to perform a certain function in a given framework, then this does not at all mean that he is a good specialist.
This means only that he, by coincidence, is able to perform a certain function here and now.
In fact, based on my experience, other criteria are much more important for a candidate (and a future successful employee):
Look at the large successful companies, their requirements for candidates. They minimally specify technologies, just to designate a certain base on which to rely.
Here is what Yandex writes in its vacancies in the position of the System Administrator in the requirements:
And that in the wishes:
But the requirements for the position of SRE in Google :
And here are the wishes:
It is much better to pay more attention in the job description to what the company does and what the candidate will have to do than to list all 10 frameworks that are used in your projects.
Change and approach to interviews.
Ask at the interviews for the basics, ask to argue out loud, ask broad questions (and be ready to hear more than once the answer that will be a surprise to you), build a dialogue, communicate, share information. Look for points of contact, try to understand how a person thinks and why he thinks so.
Most of the people to whom I asked this question (as well as myself) agree that in fact 15-20 minutes of communication is enoughto make sure that the person fits and determine his level and within 10 minutes you need to realize that the person does not fit perfectly.
At the same time, tests and deep technical surveys have virtually no effect on the result .
Yes, at this time it is necessary to strain the brain and communication skills of those who conduct interviews.
Top management must learn to trust those who conduct these interviews and who, in the future, work with hired people.
We'll have to abandon the tags, crazy (and thoughtless) filtering and unnecessary, but so calm, standardization.
You will have to take extended responsibility for the result of hiring, because “Here are his test results, he answered 98% of the questions, I don’t know why he failed the project” will no longer work.
Increase the incoming flow of candidates, including inappropriate.
But, think for yourself - it will pay off?
During the 10 years of my career, first as a System Administrator, then a System Engineer and DevOps, being a simple executor, technical and team lead, I visited and conducted dozens of interviews with companies of different sizes in different countries and took part in forming requirements when searching for employees and ... guys, hiring is dark.
I think that the style and way of hiring that lives and flourishes now harms both employees and companies.
I'll try to explain why.
Who is the employer looking for?
It all depends on the plane in which to consider this issue.
From a business point of view, an employer is looking for a unit that can perform the required functions at minimal cost.
At the level of department heads, deputy directors, etc. the requirements are somewhat changing and detailed - they need a person whose salary is within the budget, which can be found on the market with available funds and who will fulfill the tasks that his manager will set for him in the interests of the business.
At this level, the specific money that the business is willing to pay for the job is usually determined, and HRH comes out of this level to find an employee who fits the criteria, and then those candidates who have passed the first filters come for an interview.
That's all about this is to talk.
In order to run the recruitment, you need to know who to look for.
For this, the requirements for candidates applying for a vacancy are formed.
In large companies, for the sake of standardization, there is also a list of “how to conduct interviews” rules and even internal trainings with the assignment of the title “licensed interviewer”.
And it all works disgusting.
Depending on the structure of the company and the competence of managers, the list of requirements is formed in styles ranging from “we need a frontend programmer, usual requirements”, to “we need a frontend programmer with knowledge of <list of 30 items> , work experience of at least 23 months and mandatory experience in FMCG companies for at least 2 years . "
Sometimes even technically competent employees are recruited who are given the task “to form a complete list of skills and technologies that you use in writing”, and all this with some adjustments leaves for the vacancy in the “requirements” block.
In even rarer cases, the task “form a test to check the necessary knowledge” comes in, which gives rise to various test tasks on Hackerrank, consisting of tasks infinitely far from workers.
Whatever approach to the formation of requirements from this range is used - it does not work well.
Why does it work badly?
The technology stack in the industry is huge.
More than you can submit or write in the requirements (although there are three-page listings of requirements).
Moreover, the stack in the company will also change sooner or later.
The leaders will change, the software platform will change, a new vendor with a profitable offer will come.
But the people - will remain. If they don’t escape or don’t have to fire them, they are not able to perform new functions.
The desire for formalization is understandable. It is psychologically safe and relieves pressure from the head.
But it interferes with hiring and further work .
Specialists in hiring miss a huge number of talented people simply because they did not match the keywords.
Look at LinkedIn with his “you have 27% of skills with this job.” Or on the first page of the issuance of HH / Indeed / Glassdoor, for vacancies with foot-jacketed requirements and knowledge of technology.
Following the rules, interviewers ask delusional questions , realizing that they have nothing to do with future tasks. Most often, they themselves do not know any answers except those written in the questionnaire and will not understand the correct answer if it is non-standard.
Especially when the company has many specialists with different specializations, and the rules and questions are the same for everyone.
Without following the rules, interviewers begin to rely on their own, perhaps very specific knowledge and ask questions that again, in no way help determine how a person will perform the tasks that will be in front of him.
It may be from another project to develop a specific system, it can (not) love ML very much, it can (not) love Go / Python / Perl / C # / C ++ / C / Java / Scala, despise or adore Puppet / Salt / CFEngint / Chef etc.
Just because he is a man and he has nothing to rely on, except for his own experience and taste.
Such job interviews are stressful for everyone involved.
Most of the interviewers are still unpleasant to write negative reviews on candidates. The impression of candidates after such interviews is also far from positive. Managers are upset that the vacancy is not closed, HRy are forced to send more and more letters and messages, wondering what the candidate provided by them didn’t fit, because "it fits the requirements perfectly."
These problems arise from the fact that the employee search system is designed to find not a good employee with a head, but a certain function, trying to describe it through the maximum number of requirements.
Lists, keywords, tags, lists of questions for interviews in the style of "how many arguments the substring function takes" - they spoil everything.
Such a selection system, on the one hand, generates professional “interviewers” who fall into positions that objectively do not pull, on the other hand, prevent normal specialists from coming to the company and bringing many benefits to it, because they used Puppet instead of Salt, wrote in Python 2.7 instead of 3.5, they used Symphony instead of Laravel, Docker, not RKT, Docker Swarm, not Kubernetes or etcd, not Consul.
All tools are changed and replaced.
After 1-2 years, the current knowledge of the tools will be irrelevant; after 5 years, no one will remember the majority. Everything will have to change, the function of the employee may also change with the environment and projects.
In the overwhelming majority of companies there are no tasks where you need to know 8 sorting algorithms and remember all the Spring Boot Core functions or what npm libraries he knows.
It makes no difference what configuration management the person knows at the start or how many arguments to java he remembers.
If a person knows how to perform a certain function in a given framework, then this does not at all mean that he is a good specialist.
This means only that he, by coincidence, is able to perform a certain function here and now.
In fact, based on my experience, other criteria are much more important for a candidate (and a future successful employee):
- You need to be adequate, to be able to reason and learn, to be able to make reasonable assumptions about what you do not know.
- You need to have basic knowledge of operating systems, networks and current technologies.
- You need to understand what underlies the tools that are used and why these tools are needed (or not needed).
- You need to have beliefs about how to work and the power to follow them.
- In short - you need to be able to think in a broad sense.
Look at the large successful companies, their requirements for candidates. They minimally specify technologies, just to designate a certain base on which to rely.
Here is what Yandex writes in its vacancies in the position of the System Administrator in the requirements:
- Unix / Linux administration experience - more than three years;
- experience in administering open source applications (web servers, databases, mail servers, etc.);
- knowledge of TCP / IP network technologies;
- programming experience in scripting languages (shell, python, perl);
- the ability to learn from the experience of colleagues and share with them your own;
- Last year you worked in a similar position.
And that in the wishes:
- experience in designing systems operating continuously and without interruption (24x7x365);
- analytical skills to prevent and quickly troubleshoot.
But the requirements for the position of SRE in Google :
- BS degree (eg, physics or mathematics), or equivalent practical experience.
- Experience with algorithms, data structures, complexity analysis and software design.
- Experience in one or more of the following: C, C ++, Java, Python, Go, Perl or Ruby.
And here are the wishes:
- Interesting designing, analyzing and troubleshooting large-scale distributed systems.
- Systematic problem-solving approach and drive.
- Ability to debug and optimize code and automate routine tasks.
It is much better to pay more attention in the job description to what the company does and what the candidate will have to do than to list all 10 frameworks that are used in your projects.
Change and approach to interviews.
Ask at the interviews for the basics, ask to argue out loud, ask broad questions (and be ready to hear more than once the answer that will be a surprise to you), build a dialogue, communicate, share information. Look for points of contact, try to understand how a person thinks and why he thinks so.
Most of the people to whom I asked this question (as well as myself) agree that in fact 15-20 minutes of communication is enoughto make sure that the person fits and determine his level and within 10 minutes you need to realize that the person does not fit perfectly.
At the same time, tests and deep technical surveys have virtually no effect on the result .
Yes, at this time it is necessary to strain the brain and communication skills of those who conduct interviews.
Top management must learn to trust those who conduct these interviews and who, in the future, work with hired people.
We'll have to abandon the tags, crazy (and thoughtless) filtering and unnecessary, but so calm, standardization.
You will have to take extended responsibility for the result of hiring, because “Here are his test results, he answered 98% of the questions, I don’t know why he failed the project” will no longer work.
Increase the incoming flow of candidates, including inappropriate.
But, think for yourself - it will pay off?