En el mundo dinámico de la tecnología, las empresas están en constante búsqueda de talento que no solo posea hard skills, sino que también se integre perfectamente en la cultura y la filosofía de la organización. Para obtener una visión más profunda de este proceso, tuvimos el privilegio de hablar con Carlos, Engineering Manager en Stayforlong, una empresa líder en el sector de viajes. Carlos compartió su enfoque único hacia la contratación, el desarrollo del equipo y la arquitectura tecnológica en Stayforlong.
¿A la hora de contratar, de qué forma validáis los conocimientos técnicos (entrevista tech, test técnico, pair programming..)? ¿Qué es lo que más os interesa validar?
En nuestros procesos de selección realizamos tanto pruebas de soft skills como pruebas para validar los hard skills. Los candidatos y candidatas, tras pasar un primer filtro con nuestro equipo de People, realizan una prueba técnica y si esta es satisfactoria pasan una última entrevista en la que les planteamos preguntas de índole más teórico sobre programación y algoritmos y realizan una prueba en live code en unos 45 minutos.
Lo que más nos interesa validar es que es el candidato idóneo, que tiene un buen equilibrio entre conocimientos y capacidad para resolver problemas y además que encaja con nuestra forma de ser, abierta y cercana.
¿Con qué stack tecnológico trabajáis y cuál es la motivación para elegir estas tecnologías y no otras? (Frontend, backend, BD, infra…)
En nuestra empresa trabajamos con una amplia gama de tecnologías: en el frontend trabajamos con React y Nextjs. En el backend utilizamos principalmente los lenguajes Golang y PHP, aunque nuestra intención es terminar migrando todo a Golang, ya que es un lenguaje muy robusto y con una gran performance, a parte de ser muy amigable a la hora de programar con él. Y respecto de las herramientas de base de datos principalmente utilizamos MySQL, Redis para cachés temporales, Elasticsearch para búsquedas, aunque en nuestro departamento de Data se utilizan otro tipo de bases de datos para procesamiento de grandes volúmenes.
¿Crees que da mejores resultados tener una persona experta por cada tecnología/scope o personas transversales que puedan tocar un poco de todo?
Para mí lo ideal es tener personas que puedan estar abiertas a trabajar con cualquier tecnología o scope aunque a veces esto no es posible y es valorable tener algo de especialización. En el equipo en el que ejerzo de manager seguimos una filosofía de Feature Owning, mediante la cual los diferentes scopes del equipo están repartidos entre sus miembros. Por ejemplo, si en nuestro equipo se lleva a cabo el cálculo de precios y la integración de proveedores un miembro será la persona de referencia acerca de todos los asuntos relacionados con el cálculo de precios y otro lo será de la integración con proveedores. Tendrán que velar por el buen funcionamiento de sus scopes así como participar en la toma de decisiones para la mejora de cada uno. No obstante, cualquier persona del equipo está capacitada para realizar un desarrollo en cualquiera de las aplicaciones del equipo y prefiero que sea así para evitar silos de conocimiento.
¿A nivel de arquitectura cómo trabajáis? Monolitos, microservicios, sistemas de colas… ¿por qué?
Intentamos seguir una filosofía de microservicios aunque no somos extremadamente rigurosos ya que un microservicio con complejo de monolito puede tener varias ventajas: facilidad en el mantenimiento y deployment, no necesita mantener código similar en varias
aplicaciones, etc. Los diferentes servicios se comunican entre sí bien directamente o bien con sistemas de colas. Las interfaces que utilizamos para la comunicación directa suelen ser HTTP o GRPC, ya que tiene muy buena performance. Para eventos asíncronos utilizamos colas de Kafka
aunque en el pasado hayamos utilizado otros como RabbitMQ o el propio Redis.
¿Cómo funciona vuestra infraestructura? ¿Donde alojáis vuestro código, bases de datos, etc.?
En este sentido hemos decidido confiar gran parte de esta gestión a un proveedor de servicios, en este caso AWS en lugar de tener infraestructura propia ya que requeriría mucho esfuerzo por nuestra parte. Para el código actualmente utilizamos Github aunque hemos tenido experiencias previas con Bitbucket.
¿Como y cada cuanto tiempo hacéis los deploys? ¿Utilizáis CI/CD? ¿Hacéis deploys los viernes?
Nuestro sistema de deploy es continuo. Cada feature que está lista y revisada en una rama de desarrollo se fusiona con la rama master y comienza el deploy. A algunos de nuestros miembros de reciente incorporación les llama la atención, ya que estaban acostumbrados a
tener una versión de staging antes de pasar a producción. Pero en nuestro caso vamos directamente a producción ya que nuestro sistema de desarrollo es bastante riguroso y confiamos en que si se siguen los pasos correctamente el código que llegue a producción será fiable.
Y en caso de que algo no vaya como se esperaba no hay problema en hacer rollback (poner una versión anterior de manera temporal) o hacer revert (dejar el código de la rama master como antes del cambio).
Efectivamente tenemos un sistema de CI (continuous integration) mediante el cual cada cambio que se sube a una rama de desarrollo se somete a una batería de tests para verificar que todo funciona según lo esperado.
¿Trabajáis con algún tipo de testing? ¿Qué importancia tienen en vuestro proceso de desarrollo? (Solo los utilizáis manualmente, os basáis en TDD, están integrados en CI/CD…)
Sí, aplicamos los tres niveles más habituales de testing: tests unitarios, tests de integración y tests e2e, siguiendo la clásica pirámide de testing, mediante la cual procuramos tener muchos tests unitarios, menos tests de integración y menos e2e, con el fin de que los tiempos de ejecución de los flujos de CI no sea excesivamente largos y no dificulten el proceso de desarrollo.
Para nosotros son imprescindibles. De hecho hemos ido eliminando la práctica habitual de probar manualmente las features que se van desarrollando en nuestros entornos locales: si quieres probar algo que has hecho, crea un test y ejecútalo.
¿Cual es el mayor reto tecnológico con el que os habéis encontrado últimamente y cómo lo habéis afrontado? (Problemas de performance, escalabilidad, integridad de base de datos, seguridad…)
Teníamos un cuello de botella con la utilización de PHP para ciertas tareas. Aunque es un lenguaje muy extendido y tiene una sintaxis familiar, su performance se ve afectada negativamente cuando la carga de operaciones es muy alta. De ahí que migráramos gran parte del contenido a Go. Desde ese momento los problemas de performance han sido significativamente menores y mejorando los algoritmos implementados en cada servicio hemos podido ir puliendo los problemas que nos hemos ido encontrando.
¿Usáis alguna herramienta y/o metodología para medir la perfomance del equipo técnico?
Seguimos una metodología Agile, planificando nuestros sprints y evaluando qué ha ido mal y qué ha ido bien. Anualmente realizamos performance reviews a los miembros del equipo las cuales nos ayudan a descubrir puntos de mejora y qué cosas puede hacer cada persona para mejorar su rendimiento y su impacto en la compañía.
Conclusión: Un Entorno Atractivo para Ingenieros Talentosos
En resumen, Stayforlong destaca no solo por su enfoque tecnológico innovador, sino también por su compromiso con la excelencia en la contratación, el desarrollo del equipo y la entrega de productos de alta calidad. Con una cultura de colaboración y un enfoque ágil, la empresa continúa superando desafíos y avanzando en un mercado competitivo y en constante evolución.
Deja una respuesta