A lo largo de mi carrera profesional he entrevistado a tantos candidatos que he llegado a identificar ciertos patrones habituales. Obviamente, lo que voy a compartir es mi percepción personal, pero si eres desarrollador, seguro que te ayuda a destacar en tu próxima entrevista.

Tipos de entrevistas

Antes de nada habría que aclarar que en el mundo del software hay al menos 2 tipos de entrevistas que suele incorporar cualquier proceso:

• Las de entender el perfil y encaje cultural
• Y las técnicas

Las primeras las suelen llevar a cabo el recruiter y/o el manager del departamento ligado al puesto, mientras que las segundas las dirigen principalmente desarrolladores seniors o Team Leads. Tienen objetivos y enfoques distintos, así que voy a comentarlas por separado.

Entrevistas de perfil y encaje cultural

Objetivo

El objetivo de este tipo de entrevista es validar que (a priori), tu perfil encaja con lo que está buscando la compañía. No solo me refiero a si eres junior, mid, o senior, si no también a tu personalidad.

Formato

Suele ser literalmente una entrevista -presencial o telemática- en la que el entrevistador van haciendo preguntas y tú respondes. Eso no significa que tú no puedas hacer también preguntas. De hecho, es recomendable.

Como pasar de fase

Si estás aplicando a una posición que cuadra con tu nivel técnico, esa parte debería ser fácil de pasar: Suelen ser preguntas genéricas sobre tecnologías con las que has trabajado, proyectos, experiencias, etc.

Encajar con la personalidad que buscan, en cambio, es algo que no solo depende de ti, sino también de las necesidades que tenga la empresa en ese momento.

Las empresas que valen la pena suelen tener una tasa de rotación más baja que el resto del sector. Su objetivo no es solo encontrar talento, sino cuidarlo para conseguir retenerlo a largo plazo. Por eso, el encaje de tus valores y personalidad con su cultura de empresa será crítico a la hora de que pases o no a la siguiente fase.

Las famosas «cárnicas»… ese es otro mundo. Por norma general no les preocupa el largo plazo, así que la personalidad que busquen dependerá del proyecto y el momento. Eso si, probablemente con tendencia al esclavismo. Mi recomendación es que te alejes de ellas como de la peste 🙂

Las empresas que valen la pena suelen tener una tasa de rotación más baja que el resto del sector. Su objetivo no es solo encontrar talento, sino cuidarlo para conseguir retenerlo a largo plazo.

Mis sugerencias

Pocos consejos puedo darte respecto a esta entrevista, pero ahí van algunas sugerencias:

• Sé tú mismo/a: Si en la entrevista no se dan cuenta de que tu perfil no encaja, al final las discrepancias saldrán igual a la hora de trabajar, no tiene sentido complicarte así la vida.

• Infórmate sobre la empresa: Ir a una entrevista sin tener claro a qué se dedican es una clara señal de desinterés. Estas cosas se notan.

• Demuestra interés: Ligado con el punto anterior. Estas entrevistas suelen darte margen para hacer preguntas sobre la compañía. Su stack tecnológico, el tamaño del equipo, el proyecto en el que entrarías, sus metodologías… son cosas que seguramente querrías saber si vas a trabajar con ellos. El hecho de que no preguntes sobre estos temas, de nuevo, es otra señal de desinterés.

• Conócete a ti mismo/a: Puede ser que te pregunten directamente acerca de tu personalidad. Esto le encanta a la gente de RRHH, pero hasta yo lo he utilizado para intentar entender si va a haber encaje del candidato. Responder a este tipo de preguntas en vez de quedarse bloqueado suele ser un plus.

• Rompe el tabú salarial: Habrá quien discrepe, pero para mí es muy claro. Desde mi punto de vista, ANTES incluso de esta entrevista ya deberías tener claro si va a haber un encaje salarial. Pero si no lo tienes, es el momento de preguntarlo. OJO, no te estoy diciendo que negocies aquí el sueldo. Pero si deberías preguntarles sobre el «rango salarial» asociado a la posición, no vaya a ser que estéis perdiendo el tiempo mutuamente. De hecho, es habitual que aquí sean ellos los que te pregunten por tu salario actual o deseado. Al final viene a ser lo mismo, si ellos no ven encaje, también te lo dirán.

Entrevistas técnicas

Objetivo

En esta entrevista se supone que habéis aclarado verbalmente cual es tu nivel, pero es el momento de validarlo. Arremángate porque toca programar.

Formato

El formato varía mucho en función de la empresa. Hay desde sesiones tipo pair-programming en las que tienes que resolver un problema sencillo, a pruebas que te envían por e-mail para que completes en una semana, pasando por la resolución de algoritmos complejos en una pizarra, o «exámenes» a resolver con papel y boli.

Cuando te invitan a una de estas entrevistas, suelen darte ya indicaciones, pero si no, siempre puedes preguntar los detalles: ¿Cuando durará? ¿Necesito mi portátil / algo instalado? etc. Así de paso te puedes hacer a la idea de lo que te encontrarás e irás más tranquilo a la prueba.

¿Realmente hace falta?

Sé que hay quién no está de acuerdo con hacer entrevistas técnicas. Los argumentos suelen ser del estilo: «Llevo X años programando, a estas alturas no tengo que demostrar nada, etc, etc «

Entiendo el argumento, faltaría más, pero salvo que vengas de Google, Facebook, o alguna otra super-top, tu CV no garantiza gran cosa.

