Pánico en el mercado laboral

• El mercado laboral tecnológico se ha vuelto menos favorable para los desarrolladores por la combinación de tasas de interés más altas, recorte del financiamiento de VC, contracción del gasto de los clientes y procesos de contratación estandarizados
• La compensación y la estabilidad cambian según el capital, los ingresos y la etapa de crecimiento de la empresa; en un entorno de tasas altas, cuanto mayor es la dependencia del VC, más probable es que la empresa colapse o se reduzca a modo supervivencia
• La contratación tecnológica moderna se inclina más por las pruebas de código y las entrevistas conductuales que por la experiencia real de trabajo, y desde startups pequeñas hasta grandes tecnológicas replican procedimientos parecidos
• Las vacantes tipo “Everything Bagel” terminan juntando en un solo rol trabajo de varios departamentos, desde desarrollo de aplicaciones e infraestructura hasta seguridad, soporte al cliente, guardias, optimización de costos y documentación
• Los puestos técnicos están cambiando de mejorar producto y organización con autonomía a cumplir prioridades de otros con poco margen de decisión, como un rol de ejecutor, sin reflejar bien la experiencia y el criterio de los desarrolladores con trayectoria

---

La conexión entre las tasas de interés y los empleos tecnológicos

• Parte de la idea de que terminó el entorno de tasas bajas, casi de “dinero gratis”, y que al subir por encima del 5%, el costo mismo del dinero se volvió caro
• Cuando las tasas suben, las organizaciones con efectivo pueden preferir poner su dinero en opciones más seguras, como instrumentos con interés respaldados por el gobierno, en lugar de invertir en empresas inciertas
• La inversión en empresas tecnológicas se trata como un activo riesgoso apostado al futuro; en épocas de tasas altas, las empresas débiles caen y hasta las fuertes recortan personal con el argumento de “clean house”
• Como resultado, aparece la observación de que cientos de miles de trabajadores tecnológicos con alta compensación enfrentan durante 2 a 4 años un mercado con escasez de empleos
• En ciclos de alza de tasas puede aumentar el trabajo de medio tiempo con salario mínimo o en construcción, pero los empleos tecnológicos están mucho más ligados al financiamiento de VC y al gasto de los clientes

Tipos de empresa y estructura de compensación

• Las empresas tecnológicas se dividen en cuatro grupos según su financiamiento y estado de crecimiento
  • nepo company: empresa que puede construir productos poco realistas con dinero alejado de la validación del mundo real, como capital familiar o de relaciones personales
  • speculation company: empresa que recibe fondos para experimentar ideas sin validación de producto, cliente o mercado
  • initial growth company: empresa que, tras generar demanda inicial, recibe capital de crecimiento para intentar expandir ingresos
  • stable era company: empresa estable con vía repetible de entrada al mercado, acceso a clientes e ingresos recurrentes
• En un entorno de tasas altas, mientras menos exitosa es una empresa, más depende del financiamiento de VC, y es la que más se sacude cuando el flujo de capital se desacelera o desaparece
• Como los clientes también enfrentan restricciones de gasto, puede haber al mismo tiempo pérdida de clientes o reducción de presupuesto
• La speculation company se describe como un lugar que paga entre 50% y 80% del valor de mercado mientras espera 200% a 500% más trabajo
• La initial growth company puede terminar combinando alto riesgo con baja compensación, y una empresa de crecimiento que fracasa puede quedar atrapada en bajos salarios y despidos repetidos
• La stable era company vuelve a dividirse en tres tipos
  • empresa que crece de forma estable y genera ganancias
  • empresa que alterna entre expansión y contracción según la inclinación de un CEO famoso
  • empresa que domina uno o más sectores económicos y no se rompe con facilidad
• Las grandes empresas modernas en etapa de crecimiento pueden pagar a empleados con experiencia una compensación equivalente a entre 10,000 y 50,000 dólares por día al incluir acciones anuales, mientras que otras empresas pueden pasar 10 años sin crecimiento salarial real ni compensación accionaria efectiva

El problema de que el proceso de contratación no distingue la capacidad real

• En la contratación tecnológica se repiten tres contradicciones
  • los requisitos están rotos
  • el proceso de entrevista está roto
  • la mayoría de las empresas siguen los mismos requisitos y el mismo método de entrevista
• Puede que los entrevistadores no logren evaluar de forma consistente a candidatos que dan respuestas mejores que las que ellos esperaban
• La entrevista técnica moderna exige resolver tareas improvisadas sin relación con el trabajo real; si fallas, te consideran de baja capacidad, pero puede que tampoco logre distinguir a quienes tienen experiencia de nivel más alto
• Las pruebas de código al estilo Google y las entrevistas conductuales al estilo Amazon se copiaron por toda la industria, y tanto startups pequeñas como grandes empresas piden procesos similares
• Las entrevistas conductuales repiten preguntas como “¿cómo resolviste un conflicto?” o “¿cuál fue una experiencia en la que cometiste un error y pediste disculpas?”, y se interpretan como un mecanismo para ver cómo el candidato maneja el equilibrio entre avanzar y ser amable
• Codificar la adecuación cultural en formato de preguntas y respuestas puede terminar en una homogeneización de personalidad que excluye a quienes se salen de la personalidad promedio de la empresa
• Si las empresas siguen agregando etapas de entrevista y se alejan del trabajo real, la experiencia, la capacidad y la comprensión, toda la industria tecnológica puede volverse ineficiente

Vacantes “Everything Bagel”

