Eu fiz um curso incrível sobre linguagens de programação, que propõe uma ótima discussão sobre o design de linguagens e suas motivações. Pensei em escrever sobre alguns pontos interessantes do curso, indicar para todos que gostam de experimentar novas linguagens, mas percebi que talvez não faça sentido.

O curso é bem longo para um MOOC, demorei cerca de 65-70 horas para terminá-lo de acordo com minhas estimativas. Durante o curso, são abordadas três linguagens: SML, Racket e Ruby. Não conhecia as duas primeiras, Ruby apesar popular, não tenho perspectivas de utilizá-la por enquanto.

É complicado recomendar – especialmente para alguém em começo de carreira – investir esse tempo todo em um curso que não agrega muito ao currículo. Talvez, listar essas linguagens peculiares chame a atenção de alguém mais técnico, mas certamente não chamará muita atenção dos recrutadores no LinkedIn.

Ao mesmo tempo que acho difícil recomendar do ponto de vista prático, adoraria que o máximo de pessoas o fizessem. As discussões sobre paradigmas de programação, “tipagem” e técnicas de programação são importantes, fornecem uma base para o aprendizado de outras linguagens.

Entendo que o motivo dessa contradição, entre o que acho bom para o currículo e o que acho bom para o trabalho, é devido a desconexão entre o que dizem ser o futuro profissional e os métodos de contratação aplicados a desenvolvedores.

Os anos de experiência

Uma tecnologia (e.g. linguagem, framework, banco de dados) precisa de um conjunto de fatores para fazer sucesso no mercado, sendo um dos principais a comunidade no entorno dela. Não adianta ter uma boa tecnologia, se não há suporte e mão de obra disposta a trabalhar com ela.

A disponibilidade de mão-de-obra é um problema complicado para a adesão de novas tecnologias, especialmente quando o critério do mercado para contratação de profissionais são os famigerados “anos de experiência”. O que gera situações como essa, do criador do Fast API, que acabou viralizando:

É fácil rir dessas vagas, infelizmente são várias com exigências absurdas, mas é um problema complexo e não um caso pontual. Há todo um ecossistema de recrutamento, formação e estrutura empresarial baseado nisso.

A ideia de “X anos de experiência” é uma heurística, que ajuda mas possui falhas como qualquer outra. Por exemplo, à medida em que os anos passam, se torna muito mais importante qual tipo de experiência você teve com a tecnologia do que o tempo em si. Dependendo do trabalho, 5 anos de experiência significam a experiência de 1 ano repetida 5 vezes.

Por outro lado, usar essa abordagem é extremamente prática para fazer uma triagem de currículos. Qualquer pessoa, com zero noção de TI, consegue pré-selecionar usando essa lógica. Para tecnologias consolidadas, esse critério simples é viável porque mesmo filtrando muita gente ainda terão vários candidatos para a vaga.

Apesar dessa abordagem descartar bons profissionais e supervalorizar alguns meia-boca, a roda vai girando dessa forma. Os profissionais e o mercado, em geral, acabam se adaptando a essa dinâmica.

Atalhos aos anos de experiência

As certificações e cursos costumam servir como um atalho para os anos de experiência, o que criou um ecossistema grande em torno dessa ideia.

A empresa que concede a certificação (e.g. Micosoft, Oracle, Cloudera) agiliza a criação de mão-de-obra, fortalecendo a posição da tecnologia no mercado. Os parceiros, que ministram cursos e aplicam a certificação, ganham alunos. O RH ganha mais informação para o processo de seleção e, por consequência, os profissionais também conseguem se mostrar qualificados sem precisar de “anos de experiência”.

Para tecnologias que não possuem certificação, cursos reconhecidos no mercado costumam fazer bem esse papel de qualificar profissionais com mais velocidade. Programas de graduação e pós-graduação – mais focados em rápida entrada no mercado de trabalho – também oferecem matérias focadas nas tecnologias mais demandadas.

