¿Cómo verificar o evaluar las habilidades de depuración de una persona? [cerrado]


48

¿Qué tipo de habilidades determinan a una persona que es capaz de depurar código con facilidad? Hace algún tiempo, mi amigo realizó una entrevista con un programador relativamente bueno. El programador fue contratado. Podía escribir un buen código, entendía los marcos y los patrones de diseño. Lo que le faltaba era: habilidades de depuración. No podía depurar en absoluto y encontrar problemas con su código o el de otra persona fue un gran dolor para él.

Desde entonces, estamos pensando en cómo podemos evaluar o estimar las habilidades de depuración de una persona.

Entonces, la primera pregunta es: ¿qué habilidades determinan si una persona puede depurar efectivamente el software?

Y el segundo: ¿cómo evaluar esas habilidades durante la entrevista?


14
En realidad, me dieron un código para depurar, en una computadora, en una entrevista. Habían modificado el código fuente a tar o gzip o algo así, y querían ver cómo lo depuraría.
wkl

44
La única manera de estar seguro es dejar que él o ella lo haga "en vivo". Hágale saber de antemano cuál es su entorno de desarrollo y que habrá una simple prueba de codificación y depuración.

Ni siquiera tiene que estar en vivo, @ ThorbjørnRavnAndersen. Me entrevisté en un par de lugares que me entregaron una copia impresa de una función pequeña, junto con una especificación de lo que hace esa función, y luego me pidieron que "encontrara el error".
Quanticle

@quanticle Igual aquí, mi compañía realiza una prueba de programación de 5 preguntas (aproximadamente la mitad es depuración) antes de que lo consideren para una entrevista en persona. Aparentemente elimina a la mayoría de los candidatos ...
Izkata

Dale un rastro de pila para analizar :-)
JustMe

Respuestas:


24

Si lo primero que quiere hacer la persona es mirar el código y recorrerlo con un depurador, esa persona no es un gran solucionador de problemas.

Si todavía no tiene un plan de acción y se sumerge en el depurador a ciegas, básicamente es Huevo de Pascua. Esto es cierto para CUALQUIER tipo de solución de problemas.

En una situación de entrevista, una persona que pregunta cómo funciona el sistema y pregunta sobre el historial del sistema sería alguien que podría ser un buen solucionador de problemas. Una persona que piensa primero en el sistema y la mecánica en segundo lugar podría ser un buen solucionador de problemas.

Esto es cierto para cualquier sistema complejo.


1
+1 para una buena perspectiva sobre esto. Estoy de acuerdo, pero cuando piensan que la mecánica es la segunda, ahora saben cómo usar las herramientas. Al igual que en los automóviles, un ingeniero que no entiende o no puede usar herramientas mecánicas no es un ingeniero calificado en absoluto.
maple_shaft

16
Esta respuesta no deja espacio para la depuración instintiva. Alguien que ha trabajado con suficientes sistemas, tipos de código o idiomas, a menudo podrá "oler" su camino hacia lo que está pasando. A veces no es necesario conocer los entresijos del sistema para poder encontrar sus fallas.
Jordan

Primero, no existe la "depuración instintiva". Hay heurísticas (también conocidas como "pistas de pierna rota") que los expertos usarán. Tan seguro. Si hay heurísticas disponibles, los expertos las usarán de manera efectiva. Pero esas heurísticas pueden morder a estos expertos en el trasero. Lea sobre las toneladas de trabajo realizado en expertos en psicología cognitiva y verá. Por lo tanto, un buen experto puede tener buenas ideas sobre por dónde comenzar, pero nunca debe confiar por completo en esos sentimientos. Y deberían ser capaces de explicar, al menos en cierta medida, esos instintos.
ElGringoGrande

10
Tengo que estar en desacuerdo al 100% con tu blanco y negro si lo primero que comentan. Yo diría que si una persona piensa que activar el depurador no es una buena primera opción en algunos casos, entonces esa persona tampoco es un buen solucionador de problemas. Si el problema es que las comunicaciones se detuvieron, lo primero que haré es encender el depurador y descubrir qué procesos / hilos / tareas están bloqueados o dejan de funcionar. Otra razón para activar el depurador es intentar ver si el problema es repetible. Una vez que sepa cómo romper el sistema, encontrar la solución se vuelve mucho más fácil.
Dunk

