Cómo prepararte para las entrevistas de un proceso de Frontend Engineer

Cómo prepararte para las entrevistas de un proceso de Frontend Engineer

Da igual si tienes experiencia o no... tarde o temprano vas a pasar por al menos un proceso de selección si quieres conseguir el trabajo de tus sueños.

Cuando empecé a dar los primeros pasos en mi carrera profesional estuve trabajando para varias empresas de consultoría. Los procesos de selección no eran nada técnicos. Una entrevista personal y poco más. Durante mis cinco primeros años como ingeniero de software cambié tres veces de empresa y nunca me hicieron una entrevista demasiado técnica para entrar en ninguna de ellas.

Durante los seis años siguientes estuve trabajando en Anuntis, que luego pasó a llamarse Schibsted y hoy es Adevinta. Cuando tomé la decisión de empezar a buscar trabajo, el mercado laboral había cambiado. En Barcelona había muchas empresas en fase de start-ups e imitaban los procesos de selección de otras empresas alrededor del mundo. Y me di cuenta de que había estado viviendo en una burbuja.

Experimenté por primera vez la sensación de ser rechazado una y otra vez por las empresas a las que enviaba mi CV. Me preguntaban conceptos que conocía, pero hacía mucho tiempo que no utilizaba y ya no sabía cómo explicarlos. Cosas que no había hecho desde que estaba estudiando, más de diez años atrás.

Superar entrevistas de trabajo es una habilidad que se puede aprender. La mayoría de empresas tienen un proceso similar bastante estándar. Aunque cambien las preguntas de una a otra empresa, el tipo de preguntas suele ser el mismo y se puede practicar para superarlas.

En este artículo te quiero resumir todo lo que aprendí para mejorar mis opciones de superar un proceso de selección de programador Frontend. Espero que te ayude.

Tu CV

Tu Currículum Vitae (CV) o tu perfil en LinkedIn es una de las cosas que puedes empezar a optimizar. Lo primero que tienes que saber, es que nadie se lo va a leer concienzudamente. Las empresas tienen un software que escanea el documento buscando la presencia de palabras clave y su relevancia. Eso hace que pases el primer filtro y le llegue a alguien de recruitment. Así que ahórrate la paja y ve al grano.

Incluye una buena introducción que hable lo mejor posible sobre ti. Siempre recomiendo que tenga un pequeño párrafo con una o dos frases que resuman la siguiente información, en este orden:

  • Quién eres

  • Qué has hecho y dónde

  • Qué te motiva, apasiona…

  • Qué estás buscando en un futuro puesto

Por ejemplo, la mía:

Engineering manager with more than 15+ years of experience developing software products in multiple industries (Marketplaces, Video Games, Healthcare or B2B), in companies that range from established multinationals (Adevinta, King…) to start-ups in hyper-growth stages (Tempus, Typeform or Glovo).

My leadership style is based on promoting a high performance and inclusive engineering culture, which leads to autonomous and upskilled teams that consistently deliver high-quality, innovative customer-centric products that also satisfy business needs.

My passion for building high-performance teams and helping everyone achieve their highest potential led me in 2019 to create my own professional mentoring business, a journey that I have been able to continue and evolve through my management roles ever since.

Always looking for ways to grow, evolve and discover new ways to empower success within organizations and for our customers.

Explica tu experiencia en orden cronológico inverso (más reciente primero) y en pocas palabras. Céntrate en los resultados que tú has conseguido en los proyectos clave en los que hayas trabajado. Evita el “nosotros”. No es el momento de ser humilde. Explica qué has hecho en esos proyectos, ya que quieres que te contraten a ti.

Escribe un par de frases sobre el proyecto y sobre la empresa, para que quien no la conozca sepa de qué estás hablando. Aquí tienes un ejemplo de mi experiencia, que puedes consultar en mi perfil de LinkedIn. Te animo a echarle un vistazo para inspirarte. Está lejos de ser perfecto, pero para que te hagas una idea de lo que hablo:

