¿Cómo manejar una entrevista de 'código incorrecto'? [cerrado]

Una entrevista de "código incorrecto" es aquella en la que se muestra al entrevistado un fragmento de "código incorrecto" y se le pide que lo corrija o señale las cosas que están mal con él. Tengo problemas con estas entrevistas porque me lleva un tiempo leer el código, descubrir qué está haciendo y señalar los defectos. En una situación donde hay presión de tiempo, tiendo a congelarme y veo que el código 'debería' funcionar, incluso cuando no funciona.

¿Cuál es una buena manera de manejar este tipo de entrevista y, en general, cuáles son algunas buenas técnicas para leer y comprender el código rápidamente ?

Las entrevistas de código incorrecto (si se realizan correctamente) deberían mostrarle el código con lo siguiente:

• Una mala técnica del lenguaje (no usar la usingdeclaración en C # cuando sea necesario, o usar un en ArrayListlugar de un List<T>)
• Una mala decisión de diseño (¿por qué diablos estamos pasando cadenas por todas partes, o usando tanto parámetros refy out?)
• Errores de sintaxis (¡esto ni siquiera debería compilarse!)
• Errores en tiempo de ejecución (como un desbordamiento de pila causado por una propiedad que se refiere a sí misma en C #)

Hay una lista de verificación mental por la que debes pasar, llegando a cada uno de los puntos anteriores. Si no puede mirar el código y hacer eso, eso es un punto de mejora. Independientemente del idioma en el que afirme ser "competente", debería poder mirar un bloque de código y señalar esos cuatro tipos de errores.

Recientemente escribí en un blog sobre un código que exhibía todos estos problemas , debería ayudarte a pasar por el mismo proceso mental.

Ayende lo lleva más profundo con su serie Wages of Sin .

No trates de entenderlo rápidamente. El objetivo aquí no es ver si puedes entender el código como un gurú, sino ver cómo piensas.

La clave de la OMI es simplemente pensar en voz alta. Entonces, incluso si te congelas, entonces solo di: "Estoy estresado aquí, pero déjame pasar por esto lentamente en voz alta".

Asumir que tiene la habilidad de pensar en voz alta lo retrasará lo suficiente como para tener la mente correcta. Si las entrevistas son lo suficientemente inteligentes, verán tu situación y te ayudarán hasta que pienses con claridad. No están tratando de engañarte para que te veas estúpido, solo una técnica poderosa para ver cómo piensas.

Lo más probable es que la 'presión de tiempo' que sientes es completamente autoimpuesta. Tiene más que ver con sus propios sentimientos de inseguridad y preocupación sobre qué tan bien se mide.

El mejor consejo que cualquiera puede dar es: Relájese. Tómese su tiempo, mire el código y simplemente hable sobre lo que ve tal como lo ve. Siéntase libre de hablar tanto de las partes buenas como de las malas; ayudará a reducir su nerviosismo y las preocupaciones internas de que pase demasiado tiempo.

Además, pasar por diferentes 'pases' podría hacer que sea un poco más fácil detectar detalles específicos. Tome un pase en busca de llaves o errores tipográficos no coincidentes. Tome otro pase buscando líneas ofuscadas. Tome otro buscando pretzels semánticos. Centrarse en un tipo de "cosa incorrecta" podría hacer que sea más fácil detectar esos detalles y (nuevamente) reducir su voz interior cuestionando si lo está haciendo lo suficientemente rápido / bien.

Sobre todo, hable a través de lo que está haciendo y pensando: lo ayudará tanto a usted como al entrevistador.

Nunca he estado en este tipo de entrevista, pero cuando intento trabajar en un código complicado que sospecho que es malo, a veces hablo en voz baja conmigo mismo. Creo que vocalizar a veces ayuda a resolver problemas. También en una entrevista, podría intentar rastrear los pasos de ejecución como un diagrama o algo con un lápiz y papel. Esto solía funcionar para mí en la escuela, todavía lo hago a veces en el trabajo. YMMV, por supuesto ...

Creo que un buen lugar para comenzar (si no ve nada obvio) sería "depurarlo". A menos que vea posibles problemas de inmediato, un buen lugar para comenzar es hacer una pequeña lista de valores de prueba. Los buenos valores son un valor de 'ruta feliz' (normal), un valor 'cero' o 'vacío', nulos, un valor muy pequeño (una cadena de 1 carácter, el int 1, etc.), un valor muy grande o muy largo valor y valores "extraños" específicos del tipo (por ejemplo, caracteres Unicode para cadenas, números negativos para ints, etc.). No estaría de más mencionar aquí que normalmente escribiría pruebas unitarias utilizando estos valores para probar el código, y simplemente los ejecutaría para verificar la función.

Comience caminando con sus valores de camino feliz. Para una función de suma, puede comenzar con 3 o 4. Examine cada línea en busca de errores tipográficos y lógicos, siguiendo los valores de las variables locales a medida que avanza. Con suerte, encontrarás algunos errores. Cuando termine con el camino feliz, tendrá una mejor idea del código y, con suerte, se sentirá un poco menos abrumado, así que diga algo como: "Ahora que tengo una mejor idea de lo que está haciendo este código, estoy va a dar un paso atrás y echarle un vistazo ", luego haga exactamente eso: busque cosas que se destaquen como cosas que hubiera hecho de manera diferente (malas decisiones de diseño, variables mal nombradas, investigar posibles errores, etc.).

Si eso no lo lleva a ninguna parte, o si siente que se le acabaron las cosas que decir, regrese a su lista de valores de prueba y vuelva a revisarla con una nueva que cree que puede causar problemas.

Esto al menos te pondrá en marcha.

Como dijo Stephen Bailey, pensar en voz alta es una técnica excelente en esta situación, ya que permite a los entrevistadores ver su proceso de pensamiento. Más o menos explica lo que estás tratando de resolver. La otra cosa que podría hacer es informar a los entrevistadores que va a leer el código correctamente antes de proporcionar un diagnóstico sobre la maldad del código. He estado en ambos lados de la mesa y sé que puede ser frustrante para ambos lados en estas situaciones.

Si siente menos presión al hacerlo como prueba escrita, saque su cuaderno y comience a tomar notas. Saqué un cuaderno y comencé a dibujar notas como parte de mi proceso de pensamiento en una entrevista. Tener un cuaderno y un bolígrafo te hace ver organizado incluso. Puede escribir algunos puntos de las cosas que debe buscar, sintaxis, errores lógicos, desajustes de tipo de datos, valores de variables locales (la lista puede variar según el tipo de código que obtuvo, mi lista para una pieza compleja de SQL sería ser diferente de alguien que obtuvo un código que no estaba centrado en los datos) a medida que avanza el proceso, etc. Una vez que haya escrito algunos de estos, comience a buscarlos. De esa manera, incluso si no encuentra todos los problemas antes de que el entrevistador quiera seguir adelante, él / ella podrá ver una lista de las cosas que iba a verificar. Si crea una lista de verificación de antemano de las cosas que desea buscar, entonces se sentirá más seguro al comenzar el proceso sabiendo qué cosas ha planeado mirar. Por lo general, estas preguntas son más acerca de cómo encontraría los errores que realmente encontrarlos todos.

Llego un poco tarde a esta fiesta, pero una técnica que podría usar sería escribir pruebas unitarias para el código en cuestión. Entonces puede concentrarse menos en lo que está sutilmente mal con el código y más en los resultados esperados que está buscando. Prefiero contratar a alguien que pueda escribir buenas pruebas que alguien que pueda detectar inmediatamente lo que está mal con un código.

Puede haber dos problemas:

Puede ser una "entrevista de estrés" http://en.wikipedia.org/wiki/Job_interview#Stress . El entrevistador está tratando de ver cómo lidias con el estrés, ya que su entorno de trabajo es tal.

O

Tal vez te estés estresando. En ese caso, tendrá que manejar este estrés, por ejemplo, introspección y ver cómo puede mantener la calma.