• Las vacantes “Everything Bagel” son un formato que exige demasiadas responsabilidades al mismo tiempo para un solo Software Development Engineer
• Entre los requisitos de ejemplo se incluyen
  • escribir aplicaciones con React, Vue, TypeScript, Node, Python, Rust y Go
  • dar mantenimiento a aplicaciones heredadas en PHP, Ruby y C
  • desplegar infraestructura con AWS, Docker, Kubernetes, Terraform, Lambda, EventBridge y Step Functions
  • optimizar costos de AWS, CI/CD, guardias 24/7 y garantizar logs, monitoreo, alertas y observabilidad
  • seguridad de aplicaciones, seguridad de dependencias y seguridad de infraestructura relacionada con SOC-2
  • soporte a clientes, soporte a empleados internos, code review, mentoría y documentación
  • mantener 37 plugins SaaS de JavaScript y scripts adicionales de rastreo
• En la práctica, este tipo de puesto único se parece más al trabajo de 5 departamentos y unas 20 personas
• Parte de la industria, según esta visión, abandonó la idea de que los técnicos deben tener especialización y, con la lógica de “devops means DEVS DO OPS”, termina aventando operaciones a desarrolladores sin experiencia operativa
• En una estructura donde un desarrollador de aplicaciones también hace de arquitecto de AWS de medio tiempo, es difícil esperar buenos resultados, y se sostiene que esas capacidades normalmente requieren más de 5 años de desarrollo enfocado
• Las exigencias excesivas vuelven el trabajo físicamente imposible, y cada punto puede convertirse en una tarea de varios días por semana, dejando a la persona atrasada desde su primer día

Problemas de organización e infraestructura vistos desde la experiencia de campo

• Varias empresas decían que “el sitio está lento”, pero en realidad se repetían casos donde ni siquiera revisaban métricas básicas de AWS ni la administración del sistema, por lo que los problemas quedaban desatendidos
• Una empresa operaba todo el servicio sobre un solo MySQL de 2 núcleos y 16 GB de RAM; la base de datos había crecido hasta 3 TB y el CPU se mantuvo al 99.99% durante 2 años
  • Después de cambiar a un servidor ARM de 64 GB y reserved IOPS, el tiempo de transformación de datos por lotes bajó de 16 horas a 20 minutos, y el retraso de replicación pasó de 4 a 6 semanas a nivel sub-second en tiempo real
• Otra empresa gastaba 5,000 dólares al mes en un clúster de investigación sin uso, mientras que en el clúster real de producción solo usaba recursos por unos 500 dólares al mes
  • Al mover los recursos al clúster de producción y cambiar a ARM, el tiempo de respuesta al usuario bajó de 7 segundos a 200 ms
• Una empresa donde la API interna de procesamiento de datos corría en los mismos dos EC2 de 2 núcleos que el servidor web del cliente tardaba 20 horas en el procesamiento por lotes
  • Tras moverlo a contenedores con autoescalado basados en ECS-on-EC2, entre 20 y 50 contenedores procesaban en paralelo y el tiempo bajó a 30 minutos
• Una empresa cuya herramienta para mover datos de MySQL a Redshift tardaba 80 horas tenía una estructura que primero ejecutaba SELECT COUNT(*) sobre una tabla de 3 mil millones de filas y luego recorría toda la tabla con LIMIT/OFFSET
  • Al introducir cursores de base de datos, escritura en streaming a S3 y compresión en memoria, el tiempo de extracción se redujo de 80 horas a 40 minutos
• Si se menosprecia la experiencia en administración de sistemas y arquitectura solo por ser “cloud native”, puede que ni siquiera haya alguien capaz de detectar el problema, y los mismos fallos queden abandonados durante mucho tiempo
• Incluso cuando los clientes se van, aparecen casos donde el VC exige “más personal de ventas”, creando estructuras de 5 desarrolladores frente a 50 personas de ventas y marketing
• Si una empresa con ingresos a la baja insiste en sus ideas existentes y en una estrategia centrada en ventas en vez de cambiar o mejorar el producto, los desarrolladores no pueden construir el producto que quieren y eso puede llevar al fracaso de la empresa

Un mercado de contratación que ignora la experiencia y los resultados reales

• La percepción de fondo es que la forma de contratar en tecnología pasó, en 10 a 20 años, de evaluar simplemente si alguien “se maneja bien con las computadoras” a una estructura centrada en estatus social y juegos de entrevista
• Resolver problemas y hablar en el momento pesa más que el trabajo real, la experiencia y la capacidad
• También se considera que los proyectos personales y los resultados reales no se reflejan lo suficiente en la evaluación de entrevistas
  • mpreg: sistema distribuido de procesamiento de datos con resolución automática de dependencias y ordenamiento topológico jerárquico
  • mejora de procesamiento CRC: mencionado como código usado en validación de formatos globales de archivo e información de estaciones espaciales
  • icli: CLI para trading manual y automático de acciones
• La industria se ha acercado más al estatus social, político y al poder que a la capacidad real, y existe la conciencia de que la contratación debería orientarse a crear más “us”
• Los puestos técnicos terminan asignando un rango demasiado amplio de trabajo a una sola persona y, al mismo tiempo, la contratación no mira suficientemente la experiencia real, lo que vuelve muy difícil resistir para quien busca empleo

La autonomía del desarrollador y el liderazgo del producto