Nada inerentemente errado em relação aos cursos e certificações, mas funcionam mais como um ajuste para o modelo existente que uma correção. E esse ajuste não está sendo o suficiente, para o mercado atual e futuro, que adota mais rapidamente novas tecnologias e se torna mais heterogêneo.

O mercado heterogêneo

Não tenho dados ou referência para afirmar, mas sinto que o mercado tem se tornado muito mais ágil e flexível para adotar novas tecnologias. Incluindo as grandes empresas, que costumam ser as mais lentas nesse aspecto.

Quando entrei no mercado – 10 anos atrás – as grandes empresas se restringiam a poucas opções de “stacks” tecnológicos. Legados de grande porte ficavam no mainframe e de menor porte em Visual Basic ou Delphi, enquanto os novos sistemas eram majoritariamente Java ou .NET. As startups sempre tiveram mais variedade, mas talvez fossem menos ousadas nesse aspecto.

Hoje, o mercado parece mais receptivo a trabalhar com novas tecnologias, os motivos são vários e merecem uma reflexão a parte. Mas para exemplificar essa percepção, podemos pensar um pouco no cenário das linguagens de programação. A consolidação das plataformas, com linguagens compatíveis entre si, facilitou a adoção de uma maior variedade delas pelo mercado.

Por exemplo, a JVM suporta várias linguagens além do Java. Scala é usada em projetos de Big Data populares, como Spark e Kafka. O Clojure ganhou destaque “regional” com o NuBank. Por fim, temos o Kotlin que foi adotado pelo Android e frameworks populares. Outras plataformas também tem cenários parecidos, como o front-end e as várias linguagens que transpilam para Javascript.

Nesse contexto, não tem como esperar uma grande quantidade de profissionais com anos de experiência e certificados/cursos nessas novas linguagens. Mais importante, talvez os profissionais dispostos a trabalhar com essas tecnologias não estão interessados em certificados, muito menos em cumprir anos de experiência.

Quem deseja trabalhar nesse mercado?

Eu seria um desses profissionais, que gostam de trabalhar com várias tecnologias e não “fazer currículo” em uma. Fiz mudanças bruscas de tecnologias durante minha carreira e acabo tendo um histórico que não me qualifica como programador senior em nada.

Para piorar, também não tenho muito interesse em cursos práticos e menos ainda em certificações. Consigo perder essas 60 horas em um curso teórico, com retorno intangível para o meu trabalho atual, mas não consigo dedicar meu tempo às provas de certificação.

Minha forma de aprender é meio caótica, depende muito do assunto e nível de profundidade, se é algo mais prático ou conceitual também. Mas o ponto não é como eu aprendo, e sim como é complicado mostrar isso no modelo de currículos quando é uma abordagem não estruturada.

A experiência variada, combinada com poucos de cursos e certificações, tornam meu currículo estranho se olhado pelo prisma de “anos de experiência”:

  • Java na graduação
  • Python na pós-graduação
  • 5 anos em Oracle (PL/SQL e Forms)
  • 1 ano como full stack (PHP, Coffeescript, SASS, GCP)
  • 2 anos como engenheiro de dados (Spark, Hive, etc..)
  • 2 anos como cientista de dados

Somente com essas informações, como definir quão bom eu seria como programador Python ou Clojure? Não é possível deduzir muito, mesmo para alguém com conhecimento técnico, muito menos para a etapa da busca de candidatos que geralmente é conduzida pelos recrutadores.

Entrando em mais detalhes dessa lista de experiências, fazendo algum teste e com uma entrevista, provavelmente conseguiriam medir minhas capacidades. O problema é que a heurística dos anos de experiência já foi quebrada, os 10 anos são compostos de vários experiências relativamente curtas e desconexas para quem bate o olho no currículo.

Entendo que muitos trabalhos se beneficiam mais de um especialista que um generalista, como algo de tiro curto ou evolução de um sistema existente. Se o escopo é fechado, não tem o porquê escolher um profissional de conhecimentos mais gerais em detrimento a um mais especializado.

