Escuché esa frase decenas de veces. E incluso yo mismo lo pensaba.

Al menos en España, y creo que también en gran parte de América Latina, tenemos un complejo enorme con el idioma de los piratas. Nunca nos parece tener un nivel suficiente como para siquiera intentar entrevistarnos con empresas extranjeras.

La realidad es que no necesitas un gran nivel. Y mucho menos títulos oficiales.

En esta entrega de Status 418 voy a contaros mi experiencia trabajando para empresas americanas y mi proceso para llegar a un nivel decente de inglés.

Suscríbete ahora

Si quieres aprender más sobre las bases de la ingeniería de software y acceder a nuevas oportunidades de trabajo, mis cursos te pueden ayudar!

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

La dura realidad

En España no destacamos por nuestro nivel de inglés. A diferencia de los nórdicos o los países bajos, el nivel con el que sale uno de la educación obligatoria es bastante bajo.

Viendo a mis primos pequeños y a mi hermano, creo que eso está mejorando, pero sigue sin ser suficiente para llegar a un inglés conversacional mínimo. Y, tras más de una década de 3 horas de inglés a la semana, es un pecado.

Pero bueno, no hemos venido a hablar de los problemas de la educación patria. Aunque es importante tenerlo en cuenta para buscar otras formas de compensarlo.

Nadie te va a juzgar por tu nivel

Dicho eso, jugamos con una ventaja. Los anglosajones son todavía peores que nosotros con los idiomas. Ya hablan el idioma universal, por lo que no tienen un motivo real que les fuerce a aprender un segundo idioma.

Por eso, vas a ver que la gran mayoría de nativos valora mucho que intentes hablar en inglés. Por muy mal nivel que tengas, casi seguro que es mejor que su mejor segundo idioma, por lo que apreciarán el esfuerzo.

En el mundo profesional, o al menos en el sector tecnológico, trabaja gente de todo el mundo. Tuve compañeros japoneses, indios, polacos, alemanes, españoles, holandeses, mexicanos, americanos, irlandeses, ingleses, de oriente medio y muchos más. Cada uno con su acento típico y su nivel particular.

Verás gente con mejor y peor nivel, pero nadie se fija en eso. Si cumples unos mínimos, es decir, poder comunicarte con que te entiendan y poder entender a los demás, es más que suficiente. Lo importante es lo que aportes en el apartado técnico.

Cómo mejorar inglés sin esfuerzo

La estrategia que me resultó más efectiva para mejorar la comprensión fue consumir todo mi ocio en inglés.

Pasé a ver todas las series y películas en versión original, primero con subtítulos en español y después en inglés.

Dejé de consumir YouTubers españoles y empecé a interesarme por creadores de contenido en inglés.

Empecé a leer en inglés. Si bien esto sí requiere un poco más de esfuerzo, no es tanto si estás leyendo libros que también habrías consumido en español.

Cambié el idioma de todos mis dispositivos y videojuegos.

Durante un tiempo incluso cambié forocoches por reddit para forear un rato sobre noticias y temas random xD.

Y por último, se dió la casualidad de que siempre me gustaron los deportes americanos, y me descargaba los partidos de la NBA y la NFL con los comentaristas nativos.

Todas estas cosas no suponen casi ningún esfuerzo. Tampoco van a hacer que mejores de un día para otro. Pero poco a poco, sin que te des cuenta, el cerebro irá asimilando información y mejorando muchísimo.

Cómo mejorar inglés con esfuerzo

Para avanzar más rápido, sobre todo cuando tu nivel es bajo, también se necesita aprendizaje activo.

De las cosas que más me ayudaron fue la Escuela Oficial de Idiomas de España. Es barata y normalmente los profesores son mucho mejores (para empezar, solo hablaban en inglés, mientras que mis profesoras del colegio nunca lo hacían xD). Además, es un tipo de aprendizaje más conversacional, no se centra tanto en la gramática.

En verano siempre me inscribía a cursos o actividades 100% en inglés, para forzarme a hablar y perder la vergüenza.

También hice amigos online en varios videojuegos, lo que me forzaba a practicar mientras me divertía.

La clave de todo esto es ser lo más proactivo posible y buscar formas de aprender el idioma que realmente te gusten. Estando quieto es muy complicado aprender. Pero forzarse a métodos que detestas tampoco es lo mejor, porque probablemente acabarás abandonándolos.

Aplica antes de estar listo

Nunca te vas a sentir listo al 100%. Es imposible. No es tu idioma nativo, y además tienes que usarlo en un entorno con presión, el proceso de entrevistas y el trabajo.

Después de años trabajando en inglés y viviendo en Irlanda y Austria, todavía considero que mi nivel es bastante bajo. Sigo cometiendo errores, me sigo trabando a veces y mi pronunciación deja bastante que desear. Pero mi objetivo no es hablar un inglés perfecto. Es ser el mejor ingeniero de software posible.

Es por eso que es muy importante aplicar lo antes posible. Empieza con ofertas que te interesen menos, para hacer entrevistas con menos presión y sin miedo al fracaso. Es muy probable que las primeras entrevistas te salgan bastante mal (yo no entendía ni lo que me decían los recruiters y acababan colgándome xD). Por eso, no gastes tus mejores balas a las primeras de cambio.

Verás que, como en español, todas las entrevistas siguen una estructura muy similar. Cuando lleves 4 o 5 ya estarás acostumbrado y te sentirás mucho más cómodo hablando en otro idioma.

Conozco gente que lleva años preparándose para aplicar, y al final nunca lo hacen. No caigas en ese grupo. El no ya lo tienes, y los beneficios de intentarlo y fracasar son mucho mayores que los de prepararse sin un fin claro.

Y recuerda echarle un vistazo a mis cursos si quieres aprender más sobre las bases de la ingeniería de software.

Mi currículum tenía 2 páginas, y había gente con 3 o 4. Todo eso sin haber cotizado ni una hora en nuestras vidas.

Resultado? Cuando intenté usarlo para cosas serias, no me respondía ni Dios. Ahí empecé a pensar que o yo era un inútil (que también xD), o había margen de mejora en cómo aplicaba a las ofertas.

En este artículo os voy a contar cómo pasé de no recibir ninguna respuesta a conseguir entrevistas con Google, Amazon, Salesforce, Stripe, MongoDB y muchas más. Con la plantilla que uso yo gratis al final!

Suscríbete ahora

Mis cursos de Udemy están al mejor precio disponible! Aprovecha las rebajas para aprender más sobre las bases de la ingeniería de software.

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Los fallos de mi primer CV

Cuando nos obligaron a utilizar Europass, nos vendieron que era el estándar que la Unión Europea estaba buscando implantar. Eso suena atractivo a primera vista.

El problema con este formato es que, si rellenas toda la información que te pide, te vas a las 3-4 páginas muy fácilmente. Y eso no lo va a leer nadie.

Ponte en el lugar del recruiter. Si tuvieras que revisar cientos de CVs, leerías cada uno de ellos detenidamente? Muy probablemente no.

Un recruiter invierte de 6 a 10 segundos en una primera revisión. Y, si pasa el filtro, quizás le dedique otros 30 segundos o un minuto, con mucha suerte.

Eso quiere decir que, si la información importante no está claramente a la vista, no la va a leer.

En el CV de Europass, tenía demasiada información que no sumaba nada:

• Cabecera enorme con foto y sexo.

• Conocimientos que adquirí en la carrera de Ingeniería Informática, algo obvio.

• Tablas enormes para mis idiomas y para el permiso de conducir xD.

• Demasiados proyectos, y ninguno con enlace.

Además, la redacción no está nada optimizada para una lectura rápida y, en general, el estilo del CV tiene demasiado espacio en blanco.

Compáralo con el formato que utilizo ahora:

Una única página, limpio, fácil de leer y solo con datos relevantes. Vayamos sección a sección.

Cabecera y skills

Debemos empezar con lo que más les importa a los recruiters: formas de contacto y habilidades.

Recomiendo hacer la cabecera lo más corta posible para priorizar la información relevante. No añadas foto, a no ser que estés seguro de que en tu país la piden siempre.

La parte de skills divídela en cuatro o cinco categorías, como en mi caso. Y recuerda que más no siempre es mejor. De nuevo, queremos que el recruiter vea que somos un buen match para el puesto, no crear un diccionario de tecnologías irrelevantes xD.

Experiencia

En la siguiente sección añadiremos la experiencia profesional, siempre de más a menos reciente.

Si has tenido trabajos que no tienen demasiada relevancia para el puesto al que aplicas, yo te recomiendo quitarlos, especialmente si hacen que tu CV se vaya a más de una página.

Por ejemplo, en este caso no mencioné varias prácticas que hice durante la carrera. Y cuando cambié a MongoDB y tuve que añadir Salesforce a mi experiencia, eliminé la internship en Go Walk Talk, porque sabía que no iba a marcar la diferencia.

Menciona cuatro o cinco puntos para cada una y añade algunos puntos en el que tu impacto sea medible. Por ejemplo, en Arantia mejoré el tiempo de procesamiento de un algoritmo en un 95%.

No todos tienen que ser así, pero la estructura “Hice X para solucionar Y problema, dando como resultado un Z% de mejora” queda muy bien y hace ver tu impacto real de forma sencilla y directa.

Lo que no recomendaría es añadir puntos del estilo “creé un servicio con X e Y tecnologías”. Ya hemos dejado claras nuestras skills en la primera sección, por lo que es preferible no repetir lo mismo aquí también.

Proyectos

En la siguiente sección mencionaremos los proyectos más relevantes, si tenemos. Esta sección es especialmente importante si eres junior, ya que al no tener demasiada experiencia, todo lo que pueda mostrar tu habilidad, proactividad e interés por el sector ayuda un montón.

Por ejemplo, en mi caso, varios entrevistadores se descargaron mi app de Crossbar Challenge y la probaron antes de la entrevista por curiosidad. Y casi todos me preguntan sobre mis cursos de Udemy.

Añade enlaces al código o al proyecto en sí. Si no puedes publicar ninguna prueba, es mejor no añadirlo, no aporta demasiado.

Y nunca crees proyectos “basura”, especialmente ahora que con la IA es muy fácil. Si añades un proyecto, asegúrate de que puedes responder preguntas sobre él y explicar lo que hace. Si no, te va a restar en lugar de sumar.

Por último, si ya llevas muchos años en el sector o si no tienes ningún proyecto público interesante que puedas enseñar, prioriza contar más sobre tu experiencia profesional.

Educación

Para finalizar, menciona los estudios relevantes para el puesto al que estás aplicando, de forma muy breve.

No añadas estudios de instituto o colegio ni nada de idiomas. Si aplicas a un puesto en inglés, se asume que tienes un nivel suficiente. Aporta poco decir que tienes un C1 en inglés, de hecho, es probable que los americanos ni sepan qué significa.

Plantilla

Lo prometido es deuda! Aquí os dejo la plantilla para que podáis reutilizarla y adaptarla si así lo necesitáis: https://github.com/danielblanco96/resume-public

El CV no lo es todo, ya que después vienen las entrevistas. Pero es muy importante optimizarlo para maximizar las probabilidades de conseguir una oportunidad!

Y recuerda echarle un vistazo a mis cursos si quieres aprender más sobre las bases de la ingeniería de software.

“Hay cientos de ingenieros trabajando en YouTube desde hace dos décadas. Cómo voy a poder diseñarlo yo sólo en una hora?”. Valid crashout xD.

Tras hacer cientos de entrevistas, tanto como entrevistador como candidato, voy a resumirte las claves del diseño de sistemas en este post.

Suscríbete ahora

En mi curso Diseño de Sistemas a Gran Escala y Arquitectura de Software cubro todo el proceso desde cero, con 7 casos reales:

• Diseñar sistemas con alta escalabilidad, disponibilidad y fiabilidad.

• Conceptos clave en el diseño de sistemas (load balancer, cdn, message brokers, cache y mucho más)

• Patrones de Arquitectura Software.

• 7 casos prácticos reales.

Únete a los más de 6500 estudiantes y 4.7 / 5 ⭐️ de valoración!

Qué se busca realmente en las entrevistas de Diseño de Sistemas

Antes que nada: no, no te van a pedir diseñar un sistema perfecto. Ese no es el objetivo.

Lo que realmente van a evaluar es la forma en la que piensas y abordas un problema muy ambiguo para llegar a una posible solución, colaborando con el entrevistador.

El objetivo debe ser partir de un problema abierto, establecer el alcance con el entrevistador y descomponerlo en partes más pequeñas y manejables.

El entrevistador va a querer comprobar si entiendes los problemas de los sistemas a gran escala. Una solución que puede ser perfectamente válida para un sistema con unos pocos miles de usuarios seguramente sea inviable para uno con decenas de millones de usuarios concurrentes.

Y ahí está la clave. El entender que no existe una solución perfecta y que todo en el desarrollo de software son trade-offs.

Cómo estructurar la entrevista

Con el tiempo tan limitado que tenemos, es muy importante estructurar bien la discusión. Aquí os dejo mi forma de abordar estas entrevistas y el tiempo en cada fase.

1. Toma de requisitos y definir el alcance (5-10 min)

En un problema tan abierto, podríamos estar hablando horas y horas de las distintas partes del sistema. Y no queremos perder el tiempo en áreas en las que el entrevistador no está interesado.

Mucha gente asume los requisitos y empieza a diseñar el sistema desde el principio, y eso es un gran error. Estas entrevistas hay que tomarlas como una discusión con el entrevistador, no como un problema que tienes que resolver por tu cuenta.

Para ello, debemos empezar definiendo los requisitos funcionales y no funcionales. Empieza con los requisitos más obvios y pregunta siempre al entrevistador si quiere aumentar el alcance por algún lado.

Por ejemplo, si tenemos que diseñar un sistema como YouTube, está claro que como mínimo debemos permitir subir y visualizar vídeos. Pero funcionalidades como comentarios, suscripciones, likes, etc. pueden estar dentro del alcance o no.

No podemos abarcar todo en tan poco tiempo, por lo que es probable que el entrevistador deje funcionalidades secundarias fuera del alcance. Pero, aunque eso pase, mencionarlas te da puntos a tu favor, ya que muestra que estás pensando a fondo sobre el problema.

2. Cálculos aproximados sobre la escala del sistema (5 min)

A partir de los requisitos, algunos entrevistadores estarán interesados en calcular ciertos datos sobre la escala del sistema. Por ejemplo, consultas por segundo (QPS), usuarios, almacenamiento necesario, etc.

Pregunta por datos como el número de escrituras por unidad de tiempo, el número de usuarios y haz los cálculos de forma aproximada. No tienen que ser exactos, es simplemente para dar una idea de la escala.

