Vamos a repasar los aspectos mas relevantes de un proceso de entrevistas en una compañía de IT. Desde el primer contacto hasta la resolución de ejercicios técnicos en vivo, algo que muchos desarrolladores están en contra, ya sea porque se aleja muchísimo de lo que es un trabajo o porque lo que hay que hacer en el día a día no tiene nada que ver con ese ejercicio que su respuesta esta replicada mil veces en internet. Incluso ChatGPT puede resolverlo en menos de 5 minutos.
Pero por otra parte, desde el punto de vista del entrevistador, puede ver nuestra manera de pensar, de comunicarnos, como reaccionamos ante determinada situación y como trabaja nuestra cabeza cuando tiene un problema en frente y si o si hay que resolverlo. O al menos intentarlo.
Comenzamos con algunos pasos:
Contacto
- LinkedIn y referidos. No creo que mandando CV al mail de la página de careers sea una buena opción.
- Agregar RRHH de esas empresas y tener el perfil lo mas atractivo posible (hay mucha info sobre eso). Mi único consejo es investigar sobre la empresa, lenguajes y tecnologías que usa y ver si mi perfil está alineado. Tener paciencia va a ayudar mucho.
- Referidos: bueno, si ya tengo conocidos ahí dentro, pedir que deje nuestro CV por algún programa interno. En caso que no haya, directo a RRHH.
Etapas de la entrevista
- Suelen ser varios pasos, incluso mas de uno para validar lo mismo. El primer screening es 100% cultural y repasar el CV, muchas veces es un trámite [ver apartado de QUE NO HACER].
En este punto podemos preguntarle a nuestro contacto como van a ser las siguientes etapas, eso nos ayuda a prepararnos mejor.
La temida "técnica"
Las entrevistas técnicas son todo un reto, pueden dividirse de varias formas, las mas comunes suelen ser primero un ping pong de preguntas y 45 minutos con algún ejercicio de programación en vivo o un diseño a alto nivel de una big tech, por ej Uber/Twitter/YouTube/gateway de pago. No se espera que sea un detalle exacto ni mucho menos, pero si lo actores principales, como escalar, modelos de datos correctos, separación de intereses y demás. Hay material sobre diseño en entrevistas, pero NADA supera la experiencia.
-
Los ejercicios de desarrollo, son los que vemos en HackerRank, Leetcode y similares. Muchas veces son textual extraídos de esos sitios. Esa práctica es clave para el una resolución rápida y efectiva. Muchas veces, no buscan que el algoritmo resuelva el 100% de los casos o que este optimizado. Pero si de buscar la mejor complejidad temporal (Big O) y que cumpla al menos los test cases de ejemplo.
- Duración: Largas, entre 1 y 2 horas seguro. Mantener agenda limpia esa mañana o tarde.
Estudiar/Prepararse
- Conocer bien su CV, tecnologías que manejan, proyectos trabajados, challenges resueltos, como manejar ciertas situaciones, por ejemplo, no cumplir un deadline, un compañero “rompe” el CI el viernes a las 17.50, y cosas parecidas. Repasar experiencias y armar una buena narrativa ayuda y mucho.
- Algoritmos y estructuras de datos. Practicar mucho, leer códigos con soluciones. Fundamental vero soluciones reales, en GitHub hay infinidad de snippets en todos los lenguajes y con muchos enfoques. Cuando nos trabamos con algo, tenemos que buscar la solución. No dedicar mas de 1 hora en un problema. Pasado este tiempo, vamos a ver como otros lo resolvieron y re-pensar nuestros errores.
Que no hacer
- Llegar tarde 🕚, siempre calcular al menos 10 min de margen. Tener mic y cámara listos.
- Hablar “mal” de una compañía pasada.
- No estar dispuesto a escuchar o recibir feedback, esto incluso podemos no darnos cuenta, pero los entrevistadores tienen herramientas para detectar estas actitudes y es un NO FIT cultural seguro. Un ejemplo es no dejar hablar al entrevistador.
- No saber a que se dedica la empresa a la que estamos aplicando. Una mínima investigación es necesaria.
- No hacer preguntas. Capaz sea un punto intermedio, pero siempre hacer preguntas sobre la posición a ocupar, metodologías, como están compuestos los equipos, nos va a dar mucho mejor panorama a la hora de decidir. No estoy realmente seguro de que influya negativamente en la entrevista, pero si nos brinda mas información a nosotros.
Conclusiones
Salir bien en las entrevistas es un skill en si mismo, antes de aplicar al trabajo de nuestros sueños, tenemos que estar preparados y saber que nunca nos vamos a sentir seguros por completo, pero eso no nos tiene que impedir tener mucha confianza en nosotros mismos y encarar los procesos. Asi que a prepararse y ser pacientes que tarde o temprano, nuestra oportunidad va a aparecer.
El día de la entrevista, hay que mantenerse tranquilo y repasar mentalmente lo que vamos a decir, ya sea en nuestro idioma o en inglés.
Top comments (3)
Excelente consejos, siempre es todo un tema el de las entrevistas, sobre todo el tema de los code challenger porque después en el día a día uno no realiza ese tipo de ejercicios. O no tiene que recordar como resolver x algoritmo de memoria. (En su momento para practicar challenges yo utilice Codewars, es otra buena opción).
Pero como comentas, es casi una skill diferente el ser bueno para las entrevistas.
Si, yo trato de hacer ejercicios en leetcode regularmente. No te digo todos los dias, pero al menos 2 por semana, te ayuda a mantenerte activo en ese aspecto, pero la realidad con el trabajo es totalmente distinta.
Thanks