Man-function or stop hiring technology
I did not think that I would be going to write an article about this, and even less so on Habr, but, as they say, “something needs to be done about it”. Got sick.
For 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 sets for him in the interests of the business.
At this level, specific money is usually determined that the business is willing to pay for the performance of work, and it is from this level that HRs find an employee who fits the criteria, and then those candidates who have passed the first filters come in 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 rules “how to conduct interviews” and even internal trainings with the assignment of the title “licensed interviewer”.
And it all works disgustingly.
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 is to “form a test to check the necessary knowledge”, which gives rise to various test tasks on Hackerrank, consisting of tasks infinitely far from workers.
Whatever approach to forming 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 managers 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 removes the load from the head.
But this prevents the 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 issue of HH / Indeed / Glassdoor, for vacancies with footcloths of 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 there are many specialists in the company 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 can be from another project to develop a specific system, can really (not) love ML, 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 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 by the fact that the vacancy is not closed, HRs 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 formed in order 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 are not objectively pulling, 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 about 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 vast 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 so, 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 enough to make sure that the person fits and determine his level and within 10 minutes you need to understand that a person does not fit perfectly.
At the same time, tests and deep technical surveys have practically 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?
For 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 sets for him in the interests of the business.
At this level, specific money is usually determined that the business is willing to pay for the performance of work, and it is from this level that HRs find an employee who fits the criteria, and then those candidates who have passed the first filters come in 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 rules “how to conduct interviews” and even internal trainings with the assignment of the title “licensed interviewer”.
And it all works disgustingly.
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 is to “form a test to check the necessary knowledge”, which gives rise to various test tasks on Hackerrank, consisting of tasks infinitely far from workers.
Whatever approach to forming requirements from this range is used - it does not work well.
Why does this 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 managers 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 removes the load from the head.
But this prevents the 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 issue of HH / Indeed / Glassdoor, for vacancies with footcloths of 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 there are many specialists in the company 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 can be from another project to develop a specific system, can really (not) love ML, 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 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 by the fact that the vacancy is not closed, HRs 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 formed in order 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 are not objectively pulling, 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 about 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 vast 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.
- It is necessary to understand what lies at the basis of 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 so, 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 in computer science or related technical field coding (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,
- 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 enough to make sure that the person fits and determine his level and within 10 minutes you need to understand that a person does not fit perfectly.
At the same time, tests and deep technical surveys have practically 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?
Source: https://habr.com/ru/post/423953/
All Articles