Entrevistas de Trabajo

Casi como cada año comencé este año 2019 en procesos de selección. Después de pasar muchas veces por esto creo que puede ser interesante compartir cómo fue esta vez mi proceso. ¿Buscamos trabajo?

Por desgracia mi aventura con Altenwald no funcionó y desde 2016 he tenido que ser empleado en otras empresas mientras intentaba levantar la compañía. Esta es otra historia a contar más adelante por lo que voy a centrarme en el tema de este artículo de momento: las entrevistas de trabajo.

Procesos de Selección

He estado en decenas de procesos de selección. En concreto y para mostrar datos reales en este año entre enero y marzo de 2019 he pasado por 14 procesos de selección diferentes. Contando los que progresaron más allá de dar los datos y no obtener nunca respuesta claro. De estos a los que envié mis datos y nunca me respondieron o me rechazaron antes de poder avanzar a otra fase fueron otras 4 compañías.

Además, resido en estos momentos en los Países Bajos y para atender el avance de algunos procesos tuve que desplazarme físicamente a las oficinas de algunas de estas empresas. Lo que llevó a viajar entre enero y febrero 4 veces: 2 veces a Londres y 2 veces a Barcelona. El resto de entrevistas las llevé a cabo a través de Skype u otros sistemas de videoconferencia.

Usé una pizarra blanca para anotar en principio algunos datos de los procesos de selección y tener siempre presente con cada empresa en qué momento estaba de cada proceso. Cuando alguna empresa me decía que no o yo decidía no ir a trabajar con ellos por cualquier entonces quitaba la opción de la pizarra.

Los datos que reseñaba siempre:

• Nombre de la empresa
• Persona con quien suelo hablar o quien me consiguió el contacto de la empresa.
• Salario base o rango salarial en negociación.
• Lugar donde trabajaría o de donde es la empresa y si deja trabajar en remoto o no.
• Barra de progreso. Esta barra la dividía en segmentos teniendo en cuenta los pasos de cada empresa para cumplir con el proceso.

Después lo fui evolucionando hasta llegar a un modelo en hoja de cálculo como se ve en la siguiente captura:

He eliminado el nombre de la empresa y el sueldo real usando el sistema de plátanos de David Bonilla.

Normalmente los procesos de selección tenían los siguientes pasos:

• Puesta en contacto. Donde normalmente hablaba con alguien de recursos humanos para contar un poco a qué se dedica la empresa, la cultura que tienen, el volumen de negocio y hablar sobre el puesto de trabajo, responsabilidades, requisitos y rango salarial. Si todo va bien se puede profundizar un poco más en beneficios del puesto de trabajo, detalles específicos como si hay posibilidad de trabajo en remoto algunos días, días de comida en equipo, clubs sociales o deportivos, gym o cualquier otro detalle a resaltar. Cabe destacar que hay empresas que también hacen algunos tests en este nivel como el test Belbin. Aunque es diferente a Belbin, hace tiempo escribí algo sobre Afinidad y Perfiles que puede ser de ayuda para ver cómo los recursos humanos validan o pueden validar si la persona puede ser buena para el equipo o no. En este caso fui rechazado en un par de compañías por ser la oferta muy baja con respecto a mis expectativas o por tener un perfil diferente al requerido.
• Entrevista técnica. Es la primera entrevista con el equipo técnico. En esta entrevista normalmente hay un pequeño interrogatorio para saber si la persona tiene los conocimientos técnicos suficientes. Teóricamente. No solo se comprueba esto sino también el nivel de afinidad con esta nueva persona. Hay que tener presente que es la primera vez que se conoce a quien será un futuro compañero de trabajo, si durante la entrevista no se tiene una buena sensación o existe incomodidad quien contrata puede rechazar a la persona entrevistada o incluso la persona entrevistada puede rechazar trabajar con ese equipo si no siente afinidad con ellos. En este caso fui rechazado en este nivel en varias ocasiones también por mi nivel de inglés y/o no tener conocimientos acordes a lo que se buscaba principalmente. Por mi parte solo rechacé a una de estas empresas pasada esta entrevista.
• Prueba técnica. Que puedas responder teóricamente a las respuestas no es suficiente. Tal y como habrás podido observar en el enlace de más arriba sobre las pruebas que he completado a lo largo de los años para algunas empresas se busca también que seas capaz de completar una tarea dada en un tiempo específico. En este año puedo decir que pude completar todas las tareas que se me pidieron salvo en una ocasión. El test me resultó muy desordenado y consideré que si los requisitos eran así seguramente el trabajo diario sería también de la misma forma. Preferí no seguir con el proceso.
• Reunión con el equipo: esta es la última fase en la que normalmente se pasa a conocer al equipo. Puede requerirse un viaje a las oficinas para tener una inmersión completa. En este punto realmente ya no existe mucho peligro de ser descartado. De hecho este punto es previo a obtener la oferta definitiva por parte de la empresa. Este es el punto donde toca ser más preciso y fuerte en la negociación para conseguir lo que se desea y como se desea. Es importante estar cómodo con todos los puntos acordados y mostrar desacuerdo o conformidad para poder renegociar los términos.
• Obtención de oferta: ellos ya han mostrado su interés y obtienes una oferta por su parte. En este punto es cuando te dan unos días para que te decidas si aceptas los términos y por ende firmas la oferta y te preparas para el día de inicio de trabajo.