Es importante preguntar al entrevistador si está interesado en estos back-of-the-envelope calculations, ya que muchos, entre los que me incluyo, creemos que no aportan mucho valor y preferimos invertir más tiempo en discutir el diseño.

3. Diseño a alto nivel (15-20 min)

El siguiente paso es diseñar el sistema a alto nivel. No debemos entrar aún en detalle en ningún componente. Queremos establecer una primera solución al problema y ver que el entrevistador está conforme con ella.

Debes tratar el sistema end-to-end: clientes, APIs, servicios y almacenamiento de datos. Si necesita integraciones con servicios externos, menciónalo también. El objetivo es identificar los componentes del sistema y cómo interactúan entre ellos.

Algo muy importante es comentar los trade-offs de tus decisiones. En el desarrollo de software, una decisión que te ayuda a cumplir un objetivo tiene siempre sus contrapartidas. No hay una solución perfecta para todo, y debes dejar claro que lo tienes presente.

Asegúrate de que cubres todos los requisitos establecidos en la primera fase. Parece obvio, pero con la presión he visto muchos casos en los que uno se olvida de algún detalle y luego es complicado rectificar, por lo que no está de más comprobar de nuevo los requisitos.

4. Entrar en detalle en los componentes más importantes (15 min)

Una vez el entrevistador está conforme con el diseño a alto nivel, pasaremos a hablar a fondo de los componentes más importantes.

Esto depende mucho del problema en cuestión. Si diseñas un sistema como YouTube, deberías hablar del procesamiento de los vídeos; si te toca Uber, deberías hablar del algoritmo para emparejar conductores y pasajeros, etc.

En el hipotético caso de que no sepas de qué hablar, no tengas miedo de preguntarle al entrevistador para ver en qué está más interesado.

Otros temas que podrías tocar en esta fase si tienes tiempo son el diseño de datos, la estrategia de caching, el particionado de datos, la seguridad, las analíticas, las métricas y otros aspectos que no hayas cubierto aún en el diseño a alto nivel.

5. Cierre (5 min)

Aprovecha los últimos minutos de la entrevista para repasar el diseño y mencionar los temas más importantes.

También puedes hablar brevemente de temas que no hayas podido cubrir, para que el entrevistador sepa que no los has olvidado o ignorado, sino que no has tenido tiempo de tratarlos.

Puntos clave en el diseño de sistemas

Es difícil tratar los temas más importantes en estas entrevistas porque los problemas pueden ser muy distintos en cuanto a alcance y complejidad. Pero hay temas que sí o sí debes tener en cuenta en casi todos los diseños.

• Escalabilidad. Diseña tu sistema para que pueda escalar horizontalmente (añadiendo más nodos). Para ello, prioriza los servicios stateless y utiliza componentes como load balancers y API gateways para distribuir la carga a tus servicios. Solo en casos muy concretos tiene sentido utilizar servicios stateful, como por ejemplo en sistemas en tiempo real que utilizan websockets.

• Patrones de uso. Es el sistema read-heavy o write-heavy? Esto va a impactar mucho en tu diseño, sobre todo el acceso a datos y la caché, por lo que debes tenerlo en cuenta.

• Caché. En cliente, usando un CDN, y en backend, usando Redis, por ejemplo. Considera las estrategias cache-aside (lazy loading), write-through (la caché siempre se actualiza en escrituras), write-back (escribes en la caché y luego la base de datos se actualiza), etc. Menciona también las estrategias de invalidación que seguirás.

• Consistencia vs disponibilidad (teorema CAP). Considera los trade-offs de consistencia fuerte vs eventual. Por lo general, a gran escala suele ser preferible la consistencia eventual, pero depende del caso de uso. Hay casos, como sistemas de pagos o inventarios, donde se prioriza la consistencia.

Cubriendo bien esos puntos ya estás atacando la gran mayoría de problemas que suelen aparecer en entrevistas de diseño de sistemas.

Y recuerda, lo importante en estas entrevistas no es buscar la solución perfecta, porque no existe. Existe la solución adecuada para un contexto concreto.

Y si te interesa preparar este tipo de entrevistas de forma más guiada, recuerda echarle un vistazo a mi curso Diseño de Sistemas a Gran Escala y Arquitectura de Software, donde cubro toda la teoría, y 7 casos prácticos reales!

Mi estrategia era simple. Dos o tres meses de sprint, y uno o dos de descanso. Quería sacar un nuevo curso? Me ponía como meta publicarlo antes del verano, le daba a tope de marzo a junio y descansaba julio y agosto. Jornadas de 6AM a 10PM se sentían ligeras al ver la meta cerca.

Y esto me funcionó genial durante años. Pero desde hace unos meses, siento cero motivación para seguir con mis proyectos personales. Yo me forzaba a continuar, como siempre había hecho hasta ahora cuando tenía pocas ganas. Pero llegó la hora de tomar un descanso antes de llegar a un burnout total.

Llevo un par de meses sin hacer prácticamente nada al acabar mi jornada laboral, y así va a seguir un tiempo.

En esta entrega os quiero contar las razones por las que creo que he llegado a este “semi burnout” y qué voy a hacer en los próximos meses.

Suscríbete ahora

Si quieres aprender más sobre las bases de la ingeniería de software y acceder a nuevas oportunidades de trabajo, mis cursos te pueden ayudar!

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Por qué creo que he llegado a este punto

No hay una única razón para llegar este punto. Son una serie de factores que juntos hacen mella poco a poco.

1. Demasiados proyectos sin un fin claro

Hace justo un año me metí en una locura de proyecto con un amigo youtuber: hacer un mapa de Fortnite bastante ambicioso que él pudiese promocionar a su audiencia.

Empezó bien y lo pasé genial, pero a la hora de diseñar el mapa llegaron los problemas. No teníamos suficiente experiencia en eso y pensamos que sería más sencillo, por lo que el proyecto quedó aparcado por el momento.

También empecé Deep Focus, una app que bloquea distracciones hasta que completas tus tareas. La hice principalmente para mí, pero la anuncié en Twitter y me comprometí a sacar actualizaciones cada dos o tres semanas (algo en lo que fallé estrepitosamente xD).

También creé esta newsletter semanal, aunque en este caso no la siento como un trabajo, sino como un espacio en el que expresar y ordenar mis ideas, y por el momento me está gustando.

Cuando empezaba un curso tenía un fin claro. Trabajaba tres meses a tope, lo publicaba y al instante veía un retorno. Con los otros proyectos no, y eso hace que me cueste más mantener la motivación.

2. Menos incentivos que en el pasado

Me mudé a Dublín en 2021 con poco dinero. Mi objetivo era ahorrar todo lo posible durante unos años, invertirlo todo y dejar que el interés compuesto hiciese su magia para que al llegar el momento de tener una familia, contar con un buen colchón detrás.

Cada curso o proyecto que llevaba a cabo me daba ingresos para cubrir gastos de mi vida, por lo que incluso 100 euros al mes me compensaban el trabajo.

Ahora, con varios proyectos funcionando de forma pasiva, es más difícil justificar el tiempo invertido en uno nuevo, por lo que la motivación se desploma.

3. Conexión y cambio constante

Nuestro trabajo no es físico, pero a nivel mental puede desgastar mucho. Es complicado desconectar de verdad cuando tienes un problema o un proyecto con ciertas expectativas y presión.

Y en mi caso, al llevar tantos años acostumbrado a trabajar en mis proyectos después del trabajo, ver que no avanzo en ellos hace que me resulte aún más difícil desconectar.

Además, el cambio constante que está sufriendo nuestro sector, con todos los avances, la incertidumbre y los despidos masivos, no ayuda a mi mente, para qué mentir.

Con la IA podemos trabajar más rápido y en más cosas a la vez, lo que implica muchos cambios de contexto. Y siento que el cerebro humano tiene un límite en ese sentido. A mayor número de tareas que intento completar de forma paralela, antes llega la sensación de agotamiento.

4. Mi trabajo a tiempo completo como Software Engineer

Hace año y medio que empecé en MongoDB y es el trabajo que más he disfrutado hasta ahora. Estamos construyendo productos que usan muchísimas personas en todo el mundo, me divierte y la recompensa es muy grande.

Eso hace que le haya dedicado más tiempo al trabajo que en otras empresas por las que he pasado. Recientemente me ascendieron y, al ver los frutos de mi esfuerzo, me motiva a seguir así.

Como contrapartida, tengo menos tiempo para avanzar en mis proyectos personales, pero en mi caso me compensa.

Mi plan para mejorar

Personalmente, lo único que me hace desconectar al completo es la naturaleza. Crecí toda mi vida en “medio del monte” y hacer cosas al aire libre me encanta.

Cuando estoy en casa en modo ocioso es cuando realmente sufro este mini burnout, por el sentimiento de culpa de no estar avanzando en nada. Es algo que sé que tengo que cambiar, pero “reprogramar” el cerebro para no sentir que si estoy en casa debo estar trabajando en mis cosas es complicado y me llevará meses o años.

Mi plan es simple:

• Desinstalar X y otras redes sociales del teléfono.

• Pasar aún más tiempo en la naturaleza.

• Aprovechar mis próximas vacaciones en Guatemala y en España para no abrir el portátil durante semanas.

• Y, lo más importante: trabajar en proyectos que realmente me llenen, me compensen y no sienta como una obligación o una carga en mi día a día.

Estoy seguro de que, tras un tiempo de desconexión real, la motivación que mantuve tanto tiempo en el pasado volverá. A partir de ahí, me centraré solo en proyectos que tengan sentido y, sobre todo, una línea de meta.

Todo el mundo me dice que esto cambia al tener hijos, ya que hay poco tiempo para uno mismo. No es mala idea, seguramente también me hace falta xD

Me gustaría leer vuestra opinión y experiencias gestionando el burnout! Os pasa a menudo? Qué hacéis para desconectar realmente?

Y recuerda echarle un vistazo a mis cursos si quieres aprender más sobre las bases de la ingeniería de software.

Eso nos dijo el CEO en Salesforce tras despedir al 10% de la plantilla y ver que la moral caía. Totalmente delusional xD.

Pasó de ser una empresa reconocida por su buena cultura y trato a los empleados, a todo lo contrario.

La confianza y la cultura se contruyen en años, pero se destruyen en segundos.

Suscríbete ahora

Si quieres aprender más sobre las bases de la ingeniería de software y acceder a nuevas oportunidades de trabajo, mis cursos te pueden ayudar!

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Últimamente estamos viendo muchas rondas de despidos. Block despidiendo al 40% de la plantilla, Oracle eliminando hasta 30,000 posiciones y rumores bastante fuertes aseguran que Meta quiere despedir a 16,000 trabajadores, el 20% de su total.

A corto plazo, estas reducciones tienen sus beneficios. Las valoraciones en bolsa suben, los gastos bajan y puedes reconducir tus inversiones hacia otras áreas con mayor potencial.

Ese es el caso de Oracle, que piensa ahorrar hasta 10 mil millones de dólares en sueldos y destinarlos a expandir infraestructura de IA.

Sin embargo, a medio y largo plazo la cultura de la empresa queda muy dañada.

Las rondas de despidos masivas siempre afectan a la cultura y la moral. Pero no es lo mismo hacerlo cuando la empresa va mal que cuando está marcando beneficios récord trimestre tras trimestre. El primer caso se acepta bastante mejor.

Mi experiencia con los despidos en Salesforce

Salesforce era reconocida en el sector tech como una de las mejores empresas para trabajar. Buenas condiciones, cultura y un cuidado por los empleados que no se veía en otras compañías.

De hecho, yo la conocí y apliqué gracias a posts de Reddit en los que hablaban muy bien de ella.

Y durante mi primer año la experiencia fue buenísima. Realmente se sentía que cuidaban de nosotros.

Pero todo cambió cuando llegó la crisis tech de 2023. Despidos masivos a los que Salesforce se unió.

Lo peor no fue el hecho, sino las formas. Nos enviaron un correo electrónico con la decisión, indicando que “en las próximas horas” les llegaría un aviso a los afectados.

A los europeos, como las regulaciones son más estrictas, nos tuvieron en vilo semanas, hasta que el tema se calmó un poco.

Además, nos recortaron el bonus y otros beneficios sin una razón clara. Los ingresos fueron récord, pero como el sector “estaba mal”, pues lo tenían que hacer.

La puntilla fue lo de la French Polynesia del CEO xDD, junto con más comentarios totalmente fuera de tono de él y otros directivos en múltiples all hands.

La empresa pasó de ser una de las mejor valoradas del sector a destruir toda su reputación. A todo el mundo le afectó ese proceso, y estoy seguro de que la motivación y el esfuerzo que los empleados estaban dispuestos a dar se desplomaron.

A día de hoy, más de 3 años después, aún no se ha recuperado, y posiblemente no lo hará nunca.

Si sabes que puedes ser el siguiente, hay pocas razones para esforzarse

Muchas empresas que despiden a granel ni siquiera se toman su tiempo para decidir a quién despiden de forma individual. Establecen porcentajes por área y la decisión la toma un algoritmo.

A veces, esto se hace para no involucrar a los mánagers de primera línea y que no se filtren los despidos antes de tiempo.

Esto lleva siempre a casos sin sentido, como uno de los trabajadores más valorados y queridos por la comunidad de Fortnite, que Epic despidió junto a otras 999 personas, o empleados que llevaban toda la vida en Oracle y que se fueron a la calle.

Cuando eso sucede, qué motivación tienen los empleados para seguir trabajando duro? Poca o ninguna. Te puede tocar aunque seas de los mejores de la empresa, simplemente porque un algoritmo así lo decide.

Y ahí es cuando la cultura muere. Se mata la moral, el esfuerzo y la innovación. Todo por buscar beneficios a corto plazo.

Y recuerda echarle un vistazo a mis cursos si quieres aprender más sobre las bases de la ingeniería de software.

No es ninguna sorpresa si te digo que la calidad del software que usamos en nuestro día a día lleva sufriendo una bajada ya desde tiempos pre-pandemia. Y la llegada de los LLMs está acelerando un proceso que cada día se nota más.

Lo vemos en productos más lentos, con más bugs y con menos cariño hacia los usuarios. Y en el post de hoy vamos a ver el porqué, y qué nos puede deparar el futuro.

Suscríbete ahora

Si quieres aprender más sobre las bases de la ingeniería de software y acceder a nuevas oportunidades de trabajo, mis cursos te pueden ayudar!

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Por qué escribimos peor software?

Las razones por las que el software se siente peor que hace más de una década son muchas y diversas.

