Pânico no mercado de empregos

• O mercado de empregos em tecnologia está mudando em uma direção desfavorável para desenvolvedores, com a combinação de alta dos juros, redução do financiamento de VCs, retração dos gastos dos clientes e processos de contratação padronizados
• A remuneração e a estabilidade variam conforme o estágio de financiamento, receita e crescimento da empresa; em um ambiente de juros altos, quanto maior a dependência de VC, mais a empresa tende a quebrar ou encolher para modo de sobrevivência
• A contratação moderna em tecnologia se concentra mais em testes de programação e entrevistas comportamentais do que na experiência real de trabalho, com startups pequenas e grandes empresas de tecnologia copiando processos parecidos
• Vagas no estilo “Everything Bagel” juntam trabalhos de vários departamentos em uma única função: desenvolvimento de aplicações, infraestrutura, segurança, suporte ao cliente, plantão, otimização de custos e documentação
• As funções de tecnologia estão deixando de melhorar produto e organização ao mesmo tempo e virando um papel de executor com pouca autonomia, que cumpre prioridades de terceiros, sem refletir adequadamente a experiência e o julgamento de desenvolvedores qualificados

---

A conexão entre juros e empregos em tecnologia

• Com o fim do ambiente de juros baixos, próximo de “dinheiro grátis”, e a alta dos juros para níveis acima de 5%, parte-se da premissa de que o próprio custo do dinheiro ficou mais caro
• Quando os juros sobem, organizações com caixa podem deixar o dinheiro em lugares mais seguros, como produtos de renda com garantia do governo, em vez de investir em empresas incertas
• Investimentos em empresas de tecnologia são tratados como ativos de risco baseados em um futuro incerto; em períodos de juros altos, empresas fracas quebram e até empresas fortes reduzem pessoal sob o pretexto de “clean house”
• Como resultado, surge a observação de que centenas de milhares de trabalhadores de tecnologia bem remunerados passam a enfrentar, por 2 a 4 anos, um mercado com escassez de vagas
• Em períodos de alta de juros, podem aumentar empregos de meio período com salário mínimo ou na construção, mas empregos em tecnologia estão muito mais ligados ao financiamento de VCs e aos gastos dos clientes

Tipos de empresa e estrutura de remuneração

• Empresas de tecnologia podem ser divididas em quatro tipos conforme seu financiamento e estágio de crescimento
  • nepo company: empresa que consegue criar produtos irreais com dinheiro afastado da validação da realidade, como recursos de família ou de contatos pessoais
  • speculation company: empresa que recebe financiamento para experimentar uma ideia sem validação de produto, clientes ou mercado
  • initial growth company: empresa que, após surgir uma demanda inicial, recebe capital de crescimento para tentar expandir a receita
  • stable era company: empresa estável, com caminho repetível de entrada no mercado, acesso a clientes e receita recorrente
• Em um ambiente de juros altos, quanto menos bem-sucedida é a empresa, mais ela depende de capital de VC e mais sofre quando o fluxo de dinheiro desacelera ou desaparece
• Clientes também têm condições de gasto mais restritas, então pode haver perda de clientes ou redução de gastos ao mesmo tempo
• A speculation company é descrita como um lugar que paga de 50% a 80% do valor de mercado e espera 200% a 500% mais trabalho
• A initial growth company pode se tornar uma combinação de alto risco e baixa remuneração, e empresas de crescimento que fracassam podem ficar presas a baixa remuneração e demissões recorrentes
• A stable era company se divide novamente em três tipos
  • Empresas que crescem de forma estável e dão lucro
  • Empresas que alternam entre crescimento e encolhimento conforme a inclinação de um CEO famoso
  • Empresas que dominam um ou mais setores econômicos e não quebram facilmente
• Grandes empresas modernas em crescimento podem pagar a funcionários experientes o equivalente a US$ 10 mil a US$ 50 mil por dia, incluindo remuneração anual em ações, enquanto outras empresas podem passar 10 anos sem crescimento real de salários ou sem remuneração efetiva em ações

O problema dos processos seletivos que não distinguem a capacidade real

• Três contradições se repetem na contratação em tecnologia
  • Os requisitos estão quebrados
  • O processo de entrevista está quebrado
  • A maioria das empresas segue os mesmos requisitos e o mesmo modelo de entrevista
• Entrevistadores podem não ser capazes de avaliar de forma confiável candidatos que dão respostas melhores do que as que eles esperavam
• Entrevistas modernas de tecnologia exigem a execução improvisada de tarefas sem relação com o trabalho real; se o candidato falha, é tratado como pouco capaz, mas o processo pode não distinguir pessoas com experiência de nível mais alto
• Testes de programação ao estilo Google e entrevistas comportamentais ao estilo Amazon foram copiados por toda a indústria, e desde pequenas startups até grandes empresas exigem processos parecidos
• Entrevistas comportamentais repetem perguntas como “como você resolveu um conflito?” e “qual foi uma experiência em que você errou e pediu desculpas?”, sendo interpretadas, na prática, como um processo para observar como o candidato equilibra avanço e gentileza
• Quando o ajuste cultural é codificado em formato de pergunta e resposta, isso pode levar a uma homogeneização de personalidade, filtrando pessoas que se afastam da personalidade média da empresa
• Se a empresa continua adicionando etapas de entrevista e se distancia do trabalho real, da experiência, da capacidade e do insight, toda a indústria de tecnologia pode se tornar ineficiente

Vagas “Everything Bagel”