Como puedes ver en la tabla superior llegué al fin del camino 4 de 14 veces. Este ratio es muy elevado. Recuerdo hace años que mis estadísticas estaban más o menos de 1 a 10. Considero que la mejora no solo viene por haber ganado mucha más experiencia sino también por saber a qué puertas llamar. También es verdad que haber hecho tantas entrevistas de trabajo en ambos lados ayuda. Comenté hace tiempo algo similar en recursos humanos con garantía.

Voy a desgranar cada uno de los puntos anteriores intentando dar un poco más de información.

Puesta en Contacto

En primer lugar, al comenzar a buscar trabajo tiré de mi lista de contactos. Como mi experiencia gira en torno a Erlang y Elixir principalmente me puse en contacto con Hayden Evans. Un recruiter especializado en este sector. Hay cientos de recruiters especializados según en qué tecnologías o lenguajes específicos. Si quieres buscar trabajo dentro de un sector concreto puedes buscar a una empresa de recruiting adaptada al sector donde te muevas más.

También hablé con conocidos y amigos en LinkedIn los cuales fueron de gran ayuda dándome reseñas y contactos. Las fuentes por tanto para conseguir los contactos de las empresas que buscaban perfiles fueron:

• Recruiters: 6 ofertas (la mitad) vinieron a través de este método. Dada mi experiencia es normal que cuando un recruiter busca trabajadores disponibles con experiencia en Erlang mi perfil salga de los primeros. No obstante tengo que decir que hubo otros recruiters de Java, Ruby on Rails, Python y otros lenguajes que también me hicieron ofertas. No obstante como no se adecuaban al perfil de ofertas que estaba buscando las descarté. Solo acepté una de Go y Rust porque me resultó un proyecto muy interesante.
• Empresas directamente a través de LinkedIn: 1 oferta llegó por este método. Hay empresas cuyos empresarios directamente buscan ellos mismos al personal. En este caso la empresa era muy pequeña estaba comenzando y es normal que buscase el propio empresario.
• Búsqueda a través de LinkedIn: 3 ofertas fueron fruto de búsquedas a través de mi red de contactos de LinkedIn y la sección de empleos. Cuando buscas trabajo echar un vistazo de dónde trabajan contactos afines con puestos de trabajo similares o empresas similares o usando la misma tecnología puede ser de gran ayuda y sobretodo si al ver sus páginas, en la sección de trabajos hay puestos disponibles.
• A través de amigos: 2 ofertas llegaron a través de amigos. Personas con las que ya había trabajado en el pasado y que me comentaron que en sus empresas se buscaba un perfil como el mío. Tengo que agradecer a todos ellos la oportunidad que me brindaron y que desgraciadamente por un motivo u otro no fue posible trabajar con ellos.
• Meetups, Slack o comunidades: 2 ofertas llegaron por estos métodos. Uno a través del Slack de Elixir y otra a través del Meetup de Elixir de Amsterdam. Es importante estar en contacto con comunidades donde no solo se aprendan nuevos conocimientos sino también podamos darnos a conocer y tener contacto con empresas interesadas en esas mismas tecnologías.

Lo más importante es no quedarse quieto. Puedes enfocarte y buscar teniendo en cuenta los siguientes parámetros:

