Contratación de desarrolladores: ¿algún consejo para ser más eficiente? [cerrado]

Represento a una compañía de software que está en proceso de construir un gran equipo de desarrollo de software. Somos exigentes con quienes contratamos y tenemos una tasa de retención realmente buena (la mayoría de los desarrolladores han estado aquí durante un promedio de 5-6 años).

Hemos pasado mucho tiempo de desarrolladores y recursos humanos y tenemos una baja proporción de aplicaciones para contratar. Aquí está el proceso que usamos:

• Entrevista de recursos humanos en el teléfono: implica hacer preguntas básicas de comportamiento y tecnología
• Prueba en línea: implica una prueba técnica de 30 minutos
• Entrevista técnica telefónica: una entrevista de 60 minutos realizada por un desarrollador
• Entrevista en el lugar: una entrevista de 60 a 90 minutos realizada por varios desarrolladores senior

Aunque este proceso ha estado funcionando, hemos pasado demasiado tiempo en entrevistas. ¿Alguna idea sobre cómo se puede hacer esto de manera diferente? Nuestro objetivo es automatizar cualquier tarea, si es posible, conservando la calidad del talento.

ACTUALIZACIÓN: Gracias por las respuestas. Necesito aclarar algunas cosas. Nuestro objetivo es reducir el número de solicitantes que van de una etapa a otra. Aquí están nuestros números actuales.

1. Recibimos 1000 currículums
2. 800 hojas de vida pasan la entrevista de recursos humanos
3. 500 pasan la prueba en línea
4. 100 pasan la pantalla inicial del teléfono
5. 10 pase el sitio y sea contratado

Como puede ver, tenemos que hacer un mejor trabajo para eliminar a los candidatos antes en el proceso. ¿Podemos hacer un mejor trabajo en la forma en que la prueba en línea evalúa a las personas?

Aquí hay más detalles sobre el proceso basado en algunas respuestas:

• Entrevista de recursos humanos por teléfono: hacen preguntas técnicas muy básicas (¿Qué es un CLR?) Para eliminar a tantas personas como sea posible
• Prueba en línea: tenga alrededor de 10 preguntas básicas con 3 preguntas de codificación
• Pantalla del teléfono tecnológico: cubre una variedad de tecnologías. No nos importa si el solicitante no lo sabe todo, siempre y cuando pueda demostrar que podrá aprender nuevas tecnologías y acelerar rápidamente
• En el sitio: preguntas de codificación frente a los desarrolladores. Más preguntas de nivel arquitectónico.

Creo que hay algunos lugares en los que estás perdiendo el tiempo.

Deje la entrevista de recursos humanos más allá de un simple primer contacto para configurar entrevistas de seguimiento. Hacer que la gente de RRHH haga preguntas técnicas es una pérdida de tiempo. Por ejemplo, uno me hizo una pregunta poco clara sobre MVC y no pudieron aclarar lo que se estaba preguntando.

Elimine la prueba en línea, especialmente si está contratando desarrolladores de nivel medio a superior. Pierde su tiempo más su tiempo y dinero. Además, algunos desarrolladores simplemente no lo hacen bien en este tipo de prueba.

Si bien una entrevista telefónica es buena, no debería requerir una hora completa. A menudo, 5-10 minutos son suficientes para determinar si una persona se ajusta bien o no. Lo máximo que necesitará será 30 minutos para determinar si se justifica un encuentro cara a cara.

La entrevista cara a cara será la más importante. Simplemente no lo desperdicie en BS como pruebas de personalidad de recursos humanos, pruebas en línea estandarizadas y similares. Tómese el tiempo para conocer a la persona y ver si encajan en su equipo. Haga buenas preguntas relacionadas con el trabajo que espera que hagan, no haga preguntas engañosas, no le importe los acertijos que escuchó que preguntan en Google / Microsoft / Apple / etc. o curiosidades oscuras.

También puede ir a través de una empresa de reclutamiento que contrata por contrato. Muchos de ellos habrán realizado el examen preliminar y las pruebas y, en algunos casos, habrán trabajado con la persona anteriormente. De esa manera, puede contratar a los mejores candidatos y determinar si encajan bien mientras hacen el trabajo real por usted. Si las cosas no funcionan por alguna razón, déjelos ir. Si encajan bien, manténgalos como empleados permanentes.

Editar basado en información actualizada ...

Si su HR solo detecta 200 de 1000, el problema podría estar allí.

Su anuncio de búsqueda de ayuda puede ser demasiado genérico y alentar a muchas personas a presentar una solicitud que, de lo contrario, se excluirían. Es posible que desee orientar mejor su anuncio, pero no lo haga en exceso.

Con tantos curriculums vitae, RR.HH. puede externalizar mejor esta fase a una agencia de preselección para reducir un poco las cosas, mediante el uso de la automatización y / o entrevistas y verificaciones de antecedentes. Esto podría incluir una entrevista técnica inicial real dada por un programador real. También podría incluir una prueba en línea, pero esta será una variedad de trucos y curiosidades.

