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

12

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. Tengo problemas con estas entrevistas porque me lleva algo de tiempo leer el código, descubrir qué está haciendo y señalar las fallas. En una situación en la que hay presión de tiempo, tiendo a congelarse y veo que el código 'debería' funcionar, incluso cuando no lo hace.

¿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 entender el código rápidamente ?

    
pregunta quanticle 29.03.2011 - 21:01

9 respuestas

18

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

  • Una técnica de lenguaje inadecuado (no usar la declaración using en C # cuando sea necesario, o usar un ArrayList en lugar de un List<T> )
  • Una mala decisión de diseño (¿por qué diablos estamos pasando cadenas en todas partes, o usando los parámetros ref y out tanto?)
  • Errores de sintaxis (¡Esto ni siquiera debería compilar!)
  • 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 control mental por la que deberías pasar, golpeando cada uno de los puntos anteriores. Si no puedes ver el código y hacer eso, eso es un punto de mejora. Sea cual sea el idioma en el que digas ser "competente", deberías poder mirar un bloque de código y señalar esos cuatro tipos de errores.

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

Ayende lo profundiza con su serie Wages of Sin .

    
respondido por el George Stocker 29.03.2011 - 21:11
9

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. Así que incluso si te congelas, solo di "estoy haciendo hincapié aquí, pero déjame ir a través de esto lentamente en voz alta".

Suponiendo que tienes la habilidad de pensar en voz alta, te ralentizarás lo suficiente como para hacer que tu mente funcione correctamente. Si las entrevistas son lo suficientemente inteligentes, verán su situación y lo ayudarán hasta que esté pensando con claridad. No están tratando de engañarte para que te veas estúpido, solo una poderosa técnica para ver cómo piensas.

    
respondido por el Stephen Bailey 29.03.2011 - 21:11
2

Las probabilidades son, la 'presión del tiempo' que sientes es totalmente autoimpuesta. Tiene más que ver con tus propios sentimientos de inseguridad y preocupación por lo bien que estás a la altura.

El mejor consejo que alguien puede dar es: Relájate. Tómese su tiempo, mire el código y solo hable sobre lo que ve como lo ve. Siéntase libre de hablar sobre las partes buenas y las malas; ayudará a reducir su nerviosismo y le preocupa que pase demasiado tiempo.

Además, pasar por diferentes 'pases' puede hacer que sea un poco más fácil detectar detalles específicos. Tome un pase buscando llaves o errores tipográficos. Toma otro pase buscando líneas ofuscadas. Toma otro buscando pretzels semánticos. Enfocarse en un tipo de "cosa incorrecta" podría facilitar la detección de esos detalles y (nuevamente) reducir su voz interna, cuestionando si lo está haciendo con la suficiente rapidez.

Por encima de todo, habla sobre lo que estás haciendo y sobre lo que estás pensando: te ayudará a ti y al entrevistador.

    
respondido por el Tim O'Neil 29.03.2011 - 23:40
1

Nunca he estado en este tipo de entrevista, pero cuando trato de trabajar en un código complicado que podría sospechar de ser malo, a veces me hablo en voz baja. Encuentro que vocalizar a veces ayuda a resolver problemas. También en una entrevista, podría intentar trazar los pasos de la 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 ...

    
respondido por el FrustratedWithFormsDesigner 29.03.2011 - 21:05
1

Pensaría que un buen lugar para comenzar (si no ve nada obvio) sería "depurándolo". A menos que vea posibles problemas de inmediato, un buen lugar para comenzar es hacer una pequeña lista de valores de prueba. Los valores buenos son un valor 'ruta feliz' (normal), un valor 'cero' o 'vacío', nulos, un valor muy pequeño (una cadena de 1 carácter, 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 caracteres, etc.). No estaría de más mencionar que normalmente escribiría pruebas unitarias utilizando estos valores para probar el código, y solo ejecutaría esas para verificar la función.

Comience caminando con sus valores de ruta feliz. Para una función adicional, puede comenzar con 3 o 4. Examine cada línea para detectar errores tipográficos y lógicos, y rastree los valores de las variables locales a medida que avanza. Esperemos que encuentres algunos bichos. Cuando termines con el camino feliz, sentirás mejor el código y, con suerte, te sentirás un poco menos abrumado, así que di algo como: "Ahora que tengo una mejor idea de lo que está haciendo este código, vaya a dar un paso atrás y eche un vistazo ", luego haga eso: busque cosas que le llamen la atención como cosas que habría hecho de manera diferente (malas decisiones de diseño, variables con nombres incorrectos, investigar posibles errores, etc.).

Si eso no lo lleva a ninguna parte, o si cree que se le han acabado las cosas por decir, vuelva a su lista de valores de prueba y vuelva a revisarla con una nueva que crea que es probable causar problemas.

Al menos, esto te pondrá en marcha.

    
respondido por el Ethel Evans 29.03.2011 - 21:37
0

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

    
respondido por el tehnyit 29.03.2011 - 21:28
0

Si siente menos presión al hacerlo como una prueba escrita, luego saque su cuaderno y comience a tomar notas. Saqué un cuaderno y comencé a esbozar notas como parte de mi proceso de pensamiento en una entrevista. Tener un cuaderno y un bolígrafo te hace lucir organizado incluso. Puede anotar algunos puntos con viñetas para 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 parte compleja de SQL sea diferente a alguien que obtuvo un código que no estaba centrado en los datos) a medida que avanza en 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 podría querer buscar, entonces se sentirá más seguro al comenzar el proceso sabiendo qué cosas ha planeado analizar. Por lo general, estas preguntas son más acerca de cómo encontraría los errores que encontrarlos a todos.

    
respondido por el HLGEM 29.03.2011 - 22:51
0

Llego un poco tarde a esta fiesta, pero una técnica que podrías 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 en lugar de alguien que pueda detectar inmediatamente lo que está mal con una pieza de código.

    
respondido por el Chris Knight 29.03.2011 - 23:09
0

Puede haber dos problemas:

Puede ser una "entrevista de estrés" enlace . El entrevistador está tratando de ver cómo lidiar con el estrés ya que su entorno de trabajo es tal.

O

Puede que te estreses. En ese caso, tendrá que manejar este estrés, por ejemplo, inspecciona y observa cómo puedes mantener la calma.

    
respondido por el Shamit Verma 30.03.2011 - 08:06

Lea otras preguntas en las etiquetas