• Buscar empleo en empresas donde quieras trabajar. Dada nuestra experiencia y nuestro sector podemos ver siempre que hay empresas donde querríamos trabajar por un motivo u otro. En el caso tecnológico por ejemplo hay muchos cuya meta es poder trabajar en sitios como Facebook o Google por ser empresas punteras en el sector tecnológico. Pero también hay otros que preferirían trabajar en Rovio o Supercell como principales exponentes de videojuegos móviles. Lo ideal es buscar la empresa o el tipo de empresa en el que te gustaría trabajar y entonces ir a sus webs y buscar ofertas de trabajo que puedan tener.
• Buscar empleo en el sector donde quieras trabajar. Muchas veces la empresa no es importante. Hay quien quiere trabajar específicamente en el sector de los videojuegos, o en el sector financiero. Hay quienes prefieren trabajar con nuevas tecnologías como blockchain o chatbots. En este caso lo ideal es buscar las ofertas basadas en los requisitos a cumplir por las empresas y el tipo de trabajo a desempeñar.
• Buscar empleo al nivel y/o salario que quieras conseguir. Sí, es más mundano pero hay veces que cuando una persona cambia de trabajo es porque sus necesidades económicas cambian y necesita un nuevo trabajo que le ayude a cubrirlas. En este caso no es tanto qué empresa sea o qué sector sea sino lo que puedan ofrecer. Hay páginas como Experteer que se basan en esto mismo: buscar trabajo muy bien remunerado y en posiciones de alta responsabilidad.

Por último podría reseñar otras fuentes donde puedes encontrar buenos puestos de trabajo dentro de España o que permiten trabajo en remoto como es Manfred.

Requisitos y Responsabilidades

Ten en cuenta cuando estés en la puesta en contacto con los Recursos Humanos de la empresa con la que estés hablando que debes cumplir con unos requisitos. Normalmente estos requisitos están escritos en la oferta pero hay otros que puede que nadie diga y que es necesario tener estos días:

• Inglés: las ofertas que he atendido en Barcelona ha sido con empresas donde el idioma de trabajo es inglés. Obviamente en el resto de empresas el idioma también era inglés. Hay pocas empresas donde el sueldo a percibir sea alto y no se requiera inglés como idioma de trabajo. Si tienes un nivel bajo/medio te recomiendo que sea lo primero a mejorar para mejorar en tu carrera profesional.
• Metodologías Ágiles: no hablo solo de conocerlas sino de trabajar en base a estas metodologías. Es importante saber cómo funciona sobretodo Scrum. En estos días todos los equipos de trabajo en mayor o menor medida emplean alguna de estas metodologías y Scrum es el preferido. Saber cómo trabajar con esta metodología ya allana mucho el terreno y te da muchos puntos extra. Te recomiendo hacer la certificación Scrum que es gratuita y te da todos los elementos para conocer esta forma de trabajar. También será buena idea conocer otros conceptos como TDD.
• Control de Versiones: cuando trabajamos con código y en equipo debemos conocer sistemas de control de versiones. El más empleado es git seguido de mercurial. Hay otras empresas más antiguas que aún emplean otros como subversion ante los cuales sería buena idea recomendarles el uso de los otros dos en su lugar.

En caso de ser programador agregaría también saber más de un lenguaje de programación. Hay otros casos más concretos donde tener conocimientos de devops siendo programador de backend es buena idea. Al igual que tener conocimientos de UX para los desarrolladores de frontend o aplicaciones móviles.

Las responsabilidades dependerán del puesto. Un desarrollador/programador no tendrá más responsabilidades más allá de desarrollar basado en las mejores prácticas, realizar pruebas y entregar a tiempo los desarrollos pedidos. Un desarrollador/programador senior tendrá además como responsabilidades ayudar en la infraestructura, la supervisión de otros perfiles junior y algunas tareas administrativas y de más alto nivel. Lo más importante es saber que si el puesto es en remoto se debe hacer hincapié en la responsabilidad y proactividad para trabajar por tu cuenta.

Entrevista técnica

La toma de contacto con el equipo técnico. Esta reunión es para obtener información acerca de qué sabes hacer realmente, cuales son tus aptitudes y tu actitud y obtener una primera impresión. Como dije antes el equipo no solo evalúa tus conocimientos acorde al trabajo que ellos realizan y lo rápido que podrías sumarte de forma productiva al equipo sino también cómo sería trabajar contigo.

