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.
comments
15 Respuestas a "Cinco preguntas para tu próxima entrevista de trabajo si te gusta el software"12:59
Estoy de acuerdo recena, por eso el punto donde digo que esas preguntas no deben sonar como un examen para la empresa sino como simple curiosidad profesional, que es muy sana.
13:27
En todas mis entrevistas he hecho estas preguntas, o similares. Una entrevista de trabajo es para que te conozca la empresa y para que tú la conozcas. Si ellos te pueden interrogar, tú tienes el mismo derecho a interrogarles, ¡qué narices!.
Estoy un poco en desacuerdo respecto a la pregunta de los framework, y la ampliaría a qué lenguajes y tecnologías usan. Si te dicen usamos X con el framework Y, sin más, mal asunto. Yo al menos no iría a esa empresa (donde, por probabilidad, posiblemente X será Java e Y será struts, típico caso de consultora cárnica).
Muchas empresas (normalmente las grandes donde nadie se preocupa de nuevas tecnologías emergentes) se encasillan en una tecnología concreta y eso desde luego repercute en la calidad de los proyectos. Para cada proyecto hay que elegir qué usar.
16:51
Muy interesante!
Ciertamente son preguntas que DEBES hacer para conocer la empresa donde vas a ir. Como dice blaxter la entrevista debe ser a dos bandas, no es cuenta solo la decisión de la empresa, si no si a ti te interesa ir o no a trabajar a ella.
Las entrevistas de trabajo deberían empezar a verse más como una negociación entre dos bandas.
8:21
Uy, en la mía según quien te haga la entrevista pueden despistarte. Es tan sumamente caótica, que unos usan maven, otros hacen script .sh o .bat para compilar. Unos usan spring, otros no usan nada. Unos usan iBatis, otros usan JDBC a pelo... ¡¡ Y todo en el mismo proyecto !!. E incluso han metido JEE para una aplicación no web con cuatro ordenadores y tres operadores en una red cerrada.
Se bueno
9:03
Me gustaría añadir algo. ¿Qué tal algo de formación?
No sería bastante adecuado que cuando entras a trabajar en una empresa, hubiese un plan de formación, ya sean cursos de programación, especialización en algún servidor, algo de administración de bases de datos, performance, alguna nueva tecnología, quizás certificaciones, etc.
¿Qué decis?
10:29
No sé Jesús, yo creo que cuando alguien pregunta por formación la respuesta es "sí, nosotros nos preocupamos mucho por los empleados, tenemos un plan de carrera, los mandamos a cursos, les subvencionamos las certificaciones, ..." y mirando en TrabajoBasura parece que casi siempre de ahí a la realidad hay un mundo.
16:08
Yo no sé si es una pregunta interesante, supongo que en Dublín no tiene mucho sentido, pero aquí preguntaría ¿Cuánto tiempo lleva el desarrollador más antiguo de la empresa? Poco tiempo, mal asunto, por algo se marchan. Mucho tiempo, entonces quizás es un acomodado con pocas miras, pero para eso están el resto de las preguntas. También se podría preguntar, o me gustaría saber, la proporcion entre personas en producción (diseñadores, redactores, programadores) y personas en dirección-gerencia-contabilidad, porque hay veces que asusta esa proporción. Luego preguntaría si leen este blog, y qué piensan de él ...
18:51
@Albin, muy buena esa pregunta de "cuanto tiempo lleva el desarrollador ...", es una forma encubierta de preguntar, ¿tenéis un rotamiento de gente nonstop? xD (símbolo de que es una p**a mierda de empresa, hablando claro)
0:22
Martin, depende del puesto que vayas a cubrir y de tu experiencia.
Las preguntas me parecen bien planteadas si buscas un trabajo de desarrollador de aplicaciones o tienes poca experiencia, ya que te interesa que el entorno de trabajo (tecnologías, procesos, ...) sea atractivo y puedas aprender. Suelen ser entornos donde se desarrollan aplicaciones como churros utilizando una factoría de software pura y dura, y donde solo podrás innovar en la parte de "negocio".
Pero si estas más interesado en el lado tecnológico, o en la ingeniería del software, o en la arquitectura, o tienes bastante experiencia, entonces no te conviene una empresa que conteste positivamente a tus cinco preguntas. De lo contrario, te vas a aburrir un montón, ya que no hay nada a mejorar!!!
9:56
@Albin, son buenas preguntas. ¿Quizás un poco hostiles? Aunque estamos en lo de siempre, las preguntas que he puesto yo también se pueden considerar como "hostiles" en cierto punto. Todo depende de lo "saludable" que sea la empresa y el entrevistador. A mi personalmente apreciaría esas preguntas.
@Ferdy Ahí tienes razón, a nadie le gusta aburrirse :) De todos modos, ¿a quien no le gustaría participar en una de esas arquitectura que te presentan en la QCon? Aunque eso es como las peliculas, nadie te habla del "backstage".
22:30
Juassss! Me ha encantado la entrada!
Yo es que precisamente estuve en una empresa en la que un gran "arquitecto de software" (al cual le parecia que ASP.NET era el santo grial y, por dios, no le preguntases que es eso de MVC) estaba empezando a elucubrar para hacer el framework de la empresa! Ay que me meo de la risa (eso ahora), porque es que no se que es peor, si entrar en una empresa que lo tiene, o en una que lo quiere hacer!!
Otra pregunta interesante que podemos hacer que proporcion de ingenieros tecnicos/superiores informaticos hay trabajando en la empresa, y sobre todo que estudios tiene el arquitecto de software o coordinador. Yo estuve en una empresa en la que primero habia un jefe que era ingeniero superior pero que tenia un perfil muy de sistemas, y no se preocupaba para nada de mejorar la arquitectura de software, pues al final lo que hacia era probar el producto. Luego se puso a un ingeniero de teleco y a este lo unico que le importaba es lo que dijera el cliente, eso de medir todo estaba muy bien pero no se preocupaba si la calidad interna del producto era buena o mala (algo que puede no detectarse a la primera ni por un cliente en particular, sino por la trayectoria y calidad general del software, que hace que sea inestable o estable).
En fin, no se me ocurre nada mas, pero este es un tema muy interesante sin duda.
22:31
PD: Siento haber publicado sin tildes ni enyes, estoy en un teclado ingles.
13:12
Realmente interesante!
Simplemente encuentro a faltar alguna referencia a qué sistema de control de versiones se utiliza, y qué políticas de versionado/branching utilizan (te puede dar ideas sobre cada cuanto se lanzan nuevas versiones de los productos, si existen equipos específicos de mantenimiento de versiones, etc.).
Un saludo y gracias por compartir tus conocimientos (porque desde tus posts en Javahispano te habia perdido la pista jeje),
Juan Carlos (LeTissier)
22:53
Cierto Juan Carlos, esa sería una buena pregunta también. CVS está ya un poco anticuadillo, y probablemente usarlo para proyectos nuevos indique un poco de desidia en el equipo de arquitectos.
Por otra parte, saber si tienen un plan de versiones, un buen roadmap estable, etc. son cosas también bastante importantes.
3:39
Hola,
Estoy muy de acuerdo con el artículo. De hecho encaja bastante con mi perfil y con el tipo de empresa en el que me gustaría acabar (por tecnología y por metodología de trabajo).
Ahora que estoy en proceso de búsqueda en tierras de habla inglesa, ¿algún listado de empresas que cumplan tales requisitos? (o quizá una pista de donde encontrarlo).
Merci y feliciadades por un blog muy interesante,
Iván
Publicar un comentario