No pensé que iba a escribir un artículo sobre esto, y más aún sobre Habr, pero como dicen, "hay que hacer algo con esto". Dolorido
A lo largo de los 10 años de mi carrera, primero como administrador del sistema, luego como ingeniero de sistemas y DevOps, habiendo logrado ser un simple intérprete, líder tecnológico y de equipo, visité y realicé docenas de entrevistas en empresas de varios tamaños en diferentes países, participé en la formación de requisitos al buscar empleados y ... muchachos, contratar es oscuridad.
Creo que el estilo y la forma de contratación que vive y prospera ahora perjudica tanto a los empleados como a las empresas.
Trataré de explicar por qué.
¿A quién busca el empleador?
Todo depende de qué plano considerar este tema.
Desde el punto de vista comercial, el empleador está buscando una unidad que pueda realizar las funciones requeridas a un costo mínimo.
A nivel de jefes de departamento, subdirectores, etc. los requisitos cambian un poco y son detallados: necesitan una persona cuyo salario se ajuste al presupuesto, que se pueda encontrar en el mercado con los fondos disponibles y que realice las tareas que su gerente le asignará en interés de los negocios.
En este nivel, generalmente se determina el dinero específico que la empresa está dispuesta a pagar por el trabajo y, a partir de este nivel, las RR.
De eso vale la pena hablar.Para comenzar a reclutar personal, necesita saber a quién buscar.
Para esto, se formulan requisitos para los candidatos que solicitan una vacante.
Para las grandes empresas, en aras de la estandarización, todavía hay una lista de reglas "cómo realizar entrevistas" e incluso capacitaciones internas con el título de "entrevistador con licencia".
Y todo funciona asqueroso.Dependiendo de la estructura de la empresa y la competencia de los gerentes, se forma una lista de requisitos en los estilos de "necesitamos un programador frontend, los requisitos son ordinarios", a "necesitamos un programador frontend con conocimiento de
<lista de 30 elementos> , experiencia laboral de
al menos 23 meses y experiencia requerida en empresas de bienes de consumo por
al menos 2 años ".
A veces, incluso los empleados técnicamente competentes están involucrados a quienes se les da la tarea de "formar una lista completa de habilidades y tecnologías que utiliza en la escritura" y todo esto con algunos ajustes deja la vacante en el bloque de "requisitos".
En casos aún más raros, la tarea es "formar una prueba para probar el conocimiento necesario", lo que da lugar a varias tareas de prueba en Hackerrank, que consisten en tareas que están infinitamente lejos de los trabajadores.
Cualquiera que sea el enfoque para la formación de requisitos de este rango, se utiliza
mal.¿Por qué esto funciona mal?
La pila de tecnología en la industria es enorme.
Más de lo que puede imaginar o escribir en los requisitos (aunque también hay listados de requisitos de tres páginas).
Además, la pila en la empresa también cambiará tarde o temprano.
Los líderes cambiarán, la plataforma de software cambiará, un nuevo proveedor vendrá con una buena oferta.
Pero la gente se quedará. Si no se escapan o no tienen que dispararlos, porque no pueden realizar nuevas funciones.
El deseo de formalización es comprensible. Es psicológicamente seguro y elimina el estrés de la cabeza.
Pero esto
interfiere con la contratación y el trabajo posterior .
La contratación de profesionales se pierde a un gran número de personas con talento simplemente porque las palabras clave no coinciden.
Mire LinkedIn con su "usted tiene el 27% de las habilidades que coinciden con este trabajo". O en la primera página de emisión de HH / Indeed / Glassdoor, para vacantes con paños de requisitos y conocimiento de la tecnología.
Siguiendo las reglas, los entrevistadores
hacen preguntas delirantes , al darse cuenta de que no tienen nada que ver con tareas futuras. Muy a menudo,
ellos mismos no conocen ninguna respuesta que no sea la escrita en el cuestionario y
no entenderán la respuesta correcta si no es estándar.
Especialmente cuando la compañía tiene muchos especialistas con diferentes especializaciones, y las reglas y preguntas son las mismas para todos.
Al no seguir las reglas, los entrevistadores comienzan a confiar en su conocimiento, posiblemente muy específico, y hacen preguntas que, de nuevo, no ayudan de ninguna manera a determinar cómo la persona realizará las tareas que enfrentará.
Puede ser de otro proyecto para desarrollar un sistema específico, puede (no) amar ML, puede (no) amar Go / Python / Perl / C # / C ++ / C / Java / Scala, despreciar o adorar Puppet / Salt / CFEngint / Chef etc.
Solo porque es un hombre y no tiene nada en lo que confiar excepto por su propia experiencia y gusto.
Tales entrevistas son estresantes para todos los involucrados.La mayoría de los entrevistados siguen siendo desagradables para escribir críticas negativas sobre los candidatos. La impresión de los candidatos después de tales entrevistas también está lejos de ser positiva. Los gerentes están molestos porque la vacante no está cerrada, los recursos humanos se ven obligados a enviar más y más cartas y mensajes, preguntándose por qué el candidato que proporcionaron no encaja, porque "se adapta perfectamente a los requisitos".
Estos problemas nacen del hecho de que el sistema de búsqueda de empleados está diseñado para encontrar no un buen empleado con la cabeza, sino una determinada función, tratando de describirlo a través del número máximo de requisitos.Las listas, palabras clave, etiquetas, listas de preguntas para entrevistas en el estilo de "cuántos argumentos toma la función de subcadena", estropean todo.
Tal sistema de selección, por un lado, da lugar a "entrevistadores" profesionales que caen en posiciones que no están tirando objetivamente y, por otro lado, evitan que los especialistas normales vengan a trabajar en la empresa y le brindan muchos beneficios, porque usaron Puppet en lugar de Salt, escribieron en Python 2.7 en lugar de 3.5, usaron Symphony en lugar de Laravel, Docker, no RKT, Docker Swarm, no Kubernetes o etcd, no Consul.
Todas las herramientas se cambian y se reemplazan.
Después de 1-2 años, el conocimiento actual sobre las herramientas será irrelevante, después de 5 años nadie recordará más. Todo tendrá que ser cambiado, la función del empleado también puede cambiar junto con el entorno y los proyectos.
La gran mayoría de las empresas no tienen problemas en los que necesita conocer 8 algoritmos de clasificación y recordar todas las características de Spring Boot Core o las bibliotecas npm que conoce.
No importa qué sistema de gestión de configuración conozca una persona al principio o cuántos argumentos a Java recuerda.
Si una persona sabe cómo realizar una determinada función dentro de un marco determinado, esto no significa en absoluto que sea un buen especialista.
Esto solo significa que, por coincidencia, él sabe cómo realizar una determinada función aquí y ahora.
De hecho, según mi experiencia, otros criterios son mucho más importantes para el candidato (y futuro empleado exitoso):
- Debe ser adecuado, poder razonar y aprender, poder hacer suposiciones razonables sobre lo que no sabe.
- Debe tener conocimientos básicos sobre sistemas operativos, redes y tecnologías relevantes.
- Debe comprender qué subyace a las herramientas que se utilizan y por qué estas herramientas son necesarias (o no necesarias).
- Uno necesita tener creencias sobre cómo trabajar y la fuerza para seguirlas.
- En resumen, debe ser capaz de pensar en un sentido amplio.
Mire las grandes empresas exitosas, sus requisitos para los candidatos. Especifican mínimamente las tecnologías, solo para indicar una cierta base en la que confiar.
Esto es lo que
Yandex escribe en sus vacantes en la posición del
Administrador del
sistema en los requisitos:
- Experiencia en administración de Unix / Linux: más de tres años;
- experiencia en la administración de aplicaciones de código abierto (servidores web, bases de datos, servidores de correo, etc.);
- conocimiento de las tecnologías de red TCP / IP;
- experiencia en programación en lenguajes de script (shell, python, perl);
- la capacidad de aprender de la experiencia de colegas y compartir la suya con ellos;
- El año pasado trabajaste en un puesto similar.
Y esto es lo que hay en los deseos:
- experiencia en el diseño de sistemas que funcionan de manera continua y sin problemas (24x7x365);
- habilidades analíticas para prevenir y solucionar problemas rápidamente.
Y aquí están los
requisitos para
la posición SRE
de Google :
- Licenciatura en Ciencias de la Computación o campo técnico relacionado con la codificación (por ejemplo, física o matemáticas), o experiencia práctica equivalente.
- Experiencia con algoritmos, estructuras de datos, análisis de complejidad y diseño de software.
- Experiencia en uno o más de los siguientes: C, C ++, Java, Python, Go, Perl o Ruby.
Y aquí están los deseos:
- Interés por diseñar, analizar y solucionar problemas de sistemas distribuidos a gran escala.
- Enfoque sistemático de resolución de problemas, junto con fuertes habilidades de comunicación y un sentido de propiedad e impulso.
- Capacidad para depurar y optimizar código y automatizar tareas rutinarias.
Es mucho mejor
prestar más atención a las descripciones de trabajo de
lo que hace la empresa y lo que el candidato tendrá que hacer que enumerar los 10 marcos que se utilizan en sus proyectos.
Cambiar el enfoque de las entrevistas.Pida lo básico en las entrevistas, pida razonar en voz alta, haga preguntas amplias (y esté preparado para escuchar más de una vez una respuesta que le sorprenderá), entable un diálogo, comuníquese, comparta información. Busque puntos en común, intente comprender cómo piensa una persona y por qué piensa eso.
La mayoría de las personas a las que les hice esta pregunta (así como a mí mismo) están de acuerdo en que, de hecho,
15-20 minutos de comunicación son suficientes para asegurarse de que la persona sea adecuada y determinar su nivel, y
en 10 minutos es necesario Entiendo que una persona no encaja perfectamente.
Al mismo tiempo, las pruebas y encuestas técnicas profundas prácticamente
no afectan el resultado .
Sí, durante este tiempo tendrá que forzar su cerebro y sus habilidades de comunicación para quienes realizan entrevistas.
La alta gerencia debe aprender a confiar en quienes realizan estas entrevistas y en quienes, en el futuro, trabajarán con personas contratadas.
Tendrá que abandonar las etiquetas, el filtrado loco (e irreflexivo) y la estandarización excesiva, pero muy tranquila.
Deberá asumir una mayor responsabilidad por el resultado de la contratación, ya que "Aquí están los resultados de su prueba, respondió el 98% de las preguntas, no sé por qué falló el proyecto" ya no funcionará.
El flujo entrante de candidatos, incluidos los inadecuados, aumentará.
Pero, piense por usted mismo: ¿valdrá la pena?