WTF como ejercicios en entrevistas y en formación
sábado 3 de enero de 2009
A estas alturas del año ya habréis visto el código responsable del cuelgue masivo de los Zune:
while (days > 365) {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
if (IsLeapYear(year)) {
if (days > 366) {
days -= 366;
year += 1;
}
} else {
days -= 365;
year += 1;
}
}
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.
- 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.
- 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!).
Enviar a
Posted by Nacho 08:28
Etiquetas: calidad , formación , wtf
12 Comments:
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.
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...
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.
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.
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 -
@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
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.
"""
+1 a ejercicios cortos en entrevistas para desarrolladores y juniors.
"""
Y para los jefes de proyecto? y para los gerentes de tecnológicas ? :)
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.
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.
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.