Si tienes poca experiencia o ninguna, céntrate en los proyectos clave que hayas hecho en la carrera, bootcamp o el curso que hayas hecho para prepararte para ese puesto. Habla de aprendizajes, motivaciones y retos que has superado.

Escríbelo en inglés, por supuesto. Presta atención a la gramática, ortografía y los detalles. Escribe correctamente los nombres propios de empresas, ciudades y tecnologías. Puedes utilizar Grammarly ara corregir la gramática.

Añade las tecnologías que utilizaste en cada experiencia, para subir el peso de las palabras clave y darle relevancia a tu CV. No hace falta ni que formen parte del texto, yo las enumero de esta forma:

Por último, hay herramientas online que puedes utilizar para enviar tu CV y que alguien te lo revise. Una de ellas es TopCV. Tienen una revisión gratuita que te envían a tu correo y no está nada mal. A cambio, te perseguirán durante unos días para que pases por caja para el servicio de pago, pero ya te adelanto que con la revisión gratuita es más que suficiente.

Te dejo esta guía de Glassdoor con muchos más consejos para escribir el mejor CV.

La entrevista técnica

La entrevista técnica se suele hacer para tener una primera impresión de tu nivel. Suele consistir en una batería de preguntas que deberías responder en uno o dos minutos sobre conceptos de HTML, CSS y JavaScript.

En algunas empresas esta prueba es puramente teórica y en otras te hacen escribir algún pequeño fragmento de código o hablar sobre el resultado esperado.

Cada empresa llama a estas pruebas de una manera (pre-screening, technical phone call…) pero el objetivo es descubrir si tienes el nivel suficiente para pasar a la siguiente fase.

Uno de mis recursos favoritos para preparar esta prueba es el repositorio de 123 essential JavaScript questions. Está organizado por preguntas, con su explicación, soluciones, ejemplos y demás.

Otro que está bastante bien, también sobre JavaScript, es el de freeCodeCamp. Un manual que va mucho más al grano, a través de las preguntas que se suelen hacer sobre el lenguaje (type coertion, closures, prototype…).

Por último, el más completo: Front-end interview questions. Además de JavaScript, incluye temas sobre HTML, CSS y algoritmos, con ejemplos y soluciones.

Seguro que puedes encontrar muchos más recursos en la Red para practicar este formato de entrevistas. Piensa que esta fase es teórica y que te van a preguntar cosas que ya sabes hacer, pero que hay que aprender a explicar bien. ¡No queda otra que hincar los codos y estudiar!

Algoritmos y estructuras de datos

Esta es una prueba que no se solía hacer para perfiles de Front-end pero, dado que últimamente son necesarias habilidades de programación sólidas en aplicaciones web, se ha puesto de moda ponernos a prueba resolviendo uno o dos algoritmos durante el proceso de entrevistas. Es una forma de comprobar cómo te enfrentas a un problema y si tienes nociones sobre fundamentos de ingeniería de software.

Bueno, es lo que hay. Hemos venido a jugar.

Es algo que asusta la primera vez que te acercas al tema, sobre todo si no has hecho una ingeniería. Pero también se puede aprender si sabes qué buscar y dónde. Para eso estoy yo aquí.

Para empezar, échale un vistazo al siguiente repositorio de Github: JavaScript Algorithms and Data Structures. Es simplemente brutal. No sólo tiene ejemplos de cada concepto en JS, sino que están clasificados por dificultad e incluyen una buena explicación, con dibujitos y todo.

También tienes a tu disposición libros que te pueden ayudar, si el formato online no te convence. Un clásico es el de Cracking the Coding Interview, de Gayle Laakmann McDowell. Más conocido como “el libro verde de las entrevistas de programación”. Allí te encontrarás casi doscientos problemas que se suelen preguntar en grandes empresas, como Google, Facebook y compañía. Si te gusta el tema, te recomiendo otros dos para aprender a fondo: Introduction to Algorithms y Algorithms.