Por outro lado, é de se pensar que especialistas deveriam ser exceção e não a regra. Tanto quem contrata quanto quem é contratado ganhariam com essa abordagem, o primeiro com mais opções de profissionais e o segundo com maior variedade de oportunidades. Só que, se adaptar ao generalista, exige mudanças que estão longe de ser simples.

Novos processos

Uma solução para esse problema passa por deixar o processo de seleção mais complexo e consequentemente mais caro, tanto para empresa quando para o candidato. Empresas populares, como o Stack Overflow, podem ser dar ao luxo de aplicar processos elaborados, que extraem muitas informações dos candidatos em vários aspectos.

No entanto, a maioria das empresas não podem exigir tanto esforço/tempo dos candidatos que simplesmente desistiriam. Além disso, muitas vezes é necessário contratar muita gente em um curto espaço de tempo, o que pode tornar um processo elaborado inviável.

No final, o ajuste de um processo de contratação de profissionais é similar a um problema de classificação em machine learning. Mais dados de qualidade ajudam a melhorar os resultados, mas sempre há um limite no quanto de informação você tem acesso. Isso cria um teto de desempenho para o processo, mas ainda cabe à empresa ajustar para ser um processo com maior precisão ou sensibilidade.

Um processo rigoroso e rápido, conseguirá muita precisão e pouca sensibilidade. Ou seja, descartará muitos candidatos mas terá certeza de que os contratados serão bons. Um processo rápido e mais acessível conseguirá muitas pessoas, mas provavelmente nem todas serão boas.

Só a empresa pode definir onde ela se encaixa, tanto em relação ao quanto ela pode exigir de tempo/esforço dos candidato quanto em relação às prioridades do processo.

Ajustando o processo à realidade

A dificuldade em definir um bom processo é justamente porque não dá para aplicar a receita usada em outra empresa. A posição de mercado e o escopo de atuação definem muito do processo, não faz sentido copiar o processo de uma startup e aplicar em uma consultoria.

O Vale do Silício popularizou testes de algoritmos e estruturas de dados, os méritos dessa abordagem são muito discutidos. Alguns acham desnecessário e elitista enquanto outros acham que avaliam habilidades importantes. Acredito que ambos estão corretos em algum nível, pois avaliam habilidades relevantes, mas acabam descartando desnecessariamente boa parte de candidatos.

No final, esses testes acabam filtrando não bons profissionais, mas selecionando formados (recentes) em ciência de computação. Não faz sentido para a grande maioria do mercado, já que nem é uma habilidade realmente necessária para grande parte dos trabalhos de TI.

O Google, por sua vez, pode se dar ao luxo de usar esse processo e ter um processo seletivo de alta precisão e baixa sensibilidade como esse, afinal eles têm infinitos ótimos candidatos e não precisam correr o risco de aceitar um mediano.

Em geral, a ideia de copiar os melhores é uma boa receita, mas para recrutamento provavelmente não é um bom plano.

É complexo…

Acredito que haja melhorias universais para os processos, como melhores descrições de vagas e algum nível de automação, mas boa parte do processo depende das características da empresa, candidatos e vaga. Por mais que eu esteja fazendo os paralelos do processo de seleção com machine learning, recrutamento Data Driven não parece ser a panaceia como estão vendendo.

Em algum nível, a forma de contratação molda o mercado como um todo. As empresas consideram as opções de tecnologia, em partes, pela disponibilidade de profissionais. O ensino se molda às demandas do mercado, já que empregabilidade é um critério chave dos alunos. Até decisões técnicas são influenciadas, já que a expectativa de ter experiência em várias tecnologias gera um incentivo ao overengineering.

Não tenho muita experiência com recrutamento, mas sempre me pareceu um processo sub-otimizado e cada vez mais distante da realidade atual e do futuro. Acredito que os processos tenham melhorado, mas ao custo de mais tempo e esforço, o que talvez seja inevitável nesse novo contexto.

Ironicamente, é um processo especialmente complexo de especificar e automatizar, a contratação de programadores.