• Uma vaga “Everything Bagel” é um formato que exige responsabilidades demais ao mesmo tempo de um único Software Development Engineer
• Exemplos de requisitos incluem
  • Escrever aplicações com React, Vue, TypeScript, Node, Python, Rust, Go etc.
  • Manter aplicações legadas em PHP, Ruby e C
  • Fazer deploy de infraestrutura com AWS, Docker, Kubernetes, Terraform, Lambda, EventBridge, Step Functions etc.
  • Otimizar custos na AWS, CI/CD, plantão 24/7 e garantir logs, monitoramento, alertas e observabilidade
  • Segurança de aplicações, segurança de dependências e segurança de infraestrutura relacionada a SOC-2
  • Suporte ao cliente, suporte a funcionários internos, revisão de código, mentoria e documentação
  • Manter 37 plugins SaaS em JavaScript e scripts adicionais de rastreamento
• Esses requisitos para uma única função, na prática, se aproximam do trabalho de 5 departamentos e uma equipe de 20 pessoas
• Parte da indústria parece ter desistido da ideia de que tecnólogos devem ter especialização e, no estilo “devops means DEVS DO OPS”, empurra operações para desenvolvedores sem experiência operacional
• Em uma estrutura em que desenvolvedores de aplicação também atuam como arquitetos AWS em meio período, é difícil esperar bons resultados; a posição é que essas competências normalmente exigem 5 anos ou mais de construção focada
• Requisitos excessivos tornam o trabalho fisicamente impossível, e cada item pode virar uma tarefa de vários dias por semana, fazendo a pessoa já começar atrasada no primeiro dia

Problemas organizacionais e de infraestrutura vistos pela experiência em campo

• Várias empresas diziam que “o site está lento”, mas, na prática, casos em que problemas ficaram abandonados por não se olhar para métricas básicas da AWS e administração de sistemas se repetiram
• Uma empresa operava todo o serviço em um único MySQL de 2 cores e 16 GB de RAM; o banco de dados cresceu até 3 TB, e o estado de CPU a 99,99% persistiu por 2 anos
  • Após a troca para um servidor ARM de 64 GB com reserved IOPS, o tempo de transformação de dados em batch caiu de 16 horas para 20 minutos, e o atraso de replicação passou de 4 a 6 semanas para nível sub-second em tempo real
• Outra empresa gastava US$ 5.000 por mês em um cluster de pesquisa sem uso, enquanto usava apenas cerca de US$ 500 por mês em recursos no cluster de produção real
  • Ao mover os recursos para o cluster de produção e migrar para ARM, o tempo de resposta para usuários caiu de 7 segundos para 200 ms
• Em uma empresa onde uma API interna de processamento de dados rodava nos mesmos dois EC2 de 2 cores que os servidores web de clientes, o processamento em batch levava 20 horas
  • Depois da migração para contêineres com autoscaling baseados em ECS-on-EC2, 20 a 50 contêineres processavam simultaneamente, e o tempo de processamento caiu para 30 minutos
• Uma empresa cuja ferramenta para mover dados do MySQL para o Redshift levava 80 horas executava primeiro SELECT COUNT(*) em uma tabela de 3 bilhões de linhas e depois percorria a tabela inteira com LIMIT/OFFSET
  • Com a introdução de cursores de banco de dados, escrita em streaming para S3 e compressão em memória, o tempo de extração caiu de 80 horas para 40 minutos
• Quando se desvaloriza experiência em administração de sistemas e arquitetura sob o argumento de ser “cloud native”, pode não haver sequer alguém capaz de detectar o problema, e o mesmo problema pode ficar abandonado por longos períodos
• Mesmo em situações em que clientes estavam indo embora, VCs exigiam “mais vendedores”, gerando casos com 5 desenvolvedores e 50 pessoas em vendas e marketing
• Quando uma empresa com queda de receita insiste na ideia existente e em uma estratégia centrada em vendas, em vez de transição ou melhoria de produto, desenvolvedores não conseguem criar o produto desejado, levando ao fracasso da empresa

Experiência e entregas reais ignoradas no mercado de contratação

• Há a percepção de que, nos últimos 10 a 20 anos, a forma de contratar em tecnologia mudou de uma avaliação simples de “sabe mexer bem com computadores” para uma estrutura centrada em status social e no jogo das entrevistas
• O processo de resolver problemas e falar de improviso passou a ter mais peso do que o trabalho real, a experiência e a capacidade
• Projetos pessoais e entregas reais também são considerados pouco refletidos na avaliação de entrevistas
  • mpreg: sistema distribuído de processamento de dados com resolução automática de dependências por ordenação topológica hierárquica
  • Melhoria no processamento de CRC: mencionado como código usado em formatos globais de arquivo e na verificação de informações da estação espacial
  • icli: CLI para negociação manual e automática de ações
• Há uma preocupação de que a indústria tenha se aproximado mais de status e poder social e político do que da capacidade real, e de que a contratação deveria caminhar na direção de criar mais “us”
• Funções de tecnologia colocam trabalho amplo demais em uma só pessoa e, ao mesmo tempo, a contratação não observa suficientemente a experiência real, criando uma estrutura difícil para candidatos suportarem

Autonomia de desenvolvedores e protagonismo no produto

