Hiring, hunting, training and development of rubists. HR-corner at the conference RubyRussia-2018
On October 6, in the framework of the RubyRussia conference, a round table discussion was held on “Hiring, hunting, training and development of rubists. HR corner . More than 30 participants gathered to talk about the sore: interviews, hiring, adaptation and development of employees. Eychary, timlids, technical directors - all those involved in the HR processes in the company participated in the round table.
In this article we want to share with you the main points and the hottest discussions from this event.
Let's start with the questions in which the opinions of the participants met.
')
The importance in the labor market of certain selection criteria that have been important for many years has changed. For example, about 5 years ago, much attention was paid to:
Once the “flyers” were considered those who worked less than three years in one place. Now this period has been reduced to a year or even less. Higher technical / mathematical education has become an additional plus rather than a competitive advantage. The threshold of transition to IT from other industries has significantly decreased: whereas previously, after 30 years, it was almost impossible to switch “from sales to programmers”, now this is quite a frequent case.
Shock content: it was unanimously found the main criterion of whether a person gets into the company or not! This is not a knowledge of a specific language / framework, not a higher education or work experience in the profession, but “general adequacy” and a desire to develop in the industry. “Overall adequacy” is a term that is as vague as possible, but each of those present understood exactly what was being said.
Since in each team "overall adequacy" is determined individually,
It is very important that Eychar and the hiring lead be played by the team. Participants managed to formulate a “secret” of success in effective hiring:
It all starts with a joint definition of the requirements for this position, which qualities will be mandatory, and which ones will go to the background. It is very good when eychar sits in the same place as the developers, constantly contacts with them, understands their tasks, pains, peculiarities of interaction within the team. Such an eychara has every chance to feel what kind of person is needed, what kind of people need more, what kind is not needed. The meaningful presence of Eychara on technical interviews is important. Watching whoever selects the Caddy, those he likes, what questions he asks and what answers are "taken into account" makes it easier for euchar to begin the initial selection process, and for hiring leads he shortens the time for interviews with the very inappropriate guys. Another useful way to decide on the content of the concept of “overall adequacy”, if your company is not yet ready to lay out the matrix of competencies within itself, is to “analyze” existing members of the team: “Here is Vasya, he is cool, because he behaves like this, like this and like this. But we had Fedya, he did this and that, so we were very happy when he left. Let's look for people like Vasya and do not allow people like Fedya to come to us. ”
They also shared examples of undesirable (and surprising for the employer) behavior of the candidate. What annoys all hiring professionals:
It is surprising that quite understandable norms of behavior in practice are not understandable for everyone. Let's repeat them again just in case: it is considered good for the employer to indicate the salary fork in the text of the vacancy, it is considered normal for the candidate to specify the fork if it was not indicated or the run was too large, but this should be done in the middle / end of the Q & A session c by company.
With sofskilami sorted out. But in the end, we hire programmers. How to check the technical qualifications of the candidate? All were unanimous only that you can not hire a developer without seeing how he writes the code. It turned out to be a completely non-unique case, when at the interview the candidate explains well how to write it in theory, but when it comes to practice, he does not cope.
How to correctly “look at the code from a candidate” is a question that does not have an unequivocal solution. Some representatives of the companies refused to test for the June, as from wasting time. Some, on the contrary, believe that the main thing in the test is for the applicant to do it, and then you can sit down and discuss with him the course of his thoughts and reasoning. It is customary for someone to give as a test task to see someone's pool request, on the contrary, someone is not ready to show the code to all applicants, but only to the finalists. For their part, applicants are also not always ready to do “combat” tasks (albeit small ones), because employers are suspicious of impropriety and the desire to get the feature “for free” at the expense of the candidate.
The best way to check the code recognized live-coding directly at the interview. At the same time it is important to preserve the “general adequacy” of both the writer and the verifier. The notorious “write a bubble sort algorithm on a napkin” annoys most candidates and does not always correlate with real commercial programming skills. Adequate employers always make adjustments for the stressful situation of live coding and do not find fault with trifles, but look at the course of thinking.
All participants of the table agreed that it’s very cool when, after feedback on the lack of knowledge and the message about the refusal, the candidate draws conclusions and returns after some time to the same company.
The probationary period is the time used to verify interoperability for the employer and the candidate. During the trial period, both the candidate and the company are better disclosed to each other. Something that was not seen at the interview may show up at this stage.
Everyone acknowledges that adaptation is a very important process in a company. Someone, drawing conclusions from his previous experience as a job seeker, tries not to let the novice in the first days turn into hell. Someone in the company started heart to heart once a month. This allows you to find out how a person lives in a company, what he learned during this time, how it develops. It is necessary to pay enough time to a new employee so that he understands what his project is, how to approach him, with whom he is to work. making it so that the employee is as comfortable as possible in the first days is an important task of the immediate supervisor.
The hottest controversy broke out on the topic of whether to introduce unpaid or low-paid internship in the company humanely. It didn’t come to the assault, but they agreed that the internship would help meet the needs of both parties, both job seekers and employers. Every day, letters from candidates with little or no experience come to HRC with requests to take up jobs in order to learn and practically “for food”. The internship will help to see the candidate's enthusiasm and his abilities, and the employer will help attract applicants, look at them and stay with those whom they are willing to grow, and all this for relatively small expenses on payroll funds.
In general, there was a lot of talk about development. The pain is the same for everyone: “the pyramid of professionals” at the entrance to the company. It is very easy to hire 10 juns, but it is much more difficult (and often not necessary) to hire 10 middles, and even more so 10 signors. Especially when the industry does not have a single and strict understanding of how to properly hang these labels on people. Despite this, the majority of participants can quite clearly divide the entire set of developers into 2 subsets: “coders” and “engineers”. The first ones are such hard workers from IT who can quickly, efficiently and a lot solve a certain range of typical tasks. The latter are those who can think on a larger scale and more abstractly, think over architectures, build systems. Unfortunately, not everyone can go from coders to engineers. And one of the hot topics of discussion was how to distinguish an inexperienced engineer from an experienced coder, which of them and how to grow in a company.
Most often, employers decide to grow professionals within themselves (and as practice and statistics show, this is the best way). But the silver bullet, of course, no. Frequent, but not always unambiguous composition of the team - 1 Signor, under which 2-5 junior "for growth". The disadvantage of this configuration is that the only person who is responsible for both the team and the project is this signor. And he either develops a product or develops people. In any case, for the company it turns out a costly story. Finding the golden mean between these poles is the main task of managing a company's human resources. And, as the discussion showed, this question is not always only about what to teach, but also about “the person in his place”, about the proper organization of the process of developing and distributing suitable tasks to the right person.
Unfortunately, the round table time ended before the questions and ideas for discussion ended. The topic went on the sidelines and in this article.
Many thanks to all who participated in this format. If someone has a desire to continue the public discussion of the topic of hiring and the development of rubists, without waiting for RubyRussia 2019, write to js@evrone.com, muddle round-table meeting.
In this article we want to share with you the main points and the hottest discussions from this event.
How companies choose candidates
Let's start with the questions in which the opinions of the participants met.
')
The importance in the labor market of certain selection criteria that have been important for many years has changed. For example, about 5 years ago, much attention was paid to:
- profile education programmer;
- the duration of work in one place;
- previous specialties (if they were).
Once the “flyers” were considered those who worked less than three years in one place. Now this period has been reduced to a year or even less. Higher technical / mathematical education has become an additional plus rather than a competitive advantage. The threshold of transition to IT from other industries has significantly decreased: whereas previously, after 30 years, it was almost impossible to switch “from sales to programmers”, now this is quite a frequent case.
Shock content: it was unanimously found the main criterion of whether a person gets into the company or not! This is not a knowledge of a specific language / framework, not a higher education or work experience in the profession, but “general adequacy” and a desire to develop in the industry. “Overall adequacy” is a term that is as vague as possible, but each of those present understood exactly what was being said.
Since in each team "overall adequacy" is determined individually,
It is very important that Eychar and the hiring lead be played by the team. Participants managed to formulate a “secret” of success in effective hiring:
It all starts with a joint definition of the requirements for this position, which qualities will be mandatory, and which ones will go to the background. It is very good when eychar sits in the same place as the developers, constantly contacts with them, understands their tasks, pains, peculiarities of interaction within the team. Such an eychara has every chance to feel what kind of person is needed, what kind of people need more, what kind is not needed. The meaningful presence of Eychara on technical interviews is important. Watching whoever selects the Caddy, those he likes, what questions he asks and what answers are "taken into account" makes it easier for euchar to begin the initial selection process, and for hiring leads he shortens the time for interviews with the very inappropriate guys. Another useful way to decide on the content of the concept of “overall adequacy”, if your company is not yet ready to lay out the matrix of competencies within itself, is to “analyze” existing members of the team: “Here is Vasya, he is cool, because he behaves like this, like this and like this. But we had Fedya, he did this and that, so we were very happy when he left. Let's look for people like Vasya and do not allow people like Fedya to come to us. ”
They also shared examples of undesirable (and surprising for the employer) behavior of the candidate. What annoys all hiring professionals:
- general aggressiveness
- unnecessary disputes,
- questions in the spirit of "Now I ask questions"
- the question of salary as the very first counter question about the company
It is surprising that quite understandable norms of behavior in practice are not understandable for everyone. Let's repeat them again just in case: it is considered good for the employer to indicate the salary fork in the text of the vacancy, it is considered normal for the candidate to specify the fork if it was not indicated or the run was too large, but this should be done in the middle / end of the Q & A session c by company.
With sofskilami sorted out. But in the end, we hire programmers. How to check the technical qualifications of the candidate? All were unanimous only that you can not hire a developer without seeing how he writes the code. It turned out to be a completely non-unique case, when at the interview the candidate explains well how to write it in theory, but when it comes to practice, he does not cope.
How to correctly “look at the code from a candidate” is a question that does not have an unequivocal solution. Some representatives of the companies refused to test for the June, as from wasting time. Some, on the contrary, believe that the main thing in the test is for the applicant to do it, and then you can sit down and discuss with him the course of his thoughts and reasoning. It is customary for someone to give as a test task to see someone's pool request, on the contrary, someone is not ready to show the code to all applicants, but only to the finalists. For their part, applicants are also not always ready to do “combat” tasks (albeit small ones), because employers are suspicious of impropriety and the desire to get the feature “for free” at the expense of the candidate.
The best way to check the code recognized live-coding directly at the interview. At the same time it is important to preserve the “general adequacy” of both the writer and the verifier. The notorious “write a bubble sort algorithm on a napkin” annoys most candidates and does not always correlate with real commercial programming skills. Adequate employers always make adjustments for the stressful situation of live coding and do not find fault with trifles, but look at the course of thinking.
All participants of the table agreed that it’s very cool when, after feedback on the lack of knowledge and the message about the refusal, the candidate draws conclusions and returns after some time to the same company.
Adaptation and development
The probationary period is the time used to verify interoperability for the employer and the candidate. During the trial period, both the candidate and the company are better disclosed to each other. Something that was not seen at the interview may show up at this stage.
Everyone acknowledges that adaptation is a very important process in a company. Someone, drawing conclusions from his previous experience as a job seeker, tries not to let the novice in the first days turn into hell. Someone in the company started heart to heart once a month. This allows you to find out how a person lives in a company, what he learned during this time, how it develops. It is necessary to pay enough time to a new employee so that he understands what his project is, how to approach him, with whom he is to work. making it so that the employee is as comfortable as possible in the first days is an important task of the immediate supervisor.
The hottest controversy broke out on the topic of whether to introduce unpaid or low-paid internship in the company humanely. It didn’t come to the assault, but they agreed that the internship would help meet the needs of both parties, both job seekers and employers. Every day, letters from candidates with little or no experience come to HRC with requests to take up jobs in order to learn and practically “for food”. The internship will help to see the candidate's enthusiasm and his abilities, and the employer will help attract applicants, look at them and stay with those whom they are willing to grow, and all this for relatively small expenses on payroll funds.
In general, there was a lot of talk about development. The pain is the same for everyone: “the pyramid of professionals” at the entrance to the company. It is very easy to hire 10 juns, but it is much more difficult (and often not necessary) to hire 10 middles, and even more so 10 signors. Especially when the industry does not have a single and strict understanding of how to properly hang these labels on people. Despite this, the majority of participants can quite clearly divide the entire set of developers into 2 subsets: “coders” and “engineers”. The first ones are such hard workers from IT who can quickly, efficiently and a lot solve a certain range of typical tasks. The latter are those who can think on a larger scale and more abstractly, think over architectures, build systems. Unfortunately, not everyone can go from coders to engineers. And one of the hot topics of discussion was how to distinguish an inexperienced engineer from an experienced coder, which of them and how to grow in a company.
Most often, employers decide to grow professionals within themselves (and as practice and statistics show, this is the best way). But the silver bullet, of course, no. Frequent, but not always unambiguous composition of the team - 1 Signor, under which 2-5 junior "for growth". The disadvantage of this configuration is that the only person who is responsible for both the team and the project is this signor. And he either develops a product or develops people. In any case, for the company it turns out a costly story. Finding the golden mean between these poles is the main task of managing a company's human resources. And, as the discussion showed, this question is not always only about what to teach, but also about “the person in his place”, about the proper organization of the process of developing and distributing suitable tasks to the right person.
Unfortunately, the round table time ended before the questions and ideas for discussion ended. The topic went on the sidelines and in this article.
Many thanks to all who participated in this format. If someone has a desire to continue the public discussion of the topic of hiring and the development of rubists, without waiting for RubyRussia 2019, write to js@evrone.com, muddle round-table meeting.
Source: https://habr.com/ru/post/429310/
All Articles