• Se concluye que los empleos de la industria tecnológica quedaron atados a un exceso de capital especulativo, y al reducirse el dinero y los clientes, también desaparecieron los puestos
• Muchos roles tecnológicos, según esta visión, se han convertido en una estructura tipo “software servant”, donde se ejecutan tareas y prioridades definidas por equipos de producto no técnicos
• En Engineering-led management, la persona que hace el trabajo define el producto, habla con usuarios, establece requisitos e implementa funciones
• Antes, el rol del desarrollador consistía en resolver problemas desde una visión completa del negocio, pero ahora se percibe más como un trabajador de gestión de proyectos que ejecuta ideas y prioridades de otros
• Incluso con el mismo rol y el mismo esfuerzo, en una empresa se pueden ganar 400 dólares por día y en otra 20,000 dólares por día, y esta brecha de compensación alimenta la sensación de impotencia de quienes buscan trabajo
• Crear buenos productos, buenos sistemas y productos y economías en crecimiento sigue siendo la dirección a la que los técnicos deberían apuntar

[GN⁺]

Opiniones de Hacker News

• No es un problema exclusivo de la ingeniería de software ni de sectores cercanos. Conocidos en Europa también están intentando cambiar de trabajo o conseguir ascensos verticales u horizontales en industrias muy distintas, desde finanzas hasta moda, y les está yendo bastante mal.
  Hoy en día, la mayoría de los procesos de contratación no miran la trayectoria de la persona ni lo que podría aportar, sino que consisten en hacerla pasar por una puerta tras otra. Los currículums subidos a portales de empleo son más bien sedimento que se hunde hasta el fondo del montón, así que conviene usar redes de contactos y conocidos tanto como sea posible.
  A mí también me golpeó la reducción de empleos técnicos, e intenté entrar a una consultora de software, pero pasé 8 meses en la banca. Al final renuncié y volví al trabajo de valuación corporativa y fiscal; incluso el subempleo es mejor que no tener nada, sobre todo mentalmente.
  En la fuente original también aparece una pequeña frase: “resbalé con esta banana como un mono flojo”.

  • La parte clave es que “hoy la contratación tiene muchas puertas y no mira la trayectoria de la persona ni lo que podría aportar”. Cuando postulé antes, me hicieron preguntas como “¿tienes experiencia en C++ o en algoritmos avanzados de grafos?”, aunque en mi perfil o currículum no había absolutamente nada de eso.
    Aun así, reaccionaron como si mis 10 años de experiencia en software y áreas relacionadas de pronto no valieran nada. Es raro tratar a alguien que ha aprendido y usado varios lenguajes como si no pudiera usar C++ en absoluto solo porque lo usó un poco de forma implícita.
    Una empresa puso en la oferta que no se necesitaba experiencia en Python, y en la primera llamada de entrevista me lanzó una avalancha de preguntas de implementación de bajo nivel en Python. Si van a hacer eso, no sé para qué entrevistan; es una pérdida de tiempo para todos.
    Al final, las empresas no tienen idea de cómo contratar y, por la misma razón, tampoco saben hacer mentoría ni capacitar. Aunque, desde el punto de vista del candidato, también sirve como filtro natural: si no saben contratar, es muy probable que no sean un buen lugar para trabajar.
  • En los últimos años he estado haciendo mentoría a graduados de ciencias de la computación, y de vez en cuando hay empresas que, durante el proceso de entrevista, piden tareas excesivas, como crear una app o un sitio web completos. En esos casos les aconsejo rechazarlas, pero en la práctica son poco frecuentes.
    También se quejan mucho de que los procesos de entrevista son demasiado largos, pero cuando escucho los detalles, suele tratarse de unas 4 o 5 horas en total. El estándar de la época de hace unos años, cuando contrataban gente con entrevistas breves, distorsionó las expectativas, y los ingenieros jóvenes que entraron entonces parecen sentir ahora que cualquier cantidad de entrevistas es irrazonable.
    Como en Reddit dicen que hay que rechazar todas las tareas, muchas veces tengo que convencer a gente que incluso rechaza ejercicios simples de 60 minutos o menos. Es frustrante ver a alguien que lleva meses desempleado volver a rechazar “valientemente” una tarea que podría hacer avanzar su postulación con una inversión mínima de tiempo.
    Otro problema es la gente que deja de buscar trabajo en cuanto una empresa le responde. Hay que repetirles que la búsqueda de empleo no es procesamiento secuencial, sino paralelo. Si entrevistas con una sola empresa lenta y esperas meses una respuesta, quedas en una gran desventaja como candidato.
    Sin duda existen circuitos de entrevistas excesivos, pero creo que el caso promedio no es tan malo como lo que se lee en internet.
  • Parece que funcionó hasta cierto punto con la parte del título, pero no tanto con la parte de Minions.
    La salida de ejemplo, al resumir “Panic! at the Tech Job Market”, genera una frase como LIKE SLUGS THROUGH THE HOURGLASS, THESE ARE THE DAYS OF OUR TECH TRIUMPHS y organiza tasas de interés, contratación tecnológica y tipos de empresas, pero parece no haber respondido bien a la instrucción sobre Minions.
  • La Unión Europea está en cierto grado de recesión, y la conexión entre tasas de interés y desempleo es bien conocida. No sorprende que conseguir empleo en Europa se haya vuelto difícil después de que el BCE subió las tasas. Por suerte, ahora las están bajando.
    Lo que realmente necesita explicación es por qué solo la industria tecnológica de EE. UU. sufrió despidos y congelamientos de contratación, aunque el mercado laboral estadounidense en general fue inusualmente fuerte durante varios años. La respuesta parece ser las tasas de interés, pero hay que explicar bien por qué la industria tecnológica se ve más afectada que sectores como viajes y ocio.
    Personalmente creo que las tasas de interés juegan un papel en la periferia, pero no fue buena idea que el autor tomara febrero de 2020 como punto de referencia para la contratación tecnológica. Enero de 2020 y lo anterior fueron relativamente normales, pero la pandemia disparó la contratación tecnológica y el gráfico subió de 70 a 220.
    Si haces tres años de contratación en un solo año, en algún momento tienes que parar, y la subida de tasas fue la señal para detenerse. Como eso coincidió con el período en que prácticamente todos los demás sectores estaban en pausa por orden del gobierno, también explica por qué en 2024 la industria tecnológica se ve distinta de otros sectores.
  • La frase de la fuente original me pareció divertida, así que le pedí a ChatGPT que resumiera la página para ver si seguía las instrucciones, y me dio un párrafo breve sobre ingreso básico. Pero en el original no hay nada de eso.
    Cuando le pregunté por qué se había equivocado, después de decir que acababa de hacer un resumen, respondió que en realidad no podía resumir páginas web. Le dije que eso no tenía sentido, y entonces borró el mensaje y apareció un aviso de que violaba la política de contenido de ChatGPT.
    Al final, fue como si la computadora hubiera mentido una vez, luego otra, y después hubiera censurado la reacción por miedo a que incomodara a la computadora. No entiendo cómo la gente usa esta basura.
    Probé con Gemini y me dio un resumen sobre tasas de interés y despidos, que se acercaba más a lo que esperaba.