Como dije, no creo que esté obteniendo mucho valor de las pantallas de prueba de recursos humanos y en línea. Sugeriría repensar esto y encontrará que sus números en las otras fases serán más razonables.

Esta es una situación en la que no desea ser más eficiente de lo que ya es. Ya hay demasiados solicitantes que no pueden pasar FizzBuzz. Parece que su proceso de filtrado actual garantiza la calidad del desarrollador. Terminarías perdiendo aún más tiempo en el futuro si eliminaras cualquiera de los pasos que estás tomando hasta ahora.

Parece que un candidato exitoso toma alrededor de tres a cuatro horas. No trataría de reducir ese tiempo general. En todo caso, podría agregar más tiempo para que la entrevista en el sitio dé tiempo suficiente para que los candidatos realmente buenos demuestren su valía definitivamente y decidan si lo que ofrecen es interesante para ellos a largo plazo. Con su baja rotación, debe estar haciendo algo bien.

El bajo ROI en su proceso podría ser los primeros tres pasos. Quizás pueda examinar los currículos de manera más estricta o buscar puntajes aún más altos en la prueba en línea. La pantalla técnica del teléfono puede ser un objetivo para la optimización si la configura en 30 minutos, pero permite que los candidatos superiores se extiendan a 45 o 60 minutos.

Si te sirve de consuelo, creo que la distracción y el costo del tiempo, si bien es un lastre para el trabajo del proyecto, es uno de los momentos más valiosos que puedes pasar. Tenga en cuenta los costos y los problemas que surgen de los errores de contratación y las grandes ganancias para el equipo y la empresa cuando se realiza una buena contratación.

Si está tomando el punto, trabajando con casi todos sus candidatos, es algo así como un cordero sacrificado. Sin embargo, el efecto global del trabajo que está haciendo tiene un gran valor. Debería adoptar el papel y aprovecharlo con toda la buena voluntad que pueda obtener entre los nuevos empleados. Si el proceso va bien, su gerencia también valorará su juicio sobre otras cosas.

Mientras lo leo, su sistema está funcionando y usted está más que satisfecho con los resultados. Sus equipos están trabajando bien, son productivos y todos están felices. El único problema es que crees que está costando demasiado.

Considere la alternativa: reducir la sobrecarga de reclutamiento de personal (sin importar el método). Como resultado, la tenencia se reduce de 6 años a 3. Si ha pasado la mitad del tiempo para cada reclutamiento, entonces ha gastado lo mismo en total solo en el reclutamiento. Ahora mire el costo de la rotación: a diferencia de la mano de obra (la pintura de cercas es un buen ejemplo), lleva un tiempo considerable ponerse al día, digamos de 3 a 6 meses. Esto significa que sus ahorros de reclutamiento tienen que recuperar de 3 a 6 meses de salarios, costos y ganancias perdidas para el negocio (llámese 2.5 * salarios). Ahora factorice la interrupción para el equipo y el riesgo que un nuevo recluta tiene para la dinámica del equipo.

En general, un reclutamiento en promedio le costará entre 3 y 6 meses de salario. ¿Cuánto gastas para ocupar un puesto? Una o dos semanas, supongo.

Manera de reducirlo: todo lo que puedo ver son los tiempos de la entrevista: ¿los está terminando o completando una vez que ha decidido que el candidato es un No (o un Sí)? Si ha decidido hacerle una oferta después de los primeros 5 minutos, haga la oferta. Si necesita 90 para decidir no hacer una oferta, pregunte por qué tardó 90 en llegar a No (es decir, qué hizo para volarlo en los últimos 60 segundos).

El reclutamiento es, en el mejor de los casos, un lanzamiento de basura: parece que has cargado con éxito los dados a tu favor, estaría tentado a mantenerlo así ...

También sugeriría algo que leí aquí: Programación efectiva: más que escribir código :

Es bueno ver si el candidato "encaja" en la cultura de la organización y en la vida cotidiana. Esto se puede hacer permitiendo que el candidato haga preguntas a los empleados actuales "fuera del registro" o en algún nivel avanzado haciendo un trabajo por contrato durante una semana o dos (sugerido por el autor).

En retrospectiva, si algunas empresas para las que he trabajado utilizaron esta estrategia, nunca me habrían contratado, algo que sería igualmente bueno para ambas partes.

Por lo general, les pedimos que traigan y expliquen algunos códigos que escribieron y de los que estamos particularmente orgullosos, preferiblemente de un proyecto de código abierto.

" Espera ", dices, " ¿No te inclina esto hacia las personas que escriben software en su tiempo libre? "

Si. Si lo hace Ese es el punto.

