¿Qué estándares se pueden esperar de los ingenieros graduados / junior? [cerrado]

¿Son aceptables los desbordamientos de búfer de un desarrollador graduado? ¿Estamos poniendo el listón demasiado alto? ¿Cuáles son las capacidades esperadas de los ingenieros graduados / junior?

Contexto:

Actualmente estamos reclutando para un puesto de Desarrollador Junior trabajando principalmente en C en Linux.

Como parte del proceso, requerimos que los candidatos completen una prueba de código en su tiempo libre en C.

Hasta ahora hemos rechazado a dos candidatos sobre la base de que su código, aunque legible y en un caso bastante idiomático, sufrió errores de desbordamiento del búfer debido a escrituras de búfer ilimitadas.

[Editar]:

• Solicitamos explícitamente un código de calidad de producción con verificación de errores.
• Ofrecemos un marco de prueba y construcción para los candidatos.

[Actualizar]:

Como resultado de este hilo, y las conversaciones que hemos tenido con otros desarrolladores en persona, estamos cambiando la forma en que realizamos las pruebas de código y a quién nos dirigimos con nuestro reclutamiento.

Decidimos que un candidato que no puede arreglar o comprender un desbordamiento del búfer significa que no sería adecuado para el trabajo que llevamos a cabo, en particular recibiría más tutoría de la que nos sentimos cómodos. Por lo tanto, seguiremos rechazando candidatos que finalmente no puedan enviar una muestra de código robusta.

Sin embargo, hemos implementado algunas medidas para hacer que el proceso de reclutamiento sea más productivo tanto para nosotros como para los candidatos.

En particular:

• Hacemos que nuestras expectativas sean más explícitas, con una explicación clara de lo que entendemos por calidad de producción y una advertencia de que se espera que el código sea robusto con respecto a la entrada y los errores.
• Ahora vinculamos a los candidatos a recursos sobre programación defensiva y la biblioteca estándar C en la descripción de la prueba de código.
• Cambiamos nuestro público objetivo de desarrolladores junior y graduados para apuntar a personas con alguna experiencia relevante.
• En caso de que el código enviado falle de alguna manera, pero de lo contrario sería aceptado, ahora proporcionamos un caso de prueba mínimo que causa la condición de error y brindamos a los candidatos la oportunidad de corregir sus errores (a menos que el código sea rechazado por alguna otra razón). También señalaremos líneas / funciones problemáticas si es apropiado.
• El objetivo de las pruebas en sí ahora ha cambiado ligeramente de un filtro frontal a una oportunidad de construir una mejor imagen del candidato, en particular informará nuestra discusión telefónica. Dicho esto, todavía estamos dispuestos a rechazar basándonos únicamente en el código.

[Actualización 2015-07-09]: Andy Davis de Nujob ha escrito un artículo interesante y relevante sobre el uso de una prueba de código desde la perspectiva del candidato, y vale la pena mirar el artículo. Encuéntralo aquí .

No creo que hayas puesto la barra demasiado alta, creo que podrías necesitar una barra diferente.

Creo que las pruebas de código son útiles para determinar la competencia de un candidato, pero no deberían aprobarse / fallar. Debe usar los resultados de la prueba de código para iniciar un diálogo con el candidato.

Si ve errores que han cometido (especialmente si son desarrolladores junior), indíquelos y pregúnteles qué harían de manera diferente o si entienden por qué hay un problema.

Creo que el calificador junior es lo que marca la diferencia aquí. Los jóvenes no deben ser evaluados por su competencia, deben ser evaluados por su capacidad de aprendizaje, curiosidad, pasión, ética y definitivamente humildad. La suposición con un junior debe ser que no son competentes , es su trabajo como senior para hacerlo.

Obviamente, deberían poder escribir código básico como fizzbuzz y tener un conocimiento general de los conceptos; si se lo señaló y ni siquiera sabían qué era un desbordamiento del búfer, entonces diría que no se puede, pero no espero que un junior escriba más de 5 líneas de código sin un error.

El día en que confía en la competencia de su hijo menor es el día en que debe cuestionarse la suya, los jóvenes deben ser tratados con mucha tutoría y una buena dosis de "confiar pero verificar". Una vez fui junior, y para todos los que estaban allí en ese momento: lo siento. ¿Recuerdas las cosas terribles que hiciste cuando eras menor? (Por favor, no me digas que solo fui yo; me darás un complejo ...)

Veo algunos problemas aquí.

