Prueba de codificación previa a la detección: ¿cuánto tiempo es razonable? [cerrado]

EDITAR

Después de una buena cantidad de pensamiento y autorreflexión sobre el tema, me di cuenta de que la mayoría de los problemas que planteé en esta pregunta provenían solo de una perspectiva personal, más que profesional. Por lo tanto, los moderadores pusieron esta pregunta en espera debido a la naturaleza altamente personal y subjetiva del problema del que intenté hablar. Estaba pensando en reformular la pregunta, pero realmente no pude encontrar una manera posible de manifestar la pregunta de manera más objetiva, por lo que puede ser el tema de una discusión donde las respuestas pueden respaldarse con algún tipo de evidencia o referencias.

Por el bien de aquellos que todavía están interesados, estoy tratando de dar un resumen de la discusión que surgió de esta pregunta:

• una prueba de programación previa a la entrevista de 4 horas no es habitual, pero
• muchas personas señalaron que para algunas empresas se entrevistaría por mucho, mucho más tiempo que eso, todos juntos
• es nuestra decisión personal si tomamos una prueba o no, y podemos evaluar esto en función de nuestras circunstancias y los beneficios percibidos de ser contratados para la empresa
• todas las empresas son diferentes, como lo son las personas, y puede ser perfectamente razonable que una empresa emplee una prueba externa más larga antes de la entrevista, si eso es lo que se ajusta a sus necesidades o circunstancias

Quería que mi pregunta original fuera sobre cuán razonable es esperar 4 horas de mí y cuán ético es dar un problema para que la solución (no el código, sino el diseño) pueda usarse para la compañía. Como ahora puedo ver, estas dos preguntas solo pueden (en el mejor de los casos) ser exploradas en una discusión del foro, en lugar de usar una herramienta de comunidad de tipo pregunta-respuesta como stackexchange.

Sin embargo, encontré todas sus respuestas valiosas y gracias por compartir.

POSTE ORIGINAL

Estoy entrevistando para varios puestos, y la mayoría de ellos incluyen una fase de preselección donde tengo que presentar una prueba de codificación antes de la entrevista telefónica o la entrevista en el lugar. Ya me he acostumbrado a esta idea, y considero bastante razonable que las empresas esperen que haga esto para que puedan verificar qué tipo de trabajo puedo producir por mi cuenta.

En general, mi experiencia es que este tipo de ejercicios de codificación son en su mayoría pequeñas tareas de programación. Haga un poco de lógica, tal vez implemente un pequeño algoritmo, abra un archivo y lea / escriba datos, cosas así. Incluso la tarea más simple se puede implementar con una buena separación de lógica, componentes comprobables, etc., para ver cómo codifica el candidato, en general, qué tan bien está preparado para el tipo de trabajo que una empresa desea completar.

Recientemente me encontré con una empresa que me envió una prueba de codificación con una descripción completa de su ejercicio, pidiéndome que resolviera un problema de la vida real de su negocio (no quiero decir detalles específicos para proteger a la empresa, pero la prueba era más o menos lo que hacen). Describieron un sistema bastante complejo para implementar, incluyeron datos reales, y al final concluyeron que la prueba de codificación no debería tomar más de 4 horas .

¿Es razonable que una empresa espere que pase 4 horas trabajando en su asignación ficticia en mi tiempo libre, incluso antes de que me saludaran? (el reclutador me envió la prueba de codificación)

No me malinterpreten, estoy motivado para encontrar un nuevo trabajo y nuevos desafíos, pero la mayoría de las compañías esperan que pase un máximo de 1-2 horas en una tarea como esa, y esas tareas siempre han sido mucho menos complicadas.

Lo que llegué a la conclusión de esta compañía es que:

1) Mi motivación no es buena y probablemente estén buscando a alguien más

2) No respetan a sus futuros empleados que esperan que se realicen pruebas de codificación tan largas incluso sin saludarlos

3) Solo quieren dar a conocer uno de los problemas en los que trabajan y ver si hay un joven entusiasta que lo resolvería de forma gratuita (de nuevo, no me malinterpreten, no soy un teórico de la conspiración, pero tengo escuché tales historias ...)

¿Cuánto cree que es razonable que una empresa espere que los candidatos pasen tiempo en sus pruebas de codificación ficticias sin hablar con ellos? ¿Cuál es tu experiencia en general?