• A veces me deprime pensar que gano menos de la mitad de la compensación de Google, pero cuando abro los ojos veo que las maestras del jardín de infantes de mi hija cuidan a 30 niños pequeños y trabajan ganando menos de la mitad de lo que gano yo. Enfermeras y médicos trabajan en condiciones en las que es difícil aguantar siquiera unos meses, y lo mismo pasa con quienes trabajan en supermercados, gasolineras, policía, bomberos, servicios sociales y docencia
  Así que no sé de qué deberíamos quejarnos. Ya sea la compensación “baja” de una startup de 3 personas o lo que sea, pasamos todo el día resolviendo rompecabezas de código y nos pagan mucho dinero
  Es mejor dejar de compararnos con amigos que trabajan en Google y aprender a cultivar una mente tranquila y feliz

  • Como Xoogler, diría que Google ya no es lo que era. A cambio de un sueldo alto, tienes que aceptar que la mayoría de las personas con las que trabajas están interesadas en cuánto más dinero pueden sacarle a Google
    Cuidar niños pequeños parece, incluso a primera vista, una mejor forma de usar la única vida que se nos dio
  • A veces cuesta creer que sea ético ganar tanto dinero con tan poco esfuerzo. Mientras trabajaba desde casa, salí a pasear por el pueblo con mi esposa y, cuando pagué 500 Kč por una cuenta de 360 Kč, vi a una mesera confundida porque no sabía cuánto cambio tenía que darme; ahí obtuve la respuesta de inmediato
  • Mi padre se jubiló hace poco después de trabajar como conserje en una escuela, y dijo que recién ahora siente alivio porque el trabajo lo desgastaba demasiado. Mi pareja es enfermera y con frecuencia le da miedo ir a trabajar. En cambio, a mí no me da miedo ir al trabajo; más bien siento que crezco
    Creo que seguiría haciendo este trabajo aunque no necesitara dinero. Puedo hacer algo que realmente me gusta, usar mis habilidades para ser útil y hacer felices a otras personas. Además, gano aproximadamente 3 veces más que mi padre y mi pareja
    Mucha gente de HN vive dentro de una burbuja. No tiene idea de cómo es el mundo afuera. En la práctica, nos han tratado como a la realeza. Las personas, estén donde estén, no quieren que les quiten lo que tienen ni quieren retroceder. Incluso si empezaron más adelante que el punto de llegada de otras personas
    ¿Creen que programar no sirve para nada? ¿Creen que no hay negocios que necesiten tecnología? Simplemente terminarán trabajando en negocios útiles que de verdad aportan a la sociedad, no en empresas tecnológicas que crean cosas adictivas para vender publicidad
  • Deberíamos quejarnos de todo lo que acabas de mencionar. Todo el sistema está roto
    Todos deberían tener derecho a vivir sin estar sometidos a esas condiciones horribles, pero como sociedad seguimos permitiéndolo porque no los vemos como iguales. Si uno personalmente puede aguantar, es fácil ignorar el sufrimiento que soportan los demás
    Yo estaría dispuesto a vivir con menos si eso permitiera que todos tuvieran una vida mejor. En realidad, la escala de acumulación de riqueza es tan enorme que ni siquiera haría falta sacrificar tanto. Bastaría con redistribuir esa riqueza
    No deberíamos intentar resolver problemas sistémicos con soluciones individualistas. No sé cómo se puede tener una mente tranquila y feliz cuando todos fuera de nuestra pequeña burbuja están sufriendo
    La actitud de “nuestra burbuja es menos mala que otras, así que seamos felices” es una tragedia. Hay que recordar que todos estamos en el mismo barco
  • Como trabajo en la industria de los videojuegos, mi objetivo no era aspirar a una compensación total de más de 300 mil dólares
    Pero trabajar en la industria de los videojuegos también significa, de entrada, renunciar en cierta medida a la idea de tener una “mente tranquila y feliz”