• A conclusão é que empregos na indústria de tecnologia ficaram ligados a financiamento especulativo excessivo e, quando dinheiro e clientes diminuíram, os empregos também desapareceram
• Muitas funções de tecnologia teriam se transformado em uma estrutura de “software servant”, executando tarefas e prioridades definidas por equipes de produto não técnicas
• Em Engineering-led management, quem faz o trabalho define o produto, conversa com usuários, estabelece requisitos e implementa funcionalidades
• O papel de desenvolvedor já foi resolver problemas do ponto de vista do negócio como um todo, mas hoje é visto como mais próximo de um executor de gestão de projetos, que cumpre ideias e prioridades de outras pessoas
• Mesmo com a mesma função e o mesmo esforço, a diferença de remuneração cresceu: em uma empresa se recebe US$ 400 por dia, em outra US$ 20 mil por dia, e essa comparação aumenta a sensação de impotência de quem procura emprego
• Criar bons produtos, bons sistemas, produtos em crescimento e uma economia em crescimento continua sendo a direção que tecnólogos devem perseguir

[GN⁺]

Opiniões no Hacker News

• Não é um problema apenas da engenharia de software ou de setores adjacentes. Conhecidos na Europa também estão tentando mudar de emprego ou conseguir promoções verticais ou laterais em setores completamente diferentes, de finanças a moda, mas estão fracassando de forma bem séria.
  Hoje em dia, a maioria dos processos seletivos não olha para o histórico da pessoa nem para sua possível contribuição; é só uma sequência de portões a atravessar. O currículo enviado a portais de emprego fica mais como sedimento afundado no fundo da pilha, então é melhor usar redes de contato e conhecidos sempre que possível.
  Eu também fui atingido pela queda nas vagas de tecnologia e, ao tentar entrar em uma consultoria de software, fiquei 8 meses no banco. No fim, saí e voltei a trabalhar com avaliação empresarial e tributária; mesmo o subemprego é melhor do que nada, especialmente para a saúde mental.
  A fonte original também contém uma pequena frase: “escorreguei nesta banana como um macaco preguiçoso”.

  • O ponto central é a parte de que “hoje em dia a contratação tem portões demais e não olha para o histórico da pessoa nem para sua possível contribuição”. Quando me candidatei antes, perguntaram coisas como “você tem experiência com C++ ou algoritmos avançados de grafos?”, mas não havia nada disso no meu perfil nem no meu currículo.
    Mesmo assim, reagiram como se meus 10 anos de experiência em software e áreas relacionadas tivessem sido subitamente invalidados. É estranho tratar alguém que aprendeu e usou várias linguagens como se fosse incapaz de usar C++ só porque usou C++ implicitamente apenas um pouco.
    Uma empresa dizia no anúncio que experiência em Python não era necessária, mas na primeira entrevista por telefone despejou perguntas de implementação de baixo nível em Python. Se é assim, não sei por que fazem a entrevista; é desperdício de tempo para todo mundo.
    No fim, as empresas simplesmente não sabem contratar e, pelo mesmo motivo, também não sabem fazer mentoria nem treinamento. Mas, do ponto de vista do candidato, isso também pode servir como um filtro natural: um lugar que não sabe contratar provavelmente não é um bom lugar para trabalhar.
  • Tenho orientado formandos em ciência da computação nos últimos anos, e às vezes há empresas que exigem tarefas excessivas no processo de entrevista, como criar um app ou site inteiro. Nesses casos, aconselho a recusar, mas na prática isso é raro.
    Também há muitas reclamações de que o processo de entrevista é longo demais, mas, quando se escuta em detalhes, com frequência dá algo em torno de 4 a 5 horas no total. O padrão da época, alguns anos atrás, em que se contratava alguém com entrevistas curtas, distorceu as expectativas, e os jovens engenheiros que entraram naquela época agora parecem achar qualquer volume de entrevistas irracional.
    Como no Reddit dizem para recusar todas as tarefas, muitas vezes é preciso convencer pessoas que recusam até tarefas simples de 60 minutos ou menos. É frustrante ver alguém desempregado há meses “corajosamente” recusar de novo uma tarefa que poderia fazer a candidatura avançar com um investimento mínimo de tempo.
    Outro problema são as pessoas que param de procurar emprego assim que uma empresa responde. É preciso repetir o tempo todo que busca de emprego não é processamento sequencial, é processamento paralelo. Entrevistar com uma empresa lenta e esperar meses por uma resposta coloca o candidato em grande desvantagem.
    Loops de entrevista excessivos certamente existem, mas acho que, na média, a situação não é tão ruim quanto se lê na internet.
  • Parece que funcionou em certa medida no lado do título, mas não tão bem na parte dos Minions.
    A saída de exemplo, dizendo resumir “Panic! at the Tech Job Market”, criou uma frase como LIKE SLUGS THROUGH THE HOURGLASS, THESE ARE THE DAYS OF OUR TECH TRIUMPHS e organizou juros, contratações em tecnologia e tipos de empresa, mas parece não ter reagido direito à instrução dos Minions.
  • A União Europeia está, em certa medida, em recessão, e a ligação entre juros e desemprego também é bem conhecida. Não surpreende que tenha ficado mais difícil conseguir emprego na Europa depois que o BCE elevou os juros. Felizmente, agora estão reduzindo os juros.
    O que realmente precisa de explicação é por que, apesar de o mercado de trabalho dos EUA como um todo ter estado excepcionalmente forte por alguns anos, apenas o setor de tecnologia americano passou por demissões e congelamento de contratações. A resposta parece ser juros, mas é preciso explicar melhor por que o setor de tecnologia é mais afetado do que setores como viagens e lazer.
    Pessoalmente, acho que os juros têm um papel periférico, mas não foi uma boa escolha o autor usar fevereiro de 2020 como ponto de referência para contratações em tecnologia. Janeiro de 2020 e o período anterior eram relativamente normais, mas a pandemia fez as contratações em tecnologia dispararem, levando o gráfico de 70 para 220.
    Se você faz três anos de contratações em um ano, em algum momento precisa parar, e a alta dos juros virou esse sinal de parada. Como isso coincidiu com um período em que todos os outros setores estavam, na prática, em licença por ordem do governo, isso também explica por que o setor de tecnologia parece diferente dos demais em 2024.
  • Achei a frase da fonte original engraçada e pedi ao ChatGPT para resumir a página, para ver se ele seguiria as instruções; ele me entregou um parágrafo curto sobre renda básica. Só que não há nada disso no original.
    Quando perguntei por que estava errado, depois de ter acabado de dizer que fez o resumo, respondeu que na verdade não podia resumir páginas da web. Eu disse que isso não fazia sentido; então ele apagou a mensagem e apareceu um aviso de violação da política de conteúdo do ChatGPT.
    No fim, foi como se o computador tivesse mentido uma vez, mentido de novo e depois censurado a reação por medo de desagradar o computador. Não sei como as pessoas usam esse lixo.
    Testei no Gemini, e ele deu um resumo sobre juros e demissões, o que ficou mais perto do resultado esperado.

