WTF como ejercicios en entrevistas y en formación

A estas alturas del año ya habréis visto el código responsable del cuelgue masivo de los Zune:

    while (days > 365) {
if (IsLeapYear(year)) {
if (days > 366) {
days -= 366;

year += 1;
}
} else {
days -= 365;
year += 1;
}
}
Este código no creo que entre en la categoría de WTFs, a todo el mundo se le puede patinar un igual. Sin embargo, me viene de perlas para uno de los trabajos que voy a tener en los próximos días: preparar ejercicios de programación para formación y contratación (¿por qué será que recruiting me parece más preciso?). En un post anterior en el que hablaba de mi opinión sobre la aptitud y actitud profesional, Julio César Pérez comentaba lo siguiente
La pregunta estrella era implementar una funcion recursiva que calculara el factorial de un numero entero en cualquier lenguaje. Sólo el 10% la hicieron bien y todos los candidatos eran como mínimo ingenieros.
Ya me habían mirado raro a veces por opinar que las entrevistas hay que orientarlas en ese sentido, pero desde que supe que Google pide programar en una pizarra me he sentido reafirmado: las entrevistas deben ser prácticas.


Contexto
Trabajo en un entorno parcialmente universitario, por lo que una de nuestras razones de ser es la ocupación de estudiantes, con las ventajas e inconvenientes que esto conlleva.

Requisitos
Necesito una forma de...
  • poder evaluar en una entrevista de trabajo los conocimientos (si hablamos de gente con experiencia) o la aptitud (si hablamos de becas) de una persona.
  • facilitar la autoformación del personal, nuevo o no, que se va a incorporar a proyectos con nuevas tecnologías.
Alternativas de implementación
  • Para las entrevistas, recopilar una serie de WTFs y trozos de código, tanto correctos como no, y preguntar al entrevistado por ellos.
  • Para la formación, plantear ejercicios cortos con tareas de no más de una o dos horas, en el que se busque escribir código lo más impecablemente posible. Una vez completado el ejercicio, alguien revisaría el código escrito para pulir entre los dos todo lo mejorable.
Esto último de la revisión, aunque algo exigente (ocupa a dos personas en código de prueba) me parece fundamental. En mi opinión, pensar que una persona aprende a programar símplemente programando es falso. Conozco gente que programa mal y lo seguirá haciendo toda su vida, porque ni lee código de otros, ni libros, y nadie le corrige sus errores. Especialmente en entornos de formación, la figura del revisor me parece fundamental.
  • Calidad de código en el motor de integración contínua como formación: tanto instalar plugins de Eclipse como generar informes de calidad de código pueden ser positivos para aprender. Si se presta atención a los warnings de FindBugs, PMD o Metrics se puede aprender mucho (¡a la vez que mejoras la calidad!).
PD: aquí, al hablar de "código WTF" me refiero a código con una elevada medida de "WTF" como en la siguiente viñeta:

Posted by Juan Ignacio Sánchez Lara 8:28  