55
@ElGringoGrande estaba sugiriendo lo contrario de eso, de lo que estoy leyendo. El punto es que las personas mejoran naturalmente la depuración a medida que adquieren más experiencia. Las herramientas o la metodología no son tan importantes como lo efectivas que son. Es por eso que tu respuesta es incompleta. Hay muchas formas válidas de depurar, incluyendo levantar una silla y revisar el código, hacer preguntas, etc. Efectivamente depuré grandes programas PHP con print. No me gusta hacerlo, pero realmente no se trata tanto de la herramienta como del conocimiento de cómo funcionan los sistemas en general.
Jordania

15

Yo diría que la mejor medida de un buen desarrollador de software en un lenguaje o marco particular es la capacidad de analizar críticamente problemas complejos y tener buenas habilidades de depuración en el lenguaje o marco. Deben ser capaces de demostrar la depuración de bajo nivel, así como la competencia en la depuración de alto nivel con herramientas de depuración comunes.

Esto significa crear un escenario para ellos que demuestre una alta aptitud de las herramientas de depuración en su IDE elegido. Debes buscar cosas como:

  • Ejecutar una aplicación o servidor de espacio aislado en modo de depuración o crear una aplicación con símbolos para la depuración

  • Poner a disposición y demostrar puertos de depuración remotos o depuración de aplicaciones sin espacio aislado que se construyeron con símbolos (si corresponde al idioma)

  • Uso estratégico de puntos de interrupción

  • Propiedades personalizadas de puntos de interrupción, expresiones condicionales en puntos de interrupción (si corresponde al idioma)

  • Uso de expresiones o relojes variables para monitorear valores variables o referencias

  • Uso de valor variable ad-hoc o referencia o manipulación del puntero en tiempo real

  • Demostrar capacidad para entrar, salir y salir del flujo de la aplicación.

  • Evaluación crítica de la pila de llamadas

  • Depuración de aplicaciones multiproceso y comprensión de esto.

También se deben demostrar otras estrategias de depuración sin herramientas, como analizar registros y código fuente, así como la capacidad de realizar algunas depuraciones de bajo nivel sin el uso de un IDE también.


+1 lista bastante útil. Y más aplicado uno.
Dipan Mehta

8
Soy de la opinión de que la depuración de aplicaciones de subprocesos múltiples es una realidad completamente diferente a la depuración de aplicaciones de subprocesos únicos. Diferente, y mucho, mucho más difícil.
Bruce Ediger

20
@JarrodRoberson Brian Kernighan y Rob Pike escribieron en The Practice of Programming que todavía prefieren las declaraciones impresas a los depuradores porque es menos transitorio. Muchas personas prefieren un buen sistema de registro que les brinde una vista detallada de la ruta del código sin detener el programa a mitad de ejecución. También es más fácil leer un archivo de registro y luego depurar un volcado de memoria. Por lo tanto, su prueba de fuego podría rechazar a algunos buenos programadores porque no todos están de acuerdo en que los depuradores son tan útiles como los enfoques de depuración alternativos (registros, pruebas unitarias, afirmaciones)
MetricSystem

12
Las declaraciones de impresión de depuración están bien y pueden ser preferibles a un depurador, especialmente cuando hay concurrencia. Su problema con ellos podría ser realmente con un compilador lento.
Ricky Clarkson

8

Yo diría que elimine un error que tenía en su sistema en algo que pueda discutirse en el contexto de una entrevista. Encienda el depurador y déjelo.


7

Hágale preguntas como esta:

  1. ¿Cómo abordas un problema?

  2. ¿Cuál es uno de los proyectos complejos que hizo y cómo lo logró?

  3. ¿Qué herramientas de depuración usaste?

  4. ¿Tienes alguna preferencia por ciertas herramientas?

  5. Dé un ejemplo de su propio escenario y pregúntele cómo lo abordará.

  6. ¿Cómo calificaría su capacidad para ingresar al código de otra persona?

Puede abordar sus inquietudes haciendo preguntas. Siempre existe el riesgo de que pueda o no ser bueno en ciertas habilidades. Pero si él es un buen alumno, eso ayudará mucho.


6

Si quieres ver si un programador puede depurar, dale el código para que lo arreglen. Es el mismo enfoque si quieres ver si pueden escribir código. Déles un problema y pídales que escriban el código.