Una de las empresas que me entrevistó separó esta entrevista en tres partes. Una primera charla con dos personas de un equipo a través de Skype. Una prueba técnica donde una persona se mantenía en contacto conmigo 100% del tiempo a través de Skype y compartíamos la sesión online de VS Code de modo que tanto él como yo podías ir desarrollando la solución a un problema planteado. Por último tuve otra última entrevista con otras dos personas que dirigían al equipo. Obviamente todo se basaba no solo en los conocimientos que tenía, sino también en cómo era trabajar conmigo.

En otra reunión que tuve que realizar en Londres la entrevista técnica pasó rápidamente de qué sabes a realizar una serie de medidas de complejidad de algoritmos en una pizarra blanca que teníamos en la sala. Como nota, si vas a presentarte a una empresa donde se realice machine learning de verdad, ten presente hacer un buen repaso de los órdenes de complejidad y los algoritmos básicos para tenerlos bien frescos. Son muy importantes para ellos.

Como media podría decir que las preguntas se basan siempre en mencionar la experiencia que tengas respecto de la tecnología que ellos emplean. Comentes cosas importantes que realizaste con esas tecnologías y qué has hecho o qué sabes hacer con esas tecnologías.

Es importante haber revisado qué tecnologías emplean y en caso de no haber tenido experiencia con algo intentar practicar un poco y construir algo en el tiempo que tengas disponible antes de esa reunión para poder aprender lo máximo posible. En caso de ser algo como un framework web, intentar montar algo simple y ponerlo a disposición en github e incluso en algún servidor para poder mostrarlo en esta reunión. Te dará puntos por iniciativa y proactividad.

Prueba técnica

En el caso anterior hubo momentos en el que la entrevista técnica se mezclaba con la prueba técnica. En estos casos es porque hacían la prueba en papel o de forma presencial directamente en la oficina (como me pasó en Londres y Barcelona con dos empresas diferentes) o en remoto (con otra empresa de Londres a través de Skype y VS Code).

No obstante, lo normal es recibir una prueba ya sea a través de un PDF, un texto dentro de un email o incluso un repositorio en github u otro sistema de control de versiones que consista en realizar las modificaciones requeridas en el ejercicio.

En estos casos es importante escribir código de forma correcta:

• Cuidando tu estilo. Si ellos escribieron algo de código previamente tendrás los lineamentos básicos de cómo desarrollan ellos el código y te puede servir de ejemplo para continuar la prueba con ese mismo estilo. Si no hubiese código escrito por su parte lo ideal será escribir código en el estilo típico del lenguaje o framework que se emplee.
• Usa nombres claros: Bautiza con cuidado los objetos, las funciones, las variables, las constantes e incluso los nombres de los ficheros. Todo debe ser claro. Obvio. Que sea muy fácil de leer para los compañeros a los que le toque revisar tu código.
• Elige bien los algoritmos: A la hora de realizar el código eligen bien las estructuras de datos, los algoritmos que vas a emplear e intenta cumplir siempre con lo pedido, ni más ni menos. Si haces más de lo que se pide podrías estar sobre-desarrollando (overengineering*) lo cual está muy mal visto en entornos ágiles.
• Haz pruebas: Las metodologías ágiles implican la realización de pruebas. Aunque la mayoría de tests no requieren que hagas pruebas siempre está bien agregarlas. De esta forma también se le dará a los empleadores una forma de comprobar que el código entregado cumple con el objetivo. Quizás la realización de pruebas dé más información acerca de lo que sabes y lo que no sabes por lo que debes hacerlas de forma muy cuidadosa y siguiendo los estándares del lenguaje/framework.

Las pruebas además suelen tener una fecha límite de entrega. He llegado a hacer pruebas con límite de una semana y otras con límite de 2 horas. La argumentación para las pruebas de tiempo muy limitado se basan en medir cómo desarrollas bajo presión. Esto puede ser una buena idea pero tener presente esto en una prueba técnica y basar la prueba técnica en este hecho da muy mala impresión de la empresa. Dan a entender que trabajar bajo presión pueda ser algo frecuente y muy importante.

