"Not a real engineer" de verdade (2019)

• O curto poema em prosa parte da declaração “You are not a real engineer” e sobrepõe, no mesmo contexto, uma notificação de reprovação em entrevista e a imagem de um monstro mítico
• O alvo é retratado como um ser transcendental com altura humana, cabeça de leão, dezesseis asas e centenas de olhos, além de um cinto em forma de serpente
• A respiração como nuvens de tempestade, a voz como o rugido do vento e os passos que fazem a grama murchar ampliam continuamente o poder esmagador da figura
• No fim, vem a frase de recusa de contratação — “não vamos oferecer este cargo neste momento” — seguida da justificativa de que “estamos procurando alguém mais técnico”
• Até mesmo uma entidade destrutiva é rejeitada por não ser alguém mais técnico, revelando o absurdo do critério de “engenheiro de verdade”

---

Descrição que se expande até virar uma entidade mítica

• A frase inicial é “You are not a real engineer”, declarando diretamente ao alvo que ele não é um engenheiro de verdade
• Em seguida, o alvo cresce e se torna uma criatura com porte humano e cabeça de leão, descrita com dezesseis asas brancas e centenas de olhos como tochas
• O cinto em sua cintura é uma serpente, seu hálito é um ajuntamento de nuvens de tempestade, e sua voz se aproxima do rugido do vento
• Diante de seus passos, a grama murcha, e sua língua negra como um abismo profundo traz o fim a tudo que toca

A reviravolta criada pela fórmula de rejeição em contratação

• O desfecho muda abruptamente da descrição avassaladora para a fórmula educada de recusa típica de um processo seletivo
• Depois da frase “não vamos oferecer este cargo neste momento”, vem a justificativa de que “estamos procurando alguém mais técnico”
• O choque entre as imagens míticas anteriores e a frase comum de rejeição em contratação no final expõe a fragilidade da expressão “engenheiro de verdade”

[GN⁺]

Comentários no Hacker News

• Hoje em dia, desisti da ideia de contratar engenheiros geniais para vagas em que 80% do tempo de trabalho é construir aplicações CRUD.
  É desperdício de dinheiro e de pool de talentos, não é bom para o candidato e vira um risco de longo prazo para a empresa. Essas pessoas acabam ficando entediadas e provavelmente começam a fazer overengineering só para usar a cabeça.
  Para a maioria dos engenheiros, basta escrever corretamente operações de criar, alterar, excluir e consultar no nível do banco de dados e da API, chamar a API no frontend e ter tratamento de erros adequado e uma abordagem decente de depuração.

  • Já fui gerente de contratação em várias equipes, mas não era tão simples assim. É verdade que não é preciso um John Carmack para tarefas técnicas que não são de nível John Carmack.
    Mas também já vi programadores “decentes” entregarem resultados “mais ou menos”, e programadores melhores trabalharem 5 vezes mais rápido sem trabalhar 5 vezes mais, praticamente se autogerenciarem, não exigirem que QA fique em cima para confirmar se um ticket marcado como concluído estava mesmo pronto e resolverem problemas de forma criativa sem precisar que alguém destravasse o repositório Git por eles.
    Não é preciso uma mente excepcionalmente inquieta, mas programadores bons/ótimos fazem uma grande diferença mesmo em projetos que parecem tecnicamente comuns.
  • No mundo atual de SPAs e microsserviços, a pessoa que você acabou de descrever é praticamente um engenheiro genial.

• Ultimamente tenho me interessado por Steve Howe, e vi algo em que ele, considerado um dos maiores guitarristas de todos os tempos, dizia que gostaria que guitarristas se concentrassem em se tornar músicos. A diferença entre coders e engenheiros é parecida.
  Já vi muitos programadores tecnicamente mais capazes do que eu, mas eles não eram engenheiros melhores. O fato de eu ser fundador e também ter alguma experiência em marketing pesa bastante.
  Muitas empresas subestimam as competências que não envolvem código e que realmente formam um engenheiro. É como contratar um açougueiro em vez de um chef e depois estranhar que a comida não esteja boa.

  • Isso é verdade até certo ponto, mas foge um pouco do perfil padrão que costuma entrar em engenharia.
    Fazer uma graduação técnica, trabalhar como engenheiro nº 52354 em lugares como Ingersoll Rand ou Boeing e se aposentar 30 anos depois como especialista em uma área complexa, porém limitada, também é uma ótima carreira. Essa também é uma definição válida de “engenheiro”, e essas pessoas podem parecer entediantes, mas provavelmente levam vidas pessoalmente gratificantes.
    Tenho pensado muito sobre esse problema ultimamente: executivos tendem a ver o engenheiro padrão como centro de custo, enquanto alguém como o autor do texto consegue escapar dessa crítica porque seu valor se estende além da engenharia, até outros departamentos que geram receita diretamente.
    Acho que sou um engenheiro de tipo parecido, mas venho tentando transformar meu desprezo por esse estereótipo em uma atitude mais colaborativa.
  • Mas esse é o mercado. 99% dos empregadores não querem engenheiros; querem coders baratos no framework da moda.
    O mercado real valoriza mais um coder Spring Java do que um engenheiro C++ que trabalha com hardware.
  • Quais seriam exemplos de competências que não envolvem código e que fazem alguém se tornar um engenheiro melhor?
  • Só um pequeno adendo: Howe é excelente e de fato um dos melhores, mas Paco De Lucia está muito acima.