Ahora, estoy confundido acerca de este programador que no tiene problemas para escribir código pero falla de manera errónea cuando se le pide que depure. ¿Esta persona regurgita ejemplos de código o simplemente se adhiere a áreas que tiene experiencia como leer y escribir en una base de datos? A menos que obtengan el código correcto la primera vez, ¿no pueden arreglarlo?

¿Quizás a la persona simplemente no le gusta la depuración y no hace ningún esfuerzo? No soy bueno en esto, así que deja de pedirme que lo haga, aprendí la impotencia.

Trabajar en una base de código existente requiere revisar el código, la documentación y posiblemente hacer algunas notas y diseños propios.

Sé que pensamos en la depuración como arreglar el código de producción que ha fallado, pero necesito depurar el código mientras lo estoy escribiendo. O esta persona no es un muy buen programador o simplemente prefieren escribir código nuevo. No todos.


2
Todos depuramos nuestros programas. Al principio es fácil porque el programa es pequeño y es fácil tenerlo todo en la cabeza. Pero a medida que crece y se vuelve más compleja, la depuración se vuelve más difícil. Y ahora, algunas personas aún pueden manejar eso y encontrar un error en un tiempo razonable y algunas personas simplemente se pierden. No saben dónde concentrarse y cómo reducir su alcance para encontrarlo ...
Michal B.

1
@MichalB .: Todos depuramos nuestros programas, pero algunas personas exhibirán un enfoque basado en principios, mientras que otras simplemente modificarán las cosas al azar y verán qué sucede .
Matthieu M.

No entiendo por qué estarías confundido. Ser un buen desarrollador y un buen mantenedor son conjuntos de habilidades muy diferentes. En el mejor de los casos, la mayoría de las personas solo tienen habilidades en uno u otro, si es que tienen habilidades (lo que desafortunadamente cubre a la mayoría de los desarrolladores).
Dunk

3

De la misma manera que determinaría la capacidad de codificación de alguien, hágales preguntas sobre la depuración.

Pregúnteles "cómo" localizarían un error en una situación dada.

Dé un paso más allá y siéntelos frente a una computadora y vea cómo depuran un problema.


3

A menudo les he dado situaciones hipotéticas a los candidatos ... por ejemplo, un sistema de producción ha dejado de responder. ¿Qué haces? Pueden responder "verificar los registros" y yo digo "los registros no muestran nada anormal, excepto que no hay nada escrito en ellos desde que el problema comenzó a suceder". Y así continúa, hasta que esté satisfecho de haber evaluado la capacidad de los candidatos para resolver problemas.


2

Por lo general, las personas con buena aptitud también son las que tienen buenas habilidades de depuración.

Durante la entrevista, (dependiendo de su antigüedad) puede asignarles una tarea similar a un rompecabezas, como un algoritmo más o menos. Esa es la manera simple.

Si puede, puede imprimir un código de algún trabajo y preguntarle a la persona si algo está mal aquí y, de ser así, cómo solucionarlo.

No prefiero hacer preguntas de entrevista ofuscadas que tienden a centrarse en la capacidad de las personas para leer y corregir la sintaxis.


+1 ¡Gran respuesta! Estoy de acuerdo en que los mejores desarrolladores de software tienen buenas habilidades de depuración y también siento que detectar errores de sintaxis no demuestra mucho. La mayoría de los IDE e incluso algunos buenos editores de texto (Notepad ++) identificarán errores de sintaxis en idiomas comunes. Sin embargo, no estoy de acuerdo con que un rompecabezas demuestre habilidades de depuración. Rompecabezas demuestra el pensamiento crítico, que es una habilidad diferente pero relacionada.
maple_shaft

@maple_shaft gracias por (otro +1). Es cierto que los rompecabezas no están directamente vinculados a la depuración . Pero es bueno para juzgar cómo las personas se acercan a los problemas, algo realmente indirecto.
Dipan Mehta

2
Miro el rompecabezas y soy como ewwwwwwww. ¿Realmente no tienes nada mejor que cosas de "gotcha"? ¿Y cómo entra en escena la "antigüedad"? ¿Se supone que las personas mayores resuelven acertijos más difíciles? ¿Todos los buenos programadores (o depuradores) son fanáticos del sudoku? podrías terminar molestando a algunos programadores realmente buenos y hablando mal por toda la ciudad. las preguntas gotcha son un insulto <period>, por favor, inventa algo mejor, hombres
Chani

