Tuve una docena de entrevistas en mi vida (estoy a punto de graduarme) y me pregunto por qué solo una vez me pidieron que leyera y explicara algunos códigos. Aproximadamente, el 90% de los empleos son principalmente para mantener los sistemas existentes. La capacidad de la OMI para leer el código de otra persona es una habilidad importante.
¿Por qué los entrevistadores no lo revisan? *
* Entre mis amigos, soy el único a quien se le pidió revisar un código.
Cuando estaba haciendo las preguntas de la entrevista, lo hice al principio, pero lentamente lo eliminé. Los solicitantes que podrían escribir el código bien en la entrevista todos podrían leer el código bien en la entrevista. Los solicitantes que no podían leer el código tampoco podían escribirlo. Las preguntas involucradas en la lectura del código no diferenciaron realmente a ningún solicitante.
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.
¿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.
La lectura es una suposición basada en el hecho de que la capacidad está presente para la escritura. Considere el concepto en cualquier idioma. La programación es solo un lenguaje para comunicarse entre humanos y máquinas. Considere una comunicación de humano a humano. Si estuviera contratando a alguien para que fuera intérprete de japonés, ¿no sería razonable que si pudieran escribir un ensayo de 1.000 palabras sobre un tema en particular, pudieran leerlo?
Como programadores, nuestra actividad principal es la creación de código y la traducción de ideas abstractas en implementaciones concretas. Esto generalmente significa escribir. Estoy de acuerdo en que la lectura es igual de crítica, pero en una gran mayoría de los casos, donde la capacidad de escritura está presente, la capacidad de lectura también está presente. El único caso real en el que podría ver una diferencia distinguible sería en un entorno donde hay muchos casos altamente complejos que han evolucionado con el tiempo. Sin embargo, incluso con estos, no esperaría que alguien pudiera leerlos y comprenderlos sin al menos un poco de estudio.
Además, leer el código y explicar lo que crees que hace realmente no expresa al entrevistador cómo utilizas tus habilidades de pensamiento crítico. Muestra un poco de análisis, pero la mayoría de los empleadores quieren ver si puede pensar sin ser colocado en una caja. Quieren saber si puede comprender los conceptos sin el beneficio (o incluso la muleta) del código existente para decirle qué o cómo hacer algo.
En el pasado solía pensar que la lectura del código debería ser algo demostrado en las entrevistas, pero con el tiempo me he dado cuenta de que esto es una pérdida de tiempo tanto para el entrevistador como para el entrevistado. ¿Por qué? Porque incluso los codificadores malos pueden leer un fragmento de código.
Ser capaz de juzgar la capacidad de alguien para leer el código solo se vuelve relevante cuando se observa algo complejo o código que abarca muchas clases y archivos. Ser capaz de rastrear el código para descubrir qué está haciendo es un rasgo deseable, pero simplemente no hay tiempo suficiente para que alguien dé un buen ejemplo (no es un código de producción) ni hay tiempo en una entrevista para hacer esa pregunta .
Por lo tanto, los codificadores incorrectos pueden leer el código, pero no pueden escribirlo bien. Pedir ejemplos de trabajo de un candidato o pedirle a un candidato que escriba un código en la entrevista son mejores indicadores de su habilidad. Si pueden escribir código limpio y conciso, es probable que puedan leer el código que estaba bien.
Le pregunto a cada candidato que estoy entrevistando a una variación del FizzBuzz problema Es rápido, simple y normalmente puede detectar a los codificadores maliciosos mucho más rápido que cualquier otra cosa que haya encontrado. Un buen programador lo obtendrá de forma rápida y sencilla y le dará una mirada rápida a su estilo de codificación y proceso de pensamiento.
Lea otras preguntas en las etiquetas code-reviews interview