Para mí, una hora de whiteboard complejo no es el proceso de cribado ideal porque depende de tu inspiración en ese momento. Tampoco me parece lógico hacerte currar durante una semana para «demostrar» tu nivel (yo directamente rechazaría una prueba así).

Personalmente me gustan las entrevistas tipo pair programming. Obviamente no es un pair programming real, porque mi objetivo es evaluar al candidato, pero se parece. A diferencia de un examen, aquí la idea es ayudarte si te atascas, preguntarte y entender por qué tomas determinadas decisiones.

Hay varias soluciones y cada empresa elige la que considera más adecuada. En todo caso, es vital contrastar el conocimiento técnico del candidato. Te llevas sorpresas, la verdad: Te encuentras desde el que se ha vendido como un auténtico gurú y luego no sabe ni dar los primeros pasos, hasta el «tapado» que iba como junior y acabas felicitándole y dándole la bienvenida, aún sin haberlo comentado con RRHH.

Cómo pasar de fase

Obviamente el objetivo principal es que tu código resuelva el problema planteado, pero no se trata solo de eso. También suele ser relevante tu forma de desenvolverte: Cómo afrontas el problema, cómo te comunicas, qué haces cuando te bloqueas… Todo esto son pistas de tu personalidad y forma de trabajar. Es información muy valiosa.

De hecho, es importante entender que no siempre hace falta completar la tarea al 100% para pasar la prueba.

• Un pair programming por ejemplo, podría estar diseñado para no completarse en el tiempo proporcionado. Simplemente conforme avanzas, se te van pidiendo más tareas hasta que se acaba el tiempo.
• En un whiteboard por otro lado, sería una buena idea empezar con pseudo-código para diseñar el algoritmo que te piden. Si el algoritmo está bien planteado pero al llevarlo a código real cometes algún error, es probable que sigas adelante en el proceso. Al fin y al cabo, lo que se pretende validar es tu capacidad analítica, no que tu código compile a la primera.

Aún así, hay procesos con un alto volumen de candidatos que se automatizan al máximo. Haces una prueba tú solito mediate una plataforma online y si el código no pasa los tests, estás descartado. Poco consejo te puedo dar aquí, a parte de que tengas mucha suerte 😉

Para el resto de procesos (aquellos en los que interactúas con alguien de la empresa), ahí van mis sugerencias:

Mis sugerencias

• Entiende bien el problema: Esto debería ser el punto 1 al enfrentarte a cualquier problema. ENTENDERLO. Lee bien el enunciado, haz preguntas, plantéalo con otras palabras para que te confirmen que lo has entendido. Si no entiendes lo que te piden… estás fuera.

• Comunícate: De poco sirve tener un compañero de trabajo que funciona mejor aislado y no es capaz de explicar a los demás lo que está haciendo. En estas pruebas también se valida tu potencial para trabajar en equipo. No te cortes: haz preguntas, explica el por qué de tus decisiones, pide orientación si estás estancado. En serio, un candidato que no sepa comunicarse hace saltar todas las alarmas.

• Practica, practica y practica: El principal enemigo del candidato en estas pruebas suele ser el nerviosismo. Si programas a diario no debería ser un problema, pero si no (pongamos que en tu puesto actual dedicas cierto tiempo a management), es mejor ir con cierto rodaje para no quedarte en blanco. Trabajar en un side-project en tu tiempo libre, hacer katas o simplemente dedicar algo de tiempo a hacer code-challenges es suficiente para prepararte.

• Trabaja las bases: Conocer un framework u otro está muy bien, pero lo que es realmente importante es entender el lenguaje que hay debajo. De nada sirve que sepas mucho de Angular o React, si no entiendes los Closures de Javascript. Con los patrones de diseño pasa lo mismo. Antes de mirarte la librería de moda en Twitter o Reddit, asegúrate de que entiendes lo que es un Singleton, una Factoría, un Decorador o una Facade.

• Conoce tu IDE: Hay veces que por motivos que no acabo a comprender, el candidato decide probar un nuevo IDE justo el día de la prueba. ¿Resultado? Media sesión perdida intentando averiguar los shortcuts habituales. Es un terrible error. Si quieres jugar con algo nuevo hazlo en tu tiempo libre, aquí tienes que ser eficiente. Obviamente, solo aplica cuando la prueba la haces en tu propia máquina. Si no, tendrás que adaptarte 🙁

• Prepárate el stack: Una vez tienes trabajadas las bases, siempre puedes ir a por nota. Programar es programar, independientemente del lenguaje, ya. Pero si sabes que te van a pedir un stack concreto que no habías tocado o que tienes algo olvidado, repásatelo. Las bases al menos: conceptos básicos, sintaxis y estructura habitual. Si no lo haces vas a ir mucho más lento y es difícil mostrar algo relevante así, cuando la duración de la prueba es limitada.

Reflexiones personales

No hay dos procesos iguales, pero sí hay una serie de marcadores habituales que se intentan validar durante las entrevistas, como por ejemplo:

• Adecuación a las tareas / conocimiento deseado
• Adecuación al equipo
• Adecuación a la cultura de empresa
• Talento

No puedo darte la clave para que destaques en todos esos puntos, claro está. Hay veces que simplemente y de forma objetiva, no hay match. No pasa nada. Aprende de la experiencia y sigue buscando.

Aún así, si sigues estas sugerencias, al menos mostrarás mejor tu potencial en las entrevistas y no desperdiciarás la oportunidad perfecta debido a una mala preparación.

¿Te ha gustado este artículo? No te cortes, déjame un comentario y ayúdame a compartirlo 😉