Para que una compañía te ofrezca trabajo, tiene que entender cómo vos le vas a poder agregar valor. Si sos junior, lo más probable es que no tengas nada de experiencia, o que tengas muy poca. Entonces, ¿qué valor podés agregarle a la compañía y cómo se lo podés comunicar? Es esencial demostrar que entendés los requerimientos, que podés trabajar de manera independiente y que sabés cuándo pedir ayuda. También es importante que sepas usar las herramientas básicas y que tengas un conocimiento sólido del lenguaje en el que querés desarrollarte. Además, escuchar y aplicar los comentarios de compañeros y mentores es fundamental. Debés seguir las mejores prácticas de la empresa, como linters, pruebas unitarias y gitflow, y comprender la importancia del testing, asegurándote de que tu código funcione antes de marcarlo como "listo para probar". Al arreglar bugs, es crucial entender toda la lógica del código para evitar romper algo. Finalmente, aprender sobre herramientas y tecnologías que no son tu responsabilidad directa te permitirá tener una visión completa del sistema.
1. Demostrar que podés entender requerimientos
Como desarrollador junior, no tenés mucha experiencia profesional, y está bien que no la tengas. Ahora, lo importante para la empresa, aunque no tengas experiencia profesional, es que sepas demostrar que podés entender un requerimiento, un pedido para hacer una funcionalidad, para resolver un bug, un error, para poder realizar una tarea. Aplica lo mismo para cualquier otro tipo de trabajo.
Si tu jefe o un compañero de trabajo te pide algo, es importante que puedas entender qué se te pidió para que puedas ejecutar. Si vos empezás no teniendo claridad en qué significa el requerimiento que te pidieron, probablemente no vas a poder desenvolverte bien más adelante.
“Pero no tengo experiencia, ¿cómo voy a hacer para saber si entiendo los requerimientos? ¿Como hago para demostrar que yo sé entender requerimientos?”
Podés dar ejemplos de proyectos que hayas realizado por tu propia cuenta, donde el requerimiento estaba dado en el curso, la tarea, el ejercicio. Te recomiendo explicar cómo interpretaste el requerimiento, cómo lo implementaste, e incluso también que hagas una retrospectiva y expliques a qué conclusión llegaste, por ejemplo: “me di cuenta que había malinterpretado el requerimiento.”
Otra cosa que podés hacer es hablar con otras personas que están en ese puesto de trabajo, y preguntarles cuáles son los requerimientos que más les pidieron durante los primeros seis meses de trabajo.
Al final, un requerimiento es una tarea que uno tiene que ejecutar, puede venir por un ticket creado en un Github, en un Jira. Entender cómo son los requerimientos, los pedidos de trabajo.
Si uno hace una investigación hablando con un montón de otros desarrolladores junior y va preguntando “¿cómo se hace el pedido de requerimientos en tu compañía?, ¿cómo hacés para preguntar si no entendiste?, ¿Cómo te organizas?”, empezás a obtener un montón de información, entonces, el día de mañana, cuando vas a una entrevista, podés estar mejor preparado para poder hablar de la importancia de un requerimiento y los problemas que puede traer trabajar en un requerimiento que uno no terminó de entender bien.
2. Demostrar que podés trabajar por tu cuenta
Poder trabajar por tu cuenta significa que te dan el requerimiento, lo entendés, y tenés autonomía para poder resolver eso. Significa que tenés cierta autonomía de trabajo.
Obviamente uno va a tener preguntas. Ahora acá lo importante es decir bueno, voy a Google, veo que puedo encontrar, voy a Stack Overflow y veo qué puedo encontrar, leo documentación, analizo un poco el sistema. Tratar de encontrar patrones en común. Tratar de tener cierta autonomía a la hora de trabajar. Poder avanzar y tratar de resolver cosas utilizando herramientas como Stack Overflow, Google, documentación que haya en la empresa, y demás. Eso significa trabajar por tu cuenta.
Ahora vuelvo al punto número 1: cuando te dan un requerimiento, ese es un buen momento para preguntar “hay documentación? ¿Hay algún tipo de herramienta dentro de la compañía que me pueda llegar a ayudar a cumplir con este requerimiento?”
3. Demostrar que sabés cuándo pedir ayuda
Si no podés avanzar, tenés que pedir ayuda. No está bueno que de repente te pases dos horas tratando de resolver todo por tu cuenta yendo a Stack Overflow, Github, Google, leyendo documentación, si quizás a los 15 minutos le podés preguntar a alguien que te da la respuesta. Preguntando avanzás sin perder dos horas de tu tiempo.
Si no podés avanzar, pedí ayuda. Empezar a entender cómo manejar los tiempos. No te quedes dos horas tratando de resolver algo, porque esas dos horas son muy valiosas. Si no sabés por donde arrancar, no tengas vergüenza ni miedo, pedí ayuda.
La gente va a preferir a que pidas ayuda y se pueda avanzar, a que no pidas ayuda y no se avance.
Acordate de esto: lo que estás haciendo es parte de un eslabón para lograr un resultado final, por más que tu tarea sea chica cuando sos junior, no deja de ser parte de ese eslabón a la hora de completar un trabajo, asi que ni no podés avanzar, podés llegar a estar atrasando al resto del equipo. Preguntar no está mal. Podés organizarte para hacer todas las preguntas juntas. Siempre es preferible preguntar y poder avanzar.
4. Aprender a usar las herramientas básicas
Aprender a usar las herramientas básicas es algo que podés empezar a hacer antes de empezar a trabajar. En la mayoría de las compañías, esto incluye Git. Es crucial entender para qué sirve Git, ya que es una herramienta fundamental en casi todas las empresas. Conocer a fondo cómo funciona Git no solo te va a ayudar en tus proyectos personales, sino también en proyectos colaborativos con otros compañeros. Esto te va a permitir avanzar más rápido en el trabajo sin tener que preguntar constantemente "¿cómo funciona esto?". Estudiar proactivamente te va a permitir hacer preguntas más específicas y fáciles de responder, lo que va a facilitar tu integración y eficiencia en el equipo.
Preguntar está bien, pero hay preguntas buenas y no tan buenas. Las preguntas mejores y más específicas hacen que sea más fácil responder y ahorran tiempo. Mientras más te involucres en un tema, mejores preguntas vas a poder hacer. Si hacés preguntas específicas, todo fluye mejor. Las preguntas ambiguas o poco claras requieren explicaciones más largas y pueden frustrar a quien las responde. Puede que la otra persona se frustre porque le lleva demasiado tiempo responder. A lo largo del tiempo, esto puede afectar el progreso y las expectativas del equipo. Por eso, es crucial entender los requerimientos y los plazos desde el principio.
5. Demostrar que sabés lo básico del lenguaje en el que querés seguir una carrera, cómo configurar un entorno de desarrollo y usar las herramientas necesarias para trabajar
Estas son cosas que seguramente hayas estudiado y trabajado, pero de vuelta: cuando vas a una entrevista de trabajo, es importante que lo tengas bien fresco.
Cuando te estós preparando para una entrevista sobre algo sobre lo cual no tenés experiencia, y te preguntan algo súper técnico y no lo sabés, puede ser un punto en contra.
6. Discutir con tus compañeros y mentores (y así poder mejorar más rápido)
Esto es algo que me mencionaron distintos desarrolladores como una de las diez mejores virtudes que puede tener un desarrollador junior. Está bien hacer preguntas o aclarar, pero preparate para tener una discusión (en el buen sentido de la palabra). Las respuestas siempre vienen con puntos de vista, opiniones; una persona te dice una cosa, otra persona te dice otra. Es importante tener capacidad de análisis para entender por qué cada uno dice lo que dice.
¿Por qué sirve esto para poder prepararse para una entrevista? Porque es algo que podés hacer incluso hoy con tu proyecto personal: buscar personas a las que les puedas hacer preguntas, y tener una discusión (me refiero a compartir opiniones).
Si tenés un proyecto personal y le hago preguntas a la comunidad (en Discord, Slack, LinkedIn), es algo que después cuando vayas a la entrevista podés compartir y decir “Esto es lo que yo hago, porque si bien es un proyecto personal y trabajo por mi cuenta, discuto con otros profesionales, lo cual me ayuda a aprender, y además a simular estar en un trabajo real. Me estoy preparando para eso.”
7. Demostrar que conocés la importancia de seguir las mejores prácticas establecidas en la empresa
Asegurate de conocer cuales son las mejores prácticas estándares en la empresa en la que querés trabajar. Esto es muy importante para cuando empezás a trabajar, pero también es importante para la entrevista de trabajo:
Por un lado, es una muy buena pregunta que podés hacer en una entrevista (¿cuáles son las mejores prácticas estándares en la empresa?)
Por otro lado, podés mencionar que sabés usar linters, pruebas unitarias, Gitflow.
Y además podés hacer preguntas específicas, como si usan pruebas unitarias o no, cómo usan los linters, etc., y así, estás demostrando que sabés que en cada empresa lo hacen de forma particular, y que te interesa entender cómo es la forma en esa compañía.
El simple hecho de demostrar este conocimiento en una entrevista haciendo esta pregunta, te va a posicionar por encima de los otros graduados que no tienen este conocimiento, y que por ende no pueden hacer este tipo de preguntas.
8. Asegurate de hacer testing y que tu código funcione bien antes de mover la tarea a “listo para probar”
Tener un software funcional es más importante que obtener un resultado rápido o desplegar un error en un entorno de producción. Antes de mover tu tarea a “listo para probar”, asegurate de haberla probado adecuadamente.
Este punto habla de la importancia del testing, de que tu código no tenga errores, de que tu código no pueda romper otra cosa en el sistema.
Aca podés prepararte para hacer preguntas sobre cómo hacen este despliegue en producción, si tienen testers o no, y cómo trabajan con los testers. Asegurate de hacer testing y que tu código funcione bien.
9. Si estás corrigiendo bugs, asegurate de entender toda la lógica, especialmente en bases de código grandes
No querés corregir un bug y romper otras cosas con el arreglo que hiciste. Acá de vuelta: es importante entender todo el código, cómo el trabajo que hacés puede impactar en el sistema.
Cuando sos junior, por lo general tenés una tarea en frente, y como no tenés experiencia, toda tu atención, foco, y energía están en esa tarea, porque es por lo que a vos te van a evaluar. Pero si sabés que esa tarea es sólo el eslabón de una cadena (que es el trabajo de tu equipo), es importante saber hacerse un poco para atrás y ver qué impacto va a tener lo que hacés en el resto del equipo y del sistema. El simple hecho de frenar y hacer eso es un montón. Si vos no entendés cómo funciona el codigo, toda la lógica del sistema, y no podés saber si eso va a ser un problema o no, es importante que vayas y preguntes “no termino de entender toda la lógica del sistema, con lo cual estoy intentando arreglar esto pero no se si me va a romper algo por otro lado.”
Estas cosas de frenar a pensar son cosas que hacen a un senior, con lo cual, en este caso no lo vas a poder resolver solo, pero el hecho de frenar la pelota y preguntar, va a hacer que si no pasa nada, te digan “andá para adelante, no pasa nada.” O si hubiese sido un gran problema, te digan “menos mal que preguntaste, qué bueno que te tomaste el trabajo de preguntar y entender el impacto de tu trabajo en todo lo que implica la lógica del sistema.”
10. Hacer preguntas sobre las herramientas y tecnologías que usás que no son tu responsabilidad para comprender todo el panorama de un sistema
Por ejemplo, si sos un ingeniero back end, vas a entender el pipeline de continuous integration, continuous delivery, o la infraestructura de la nube. Cuando sos junior, estás específico en cosas concretas. Ahora, como junior no se espera que sepas cómo implementar un pipeline de CI/CD, o los servicios de AWS de la nube.
Ahora, sí es importante cuando tengas un tiempo libre que empieces a tratar de entender cómo funciona ese ecosistema, cómo funciona la lógica de negocio, cómo trabaja el otro equipo, cómo se arman los requerimientos, cómo el PO viene con esos requerimientos, cómo se desarrolla, cómo se decide cuál va primero y cuál va después en el backload, por qué arreglar un bug o no, y dejarlo ahí, justamente por el problema de que si arreglás ese bug es crítico porque podés llegar a romper otra cosa y no es tan grave que esté ese bug ahi.
Usá tus momentos libres para aprender sobre estos temas. Esto te va a ayudar a avanzar más rápido en tu carrera. Si además tenés tiempo y ganas de seguir aprendiendo en tu casa, ¡mejor aún! “En mi empresa, utilizamos pipelines de CI/CD, que son gestionados por un equipo de infraestructura. Me explicaron un poco cómo funcionan, y cuando vuelvo a casa, trato de aprender más a través de tutoriales.”
No es necesario que te sumerjas completamente en este tema desde el principio, ya que, como junior, todavía necesitas enfocarte en aprender sobre el back end y especializarte. Pero sí es útil que comiences a entender los conceptos básicos: qué son, cómo funcionan y por qué se utilizan. Cuanto más sepas sobre el entorno en el que trabajas, mejor vas a entender cómo tu trabajo y tu código impactan en el resto del sistema.
Para prepararte bien en estos diez puntos, hablá con otros desarrolladores
Contactá a desarrolladores intermediate y senior, y haceles preguntas sobre estos diez puntos. No le hagas todas las preguntas a un solo desarrollador, porque le va a llevar mucho tiempo.
Lo que te recomiendo hacer es que busques a diez desarrolladores y les hagas la misma pregunta, por ejemplo, "¿Cómo se piden los requerimientos en tu compañía?” Y que después busques a otros diez desarrolladores más, y les hagas a todos ellos otra pregunta: “¿Cómo hacen el despliegue de producción en tu compañía?” Y así con preguntas sobre los diez puntos que vimos.
De esta forma, vas a obtener información que te va a ayudar no solo a aprender mucho, sino también a prepararte para entrevistas.
La diferencia entre un desarrollador junior bien preparado y uno que no lo está
Volvemos al punto “¿cómo nos preparamos como junior para una entrevista?”
Vienen dos graduados de un bootcamp, o de la carrera ingeniería en sistemas, buscando un puesto de testing, de desarrollador, lo que sea. Ninguno tiene experiencia.
El candidato A me dice “Estudié sistemas, me encanta. Desde chico jugaba juegos, me interesaba saber cómo funcionaba la computadora, y eso me generó interés sobre cómo se puede hacer un juego, cómo se programa, entonces empecé a programar. Soy apasionado, me encanta, y estoy buscando mi primer trabajo.”
El candidato B me dice exactamente lo mismo o similar. Pero además, me cuenta todas estas cosas: “Estuve investigando, entiendo que los requerimientos son muy importantes, que en algunas compañías los requerimientos se hacen via Jira, via Github, y en algunas empresas el requerimiento es asignado a la persona, en otras las personas pueden elegir el requerimiento en el que quiere trabajar y a medida que terminaba, elegir otro. El jefe me va pasando requerimientos. Se trabaja con el PO, con el tester, cuando se hace la planificación del roadmap.”
¿Ves la diferencia?
Una persona que no tiene experiencia pero que me viene con los diez puntos que mencione en este artículo, me llama muchísimo más la atención que una persona que me dice “estoy buscando una oportunidad, tengo muchas ganas, me gusta mucho esto, tengo muchas ganas de trabajar.”
Básicamente, me quedo sin palabras, porque es incomparable una persona que sabe muy bien qué se espera de ellos y cómo lo puede hacer, con alguien que dice, “bueno, estoy buscando esta oportunidad, por eso estudié, me gradué.”
El poder ir a la entrevista y poder contar lo que investigaste, que conocés la importancia de entender el requerimiento, porque no entenderlo puede traer problemas después, que sabés que vas a tener que preguntar cosas, que sabés que esperan que hagas tu trabajo de investigación antes de ir a preguntar, hace una diferencia enorme.
Ahora, puede pasar que la empresa realmente no esté contratando juniors, porque necesitan a alguien con experiencia que resuelva ya las cosas. Así que por más que se prepare con todo esto, quizás no esté la posibilidad de traerlo a la mesa, porque realmente necesitan a alguien que ya resuelva todas esas cosas. En ese caso, no hay nada que puedas hacer. Quizás les gustes mucho, pero ahora necesitan a otra persona.
Pero por lo general cuando se trae un junior a un equipo, se lo trae porque se apuesta, es una inversión. “Bueno, hoy voy a contratar a un junior, lo voy formando para que el semisenior pase a ser senior y el junior pase a ser semi senior. Después voy a traer a otro junior, y voy a tener un junior, un semisenior, y un senior. El senior paso a team lead, y ahora tengo una persona que lidera a un pod de tres.” Y esa es una razón por la cual las empresas contratan juniors, es una estrategia para crecer equipos.
Hay empresas que solo contratan seniors y semi seniors, y otras ya tienen previsibilidad hacia donde quieren ir, y entonces forman gente.
Para esas empresas que sí contratan juniors, que el junior haga toda la investigación de cuál es la expectativa, que se prepare en estos diez puntos para el día uno poder agregar valor, es un montón y hace una diferencia abismal. Y a esto no lo hace prácticamente nadie.
Hasta acá llegamos por hoy. Te dejo el link del vivo de YouTube donde se generaron estas preguntas Vivo 48 - Claves para tu entrevista como Junior Developer
Si querés conocer mi estrategia de búsqueda de trabajo, te recomiendo que leas mi libro:
El Ciclo de Seis Pasos, en el que explico paso a paso que hacer para conseguir trabajo en tecnología.
Si querés que te ayude personalmente a prepararte para conseguir trabajo y desarrollar tu carrera profesional en tecnología, reserva una sesión de coaching conmigo:
Si querés hacerte de las herramientas para conseguir trabajo en tecnología por tu cuenta, te recomiendo que te sumes al curso Cómo conseguir tu primer trabajo en tech.
Para ver los roles que tenemos disponibles, echa un vistazo a nuestro portal de trabajo.
Ahora sí, ¡hasta un nuevo artículo!
Comments