Hola a todos! Después de un tiempo sin escribir, estoy de vuelta, tratando de retomar el ritmo de las cosas. Quiero enfatizar que las experiencias compartidas en este espacio están basadas en mis experiencias académicas y profesionales. Por ello, es importante recordar que lo aquí descrito puede representar solo una fracción de la realidad y no debe interpretarse como una fórmula definitiva para procesos, procedimientos o servicios específicos. Actualmente estoy muy entusiasmado con esta nueva etapa de mi carrera. He aprendido mucho y me gustaría compartir algo de este recorrido con la comunidad. Espero que la información aquí presentada sea de gran valor para los lectores. La gente primero: la importancia de las habilidades blandas Cuando participé en mi primer proceso de selección, hace unos años, recuerdo claramente los pasos casi aburridos por los que pasé: entrevista con RRHH, prueba práctica, entrevista con el líder técnico y, finalmente, entrevista con el gerente. A lo largo de mi carrera como desarrollador, he participado en varias entrevistas con diferentes modelos. En ese momento, siempre me sentí incómodo al entrevistarme con gente de RRHH. No entendía muy bien por qué, pensaba: “Si puedo hacer lo que se requiere en la prueba técnica, ya estoy demostrando suficiente competencia para el puesto”. Cuando asumí mi rol como líder de desarrollo técnico, una de mis responsabilidades era colaborar con RRHH (sí, las mismas personas con las que no entendía el motivo de participar en el proceso de selección) en la preparación de una prueba técnica y la definición del formato de entrevista para dos candidatos que empezaban en el área de backend. Pensé que ya sabía lo que un desarrollador principiante en el área de backend debía entregar y qué se consideraría un diferenciador en la prueba. Sin embargo, lo que no esperaba era que, a pesar de la importancia del código, surgieran otras demandas más allá de la entrega del proyecto: ¿cómo evaluar a los candidatos en términos de comunicación? ¿Cuál es su interés en el puesto? ¿Y cómo el contexto que presentan puede influir en su idoneidad para el puesto propuesto? Estas y otras preguntas resultaron ser tan relevantes como el código presentado por ambos candidatos, algo que no había considerado previamente en mis primeros años como desarrollador. Recuerdo que me senté en la mesa de reuniones para tomar la decisión final y me sorprendí un poco al darme cuenta de lo poco que se habló sobre las habilidades técnicas de cada candidato. En parte, esto se debió al hecho de que eran candidatos principiantes, por lo que era de esperar que sus habilidades técnicas no estuvieran tan desarrolladas, y ese no fue el foco principal de la discusión. Sin embargo, incluso para puestos más avanzados, especialmente para puestos de nivel senior, es crucial considerar habilidades como la comunicación, la documentación, la adaptabilidad, la proactividad y otras habilidades que se mencionan a menudo. Estas soft skills son fundamentales y pueden ser decisivas para el éxito en el puesto, además de las habilidades técnicas. De hecho, este es mi siguiente punto. La línea entre Junior y Senior (No, no nivel medio). Sé que hay mucha discusión sobre el significado y la clasificación de términos relacionados con los niveles de experiencia, como "senior". Algunos dicen que "senior se define por años de experiencia", otros afirman que "en algunas empresas, se adquiere experiencia senior después de un año". También hay quienes dicen que "no hay una distinción clara entre junior y senior" o que "los seniors solo hacen revisiones de código y aprueban PR". Algunas de estas afirmaciones son cómicas, otras tienen algo de verdad. El hecho es que el concepto de "senior" es bastante variado y no me corresponde definir un estándar universal, pero puedo ofrecer algunas pautas para entender esta clasificación de una manera más individual. Ser senior no es sólo cuestión de conocimientos técnicos, aunque sin duda esto es muy importante. Un verdadero senior, o al menos un buen senior, es alguien capaz de resolver problemas complejos tanto en código como en arquitectura de sistemas. Mantener la calidad del código, seguir buenas prácticas de desarrollo y tener conocimientos de gestión de proyectos son aspectos cruciales. La diferencia clave es que un senior debe ser capaz de ejecutar todo esto de forma autónoma y, lo que es más importante, colaborar con equipos de diferentes niveles y sectores para entregar el mejor proyecto posible. Además, un verdadero senior (o al menos los mejores) no solo lidera y guía al equipo, sino que también desarrolla y prepara a otros desarrolladores para asumir nuevos puestos y responsabilidades. Mi primera experiencia liderando un proyecto Cuando asumí mi primer proyecto, mi jefe sabía que yo no había liderado ningún otro proyecto antes. Simplemente participé en el desarrollo y trabajé algunas cosas que facilitarían el desarrollo en términos de comunicación con la gerencia. La primera pregunta que me hizo fue: No supe la respuesta de inmediato, era una pregunta muy compleja. Debido a que el proyecto estaba solo en el boceto, no teníamos idea del stack, cuánto tiempo tomaría completar cada tarea y otras métricas de interés para las personas de arriba. Hice un estudio completo para poder entregar al día siguiente sobre varias metodologías de gestión de proyectos: Pert, Planning Poker. Elegimos colaborativamente la que mejor se adaptaba y comenzó el desafío. para cada miembro del equipo, cuál es la mejor plataforma de desarrollo, cuál es el mejor stack a utilizar, cómo funcionará la arquitectura del sistema, estudiar otras soluciones en el mercado, monitorear el nivel de cada desarrollador, . "¿Cuántas personas y de qué tipo serán suficientes para complementar el proyecto?". reuniones, reuniones y más reuniones con la gerencia resto del trabajo consistía en comunicarme con los desarrolladores, dividir tareas, monitorear métricas y, básicamente, tener un ojo en Asana (para estimar el tiempo de entrega del proyecto) y otro en Meet para asegurarme de que mi micrófono no estuviera encendido y que nada no deseado se colara "accidentalmente". Cuando menos me daba cuenta, cada vez estaba más alejado del código. Mi función pasó a ser la de sugerir mejoras y corregir algunos errores críticos para que el proyecto pudiera funcionar, o al menos proporcionar una base sólida para que los desarrolladores pudieran empezar. El Conclusión y una mirada al pasado: al maestro con cariño Comencé mi carrera como pasante de desarrollo y, curiosamente (y puede que te parezca un poco contradictorio por mi parte), no tenía ninguna experiencia concreta (al menos no registrada formalmente en mi historial laboral) que me clasificara como desarrollador junior, senior o completo. Gran parte de la experiencia que adquirí provino de proyectos personales e investigaciones en la universidad. Fue un proceso gradual hasta que me di cuenta de que mis habilidades habían evolucionado desde aquellos primeros días. Pero sí, trabajé intensamente como desarrollador en diferentes niveles y tuve la oportunidad de conocer diferentes tipos de profesionales senior a lo largo de mi carrera: El senior muy competente y eficaz, pero poco comunicativo, que resolvió los problemas sin dar explicaciones sobre su enfoque. El senior es excelente en la comunicación y la enseñanza, pero a menudo se siente abrumado por tareas urgentes y no tiene tiempo para enseñar. El senior que estaba entusiasmado con la sobreingeniería y la centralización de la tecnología, pero que cumplía con los plazos y entregaba lo que prometía. Lo más importante es que, a pesar de sus justificables defectos (aunque es posible, es muy difícil equilibrar las exigencias), todos estos profesionales tenían algo valioso que enseñar. Estas experiencias ayudaron a moldear mi carrera y me dieron una visión clara de lo que funciona y lo que no en el desarrollo de sistemas.