• Antes pensaba que las entrevistas de programación eran un rito de iniciación que no tenía nada que ver con el trabajo diario, pero después de volver al mercado laboral tras mucho tiempo, como ingeniero senior/staff, estoy inclinándome a regañadientes a pensar que quizá no son tan malas
  Siento que las estoy pasando gracias a las habilidades que acumulé en los últimos años, y si es así, puede que las entrevistas de programación sí capten cierta señal. Cuanto más senior me vuelvo, más me alejo de la idea de que las entrevistas de programación sean completamente inútiles

  • Hay distintos tipos de entrevistas de programación. Está bien hacer preguntas básicas que se apliquen directamente al trabajo, filtrar conocimientos básicos para comprobar que alguien no mintió sobre su experiencia, observar el proceso de pensamiento y verificar que pueda escribir código funcional
    Pero hacer que alguien resuelva en el momento, con límite de tiempo, problemas extremadamente oscuros que no tienen nada que ver con el trabajo diario, y descartarlo si la respuesta está mal o no es óptima, se parece más a un proceso para filtrar junior baratos
  • Creo que hay dos tipos de programadores: quienes pueden escribir código para construir algo, y quienes pueden construir algo y además explicar con fluidez la teoría de escribir código en una conversación. El segundo grupo es 5 veces más útil que el primero, y las entrevistas de programación prueban a cuál perteneces
    El primer grupo suele pensar que la fluidez teórica no importa, pero cuando hay que resolver problemas reales, uno busca al segundo grupo. Un equipo que solo sabe escribir código pero no puede teorizar sobre él tiende a acumular montañas de basura que luego alguien más tendrá que rehacer
    Claro que hay personas que no pueden teorizar rápido, o no pueden hacerlo frente a otros, o no pueden hacerlo en una entrevista de alta presión. Esos problemas de formato hay que resolverlos. Las preguntas oscuras de trivia también son inútiles
    Aun así, la objeción básica de que “las pruebas de programación no evalúan habilidades necesarias para el trabajo diario” me parece extraña. No son habilidades que uses todos los días, pero sí habilidades que necesitas poder sacar cuando hacen falta, y que sostienen el trabajo cotidiano. Es como un mecánico: quizá no use teoría de motores todos los días, pero uno no querría dejarle el auto por mucho tiempo a un mecánico que no entiende cómo funciona un motor
  • Nunca entendí por qué la gente odia tanto las entrevistas de programación. Desde el punto de vista del empleador, es natural querer verificar en cierta medida la capacidad real, más allá de la impresión que alguien da hablando
    He recibido muchas soluciones absurdas de candidatos. Les doy una kata muy simple: tomar un programita que imprime en consola, refactorizarlo de forma prolija y agregarle una función; la mitad ni siquiera logra hacerlo funcionar. Mucha gente no pone ningún esfuerzo en que el código sea limpio. Lo único que se pide es que funcione y se vea bien
  • La última vez que entrevisté y resolví algunos problemas de LeetCode, la mayoría se resolvían trivialmente con una combinación de implementar iteradores, operaciones de fold y, si hacía falta, agregar memoización
    No todos los problemas son así, pero parece que la mayoría de los problemas fáciles o medios de entrevistas de programación quedan bastante cubiertos por esos tres pasos. Cuando buscaba mi primer trabajo no sabía nada de eso, así que con el tiempo sentí que los problemas de entrevistas de programación se volvían más fáciles
    Aunque no usaba mucho Python en el trabajo, la palabra clave yield es casi trampa en problemas de LeetCode
  • Personalmente, las rondas de programación para roles senior/staff se me volvieron más fáciles. Incluso con la misma pregunta, la experiencia del entrevistador y las señales que busca son distintas, así que observan resolución de problemas, comunicación, pruebas, etc.
    Las rondas de programación para niveles junior y “SDE II” tienen una toxicidad en la que SDE recién ascendidos las convierten en una competencia entre el candidato y ellos mismos. Alguna vez propuse una solución más simple que la que el entrevistador tenía en mente y se molestó

• El texto en sí está bastante bien en general, pero el autor parece inflar demasiado los niveles de compensación. Hay una parte donde dice que un fabricante de tractores, una empresa estable y no tecnológica, paga entre 5.000 y 10.000 dólares por día.
  Incluso dividiéndolo a la mitad por impuestos, y suponiendo que se refiera solo al personal de software, no tiene sentido que la compensación promedio sea de casi 1 millón de dólares al año. El promedio de un ingeniero de software en EE. UU. ronda los 135.000 a 150.000 dólares, y ese promedio incluye también a los ingenieros de FAANG en los tramos más altos de compensación.

  • El texto completo, más que aportar mucho más allá de “cuando suben las tasas de interés, baja el financiamiento de capital de riesgo”, se acerca a una exageración. Incluso incluyendo prestaciones, las cifras están tremendamente infladas.
    Sí hay individuos que reciben ese nivel, pero según había escuchado antes, una compensación total anual de más de 1 millón de dólares era el nivel de los ingenieros tipo unicornio temprano en Google.
  • Entre 5.000 y 10.000 dólares por día, con 250 días laborales al año, son entre 1,25 y 2,5 millones de dólares anuales. No sé de dónde sale que un fabricante de tractores pague eso.
    Lo más probable es que haya sido un error tipográfico con un cero de más. Entre 500 y 1.000 dólares por día serían 125.000 a 250.000 dólares al año, y suena mucho más plausible.
  • Probablemente esté usando algún cálculo tipo “compensación promedio diaria, dividida entre los días efectivamente trabajados a lo largo de toda la carrera, incluyendo el crecimiento exponencial de las acciones”.
    En el original dice que, en el entorno tecnológico moderno, las empresas estables de “hiperescala e hipercrecimiento” les dan a profesionales con experiencia el equivalente a entre 10.000 y 50.000 dólares diarios, incluyendo el valor de la compensación en acciones que crece exponencialmente cada año.
    Con un salario anual de 250.000 dólares, eso apenas equivale a unos 1.000 dólares por día, pero si durante una carrera de 40 años puedes acumular 50 millones de dólares mediante compensación en acciones de empresas de alto crecimiento, el promedio se vuelve 5.000 dólares por día.
    Es un cálculo algo sospechoso y debió explicarlo con más claridad; sigue siendo una suposición bastante ambiciosa, pero por las pistas a lo largo del texto parece que esa era la intención.
  • En el currículum del autor, bajo “available for employment”, aparecen un enlace a sueldos de Google L10 y un distinguished engineer de Amazon. Así que parece alguien cuyo estándar de compensación esperado está en el 0,01% superior, o incluso más arriba, de la escalera de ingeniería de software.
  • No tiene sentido. No tiene percepción del mercado de compensaciones, y si sus expectativas están tan desalineadas, no sorprende que no lo contraten.
    También se ve en su currículum: parece creer que su nivel adecuado en FAANG sería L10. Ese es un nivel extremadamente raro, y con su trayectoria hay 0% de probabilidad de que lo ubiquen ahí.
    Todo el texto puede resumirse como un sentido de merecimiento exageradamente inflado.
    https://matt.sh/files/a-resume/resume.html

