¿Qué tan efectivos son los desafíos de programación en el proceso de reclutamiento? [cerrado]

Como cualquier herramienta, pueden ser extremadamente útiles o extremadamente peligrosas. Un taladro eléctrico hará que tu vida sea mucho más fácil, hasta que perfores la parte superior de tu mano y caigas en la sala de emergencias. Lo mismo ocurre con los desafíos de programación en el reclutamiento.

Lo bueno : esta puede ser una forma efectiva de detectar a alguien que, en el papel, podría no ser tan convincente como programador. El que tiene un título en algo que tiene muy poco que ver con lo que la gente normalmente considera "programación" en campos relacionados: biología, ciencias políticas, historia del arte ...

Si soplan a través de tus desafíos, entonces genial. Aprendieron programación, de alguna manera, y aparentemente está atascado. Si se atascan, su aplicación realmente puede ser algo que se deslizó a través de recursos humanos.

Lo malo : un desafío de programación mal escrito realmente no evalúa habilidades de programación . Prueba la resolución de problemas mediante la habilidad de programación . El problema es que la última pregunta es de dos variables: ¿eres bueno en la resolución de acertijos y puedes resolverlos a través del código? Es posible tener un programador perfectamente talentoso que falla por completo en la parte de resolución de rompecabezas.

La mayoría de los desafíos de programación que he visto también fallan en la detección de personas que están cerca de lo que quieres, dependiendo de cómo esté escrito.

Hay formas de mitigar ambos. Para este último, consideraría aceptar un "crédito parcial" en forma de soluciones que no parecen estar llegando a ese punto, "Así es como resolvería esto ..." etc., si realmente está buscando un problema. solucionadores Después de todo, muy poca gente codifica solo, y si su respuesta hubiera sido correcta si pudieran preguntar a un colega de alto rango "Hey Jim, ¿conoces una buena forma de implementar X?", Eso podría ser la persona que quieras en tu equipo.

Lo primero es un poco más difícil, porque la carga de eso está en ti. Elija rompecabezas / problemas / desafíos que importan. Si nadie en su grupo se ha encontrado con algo que se parezca remotamente al problema de Travelman Salesman en su trabajo, no le dé un giro inteligente a Travellingman, el desafío que se le presenta. De esa manera, si fallan en el aspecto de resolución de problemas de "resuelva el problema y codifíquelo", al menos fallará en algo que realmente surgirá, en lugar de un poco de inteligencia arbitraria que su equipo escupió durante el almuerzo.

Muy efectivo.

... siempre y cuando su proceso de contratación no solo contenga desafíos de programación. Mientras me preocupo y odio hacer la evaluación técnica de cualquier entrevista, sí actúa como un indicador simple para filtrar a los idiotas. Y filtrar a los idiotas es el punto crucial del proceso de reclutamiento, por lo que puede dedicar más tiempo a aquellos que están aptos para la función.

Al entrevistar, considero que es muy importante ver lo que las personas dicen bajo presión. Si están dispuestos a escupir un montón de basura descarada, es fácilmente identificable y sabré que esta persona no merece mi tiempo.

  

Es más probable que tenga miedo de acercarse a nosotros en una feria profesional.

Esto no es algo malo. Si su candidato potencial no está dispuesto a apostar a que vale la pena trabajar allí, ¿realmente quiere reclutarlo?

Supongo que usted quiere que alguien trabaje como parte de un equipo; por lo tanto, el mejor programador es la persona que trabaja mejor con los miembros del equipo existente. Desea reunir a un grupo de personas que puedan comunicarse efectivamente entre sí, que realmente se lleven bien entre sí (no tienen que ser amigos, pero necesitan una buena relación y respeto), que están de acuerdo y use estándares de desarrollo comunes (código y proceso), que están dispuestos a ayudar a sus universidades cuando tratan un tema nuevo o tienen un bloqueo mental (teoría de los cuatro ojos). También debe encontrar una combinación de tipos de personalidad, por lo que si tiene un equipo de introvertidos que rara vez hablan, entonces traer un miembro del equipo más hablador puede mejorar la dinámica del equipo, lo que hará que el equipo sea más productivo. Por otro lado, desea evitar a una persona con una personalidad demasiado fuerte porque dominará el equipo y eso reducirá la calidad y la productividad, especialmente con introvertidos en el equipo.

Después de hacer que una persona encaje en esa combinación, considera una habilidad / habilidad técnica. Estos también necesitan complementarse. Cada uno tiene diferentes áreas en las que son fuertes, otros en los que están bien y algunos no tienen ni idea. Por lo tanto, debe obtener una combinación de fortalezas que sean relevantes para el proyecto en cuestión. Recuerde que un codificador intermedio que trabaja bien con un buen codificador tendrá el nivel de su trabajo elevado por la persona más fuerte. El eslabón débil en la cadena son las relaciones, no las habilidades (siempre que la habilidad esté en el equipo)

Buena suerte en armar eso.