@Scrooge Solo lo dije como rompecabezas de programación : nunca jugué sudoku con cientos de entrevistas que tomé.
Dipan Mehta

2

Durante una entrevista, pídales que le cuenten sobre un error que solucionaron en el pasado y los pasos que usaron para depurarlo.

Haga que le cuenten sobre lo que hicieron en su último trabajo, tarea, etc. y sobre lo que hicieron para encontrar el problema.


2

Compartiré una experiencia junto con una perspectiva de reclutas sobre la evaluación de las habilidades de un candidato para la depuración. Seguí una entrevista que tenía tres etapas. La segunda etapa fue un "caso práctico". No sabía más en ese momento. Mientras estaba allí, me informaron que hay un sistema que dejó de funcionar y no lo saben. Algunos errores yacen detrás.

Se organizó como un escritorio remoto en un antiguo entorno de prueba. Probablemente a un entorno desconectado o aislado. El proyecto consistía en algunos formularios web con algunos controles ASP.NET y código de archivo de código relacionado. El archivo de código se refería a un tipo de capa empresarial para la que solo tengo un dll, sin código fuente y descripciones de métodos. Webforms realizó las funciones CRUD que puede esperar. También una pequeña función de búsqueda. La capa empresarial, a su vez, habló con Views y SP en un servidor sql.

Intercambiaron algunas partes a diferentes niveles. Me dieron un papel con síntomas. "No se puede buscar" "El campo 'región' desapareció después de la última actualización" y demás. Tal como puede recibir de sus usuarios.

No recuerdo todos los detalles, pero al menos se cambió el nombre de un campo de tabla, lo que condujo a un SP roto, que fue utilizado por la función de búsqueda. Eso significa que no hay error en VS y no hay código fuente BL para rastrear nombres de campo. Un parámetro SELECT contra Sqlcommand fue mal escrito y provocó un mal funcionamiento de un formulario web. También se omitió un campo que era el campo faltante en GridView (Autogeneratecolumns). Se hizo referencia a un botón ASP.NET a algo que debía ser un método duplicado y mejorado y se "olvidó" de apuntar el botón al nuevo método.

También algo tan pequeño usando el título en una etiqueta html que no lo permite. También se omitió la etiqueta ALT opuesta en un control que lo requería. También hubo algunos errores con las etiquetas html cerradas incorrectas, pero que no funcionaron mal. No estoy seguro de si todo eso fue un puro error de proyecto playhouse o tal vez el mismo proyecto para diferentes reclutamientos. Nunca pregunté El nivel de dificultad, por supuesto, debe coincidir con la necesidad del recluta.

Tal prueba probablemente debería examinarse (no seguirse) para ver, después de la entrevista, cómo se realizó la depuración. Para mí en esa etapa, la prueba me pareció un poco ridícula, pero ese también sería el gran punto. Si fue o no, debería valer mucho tener al candidato en el lugar correcto.

* Creo que esa prueba demostró que los candidatos / mis habilidades *
* Analizar un sistema extraño
* Usar un mínimo de información para encontrar errores y errores
* Bajo el estrés del tiempo y sin que alguien lo ayude, codifique las correcciones asumidas
* Diferentes niveles de conocimiento;
** sql db y procedimientos almacenados,
** uso de dll en el proyecto,
** técnica asp.net,
** arquitectura en capas
** aspecto orientado a problemas

Pero también las cosas más obvias como manejar el entorno del desarrollador, encontrar y comprender la herramienta Db Server Management. Seguramente hay candidatos que se ven muy bien en el papel pero, en la práctica, podrían atascarse en tales tareas.


2

Elijo un problema real que encontré que es relevante para el puesto y se lo presento al candidato tal como me lo presentaron. Por supuesto, les ofrezco algunos antecedentes generales y una pequeña cantidad de documentación relevante, como un fragmento de código o un diagrama esquemático.

Les digo que su trabajo es resolver el problema y les ofrezco responder cualquier pregunta técnica que tengan y decirles el resultado de cualquier experimento que quieran realizar. Si dicen: "Pondría una sonda de alcance aquí", les daré un rastro de lo que podrían encontrar. Si quieren insertar un printfen un bucle, les diré que nunca sale (!) O imprime primero "7" y luego repetidamente "5". Si se alejan tanto de la maleza que no puedo dar respuestas significativas, admitiré que estamos en el camino equivocado y volveré a otro lado. Si se atascan, haré preguntas importantes o daré pistas hasta que podamos seguir adelante.