12 Comments:

  1. javi santana said...
    La idea de hacer programar en una prueba me parece básica, pero para mi es más importante la aptitud que la calidad programando. Influyen cosas como si sabe buscarse la vida, el orden, lo metodológico (casi todo cosas relacionadas con el trabajo en equipo) que sea que no se ven programando un factorial.

    Las code reviews cada día me parece más importantes. Un artículo al respecto de un ex-googler: http://1-800-magic.blogspot.com/2008/12/one-google-thing-i-miss-most.html

    De cualquier forma, solo con hablar 1 minuto con una persona se sabe si ha programado o no o si está interesada o no.
    anllogui said...
    Creo que Google no es un buen ejemplo de recruitment en España, ya que ninguna de las tics de este pais puede ofrecer ni la mitad de lo que ofrece Google en sueldo, facilidades laborales, estilo y nivel de management, etc. Ya que como dice el dicho, si pagas cacahuetes contratarás monos.

    Pero siguiendo buscando duros a 4 pesetas, no hace falta hacer programar para saber si el candidato controla, sino con unas pocas preguntas basta. Eso sí, el entrevistador ha de saber de que está hablando.

    Lo que me recuerda a la entrevista que realizó un amigo en madrid en una tic, en la que el entrevistador hacía preguntas técnicas y se iba apuntando lo que respondía. Mi amigo controlaba bastante y se explayaba en las respuestas. El entrevistador asentía y apuntaba. Hasta que al final, mi amigo preguntó si tenia idea de lo que le estaba respondiendo, a lo que el entrevistador respondió que el no, pero que una persona entendida revisaría la entrevista. A ellos les habría venido bien tener un ejercicio de código...
    Nacho said...
    @javi_santana: creo que está claro que el objetivo de quien pide programar un factorial es precisamente ver su aptitud.
    De hecho, otra de las cosas que barajo es poner ejemplos de errores y/o trazas de excepciones, para ver lo que comentas sobre "si sabe buscarse la vida".

    Muy bueno lo de las code reviews, he visto también el video de Guido sobre Mondrian.

    @anllogui: creo que la idea no es intentar exigir el nivel de Google, sino, dado un conjunto de candidatos, tener la posibilidad de elegir a los mejores con la mejor información posible.
    El extremo que comentas yo también lo he vivido, y efectivamente, es ridículo.
    -®- pIpO -®- said...
    Te cuento, aca en México he tenido varias entrevistas de estudiante y ahora de egresado, tengo 6 meses de egresar, las entrevistas van desde algo "practico" que te ponen en papel a realizar (ahora recuerdo) el movimiento del caballo en el ajedrez en java, o son examenes tipo "certificacion" como los de javablackbelt en los cuales la primer pregunta es por lo general la declaración de variables cual no marcara error o warning, no se, se me hace que no es la forma correcta de evaluar que nivel traes, ya que no por tener mal esa pregunta no sabes programar, va mas alla, yo creo que si se debe analizar a la persona con un WTF como lo indicas, ya que es la logica lo dificil de este negocio, el enseñar el lenguaje alguien que tiene logica es mas sencillo y mas barato... no tengo años de experiencia pero como profesional en busca de crecer creo que seria la forma correcta de ponerme a prueba.

    Interesante tu blog,a pesar de que eres informatico de los 80's, estas mas actualizado que muchos de por aca ...

    Si tienes los ejercicios seria interesante checarlos, digo para prepararme.
    jeza said...
    Nacho, he intentado, sin éxito :( implantar peer reviews en algún proyecto. Creo que para la formación puede ser muy interesante, pero para proyectos de desarrollo me he encontrado con varios problemas: explicar al boss porque hay un programador mirando, por ej., o tener que justificar porqué se emplea más tiempo del estimado en desarrollo y pruebas del estimado, cuando los proyectos están regalados más que vendidos. De todas formas ya sabes que apoyo todas tus iniciativas.
    Respecto a la aptitud, no olvides que también es muy importante la actitud, casi más que la primera. El problema de la actitud es que es cambiante en función del clima laboral ;)
    Y por último, y para evaluar la capacidad de trabajo en equipo, si tienes la oportunidad no dudes en hacer una dinámica de grupo (por ej. si tienes varios candidatos finales) - en las dinámicas se les ve el plumero enseguida a los trepas, sanguijuelas y demás personajes -
    Nacho said...
    @-®- pIpO -®- : no me gustan los exámenes de certificación, porque dan demasiada importancia a la sintaxis. Una vez me preguntaron en un examen cómo ordenar por un par de parámetros diferentes (no recuerdo cuáles) con el comando 'ls', y no recuerdo si no respondí o respondí una bordería del estilo 'man ls y lo miro'. Cuando buscas gente para un puesto muy específico (programador java 100% en tu caso, o administrador UNIX en el mío) tiene su lógica, porque eso puede mostrar si realmente lo manejas a diario. Pero para puestos más versátiles, como habitualmente, temas de sintaxis no son importantes.

    @jeza:
    - Sobre las peer reviews: tanto en este caso como en otros, mi pelea es demostrar que las técnicas que proporcionan calidad al producto (pruebas, revisiones de código, métricas estáticas...) reducen el tiempo de desarrollo total. Hacer peer reviews reducirá (soy positivo :) ) el tiempo de corrección de errores, porque corregirá tanto los vistos en la revisión como los que en un futuro el "revisado" no cometerá.
    Eso sí, si la estimación es un regalo, todo van a ser problemas, pero esa es otra historia. Una de las cosas que se repite hasta la saciedad en Peopleware es que no se debe bajar la calidad del producto por culpa de las fechas, porque eso mina la moral de la gente.

    - Actitud, of course :). No veo útil entrar a discutir cuál de las dos es más importante, y ambas se pueden desarrollar, mejor o peor.

    - Sí estaba pensando en dinámicas de grupo... en el Tío Molonio un jueves =D
    Nacho said...
    PD: "El Tío Molonio", para los no pucelanos, es un bar :)
    jcesarperez said...
    Vaya, qué sorpresa lo de la cita! Es verídico eh. Los entrevistados eran todos mínimo ingenieros técnicos en informática o teleco, eso sí casi todos sin experiencia.

    Además decir que el 10% fueron los que lo implementaron perfecto, teniendo en cuenta valores negativos y el cero. Con una implementación menos exigente el % subía hasta asi la mitad.
    Luego habia de todo, desde gente que no incluia un caso base a gente que directamente hacia un procedimiento con sysos en vez de una funcion o alguno que hizo un for en vez de recursividad.

    Y eso que mi idea original era implementar el borrado de un directorio de forma recursiva!

    Por si te interesa, el resto del test escrito eran preguntas teóricas sobre Java y POO. Era un test muy corto, no llegaba a 20 minutos. La oferta era para Desarrolador Java sin experiencia requerida (intentaré hacer un post sobre todo el proceso).

    En conclusión:

    +1 a ejercicios cortos en entrevistas para desarrolladores y juniors.

    Para formación podría estar bien si la empresa se lo toma en serio y obliga a hacerlos por ejemplo una vez al año. Realmente sería muy curioso y siempre es mejor que el típico catalogo de cursos online obsoletos.
    javi santana said...
    @jcesarperez: para ti perfecto es que vayan más allá de la especificación... En cualquier caso, si yo pongo ese ejercicio lo daría por bueno con 3 ó 4 casos de test sin que la función estuviese implementada.

    """
    +1 a ejercicios cortos en entrevistas para desarrolladores y juniors.
    """

    Y para los jefes de proyecto? y para los gerentes de tecnológicas ? :)
    jcesarperez said...
    Hola Javi.

    No entiendo lo de la especificacion que comentas. El enunciado era: implementar una función recursiva que calcule el factorial de un número entero. No hacia falta que fuera en Java.

    Los números enteros incluyen los positivos, negativos y el cero. Por tanto, tener en cuenta esos casos entra dentro de la especificación.

    El objetivo del ejercicio iba más allá de que el código funcionara para n!. Examinando la respuesta se podian sacar muchas cosas, por ejemplo:
    ¿Diferencia el candidato entre funcion y procedimiento?
    ¿Tiene una base en programacion aceptable (recursividad)?
    ¿Es capaz de analizar en detalle una especificacion?
    ¿Tiene en cuenta casos de error?
    ¿Realiza un código ordenado?
    ¿Se siente cómodo programando en Java? (Aunque no se exigia un lenguaje, la oferta era Desarrollador Java)

    Es igual que en las preguntas teóricas sobre Java y POO, no buscaba respuestas perfectas sino ver que el candidato sabía expresarse y escribir correctamente además de que no metiera la pata con conceptos básicos.

    En realidad el test sirve más para rechazar candidatos que para ganar el puesto. Lo segundo ya dependía más de la entrevista cara a cara. Una vez comprobado que tiene un nivel de aptitud aceptable, lo siguiente a examinar es su actitud.

    Todo esto para el caso de un desarrollador Java (seguramente junior). Para puestos donde no se va a picar código veo más importante buscar otras aptitudes. Tendria que pensarlo, pero lo enfocaria más a cosas relativas a procesos y metodologias, como testing, ci, formacion, arquitectura, tecnologias, experiencia, portales o blogs que visite.
    javi santana said...
    @jcesarperez no he hablado de java en ningún momento, pero ya que lo comentas si el ejercicio es libre y la persona lo hace en java es un punto negativo de entrada :).

    Lo que yo me refiero es que si le mandas hacer un factorial y te hace lo siguiente:
    /**
    * aqui la doc
    */
    int fact(int n);
    void main()
    {
    ASSERT(fact(0) == 1);
    ASSERT(fact(1) == 1);
    ASSERT(fact(2) == 2);
    ASSERT(fact(3) == 6);
    ASSERT(fact(-4) == -1);
    }


    (y no te digo nada si lo hace en python y usa doctest)

    para mí tiene mucho más mérito que saber implementar la propia función el hecho de que sea metódico (los test lo demuestran), que sepa trabajar en equipo (la documentación y los test lo demuestran). Implementar bien esa función significa que o bien lo sabe hacer o lo tiene bien entrnado de cualquier test de internet.
    jcesarperez said...
    @javi hubo uno, con experiencia, que sí añadió un main con una especie de assert a pelo.

    Desgraciadamente no es nada normal encontrar gente sin o con poca experiencia que sepa de asserts y testing en general. Algo falla en nuestro sistema educativo...

    No coincido contigo en que resolver el ejercicio en Java sea negativo. Al revés. En la oferta sólo se citaban los lenguajes Java y Javascript. Si sabes python ya lo habrás puesto en el curriculum y ya llegará el momento de hablar de ello. Pero la oferta es Java y para mi es sintoma de ser practico hacer la implementacion en Java. Pero bueno, son gustos. No merece más la pena discutirlo.

    De todas formas, insisto, este tipo de tests yo los veo más para descartar candidatos que para seleccionar al elegido.

Post a Comment