• Já passei pelos dois lados. Já enfrentei as oscilações inexplicáveis e as pequenas humilhações do processo de busca de emprego, e também já entrevistei e rejeitei candidatos experientes que falavam bonito, mas não conseguiam programar um problema de nível FizzBuzz em linguagem nenhuma.
  Não é uma questão de escolher apenas uma entre “entrevistas técnicas são uma bagunça” e “há muitos candidatos sem qualificação no mercado de trabalho”. As duas coisas podem ser verdade, e na prática acho que estão conectadas como em um mercado de limões.

  • Aprendi que é importante entender que entrevistas, e a busca de emprego de forma mais ampla, não são processos objetivos e justos, e que os resultados não são determinísticos nem reproduzíveis.
    Uma pessoa objetivamente melhor pode ser contratada, e um candidato ideal pode ser descartado logo na triagem por telefone. No fim, é quase sorte; quem diz o contrário mistura viés de sobrevivência com relutância em admitir que o próprio processo é falho.
    A ideia de julgar um candidato experiente dizendo que ele nem conseguiu resolver algo no nível FizzBuzz também reflete o pensamento de culto à carga que assola contratações. Conheço engenheiros de FANG que precisam praticar por semanas code golf e quizzes de algoritmos e estruturas de dados que não se parecem com engenharia de software real para passar na primeira entrevista.
    Chego a achar que esses problemas são mais parecidos com puxar a escada do que com avaliação técnica. Certa vez fui eliminado automaticamente de uma vaga C++ para criar aplicativos desktop porque não sabia placement new, e um conhecido que se candidatou a uma vaga de backend criou um serviço Spring do zero e passou em todos os testes de integração, mas foi reprovado porque não havia comentários nos controllers. Há entrevistadores que tratam algo que poderia ser resolvido com um comentário de uma linha em um PR como se fosse um grande desafio técnico e eliminam a pessoa por isso.

• Quem contrata também comete erros. Contratar bem é realmente difícil.
  Às vezes, isso acaba salvando você de trabalhar em um lugar com pessoas de quem você não gostaria de qualquer forma. Elas também não são muito boas em inventar desculpas plausíveis para explicar por que não contrataram alguém, e boa parte é sorte.
  Por exemplo, talvez tenham tido a impressão de que você “não parece apoiador do Trump” e sentido que não conseguiriam conviver confortavelmente com você. Se você realmente não é do tipo deles, por que faria questão de trabalhar lá?
  Procurar emprego sempre me deixa deprimido, e não sei a resposta além de não criar expectativas grandes demais em relação a uma vaga específica. Ao mesmo tempo, também não se deve descartar com facilidade oportunidades que não parecem tão incríveis.
  Meu primeiro chefe no emprego atual era terrível e não havia muita gente boa, mas eles saíram da empresa e eu fui promovido. Como prever isso? O recrutador também não consegue prever você; o processo inteiro é bastante aleatório e desconfortável.
  Quando estou do lado de quem entrevista, tenho prioridades. Primeiro, meu chefe me deu um conselho curto: “tente contratar uma boa pessoa”. Prefiro trabalhar com um bom desenvolvedor que seja gentil, ajude os outros e se dê bem com a equipe do que com alguém que sempre precisa fazer tudo do próprio jeito e acredita ser um gênio superprodutivo que deve ter carta branca.
  Segundo, observo se o candidato se interessa por software ou pelo menos por alguma coisa. Se não houver nem um pouco de entusiasmo por software, tecnologia ou algo relacionado ao trabalho, como a pessoa vai aprender o que for necessário e não estiver no currículo? As pessoas não chegam como “produto acabado”; é preciso esperar que elas aprendam.

  • Por que você faria questão de trabalhar lá se realmente não é do tipo deles? Porque precisa pagar o aluguel. E às vezes, como luxo, também gostaria de comer.

• Acho que mesmo um bom processo de entrevista certamente pode rejeitar algumas pessoas que, na prática, teriam feito o trabalho muito bem.
  Para entender de verdade se alguém se encaixa naquela função, o tempo exigido no processo de entrevista fica grande demais tanto para o empregador quanto para o candidato. Para o empregador, é uma má alocação de recursos; para o candidato, é difícil de aceitar.
  O ideal seria o candidato ir ao escritório e concluir sozinho, ao longo de um dia, um pequeno projeto de programação, mas na realidade isso não é prático.