Entrevista a Alejandro Acosta, un developer de 1.000.000 USD
Yo siempre quise ser programador. Por eso en la universidad hice todas las asignaturas de programación, algorítmica y bases de datos. No me interesaba mucho la seguridad informática - por eso no la cursé - y era normal. Ya sabéis que comencé con 12 años a programar en BASIC tras ver la película de TRON de la que tanto os hablo por aquí . Figura 1: Entrevista a Alejandro Acosta, un developer de 1.000.000 USD Lo cierto es que me picó el veneno del hacking y la ciberseguridad , y ya es difícil cambiar eso, pero sigo amando a esa "rara avis" que existe es nuevo mundo como nombre antagonista a " Hacker ": " Developer ". Por eso cuando conozco algún developer quiero saber más de él. Figura 2: Contactar con Alejandro Acosta Este es el caso de Alejandro Acosta , que tras comenzar cobrando 300 € - yo comencé programando gratis en mi beca -, se fue a Silicon Valley a pasarse el juego, y lograr cobrar 1.000.000 de USD como desarrollador en Microsoft . No está mal. Puedes saber todo lo que hace hoy en día, en Engineer Game . Figura 3: Engineer Game Como creo que su historia es curiosa, le he hecho una entrevista, pero diferente. Le he dejado diez temas abiertos para que él conteste de ellos, y aquí están las respuestas. Si quieres conocer más de él, puedes contactar con él a través de su buzón de MyPublicInbox o solicitarle directamente una clase gratuita , si quieres ser un desarrollador que haga "las américas". 1. El mito de las 1.000 entrevistas vs. la contratación en la era de la IA Los fundamentos son hoy más importantes que nunca. En una entrevista no se evalúa únicamente si una persona puede completar un ejercicio de live coding o diseñar un sistema, sino su capacidad para analizar problemas reales, razonar bajo presión y encontrar soluciones aplicables a producción. La inteligencia artificial es una gran aliada, pero resolver un ejercicio con su ayuda no demuestra por sí solo que alguien sea un buen ingeniero. La diferencia aparece cuando el entrevistador introduce nuevas restricciones, cuestiona una decisión o complica progresivamente el problema. Es en ese diálogo donde se comprueba si el candidato entiende realmente lo que está haciendo. Por eso, especialmente en el mercado de Silicon Valley, prepararse sigue siendo fundamental. La constancia, el estudio y el dominio de áreas como live coding y system design continúan siendo determinantes para acceder a las mejores oportunidades y alcanzar una compensación elevada. Esa es también la razón por la que en EngineerGame acompaño a ingenieros de software que quieren dar un salto en sus carreras. 2. SRE y ciberseguridad: cuando el sistema cae a las 3:00 AM El error más común es diseñar la arquitectura pensando que los incidentes pueden evitarse por completo. En las grandes empresas se asume que, tarde o temprano, habrá una caída crítica. La diferencia no está solamente en prevenirla, sino en la capacidad de detectarla, contenerla, recuperarse y aprender de ella. La cultura es decisiva tanto antes como después del incidente. Antes, porque deben existir mecanismos de prevención, observabilidad y respuesta. Después, porque hay que realizar un análisis sin culpabilizar a las personas, identificar las causas y aplicar cambios que impidan que el mismo problema vuelva a repetirse. Prácticas como Chaos Engineering permiten comprobar qué sucede cuando falla una dependencia, una región o un componente crítico. No todas las empresas necesitan aplicarlo con la misma profundidad, pero todas deberían diseñar sus sistemas partiendo de una idea básica: cualquier componente puede fallar. 3. AIOps y el dilema del self-healing Confío en la inteligencia artificial como apoyo durante el ciclo de desarrollo y en las operaciones diarias. Puede ayudar a investigar incidentes, relacionar señales y reducir considerablemente el tiempo necesario para resolver problemas críticos. Sin embargo, la autorremediación ya existía antes de la IA.