Permítanme tomar el lado de la compañía por un momento, ya que las otras respuestas no lo han hecho hasta ahora. Sería casi imposible construir una base de código utilizable a partir de un conglomerado de envíos de pruebas de codificación de 4 horas de personas cuyas calificaciones son completamente desconocidas. Crear una especificación suficientemente detallada, examinar las respuestas e integrarla con el resto de su código tomaría más de 4 horas. Sin mencionar que los proyectos de software de nivel empresarial más útiles requieren miles de horas hombre. La idea de construir un negocio dividiéndolo en incrementos de 4 horas con semanas de tiempo de respuesta cada uno es francamente ridículo.

Dar un problema de la vida real del negocio es una de las mejores maneras de determinar si alguien será bueno, sorprendentemente, para resolver problemas de la vida real del negocio. Hago esto con frecuencia en entrevistas (aunque pido principios de diseño generales y no 4 horas de código), y cada vez ha sido un problema que ya he resuelto. Si no lo hubiera resuelto, la prueba perdería casi todo el valor probatorio.

Si una prueba de 4 horas vale la pena para usted es una decisión personal. Siempre me enseñaron a tratar la búsqueda de trabajo a tiempo completo como un trabajo a tiempo completo. Cuando estás desempleado o subempleado y pasas 8 horas al día buscando trabajo, una prueba de codificación de 4 horas no es nada. He pasado mucho más tiempo que eso en tareas como repasar idiomas oxidados, escribir programas de cartera y personalizar currículums para puestos específicos.

Por otro lado, algunos de los mejores trabajadores ya tienen un empleo remunerado y solo buscan oportunidades de manera informal. Es poco probable que las personas en esa situación pasen por la rigamarole de una prueba de 4 horas, a menos que la oportunidad sea estelar. Sin embargo, ese es el problema de la compañía, no el suyo.

En cuanto a discernir lo que significa la actitud de la empresa hacia sus empleados, no creo que se pueda decir nada de ninguna manera, aparte de que probablemente estén cansados ​​de tratar con solicitantes no calificados, en un grado que estén dispuestos a arrojar. fuera algo de lo bueno con lo malo.

No, no es típico , ¿por qué resuelves sus problemas de forma gratuita? (4 horas)

1 hora es típico para una prueba de programación. En el pasado nuestra prueba de programación tenía 4 preguntas. Las primeras 3 preguntas tomaron 1/2 hora, la última media hora. También dimos la prueba a los empleados existentes en la empresa para asegurarnos de que estuviéramos en el plazo esperado y que la prueba fuera justa y ajustada de manera acorde.

Las primeras preguntas fueron del tipo "Fizz Buzz" para eliminar a las personas que no pueden programar. Se volvieron progresivamente más difíciles. La última pregunta fue un ejercicio de resolución de problemas. En general, tratamos de limitar la cantidad de código escrito a unos cientos de líneas (total) y no requerimos ningún truco inteligente. También calificamos a las personas en el manejo de errores, estilo, sintaxis, organización, etc. Las preguntas no estaban relacionadas con nuestro negocio sino con las habilidades y la tecnología en las que estaba escrita la plataforma actual.

Por lo general, los grandes candidatos terminaron en menos tiempo del asignado. A veces, las personas solicitan tiempo adicional que permitimos debido al estrés que implica tomar una prueba, pero limitamos a todos en un cierto límite. La prueba se realizó en el entorno de desarrollo actual y las personas tuvieron acceso a Internet para obtener información de referencia. También revisamos las expectativas del cuestionario a cada candidato.

En un momento discutimos la incorporación de nuestra base de código (mundo real) en el cuestionario, pero finalmente lo descartamos debido a las preocupaciones de que el código se copió / robó / etc. (nuestro jefe era un poco paranoico). Finalmente, fuimos con un equipo separado quiz.slnen una máquina de desarrollo aislada.

Finalmente, descubrimos que era difícil hacer una prueba que fuera justa, pero ni demasiado difícil ni demasiado fácil. Siempre les preguntamos a nuestros candidatos sobre el cuestionario después de que lo tomaron y obtuvimos sus comentarios para refinarlo para futuros candidatos.

Creo que las pruebas de codificación en la entrevista son un montón de tosh de todos modos. Nadie codifica nada excepto la rutina más simple bajo presión sin el entorno y las herramientas habituales, por lo que los resultados que obtienes son dudosos en el mejor de los casos.

