Código como parte de entrevistas técnicas

Imagen de http://theodysseyonline.com/suny-new-paltz/interviews-the-bane-of-everyones-existence/249182

En los últimos meses he hecho unas cuantas entrevista en diferentes empresas españolas o que tienen sede en España y comparándolas con las que he hecho en Holanda lo que más me ha llamado la atención es que en ninguna española me han pedido código. Me llama la atención porque es algo que frecuentemente me han pedido en Holanda.

Pensando sobre esto me pregunto si puedes decir que un programador es bueno sin haber visto una línea de código que ha escrito.

Pongamos como ejemplo las entrevistas que he hecho para una empresa en España. Hice tres, una técnica, otra con mi posible futuro jefe y en la última con alguien de recursos humanos.

En la entrevista técnica respondí a muchas preguntas y en la parte final tuve que resolver problemas utilizando Java. En esta entrevista pudieron ver mis capacidades para resolver problemas y mis conocimientos de forma general sobre la informática.

En la segunda entrevista estuve hablando en ingles con mi posible jefe por teléfono. Fue una conversación sobre temas poco relacionados sobre mi trabajo, excepto por las preguntas que hice sobre la empresa. En esta entrevista pudieron comprobar cómo me manejo con el inglés y seguramente algo sobre mi carácter y forma de ser.

En la ultima entrevista hablé con alguien de recursos humanos sobre las cosas que le interesan a la gente de recursos humanos. Me imagino que van dirigidas a intentar conocer cuáles mis habilidades no técnicas, lo que en inglés se llama soft skills.
Teniendo en cuenta las tres entrevistas esta empresa sabe de mí:

• Mi capacidad de resolver problemas
• Mis conocimientos sobre informática
• Como me comunico en español y en inglés
• Mi forma de ser
• Mis habilidades no técnicas

Con esta información, ¿pueden saber si soy un buen programador? En mi opinión, no. Paso una parte importante de mi tiempo escribiendo código por lo que sí no ven nada de lo que he escrito es imposible que sepan que soy un buen programador.

Y si no saben si yo soy un buen o mal programador es posible que halla pasado lo mismo con los que serían mis futuros compañeros. Eso es muy peligroso porque significaría que la gente con la que estaré rodeado no son buenos y que por lo tanto podré aprender poco de ellos. Es un problema ya que aprender es muy importante para un profesional y más para un informático.

En conclusión, las empresas que no preguntan por código o no hacen pruebas de código no pueden garantizar que sus empleados sean buenos programadores. Personalmente, no me fío de este tipo de empresas porque pueden tener gente con la que podría trabajar y que me no aporten nada a mi aprendizaje.

Ciclo TDD: versión extendida

Imagen de http://www.agilenutshell.com/test_driven_development

Cuando a alguien se le explica por primera vez test driven development (TDD) lo primero que se le cuenta es su ciclo de desarrollo, que consiste en:

1. Escribir un test que falle
2. Escribir código de producción que haga que el test pase
3. Refactoriza el código

Estos pasos son un gran resumen de las principales tareas que hay que hacer en TDD pero para alguien nuevo en TDD no es suficiente. Voy a extender el mismo ciclo de desarrollo añadiendo más detalles. La mayoría de los pasos vienen de la siguiente página:

http://c2.com/cgi/wiki?TestDrivenDevelopment

Versión extendida

1. Selecciona un test. Busca un test que sea fácil de implementar pero que permita progresar lo máximo posible en la implementación
2. Piensa cómo quieres comprobar que el test pasa
3. Piensa qué debe ocurrir cuando todo va bien y cuando ocurre algo inesperado (excepciones). Por ejemplo, cuando hay problemas en la base de datos.
4. Escribe el test teniendo en cuanta cómo quieres que sea la API. Con la API me refiero al nombre del método, a sus parámetros y al valor a devolver
5. Haz que compile el código creando las clases y métodos que has escrito en el test. Los métodos deben devolver un valor, el que consideres que es el de por defecto
6. Comprueba que el test no pasa
7. Escribe el mínimo código de producción que hace que todos los test pasen. Si, el mínimo.
8. Si es necesario, mejora el código sin cambiar su comportamiento. O lo que es lo mismo, refactoriza el código
9. Comprueba que todos los test pasan