Empecemos con lo obvio. Los sistemas son mucho más complejos hoy en día. Algunos con buenas razones: la democratización de la tecnología trajo una explosión en el número de usuarios, y los sistemas necesitan escalar.

Otros no tanto. Esos que te montan una arquitectura hexagonal con tropecientos microservicios y componentes para apps con 20 usuarios.

Las arquitecturas distribuidas tienen sus ventajas, pero también traen consigo mayor complejidad de coordinación, un debugging más difícil y menor velocidad de desarrollo.

La segunda razón son las dependencias excesivas. Se ha pasado a un modelo de desarrollo donde un Hello World pesa 10MB.

Esto me sorprendió bastante con la última app que desarrollé, Deep Focus. Una app de tareas que bloquea las apps que quieras hasta que completes tu trabajo. Es bastante simple, la hice con React Native y pesa 33 MB. Y la versión que estoy desarrollando con sync entre dispositivos ya va por 50.

Todas estas dependencias hacen que las aplicaciones sean más lentas y muchas veces menos seguras. Gran parte de ellas ni siquiera las necesita nuestra app, pero se incluyen en la build porque son dependencias de otras dependencias. Y, a mayor número de ellas, más probable es que aparezcan vulnerabilidades que te afecten.

Otro punto importante es la velocidad de desarrollo. Move Fast and Break Things, decía Mark Zuckerberg. No estoy del todo en contra de esa metodología, pero cuando la llevas al extremo la calidad acaba resintiéndose.

Estamos en un mundo que cada vez quiere ir más rápido. Se premia el contenido basura y las quick wins, y eso se nota también en el software.

Y por último está la IA.

La IA lo acelera todo

Muchos culpan a la IA de todos los males. Pero la IA no hace más que amplificar los comportamientos que ya teníamos en el sector.

Con la llegada de los LLMs, el desarrollo de software se ha vuelto mucho más accesible. Ya es posible crear una web o una app desde cero sin escribir una sóla línea de código.

Esto se ha visto muy claramente con la explosión de apps publicadas en la App Store a finales de 2025.

Pero mayor cantidad no significa mayor calidad. De hecho, suele ser inversamente proporcional, como en este caso.

Se está llenando todo de productos que son clones de otros, sin ningún factor diferencial. La calidad parece no importar, sólo interesa sacar producto tras producto hasta que nos toque la lotería con uno. Como esto fuera un casino.

Además, todo el sector está invirtiendo millonadas en inteligencia artificial. Y tiene que haber algún retorno. Desde las grandes empresas hasta las pequeñas, todas están forzando la adopción de estas herramientas y una mayor velocidad de desarrollo.

En los últimos meses hemos visto cómo grandes plataformas como AWS, GitHub o Cloudflare han tenido caídas enormes.

Y también a empresas más pequeñas, como Claude, que han tenido casi más días con problemas que días buenos.

Están estas caídas inusuales directamente relacionadas con el uso indiscriminado de LLMs para el desarrollo? Es difícil saberlo a ciencia cierta. Pero, sin lugar a duda, es un factor que contribuye a ello.

Qué futuro nos depara?

El futuro es incierto y alberga horrores xD.

Si todo sigue el curso actual, mi apuesta personal es que veremos más caídas y problemas de seguridad en el corto y medio plazo. Y posiblemente más grandes.

Pero también creo que las herramientas mejorarán, la gente se cansará de productos a medio hacer y todo acabará en un cambio de rumbo.

También creo que estamos ante una oportunidad enorme para crear productos con cariño y bien cuidados. Productos que se diferencien por su calidad, en lugar de por la velocidad de desarrollo.

Necesitamos más casos como la Lareira y menos como todo el slop que está inundando la App Store.

Y recuerda echarle un vistazo a mis cursos si quieres aprender más sobre las bases de la ingeniería de software.

Pero esto es un arma de doble filo, y tardé en darme cuenta. Estoy seguro de que mucha gente me veía (y todavía me ve xD) como un pesado.

Suscríbete ahora

Esta entrega de Status 418 está patrocinada por @DanielBlancoSWE (yo xD)

Mis cursos de Udemy están al mejor precio disponible! Aprovecha las rebajas para aprender más sobre las bases de la ingeniería de software.

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Todos tenemos un cierto “crédito político”. Es la confianza que tienes dentro de un grupo para influir en decisiones. Algo que no se ve, pero se siente.

Cada vez que inicias una batalla por cambiar una decisión, gastas parte de ese crédito. Si te quejas demasiado, serás visto como esa persona que siempre protesta por todo, y será más fácil que te ignoren.

Sé que conoces a alguien así, que siempre va en contra del consenso. Y estoy seguro de que te cuesta escucharlo, a pesar de que a veces tenga razón.

Y también conoces el caso contrario. Alguien que pelea lo justo, en situaciones importantes, y suele ser escuchado.

En muchas ocasiones tu opinión es valorada más por la percepción que tienen otros de ti que por la propia opinión. Es duro y un poco ilógico. Pero la psicología humana es así.

Por eso hay que elegir bien las batallas que quieres tomar.

El diseño que se ha propuesto para una funcionalidad crítica tiene problemas? Coméntalo.

El equipo está tardando mucho en revisar las PRs? Háblalo con ellos.

Se ha tomado una decisión que funciona, pero no es tu preferida? Probablemente deberías aceptar que tienes gustos diferentes y dejarlo pasar.

Hay otras formas de influir en la opinión del grupo sin entrar al choque. Por ejemplo, soltar una idea al aire y que se discuta en grupo, sin querer forzar nada. No solo importa el qué, también el cómo.

Tu crédito político también puede aumentar. Si ayudas a otros, tomas decisiones acertadas o lideras proyectos complicados, hará que ganes confianza dentro de la organización. Y, por lo tanto, tendrás más margen para pelear tus batallas.

Somos seres sociales. A pesar de estar en un sector muy técnico, sigue importando mucho cómo te ven otras personas.

Tener razón no sirve de nada si nadie te escucha.

Y recuerda echarle un vistazo a mis cursos si quieres aprender más sobre las bases de la ingeniería de software.

En esta entrega de Status 418 te cuento por qué Irlanda es, de lejos, la mejor opción si eres programador en Europa.

Suscríbete ahora

Esta entrega de Status 418 está patrocinada por @DanielBlancoSWE (yo xD)

Si quieres aprender más sobre las bases de la ingeniería de software y acceder a nuevas oportunidades de trabajo, mis cursos te pueden ayudar!

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Europa tiene varios países donde te puedes ganar muy bien la vida como ingeniero de software. Suiza, Alemania, Países Bajos, Irlanda… Pero la isla esmeralda tiene cosas que ninguno de los anteriores ofrece.

Empresas y sueldos

Gracias en parte a los beneficios fiscales para las empresas (al trabajador lo revientan, en contra de lo que se suele pensar), todas las multinacionales potentes tienen sede en Irlanda.

Uno de los requisitos que pone el gobierno de Irlanda para ofrecer aún más beneficios fiscales es que un gran porcentaje de los empleados europeos trabajen para la sede irlandesa. Esto hace que la demanda de trabajadores sea muy alta, incluso teniendo en cuenta la bajada post-covid.

Los sueldos y beneficios que ofrecen son otro gran punto a favor. No solo hay mucho trabajo, sino que también es relativamente fácil pasar de los 100,000 euros anuales como mid / early senior (4-6 años de experiencia). Y llegar a 200k no es ninguna locura si sigues acumulando experiencia.

En otros países como Suiza puedes encontrar sueldos aún mejores, pero tienen muchas menos empresas. Y las locales valoran el idioma del país.

Cultura de trabajo

Un gran beneficio que pasa desapercibido es la cultura de trabajo que tienen los irlandeses. Toman las cosas buenas de los americanos (menor importancia de la jerarquía, prioridad por buscar la mejor solución al problema venga de donde venga, etc.) y el work-life balance propio de Europa.

En España, sobre todo en empresas más tradicionales, el jefe tiene muchísima importancia todavía. Y en países con cultura germánica, muchísimo peor. Llevar la contraria a alguien superior es casi un crimen xD, y es algo a lo que me habría costado mucho acostumbrarme.

Accesibilidad y la gente en general

Si tienes pasaporte europeo, no hace falta visas. Y si eres de fuera, entrar es relativamente sencillo, son bastante abiertos a extender visas. Eso, y que su idioma sea el inglés, facilita mucho las cosas al empezar.

La gente local es abierta y muy amable. Y hay una comunidad muy grande de emigrantes españoles y latinos en general. Es casi más fácil escuchar español que inglés por la calle xD, lo que hace que te sientas un poco más en casa.

Mi experiencia fuera de lo laboral

No todo en esta vida es el trabajo. Hay otras cosas de Irlanda, tanto buenas como malas que me gustaría destacar sobre mi experiencia.

1 - Encontrar casa es un infierno

Este punto se comenta mucho, pero todo lo que puedas pensar se queda corto. Dublín no es como otras capitales europeas. Es caro, sí. Pero el precio del alquiler no es el mayor problema.

Yo pensaba que al ir con un sueldo superior a la media, podría vivir en un lugar decente sin necesidad de compartir. Fui dos semanas antes para dedicarme a buscar piso full time. Recibía poquísimas respuestas a las decenas de solicitudes que enviaba. Y las que sí me respondían, iba a la visita y había 15 personas más.

Un anuncio salía por la mañana, por la tarde tenía visitas y por la noche estaba alquilado. Era un infierno. Tras bajar las expectativas, conseguí un estudio de ~20 metros cuadrados por 1300 euros al mes. Un auténtico dolor. Al menos la zona resultó ser buena (Rathmines, zona de “ricos” cerca del centro), pero fue pura casualidad porque no filtraba nada.

El tamaño no era lo peor. No estaba nada aislado, era muy frío en invierno, era viejísimo y hasta tuve ratones en casa. Me río ahora, pero en ese momento lo sufrí bastante xDD.

2 - El tiempo no es tan malo

Si eres del norte de España, como yo, te darás cuenta de que en Dublín no llueve tanto como dicen. Como gallego, irme a Dublín fue una mejora. Los inviernos son fríos, pero no suele llegar a bajo cero demasiadas veces. Los veranos son templados, entre 18-21 de máxima normalmente.

El viento y, sobre todo, la falta de sol, fue lo que más sufrí. En invierno el sol no sube nada, como puedes ver en la siguiente foto. Amanece a las 9 y se pone a las 4.

En verano esto está genial, hay sol para repartir. Pero de noviembre a marzo toca sufrir.

3 - Ocio decente pero limitado

Si te gusta la fiesta, Dublín es el paraíso. Es con diferencia el lugar donde mejor me lo pasé de fiesta. En verano, la gente sale a las calles a beber a las 6 de la tarde, y eso se extiende a los bares y discotecas hasta las 3 de la mañana.

También hay montañas y naturaleza al sur de la ciudad. Me pasé muchos fines de semana de senderismo por Bray y alrededores con mi mejor amigo de Irlanda.

Quitando estas dos cosas, tengo que ser honesto. No hay mucho más que hacer en Irlanda. La oferta de ocio es limitada, no hay casi ningún evento, concierto ni nada relevante que pase por la ciudad, ya que todos eligen Londres para eso.

Además, Irlanda es una isla que se cruza en tres horas, por lo que se ven rápido los lugares más emblemáticos. Y necesitas coche sí o sí para ello, el transporte público es una basura.

4 - Burocracia muy simple

Una gran ventaja de Irlanda es que la burocracia es mínima y bastante simple. Llegas, pides el número de seguridad social y listo, no hay que hacer ningún proceso más.

Los impuestos son muy altos, pero la declaración es automática y muy sencilla si tienes que añadir algo más. Y lo mejor de todo es que no te persiguen si cometes algún error, son bastante permisivos.

La lié en un par de ocasiones por no declarar la venta de unas acciones a tiempo y no me multaron ni me acosaron. Simplemente me pidieron que lo corrigiese en la siguiente declaración y listo.

Muy distinto a España y a Austria, y lo echo de menos, la verdad.

5 - Servicios tercermundistas

Lo de tercermundistas quizás sea una exageración, pero no está lejos. La sanidad funciona bastante mal y el transporte público es casi inexistente. En Dublín no hay metro y los buses pasan cuando quieren. El tren es escaso y deficiente.

Si vives fuera de la capital es un horror, necesitas coche sí o sí. En cuanto a infraestructuras y servicios, es un país como lo era España hace 30 o 40 años, sin exagerar. Quizás incluso más.

Conclusión: es un gran país para impulsar tu carrera

Irlanda me cambió la vida, y es un país al que volvería una y mil veces. Crecí como profesional y como persona, conocí a mucha gente que se hizo importante en mi vida y lo pasé genial.

Pero personalmente no podría vivir en él toda la vida. La falta de servicios, el clima y el ocio limitado son factores que para mí no compensan el gran mercado laboral del país. Pero para propulsar tu carrera es, sin duda, el mejor país de Europa, y lo sigo recomendando a todo el mundo!

Has visitado o vivido en Irlanda? Qué opinión tienes del país? Si tienes cualquier duda, no dudes en dejarme un comentario o enviarme un DM, estaré encantado de ayudarte!

Y recuerda echarle un vistazo a mis cursos si quieres aprender más sobre las bases de la ingeniería de software.

Hace unas semanas me comunicaron mi ascenso tras mi segundo performance review, poco más de un año después de haber entrado en la empresa.

En este artículo te cuento cómo funciona el proceso y qué fue lo que más impacto tuvo para conseguirlo.

Suscríbete ahora

Si te interesa profundizar en cómo crecer hasta senior y más allá, en mi curso “El Camino a Senior: Claves para el Éxito como Programador” trato temas que te ayudarán a avanzar hacia ese objetivo:

🔹 Cómo priorizar tareas de alto impacto
🔹 Habilidades técnicas avanzadas: debugging, design docs y gestión de deuda técnica
🔹 Soft skills y crecimiento profesional
🔹 Liderazgo técnico y desarrollo de equipos

Échale un vistazo en https://danielblanco.dev/link/senior. Ya lo han hecho más de 1300 estudiantes, con una valoración media de 4.7 ⭐️

Por qué entré como Mid si ya era Senior

Lo primero que tuve que hacer para entrar en MongoDB fue tragarme un poco mi ego de programador xD. A pesar de llevar más de un año como Senior en Salesforce, no me consideraban como tal en MongoDB. Y como ya me habían rechazado el año anterior al aplicar a un puesto Senior, decidí entrevistarme para el puesto de Mid, L4.

Los niveles varían muchísimo dependiendo de la empresa. En Salesforce existe el título de Lead Software Engineer después del Senior. En MongoDB, no. Aquí se sigue el “estándar” de otras empresas como Google, Meta o Netflix, donde el siguiente nivel es el Staff.

