Durante las últimas semanas le he estado dando la vuelta a un tema relacionado con la búsqueda de empleo. Normalmente cuando a uno le preguntan en una entrevista de trabajo si desea saber algo sobre la compañía, se suele caer en las típicas preguntas sobre horario de trabajo, vacaciones, pensiones, comidas, bonuses, etc.
Pero, a parte de esto, cuando uno se dedica al mundo del software ya sea como programador, arquitecto, jefe de proyecto o manager, lo que le gusta es caer en un sitio donde se pueda aprender cosas nuevas, evolucionar técnicamente, trabajar con las últimas tecnologías, estar expuesto a sistemas interesantes o integrarse dentro de ciclos de desarrollo racionales con metodologías de programación modernas. Atendiendo a esto, probablemente merezca la pena dedicar estos últimos minutos de la entrevista a realizar otro tipo de preguntas que den una pista de si tu futuro entorno laboral va a ser enriquecedor o no, desde punto de vista técnico.
Pero, ay, y ahí está el problema, el entrevistador probablemente intentará maquillar cualquier punto negro de la empresa, ya sea para cazarnos o para no exponer sus vergüenza. Por ejemplo, si vamos a una entrevista y preguntamos "- ¿Utilizáis metodologías ágiles?", no sería raro recibir una contestación como "- Por supuesto, por supuesto, nuestros equipos practican XP", y dos semanas después encontrarse con cien folios de requisitos que tienen que firmar diez personas de diez departamentos diferentes para poder pasar al diseño de la aplicación.
El conjunto de preguntas deberían ser lo suficientemente claras y directas para no dar lugar a error sin llegar a ser ofensivas o sin llegar a poner en peligro nuestra candidudatura. Es decir, preguntarle al entrevistador que nos diga lo que es un assemblyen .NET puede resultar un poco incómodo para ambos :-)
A mi se me ocurren una serie de preguntas que nos pueden dar pistas de como funciona la empresa sin que el entrevistador se sienta realmente entrevistado. Estas preguntas son evidentemente técnicas. Si el entrevistador no sabe responderlas, titubea, se muestra dubitativo o esquivo, yo desconfiaría directamente de la empresa, especialmente si ese va a ser nuestro. Me voy a centrar en Java porque si pongo otro lenguaje de ejemplo al final soltaré alguna tontería. Aún así, las preguntas y sus explicaciones son lo suficientemente generales para ser aplicables directamente a cualquier otro lenguaje/plataforma. Ahí van:
- ¿Qué framework de desarrollo utilizáis?:
Atención, porque esta pregunta es la más importante. Si por cualquier razón la respuesta es "tenemos un framework propio", mal pinta la cosa. De hecho, hasta me atrevería a ser radical y decir que es hora de huir de ahí como del demonio. A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas "porque Spring o JSF no se ajustan a los requisitos de la empresa".
El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda. De aceptar esto, tocará trabajar con tecnologías probablemente obsoletas, tocará corregir bugs que no estarían ahí de utilizar algo probado, o tocará "mejorar" el framework con cosas que ya están implementadas en otras librerías. Un framework propio, puede ser resultado de una mala elección, o quizás de una elección forzada debido a que el producto se creó hace muchos años.
La respuesta ideal dependerá de lo que quiere hacer el desarrollador o del lenguaje, pero a cualquiera que se mantenga un poco al día le será fácil detectar nombres clave. En Java, Spring, Hibernate, JSF, WebWork, Seam, o incluso EJBs serían respuestas válidas. Struts, mmmmm, ok, todavía hay mucho Struts por ahí y siempre será mejor que un framework web propio. En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente. - ¿Qué metodología de desarrollo utilizáis?:
La pregunta, así de seca. Sin dar pistas. Así, si el entrevistador nos quiere engañar no podrá predecir nuestros gustos (salvo por nuestro CV). Si la respuesta no es clara, o es "bueno, nosotros tenemos nuestra metodología propia", etc. entonces ojo, peligro de caos, intentemos sacar algo más de información.
Si la respuesta es cualquier cosa que implique desarrollo en cascada (e.g. métrica o similares), un punto por ser honesto. No tiene porque ser algo tan terrible si el resto de preguntas están a nuestro gusto, o si el ciclo de vida de los proyectos sigue un flujo racional. Es mejor que conteste eso que el que detectemos que nos intenta engañar.
Si la respuesta es XP, yo estaría con la mosca detrás de la oreja, al fin y al cabo se lee más de esta metodología de lo que se usa en realidad. Si la respuesta es Scrum, o cualquier otra metodología o derivación que implique desarrollo ágil (e.g. RUP bien aplicado), seguramente estemos ante un buen lugar. - ¿Qué sistema de build utilizáis?:
Si la respuesta es ninguno, o qué es eso, pues muy mal empezamos. En Java, si la respuesta es ant, desconfianza total (lo siento por los que todavía utilizen ant, pero los sistemas de build ya han avanzado bastante en los últimos años) ya que podría significar que el trabajo será realizar mantenimientos viejos, o que la empresa no se preocupa en mejorar sus herramientas. Respuestas como maven, ivy, etc. indican que se han preocupado de mejorar estas cosas. Si la respuesta incluye integración continua, de manera espontánea, será un excelente indicador.
- ¿Qué entorno de desarrollo utilizáis?:
Esta es la típica pregunta que, siendo bastante inocente, nos puede dar bastante información sobre como es la empresa ha evoolucionado desde el punto de vista del software. En una plataforma como Java, ha habido y hay montones de entornos de desarrollo, cada uno con una historia particular que nos puede dar pistas sobre la gente que lo utiliza.
Intellij IDEA por ejemplo siempre ha sido un entorno de desarrollo que siempre ha tenido buena fama. Punto positivo si lo usan. Si la empresa utiliza NetBeans y Eclipse, se situará en el baremo de lo habitual, así que no nos indicará nada bueno o malo. Si utiliza alguna especialización de Eclipse (e.g. MyEclipse), puede ser un buen dato ya que Eclipse se deja muchas cosas en el tintero, y eso denotaría que lo saben y que han buscado una solución. Otros entornos que han ido quedando más en desuso si que nos pueden dar una pequeña alarma sobre la compañía.
¿Utiliza Visual Age, o Visual Café? Entonces es hora de huir. Estos son entornos desaparecidos hace siglos. ¿BlueJ, JCreator, ...? Hay algo raro. Son entornos que muy poca gente utiliza. ¿JBuilder, JDeveloper? Cuidado. Son entornos que han caido bastante en desuso y que la gente suele utilizar por el valor añadido de sus componentes, es decir, que quizás estén utilizando todo este "valor añadido" que es mejor evitar.
¿BEA WorkShop, WebSphere Studio, ...? Cuidado. Esto puede indicar tanto que la empresa aprovecha realmente todas las funcionalidades que ofrecen lo que sería muy bueno, como que la empresa no tiene ni idea de lo que hace y espera que las aplicaciones funcionarán mejor por el mero hecho de utlizar el IDE que viene con el servidor de aplicaciones. - ¿Cómo se prueban las aplicaciones?:
Esta es una pregunta un tanto complicada porque resulta muy amplia así que habrá que estar atento a las respuestas. Si la respuesta incluye un departamento de calidad, con bastantes personas, eso será un buen indicador. Si no lo incluye, no tiene porque ser algo terriblemente malo, aunque dependerá de lo que nos diga a mayores.
Si el entrevistador nos menciona explicitamente unit tests, tests de integración, tests de stress, será un buen detalle. Si nos menciona soak testing (dejar una aplicación ejecutandose durante semanas), será un muy buen indicador. Si a mayores detectamos la presencia de algún sistema de automatización de tests, ya sea Mercury, Selenium, DBUnit, etc. será un punto realmente muy positivo. Y ya si nos comenta que los tests se ejecutan dentro del sistema de integración continua que nos mencionó antes, entonces... ¿pagan bien? :)
Si la respuesta no incluye nada de lo anterior, mucho cuidado. Puede ser una buena empresa con simplemente una falta de control de calidad, pero también una empresa caótica donde no queremos trabajar. ¿Ha respondido bien al resto de preguntas? Si la respuesta es "tenemos nuestro propio sistema de testing" (ver el primer punto), entonces habrá que plantearse seriamente el trabajar en esa empresa.
Vaya, he repasado el post y me ha quedado realmente largo. Espero que al menos alguien lo encuentre interesante. A mi, personalmente, me interesan más aún vuestras preguntas, así que lanzo esto al aire a ver si alguien lo recoge: ¿Qué preguntaríais vosotros para evaluar a una empresa en una entrevista de trabajo relacionada con el mundo del software?
Imagen via melissa22@flickr.
Shashikant01 