Lo que he encontrado como pruebas realmente buenas de la capacidad de un programador es darle un código de proyecto y pedirle que lo revise, esto funciona muy bien si el código tiene varios errores obvios, varios problemas de código obvios y algunas prácticas cuestionables. Un buen programador le dirá todos ellos y se comprometerá con usted para discutir por qué algunos códigos no están 'mal', pero podrían hacerse mejor para facilitar el mantenimiento más o menos. Un programador pobre encontrará un error y se detendrá.

Cualquier trabajo que espere que haga una prueba que tome más de media hora simplemente no ha pasado ni tanto tiempo trabajando en una buena prueba dirigida que les brinde una idea más que vaga de sus habilidades. (a la mayoría de las empresas les resulta muy difícil dedicar tiempo a la configuración previa a la entrevista).

Si me hicieran una prueba como la que tienes, escribiría la respuesta en pseudocódigo. Eso debería ser suficiente para demostrar mi comprensión de la codificación y el diseño, sin pasar por las fases completas de compilación, compilación y prueba que haría para un proyecto de trabajo normal.

Puede que no tenga 4 horas, pero alguien más interesado en su compañía ciertamente lo tendrá. Básicamente me contrataron en base a una tarea similar que una compañía me pidió que hiciera de antemano solo en la tarea. Aparentemente, escribir código limpio y comprensible, casos de prueba exhaustivos y documentación de diseño comprensible y coherente es una anomalía. Ver a alguien haciéndolo enloqueció. De todos modos, todos con los que hablé en la entrevista me felicitaron por lo que hice y sentí que no tenía que impresionar a nadie en la entrevista porque ya habían tomado una decisión. Era simplemente una cuestión de mí no darles una razón para decir no haciendo algo estúpido.

Entonces, aunque estoy de acuerdo en que 4 horas es una inversión de tiempo bastante grande, también significa que la tarea es de un tamaño suficiente para que tenga la oportunidad de mostrar realmente de lo que es capaz. Su trabajo muy bien puede decir mucho más de lo que podría en una entrevista real.

Como nota al margen: últimamente he intentado algo similar pero con un problema mucho menor y no estoy contento con los resultados. Los pequeños problemas son triviales para demostrar suficiente conocimiento de la persona. Además, los problemas triviales requieren que la persona reconozca algún truco / detalle necesario para resolver el problema. Por lo tanto, existe cierto equilibrio entre tomar demasiado tiempo de una persona y no obtener ningún beneficio real porque la tarea es trivial. Creo que una tarea de 4 horas es probablemente la cantidad de tiempo adecuada para ser lo suficientemente compleja como para que los candidatos demuestren sus habilidades y no sean tan largos que nadie se moleste.

Tomé una prueba de codificación de 6 horas en un punto. Cuando tomé esta prueba, tenía bastante confianza en que me contratarían, aunque se hizo realidad, no estaba tan satisfecho con el seguimiento.

Obviamente, tener muchos empleadores pidiendo cada uno 4 horas es excesivo. Lo que la persona estaba buscando en la prueba que tomé fue mi estilo de codificación: me contrataron porque el mío era "más cercano" al suyo. En este contexto, mire el problema desde esta perspectiva: Primero, ¿es un problema interesante que la resolución le valga en cualquier caso? Después de todo, podrías aprender algo valioso.

En segundo lugar, si puede "pasar" la prueba, ¿significa que está contratado? Si esto no es bastante obvio, entonces debe decidir si hay otras razones para hacerlo de todos modos.

En tercer lugar, podrían estimar que lleva '4 horas', pero es posible que descubras de manera diferente. ¿Saben realmente cuánto tiempo debería llevar esto? Lo más probable es que la respuesta sea no. Por lo tanto, seguirán probando a las personas en plazos de 4 horas hasta que se den cuenta de que no encajará en cuatro horas. En ese caso estás perdiendo el tiempo. Entonces, el mejor enfoque es ser agresivo con el gerente de contratación y determinar si debe detenerse a las cuatro horas y darles lo que tiene, o continuar hasta que termine y decirles cuánto tiempo tomó. En resumen, puede haber una prueba de carácter envuelta en esto, y simplemente tratar de aceptarlo en sus términos puede revelar inexperiencia.