Eso hace que las expectativas de un Senior sean bastante mayores. Y como llevaba poco en ese nivel en Salesforce, Mid era el nivel más adecuado para mí.

Al empezar ya lo ví mucho más claro. Todos los seniors de mi equipo tenían más de 15 años de experiencia y eran muy, muy buenos. Estaba claro que me había flipado bastante al aplicar a ese nivel con apenas 5 años de experiencia en 2023 xD.

Cómo funcionan los ascensos

En la mayoría de empresas medianas y grandes hay dos oportunidades al año para ascender. Una a inicios de año y otra a mediados.

El proceso comienza meses antes. Si demuestras que puedes operar al siguiente nivel, tu manager podrá proponerte como candidato. En ese caso, entre los dos se crea un documento con todos tus logros y pruebas de que cumples con los requisitos.

Además, tu manager tendrá que pedir feedback a compañeros y a otros equipos para respaldar la propuesta.

Cuando termina la recogida de feedback, se pasa a un proceso de calibración. Se compara el rendimiento de todos los ingenieros de la misma organización (un nivel por encima de tu manager), y el proceso termina con una valoración del rendimiento.

Al mismo tiempo, los managers pueden proponer ascensos y, si el director y otros managers de la org están de acuerdo, se envía tu candidatura. Pero esto no significa que el ascenso esté asegurado.

Todos los ascensos pasan a un nivel superior para revisarlos y aprobarlos en caso de que tu candidatura sea fuerte. En mi caso, como llevaba poco tiempo en mi rol y HR suele pedir más tiempo para ascender a alguien, mis jefes tuvieron que luchar para que me lo concedieran.

Qué hice para ascender rápido

Cuando me hicieron la oferta, la recruiter me dijo que no podían asignarme el nivel de Senior todavía, pero que podría ascender rápido porque el equipo me había visto como un L4 fuerte.

Aunque todo lo que te digan antes de firmar la oferta debería tomarse como palabras vacías, me puse manos a la obra para demostrar que podía ascender rápido.

Clave 1: Las primeras impresiones cuentan mucho

Como bien dijo el Xokas, “so never get a second chance to make a first impression” xD. Las primeras impresiones son difíciles de cambiar, y hacer un esfuerzo extra al principio puede darte un rédito futuro muy valioso.

Hice el onboarding lo antes posible y me centré en aprender a fondo nuestro producto, Ops Manager. Es más importante conocer el qué y el por qué lo hace que el cómo. En un proyecto tan grande es fácil perderse en los detalles técnicos, y es imposible saberlo todo.

Además, completé pronto las primeras tareas que me asignaron y, sin que me lo pidieran, ayudé a desbloquear la actualización a Ubuntu 24.04 que estaba bloqueada por un bug bastante complejo.

Clave 2: Trabajar en proyectos relevantes

Al principio es normal que te asignen proyectos poco a poco. Pero si quieres ascender, necesitas visibilidad. Como quería demostrar mi valía, le pedí directamente a my manager que me asignara como líder de un primer proyecto.

Como había causado una muy buena primera impresión, mi manager confiaba en mí y me asignó un proyecto para enviar las alertas de la plataforma vía webhook. Hice la investigación inicial, definí el scope, el design doc y completé la implementación y el release de la funcionalidad.

También tuve la oportunidad de asistir a varias llamadas con nuestro cliente más importante, lo que me dio muchísima visibilidad.

Como pude liderar ese primer proyecto sin problemas y de forma autónoma, a partir de ahí me siguieron asignando proyectos cada vez más grandes e importantes.

Clave 3: Pedir el ascenso

Mucha gente espera que los ascensos lleguen por sí solos. Y, a pesar de que en algunos casos acaban llegando, no es la mejor estrategia posible. Dejar claras tus intenciones a tu manager también es muy importante, ya que va a ayudarte a establecer unas expectativas para lograrlo.

Además, de esta forma tu manager sabe lo que buscas y lo que quieres, y puede ayudarte a conseguirlo dándote ciertos proyectos con mayor visibilidad, ofreciéndote consejos o conectándote con otros equipos importantes.

Pedir el ascenso no significa exigir nada. Es solo dejar claras las expectativas.

Clave 4: Crear conexiones

Es tan importante tu rendimiento como que otras personas tengan una buena opinión de ti. Por muy bueno que seas, si otras personas no lo consideran así va a ser difícil progresar.

A mí personalmente me gusta mucho ayudar cuando alguien tiene problemas, aunque eso signifique “perder” tiempo de mis proyectos. Ser de los primeros en ofrecer ayuda hizo que mucha gente distinta me considerara como alguien resolutivo, lo que me llevó a recibir muy buen feedback de compañeros y otros equipos.

También me ayudó mucho buscar proyectos que involucraran a diferentes equipos, ya que te dan mucha más visibilidad y te permiten construir relaciones con más gente dentro de la empresa.

Cómo es el proceso de ascensos en tu empresa? Me interesa mucho leer tu experiencia en los comentarios!

Y recuerda echarle un vistazo a mi curso “El Camino a Senior: Claves para el Éxito como Programador” si quieres aprender las claves parallegar a senior y más allá!

Después de hacer decenas de entrevistas, puedo decir que me siento cómodo en ellas. Sigo nervioso, sí. Pero ya no me bloqueo, puedo seguir una estructura y llegar a soluciones aceptables en la mayoría de casos.

Hace unas semanas te contaba cómo me preparé para entrar en empresas americanas. Hoy entramos en detalle en las entrevistas de live coding, explicando todo lo que he hecho para superar ejercicios de Google, Amazon, Stripe o MongoDB, entre otros.

Suscríbete ahora

En mi curso Algoritmos, Estructuras de Datos y Entrevistas de Programación cubro todo el proceso desde cero, con más de 50 ejercicios reales:

• Complejidad algorítmica (Big O)

• Estructuras de Datos (tablas hash, linked list, stack, queue, tree, graph, heaps y tries)

• Recursividad y programación dinámica.

• Algoritmos de ordenamiento y búsqueda

• Mejora tu CV y cómo aplicar a vacantes de empleo.

Qué evalúan realmente en estas entrevistas

Mucha gente cree que lo que más cuenta en estas entrevistas es llegar a la mejor solución posible. Y si es sin ayuda, mejor.

Si bien es cierto que eso suma, no es lo más importante. Lo que más se valora es la comunicación, el razonamiento, la capacidad de adaptación y colaboración con el entrevistador y los conocimientos que tengas de las bases de la ingeniería de software.

Me han rechazado en entrevistas que resolví perfectamente, llegando a la solución óptima, por falta de comunicación. Y he pasado procesos en los que no pude llegar a la mejor solución, pero donde la colaboración fue muy buena.

1. Introducción (5-10 min)

La entrevista suele empezar con una fase de introducción que dura unos 5-10 minutos. Para esto, debes preparar un resumen de tu carrera, tus logros y tu puesto actual en un par de minutos como máximo. Enfatizo lo de preparar. Es la pregunta más típica y te va a ayudar llevarla lista.

Es importante no demorarse mucho en esto, ya que es una entrevista técnica y es fácil que el entrevistador pierda el hilo si sueltas demasiada información.

2. Presentación del problema y propuesta de primera solución (10-15 min)

A continuación, te presentan el problema y te dan un tiempo para que lo leas. No intentes ir con prisa y, bajo ningún concepto, pienses en tirar código todavía.

Léelo con calma y haz todas las preguntas que necesites. Hay cosas que pueden parecer obvias, pero si no están especificadas en los requisitos es mejor preguntar para establecer el alcance del problema.

Aquí llega el momento de proponer una primera solución. No tiene que ser la más óptima. Mucha gente se queda bloqueada en este punto por querer dar la mejor respuesta posible. Una solución subóptima es mil veces mejor que un folio en blanco.

Lo más importante es hablar mucho. El entrevistador no puede leer tu mente, y una de las cosas que quiere evaluar es cómo piensas. Además, si sabe lo que estás pensando, podrá darte pistas para resolver el ejercicio.

3. Optimización y escribir el código (20 min)

Una vez tenemos una primera solución que resuelve el ejercicio, es hora de optimizarla. Hasta este momento no has escrito ni una línea de código. Ha sido una conversación con el entrevistador y notas en texto plano.

Analiza la complejidad algorítmica de tu solución e intenta estimar cuál sería el Big O óptimo. Si te quedas bloqueado, puedes hacer un brainstorming de los algoritmos y estructuras de datos más comunes, ya que pueden ayudarte a optimizar la solución.

Una vez llegas a un acuerdo con el entrevistador, es hora de programar. Intenta escribir código lo más legible y sintácticamente correcto posible, pero esto no es lo que más se valora. Se entiende que el tiempo es muy limitado, por lo que no importa si cometes algún fallo de sintaxis o si no te acuerdas de alguna función.

Al acabar, repásalo y “ejecuta” ejemplos de forma manual en él, para comprobar que todo funciona como esperas. Si encuentras algún bug, coméntalo y soluciónalo si te da tiempo.

4. Cierre y preguntas (10-15 min)

Dependiendo del tiempo que te quede, el entrevistador puede hacerte más preguntas o dejarte hacer unos comentarios finales. Aquí puedes comentar aspectos que tendrías en cuenta, pero para los que no hay tiempo en una entrevista así: logging, métricas, tests, calidad del código, etc.

Finalmente, aprovecha la oportunidad para hacer buenas preguntas sobre el equipo y la empresa. Es un detalle que suma y puede marcar la diferencia si muestras interés real por la oportunidad.

Mi proceso de preparación

Si has llegado aquí, gracias por aguantar la chapa xD. Pero es muy importante conocer la estructura de estas entrevistas y lo que se valora, para entender cómo se preparan.

Complejidad Algorítmica

El concepto más importante para llegar a soluciones óptimas es el Big O. Te lo van a pedir y, aunque no lo hagan directamente, se asume que debes mencionarlo. Si no lo haces, penaliza.

No tienes que entrar en todas las matemáticas de la definición formal. De hecho, me sigue asustando echar un vistazo a la página de Wikipedia xD. Lo que sí tienes que conocer son las complejidades más comunes y cuándo se dan:

Complejidad Constante O(1). No importa el tamaño de entrada, el número de operaciones siempre es el mismo.

Complejidad logarítmica O(log n). Se da cuando el problema se reduce a una fracción del tamaño original en cada paso. Un ejemplo típico es la búsqueda binaria.

Complejidad lineal O(n). Algoritmos que crecen al mismo tiempo que la entrada.

• Complejidad log-lineal O(n log n). Crecen a mayor ritmo que la lineal pero menos que la cuadrática. Son muy comunes en algoritmos de ordenamiento eficientes como quicksort o mergesort.

• Complejidad cuadrática O(n^2). Se dan normalmente cuando tienes bucles anidados que recorren un mismo conjunto.

Complejidad Exponencial O(2^n). El número de operaciones se duplica cada vez que aumenta el tamaño de entrada.

Complejidad factorial O(n!). Se dan en algoritmos que deben explorar todas las permutaciones posibles de los elementos.

Ninguna complejidad es mala por sí misma, todo depende del problema que estés resolviendo. Pero en estas entrevistas técnicas, cuando una solución tiene complejidad cuadrática o mayor, normalmente es una señal de que el algoritmo puede optimizarse.

Estructuras de Datos y Algoritmos

El siguiente paso en mi preparación fue repasar todas las estructuras de datos que ya había visto en la universidad, pero que mi memoria había descartado xD. Primero de forma teórica y, a continuación, con ejercicios específicos para cada una de ellas.

Como ya he comentado muchas veces, yo seguí Cracking the Coding Interview, que ya tiene ejercicios específicos para cada estructura. Pero si no quieres pagar por libros o cursos, recomiendo mucho que busques en LeetCode, ya que puedes filtrar por el tipo de ejercicio.

En esta primera fase hacía 4-5 ejercicios easy y 1-2 medium. Para algunas estructuras, como trees, graphs y heaps también creaba una implementación propia para repasar la lógica interna, aunque esto no me aportó demasiado.

Sé que hay muchos temas, y puede agobiar un poco. En mi caso, el orden que seguí fue el siguiente:

1. Arrays, Strings y Hash Tables

2. Linked List

3. Stacks y Queues

4. Trees y Graphs

5. Heaps

6. Tries

7. Recursividad y Programación Dinámica

8. Algoritmos de Ordenamiento y Búsqueda

9. Manipulación de Bits

Tras cientos de entrevistas que he hecho como entrevistador y entrevistado, las más relevantes son sin duda los grafos y árboles, heaps, y la recursividad y programación dinámica.

Las que menos útiles me han resultado son los algoritmos de ordenamiento, ya que es rarísimo que te pidan implementar quicksort o merge sort a mano en una entrevista así, y la manipulación de bits, porque son ejercicios muy específicos, poco intuitivos y que en general se piden poquísimo (en mi caso nunca me pidieron uno).

Ejercicios y claves

Cuando filtras por tipo, se elimina uno de los mayores retos que tienen estos ejercicios: identificar qué estructuras de datos y patrones pueden ser útiles para llegar a la mejor solución.

Por eso, mi siguiente paso fue hacer ejercicios aleatorios en LeetCode. No es necesario hacer cientos de ejercicios para empezar a pasar este tipo de entrevistas, pero sí hace falta bastante práctica.

Al contrario de lo que se suele pensar, no hace falta hacer los hard sin sufrir. En mi experiencia, es más productivo enfocarse en los medium. Y, como puedes ver en la distribución de ejercicios, fue en lo que más me centré.

Cuando empecé, seguía listas recomendadas que encontraba por blogs, pero ahora LeetCode tiene rutas de estudio. Recomiendo hacer la Top 150, pero si no tienes tanto tiempo la Top 75 también es muy buena. Elige un problema y haz click en botón de aleatorio, porque si no ya sabes de antemano qué tipo de problema estás resolviendo.

Tras cientos de horas practicando y muchas entrevistas, estas son las claves que más me ayudaron a mejorar.

Clave 1: Esto es un maratón, no un sprint

De nada sirve hacer diez ejercicios un día si no abres LeetCode el resto de la semana. Tu cerebro necesita tiempo para asimilar estos problemas, y si los rusheas no vas a conseguirlo. Ponte como objetivo hacer al menos un ejercicio al día, pero dedicándole su tiempo. Yo siempre intento hacer tres al día en mis épocas de entrevistas.

Clave 2: No te rindas a la primera de cambio