Ya te adelanto que lo más importante es practicar. Saber identificar el tipo de problema adecuado y qué estructuras de datos son más adecuadas para resolverlo. El mejor sitio para hacerlo es LeetCode.No sólo por su buena interfaz y editor de código online, sino por las explicaciones que acompañan a cada ejercicio.

Si buscas algo más social y con gamificación, también puedes probar con HackerRank y Codewars.

Por último: si comienzas a estudiar algoritmos y estructuras de datos, tarde o temprano te encontrarás con el concepto de Big O. A las personas que entrevistan les encanta preguntar por la notación Big O. Es un conocimiento que prácticamente sólo sirve para pasar entrevistas de este tipo, pero no queda otra que conocerlo. No te preocupes, que no es tan difícil.

El concepto de Big O es una notación matemática para determinar la complejidad de un algoritmo. La complejidad se puede determinar en dos dimensiones: en tiempo y en espacio.

La complejidad en tiempo quiere decir cuánto va a tardar en ejecutarse el algoritmo en función del número de valores de entrada. Por ejemplo: imagina una función que recibe un Array con un número de valores (n) y realiza un cálculo. Si crece el número de valores hace que el tiempo de ejecución también crezca en la misma proporción, la complejidad será lineal O(n). Pero si cada valor nuevo que añadimos al array hace que el tiempo de ejecución se duplique, la complejidad será exponencial: O(n²).

La complejidad en espacio es lo mismo, pero considera el espacio que ocupará en memoria el algoritmo mientras se ejecute, en función del número de parámetros. Por ejemplo: si dentro de la función creas otro Array para ayudarte a calcular el resultado, ¿cuánto espacio ocupa en memoria ese Array en función del número de valores que contiene el Array de entrada?

El amigo YK, del canal de YouTube CS Dojo explica el concepto de Big O notation de maravilla. Mucho mejor que yo. Asegúrate de comprenderlo y de saber identificar la complejidad de tus implementaciones cuando resuelvas algoritmos.

La prueba técnica

A diferencia de la entrevista técnica de la que te hablé anteriormente, la prueba técnica sí que te exigirá programar una pequeña aplicación web con cara y ojos. Aquí puedes encontrarte dos escenarios: que te pidan hacerla en directo (live coding) o que te den tiempo para hacerla tranquilamente en casa y enviarla.

En este caso, no tengo mucho más que añadir a lo que escribí en este artículo hace ya algún tiempo. El contenido sigue vigente, así que permite que me cite a mí mismo:

Si tienes una entrevista para un puesto de programador Frontend, antes practica este ejercicio - Dani de la Cruz

Si no te gusta la API de Pokémon que utilizo en el ejercicio, ya puedes irte por donde has venido

aquí tienes un repositorio de APIs públicas que puedes usar.

Y si llamar a APIs públicas no es lo tuyo o quieres probar con algo muy personalizado, siempre puedes probar con un sencillo servidor de JSON local. Aquí tienes uno que puedes configurar en dos minutos y que también tiene su versión online.

¿Sigues necesitando inspiración? Pues prueba con estos 40 ejercicios propuestos por freeCodeCamp.

Conclusiones

He intentado volcar en este artículo todo lo que tuve que aprender hace seis años cuando empecé a hacer entrevistas para encontrar el trabajo que buscaba como programador Front-end.

Recuerda que cuando empecé a hacer entrevistas, me rechazaban porque no sabía contestar cosas como qué es una closure, cómo funciona el contexto o la cadena de prototipos en JavaScript. Eran cosas que utilizaba, pero que no sabía cómo explicar.

Lo mismo ocurrió cuando empecé a superar esas pruebas y me preguntaban por estructuras de datos, árboles binarios y Big O notation. Se me apagaba la luz.

Pero todos estos conceptos pueden aprenderse. Los que nos dedicamos a esto no somos especiales, sólo hemos invertido nuestro tiempo en estudiar. Yo tuve que hacerlo durante meses. Me llevó casi un año estar preparado para superar un proceso completo. Ten paciencia, constancia y empieza prepararte desde hoy.

¡Ánimo! 💪

Foto de la cabecera de Mimi Thian en Unsplash