El motivo por el que decidí rechazar una de las ofertas de trabajo fue precisamente porque la prueba no tenía unos requisitos claros. Había partes de los requisitos que chocaban con otros y todo el planteamiento para la realización de la prueba estaba tan abierto que se podía resolver de más de mil maneras posibles, pero igualmente esas mil maneras podían ser erróneas por la cantidad de ambigüedad introducida en los planteamientos. Si piensas que la prueba debe ser algo genérico, ligado a la empresa de alguna forma y que permita dar una idea de cómo se resuelve un problema en la forma que podría solicitarse una vez estés trabajando con ellos, hace pensar que el planteamiento del trabajo real podría también contener esa misma cantidad de ambigüedades, lo cual conduciría a muchas reuniones para intentar clarificar qué hacer exactamente teniendo que entender y desgranar poco a poco la información recibida. No quise entrar en ese tipo de trabajo otra vez.

Reunión con el equipo

Esta es la última fase. Suele ser una reunión para hablar de cómo fue la prueba técnica y acordar el resto de condiciones de trabajo. Acorde a cómo vieron ellos tus destrezas y si el trabajo tenía un rango salarial podrán cuantificar si te ofrecen el mínimo o el máximo acorde a lo mal o bien que lo hayas hecho.

En mi caso hubo momentos que quisieron bajar el valor de la oferta por mi nivel de inglés. Otras veces por no tener suficiente soltura en ciertos aspectos de su negocio.

Pero también tuve la suerte de encontrar otras ofertas donde incluso elevaron el precio del máximo para motivar a elegirlos frente a otras ofertas que tenía.

Recuerda que las ofertas son públicas, es decir, no existe una necesidad de confidencialidad entre empresa y empleado. Por mi parte podría incluso publicar cada oferta de trabajo recibida aquí y no tendría ningún problema legal. No obstante, como muchas empresas son celosas de este tipo de información y no quiero crearme enemigos innecesariamente prefiero eliminar los nombres de las empresas para que no se sientan eludidos y el salario negociado por plátanos para referenciar cómo fue la oferta con respecto al mercado laboral.

Una vez termina esta reunión o esta fase ya solo queda recibir la oferta por escrito.

Obtener la oferta

La oferta es un documento que obliga a la empresa a mantener las condiciones pactadas y acordadas en el papel hasta el momento de la firma de contrato. Es una garantía para el candidato. Pero tanto la empresa como el candidato pueden echarse atrás.

De hecho tengo que reconocer, de forma vergonzosa, que en esta ocasión me eché atrás en dos ofertas firmadas. No es lo que suelo hacer porque normalmente termino los procesos de selección en el momento que una buena oferta me llega y me decido por ella. Pero en esta ocasión un proceso que se demoró mucho terminó en una oferta mejor que llegó al poco tiempo de haber firmado otra de las ofertas y lo mismo ocurrió más tarde. Sin embargo, después de romper la segunda oferta la empresa mejoró las condiciones y entonces volví a firmar su nueva oferta. No hay mal que por bien no venga.

Las ofertas tienen un tiempo limitado. Tienes que tenerlo en cuenta cuando estes en varios procesos de selección. Intenta mantener una fecha límite y hazlo saber a todas las empresas con las que tengas procesos de selección abiertos. De esta forma cuando llegue el momento tendrás todas las ofertas y podrás tomar la decisión.

La toma de decisiones es algo muy personal. En mi caso como cada oferta está ligada a un sitio de trabajo completamente diferente (Estocolmo, Madrid, Barcelona, Londres, Berlin, ...), es un factor más a tener en cuenta. Una vez consigas decidirte primero deniega las otras y cuando no haya posibilidad de contra-oferta por parte de ellas entonces firma por la que optaste y entrega.

Conclusiones

Esta visión está alineada a mi forma de proceder con este tipo de tareas. Quizás tu forma sea diferente e incluso mejor para afrontar un cambio de trabajo. En mi forma he ido detectando con el tiempo muchos problemas que he intentado solventar y finalmente estoy bastante contento con la forma. Sin embargo preferiría no tener que emplear este sistema de forma tan frecuente. Esa fue otra de mis variables en este nuevo proceso, el tiempo que podría mantenerme en este puesto o empresa. Considero que esta vez avanzaré más y de forma más positiva en mi carrera.

¿Tú te ves sometido/a de forma frecuente a estos cambios? ¿Sigues algún proceso? ¿Algún recruiter en tu agenda marcado como contacto prioritario? ¡Déjanos tu comentario!