Notas

Teniendo en cuenta los pasos de la versión extendida, cuando escribimos el test ya hemos decidido qué vamos a hacer, cómo vamos a testearlo y cómo será su API. Luego dirán que con TDD no se piensa :)

Para gente con cero experiencia con TDD seguramente lo que les resulte extraño es que al escribir el
primer test, el código no compila y tendremos que crear todas las clases y métodos necesarios para que el código compile. Es una forma diferente de pensar, por lo que es necesario tiempo para asimilarla.

Consejo

Un muy buen consejo de Kent Beck en su libro TDD by example es el mantener una lista de los tests que quieres implementar. Así, cada test o prueba se convierte en una tarea a realizar y cada vez que terminas una es un ciclo TDD terminado y te acerca a la nueva funcionalidad que estás buscando.

Si eres indispensable estas haciendo mal tu trabajo

Imagen de http://www.newyork.com/

Te quieres ir de vacaciones tres semanas y se lo comentas a tu jefe. Te dice que ahora imposible porque el proyecto en el que estás trabajando eres el único que puede hacer una parte que es crítica. Al escucharle te sientes decepcionado al perderte tus vacaciones pero a la vez orgulloso porque eres una persona importante en tu empresa y porque eres imprescindible, ya que sin ti tu empresa no funciona.
Si este es tu caso no deberías sentirte orgulloso porque no estás haciendo bien tu trabajo.

Hay muchas razones por la que eres imprescindible pero seguramente que lo que está sucediendo es que eres la única persona en tu empresa que tiene el conocimiento de cómo realizar esa tarea.
Hay muchas razones por lo que esto puede suceder. Algunas son:

• La tarea es de vital importancia y no confías en nadie para hacerla.
• Tú eres la única persona con los suficientes conocimientos sobre el tema para entender el que hacer si surgen problemas.
• Tus compañeros no son lo suficiente buenos o profesionales para hacer (o eso es lo que tú piensas).
• No has tenido tiempo en compartir lo que sabes porque ha surgido algo urgente.
• Has pensado que no era importante el compartirlo.
• Tu jefe te ha dicho que es una perdida de tiempo.
• En un caso extremo de egoísmo, has decido el no compartirlo para convertirte en imprescindible y que no te puedan echar.

En cualquiera que sea tu caso no estás pensando en tus compañeros, ni en tu empresa y ni siquiera en ti.

De primeras te has quedado sin vacaciones, así que la playa y los mojitos tendrán que esperar. Además te has quedado sin aprender, porque no se tu pero cada vez que comparto información con mis compañeros siempre aprendo algo nuevo de ellos. Puede que aprenda algo pequeño pero siempre aprendo, y si eres informático como yo el aprender debería ser algo muy importante porque a los pocos años te quedas desfasado.
Si no eres informático el aprender también debería ser importante porque así te podrá diferenciar de tus compañeros y tener más posibilidades de destacar.

Desde el punto de vista de tus compañeros, toda la información debe estar compartida al menos por dos miembros de tu equipo. Así sí uno de ellos está enfermo, está de vacaciones o deja la empresa siempre habrá otra persona con esa información.
Por ejemplo, imagínate que has estado enfermo y debido a ello tu equipo ha estado casi parado. Lo que ha provocado que el proyecto no se ha terminado a tiempo y tu empresa ha perdido tiempo y dinero. Y todo ello por tu culpa, por no hacer bien tu trabajo y no compartir lo que sabes con tus compañeros.

Si no te he convencido y crees que eres intocable porque eres el único con esos conocimientos, recuerda que el mundo de la informática todo cambia muy rápidamente y que en 2, 5 o 10 años ese conocimiento no valdrá nada, tus jefes querrán despedirte, ninguna empresa querrá contratarte y lo vas a pasar mal. El que avisa no es traidor.