Ver la solución sin luchar por resolver un ejercicio es tiempo perdido. Lo que yo suelo hacer es poner un temporizador con 40 minutos, que es lo que normalmente te dan en las entrevistas. Si en ese tiempo sigo sin tener ni idea de cómo resolverlo, echo un vistazo a las pistas. Y si las pistas no ayudan, 15-30 minutos más tarde voy a la solución.

Clave 3: No te dejes llevar por el nivel de dificultad

Va a llegar algún momento en el que te vas a frustrar, pero es importante no dejarte llevar por el nivel de dificultad. Es súper común encontrarse con ejercicios supuestamente fáciles en los que cuesta encontrar la mejor solución, y ejercicios difíciles que se resuelven en 10 minutos.

Clave 4: Aplica mientras te preparas

No esperes a estar cómodo para empezar a aplicar a ofertas, porque nunca lo vas a estar. Yo me sigo poniendo nervioso con estas pruebas hoy en día, después de toda mi experiencia. Además, en las entrevistas es donde más se aprende y se mejora, ya que es la única forma de practicar con la presión real.

Clave 5: Repite problemas después de unos días.

Especialmente si un ejercicio te costó o no pudiste resolverlo, no lo dejes aparcado. Vuelve a intentarlo unos días después.

Clave 6: Practica en voz alta

La única forma de practicar en un entorno real es con una entrevista. Pero eso no significa que no podamos simular cómo sería una. Intenta pensar en voz alta durante todo el ejercicio para que cuando llegue la entrevista te salga de forma más natural.

Clave 7: Practica con otras personas

Si tienes amigos o conocidos que también se están preparando, aprovéchalo y practica con ellos. Una vez uno hace de entrevistador y otra vez de entrevistado. Si no, también puedes buscar gente en foros como Reddit que busca compañeros para practicar, aunque sinceramente, yo nunca lo hice por vergüenza xD.

Clave 8: Fíjate en los patrones

Hay miles de ejercicios que te pueden caer, pero todos tienen ciertos patrones o técnicas para resolverlos de forma eficiente: sliding window, two pointers, BFS/DFS, backtracking, etc. Cuando empiezas a reconocer estos patrones, muchos problemas dejan de parecer tan distintos entre sí. No memorices ejercicios concretos, céntrate en entender bien estos enfoques y cuándo aplicarlos.

En resumen: mucho tiempo, pero buen retorno

No te voy a mentir. Preparar estas entrevistas por primera vez es un dolor de cabeza. Se necesita invertir mucho tiempo y pasar por entrevistas que son estresantes.

Pero también tiene su lado positivo. Una vez lo haces, las siguientes veces es bastante sencillo y rápido volver a prepararlas (normalmente yo repaso una semana y empiezo a aplicar). Además, es un proceso muy estructurado y sabes lo que te espera, a diferencia de otras entrevistas técnicas donde pueden preguntarte cualquier cosa.

Esta forma de evaluar candidatos sigue siendo la preferida por empresas estadounidenses o extranjeras en general, por lo fáciles que son de hacer y escalar. Y el sueldo que ofrecen suele ser razón suficiente como para que, en mi opinión, compense prepararlas!

Y si te interesa preparar este tipo de entrevistas de forma más guiada, recuerda echarle un vistazo a mi curso Algoritmos, Estructuras de Datos y Entrevistas de Programación, donde cubro toda la teoría, el CV y más de 50 ejercicios reales.

Desplegamos una nueva web en el CRM interno en Salesforce, y como todo se veía bien cerré el portátil y me fui a dar un paseo. Al volver, tenía miles de mensajes y correos. Recibía tantos que mi cuenta de Gmail se bloqueó, mi Slack iba a pedales y el sistema de seguridad anti-spam de la empresa se cayó.

No tenía ni idea de la que había liado, y mi equipo ya estaba trabajando en ello para parchear la situación lo antes posible.

Suscríbete ahora

Esta entrega de Status 418 está patrocinada por @DanielBlancoSWE (yo xD)

Mis cursos de Udemy están al mejor precio disponible! Aprovecha las rebajas para aprender más sobre las bases de la ingeniería de software.

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

El preludio

Estábamos construyendo un buscador interno para todo lo que necesitaban los empleados de Salesforce. Para ello, se integraba con el CRM de la empresa para obtener información de todo tipo.

Para esa web se usaron tecnologías relativamente modernas, casi todo Java y React. Se hacían llamadas a las APIs de la plataforma para obtener la información necesaria. Pero, para ciertas funcionalidades, eso no era suficiente.

Una de esas funcionalidades era el chat de soporte. Si tenías alguna urgencia, como por ejemplo problemas con tu portátil, podías abrir un chat directamente con el servicio técnico. Salesforce proporciona esta funcionalidad de forma nativa en la plataforma, pero no a través de APIs.

Para implementar esta funcionalidad me asignaron a mí. Con cero experiencia como desarrollador de Salesforce a mis espaldas, no fue una tarea sencilla. La solución final fue implementar un Salesforce Site (web nativa de la plataforma) únicamente con el código necesario para que el chat de soporte cargase, y después incrustarlo en nuestra web principal mediante un iframe.

Cuando se completó el trabajo, se desplegó a producción el site nativo antes de lanzar nuestra plataforma.

El día D

Llego del paseo y entro en panic mode. ¿Por qué estaba recibiendo mensajes y correos de miles de empleados sin parar? Me conecto a la llamada con mi equipo y me explican la situación.

Se había enviado un correo a los 80,000 empleados de Salesforce de forma automática al desplegar el site. Resulta que los sites nativos de Salesforce tienen una opción por defecto de enviar un email de bienvenida a los usuarios con acceso (en nuestro caso, toda la empresa). Hasta el CEO, Marc Benioff, recibió mi correo electrónico.

Para empeorar la situación, el nombre de la web era bastante críptico, la plantilla de bienvenida era la predeterminada y los correos salían a mi nombre, pero con un dominio custom, porque había sido yo quien desplegó esa web. Eso hizo que los usuarios reportaran el email y, de tantos reportes y respuestas a mi correo, el sistema de seguridad interno se cayó.

El equipo, lejos de buscar culpables, se puso manos a la obra para solucionar el problema. Mi manager habló con el equipo de seguridad para que descartasen un posible ataque, y contactó con un compañero que tenía acceso a producción en Google Workspace para eliminar el correo de la bandeja de entrada de los empleados y así evitar que el caos siguiera aumentando.

Yo me puse a analizar si podría haber otros casos en los que se enviasen correos electrónicos automáticos desde el site. Por suerte, encontré un par de casos antes de que causaran más problemas. Los desactivamos y desplegamos el parche al momento en producción.

Qué saqué de este incidente

Afortunadamente, el daño causado fue muy pequeño porque los usuarios eran solamente internos de la empresa. Pero, si en lugar de ser un site interno, hubiera sido algo con clientes reales de Salesforce, el daño reputacional podría haber sido mayor.

Es imposible saber lo que no sabes. Al ser nuevo en el desarrollo de Salesforce, era difícil que supiese que existían esos correos automáticos. La mayor lección aprendida fue que toda precaución es poca cuando tratas con algo nuevo. Y más aún, cuando es un despliegue a tal escala.

En lugar de desplegar el site con todos los usuarios asignados, habría sido más inteligente hacer una prueba con nuestro equipo únicamente, y testear todo más a fondo. Nosotros sólo hicimos pruebas en QA, donde esos correos estaban desactivados por defecto.

Otro punto que me llevé de esta experiencia es la importancia de tener un equipo que te apoye. Nunca nadie me echó la culpa. Al contrario, me animaron y me ayudaron desde el primer minuto. Me recordaron también que el desarrollo de software es un trabajo de equipo y, aunque uno pueda provocar directamente un problema, el equipo también es responsable de revisar.

Sigo pensando que no se deberían prohibir despliegues los viernes. Pero a partir de ese momento también sé por qué muchos equipos deciden no hacerlo xD

Y recuerda echarle un vistazo a mis cursos para aprender más sobre las bases de la ingeniería de software.

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Y es que, desde que trabajo en empresas americanas, sólo una parte del sueldo es fijo. El resto depende de componentes que cambian cada año, o incluso a diario.

Esto hace que el número que firmas en tu oferta no sea realmente el que vas a cobrar. Puedes aceptar una oferta de 120k y cobrar menos el primer año, o bastante más a partir del segundo.

En esta entrega te cuento cómo funcionan realmente estos sueldos y qué estás firmando cuando aceptas una oferta.

Suscríbete ahora

Esta entrega de Status 418 está patrocinada por @DanielBlancoSWE (yo xD)

Si te interesa entrar en empresas extranjeras, tengo dos cursos donde explico en detalle cómo prepararse estos procesos:

🔹 Algoritmos, Estructuras de Datos y Entrevistas de Programación: cubro las pruebas de Live Coding, además de consejos para el CV y cómo aplicar.

🔹 Diseño de Sistemas a Gran Escala: enfocado en entrevistas de System Design, muy comunes para roles mid y senior.

Qué me encontré al recibir mi primera oferta de Salesforce

Cuando el recruiter me llamó para decirme que el equipo quería extenderme una oferta, empezó a soltarme números por todos lados. Que si sueldo base, bonus, sign-on bonus, acciones… Hasta ese momento sólo había cobrado sueldo fijo, y todas estas variables me sonaban a chino.

Al final me dijo que tendría una total compensation cercana a los 100k, y qué opinaba de ello. Eso en mi cabeza sonaba a “voy a cobrar 100k, qué locura”, sin saber que el ~30% del sueldo no era fijo (y sin saber que pagaría 1300 euros al mes por un cuchitril de 20m2 en Dublín, pero ese es un tema que dejaremos para otro día xD).

Y es que esa compensación total es sólo una estimación. Parte de ella ni siquiera la cobras el primer año, y depende de variables que no controlas, puede variar mucho. Firmé una oferta cercana a los 100k, pero eso no significaba que fuera a cobrar 100k.

RSUs y vesting: por qué el primer año cobras menos

La principal razón por la que el sueldo en empresas americanas que cotizan en bolsa varía tanto son las Restricted Stock Units (RSUs).

Al firmar el contrato, te ofrecen X dólares en acciones. Por poner un ejemplo, imaginemos que son $100,000. A las pocas semanas de empezar, te asignan un número de acciones. Si la acción de la empresa cotiza a $100 te asignan 1000 acciones. Si cotiza a $500 te asignan 200, etc.

Pero esas acciones no pasan a ser tuyas de golpe. Se liberan poco a poco durante los siguientes 4 años, siempre que sigas en la empresa.

Ese momento en el que un porcentaje de tu paquete pasa a tu disposición se llama vesting. Normalmente, recibes las primeras acciones un año después de entrar a la empresa, y posteriormente cada tres meses, hasta completar el total asignado.

En el momento del vesting las acciones son tuyas y puedes decidir venderlas o mantenerlas. Y aquí viene el tema: si el precio ha subido de $100 a $200, por ejemplo, estarías vendiendo esa parte del paquete al doble de lo que te ofrecieron en el contrato. Pero si la acción está en $50, las vendes a la mitad.

Las acciones, especialmente las tecnológicas, suelen ser muy volátiles. Eso significa que en cuatro años el valor puede ser muy distinto a lo que ponía en el contrato, para bien o para mal. Yo tuve mala suerte al entrar en 2021 en máximos, justo antes de la caída en 2022.

Bonus y sign-on

El sign-on bonus es una parte importante del TC del primer año. Es un bonus único, que recibes al empezar y que está condicionado a superar el período de prueba.

Además están los bonus anuales, que suelen ser del 10% al 20% del salario base dependiendo del nivel. De nuevo, te lo venden como algo “seguro”, pero nada más lejos de la realidad.

El primer año “sólo” recibí un 6% porque a la empresa no le fue del todo bien. Otros años me dieron el 9% y el 11%. También varían en función de tu rendimiento, pero al menos en mi experiencia tienen mucho más peso los resultados de la empresa.

Refreshers

Como las acciones que te dan al entrar se acaban a los cuatro años, muchas empresas ofrecen las llamadas refreshers. Estos son paquetes de RSUs que se reparten de nuevo en cuatro años.

Suelen ser más pequeños que el paquete inicial, y se asignan anualmente en función de tu rendimiento. Pero en casos especiales, como ascensos, pueden ser incluso más grandes.

Siguen la misma lógica: se calcula un precio inicial y se libera un porcentaje cada cierto tiempo.

De nuevo, otra variable en la que influye mucho la suerte. A mí, por ejemplo, me dieron refreshers en el mínimo, y las pude vender por bastante más.

ESPP

Casi me olvido de un último detalle xD. La gran mayoría de empresas ofrece también el Employee Stock Purchase Plan (ESPP).

Cada mes te retienen un porcentaje de tu sueldo base, normalmente hasta un 15%. A los seis meses, ese dinero se utiliza para comprar acciones de la empresa con descuento, normalmente también del 15%.

Además, se establecen dos precios: el precio al inicio de esos seis meses, y el actual. Se elige el menor, y a ese precio se le aplica el descuento. Si decides venderlas al momento, obtienes siempre un beneficio inmediato.

Se infravalora bastante, pero si la acción sube mucho en esos seis meses puedes llevarte un buen pellizco. Hay empleados de NVIDIA que ganaron cientos de miles sólo con los ESPP cuando la acción subió tanto.

¿Todo lo que no es sueldo base es humo?

Escribo esta entrega para explicar el tema mejor después de bastantes debates que tuve por Twitter, donde mucha gente rechaza todo tipo de compensación variable porque “no es sueldo que entra todos los meses”.

Eso es cierto. Pero en la práctica, las empresas que ofrecen estos beneficios suelen ofrecer también sueldos base más altos.

Cuando emigré a Irlanda, un mid podía cobrar 60k-70k en empresas locales. Las empresas americanas ofrecían 75k-85k de sueldo base, y más de 100k de compensación total sumando el resto de beneficios.

Es cierto que hay que mantener las expectativas realistas para no llevarse decepciones. Pero ignorar completamente este tipo de compensación variable, en mi opinión, es pegarse un tiro en el pie.

Y recuerda echarle un vistazo a mis cursos si te interesa entrar en empresas extranjeras:

🔹 Algoritmos, Estructuras de Datos y Entrevistas de Programación: cubro las pruebas de Live Coding, además de consejos para el CV y cómo aplicar.

🔹 Diseño de Sistemas a Gran Escala: enfocado en entrevistas de System Design, muy comunes para roles mid y senior.

Sam Altman reaccionó rápidamente en X. Primero diciendo que los anuncios son muy buenos y que se había reído con ellos, para después atacar de vuelta con un texto de 420 palabras. “Más gente usa ChatGPT gratis en Texas que todos los usuarios de Claude en Estados Unidos. Tenemos un problema distinto”, decía Altman, entre otras cosas.