La primera es suponer que un graduado promedio en informática sabe, bueno, cualquier cosa. Ellos no. Francamente, estoy gratamente sorprendido cuando veo a un graduado en informática que sabe cómo instalar y configurar Visual Studio . Diablos, recientemente trabajé con un tipo que afirma tener más de cinco años de experiencia en la pila de Microsoft escribiendo código .NET que no pudo entender qué era TFS o cómo conectarse.

El segundo es su grupo muy limitado. También tenemos candidatos para hacer una prueba de programación. Hay cinco "programas" separados que tienen que escribir. Lo hacen en casa y envían el código. Las pruebas son extremadamente simples (sin base de datos, sin dependencias externas) y se pueden hacer fácilmente con la versión Express de Visual Studio. Las pruebas en sí se completan fácilmente por un hombre mayor en unos 30 minutos. Tenga en cuenta que generalmente solo hacemos esto para los recién graduados con hasta tres años de experiencia laboral verificable.

Lo que hemos cuantificado es que alrededor del 70% de los que se someten a la prueba simplemente nunca nos responden. Aproximadamente el 15% entrega cosas que no se compilan, generalmente debido a errores de sintaxis evidentes (por ejemplo, falta ;). Otro 10% compila pero no realiza las acciones requeridas.

Esto deja un enorme 5%. En este punto, ni siquiera estamos considerando condiciones como ingresar un carácter alfa como entrada cuando se requiere uno numérico. Es puramente dado un conjunto muy limitado de X como entrada, la aplicación realiza la salida adecuada. Además, estos números provienen de aproximadamente 500 candidatos en los últimos cuatro años: mantuvimos estadísticas porque queríamos saber.

Si tuviéramos que analizar más la estructura del código y las técnicas de codificación defensiva, como la disposición adecuada de los recursos no administrados o el uso de try .. catchdeclaraciones, casi nadie pasaría.

La pregunta, por supuesto, es ¿por qué?

¿Por qué un niño con un título en este campo de una universidad de cuatro años no puede lograr lo que son tareas de programación simples? La respuesta es que las universidades están completamente fuera de contacto con las necesidades del negocio y están muy por detrás de lo que consideramos de vanguardia. Hace 10 años, los estándares de codificación eran tales que la seguridad era algo que se hacía después del hecho; y las pruebas unitarias aún no estaban de moda. Mientras que hoy la seguridad es mejor estar a la vanguardia de su mente con cada característica o mejora. Solo recuerda: la mayoría de los profesores nunca han trabajado en este campo O no han trabajado en él durante mucho tiempo. Una vez que sabes eso, comienzas a entender por qué están tan atrasados. Peor aún, algunos de esos profesores pasan demasiado tiempo en una tecnología en particular ( Java , PHP, lo que sea) y no discuten problemas fundamentales serios como la estructura del código o los enfoques aceptables (¡y POR QUÉ!).

Solo un ejemplo secundario. Un recién graduado me estaba contando algo de su experiencia escribiendo un sistema operativo móvil para una de sus clases, pero no pudo explicar, ni siquiera en términos básicos, cómo funcionaba un servidor web. Simplemente no lo sabía. Hace 15 o 20 años fue probablemente el momento adecuado para comprender cómo hacer un sistema operativo. Hoy ... no tanto. Sin embargo, esta era una clase obligatoria cuando una clase de programación defensiva sería mucho más útil para ellos y para el mundo exterior.

¿Asi que que hacemos?

Fuera de ese 5%, entrevistaremos un poco más para tener una idea de su personalidad y forma. Luego elegimos los "mejores" con pleno conocimiento de que vamos a pasar unos seis meses "reprogramando" para deshacerse de la basura con la que sus profesores los llenaron.

Creo que estás viendo el problema de la manera incorrecta. Lo que debe preguntarse es esto: ¿Qué le exigimos a un candidato para que pueda hacer el trabajo? Debe evaluar adecuadamente la posición y lo que implica. A continuación hay algunas sugerencias sobre cuándo contratar a un desarrollador junior y cuándo no hacerlo.

Cuándo contratar a un desarrollador junior: - Si hay un exceso de trabajo fácil por hacer, lo que sería una pérdida de tiempo para un desarrollador más senior. - Si está dispuesto a guiar y capacitar a esta persona en los próximos años. - Si está tratando de hacer crecer la empresa y quiere a alguien que se quede por mucho tiempo. Un desarrollador junior que se queda solo un año sería un desperdicio de recursos de la compañía, haría poco para producir algo y la mayoría de los resultados serían en su propio crecimiento personal. - Cuando tiene ganas de gastar dinero en el crecimiento de alguien. Desde entonces, la mayoría de los beneficios serán lo que aprendan.