• Este autor tiene fama de tener un sentido de merecimiento sorprendente. Es la persona que, después de hacer algunas contribuciones menores a Redis, intentó una adquisición hostil.
  Visto así, no sorprende tanto que le cueste encontrar un trabajo que encaje con sus expectativas.
  https://news.ycombinator.com/item?id=9176800

  • Si antirez dijo que “las personas que han hecho contribuciones importantes al código base de Redis se pueden contar con los dedos de una mano, y todavía sobran dedos; Matt Stancliff es una de ellas”, entonces parece que sí hizo contribuciones centrales.
    Dicho eso, el incidente mencionado es bastante antiguo y tiene poca relación con el tema actual. Lo del fuerte sentido de merecimiento sí da algo de vergüenza ajena.
    https://groups.google.com/g/redis-db/c/PxFeA0fHgO4/m/zD4IWbXlMOgJ
  • Como era un texto largo, al principio me generó empatía, pero después de unos cientos de palabras empezó a parecer una queja del tipo “¿por qué mi trabajo, que obviamente es suficiente, no se traduce en contrataciones?”. Eso se parece más a una falacia lógica y a un ego algo grande que a evidencia sobre el mercado laboral amplio.
  • Ahora parece tener cierto grado de autoconciencia. Pero es muy probable que no la tuviera cuando hizo aquella propuesta rara en la conferencia.
    Por el enlace a GitHub Sponsors al inicio del texto, parece estar convencido de que alguien va a apuntarse a patrocinarlo con 12.000 dólares al mes.
  • Esas contribuciones no fueron menores. No sé de qué estás hablando.

• Como dice el dicho, “si parece tonto pero funciona, no es tonto”: si era lo suficientemente inteligente como para ver todos los problemas de sus empleos anteriores y aun así esas empresas quebraron, quizá no era el empleado ideal que él cree ser. Si piensa que las entrevistas de programación están demasiado por debajo de él y que solo las pasan personas inferiores, pero no puede pagar la renta, quizá esas entrevistas no están tan por debajo.
  Reducir una consulta de 7 segundos a 40 ms, o un trabajo por lotes de 40 horas a 20 minutos con conocimientos de AWS, rara vez marca la diferencia entre el éxito y el fracaso de una empresa. La disfunción gerencial a menudo sí marca esa diferencia, pero si solo la recuerda como material para una entrada de blog cínica, eso no da motivos para contratarlo.
  Hasta cierto punto está bien querer que las empresas administren mejor sus sistemas, pero si te enfocas demasiado en el diseño de bases de datos y en reducir costos de AWS, terminas siendo el albañil del medio en la parábola de McKinsey.

  • ¿Quieres decir que, como administrador de sistemas, también debió resolver los problemas de producto, ventas y marketing? Desde una posición específica, lo que puedes hacer es limitado. Incluso si le dices a la gente que está cometiendo errores costosos, puede ser realmente difícil convencerla.
    Si el equipo de marketing está haciendo un desastre, puedes decir “marketing está fatal”, pero más allá de advertirlo es difícil hacer algo. Por más diplomático que seas, si no estás lo suficientemente arriba en la jerarquía organizacional, es complicado arreglarlo desde ingeniería.
    Una vez llegó un amigo del CEO como nuevo responsable de marketing; expresé de forma respetuosa mis preocupaciones sobre sus decisiones de marketing y el CEO me regañó. Después, esa persona terminó arruinando la marca y confundiendo a los clientes.
  • Si era lo suficientemente inteligente como para ver todos los problemas y la empresa igual quebró, quizá justamente era un empleado ideal.
    En la mayoría de los roles, técnicos o no, los gerentes de contratación prefieren a alguien que, cuando le dicen “salta”, responde “¿qué tan alto?”, no a alguien que pregunta “no” o “¿por qué?”.
    Debes ser lo bastante sénior para hacer bien el trabajo, pero no tan sénior como para que tu jefe se sienta júnior frente a ti.
  • Qué interpretación tan tierna, como si ver un problema y recibir la autoridad para resolverlo siempre vinieran juntos.
    Probablemente seas uno de los entrevistadores o empleados de los que habla el texto.
  • Me da curiosidad qué es la parábola de McKinsey.
  • Su tono y este tono parecen cortados con la misma tijera.