Lo que quiero ver son procesos de pensamiento ordenados, determinación para llegar a la solución, preguntas y experimentos bien considerados, e idealmente una identificación exitosa del problema. A veces elijo problemas que son demasiado complejos para que alguien pueda depurarlos completamente en una entrevista de una hora y al final les doy la respuesta real. En ese momento, estoy buscando una reacción que demuestre que estaban comprometidos con el problema y experimentan ese momento "aha" y gratificación al llegar a la causa. Los mejores candidatos espontáneamente harán preguntas de seguimiento en ese momento, tratando de vincular su mapa mental del problema con lo que realmente estaba sucediendo.


1

Siéntelos en una computadora con algunos símbolos binarios simples (con depuración) que aparecen por defecto con referencia de puntero nulo o tal + código fuente + gdb y vea si pueden encontrar la causa del bloqueo.


2
Todo lo que le dice es que la persona puede analizar código y binarios para encontrar una referencia de puntero nulo potencial. En realidad, no demuestra el uso experto de herramientas comunes de depuración.
maple_shaft

1

Si hace que sus candidatos realicen pruebas de código preliminares, pídales que modifiquen el código durante la entrevista para resolver un error o agregar una nueva función o, mejor aún, ambas. Si hace que las especificaciones de prueba del código sean bastante vagas, eso facilitaría la creación de casos de prueba con "errores" en ese momento.


1

Encontrar "el error" en un pequeño fragmento de código es una situación muy artificial. Supongo que podría ser útil de la misma manera que los acertijos y los acertijos.

Un enfoque más completo haría preguntas de comportamiento sobre cómo el candidato ha realizado la depuración en el pasado citando incidentes específicos y luego haciendo un seguimiento de las preguntas.

Alguien que sea bueno en la resolución de problemas podrá hablar sobre algo más que las facilidades de depuración en el IDE. ¿Qué pasa con ... las herramientas de informe de errores, la interacción del usuario final, la reproducción del error, el análisis del archivo de registro, la verificación?

La depuración tiene MUCHO MÁS que rastrear a través de un bloque de código y cualquier evaluación de la habilidad de alguien en la depuración debería reflejar eso.


Me gusta asumir que hay errores en el software que aún no hemos descubierto. Es como buscar fallas sísmicas. La pregunta es cómo se buscan señales reveladoras.
Christopher Mahan

1

Dele a alguien un código increíble que su empresa ejecuta en producción. Pídales que presenten un error sutil. Pregúnteles por qué eligieron ese. Pregúnteles cómo harían para encontrarlo y arreglarlo.

Punto de bonificación si encuentran un error en el código original.

Doble punto de bonificación si pueden corregir el error en el código original.


1

Tiendo a pedirle a la gente que me describa el error más difícil que alguna vez tuvieron que rastrear y corregir y lo que hicieron para encontrarlo y solucionarlo. También sé que si el error más difícil era algo que esperarías que solo un principiante encuentre difícil, entonces es probable que no sean buenos solucionadores de problemas (a menos que sea una entrevista para el nivel de entrada). Si es algo realmente difícil y describen su proceso de pensamiento mientras intentaban rastrearlo, entonces puedo tener una idea de cuál es su nivel de habilidad. Lo que siempre me ha sorprendido es la gran cantidad de personas que tienen un aspecto de "ciervo en los faros" y no pueden pensar en un solo ejemplo de algo que hicieron que fuera complicado. Bueno, lo siento, alguien que deja los problemas difíciles para que alguien más los arregle, no es alguien que me interese por otra cosa que no sea la escuela,


1

Le haría un par de preguntas agnósticas tecnológicas como las siguientes:

  • Llévame a través de todos los pasos que sigues para identificar la causa raíz y corregir un error (defecto)
  • ¿Cómo usarías la Pila de llamadas mientras depuras una aplicación de subprocesos múltiples?

Esto funciona muy bien especialmente en entrevistas telefónicas, ya que solo necesita que la persona le dé una respuesta convincente que muestre cómo él realmente hace las cosas mientras resuelve un problema.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.