Este es sólo uno de los muchos choques públicos entre las dos compañías punteras en IA. En este artículo recorro la historia de OpenAI y Anthropic y cómo dos visiones distintas están compitiendo en el mismo espacio.

Suscríbete ahora

Esta entrega de Status 418 está patrocinada por Deep Focus.

Bloquea distracciones hasta completar tus tareas.

• Elige qué apps y webs bloquear.

• Añade tus tareas.

• Las distracciones no se desbloquean hasta que las completes!

Con modo Pomodoro e integración con tus tareas de Notion.

Disponible para iOS. Descárgala ya en la App Store.

Los inicios de Anthropic

Anthropic nace en enero de 2021 cuando un grupo de 11 investigadores clave de OpenAI decide marcharse de la empresa. Entre ellos, Dario Amodei (ex-VP de Investigación en OpenAI y actual CEO de Anthropic) y su hermana Daniela Amodei.

Decidieron salir de OpenAI porque sentían que, tras el acuerdo con Microsoft, se priorizaba demasiado la velocidad de desarrollo, dejando de lado la seguridad. Crearon una nueva empresa con los siguientes objetivos:

• La seguridad como mayor prioridad: El crecimiento estaría controlado, sacrificando velocidad de iteración para ofrecer productos realmente seguros.

• El concepto de IA Constitucional: En lugar de depender únicamente del feedback humano para la revisión de respuestas, querían crear un conjunto de principios que el propio modelo utilizaría para auto-evaluarse y corregir su comportamiento.

• Mantener la gobernanza: Para evitar las presiones de los inversores, Anthropic crearía un consejo independiente para vigilar la ética, con poder para vetar decisiones.

Este enfoque sentó las bases de una empresa muy distinta a OpenAI (al menos en la teoría, la práctica vino después xD). En marzo de 2023, dos años después de fundar la empresa, anunciaban oficialmente Claude.

La realidad: Anthropic no es una ONG

La teoría suena muy bonita, pero en la práctica, Anthropic es una empresa. Su principal objetivo es crecer, ganar dinero y, si es posible, aplastar a la competencia en el camino.

A pesar de que su mayor objetivo sobre el papel sea sacrificar velocidad de desarrollo en favor de la seguridad, sus avances son igual o incluso más rápidos que los de OpenAI.

El CEO es una de las principales figuras mundiales que defiende que, en 6 a 12 meses, se acabarán los Ingenieros de Software. Pocas intenciones de “sacrificar velocidad de desarrollo” veo aquí xD.

Además, Anthropic ha tomado una serie de decisiones polémicas que van en contra de los usuarios finales.

Por ejemplo, la limitación de sus APIs en plataformas de terceros como OpenCode, prohibiendo las integraciones externas. En contraste, OpenAI lanzó Codex como un proyecto Open Source y permite utilizar sus APIs desde cualquier entorno.

Lo mismo ocurre con su enfoque de tener una forma propietaria de hacer todo: un CLAUDE.md en lugar del estándar AGENTS.md, estructuras específicas de skills o APIs. Mientras que OpenAI suele tirar más a estándares que facilitan la interoperabilidad.

OpenAI y el problema de la escala

El modelo de negocio de Anthropic está muy enfocado en desarrolladores, especialmente tirando hacia enterprise. Busca intencionalmente vender menos, pero sacar mayores márgenes de ello.

El objetivo de OpenAI es muy distinto. Buscan ser la IA que usan tus padres. El modelo de negocio está más centrado en consumidores finales que en empresas. Eso implica crecer más, necesitar más inversión y, como consecuencia, tener más presión de tus inversores.

En 2024, Sam Altman decía en una conferencia que la publicidad sería el último recurso que utilizaría como modelo de negocio, y sólo lo usaría si fuera la única forma de conseguir que todo el mundo tuviera acceso a buenos servicios.

Año y medio después, OpenAI anuncia que incluirá anuncios en los planes gratuitos y Go (un nuevo plan de $8 al mes). Es el precio a pagar cuando quieres crecer a ese ritmo, recaudando 60.000 millones de dólares y buscando una nueva ronda de 100.000 millones.

Además, en 2025, tuvo su mayor polémica hasta el momento. La empresa pasó de ser un laboratorio de investigación con beneficios limitados que buscaba “el bien de la humanidad”, a una empresa comercial que puede dar retornos ilimitados a sus inversores (Microsoft, SoftBank y compañía)

Anthropic puede evitar hoy ese tipo de decisiones porque aún no juega en esa liga (como bien les recordó Sam en su respuesta).

Dos visiones, el mismo destino

En resumen, aquí no hay ni buenos ni malos.

Por un lado, Anthropic seguirá intentando posicionarse como la opción más segura y ética, que no busca un avance loco sacrificando lo anterior.

Por otro lado, OpenAI seguirá apostando por ser la opción del pueblo, con el objetivo de hacer que sus servicios lleguen a la mayor cantidad de gente posible.

Pero en el fondo, ambas son empresas. Y por mucho que intenten desacreditarse entre ellas en esta guerra no tan fría, las dos tienen sus propias costuras que resolver. Son empresas financiadas por miles de millones de capital externo. Y como cualquier empresa respaldada por VCs, les deben fidelidad a ellos, no a los usuarios finales.

Y recuerda probar Deep Focus si quieres dejar de lado tus distracciones mientras trabajas.

Seis años después he trabajado en Salesforce y MongoDB, y he pasado procesos de entrevistas con empresas como Google, Stripe o Amazon.

El cambio no fue solo salarial. Al contrario de lo que se suele pensar, la presión bajó mucho y los proyectos en los que trabajé fueron bastante más interesantes y útiles para mi crecimiento.

En esta entrega te cuento cómo me preparé para esas entrevistas y cómo conseguí perderles el miedo.

Suscríbete ahora

Cómo fueron mis inicios

Tenía claro que quería irme de España para mejorar profesionalmente y por disfrutar de la experiencia. Al principio empecé aplicando sin ton ni son a todo lo que encontraba por LinkedIn.

Yo creía que no tenía que prepararme nada. Pensaba que tenía que contar mi experiencia en la entrevista y que, si les encajaba, me acabarían haciendo una oferta. Grave error.

Las primeras 10-20 entrevistas fueron un auténtico desastre. Las pocas que pasé de la ronda de RRHH terminaron en la primera entrevista técnica, donde me destrozaron. Y lo peor es que no era consciente de que estaba haciendo algo mal.

De casualidad, una noche encontré un hilo en Forocoches, de un chico que trabajaba para Twitch en Silicon Valley. Sus inicios eran muy similares a los míos: consultora pequeña en España y cansado del sector. Y ahora cobraba $600k anuales en Twitch.

Le escribí para preguntarle cómo lo había hecho y su respuesta fue clara: las entrevistas hay que prepararlas. Me pasó material y, en ese momento, me cambió el chip y me puse manos a la obra.

Entrevistas de algoritmos y estructuras de datos

A pesar de que a muchos no les gustan, las entrevistas del estilo “LeetCode” siguen siendo las más utilizadas en las entrevistas técnicas de empresas anglosajonas.

Si has pasado por la universidad es probable que ya tengas una buena base de algoritmos y estructuras de datos. Pero aún así, estos ejercicios hay que prepararlos de forma específica.

Yo tenía una base muy floja y me sirvió un montón el libro Cracking the Coding Interview. Lo compré en físico y fue la mejor inversión de mi vida.

Para prepararlas, seguí los siguientes pasos:

1. Repasar la complejidad algorítmica (Big O) y hacer los ejercicios del libro

2. Repasar todas las estructuras de datos y hacer ejercicios concretos para cada una de ellas: Arrays, Linked Lists, Queues, Stacks, Trees, Graphs, Heaps y Tries

3. Ejercicios sobre Recursion y Dynamic Programming

4. Ejercicios aleatorios del libro y de LeetCode

De Abril a finales de Julio del 2021 me preparé casi a diario con los ejercicios del libro, dedicando una media de ~15-20 horas semanales.

Al sentirme cómodo con los ejercicios del libro pasé a LeetCode, donde seguí haciendo ejercicios hasta principios de septiembre.

Al mismo tiempo que hacía LeetCode, a partir de Julio empecé a aplicar a empresas y a hacer mis primeras entrevistas. En Septiembre conseguí una oferta de Salesforce y en Octubre del 2021 me mudé a Irlanda 🇮🇪

No os voy a mentir, fue un proceso duro. Muchas horas invertidas en aprender una habilidad que no se practica ni en la universidad ni en el trabajo. Se convirtió en un trabajo a tiempo parcial en sí mismo.

Las siguientes veces que me preparé es cierto que ya necesité muchos menos días para sentirme cómodo, normalmente sobre 3-4 semanas.

Entrevistas de System Design

Para roles senior (e incluso mid en muchos casos), preparar sólo algoritmos no es suficiente. Tendrás que pasar una ronda en la que te piden diseñar sistemas grandes a alto nivel, como Uber, WhatsApp, YouTube, tinyURL, etc.

Aunque sigue siendo un reto importante, este tipo de entrevistas se parecen mucho más al trabajo real. No te van a pedir la solución perfecta, sino ver cómo piensas, cómo priorizas y cómo comunicas decisiones.

El libro que más me ayudó fue System Design Interview – An Insider’s Guide, de Alex Xu. Sobre todo porque me enseñó a estructurar la conversación y a no perderme con el tiempo tan limitado que te dan. En estas entrevistas si no sigues una buena estructura es muy fácil quedarte sin tiempo y no haber mostrado nada interesante.

Mi enfoque siempre es el siguiente: primero aclarar bien el alcance, después hacer estimaciones rápidas para definir el alcance del problema (usuarios, QPS, almacenamiento, etc.) y después hablar del diseño a alto nivel. Antes de profundizar en nada, hay que estar alineado con el entrevistador.

A partir de ahí, elijo una o dos partes críticas del sistema y profundizo en ellas, explicando decisiones y trade-offs. Es preferible cubrir bien pocas cosas que mencionar muchas por encima.

Si queda tiempo al final, lo utilizo para comentar aspectos de los que no hemos hablado aún, como analíticas o seguridad, por ejemplo.

Entrevistas behavioral

Estas son las entrevistas “de toda la vida”. Te preguntan por tu experiencia, tus proyectos y cómo has actuado en situaciones reales. Yo pensaba que no hacía falta prepararlas, pero estaba muy equivocado.

Fui a varias entrevistas sin preparar y hubo preguntas que me pillaron por sorpresa, o situaciones para las que no podía encontrar un buen ejemplo que demostrara mi experiencia.

A partir de ahí, siempre las preparé. Elegía tres o cuatro proyectos donde mi impacto hubiera sido relevante, de empresas diferentes para no acabar hablando siempre de lo mismo. Para cada uno anotaba cosas que salieron bien, cosas que haría diferente, conflictos que surgieron y decisiones técnicas importantes.

Son entrevistas bastante relevantes, porque suelen llevarlas managers, PMs o incluso directors. Si no das una buena imagen pueden vetar tu contratación a pesar de que te hayas lucido en las pruebas técnicas.

Aplicando a ofertas

Al menos en mi caso, nunca me funcionó aplicar a todo lo que se mueve. Lo hice bastante tiempo a través de LinkedIn, pero pocos recruiters me contactaron.

Tuve mucho más éxito buscando primero empresas que me parecían interesantes por sus productos, condiciones y opiniones en Glassdoor y Reddit. Hice una lista con unas 100 empresas, y fui filtrando las que no contrataban en Europa.

A partir de ahí, empecé a aplicar a posiciones específicas que me cuadraban. Mi objetivo principal era emigrar a Suiza 🇨🇭, pero me servía también Holanda, Alemania o Irlanda.

En 2021, en pleno boom post-covid, se contrataba muchísimo. Eso hizo que empresas como Spotify, Salesforce o Amazon me dieran entrevistas incluso sin referral, a pesar de tener un perfil “poco atractivo”.

A partir de 2022 eso se volvió mucho más difícil. En mi caso, lo que empecé a hacer fue contactar directamente con gente que trabajaba en esas empresas para pedir referencias internas. Estas referencias no garantizan nada, pero sí aumentan las probabilidades de conseguir una primera entrevista.

Conseguí entrevistas en Google y en Amazon de nuevo porque conocía a gente que trabajaba allí, y me recomendaron. Pero también en empresas como Stripe, MongoDB o Workday gracias a hablar con gente que no conocía previamente por LinkedIn.

La realidad de estos procesos

Incluso preparándote bien, la mayoría de procesos con estas empresas terminan en rechazo.

Para que te hagas una idea, en mi último cambio apliqué a más de 400 ofertas. De ahí salieron 8 entrevistas y una única oferta final, la de MongoDB. Y eso que ya tenía bastante experiencia con este tipo de entrevistas (fácilmente más de 100).

Muchos de estos rechazos no dicen demasiado sobre tu nivel. Influyen factores que no controlas, como el entrevistador, el ejercicio o los nervios de ese día.

Por eso nunca traté cada proceso como algo de vida o muerte. Siempre llevaba varios en paralelo y bajaba mis expectativas para no ilusionarme.

Otros recursos

Si este tema te interesa y prefieres un aprendizaje más guiado, en mis cursos profundizo justo en estas partes del proceso.

En el de Algoritmos, Estructuras de Datos y Entrevistas cubro las pruebas tipo LeetCode, entrevistas behavioral y cómo aplicar de forma más efectiva.

En el de Diseño de Sistemas a Gran Escala trato las entrevistas de system design, con teoría y ejercicios reales.

Si prefieres seguir por tu cuenta, los libros que he mencionado a lo largo del artículo, junto con recursos gratuitos como LeetCode o el repo de System Design Primer, son también muy buenas opciones!

Esto es un desafío constante, sobre todo para los más juniors. Si no proteges tu tiempo, puedes caer fácilmente en la trampa de estar todo el día ocupado haciendo cosas, pero llegar al final del día con la sensación de no haber hecho nada.

Y lo peor de todo es que muchas veces esa sensación es real. Completamos decenas de tareas pero posponemos justo las que nos darían más valor a largo plazo. Y gran parte de ese problema viene de no diferenciar entre lo urgente y lo importante.

Suscríbete ahora

Esta entrega de Status 418 está patrocinada por @DanielBlancoSWE (yo xD)

Mis cursos de Udemy están al mejor precio disponible! Aprovecha las rebajas para aprender más sobre las bases de la ingeniería de software.

🔹 Arquitectura Software Avanzada: Más Allá de los Patrones