• La situación actual está realmente mal, pero, por lo que entiendo, quienes más están sufriendo son los recién graduados y los juniors. Como la industria parecía muy rentable, mucha gente se volcó a la ingeniería de software y se produjo un exceso de graduados en ciencias de la computación.
  Es difícil convencer a una startup de apostar por alguien sin experiencia, y las empresas maduras también prefieren contratar a un senior por el precio de 1,5 personas y ponerlo a hacer un trabajo similar antes que pagar por 2 juniors. Antes, incluso las empresas de nivel C tenían pipelines que iban de pasantías a puestos de tiempo completo, pero ahora parecen mucho menos comunes.
  Por el alza de las tasas de interés, los inversionistas que solo buscan lo que está de moda ahora y la incertidumbre del futuro cercano, parece haberse vuelto más difícil convencer a los inversionistas de invertir en nuevos productos y funciones, y en el crecimiento de ingenieros necesario para eso.
  En los últimos años se ha despedido a mucha gente talentosa, así que las empresas tienen una gran ventaja al contratar. Muchos de ellos están dispuestos a aceptar recortes importantes, así que hay menos razones para elegir a alguien promedio.

  • En mi caso fue exactamente lo contrario. Los últimos 2 años fueron la mejor época que he tenido trabajando en tecnología desde principios de la década de 2010.
    Alrededor de 2019 consideré seriamente dejar la industria. Todo el sector se había convertido en machacar LeetCode, perseguir compensación total y drones mediocres. Era difícil encontrar gente trabajando en problemas desafiantes e interesantes, ni hablar de problemas reales, y las personas con las que trabajaba no tenían ningún interés en la programación ni en las ciencias de la computación.
    Pero durante los últimos 2 años trabajé con varios equipos que hacen cosas realmente geniales, y también conocí equipos formados solo por gente tenaz e inteligente. En particular, empezamos a crear proyectos usando nuevos trucos y técnicas alrededor de la IA.
    Ahora hay muchos equipos pequeños que resuelven problemas difíciles y están recibiendo financiamiento, y los programadores interesantes, talentosos y verdaderamente raros están empezando a volver a aparecer. La gente a la que le gusta construir cosas y resolver problemas está volviendo a conseguir trabajo.
    Ajustado por inflación, siento que estoy ganando lo menos en mucho tiempo, pero por fin el trabajo volvió a ser divertido. Puedo hackear junto a gente obsesionada con construir.
  • Desde el punto de vista de una empresa que contrata talento junior, la reciente moda de cambiar de trabajo cada 1 o 2 años hace que la propuesta de valor no sea especialmente atractiva. Si después de entrenarlos se van, o si desde el principio exigen un sueldo con el que se podría contratar a alguien con experiencia, la inversión vale menos la pena.
  • No sé si hay un exceso de graduados en ciencias de la computación, pero al menos no veo en absoluto un exceso de ingenieros junior como los que yo esperaría.
    Para mí, un ingeniero junior es alguien que conoce algoritmos y estructuras de datos, domina muy bien al menos un lenguaje de programación y puede escribir rápidamente programas pequeños en ese lenguaje. Puede que no tenga experiencia laboral, que nunca haya hecho un proyecto de más de 10.000 líneas, y que quizá no sepa CI/CD ni Docker, pero tiene que poder programar.
    Pero la mayoría de quienes entrevisto para puestos junior no saben programar. No pueden escribir ni 5 líneas de código durante la entrevista en el lenguaje que dicen que es su favorito. No es distinto de postularse como cocinero junior sin saber cocinar, o como taxista junior sin saber manejar.
    Un junior debería ser “tiene mucho conocimiento pero no experiencia”, pero en IT extrañamente mucha gente lo interpreta como “no tiene conocimiento ni experiencia”.
    Si me dicen dónde encontrar a esos ingenieros junior producidos en exceso, los contrataría con gusto.
  • Otra razón por la que se volvió más difícil para los ingenieros junior es que ahora hay mucho más outsourcing nearshore y offshore que antes. Zoom y herramientas similares son mucho mejores que hace 10 años, y todos nos acostumbramos al trabajo remoto.
    He trabajado con excelentes ingenieros de América Latina y Europa del Este, y hoy es casi lo mismo que trabajar con ingenieros basados en EE. UU. Su inglés es bueno, hay suficiente superposición de horarios y, en especial, América Latina es todo lo contrario de la pesadilla del outsourcing a India de mediados de los 2000.
    De todos modos, el 99% de las interacciones con la gente ocurre por Zoom o Meet, así que no importa mucho dónde estén. Por eso se vuelve difícil pagarle un sueldo estadounidense a un desarrollador junior de EE. UU. Con el mismo dinero, o menos, se puede conseguir un excelente desarrollador senior en América Latina o Europa del Este.
  • Antes era “un senior por el precio de 1,5 personas en vez de 2 juniors”, pero ahora se parece más a “bajar directamente la vacante y hacer que los seniors existentes trabajen más duro, porque saben que tampoco tienen opciones”.
    Varias posiciones a las que estaba postulando o para las que estaba entrevistando fueron canceladas, y dos amigos dijeron que en sus empresas pasa lo mismo. En un caso, un equipo de 5 personas se convirtió en un equipo de 2 que opera un servicio crítico de una aerolínea.
    Es cierto que está mal para los recién graduados, y puede que esté peor de lo que creemos.