• Às vezes fico deprimido pensando que recebo menos da metade da remuneração do Google, mas, quando abro os olhos, vejo as professoras da pré-escola da minha filha cuidando de 30 crianças pequenas e trabalhando ganhando menos da metade do que eu ganho. Enfermeiros e médicos trabalham em condições em que é difícil aguentar até alguns meses, e o mesmo vale para supermercados, postos de gasolina, polícia, bombeiros, assistência social e professores.
  Então não sei do que deveríamos reclamar. Seja a remuneração “baixa” de uma startup de 3 pessoas ou qualquer outra coisa, nós passamos o dia inteiro resolvendo quebra-cabeças de código e recebendo muito dinheiro por isso.
  É melhor parar de se comparar com amigos que trabalham no Google e aprender a cultivar uma mente tranquila e feliz.

  • Falando como Xoogler, o Google não é mais o que era. Em troca do salário alto, você precisa aceitar o fato de que a maioria das pessoas com quem trabalha está interessada em arrancar o máximo possível de dinheiro do Google.
    Cuidar de crianças pequenas parece, mesmo à primeira vista, um rumo melhor para gastar a única vida que nos foi dada.
  • Às vezes é difícil acreditar que seja ético ganhar tanto dinheiro com tão pouco esforço. Durante o trabalho remoto, eu estava passeando pela cidade com minha esposa quando paguei 500 Kč por uma conta de 360 Kč e vi a garçonete ficar confusa sem saber quanto troco deveria dar; ali obtive a resposta na hora.
  • Meu pai se aposentou recentemente depois de trabalhar como zelador de escola, e disse que só agora sente alívio, porque o trabalho moía demais as pessoas. Minha esposa é enfermeira e regularmente sente pavor de ir trabalhar. Já eu não tenho medo de ir ao trabalho; pelo contrário, sinto que estou crescendo.
    Acho que continuaria fazendo este trabalho mesmo que não precisasse de dinheiro. Posso fazer algo de que realmente gosto, usar minhas habilidades para ser útil e deixar outras pessoas felizes. Além disso, ganho cerca de 3 vezes mais do que meu pai e minha esposa.
    Muitas pessoas do HN estão dentro de uma bolha. Não têm a menor ideia de como é o mundo lá fora. Isso porque, na prática, foram tratadas como realeza. As pessoas, onde quer que estejam, não querem que tirem o que têm nem querem dar passos para trás. Mesmo que tenham começado mais à frente do que o ponto de chegada de outra pessoa.
    Você acha que programação é inútil? Acha que não há negócios que precisem de tecnologia? Você simplesmente vai trabalhar em negócios úteis que de fato contribuem para a sociedade, e não em empresas de tecnologia que criam coisas viciantes para vender anúncios.
  • Deveríamos reclamar de tudo o que você acabou de dizer. O sistema inteiro está quebrado.
    Todos deveriam ter o direito de viver sem serem submetidos a essas condições terríveis, mas continuamos permitindo isso porque, socialmente, não os vemos como iguais. Se nós, pessoalmente, conseguimos aguentar, fica fácil ignorar o sofrimento que os outros suportam.
    Eu aceitaria viver com menos se todos pudessem ter uma vida melhor. Na prática, a escala de acumulação de riqueza é tão grande que nem seria preciso sacrificar tanto assim. Bastaria redistribuir essa riqueza.
    Não devemos tentar resolver problemas sistêmicos com soluções individualistas. Não sei como ter uma mente tranquila e feliz quando todos fora da nossa pequena bolha estão sofrendo.
    A atitude de “a nossa bolha é menos ruim do que outras bolhas, então vamos ficar felizes” é uma tragédia. Precisamos lembrar que estamos todos no mesmo barco.
  • Como trabalho na indústria de games, minha meta não era buscar uma remuneração total acima de 300 mil dólares.
    Mas trabalhar na indústria de games também significa, desde o começo, abrir mão em certa medida da ideia de ter uma “mente tranquila e feliz”.

