El valor y la propiedad de las preguntas de la entrevista de programación para desarrolladores

Recientemente me pidieron que creara una aplicación completa que incluyera una lista de funciones. Cuando le estaba explicando esto a mi esposo, inmediatamente se volvió incrédulo y acusó a la compañía de usar entrevistas para robar el código de los desarrolladores, especialmente cuando se les pidió que proporcionaran un programa de trabajo completo.

Para decirlo en una palabra: tonterías. El código proporcionado por los solicitantes de empleo aterriza universalmente en el mismo lugar que el CV después de que finaliza el proceso de contratación, y eso es un archivo para futuras referencias o un basurero.

La cantidad de trabajo que requeriría incluir el código de prueba en el producto de producción es, casi siempre, mucho mayor que lo que se necesitaría para agregar/escribir dicha característica dentro del ecosistema existente. Y eso se basa en la suposición de que su solución por sí sola está lista para producción y solo necesita integración, lo que rara vez es cierto para el código de entrevista.

La razón por la que cada vez más empresas finalmente se despiertan y usan problemas de la vida real para sus desafíos de codificación, en lugar de cosas abstractas como la codificación, es muy simple: de esta manera, está probando cómo manejará algo similar a su día a día. soluciones, en lugar de problemas muy abstractos y no relacionados con el trabajo (la mayoría de las veces) ofrecidos en probadores automáticos.

Esto es algo que he estado defendiendo durante años, y es una forma fantástica de eliminar todo tipo de solicitantes de copiar y pegar, lo que le permite concentrar más esfuerzo y tiempo en aquellos que realmente se preocupan por el trabajo.

Estoy tan acostumbrado a codificar en línea, ya sea durante pruebas de mejora personal o en una entrevista, que ni siquiera había considerado quién tenía acceso a mi código, si se está utilizando para algún otro propósito o si es valioso.

Es prácticamente inútil y por cada anuncio de trabajo recibirán docenas de soluciones (el número real varía según muchos factores, pero el punto es que obtendrán múltiplos de ellas).

¿Es una teoría común que las respuestas de las entrevistas de los desarrolladores son robadas? ¿Qué tipo de protección está disponible o hay garantías que los desarrolladores deberían buscar durante la entrevista?

Nunca escuché de un solo caso de que eso sucediera, 1ra o 2da mano. Y trabajé con alrededor de ~ 15 empresas de TI/casas de software en un lapso de casi dos décadas. Ni siquiera lo escuché sugerido por las razones explicadas anteriormente.

Si algo que ha creado para una entrevista tiene, en su mente, un valor tan profundo para usted, le sugiero que abra un repositorio de GitHub y lo publique allí. Asegúrese de volver a trabajar en la tarea con la que se relaciona y coloque la versión modificada en el archivo Léame, para que algunos futuros candidatos no la encuentren buscando en Google la tarea. Entonces, incluso si no obtiene el trabajo, tiene una nueva y sexy entrada en su cartera.

Esta fue una de las cinco preguntas que tenían un límite de tiempo de 45 minutos.

Con el debido respeto, su esposo acaba de ver demasiadas películas de Hollywood poco realistas.

El hecho de que pueda codificar algo realmente valioso desde cero para un empleador en condiciones de entrevista en menos de 45 minutos es sumamente tonto. No me importa si eres el maldito mejor programador del mundo. Lo que está pensando no es posible para nadie.

Ahora digamos que no eres cualquiera, eres David Heinemeier Hansson, creador de Ruby on Rails. David Hansson podría generar un muy buen esqueleto completo (CRUD) de una aplicación web en menos de dos minutos. Eso no sería un problema para él.

Pero para cualquier otra persona con una conexión web, su generador de código está en línea, puede descargarlo o cargarlo como una gema de rubí. Eso es todo. Tú lo ejecutas. Bang y obtendrá una aplicación de Ruby on Rails completamente funcional. Pero si tu esposo piensa que ahí termina el trabajo, en eso se equivoca.

El uso de un generador de código o la descarga de una plantilla preparada solo puede llevarlo hasta cierto punto. Se necesitarán cientos de horas, si no miles de horas, para personalizar, ajustar, escalar y probar dicha aplicación.

Y ver a alguien hacer eso en 45 minutos puede darte una buena indicación de su velocidad, pero no te da mucho más. Github está repleto de millones de proyectos a medias iniciados a medias. Eso no hace que esos proyectos sean valiosos para un empleador. Además, no es que esos proyectos ya no se puedan descargar de forma gratuita.