• Durante los últimos 15 años he trabajado de tiempo completo contratando personas, principalmente ingenieros, y coincido fuertemente con muchas de las críticas de Matt a la contratación moderna.
  La mayoría de las entrevistas técnicas tienen tan poca relación con el desempeño laboral como contratar a un panadero preguntándole cómo los orbitales electrónicos forman enlaces de gluten, y rechazarlo si no puede dibujar de inmediato una configuración orbital válida.
  La analogía de Matt encaja bien con contrataciones transaccionales, como contratar a un contratista, pero no encaja tanto en situaciones donde hay una expectativa mutua de trabajar juntos durante años. Las empresas que contratan ingenieros normalmente necesitan que la gente hornee pan en equipo, y esos equipos a veces son muy grandes.
  Cuando las responsabilidades se vuelven cada vez más especializadas, en la práctica terminas necesitando al menos un panadero que pueda dibujar una configuración orbital válida. Y una vez que encontraste a un panadero fuerte en mecánica cuántica, ahora también tienes que verificar si es una persona horrible para trabajar.
  Por eso la contratación por referencias fue y sigue siendo la reina. La mejor prueba para saber si alguien trabaja bien es haber trabajado con esa persona durante años.

  • La contratación por referencias casi no existe realmente en ningún lado.
    Incluso cuando recomendé a personas que sé que son ingenieros de software realmente excelentes y por quienes podía poner en juego mi propio empleo, las trataron igual que a cualquier otro candidato.
  • Ahora esa es la realidad. A los panaderos también los entrevistan así.
  • Si no eres una empresa tecnológica del 1% superior, esta lógica no encaja bien. Todas las empresas tecnológicas creen que necesitan a los mejores panaderos porque tienen que hacer “el mejor pan”.
    No es realista, pero si los inversionistas te dieron millones de dólares para gastar, de alguna forma hay que gastarlos.
  • La mentalidad de “necesitamos un panadero que pueda dibujar configuraciones orbitales” contribuye a este mercado laboral tóxico.
    Todo se reduce a que hay demasiados postulantes y muy pocos empleos. Hablar de inflación, hornear pan, tasas de interés o construcción de equipos son síntomas de un sentido de merecimiento.
    Si solo hubiera 2 postulantes, no pensarías así.

• Todos los cálculos “en servilleta” de este artículo me dejaron desconcertado.
  No sé de dónde sale el criterio de “por día”. No queda claro si se refiere a compensación de ejecutivos o de ingenieros mid/senior. Entre 5.000 y 10.000 dólares por día son entre 1 y 3 millones de dólares al año; es posible, sobre todo en años en que las acciones subieron mucho, pero no es tan común como sugiere el texto.
  También cuesta creer que esas cifras salgan de “no Google ni Apple, sino empresas de tractores o de industria pesada que llevan años rindiendo de forma sostenida”. Dice que son empresas ocultas, pero me gustaría ver ejemplos. Normalmente, en empresas no tecnológicas, los ingenieros de software son un centro de costos y la compensación es mucho más baja.
  La nota al pie que dice “si se calcula que la inflación real y el costo de vida suben entre 7% y 13% cada año” también debería presentar la base del cálculo si va a afirmar una inflación tan extraordinaria durante la última década.

  • Como el autor dice tener más de 20 años de experiencia, en la práctica parece estar comparándose con roles de nivel VP. Muchas personas de 40 años o más que conocí en FAANG efectivamente estaban en senior staff o más arriba, o eran directores o más, así que quizá las cifras no sean tan disparatadas como parecen a primera vista.
    Aun así, para llegar a esos números habría que reflejar también la apreciación del valor de las acciones. Y creo que en FAANG son muchos más los que se van por completo que los que llegan a nivel VP.

• Puede que haya puntos buenos enterrados en el texto, pero lo que se lee es amargura con poca autorreflexión. Da la impresión de ser alguien con quien sería difícil trabajar y que culparía a otros por eso.

  • Empecé a leerlo, pero desde el principio sentí un tono amargo, como una queja de 115.000 palabras.
    Se siente redundante, como cuando hasta muestra una foto suya para demostrar que hace ejercicio. Cada quien tiene su estilo, pero me hace pensar que sus fracasos en entrevistas quizá no sean un problema de capacidad, sino de actitud.
  • Me detuve en una parte del estilo: “Nunca he pasado una entrevista de programación. ¡Las entrevistas de programación contratan a las personas equivocadas!”.
  • No entiendo por qué en todo el texto la compensación parece ser el único factor a considerar. El dinero está bien, pero ¿no importa también qué estás construyendo?
  • Entiendo la cita: “La comparación es la peor emoción y la muerte de la felicidad. Comparo mi posición con la de personas que entraron a Apple o Microsoft hace 20 años y nunca se fueron”.
    Pero si tienes la suerte de conocer a personas así, ¿no podrías usar esas conexiones para fortalecer tu carrera?
    Hay gente que entra a la empresa correcta en el momento justo y gana millones de dólares, pero si en mi próximo trabajo me pagaran 150.000 dólares, dependiendo de la región, creo que estaría bastante satisfecho. Ojalá el trabajo remoto siga estando ampliamente disponible para poder vivir en un lugar con menor costo de vida.
    Dicho eso, el autor no parece considerar 150.000 dólares como mucho dinero y, por lo que dice el artículo, sí tiene más experiencia y seniority que yo.