• Antes eu achava que entrevistas de programação eram um rito de passagem sem nenhuma relação com o trabalho do dia a dia, mas agora, como engenheiro sênior/staff voltando ao mercado de trabalho depois de muito tempo, estou relutantemente me inclinando para a ideia de que talvez elas não sejam tão ruins assim.
  Tenho a sensação de que estou passando graças às habilidades que acumulei nos últimos anos; se for assim, talvez as entrevistas de programação capturem algum sinal. Quanto mais sênior fico, mais me afasto da ideia de que entrevistas de programação são completamente sem sentido.

  • Há vários tipos de entrevista de programação. Fazer perguntas básicas que serão aplicadas diretamente ao trabalho, filtrar conhecimentos fundamentais para verificar se a pessoa não inventou a experiência, observar o processo de raciocínio e confirmar que ela consegue produzir código funcional — tudo isso é aceitável.
    Mas fazer a pessoa resolver na hora, com limite de tempo, problemas extremamente obscuros sem nenhuma relação com o trabalho diário, e eliminá-la se a resposta estiver errada ou não for ótima, parece mais um processo para filtrar juniores baratos.
  • Vejo dois tipos de programadores: pessoas que conseguem escrever código para construir algo, e pessoas que conseguem construir algo e, além disso, têm fluência suficiente para explicar em conversa a teoria por trás da escrita de código. O segundo grupo é 5 vezes mais útil que o primeiro, e a entrevista de programação testa em qual grupo a pessoa está.
    O primeiro grupo costuma achar que a fluência teórica não é importante, mas, quando é preciso resolver problemas reais, é o segundo grupo que você procura. Uma equipe que só sabe escrever código e não consegue teorizar sobre ele tende a empilhar uma montanha de lixo que outra pessoa terá de reconstruir depois.
    Claro que há pessoas que não conseguem teorizar rapidamente, ou não conseguem fazer isso diante dos outros, ou não conseguem em uma entrevista de alta pressão. Esses problemas de formato precisam ser resolvidos. Perguntas obscuras de conhecimento enciclopédico também não fazem sentido.
    Ainda assim, a objeção básica de que “testes de programação não avaliam habilidades necessárias no trabalho diário” é estranha. Não é uma habilidade que você usa todos os dias, mas é uma habilidade que precisa ser acionada quando necessário e que sustenta o trabalho de todos os dias. É como um mecânico: ele pode não usar teoria de motores todos os dias, mas eu não gostaria de deixar meu carro por muito tempo com um mecânico que não entende como um motor funciona.
  • Nunca entendi por que as pessoas odeiam tanto entrevistas de programação. Do ponto de vista do empregador, é natural querer verificar em alguma medida a capacidade real, em vez de ficar apenas com a impressão obtida por conversa.
    Já recebi muitas soluções absurdas de candidatos. Peço um kata bem simples: refatorar de forma bonita um pequeno programa que produz saída no console e adicionar uma funcionalidade; metade nem consegue fazê-lo funcionar. Muita gente não faz o menor esforço para deixar o código limpo. O que se pede é apenas fazê-lo funcionar e deixá-lo apresentável.
  • Na última vez em que fiz entrevistas e resolvi alguns problemas do LeetCode, a maioria foi resolvida de forma trivial com uma combinação de implementar iteradores, operações de fold e, quando necessário, adicionar memoização.
    Nem todos os problemas são assim, mas a maioria dos problemas de entrevista de programação de nível fácil/médio parece ser coberta de forma bastante geral por esses três passos. Quando procurei meu primeiro emprego, eu não sabia nada disso; por isso, com o tempo, senti que os problemas de entrevista de programação ficaram mais fáceis.
    Embora eu não use muito Python no trabalho, a palavra-chave yield é praticamente apelona em problemas do LeetCode.
  • Pessoalmente, as rodadas de programação para cargos sênior/staff ficaram mais fáceis. Mesmo com a mesma pergunta, a experiência do entrevistador e os sinais que ele procura são diferentes: eles observam resolução de problemas, comunicação, testes etc.
    As rodadas de programação para níveis júnior e “SDE II” têm uma toxicidade em que SDEs recém-promovidos transformam aquilo em uma competição entre eles mesmos e o candidato. Já aconteceu de eu apresentar uma solução mais simples do que a que o entrevistador tinha em mente, e ele ficar incomodado.

• O texto em si é, em geral, bom, mas o autor parece inflar demais o nível de remuneração. Há um trecho em que ele diz que uma fabricante de tratores, uma empresa estável e não tecnológica, paga de US$ 5 mil a US$ 10 mil por dia.
  Mesmo dividindo pela metade por incluir impostos, e mesmo considerando apenas funcionários de software, uma remuneração média de quase US$ 1 milhão por ano não faz sentido. A média dos engenheiros de software nos EUA é de cerca de US$ 135 mil a US$ 150 mil, e essa média inclui também engenheiros da FAANG nas faixas mais altas de remuneração.

  • O texto inteiro beira o exagero, com pouco a acrescentar além de “quando os juros sobem, o dinheiro de venture capital diminui”. Mesmo incluindo benefícios, os números estão muito inflados.
    Existem indivíduos que recebem nesse nível, mas, pelo que ouvi no passado, remuneração total anual acima de US$ 1 milhão era o patamar de engenheiros unicórnio dos primórdios do Google.
  • US$ 5 mil a US$ 10 mil por dia dá US$ 1,25 milhão a US$ 2,5 milhões por ano, considerando 250 dias úteis. Não sei de onde viria esse valor em uma fabricante de tratores.
    Provavelmente foi um erro de digitação com um zero a mais. US$ 500 a US$ 1.000 por dia daria US$ 125 mil a US$ 250 mil por ano, o que é muito mais plausível.
  • Acho que talvez ele esteja usando um cálculo do tipo “remuneração média diária equivalente dividida pelos dias efetivamente trabalhados ao longo de toda a carreira, incluindo o crescimento exponencial das ações”.
    No original, diz que, no ambiente tecnológico moderno, empresas estáveis de “hiperescala e hipercrescimento” pagam a profissionais experientes o equivalente a US$ 10 mil a US$ 50 mil por dia, incluindo o valor da remuneração em ações que cresce exponencialmente a cada ano.
    Um salário anual de US$ 250 mil dá só cerca de US$ 1.000 por dia, mas, se durante uma carreira de 40 anos for possível acumular US$ 50 milhões em remuneração em ações de empresas de alto crescimento, a média vira US$ 5.000 por dia.
    É um cálculo meio suspeito, que deveria ter sido explicado com mais clareza, e ainda assim parte de premissas bastante ambiciosas, mas pelas pistas ao longo do texto parece que era essa a intenção.
  • No currículo do autor, abaixo de “available for employment”, há um link para salário de Google L10 e a menção a distinguished engineer da Amazon. Então ele parece ser alguém cujo parâmetro esperado de remuneração na escada de engenheiros de software está no 0,01% mais alto, ou até acima disso.
  • Absurdo. Ele não tem noção da remuneração de mercado e, se as expectativas estão tão desalinhadas assim, não surpreende que não esteja sendo contratado.
    Isso também aparece no currículo: ele parece achar que o nível adequado na FAANG seria L10. Esse é um nível extremamente raro, e a chance de a carreira dele ser enquadrada nesse nível é 0%.
    O texto inteiro pode ser resumido como um senso de merecimento exageradamente inflado.
    https://matt.sh/files/a-resume/resume.html