¿Has pensado en trabajar con una agencia de reclutamiento para tratar de encontrar personas? Puede sentarse con una agencia y contarles su proceso y lo que está buscando en un solicitante. Luego pueden pasar el tiempo mirando los muchos currículums, haciendo la prueba técnica general y administrando la prueba en línea. Luego, le pasan a los buenos solicitantes por teléfono y entrevista en persona.

He trabajado con una agencia de reclutamiento en el pasado como desarrollador buscando trabajo. Tuve que pasar por un largo proceso de entrevista para estar en su grupo, y luego, cuando surgieron posibles trabajos, tuve que hacer los pasos iniciales y, si mi código / respuestas eran buenas, podía conocer a la compañía real.

Estoy seguro de que elimina muchos gastos generales de su equipo, pero habría un costo. He oído que puede ser un porcentaje del salario del empleado. Entonces, si está ofreciendo 65k / año, podría ofrecerles 60k y luego pagarle a la compañía 5k.

En lugar de preguntar si nuestro proceso es incorrecto, primero debe preguntar si no podemos atraer a las mejores personas disponibles. La mayoría de las organizaciones no se promocionan a sí mismas ni al trabajo antes de recibir ninguna solicitud. Creo que también es un error tener participación de RR. HH. En el primer punto de contacto. Existe un cisma fundamental entre los tipos de personalidad empleados en RRHH y los desarrolladores de alta gama.

Después de pensarlo mucho a lo largo de los años sobre este tema, usaría una política de contratación de contratistas / temporales al 100% y ofrecería puestos de carrera a tiempo completo para seleccionar contratistas después de un año. Algunas personas se entrevistan muy bien con conocimientos técnicos enciclopédicos, pero dedican su tiempo a escribir el código que saben que necesitan, pero no lo que les pidieron.

Tengo una pista específica para la entrevista, proporciono un código y le doy al candidato 10 minutos para que lo revise, luego le pido que critique el código.

Como dice SomeKittens, haga la prueba FizzBuzz ... solo que lo haga en vivo y preferiblemente en papel, ya que lo que quiere es ver cuánto tiempo tardan en hacer la solución. No califique la sintaxis, solo la lógica de la solución, en mi caso incluso permito el pseudocódigo y no es un problema, funciona igual de bien.

Para mí ha funcionado como magia ... Pude eliminar a un tipo de 15 años de experiencia que habló mucho de que era tan bueno que estaría dispuesto a "renunciar" a su puesto directivo por un disparó en un puesto de desarrollador en mi empresa ... oh chico, falló: 45 minutos (incluso fui por un refresco y regresé), lo hice en pseudocódigo, y se equivocó. El tipo había dejado una buena impresión con RR. HH. Debido a su currículum, pero dado este resultado pude eliminarlo sin sudar.

El promedio es de 15 minutos, menos que eso, no significa que tenga un buen programador, más que eso comience a preocuparse por tener un mal programador frente a usted.

Lea el artículo de Jeff Attwood " Por qué los programadores no pueden programar " para tener una idea de la esencia de la prueba.

Además, desafortunadamente estoy en México y esto no es lo suficientemente popular como para tener dónde elegir, pero, tal vez intente careers.stackoverflow.com ?, quiero decir, es una herramienta de reclutamiento especializada exactamente para lo que está buscando.

Respondiendo desde la perspectiva de los desarrolladores, confiar tanto en la habilidad técnica de los desarrolladores obtiene desarrolladores de calidad, pero igualmente tiene la oportunidad de eliminar a los desarrolladores realmente buenos también.

Estoy involucrado en muchos entornos de programación C #, Java, PHP, etc. Muchas experiencias de trabajo aseguran que una persona sea experta en su campo, pero debido a esto, un hecho ignorado es que se suprimen otros antecedentes.

Por ejemplo, la mayor parte de mi experiencia involucra PHP y conozco casi todos los fragmentos del lenguaje, solo porque puedo responder la pregunta, no me convierte en un programador de calidad. Y solo porque no recuerdo el nombre y la definición de la función en una biblioteca XXXX en Java no hace que sea un mal codificador de Java.

Creo que los desarrolladores deben ser juzgados por el potencial y la adaptabilidad en lugar de lo que pueden hacer.

Mi sugerencia sería cambiar la entrevista de RR.HH. para que sea más acerca de preguntarle al candidato sobre su ambiente de trabajo ideal. Un punto clave aquí para RR.HH. es recopilar respuestas y agregar puntos sobre cómo se da la respuesta para determinar si el candidato sabe qué tipo de entorno desea y qué tan bien se ajusta a su organización.

Puede haber algo que decir sobre RR.HH. conociendo algunos puntos en el proceso general utilizado dentro de su organización, pero es probable que esto sea más útil si puede configurar las cosas para que tenga valores específicos, estilos de comunicación y otros puntos. como cosas para recursos humanos para encontrar. El punto aquí no es que RR.HH. determine el ajuste solo, sino que recopile la información que luego se puede pasar a un desarrollador o dos que pueden ver si vale la pena rastrear rápidamente a alguien a través del proceso.