En un artículo anterior
sobre la implementación de la metodología Agile en nuestro inicio, abordé parcialmente el tema de la gestión del personal. En este artículo, le diré cómo reclutamos a este personal, qué clasificación usamos, qué pruebas y métodos verificamos su profesionalismo y adecuación.
Modelo de reclutamiento
Como en cualquier empresa joven, nuestro trabajo en el campo de la selección de personal comenzó con el desarrollo de un modelo de reclutamiento. La situación era la siguiente: ya teníamos un equipo de empleados "indígenas", todos ellos eran altamente hábiles y trabajaban en puestos de alto nivel. Estas personas tuvieron que ser descargadas de alguna manera, es decir, no había necesidad de que los especialistas del mercado ganaran competencia, por lo tanto, durante el período de expansión activa del personal, el abrumador número de vacantes fueron puestos de junio. Antes de colocar vacantes en sitios de reclutamiento, decidimos elaborar nuestra clasificación interna de acuerdo con el nivel de calificación y de acuerdo con los requisitos para las diferentes categorías de desarrolladores.
Se derivó la siguiente clasificación:
Nivel 0 : fullzero-developer, una persona realizó un par de cursos, aprendió las construcciones básicas y la semántica de un determinado idioma, leyó varios artículos sobre Haber sobre temas publicitarios, como resultado, el programador tiene una etiqueta máxima en la computadora portátil.
Nivel 1 : un desarrollador junior, una persona que escribe bien el código, conoce bien las pilas, conoce las tendencias actuales, sabe cómo descomponer un problema y resolverlo por sí mismo.
Nivel 2 : desarrollador intermedio, una persona posee todas las cualidades junior enumeradas anteriormente, y también puede expresar su opinión competente sobre el problema que se resuelve sobre la base del análisis de recursos, y puede influir en el curso de su implementación dentro del marco de su cadena de herramientas elegida.
Nivel 3 : un desarrollador senior, también es un líder, es padre, padre, una persona que transforma y proyecta tareas de un plano comercial a un plano de desarrollo, distribuye estas tareas a mediados y junio, controla y ayuda con su implementación.
Se agregaron criterios a esta clasificación como: conocimiento de nuestra cadena de herramientas, adecuación, experiencia laboral de aproximadamente 1-2 años, y al menos un proyecto implementado con éxito, la capacidad de expresar claramente los pensamientos, la presencia de habilidades de comunicación, la capacidad de admitir los errores y las deficiencias (autocrítica saludable - Es una herramienta poderosa). La prioridad para el conjunto, como se mencionó anteriormente, se puso en los desarrolladores junior, ya que nuestra experiencia en el tratamiento de medios mostró que, por regla general, estas personas ya están arruinadas por algún tipo de tecnología y enfoques "únicos" de otras compañías. Además, la práctica ha demostrado que hay una gran cantidad de personas en el mercado que están acostumbradas a vivir en una estructura vertical rígida, donde entran al material aldente de la mesa de las tareas masticadas que solo se pueden llenar en forma de código, y la tarea de los adultos mayores es golpear las jambas con un palo en la cabeza . Pero la cuestión es que cuando la acción se lleva a cabo en una startup joven, y el equipo solo tiene una treintena de personas, cada una de las cuales está cargada bajo un tanque lleno, entonces no hay tiempo para una descomposición personal para cada empleado, ya que esto será equivalente a completar esta tarea. En tales condiciones, cuando escribir código toma alrededor del diez por ciento del tiempo total de ejecución de la tarea, es necesario incluir no solo los dedos, sino también la cabeza. Esto es exactamente lo que está escrito en la "biblia" de todos los programadores: Stephen McConnell "Código ideal", también conocido como Redbook (que no debe confundirse con la revista estadounidense de mujeres).
Y luego una ola nos cubrió ...
Quien no ingresó, comenzando por personajes que creen que son intermedios porque escribieron una aplicación completa en Android, que tiene hasta 37 descargas en Google Play, terminando con personas que se consideran súper firmantes porque trabajaron como desarrolladores líderes en Algunos estudios, aunque su trabajo, en general, se redujo a la transferencia de tareas del departamento de diseño al departamento de desarrollo, es decir, no tenían experiencia en el diseño o la gestión del desarrollo, pero solo había mucha ambición y mucha ambición. . También hubo quienes, con siete meses de experiencia en programación, se consideraron seniors y exigieron un salario de 240k, sin siquiera resolver tareas elementales para juniors. Desde nuestro punto de vista, estas personas ni siquiera eran Joons. El enfoque es simple: si una persona programa directamente desde el corazón, él es solo un programador, pero si una persona realiza una mala programación o no tira, no es un junior, simplemente no es un programador. Aquí fuimos ayudados por un maravilloso truco en vivo para abandonar a tales candidatos, se llama la "Ley de Plomería", que dice: "Cada nuevo plomero que llega a un nuevo lugar de trabajo vierte barro sobre otro plomero, diciendo que tiene un brazo de émbolo y que ahora tendrá que hacer todo con cero ". En la práctica, funciona de la siguiente manera: el solicitante llega al puesto de junior, le dan un código ya preparado, por ejemplo, un fragmento del kernel de Linux, y le pregunta qué piensa de esta decisión. Si comienza a escupir y dice algo como: “¿Qué tipo de escritor escribió esto? ¡Todo necesita ser rehecho aquí! Dame tiempo, y lo volveré a escribir de nuevo ”, por lo que el plomero está frente a ti, y su primera prioridad es regañar al fontanero anterior.
Miguel Ángel en esta ocasión dijo esto: "Tomo una piedra, corté todo lo innecesario". El gran maestro no escribió guiones, pero entendió bien que una persona competente se acerca al objeto de trabajo con el deseo de comprenderlo y, si es necesario, transformarlo, pero no destruirlo y convertirlo en polvo. Es decir, si una persona responde a estas preguntas: "Si el código funciona en producción y realiza sus funciones, eso es bueno, en algunos lugares creo que puede mejorar este código, si es necesario puedo mostrarlo". Luego, con esa persona, puede y debe continuar el diálogo .
Otra técnica para definir jones de baja habilidad es centrarse en las pilas de bombo y bombo. Si una persona llega a una entrevista y comienza a verter enfoques de tendencias, y a la pregunta legítima: "¿Cómo llegó a esta conclusión y analizó estas herramientas?" - haciendo una mueca ante la mueca que ha alcanzado la iluminación del anciano, él responde: "¡Puedes escribir cualquier cosa en él, el futuro está detrás de él!" herramientas y enfoques exagerados.
Un poco más sobre la entrevista.
Además de lo anterior, al contratar a un programador, es muy importante obtener una posición abierta de él en su conocimiento en una pila particular. Usted decide sobre la pila, y él elige el idioma en el que es "wai wai wai qué tan fuerte", digamos que es un montañés de JavaScript. Hay un conjunto de tareas listas para usar, por ejemplo, esto:
setTimeout(()=>{console.log('Hello World!')}, 1000); while (true) { let a = false; };
Si la pregunta sobre esta tarea es: "¿Cuándo se mostrará Hello World!" ? ", Comienza a tartamudear al estilo de" Bueno ... eh ... mira ... después de completar el ciclo while verdadero o después de un segundo ", esto significa que no conoce la pila, miente sobre sus habilidades, que probablemente estén cerca de a cero El hecho es que la construcción while cargará el preprocesador, y dado que JS tiene un solo subproceso, el bucle principal nunca emitirá un evento desde un temporizador. Es decir La respuesta correcta es nunca.
Si una persona no está lista para evaluar su conocimiento de manera adecuada y honesta, no puede leer el código de otra persona, entonces se puede discutir qué tipo de trabajo en un equipo. Si una persona no demuestra ser un "fontanero" y hace frente a las tareas, confirmando su conocimiento de la pila, o es constructivo acerca de la tarea, sus errores e incompetencia parcial, entonces existe la posibilidad de que se convierta en su nuevo empleado, y en el futuro podrá crecer en lado de los niveles de clasificación más altos.
Hay momentos en que una persona no está de acuerdo con la clasificación interna de la empresa, y reacciona negativamente a la declaración de que no se detiene en el medio o incluso en junio, y que su decisión no funcionará. En este caso, si continúa insistiendo, puede seguir el principio y ejecutar su solución en el entorno, naturalmente, este diseño resulta inoperante, es decir, la persona se ha equivocado. Entonces puede comenzar a aplastar la autoridad de su trabajo anterior. Por ejemplo, hubo casos en que una persona después de tal falla declaró que era un empleado muy valioso de un banco grande y que era muy apreciado allí. Pero en realidad resulta que otras doce mil personas como él trabajaron en este banco, y el departamento de recursos humanos simplemente pasó por alto su incompetencia, y después de pasar cerca de un año allí, ahora declara su condición de especialista. Y aquí, donde hay un equipo de unos veinte programadores, cada uno de los cuales conoce bien su propio negocio, simplemente se pierde y no puede trabajar de acuerdo con el antiguo esquema de empleado. Nuestro CEO, Ilya Bykonya, dice esto: "Para mí, en cuanto al desarrollador y fundador actual de la compañía, solo hay una autoridad: esta es la habilidad de una persona, y dónde trabajó y qué puesto tenía era de importancia secundaria".
Para resumir
Quizás haya un defecto en nuestro enfoque para evaluar a los solicitantes. Y el hecho de que "lo bajemos de rango", diciendo que no es medio, sino junio o peor, juega una broma cruel con nosotros. ¿Quizás estamos perdiendo el futuro Napoleón, como el Imperio ruso alguna vez? Quién sabe ... Pero desde nuestro punto de vista, tal estrategia está plenamente justificada por su efectividad, y al final, Napoleón aún perdió la guerra del Imperio ruso.