🔹 El Camino a Senior: Claves para el Éxito como Programador

🔹 Diseño de Sistemas a Gran Escala

🔹 Arquitectura Software Moderna: DDD, Eventos, Microservicios

🔹 Principios SOLID y Clean Code. Escribe código de calidad.

🔹 Algoritmos, Estructuras de Datos y Entrevistas Programación

Mi mayor error como junior: ser el “yes man”

Cuando era junior decía a todo que sí. Era el primero en contestar dudas de mis compañeros y el primero en ayudar cuando alguien tenía problemas. En cuanto a lo que me pedían mis superiores, ya te lo puedes imaginar. Lo hacía aún con más énfasis si cabe, para responder a sus peticiones lo antes y lo mejor posible.

Hacía eso porque pensaba que era lo que había que hacer para estar bien visto dentro del equipo y de la empresa. Y, en parte, me ayudó a que mis compañeros siempre me vieran como un gran jugador de equipo y como alguien resolutivo.

El problema viene cuando te das cuenta de que el tiempo no es infinito. Llegaba el final del día y muchas veces no había logrado avanzar en mis tareas. Y eso lo tenía que suplir con horas extras, sacrificando calidad o justificando retrasos en las entregas. Y ninguna de esas opciones es aceptable a largo plazo.

Con las peticiones de mis superiores era aún peor. Ayudar a un compañero podía esperar, pero decir “no” hacia arriba me parecía imposible. Acataba todo lo que me pedían, sin pararme a pensar si era realmente importante.

El coste de vivir en lo urgente

Una de esas tareas urgentes que normalmente me pedían mis superiores era realizar ciertas queries a mano para un cliente importante.

La parte de analíticas de la plataforma no cubría todo lo que necesitaban, y cuando lo hacía, a veces rompía con volúmenes grandes de datos porque los algoritmos eran horribles (muchos joins en código con bucles for anidados, un cristo xD).

Yo lo hacía sin pensarlo demasiado. Era nuestro cliente más importante y además no llevaba mucho tiempo, “sólo” me ocupaba un par de horas.

En unas semanas, ese “par de horas” fue aumentando, porque otros clientes chocaban con el mismo problema. Llegamos a un punto en el que teníamos a todo el equipo haciendo queries manuales por descuidar la plataforma.

Si en lugar de priorizar esas peticiones urgentes, hubiéramos invertido tiempo en mejorar la parte de analíticas desde el principio, nada de eso habría pasado.

Por cada minuto que atiendes cosas “urgentes”, estás quitando tiempo de las tareas realmente importantes. Y el mayor problema no es que tu tiempo personal sufra. Es que si todos hacen lo mismo, el producto deja de avanzar a largo plazo. La deuda se acumula y cada nueva “urgencia” se vuelve más cara que la anterior.

Por eso debes bloquear la mayor parte del día para dedicar tiempo a esas tareas. Cosas como:

• Trabajar en las funcionalidades críticas del roadmap.

• Refactorizaciones que acaban con deuda técnica que está ralentizando al equipo.

• Bugs que sabes que van a causar un aumento de tickets de soporte.

En definitiva. Todo lo que sepas que te va a morder a medio y largo plazo si no lo haces cuanto antes.

Cuándo lo urgente es correcto

Dicho todo esto, el error contrario también existe: usar “lo importante” como excusa para ignorar problemas que sí requieren atención inmediata.

Hay situaciones en las que lo urgente es lo más importante. Caídas en producción, bugs que bloquean completamente a clientes y que requieren de intervención manual, o incidentes de seguridad, no pueden esperar a que haya un hueco en el roadmap.

En esos casos, parar todo lo demás no es una mala decisión. No hacerlo, puede causar un daño irreparable a largo plazo, como la pérdida de confianza de nuestros usuarios o clientes que dejen de trabajar con nosotros.

Quiero que quede claro que el problema no es atender lo urgente, sino convertir cualquier petición en una emergencia. Y eso pasa mucho más de lo que creemos.

Cómo intento priorizar hoy

En mis primeros años, vivir en urgencias constantes me hizo buscar formas de gestionar mejor mi tiempo y aprender a decir “no” cuando hacía falta.

Leyendo y probando distintas cosas, descubrí herramientas que me ayudaron, entre ellas la matriz de Eisenhower. Seguramente ya la conoces, y no voy a entrar en la teoría. A mí me sirve mucho como punto de partida para pensar si una tarea merece realmente mi atención.

De todas formas, no la sigo al pie de la letra. De lo contrario, despriorizaría mucho ayudar a otros compañeros, cosa que a mí me encanta y me parece importante para construir relaciones fuertes y una buena dinámica de equipo.

Intento siempre encontrar un equilibrio. Ayudo, pero sin entrar en laberintos sin salida que se coman el día entero, y pensando si hay algo realmente crítico que atender primero.

Además de servirme para relativizar las urgencias, donde más me ayuda la matriz es en eliminar las tareas que están en el cuadrante azul. O, al menos, darme cuenta de que estoy perdiendo tiempo con ellas y no estoy siendo realmente productivo xD.

¿Te has visto alguna vez en situaciones así? Me encantaría leer cómo lo gestionas tú en los comentarios!

A final de año, con los avances de los LLMs, decidí darle otra oportunidad y empecé a construir Deep Focus utilizando principalmente Claude Code y Codex.

Desde el primer momento noté una mejora enorme en estas herramientas para este caso concreto. Lo que a principios de año les costaba, ahora lo resolvían en un prompt. Gracias a eso, conseguí publicar la app a finales de diciembre.

Pero no todo fue un camino de rosas. Surgieron muchos inconvenientes (y mucha deuda técnica) que también quiero contar aquí. No va a ser un post ni pro ni anti IA, simplemente una experiencia real construyendo un side project desde cero.

Suscríbete ahora

La IA acelera, y mucho

Esto es innegable. Los avances son increíbles, y gracias a ello pude crear una app sin tener experiencia previa en iOS. Sin la inteligencia artifical habría tenido que formarme bastante o seguir la documentación oficial paso a paso. Habría tardado horas en tener la pantalla de tareas básica.

Con Claude Code tenía una app de gestión de tareas funcionando en mi iPhone en cuestión de minutos. Es cierto que no era nada excesivamente complejo, pero el ahorro de tiempo fue enorme.

El primer problema: la tecnología elegida

Delegué en la IA la tecnología para este proyecto. Le dije que en principio quería sacarla para iOS, y si a la gente le gustaba me plantearía sacarla para Android más tarde. También añadí que no tenía experiencia desarrollando en iOS, pero que sí tenía experiencia con JS / TS y algo de react.

Teniendo eso en cuenta, la tecnología elegida fue React Native. Y al principio todo fue genial. Podía entender el código sin problema y hacer mis ajustes si era necesario. Probé a desplegarla en Android por curiosidad y funcionaba igual de bien.

El problema vino a la hora de desarrollar los widgets y el bloqueo de aplicaciones. Esta funcionalidad depende de lógica nativa, no se puede desarrollar únicamente en React Native.

Al principio pensé que sería necesaria poca lógica en Swift. Pero el respositorio tiene actualmente un 30% de código nativo. Si implemento soporte para Android (suponiendo los mismos porcentajes, por simplificar), tendría menos de un 50% del código en React Native.

Viéndolo con perspectiva, si hubiera sabido esto desde el principio habría desarrollado la app directamente en Swift. Me habría ahorrado muchos problemas y, sobre todo, la complejidad añadida de la comunicación entre React Native y código nativo.

Pero me fié a ciegas de la decisión de Claude Code, que a pesar de tener todos los requisitos y de comentarle las funcionalidades nativas que necesitaba, decidió tirar por el modelo híbrido.

En este caso es “solo” un side project y el impacto es limitado. Pero en una empresa, esto puede significar mucho tiempo y dinero invertido. La velocidad inicial puede acabar siendo pan para hoy y hambre para mañana.

Mi mayor sufrimiento: Live Activities y background jobs

Tras recibir feedback de varios usuarios, decidí implementar un modo Pomodoro en Deep Focus.

La idea era sencilla: implementar un temporizador en la app y utilizar Live Activities para que el usuario pudiera ver el tiempo que le quedaba desde fuera de la aplicación o la pantalla de bloqueo.

Yo no quería un simple icono de temporizador, como se ve en la anterior imagen. Quería poder pausar, reanudar y pasar a la siguiente fase directamente desde la Live Activity.

Claude Code implementó esta funcionalidad con pocos prompts. Y, al principio, parecía funcionar. Pero pronto me di cuenta de que era muy inestable. El botón de pausar a veces tenía efecto en la app, y a veces no, causando inconsistencias en el estado. Y esto era imposible de debuggear.

Ahí empezó una iteración de la cual no me siento muy orgulloso. Del estilo “pls fix make no mistakes”. Pasaron horas y horas, repartidas en varios días, y todo el código que la IA añadía no mejoraba la estabilidad del Live Activity.

La desesperación me llevó a la documentación oficial y a buscar problemas similares en Google. Para mi sorpresa, aprendí que las Live Activities no son realmente “Live”, y que 20-30 segundos después de que una app de iOS pase a background no se puede ejecutar código de manera fiable. Las tareas en background se ejecutan si el OS quiere, y no están garantizadas.

La inestabilidad que veía también era causada en parte por estar conectado al XCode, que mantiene la app “viva” más tiempo aunque esté en background. Al final, después de tanto trabajo, volví a la versión sin botones.

La IA como revisora

Como estaba en bucle con Claude Code, decidí probar con Codex. Le pedí que me revisara la implementación actual del Pomodoro e identificara la causa de los problemas que sufría.

Ahí es donde ví la primera señal de que quizás el problema no estaba en la implementación, si no en las limitaciones del sistema operativo. Codex mencionó varias restricciones de los background jobs de iOS que encajaban perfectamente con lo que estaba viendo. Como ya he comentado, investigando en internet confirmé esa hipótesis.

A partir de ahí empecé a utilizar Codex como “revisor” de todo lo que escribía Claude Code. Al principio pensé que no sería tan útil, pero me sorprendió la cantidad de problemas y mejoras que fue capaz de detectar!

El bias por añadir código sin parar

Los LLM (especialmente Opus 4.5) han llegado a un punto en el que pueden construir software bastante top desde cero. Incluso, por experiencia en mi trabajo, operan decentemente en proyectos enormes. Algo que no esperaba que sucediera tan rápido.

El mayor problema que les veo ahora es que siguen teniendo un bias enorme en añadir código. Y eso es un gran riesgo a largo plazo si vibecodeas al 100% tu sistema, al menos por ahora.

Problemas que se podrían arreglar eliminando o reutilizando código suelen acabar siempre con Claude Code añadiendo decenas o cientos de líneas.

Esto me causó muchos dolores de cabeza en Deep Focus. El más grave fue la inconsistencia del estado de la app: en lugar de mantener un único single source of truth, se fueron añadiendo múltiples stores que luego había que sincronizar. La situación empeoró según crecía la app, especialmente al introducir módulos nativos para el Shield, los widgets y las Live Activities.

Esto fue mi culpa, por optimizar el “avance”, en lugar de mirar a largo plazo. Podría haber hecho un mayor esfuerzo en definir bien la arquitectura y las reglas del proyecto para que Claude Code tuviera ese contexto presente desde el principio.

Dónde la IA realmente brilla para un backender

Si eres backender y tienes las skills de front oxidadas como yo, probablemente estarás de acuerdo conmigo. Sin duda, el punto donde más me ha ayudado la IA es en mejorar la interfaz de usuario y en crear assets “bonitos”, como el logo de la app y otras imágenes.

Es cierto que las interfaces generadas por IA suelen ser bastante genéricas, pero para un side project es más que suficiente para dejarlo en un estado aceptable.

El problema de añadir mucho código sigue estando presente. Los ficheros de la pantalla de tareas y del pomodoro superan ambos las 2000 líneas de código, y estoy seguro de que podrían ser mucho más simples. Pero es un lugar menos crítico, no es el core de la aplicación, por lo que decidí darle mucha más libertad a la IA en este aspecto.

He aprendido “poco”

La IA ha bajado una barbaridad la barrera de entrada para programar. Sin experiencia previa en iOS, y con conocimientos básicos de React Native pude publicar mi side project en tres o cuatro semanas.

El problema es que el proyecto se convierte en una “caja negra”, donde la interfaz principal es el LLM. En ese proceso he aprendido bastante poco realmente. Ahora sé cómo funciona iOS un poco mejor, pero simplemente porque me vi forzado a investigar yo mismo sin depender de la IA.

Ahora mismo no sería capaz de crear ni una app básica desde cero, y mucho menos hacerlo de forma nativa en Swift. Para balancear aprendizaje y velocidad, tendría que haber revisado todo el output generado y haber entendido todas las decisiones tomadas.

Para aprender algo desde cero sigo prefiriendo los métodos tradicionales: libros, vídeos, documentación oficial y crear cosas a mano. Eso, con el apoyo de la IA, va a potenciar mucho tus habilidades.

Conclusión: el vibecoding acelera, pero no es gratis

De este side project saco muchas cosas positivas y varias lecciones claras sobre cómo usar estas herramientas en proyectos que realmente importen.

La IA acelera un montón el desarrollo, sobre todo al principio. Reduce muchísimo la fricción para empezar algo desde cero y es un apoyo enorme en temas de UX y diseño, especialmente si vienes del backend. En ese sentido, vibecodear es casi adictivo. Yo me lo he pasado como un niño construyendo Deep Focus.

Pero esa velocidad tiene un coste. Vibecodear sin control introduce complejidad y deuda técnica muy rápido, especialmente cuando no conoces bien la plataforma en la que estás trabajando. Además, si delegas todas las decisiones en la IA, el aprendizaje real es bastante limitado. Avanzas, pero entiendes poco lo que estás construyendo.

Mi conclusión es que la IA acelera mucho, pero no sustituye entender el sistema que estás construyendo.

Suscríbete ahora

1. Proyectos personales desde el primer día

Nunca fui una eminencia en los estudios. Siempre me costó muchísimo concentrarme en clase y estudiar para los exámenes (lo cual se veía reflejado en mis notas xD)

Me metí en Ingeniería Informática por una simple razón: Me gustaban los ordenadores y solucionar problemas. Y una de las mejores cosas de esta carrera es que puedes crear lo que quieras casi desde el primer día, a diferencia de otras ingenierías clásicas o carreras de ciencias. Sólo necesitas un portátil y ganas.

Y algo que me sorpende, es que muy poca gente toma ventaja de esto. No es criticable, pero es algo que marca la diferencia. En mi caso, siempre estuve liado en algún side project. Por ejemplo:

