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

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 aún no tiene un plan de acción y se sumerge en la persiana del depurador, básicamente se trata de la 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 piense primero en el sistema y luego en la mecánica podría ser un buen solucionador de problemas.

Esto es cierto para cualquier sistema complejo.

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 idioma o marco. Deben ser capaces de demostrar la depuración de bajo nivel, así como el dominio de la depuración de alto nivel con herramientas comunes de depuración.

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

• Ejecutando una aplicación o un servidor de espacio aislado en modo de depuración o creando una aplicación con símbolos para depurar

• Poner a disposición y demostrar los puertos de depuración remotos o la depuración de aplicaciones que no están en un espacio aislado que se construyó con símbolos (si corresponde al idioma)

• Uso estratégico de los 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 vigilaciones de variables para monitorear valores de variables o referencias

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

• Demuestre la capacidad de entrar, salir y salir del flujo de aplicación

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

• Depurando aplicaciones de múltiples hilos y comprendiendo esto.

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

Diría que destile un error que tuvo en su sistema a algo que se puede discutir en el contexto de una entrevista. Enciende el depurador y déjalo en él.

Hazle preguntas como esta:

1. ¿Cómo abordas un problema?

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

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

4. ¿Tiene 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 el 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 aprendiz, eso ayudará mucho.

Si desea ver si un programador puede realizar una depuración, deles un código para corregirlo. Es el mismo enfoque si desea ver si pueden escribir código. Dales un problema y haz que escriban un código.

Ahora, estoy confundido acerca de este programador que no tiene problemas para escribir código pero falla de manera lamentable cuando se le pide que depure. ¿Regurgita esta persona los ejemplos de código o simplemente se adhiere a las á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?

¿Tal vez 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í impotencia.

Trabajar en una base de código existente requiere mirar a través del código, la documentación y posiblemente hacer algunas notas y diseños propios.

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

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

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

Vaya un paso más allá y siéntelos frente a una computadora y véalos cómo solucionan un problema.

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

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

Durante la entrevista, (dependiendo de su antigüedad) puede asignarles un rompecabezas similar, como un algoritmo o algo así. Esa es la manera simple.

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

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

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

Haz que te cuenten lo que han hecho en su último trabajo, la tarea, etc. Y lo que han pasado para encontrar el problema.

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

Se organizó como un escritorio remoto para un entorno de prueba antiguo. Probablemente a un entorno desenchufado o aislado. El proyecto consistió en algunos formularios web con algunos controles ASP.NET y código de archivo de código relacionado. El archivo de código se refirió a un tipo de capa empresarial para la cual solo tengo un dll, sin código fuente y descripciones de métodos. Los formularios web hicieron las funciones de CRUD que usted puede esperar. También una pequeña función de búsqueda. La capa empresarial, a su vez, hablaba con Vistas y SP en un servidor de SQL.

Repartieron algunas partes en 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 tal. Como puedes recibir de tus usuarios.

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

También una cosa tan pequeña que usa 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 error puro en el proyecto de la casa de juegos o quizás el mismo proyecto para diferentes reclutamientos. Nunca pregunté. El nivel de dificultad, por supuesto, debe coincidir con la necesidad del recluta.

Dicha 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, encontré la prueba un poco ridícula, pero ese también sería el gran punto. Si lo fue o no, debería valer mucho tener al candidato en el lugar correcto.

* Creo que se probaron las pruebas y mis habilidades para *
* Analizar un sistema extranjero
* Usa un mínimo de información para encontrar errores y errores. * Bajo estrés de tiempo y sin que alguien te ayude, codifica correcciones | * Diferentes niveles de conocimiento;
** db sql y procedimientos almacenados,
** uso de dll en proyecto,
** técnica asp.net,
** arquitectura en capas
** Aspecto orientado a problemas

Pero también las cosas más obvias como manejar el entorno de desarrollador, encontrar y entender la herramienta de gestión de servidores Db. Seguramente hay candidatos que se ven muy bien en el papel pero, en la práctica, podrían quedarse en esas tareas.

Escogí un problema real que encontré que es relevante para la posición y 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 me ofrezco responder cualquier pregunta técnica que tengan y decirles el resultado de cualquier experimento que quieran realizar. Si dicen "yo pondría una sonda de alcance aquí", les dibujaré un rastro de lo que podrían encontrar. Si desean insertar un printf en un bucle, les diré que nunca sale (!) O primero imprime "7" y luego repetidamente "5". Si están tan lejos de la maleza que no puedo dar respuestas significativas, admitiré que estamos en el camino equivocado y regresaremos a otro lugar. Si se atascan, haré preguntas importantes o daré sugerencias hasta que podamos continuar.

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

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

Si tiene a sus candidatos haciendo 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, sería más fácil crear casos de prueba con "errores" en ese momento.

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 lo son los rompecabezas y los enigmas.

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

Alguien que sea bueno en la resolución de problemas podrá hablar de 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?

Hay mucho MUCHO más para depurar 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 corresponder a eso.

Déle a alguien un código impresionante que su compañía ejecute en producción. Pídales que introduzcan un error sutil. Pregúntales por qué eligieron esa. Pregúntales cómo lo 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.

Tiendo a pedir a las personas que me describan el error más difícil que han tenido que rastrear y solucionar, y qué hicieron para encontrarlo y solucionarlo. También sé que si el error más difícil era algo que uno esperaría que solo un principiante encontrara difícil, entonces es probable que no sean buenos solucionadores de problemas (a menos que esta sea una entrevista para nivel de entrada). Si es algo realmente difícil y describen su proceso de pensamiento al intentar localizarlo, 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 nada que no sea un trabajo directo, fuera de la escuela y de muy bajo nivel.

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

• Guíeme por todos los pasos que tome para identificar la causa raíz y corregir un error (defecto)
• ¿Cómo utilizarías la pila de llamadas al depurar un subproceso múltiple? aplicación

Esto funciona muy bien, especialmente en las entrevistas telefónicas, ya que solo necesitas que la persona te dé una respuesta convincente que muestre cómo realmente se resuelve al resolver un problema.