¿Debería una compañía de tecnología dar una prueba de codificación genérica a cada solicitante antes de programar una entrevista en el sitio?

Los reclutadores no pueden optar por hacer una prueba a algunos candidatos y no a otros. La ley de empleo (al menos en los EE. UU.) Exige que traten a todos los candidatos por igual, de modo que ningún candidato tenga una ventaja injusta. Entonces, o cada candidato obtiene una prueba, o ninguno de ellos lo hace.

El problema que enfrentan las empresas de tecnología es que obtienen muchos solicitantes para cada puesto, y es fácil falsificar la experiencia de codificación. La mayoría de los candidatos no mienten por completo en su currículum, pero no hay forma de saber de una lista de proyectos que alguien trabajó en la codificación que realmente hicieron en esos proyectos. Entonces, en algún momento, la compañía tiene que verificar si un candidato tiene habilidades básicas de codificación.

Las compañías grandes y conocidas tienen muchos recursos, y también tienen más que perder al rechazar a los mejores candidatos, a quienes en realidad tienen una posibilidad razonable de reclutar. Entonces solo gastan el tiempo / dinero y hacen que una persona realice una pantalla inicial. Para las empresas más pequeñas o menos conocidas, creo que hay un buen argumento para usar algún tipo de detección automatizada. Claro, algunos buenos candidatos podrían verse desanimados por ese proceso, pero otros podrían estar intrigados por un acertijo bien elaborado. Incluso Google usó esa técnica una vez (Google atrae a los buscadores de empleo con Math Puzzle).

Una nota sobre el tipo de prueba. Si la prueba de codificación “genérica” ​​a la que se hace referencia en la pregunta significa un solo problema que nunca cambia, entonces estoy de acuerdo en que no tiene mucho sentido. Pero no es difícil hacerlo mejor que eso. Hay empresas (por ejemplo, CodeEval) que realizarán pruebas de una manera más sofisticada, incluida la comprobación de plagio. Todavía tienen mucho trabajo que hacer para pulir el proceso, pero con el número de puestos de programación que aumenta cada año, creo que se convertirán en una parte más importante del proceso de la entrevista. Si eres un programador superestrella, entonces no estás pasando por la puerta principal de todos modos. Estás llamando a alguien en tu red y saltando al frente de la línea. Para todos los demás, un rompecabezas de preselección no es demasiado doloroso si se maneja bien. Las personas que leen Programación competitiva hacen esas cosas por diversión.

Soy desarrollador de software durante 7–8 años y me uní a muchas entrevistas; algunos de ellos estaban con exámenes de codificación, otros no; pero honestamente puedo decir que este tipo de eliminación es inútil, voy a explicar a continuación “por qué”.

Me enfrenté a 4 tipos de examen en el pasado.

1- Examen con preguntas directas: el entrevistador le hace algunas preguntas técnicas directamente de acuerdo con su currículum y los proyectos que incluyó en el pasado. Por ejemplo, “¿Qué patrones usaste en el proyecto xxx y por qué?” , ‘¿Qué es el viewbag?’, ‘¿Cuál es la sesión?’, ‘¿Qué es la inyección de dependencia?’ y … etc. No estoy seguro de que este tipo de preguntas sean útiles para comprender las habilidades de un desarrollador; especialmente si el entrevistador no está suficientemente calificado. La mayoría de las veces que enfrenté al entrevistador no sabe sobre las respuestas de estas preguntas y no podía entender que respondiste correctamente o ni siquiera das la misma respuesta que está escrita en sus documentos.

2- el examen de los códigos en papel: algunas veces me enfrenté a este tipo de exámenes y puedo decir que la paja fue bastante estúpida. No estoy seguro de que pueda resolver un problema con los códigos en un papel. Si trató de contratar a un junior y hacer algunas preguntas de muestra, entonces podría estar bien, pero preguntar así al desarrollador senior no es una buena manera y, como sé también de mis amigos después de este tipo de examen, la gente perdió sus motivaciones para trabajar en este lugar .

3- El examen en computadora con códigos: el entrevistador le hace un examen en computadora con algunos problemas y usted tiene que resolverlos. Algunas veces te obligan a usar algunos patrones, por ejemplo, ‘Resuelve este problema con el patrón de comando’. Este tipo de examen podría ser comprensible pero aún no lo suficientemente útil; debido al estrés del examen, temas sin interés, preguntas poco claras y banalidad de las preguntas. Por ejemplo, le preguntan sobre la creación de un programa para encontrar el camino más corto entre dos puntos para una colonia de hormigas. Entonces, este tipo de pregunta puede no interesarle y es posible que no conozca el algoritmo y creo que no lo convierte en un mal desarrollador y, por otro lado, puede encontrar la respuesta de esta pregunta con una simple búsqueda en Google.

4- Pregunte acerca de crear un proyecto con algunos desafíos y con algunas tecnologías específicas: desde mi punto de vista, esta es la mejor manera de comprender las habilidades de codificación de un desarrollador. Puede comprender muchas cosas sobre un desarrollador de esta manera, puede comprender que él / ella usa estándares de codificación, conocimiento sobre patrones, estándares de nombres, conocimiento de tecnologías reales … etc. Pero haga esto si realmente está cerca de contratarlos; porque este tipo de proyecto de muestra también puede tomar muchas veces.

Finalmente, creo que entiendes que un desarrollador es bueno para ti o no solo por una conversación, y no olvides que las habilidades de codificación no son las cosas más importantes algunas veces.