• Juego que llegó a 100k descargas en Android. Lo creé en Navidad en segundo año de carrera, en lugar de estudiar para los exámenes de enero xD.

• Web de noticias de NFL.

• Incubadora de huevos con Raspberry Pi.

• Mis cursos de Udemy.

• Y el más reciente, Deep Focus, la app para bloquear distracciones.

• Y muchos más!

La mayoría de estos proyectos no me hicieron ganar ni un sólo euro. Pero sí me ayudaron a crecer, y no sólo técnicamente. Te obligan a pensar en una visión, planificación, implementación end to end e incluso algo de marketing si quieres llevarlo un poco más allá.

Y además, en entrevistas de trabajo siempre me preguntan por alguno de ellos. En Salesforce, por ejemplo, un antiguo compañero se descargó mi juego de fútbol y lo estuvo probando antes de entrevistarme.

2. Generalista primero, especialista después

Mucha gente se enfoca en especializarse lo antes posible, pensando que eso les ayudará a crecer rápido y ganar más. En mi opinión, esto es un error cuando estás empezando.

Si te especializas demasiado pronto, pierdes la oportunidad de ver el resto del stack, de descubrir qué te gusta realmente y de mejorar técnicamente en otras partes del desarrollo. Además te encasillará para futuras ofertas laborales.

Ejemplos típicos son los desarrolladores de una única plataforma (Android / iOS), quienes sólo trabajan en una única parte del stack (frontend, backend, QA...), o el caso extremo, gente que sólo quiere trabajar con un lenguaje o framework concreto.

Un generalista puede aportar valor en muchas áreas diferentes, mientras que un especialista sólo en una. Seguramente el especialista rinda mejor en su nicho, pero el generalista tiene más flexibilidad, entiende mejor el sistema completo y puede desbloquear más frentes.

La clave es llegar a ser un buen Ingeniero T-shaped. Alguien capaz de aportar en varias áreas, pero con profundidad en una concreta.

Esto lleva años, y es mucho más difícil llegar ahí si te especializas demasiado pronto.

3. Mentalidad de producto

En mis primeros años de carrera solo pensaba en ejecutar. Me centraba en escribir buen código que cumpliera los requisitos que me pedían mis superiores. No entendía, ni me interesaba el producto en sí, y eso frenó muchísimo mi crecimiento.

Era muy bueno generando output, pero no tanto generando outcomes.

Entender a fondo el producto que estás desarrollando es clave para tomar decisiones técnicas. A veces lo vemos como un problema de Product Managers, pero no lo es. Muchos problemas que parecen puramente técnicos, se resuelven mucho mejor si entiendes qué intenta conseguir el usuario y para qué existe esa funcionalidad.

Un desarrollador con mentalidad de producto:

• Entiende el producto a fondo y lo usa si puede.

• Conoce a los usuarios y por qué lo usan.

• Sabe que lo que genera dinero es el producto, no el código.

• Tiene criterio para decidir qué aporta y qué no.

• Valida ideas con pruebas de concepto antes de querer implementar media plataforma.

Con esta mentalidad puedes aportar valor más allá del código, lo que mejorará la comunicación con PMs y el equipo de diseño, y te dará mejores oportunidades laborales. Te percibirán como un ingeniero más completo, no como alguien técnico que recibe Jiras y los cierra.

El primer punto que traté también ayuda con esto. Al crear un side project estás obligado a pensar en tus usuarios y en cómo evolucionar tu producto para que tenga más oportunidades de éxito.

Por ejemplo, en Deep Focus tengo un pequeño bug con el modo pomodoro en usuarios Pro. Mi instinto como desarrollador es ponerme a investigarlo y solucionarlo ya mismo. Pero viendo los datos, sólo el 10% de los usuarios es Pro, y sólo una fracción utiliza la funcionalidad que tiene el problema. Con mi tiempo limitado, sé que arreglar el bug aporta mucho menos que otras mejoras que afectan a todos los usuarios.

4. Preparar entrevistas técnicas

Este es un punto polémico que ya he tratado muchas veces en Twitter. Mucha gente ve preparar entrevistas como “perder el tiempo”. Y en parte lo entiendo: las pruebas de Live Coding son estresantes, algo repetitivas y no representan del todo el trabajo real.

Aun así, creo que demonizarlas es un error. La realidad es que la mayoría de empresas extranjeras (y sobre todo las que mejor pagan y mejor talento tienen) siguen usándolas.

Invertir en ello me dio muchas ventajas:

• Fortalecer mis fundamentos en algoritmos y estructuras de datos.

• Entrar en Salesforce, multiplicando x5 mi sueldo en 1 año, y tres años más tarde conseguir trabajo full remote en MongoDB.

• Tener “acceso” a una densidad de talento muy alta. Al haber tanta competencia por entrar, todos los compañeros eran muy buenos, y aprendí un montón.

• Mejorar mi comunicación y mi tolerancia a la presión.

Es cierto que no fue un camino de rosas. Muchos meses invirtiendo 2-4 horas al día después del trabajo, y más horas aún durante los fines de semana. Pero ha sido sin lugar a dudas la decisión que más impacto ha tenido en toda mi vida, y no sólo a nivel profesional.

Finalmente, desde un punto de vista puramente técnico, prepararme para entrevistas técnicas mejoró mis fundamentos, tanto de algoritmos y estructuras de datos como de diseño de sistemas. Y, al menos en mi caso, eso me ha ayudado muchísimo en mi día a día como ingeniero.

5. Dar la milla extra de forma estratégica

En mi primera empresa, hacer horas extras era lo normal. Había una cierta presión social por demostrar que “tenías puesta la camiseta”. Y lo peor es que muchos ni siquiera estaban trabajando, sólo “esperando” a que el resto se levantase para irse.

El extremo contrario también me parece negativo. Negarse siempre a dar un minuto más de tu tiempo, incluso cuando tu equipo está en problemas.

La estrategia que siempre me funcionó es la de “dar la milla extra” cuando tiene sentido, cuando hay un beneficio real por hacerlo.

Por ejemplo, al entrar en un nuevo equipo. Las primeras impresiones pesan mucho y un esfuerzo extra al principio te da “crédito” para el futuro.

Otro ejemplo es cuando tu equipo, o un compañero, tiene problemas. Ofrecer tu ayuda para salir de una crisis tiene un gran impacto en tu imagen dentro del equipo.

Esos esfuerzos puntuales valen mucho más que hacer horas extra por hacer, sin un propósito claro. Encontrar ese equilibrio es difícil, pero marca una diferencia enorme.

Gracias a esto, siempre se me ha visto como un jugador de equipo, resolutivo y fiable. Y mis managers siempre han respondido ofreciéndome mucha autonomía y flexibilidad para trabajar como a mí me gusta.

6. No tener miedo a salir de la zona de confort

Esto es muy cliché, lo sé xD. Pero realmente ha sido un punto en el que siempre me he esforzado, y que me ha dado grandes resultados.

Siempre he sido un chaval tímido. Cosas como hablar con desconocidos, presentar en público, o viajar sólo me daban pánico. Por eso me obligué a enfrentarme a esas situaciones: me fui de “mini erasmus” al acabar la carrera, me apunté a actividades donde tenía que hablar en público y salí más de fiesta para hablar con desconocidos (a ver qué otro creador de contenido te recomienda eso xD). Poco a poco, dejé de ver estas cosas como algo imposible.

Con las entrevistas me pasaba igual. Me ponían nervioso, y en inglés todavía más. Para mejorar, hice decenas de entrevistas con empresas que ni me interesaban, sólo para practicar.

Intento mantener siempre esa mentalidad: recibir el cambio con los brazos abiertos y adaptarme rápido. En nuestro sector y en la vida en general, la pregunta no es si algo te va a incomodar, sino cuándo. Cuanto más entrenado estés para enfrentarte a ello, menos sufrirás cuando llegue el momento en el que de verdad importe.

Para terminar

Yo no soy ningún prodigio. Empecé como cualquiera, cobrando poco, sin contactos y sin tener mucha idea de informática. Pero estas 6 estrategias me llevaron a donde estoy hoy.

Ojalá alguna de ellas te ayude a avanzar un poco más rápido. Y si te apetece, cuéntame qué puntos han marcado más tu carrera. Me encantará leerte!

Antes de seguir

Esta es la primera entrega de Status 418. Aquí escribiré sobre:

• Arquitectura de Software y Diseño de Sistemas

• Tecnología y programación en general

• Mis experiencias en Salesforce y MongoDB

• Proyectos y un poco de vida personal

Siempre desde un enfoque directo, sincero y personal.

Un repaso a los objetivos de 2025

El año pasado fue bastante loco para mí. Cumplí mi primer año en MongoDB y en Viena, me casé y viajé mucho. Demasiado incluso (sí, ya estoy poniendo excusas de por qué no cumplí mis objetivos xD)

Me puse muchos objetivos el año pasado, así que mencionaré sólo los principales.

1. Sacar dos cursos nuevos

El principal objetivo era crear dos cursos nuevos para Udemy. Sólo lo había conseguido el año que empecé en esto, en 2021.

❌ Sólo publiqué el curso de Arquitectura Software Avanzada

Crear un curso implica muchísimo trabajo, al acabar uno necesito desconectar y no empezar otro hasta encontrar un tema valioso y sentirme motivado. Como eso no sucedió, sólo publiqué uno.

2. Conseguir 43,000 inscripciones totales

Era un objetivo complicado porque no depende al 100% de mí (uno de los errores que comentaré más tarde), pero se consiguió gracias a un gran inicio de año.

✅ 44,024 / 43,000

3. Llegar a 28,000 seguidores en X

Era mi meta más ambiciosa, porque empecé el año con 18,000 seguidores en @DanielBlancoSWE. Crecer en redes requiere de mucha constancia y también suerte, no depende al 100% del contenido que publiques.

Aunque no llegué a la meta, estoy contento porque me quedé bastante cerca, y lo más importante, conocí gente increíble este año gracias a esa red social!

❌ 27,700 / 28,000

4. Leer doce libros en alemán

La mayor fumada del año, no sé en qué estaría pensando, pero con un nivel que no llegaba al A1 no tenía ningún sentido xD

❌ 5 / 12

Mis errores con los objetivos

Los que hemos visto son sólo 4 de los 12 objetivos que me puse. En total cumplí 5, así que al acabar el año me paré a revisar cada uno para entender qué había fallado y qué podía mejorar en mi planteamiento.

Algunos errores fueron evidentes desde el principio. Otros no tanto.

Demasiadas metas

El que mucho abarca poco aprieta. Todas mis metas estaban relacionadas con hábitos o proyectos personales. No suelo ponerme metas sobre mi trabajo.

Teniendo en cuenta que el trabajo ya me ocupa 8 horas al día, el margen real para avanzar en objetivos personales es limitado si quiero tener un mínimo de vida.

Ponerme 12 objetivos fue una locura. Algunos ni los empecé, como aprender Golang o sacarme el B1 de alemán.

Esto me generó cierta ansiedad y la sensación de tener que cumplir objetivos por cumplir, sólo para sentirme “productivo”, hasta que me dí cuenta de mi error y descarté varios de ellos.

Mirando atrás, habría sido mucho mejor definir 4 o 5 objetivos importantes y centrarme de verdad en ellos.

Objetivos que no dependen de mí

Me puse demasiados objetivos que dependían de factores externos sobre los que tenía poco o ningún control:

• 28k seguidores en X: Depende de la constancia, pero también de la suerte y del algoritmo.

• 43,000 inscripciones y facturación en Udemy: depende en gran parte de las recomendaciones y de la publicidad que hace la propia plataforma.

• Llegar a cierto patrimonio: teniendo el 95% de mi patrimonio invertido en ETFs, dependo totalmente de cómo vaya el mercado.

Establecer objetivos así sólo consigue dos cosas: frustrarte si no los consigues o darte una falsa sensación de avance si salen bien, al menos en mi caso.

Y ojo, no digo que estas métricas sean inútiles. Es útil echarles un vistazo y analizar si tu esfuerzo tiene resultados o si debes cambiar el enfoque.

Pero si tus metas son, como en mi caso, hábitos y side projects y tu tiempo es muy limitado, puedes acabar frustrado muy fácilmente si los resultados no acompañan. Este tipo de metas tienen más sentido si dedicas el 100% de tu tiempo a ellas.

Metas difusas o mal definidas

Esto es de primero de planificación, pero aún así fallé en algunas. En parte por pereza y en parte por no dedicar tiempo a definir bien las metas. Además, al ser objetivos secundarios, tampoco les di demasiada prioridad.

“Aprender Golang” o “poder mantener una conversación básica en alemán” son dos ejemplos de metas súper difusas.

Cuando una meta está mal definida, es muy fácil mover el baremo y considerarla cumplida cuando realmente no lo está.

Acabó el año y no tengo claro si puedo o no mantener una conversación básica en alemán. Mi esposa me dice que sí, pero mi experiencia en la vida real me dice lo contrario xD.

Mis metas para 2026

Definí mis metas para este nuevo año teniendo en cuenta los errores del anterior:

• Sólo 4 o 5 metas importantes.

• Que dependan al 100% de mí.

• Nada de metas difusas.

La lista final es la siguiente:

1. Sacar un nuevo curso. Crear contenido de valor para mis estudiantes sigue siendo la primera prioridad del año.

2. Publicar Status 418 semanalmente. Esta newsletter tendrá una prioridad alta. Siempre me gustó escribir y creo que es una gran forma de organizar mis ideas mientras sigo creando comunidad. Además, aposté con un amigo una cena por cada semana que falle. No puedo fallar si no quiero arruinarme xD.

3. Publicar 5k tweets durante el año. Quiero seguir construyendo una comunidad en español, y X / Twitter es lo más cercano y cómodo que he probado. Me voy a enfocar en la constancia durante todo el año, no en el número de seguidores.

4. Convertir Deep Focus en algo que use a diario. En diciembre estuve trabajando en una app de productividad. Acabo de publicarla en la App Store y quiero evolucionarla hasta que disfrute usándola en mi día a día.

5. Sacar un mapa para Fortnite. Tengo un amigo que es creador de contenido de Fortnite y queremos colaborar para lanzar un mapa en la plataforma. Ya avancé bastante en 2025, pero no llegué a publicarlo. Mi meta más random, sin lugar a duda.

En resumen

Este año voy a centrarme en menos objetivos, mejor definidos y que pueda medir y controlar al 100%. Con este enfoque, espero avanzar en mis proyectos personales sin la presión innecesaria que provocaban las metas de otros años.

Revisaremos estos objetivos al empezar 2027 y veremos qué tal funcionó el cambio.