• Este autor tem reputação por um senso de merecimento impressionante. Foi a pessoa que, depois de fazer algumas contribuições menores ao Redis, tentou uma aquisição hostil.
  Vendo por esse lado, não é tão surpreendente que ele tenha dificuldade para encontrar um emprego que corresponda às expectativas.
  https://news.ycombinator.com/item?id=9176800

  • Considerando que antirez disse que “dá para contar nos dedos de uma mão, e ainda sobram dedos, as pessoas que fizeram contribuições importantes para a base de código do Redis, e Matt Stancliff é uma delas”, parece que ele de fato fez contribuições essenciais.
    Dito isso, o episódio mencionado é bem antigo e pouco relevante para o assunto atual. O senso de merecimento forte é meio constrangedor, porém.
    https://groups.google.com/g/redis-db/c/PxFeA0fHgO4/m/zD4IWbXlMOgJ
  • Por ser um texto longo, no começo eu até me identifiquei, mas depois de algumas centenas de palavras passou a parecer uma reclamação do tipo “por que meu trabalho, claramente suficiente, não se converte em contratação?”. Isso é menos uma evidência sobre o mercado de trabalho como um todo e mais uma falácia lógica com um ego um pouco grande.
  • Parece que agora ele desenvolveu algum grau de autoconsciência. Mas é bem provável que não tivesse isso na época em que fez aquela proposta estranha na conferência.
    Pelo link do GitHub Sponsors no topo do texto, ele parece ter certeza de que alguém vai assinar um patrocínio de US$ 12.000 por mês.
  • Essas contribuições não foram menores. Não sei do que você está falando.

• Como diz o ditado, “se parece idiota, mas funciona, então não é idiota”: se ele era inteligente o bastante para enxergar todos os problemas dos empregos anteriores e ainda assim essas empresas fracassaram, talvez ele não fosse o funcionário ideal que imagina ser. Se ele acha que entrevistas de programação estão abaixo dele e que só pessoas inferiores passam nelas, mas não consegue pagar o aluguel, talvez essas entrevistas não sejam tão inferiores assim.
  Usar conhecimento de AWS para reduzir uma consulta de 7 segundos para 40 ms, ou um job em lote de 40 horas para 20 minutos, raramente é o que separa o sucesso do fracasso de uma empresa. Disfunções de gestão muitas vezes fazem essa diferença, mas, se ele só guarda isso como material para posts cínicos no blog, não dá a ninguém um motivo para contratá-lo.
  Querer que empresas administrem melhor seus sistemas é bom até certo ponto, mas, ao se concentrar demais em design de bancos de dados e redução de custos de AWS, ele acaba virando o pedreiro do meio na parábola da McKinsey.

  • Você está dizendo que, como administrador de sistemas, ele deveria ter resolvido também problemas de produto, vendas e marketing? Em certas posições, o que dá para fazer é limitado. Pode ser realmente difícil convencer as pessoas, mesmo quando você avisa que elas estão cometendo erros caros.
    Se a equipe de marketing está fazendo besteira, dá para dizer “o marketing está uma bagunça”, mas é difícil ir além de avisar. Por mais diplomático que você seja, se não estiver alto o suficiente na hierarquia organizacional, é difícil corrigir isso pelo lado da engenharia.
    Uma vez, um amigo do CEO entrou como novo chefe de marketing, e eu levei uma bronca do CEO por expressar educadamente minhas preocupações sobre as decisões de marketing dele. Depois, esse chefe destruiu a marca e confundiu os clientes.
  • Se ele era inteligente o bastante para enxergar todos os problemas e a empresa fracassou, talvez ele fosse justamente o funcionário ideal.
    Na maioria dos cargos, técnicos ou não, gestores de contratação preferem alguém que, quando mandam “pule”, pergunta “qual a altura?”, não alguém que pergunta “não” ou “por quê?”.
    É preciso ser sênior o suficiente para fazer bem o trabalho, mas não tão sênior a ponto de fazer o chefe se sentir júnior.
  • Que interpretação bonitinha, como se enxergar um problema e receber autoridade para resolvê-lo sempre viessem juntos.
    Provavelmente você é um dos entrevistadores ou funcionários mencionados no texto.
  • Fiquei curioso para saber qual é a parábola da McKinsey.
  • O tom dele e esse seu tom parecem cortados do mesmo tecido.