Cuando no contratar a un desarrollador junior. - Cuando el trabajo es demasiado complicado. En este caso, está fuera de su alcance. - Cuando quieres ahorrar dinero. Un desarrollador senior debe completar las mismas tareas en una fracción del tiempo con resultados de mejor calidad y, por lo tanto, siempre debe ser más barato. - Cuando el trabajo es subcontratado o no es suficiente para mantener ocupado a un empleado. En tales casos, sería mejor descargar parte del trabajo a un contratista privado.

Un último punto importante. No contrate a un desarrollador junior porque "eso es todo lo que podemos permitirnos" o "eso es todo lo que estamos dispuestos a gastar" cuando no son adecuados para el trabajo. Al final, todo lo que terminarás haciendo es tirar el dinero por el inodoro. Además, una vez que adquieran esas habilidades, solicitarán mucho dinero de todos modos.

Sobre mi:

• Licenciado en física casi sin entrenamiento formal.
• Dos años de experiencia laboral. Entonces sé de qué se trata el proceso de aprendizaje.
• Iniciar desarrollador de software. He realizado un trabajo muy exigente y he visto diferentes niveles de habilidad de varias personas. Muchos de ellos no pueden manejar mucho de lo que hago.

Como otros mencionaron, los puestos junior pueden tener poca experiencia con C. Personalmente, solo me enseñaron brevemente sobre los desbordamientos del búfer en C e incluso si pudiera vigilarlos, es probable que aún presente algunos (especialmente si se me da una asignación que presta a sí mismo para crear desbordamientos de búfer). Probablemente, muchos desarrolladores junior tendrán una situación similar en la que pueden conocer desbordamientos del búfer, pero no están preparados para identificarlos y manejarlos de manera extensa.

Dado esto, creo que la respuesta adecuada es plantear el problema en la próxima interacción posible y preguntarles qué saben sobre los desbordamientos del búfer para probar su conocimiento general. Después de eso, diles que encontraste uno en su supuesto código de producción lista. Esto le daría una buena ventana para juzgar cómo reaccionarían ante la corrección y la instrucción.

¿No es más común pensar que un desarrollador junior que sabe menos pero está dispuesto y es capaz de aprender y mejorar es más valioso que un desarrollador junior que sabe más pero que no puede o no mejorará?

Dicho esto, en uno de sus comentarios que mencionó, les entregó pruebas que habrían señalado el desbordamiento del búfer en su código si los hubieran utilizado. Entonces, quizás la pregunta más importante es ¿por qué no ejecutaron las pruebas (o si lo hicieron, por qué entregaron el código con errores)?

Un desbordamiento de búfer es absolutamente imposible. Podría tener una pregunta de código correspondiente. En lo que todo está mal (puede salir mal) con este código, el candidato debería ser capaz de identificar el problema. La pregunta es si el problema es irrelevante, ya que de todos modos está ejecutando clint.

Sin embargo, en una prueba de código de forma libre artificial, sería leve en una violación como sprintf. Muy poco tiempo (asumido), mente hiperactiva, demasiada necesidad de presentar algo que funcione.

Creo que estás haciendo la pregunta equivocada. No hay una barra objetiva para ser un programador profesional. Si lo hubiera, habría un examen de programación estándar, pero no lo hay. Su barra individual solo debe establecerse en función de lo exigente que puede permitirse ser, cuánto puede pagar, cuánto error puede aceptar su software y cuánto tiempo puede dedicar a enseñar.

En este caso, supongo que un desbordamiento del búfer probablemente significa que este código, que el candidato presentó como una muestra de trabajo ejemplar, se bloquea con una falla de segmentación en lugar de hacer lo que usted pidió. Entonces, ¿debería aceptar un codificador que escribe código que falla con una falla de segmentación en lugar de hacer lo que le pidió? Pedir:

• ¿Es su organización capaz de atraer a cualquiera que pueda escribir código de trabajo?

• ¿Es su proceso de desarrollo lo suficientemente robusto como para que alguien que pueda casi escribir código pueda escribir código de trabajo con la ayuda de revisión por pares y soporte de prueba?

• ¿Eres capaz de enseñar a los programadores a ser programadores, y estás dispuesto a gastar ese esfuerzo y esperar unos años y esperar que el talento interno del candidato se haga realidad?