Versión corta
Si el trabajo consiste en mantener una aplicación, las habilidades que necesita probar durante las entrevistas son:
-
La capacidad de comprender el gran código base con su documentación, pruebas unitarias , etc.
-
La capacidad de refactorizar el código y de traer cambios sin romper todo.
Pedirle a la gente que lea el código no te ayudará a evaluar esas habilidades.
Versión larga
¿Te preguntaron por escribir código? En caso afirmativo, como indica Sign en su respuesta , esto es suficiente. Si generalizamos un poco, una persona que escriba un código fuente claro y fácil de entender podrá leer el código fuente escrito por otras personas.
Si no se le pidió que escribiera un código, entonces, probablemente, fue entrevistado por una persona del departamento de recursos humanos. Dichas entrevistas no pueden ser demasiado técnicas, y en su mayoría carecen de valor, ya que no aprovechan sus habilidades y su capacidad para trabajar bien, sino la cantidad de años que pasó en la universidad y otras cosas que no tienen nada que ver con el trabajo. / p>
Hay algunas razones más para no solicitar leer el código para un trabajo de mantenimiento:
1. Es difícil hacerlo de forma confiable
Concretamente, ¿qué harías si fueras un entrevistador? Haz que tus candidatos lean un código. ¿Qué código? ¿En que idioma? ¿Qué tan bien o mal escrito? ¿Con o sin comentarios? ¿Con o sin documentación?
Más importante aún, ¿qué dice sobre el candidato? ¿Qué tan bien se correlaciona con el código base en sí?
Supongamos que tiene una aplicación VB.NET heredada para mantener. Usted sabe que el código fuente es en su mayoría feo y no probado, y algunos comentarios son obsoletos o engañosos. Durante los últimos tres meses, tuvo un desarrollador muy hábil trabajando en la solución; él refactorizó y la unidad probó las partes más críticas de la aplicación, agregó comentarios donde hubo necesidad de comentarios y, lo más importante, escribió documentación detallada sobre la arquitectura general, las partes críticas y las trampas.
Ahora estás contratando a un desarrollador para mantener este código base. Durante una entrevista, ¿daría un código heredado (feo no probado) o el código que fue refactorizado por el desarrollador anterior?
¿Le darías la documentación? Para leer la documentación, el candidato deberá pasar al menos unas horas. Esto hace que sea imposible hacerlo durante una entrevista.
2. Leer un fragmento de código no es lo mismo que leer un código de un proyecto familiar
Recuerda, el trabajo es mantener un proyecto. Es difícil mantener una base de código grande los primeros días o semanas cuando no está familiarizado con el proyecto. Es mucho más fácil hacerlo después de unos meses cuando has escrito toda la documentación y tienes una vista clara de la base de código general.
Lo más importante que hay que evaluar es si la persona será eficiente en esos meses . No le importa si la persona no podrá entender nada durante los dos primeros días.
Al pedirle a una persona que lea un pequeño fragmento de código desde cero, no está probando cómo esta persona podría lidiar con un código familiar y documentado de miles de LOC .
3. Mantener el código fuente no es solo leerlo
Cuando mantienes un código base, lo estás modificando . Un desarrollador que solo lee el código no trae nada útil a su compañía.
Las habilidades útiles son la capacidad de código de refactorización , de agregar pruebas unitarias , de predecir el impacto de un cambio , etc. no pruebe esas habilidades pidiéndole a una persona que lea el código durante la entrevista.