• A situação agora está realmente muito ruim, mas, pelo que entendo, quem mais está sofrendo são recém-formados e juniores. Como o setor parecia bastante lucrativo, muita gente migrou para engenharia de software, e houve uma produção excessiva de formados em ciência da computação.
  É difícil convencer uma startup de que ela deve apostar em alguém sem experiência, e empresas mais maduras também preferem contratar 1 sênior por 1,5 vez o preço, para fazer um trabalho parecido, a pagar por 2 juniores. Antes, até empresas de nível C tinham um pipeline de estágio para efetivação, mas agora isso parece muito mais raro.
  Com a alta dos juros, investidores procurando só o que está em alta agora e a incerteza no futuro próximo, parece ter ficado mais difícil convencer investidores a bancar novos produtos/funcionalidades e o crescimento de engenheiros necessário para isso.
  Nos últimos anos, muita gente talentosa foi demitida, então as empresas têm uma grande vantagem na contratação. Muitos deles estão dispostos a aceitar cortes consideráveis, o que reduz o motivo para escolher alguém mediano.

  • No meu caso foi exatamente o oposto. Os últimos 2 anos foram o melhor período que tive trabalhando no setor de tecnologia desde o começo dos anos 2010.
    Por volta de 2019, pensei seriamente em deixar o setor. A indústria inteira tinha virado moagem de LeetCode, corrida por remuneração total e drones medianos. Era difícil encontrar gente lidando com problemas desafiadores e interessantes, quanto mais problemas reais, e as pessoas com quem trabalhei não tinham nenhum interesse em programação ou ciência da computação.
    Mas, nos últimos 2 anos, trabalhei com várias equipes fazendo coisas realmente incríveis e encontrei equipes formadas só por pessoas persistentes e inteligentes. Em especial, comecei a criar projetos usando novos macetes e técnicas em torno de IA.
    Agora há muitas equipes pequenas recebendo financiamento para resolver problemas difíceis, e programadores interessantes, talentosos e realmente estranhos estão começando a aparecer de novo. Pessoas que gostam de construir coisas e resolver problemas estão voltando a conseguir trabalho.
    Considerando a inflação, acho que estou ganhando o mínimo em muito tempo, mas finalmente o trabalho voltou a ser divertido. Posso hackear junto com pessoas obcecadas por construir.
  • Do ponto de vista das empresas que contratam talentos juniores, a proposta de valor não é particularmente atraente por causa da moda recente de trocar de emprego a cada 1 ou 2 anos. Se você treina a pessoa e ela vai embora, ou se ela já exige um salário no nível em que daria para contratar alguém experiente, o investimento passa a valer menos a pena.
  • Não sei se há excesso de formados em ciência da computação, mas pelo menos não vejo nenhum excesso de engenheiros juniores como eu esperaria.
    Para mim, um engenheiro júnior é alguém que conhece algoritmos e estruturas de dados, conhece muito bem pelo menos uma linguagem de programação e consegue escrever rapidamente pequenos programas nessa linguagem. Pode não ter experiência prática, talvez nunca tenha feito um projeto com mais de 10 mil linhas e talvez não conheça CI/CD ou Docker, mas precisa saber codar.
    Só que a maioria dos candidatos a vagas juniores não sabe codar. Não consegue escrever nem 5 linhas de código durante a entrevista na linguagem que afirma ser sua favorita. Não é diferente de se candidatar a cozinheiro júnior sem saber cozinhar, ou a taxista júnior sem saber dirigir.
    Um júnior deveria ser “tem bastante conhecimento, mas não tem experiência”, mas, em TI, estranhamente muita gente entende como “não tem conhecimento nem experiência”.
    Se alguém me disser onde encontrar esses engenheiros juniores produzidos em excesso, ficarei feliz em contratá-los.
  • Outro motivo pelo qual ficou mais difícil para engenheiros juniores é que hoje há muito mais outsourcing nearshore e offshore do que antes. Zoom e afins estão muito melhores do que há 10 anos, e todo mundo se acostumou ao trabalho remoto.
    Já trabalhei com ótimos engenheiros da América Latina e do Leste Europeu, e hoje é quase igual a trabalhar com engenheiros baseados nos EUA. O inglês é bom, há sobreposição suficiente de horário, e, especialmente no caso da América Latina, é o completo oposto do pesadelo do outsourcing para a Índia em meados dos anos 2000.
    Como 99% das interações com as pessoas acontecem de qualquer forma no Zoom ou no Meet, onde elas estão faz pouca diferença. Então fica difícil pagar salário americano a um desenvolvedor júnior dos EUA, porque pelo mesmo valor, ou menos, dá para conseguir um ótimo desenvolvedor sênior na América Latina ou no Leste Europeu.
  • Antes era “1 sênior por 1,5 vez o preço em vez de 2 juniores”, mas agora está mais para “retira a vaga do ar e faz os seniores existentes trabalharem mais pesado, porque eles sabem que eles também não têm opções”.
    Várias posições às quais me candidatei ou para as quais estava entrevistando foram canceladas, e dois amigos disseram que a mesma coisa está acontecendo nas empresas deles. Em um caso, uma equipe de 5 pessoas virou uma equipe de 2 operando um serviço essencial de uma companhia aérea.
    É ruim para recém-formados, sim, e talvez seja pior do que parece.

