Seguramente un tema anterior a este sería:
¿Será tu primera entrevista como desarrollador?
Pero creo que puede variar la forma en la que entrevistan de empresa a empresa, es muy común que en una empresa latinoamericana de desarrollo se enfoquen más en una entrevista "platicada" con algunos ejercicios, veamos, las podría segmentar de la siguiente manera:
Preguntas de tu experiencia y conocimiento de frameworks, estas entrevistas pueden tener preguntas muy abiertas y, que si no tienes la suficiente experiencia, serán complicadas de responder ya que no es una respuesta sesgada pero creo que desde mi perspectiva, estas son las entrevistas más sencillas de pasar.
Preguntas técnicas y ejercicios o "code smell exercises", aquí las preguntas técnicas van acompañadas de fragmentos de código como: "¿qué imprime el siguiente ejemplo de código?", "¿identificas algún error, señálalo?", etc.; y en ocasiones te piden que modifiques ciertas cosas en un editor colaborativo, al final tampoco son entrevistas complicadas de pasar pero ya requieren un mayor conocimiento del lenguaje para el que estás siendo entrevistado.
Ejercicios para la solución de problemas AKA algoritmos con revisión de complejidad para saber la forma en la que abstraes dicho problema, etc.; acompañado de preguntas técnicas y muchos ejercicios relacionados a programación y solución de problemas; desde mi perspectiva, las entrevistas más complicadas ya que, a pesar de que algunas cosas parezcan simples los evaluados siempre están esperando la respuesta o solución más óptima.
En algunas empresas te hacen pasar por varias entrevistas con diferentes perfiles para después, al final, dar su veredicto.
Retomando...
Pero bueno, eso es hablando de entrevistas, ahora bien, será tu primer trabajo como desarrollador y recién vienes saliendo de la universidad entonces te daré estos puntos para que, si los haces, espero comiences a evitarlos:
Los chicos con menos experiencia son los que menos leen las instrucciones, los logs, el verbose de la terminal, los errores del IDE, etc. Créanme que no estoy mintiendo cuando les digo que no leen, la gran mayoría de los errores o problemas se resolverían si leyéramos correctamente TODO lo que tenemos a nuestra disposición, es cuestión de prestar atención y leer. Haciendo esto, más del 80% de lo que crees que es un problema, realmente no lo sería.
El problema más grande no es codear tus actividades, el problema realmente es calcular el tiempo que te vas a tardar en terminar dichas actividades; aquí es donde muchos nos atoramos cuando vamos iniciando en un equipo que es controlado mediante metodologías ágiles; es necesario que te acerques a tu equipo de trabajo y entiendas la velocidad y la capacidad del mismo para que así puedas calcular tus propias medidas; ¡sí! Tu propio velocity y capacity. Nunca estimes a ojo de buen cubero, siéntate, analiza el problema, acércate a tus compañeros y solicita otras opiniones de como crees que sería una buena solución, no sin antes presentar TU solución; tampoco caigas en ese error clásico de quererse ahorrar tiempo preguntando casi casi la solución al problema, así créeme que jamás aprenderás de forma correcta.
Querer entender TODO el proyecto cuando, por lo regular, sólo se está a cargo de unos flujos del mismo. ¡No es necesario conocer TODAS y cada uno de los archivos del proyecto!, inicia conociendo lo que te corresponde y, con el paso del tiempo irás soltándote más y conociendo más cosas del proyecto, si lo quieres hacer desde un inicio te vas a frustrar y, sobre todo, asustar.
Siempre pregunta, mantente curioso, aprende, no te quedes callado; algo que es súper vital para un desarrollador que va iniciando es que no crea que por preguntar o por no poder resolver algo se le va a regañar, o simplemente el miedo latente a perder el trabajo que acabas de conseguir. Te sugiero mantengas la calma y solicites ayuda cuando ya no puedas avanzar (obviamente agota tus opciones, ya sabes, guglea', stackoverflowea', revisa la documentación, etc.), es muy importante la persona que sabe solicitar ayuda para evitar que un feature, bug, o lo que le hayan asignado se finalice.
¿Cometes alguno de estos puntos que recién mencioné? Es común, no te preocupes mejor ocúpate en evitarlos, tampoco olvides que si eres un desarrollador experimentado es muy importante que le ayudes a los chicos que recién van iniciando, tú también pasaste por ahí y seguramente no estuvo chido cuando no te ayudaron.
Ya sabes, deja un comentario si estás de acuerdo o tienes más puntos que, es muy probable, dejé pasar; me ayudará a enriquecer este post para el resto de l@s chic@s que lo lean.
🤓