Si bien sería ideal dejar que un reclutador decida cuál de sus candidatos potenciales desea examinar con desafíos de código, la desafortunada realidad es que los reclutadores de tecnología ahora están tan llenos de candidatos que simplemente no tienen tiempo para tomar una decisión detallada sobre de forma individual Además, la mayoría de las veces, los reclutadores de las compañías tecnológicas no tienen la misma habilidad de codificación que sus candidatos, por lo que no tienen una rúbrica sólida para decidir quién debe obtener una pantalla de código y quién no.

Proporcionar un desafío de código básico antes de evaluar a un candidato más puede ayudar a eliminar a los solicitantes sorprendentemente no calificados, de esa manera, el tiempo de un reclutador (muy valioso) no se desperdicia en el teléfono de detección de alguien no calificado. Por ejemplo, en Rocket Fuel, cada candidato en la parte superior del embudo fue examinado por teléfono. Aunque el proceso fue corto (10-20 minutos), con más de 1,000 solicitantes al año, ese tiempo se sumaría.

Rocket Fuel comenzó a usar un desafío de código HackerRank como parte de su proceso de solicitud, y el 24% de sus solicitantes no completaron el desafío. Eso se traduce en aproximadamente 240 solicitantes no calificados que hubieran sido seleccionados de otra manera.

Además, Rocket Fuel pudo identificar al 15% superior de los solicitantes en función de la calidad de su código. Entonces, ahorran tiempo al no evaluar a los restantes 85% de los candidatos. De ese 15%, HackerRank ayuda a RocketFuel a identificar cualquier caso de plagio, y esos candidatos son descalificados.

Al final del día, Rocket Fuel pasó de seleccionar 1000 candidatos por año, a los 114 candidatos principales, lo que resultó en un ahorro de tiempo del 88% y se aseguró de que solo entrevistaran a los mejores candidatos en el sitio.

Puede consultar más información sobre cómo las fuentes de combustible de cohetes y los ingenieros contratan un 88% más eficientemente con HackerRank, o puede comenzar a reclutar más rápido y mejor con una prueba gratuita de HackerRank for Work.

Mi empresa ha hecho que todos los candidatos realicen una prueba de codificación antes de la entrevista in situ durante casi 10 años. La “prueba” consta de dos partes. La primera parte es implementar una función de la que proporcionamos la definición. Esto prueba su capacidad de escribir código. La segunda parte es agregar comentarios a una función. Esto prueba su capacidad para leer, comprender y documentar el código de otra persona. Estas son algunas de las razones por las que lo hacemos.

1. Al menos la mitad de las personas que toman el examen no obtienen una entrevista en el sitio. Si bien el tiempo del candidato puede ser importante, el mío definitivamente lo es. Se necesita tiempo para programar la entrevista en el lugar, organizar quién hablará con la persona, despejar horarios, etc. Si descubre que la persona es un fracaso en los primeros cinco minutos, no puede terminarla limpiamente y enviarla. casa. Esta es la mayor causa de fricción y pérdida de tiempo. Es mucho mejor saber de antemano y evitar todo esto.

2. No se puede distinguir la capacidad de codificación de un currículum. He visto currículums magníficos para personas que no podían escribir un bucle for. Esto parece ser especialmente cierto para los candidatos que obtienen su maestría. Es posible que tengan muchos conocimientos especializados o teóricos, pero pocos o ningún conocimiento práctico que ayude a la empresa.

3. Proporciona un buen punto de discusión durante la entrevista en el sitio. Puede hacer un seguimiento con las preguntas de tipo “por qué hizo esto” o “cómo más podría haber hecho esto”.

4. A los buenos programadores les gusta el desafío. La mayoría de las personas que pasan la prueba realmente lo disfrutan. Nuestra prueba no tiene límite de tiempo, pero el tiempo que toma es un factor en la evaluación. Los mejores programadores pueden completarlo en 15-20 minutos. Algo más de una hora es una bandera roja.

5. No es mucho pedir. Si está buscando dónde va a trabajar durante los próximos años, entonces invertir una hora más o menos de antemano no es el fin del mundo.

Los candidatos pueden estar extremadamente ocupados, sí, pero también los reclutadores y los entrevistadores. Ese es el objetivo de una prueba de codificación, para ahorrar tiempo. Si se administra antes de la entrevista, ya que TestDome sugiere que se usen sus pruebas, entonces la prueba actúa como un filtro para los malos programadores. No creería cuántos candidatos de baja calidad solicitan empleos para los que apenas están calificados, o incluso sin calificar. Por esta razón, debe haber una forma de filtrarlos rápidamente antes de que pierdas tu tiempo (y el de ellos).

Las pruebas de codificación nunca tienen la intención principal de evaluar el nivel de habilidad de un programador. O al menos no deberían serlo. Pueden ser muy útiles como parte del proceso de selección, pero la entrevista técnica es donde se evalúa la calidad de una persona.

El problema es que, dado que las pruebas de codificación son tan fáciles de administrar, tienden a ser utilizadas en exceso sin pensar mucho en cuánto y cuándo deben usarse. Idealmente, las pruebas de codificación se deben utilizar para obtener una medida aproximada de las habilidades de un candidato que se evaluarán en profundidad durante la entrevista técnica, y para actuar como un filtro para candidatos inadecuados. Puede ser uno u otro, o ambos, dependiendo de cómo se cree la prueba, que es otro problema. Las pruebas de codificación, por supuesto, difieren en su calidad y utilidad, pero ese es otro tema.

No lo creo porque ya hay muchos criterios (perfil, exp, etc.) después de los cuales se seleccionan los candidatos. Y si agrega alguna prueba de codificación genérica, lo más probable es que termine en Google en todos los foros y, finalmente, será inútil, y no puede tener preguntas diferentes y el reclutador no tiene esas habilidades técnicas para tener múltiples preguntas de prueba.