• Passei os últimos 15 anos trabalhando em tempo integral na contratação de pessoas, principalmente engenheiros, e concordo fortemente com boa parte das críticas do Matt à contratação moderna.
  A maioria das entrevistas técnicas tem tão pouca relação com o desempenho no trabalho quanto contratar um padeiro perguntando como orbitais eletrônicos formam ligações de glúten e eliminá-lo se ele não conseguir desenhar imediatamente uma configuração orbital válida.
  A analogia do Matt funciona bem para contratações transacionais, como contratar prestadores de serviço, mas não funciona tão bem em situações em que há uma expectativa mútua de trabalhar juntos por vários anos. Empresas que contratam engenheiros normalmente precisam fazer pessoas assarem pão em equipe, e essa equipe às vezes é muito grande.
  À medida que as responsabilidades ficam cada vez mais subdivididas, na prática você acaba precisando de pelo menos um padeiro que consiga desenhar uma configuração orbital válida. E, se encontrou um padeiro forte em mecânica quântica, agora também precisa verificar se essa pessoa é horrível de se trabalhar junto.
  Por isso, contratação por indicação era e continua sendo rei. O melhor teste para saber se alguém trabalha bem é trabalhar com essa pessoa por alguns anos.

  • Contratação por indicação quase não existe de fato em lugar nenhum.
    Mesmo quando indiquei pessoas que eu sabia serem engenheiros de software realmente excelentes e pelas quais eu poderia apostar meu próprio emprego, elas foram tratadas exatamente como qualquer outro candidato.
  • Agora essa é a realidade. Até padeiros são entrevistados assim.
  • Se não for uma empresa de tecnologia do top 1%, essa lógica não se aplica muito bem. Toda empresa de tecnologia acha que precisa fazer “o melhor pão”, então precisa dos melhores padeiros.
    Não é realista, mas, se os investidores deram milhões de dólares para gastar, de algum jeito precisam gastar.
  • Esse tipo de pensamento de “precisamos de um padeiro que consiga desenhar configurações orbitais” contribui para este mercado de contratação tóxico.
    O problema todo é haver candidatos demais e vagas de menos. Conversas sobre inflação, assar pão, juros e formação de equipes são todas sintomas de um senso de direito.
    Se houvesse apenas 2 candidatos, eles não pensariam assim.

• Todos os cálculos de guardanapo deste texto me deixaram perplexo
  Não sei de onde veio o critério “por dia”. Não fica claro se é remuneração de executivo ou de engenheiro intermediário/sênior. US$ 5 mil a US$ 10 mil por dia dá US$ 1 milhão a US$ 3 milhões por ano; é possível, especialmente em anos em que as ações sobem muito, mas não é tão comum quanto o texto sugere
  Também é difícil acreditar que esses números venham de “não Google ou Apple, mas uma empresa de tratores ou de indústria pesada que vem entregando resultados de forma consistente há anos”. Dizem que são empresas escondidas, mas fico curioso se há exemplos. Em geral, em empresas não tecnológicas, engenheiros de software são centros de custo, então a remuneração é bem menor
  A nota de rodapé “se calcularmos que a inflação real e o custo de vida sobem 7% a 13% ao ano” também precisaria apresentar a base do cálculo para sustentar uma inflação tão excepcional ao longo dos últimos 10 anos

  • Como o autor disse ter mais de 20 anos de experiência, parece que está comparando, na prática, com cargos de nível VP. Muitas pessoas de 40 anos ou mais que conheci em FAANG de fato estavam em níveis de senior staff para cima ou de diretor para cima, então talvez os números não sejam tão absurdos quanto parecem à primeira vista
    Ainda assim, para chegar a esses valores, seria preciso considerar também a valorização das ações. E acho que há muito mais gente que sai da FAANG do que gente que chega a nível VP lá

• Pode até haver bons pontos enterrados no texto, mas o que se lê é um amargor com pouca autorreflexão. Parece alguém difícil de trabalhar e que jogaria a responsabilidade nos outros

  • Comecei a ler, mas desde o início senti um tom amargo, como se fosse um texto de reclamação de 115 mil palavras
    Dá a impressão de ficar se repetindo, até mostrando uma foto própria para provar que faz exercícios. Cada um tem seu jeito, mas fiquei pensando que as falhas em entrevistas talvez não sejam um problema de competência, e sim de atitude
  • Parei no trecho do tipo “nunca passei em uma entrevista de programação. Entrevistas de programação contratam as pessoas erradas!”
  • Não entendo por que a remuneração é a única consideração no texto inteiro. Dinheiro é bom, mas o que se constrói também não importa?
  • Entendo a citação “comparação é a pior das emoções e a morte da felicidade. Comparo minha posição com a de pessoas que entraram na Apple ou na Microsoft há 20 anos e nunca saíram”
    Mas, se você tem a sorte de conhecer essas pessoas, não poderia usar essas conexões para fortalecer a carreira?
    Há quem entre na empresa certa no momento certo e ganhe milhões de dólares, mas, se eu recebesse US$ 150 mil no meu próximo emprego, dependendo da região, acho que ficaria bem satisfeito. Seria bom se o trabalho remoto continuasse amplamente disponível, permitindo morar em um lugar com custo de vida mais baixo
    Dito isso, o autor não parece considerar US$ 150 mil muito dinheiro e, pelo conteúdo do artigo, ele de fato tem mais experiência e senioridade do que eu