Se tem uma área do conhecimento onde os debates são quase sempre bem acalorados, essa área é a do desenvolvimento de software. Tem todo tipo de disputa, das mais bobas como Tab vs. Espaço, temas claros ou escuros, 80 colunas ou não, etc. até as mais complicadas: tipos estáticos ou dinâmicos (ou qualquer variante doida), OO ou funcional, código aberto ou software livre, etc.

Em comum com todas essas discussões é a tendência entre os debatedores de apelar para conclusões binárias: “é isso aqui ou está errado.”

Essa postura também aparece quando as pessoas que estão habituadas a um conjunto de conceitos precisa se adaptar a outros conceitos. Um exemplo: a pessoa que usa Windows (ou Linux) reclamando do botão de maximizar janela do macOS. Ela com certeza vai reclamar e dizer que aquilo está errado. Mas se você lembrar que a primeira empresa a lançar uma interface baseada em janelas para o grande público foi a Apple e só depois o Windows e o Linux surgiram fazendo diferente, quem está “errado” nessa história?

No meio do desenvolvimento de software, talvez porque computadores eletrônicos que usamos sejam binários, adoramos a segurança das respostas absolutas. Isso é certo. Aquilo é certo. Isso é errado. Aquilo é errado.

No mundo Python onde eu trabalho tem até um termo (que eu detesto) para isso: pythônico. Todo mundo ouve, mas ninguém sabe o que é.

Mas o tempo me ensinou que as coisas podem simplesmente “ser”. Nem certas e nem erradas. Provavelmente diferentes, provavelmente similares.

Indiferente das alternativas se parecerem ou não, uma coisa é certa: cada uma das opções tem os seus pontos favoráveis (prós) e seus pontos desfavoráveis (contras). E, quando escolhemos uma opção, temos que renunciar às outras. É a tragédia (e a beleza) da vida.

Entrevista de emprego

Toda essa introdução serviu para falar sobre uma coisa que eu sempre faço quando estou entrevistando um candidato para uma vaga: perguntas específicas com poucas alternativas de respostas onde nenhuma das alternativas é certa ou errada.

Vou dar um exemplo com a minha famosa pergunta sobre ORMs.

Um ORM (Object-Relational Mapper) são softwares que servem para conectar o mundo dos objetos em um sistema orientado a objetos aos registros (linhas, tuplas, etc.) de um banco de dados relacional.

Esse tipo de software é bem complicadinho de se escrever porque o modelo relacional tem algumas diferenças fundamentais com o modelo orientado a objetos e lidar com essas diferenças sempre força o desenvolvedor a fazer certas escolhas em detrimento de outras.

Não vou detalhar muito essas diferenças e nem as alternativas aqui porque elas não são tão importantes para a pergunta e nem para a resposta, mas recomendo a leitura dos artigos que falam sobre esse tópico. Certamente vai te tornar um programador melhor.

Quando estou com o candidato eu mando um diálogo parecido com esse:

— Você sabe o que é um ORM?
— [se o candidato disser que não, eu pulo para outra pergunta parecida, senão eu prossigo… se o candidato estiver meio nervoso, eu também aviso que a próxima pergunta não tem uma resposta certa e nem errada e que eu só quero entender como ele pensa sobre programação orientada a objetos].
— Suponha que eu te peça para implementar um ORM em Python para usarmos em nosso sistema e eu te mostre dois ORMs diferentes para você se inspirar (ex. Django, SQLAlchemy). Tudo bem?
— Sim… entendo…
— No ORM do Django, se eu quero persistir um objeto no banco de dados, eu faço: modelo.save(). Mas no SQLAlchemy, se eu quero fazer o mesmo, eu faço algo parecido com storage.add(modelo). Ou seja, no Django o método que persiste o modelo no próprio modelo e no SQLAlchemy a responsabilidade de persistir o modelo é do objeto Storage. Qual desses modos você escolheria?

E aí o candidato teria algumas opções de resposta:

1. Não sei, preciso estudar mais as opções: boa resposta, mostra que entrei num assunto que ele desconhece, mas que ele tem interesse em se aprofundar.
2. Eu faria igual ao Django: resposta boa. Mas me leva à linha de contestar a escolha e perguntar se não seria responsabilidade demais para o objeto modelo cuidar das regras de negócio e da persistência dos dados no banco?
3. Eu faria igual ao SQLAlchemy: resposta boa também. Mas eu contestaria a escolha perguntando se a opção do Django não seria mais simples e conveniente para o uso mais comum onde precisamos somente gravar um objeto no banco sem ter que se preocupar com storages e afins?
   • Algumas vezes recebi boas respostas onde o candidato implementaria o ORM para funcionar no modo SQLAlchemy, mas implementaria um método helper .save() também nos modelos que faria algo do tipo: storage.add(self). Não posso negar que eu ficava bem feliz com essa resposta porque seria a minha resposta (mostrando que ela é a resposta certa 😛).
4. Eu faria diferente de ambos e faria [assim]: pode ser uma resposta boa aqui, mas, na prática, eu nunca recebi uma alternativa muito consistente nesses casos. Quase sempre foram respostas que mostravam o desconhecimento do candidato sobre o que é e como um ORM funciona.

Notem que a pergunta é só um ponto de partida para entender como o candidato pensa e faz as suas escolhas quando está programando. Quando ele faz uma escolha e, portanto, uma renúncia, eu apresento sempre um contraponto à escolha dele para compreender se ele fez essa escolha porque ele julga ela a escolha certa e a outra errada ou se ele, de fato, ponderou as diferenças, prós e contras das opções apresentadas para dar a resposta.

Profissionais que sempre estão refletindo sobre seu próprio trabalho estão sempre em crescimento. Aqueles que estão presos aos seus dogmas e tradições sempre estarão limitados por conceitos colocados por terceiros como sendo o certo.

Esse artigo é uma adaptação do meu vídeo no YouTube.

Com bastante frequência eu recebo pedidos de dicas de pessoas que pretendem começar a trabalhar em TI. Por conta disso eu reuni aqui várias dicas e recomendações para essas pessoas.

Tentei ser bem pragmático no plano. O objetivo dele é otimizar o caminho do zero ao primeiro emprego como iniciante. Eu falo só sobre o início do percurso e espero que consiga te preparar para decidir o restante do trajeto por conta própria.

Várias dicas que eu vou passar aqui foram acumuladas nos meus vários anos de experiência desenvolvendo software e participando de processos seletivos dos “dois lados do balcão”. É…! Já fui candidato para uma vaga várias vezes na vida e também já fui o contratante que escolhia os candidatos.

As dicas vão ser mais focadas na carreira de programador, mas algumas podem até servir para quem pretende trabalhar com outras áreas da tecnologia. Então se você pretende trabalhar com Data Science ou DevOps, tenta ver se tem alguma dica útil para você também.

Aprender programação não é Fácil. Mas é possível.

Bom galera, a primeira dica que vou dar é super importante e é pesada: não romantizem o trabalho de programador. Aprender a programar não! É! Fácil!

Balde de água fria, né? Foi mal aí… mas eu não poderia começar essas dicas sem mandar a real para vocês.

Diferente do que vocês vão ver nas propagandas de cursos e nos discursos de “coaches”, não é fácil aprender a programar. Você tem que estar preparado para investir muito tempo e dedicação nesse processo.

Mas por favor não me entendam mal! Eu não estou dizendo que você não consegue. Todo mundo consegue aprender a programar. Mas não tem como aprender a programar só lendo uns livros e fazendo uns cursos por aí. Cursos caros ou uma faculdade não te tornarão programador. Programar vai.

Só a prática deliberada da programação é que pode te tornar um programador.

Um livro ou um curso pode até te levar pelo começo da estrada e te ensinar como usar as ferramentas de programação, mas você vai ter que trilhar esse caminho por conta própria depois disso.

Como? Escrevendo muito código! Você precisa escrever muito código no processo porque esse é o único caminho que vai te ensinar a programar.

E vai ter vezes que vai ser frustrante. Outras vezes vai ser cansativo. Outras vezes vai ser desesperador. E algumas vezes vai dar medo. Mas mesmo assim você vai ter que seguir.

Mó papo de “coach” isso, né? Mas é a real.

E tem mais! Os primeiros códigos que você escrever vão ser uma tremenda porcaria… e tá tudo bem! É só jogar ele fora e tentar escrever outro melhor. Essa é a beleza do software, você tem matéria-prima infinita para trabalhar…

Seguindo por esse caminho, quanto mais tempo, foco e disciplina você tiver, mais rápido você se capacita para tentar uma vaga bacana.

Ah! E não importa o que aquele “guru de finanças e carreira” te disse: você não vai conseguir um emprego de programador sem se esforçar para isso. Provavelmente não vai ser rápido também. E provavelmente o salário não será no nível que eles prometem.

Não tem mágica e nem milagre. Se fosse fácil, não teria vaga sobrando, certo?

Tá, mas você deve estar perguntando: “Ok, mas quanto tempo vai levar para eu conseguir um trampo bacana?”.

Olha… não tenho uma resposta para essa pergunta. Depende muito de quanto tempo você dedicar todo dia para praticar e de um punhado de sorte.
Mas se você consegue se dedicar umas duas horas por dia, as coisas provavelmente vão caminhar mais rápido do que se você se dedicar duas horas por semana.

— Mas… dá para otimizar isso?
— Sim! Dá! Principalmente se você escolher bem os temas para focar seus estudos. Você não pode desperdiçar tempo com coisas que não serão úteis no início da sua carreira.

Ainda assim o processo todo pode levar um tempo considerável. E por isso eu gostaria de deixar a segunda dica: você não vai ganhar bem no começo!

Você não vai ganhar bem

— Orra! Você disse na abertura do vídeo que as vagas pagam bem e agora diz que a gente não ganha bem?
— Exato. No começo nem todo mundo ganha bem. Pode ser que você dê sorte, mas via de regra não é o que acontece com a maioria dos candidatos.

As vagas que pagam bem são aquelas para programadores mais experientes. E… óbvio… você não vai ter experiência no começo.

Pode acontecer que o salário de um iniciante seja maior que a sua renda atual. Nesse caso o seu salário inicial vai “parecer” alto, mas não necessariamente ele “será” alto.

Por conta dessa situação, eu daria a terceira dica: se você já tem um trabalho, continue nele.

Mantenha seu emprego

Se você já está trabalhando em algum lugar, mantenha esse emprego. Não assuma riscos altos sem motivo. Lembre o que eu disse: a vaga pode demorar para chegar.

Sei que é bem difícil ter ânimo para estudar programação depois de um dia cansativo de trabalho. Se esse for o seu caso, tente organizar seu dia para ter um tempo antes de começar o expediente. Uma horinha por dia já dá um adianto.

Se você aproveitar esse tempo, mesmo curto, para estudar computação da melhor maneira, as coisas vão funcionar.

E isso leva à quarta dica: Como estudar computação.

Estude

Como mencionei agora a pouco, se você acha que basta fazer alguns cursos para aprender a programar, você não poderia estar mais enganado.

Um curso de computação, geralmente, tem um conjunto de assuntos limitado e alguns exercícios prontos para você exercitar seus conhecimentos sobre o conteúdo apresentado.

No fim do curso você receberá um diploma dizendo que você consegue resolver os exercícios do curso. E eu te pergunto: isso te torna um programador desejável?

O trabalho de um programador é resolver problemas. Problemas com complexidades distintas, tamanhos diferentes, etc. O mundo real é muito mais complicado que o ambiente controlado de um curso de programação.

Aprender a programar exige que você procure por problemas que podem ser resolvidos com software e se arriscar a escrever seus próprios programas para solucionar eles.

Esses programas vão funcionar? É provável que, no início, não. Mas trabalhando em um programa ruim atrás de outro você vai entendendo o quê que funciona e o quê que não funciona.

Você aprende o que é bom e o que é ruim em contextos diferentes, aprende a encontrar bugs no seu software e resolver esses bugs, quebra a cabeça e se desespera até perceber que uma pausa e um pouco de descanso era tudo o que você precisava para terminar o projeto.

Ou seja, faça alguns cursos, mas, depois que você concluir alguns deles, tente se arriscar por conta própria e desenvolva seus próprios projetinhos.

Desenvolver esses projetinhos vai te ajudar agora e mais lá na frente quando algum recrutador pedir para você mostrar seu código para ele.

Se estiver sem ideia para projetos, é só olhar por perto e ver algumas coisas que você precisa no seu dia-a-dia… tipo um controle de despesas… ou no seu trabalho atual… tipo gerar um relatório no Excel.

Faça programinhas que te ajude em casa, na escola, no trabalho, no seu hobby, … qualquer coisa. E não se limite, planeje um sistema completo com todas as funcionalidades que você gostaria de ver. Mesmo que você não faça a mínima ideia de como desenvolver elas.

Você também pode procurar por listas com ideias de projetos na Internet:

• https://github.com/florinpop17/app-ideas
• https://samsquire.github.io/ideas/

Forme uma rede de suporte

Enquanto você está nesse processo de aprendizado é sempre legal ter a ajuda de alguém. E é aí que vai a quinta dica: converse com outros programadores.

Tente sempre participar de eventos e encontros sobre as tecnologias que você está estudando. Comece seu networking dentro das comunidades de tecnologia.

Você evolui como programador conversando com essas pessoas e já vai cavando as suas oportunidades de trabalho desenvolvendo uma rede de relacionamentos no mercado.

Uma grande dúvida das pessoas que estão começando é sobre qual linguagem escolher? Qual framework? Backend? Frontend? Data Science?

A minha sugestão é: forme sua rede de suporte primeiro. Comece com as mesmas ferramentas que eles usam. Nesse momento você deveria estar preocupado em aprender a programar e não com o mercado de trabalho ou onde tem mais oportunidades.

Se você não souber programar em nada, nenhuma oportunidade servirá para você.

Foco

E pensando em comunidade, programadores e networking, eu já gostaria de puxar a sexta dica que eu considero uma das mais importantes e é aqui que a gente começa a realmente otimizar o processo: foco em uma única coisa por vez.

Quando você for pesquisar vagas para trabalhar, você vai notar um mar de opções. Tem vaga para Data Science, Desenvolvedor Junior, Pleno, Sr, DevOps, Security, Tech Lead, Java, Python, PHP, Javascript, Go, etc, etc. Um buzilhão de tecnologias em uma sopa de siglas e termos técnicos que pode deixar qualquer um em pânico. Você se pergunta:

— Será que eu vou ter que aprender essa p* toda? Eu estou f*!

E pode piorar! Quando você olha tudo isso, você pode cair na tentação de guiar seus estudos pelo que o mercado está pedindo:

— Ah! Ouvi que Python é melhor! Ah! Tem muito mais vaga de front! Ah! O esquema agora é Data Science para Machine Learn…

Isso é um problemão! Lembre que você tem vários fatores limitando o seu desenvolvimento, mas só um deles não tem como mudar: o tempo.

Melhorar o uso do seu tempo é fator principal para encurtar o período de transição da sua carreira.

Otimizar o uso do tempo é o fator principal para encurtar o prazo até o novo emprego.

Você não pode se dar o direito de desperdiçar seu tempo com distrações. Você precisa ser um sniper, e não o Rambo atirando para todo lado com uma metralhadora.

Então escolha uma única profissão e uma única pilha de tecnologia e mexa só com ela. Escolha ser “Programador de uma única linguagem” e foque nisso.

— Mas e se eu não gostar de ser programador?
— Depois você muda. Primeiro você vira alguma coisa. Depois você muda.

Se você quiser ser cientista de dados, você inicia o processo de migração já em um emprego que paga bem e com conhecimentos de programação que serão muito úteis na sua carreira como cientista de dados. Saber programar é uma habilidade que ajuda em várias profissões em tecnologia.

Ah! E repito: não se distraia com ofertas de emprego com outras tecnologias. Elas vão aparecer aos montes e você vai achar que escolheu a tecnologia errada sempre que ver qualquer vaga de outra linguagem. Acredite: tem vagas sobrando para todas as tecnologias. Você vai encontrar uma.

Além disso, conforme você for ganhando experiência com os fundamentos da programação você vai ver que aprender novas tecnologias e linguagens vai ficando cada vez mais fácil e rápido.

É tudo CRUD¹

Já vimos uma dica para otimizar o tempo e a próxima dica, a sétima, é sobre otimização dos estudos: para se tornar um programador não é necessário dominar todo o campo da computação. Até porque isso é impossível.

Se você dominar bem o básico de alguns tópicos principais, já é possível desenrolar vários tipos de problemas de trabalho e, com isso, conseguir preencher uma vaga como programador.

Tem uma brincadeira entre programadores que diz que no fim das contas todos os programas são CRUD¹. É uma super simplificação, mas não é totalmente mentira… a maioria do software é isso mesmo e saber fazer CRUD você já pode trabalhar com TI.

Os tópicos que te preparam para construir softwares completos podem variar um pouco dependendo do tipo de vaga que você está procurando, mas se você aprender a:

• Programar em uma linguagem de programação como Python, JS, PHP, Go ou Java;
• Modelar software Orientado a Objetos (ou software funcional em uma linguagem funcional);
• Usar algum framework dessa linguagem;
• Modelar tabelas em bancos de dados relacionais e fazer queries SQL;
• Usar e criar APIs/Websites (ao menos) com protocolo HTTP/REST;
• Usar ferramentas de desenvolvimento como Editor de Texto ou IDEs, git, Docker e ter familiaridade com terminal Linux/Mac;

… você já está pronto para as batalhas e já consegue preencher bem a grande maioria das vagas para programador Junior do mercado.

Parece muita coisa, né? E é haha 🤷🏻‍♂️

Mas se você consegue lidar com esses tópicos, você já cobre a grande maioria dos conhecimentos necessários para desenrolar o trampo. Fazer CRUDs e tal…

E também não precisa ser “mestre” em todos esses tópicos. Sabendo preparar um arroz com feijão com cada um deles já tá de bom tamanho. No início! Para evoluir na carreira tem que dominar bem todos eles e mais alguns outros.

Outro conhecimento que é muito útil e importante, mas não tem relação com computação, é o inglês. Saber ler em inglês é a coisa que mais vai te ajudar a estudar isso aí tudo. Não é uma obrigação porque dá para “quebrar galho” com tradutores automatizados, mas, como o nome diz, isso é só um “quebra galho”.

No fim desse artigo eu coloquei algumas indicações de estudo e leitura. Infelizmente nem todas as indicações estão em português e boa parte delas é recomendação de leitura porque é o meu jeito favorito de estudar. Se você conhecer outros conteúdos em outros formatos, deixa aí nos comentários.

Muito bem, todas as dicas agora serviram para te ajudar a otimizar o processo de aprendizado, mas e a vaga? E o emprego?

Aplique para as vagas

Pois bem, a oitava dica é: aplique para as vagas. Só isso mesmo… brincadeira… Aplique para todas as vagas que você achar interessante. Mesmo para aquelas que você não atende aos requisitos. Se a vaga pede algum tipo de teste prático, é ainda mais legal.

Cuide só para não aplicar para vagas demais e acabar atrasando o desenvolvimento dos testes práticos. Sempre que eu estou aplicando para muitas vagas, eu gerencio o fluxo das atividades em um quadro no Trello para não me perder nas tarefas. No artigo Conseguindo um emprego em TI eu falo muito mais detalhadamente sobre esse assunto.

Se você estiver se sentindo confiante, também pode tentar pegar alguns servicinhos tipo freelance em sites dedicados à isso. Tem vários e como nunca usei nenhum deles não vou indicar nenhum específico. Busque no Google e procure referências com alguém que tenha trabalhado com esses sites.

Outra coisa para tomar cuidado é: tem umas poucas empresas ‘falcatruas’ que colocam trabalho de verdade como se fossem testes. Se o teste é fechado e os caras não são muito transparentes sobre o que farão com ele: desconfie.

É importante lembrar que, mesmo que você não passe no processo, você treinou e ainda pode receber um feedback da empresa com dicas para te ajudar na priorização dos estudos.

Ah! E você vai reprovar em muitos processos. Sei que é difícil, mas, não desanime. E, se der certo e você for contratado, já sabe, conta pra gente!

Se puder, faça (ou termine a) faculdade

A última dica é bônus porque, diferente das outras, essa pode não servir para todo mundo: se você está na faculdade, continue. Mesmo se ela não for de TI.

É muito comum, em TI, trabalhar com programação mesmo sem ter diploma. Por conta disso, tem muito “guru” recomendando que você abandone a faculdade para focar em estudar programação.

Se você não consegue se manter na faculdade por algum motivo, tudo bem. Mas se não for esse o caso, continue. As estatísticas mostram que pessoas formadas tem mais oportunidades e renda maior no mercado. Para quê abrir mão disso, não é?

Então essas são as dicas para você que quer mudar de área. Boa sorte na jornada e se precisar de ajuda manda nos comentários.

1. Sistema Operacional e Ferramentas (Linux/MacOS, editor de textos, git, terminal, shell e linha de comando, etc)
   1. https://osantana.me/tutorial-linux/
   2. Livro: Programação Shell Linux – https://amzn.to/3GJroMK
2. Linguagem (dê preferência em linguagens que você tenha amigos que programem. Se não tiver nenhuma vá de Python ou JS porque a quantidade de material gratuito é enorme)
   1. Livro: Introdução à Programação com Python: https://amzn.to/3NfMyEy
   2. Canal Youtube: https://www.youtube.com/c/dunossauro
   3. Livro: Fluent Python https://amzn.to/38LU5fu (intermediário/avançado)
3. Modelagem e programação Orientada a Objetos
   1. Livro: Object Oriented Python: https://amzn.to/3FbNlTT (Python)
   2. Livro: Building Skills OO Design Book: https://slott56.github.io/building-skills-oo-design-book/build/html/index.html (Python/gratuíto)
   3. Livro: Sams Teach Yourself Object Oriented Programming in 21 Days https://amzn.to/3MkaiX6 (Java)
   4. Livro: Head First Object-Oriented Analysis and Design https://amzn.to/3NQZikZ (Java)
   5. Livro: Fundamentos do Desenho OO com UML https://www.estantevirtual.com.br/livros/meilir-page-jones/fundamentos-do-desenho-orientado-a-objeto-com-uml/3383501357 (avançado/fora-de-impressão)
4. Web/HTTP/REST API:
   1. https://developer.mozilla.org/pt-BR/docs/Web/HTTP – Tutorial HTTP Web API da MDN (tem vários outros tutoriais bacanas sobre Web nesse site… dá uma passeada nele…)
   2. https://restfulapi.net – site que fala sobre APIs REST (HTTP). A parte que fala sobre hipermedia/HATEOAS você pode pular porque ninguém usa isso  
   3. https://github.com/Developer-Y/cs-video-courses#web-programming-and-internet-technologies – cursos completos sobre programação web
   4. https://www.slideshare.net/osantana/a-web-uma-api essa é uma apresentação que eu fiz online (infelizmente não tenho video dela). Ela é um pouco mais avançada mas acho que o comecinho dela pode ajudar.
   5. https://www.slideshare.net/osantana/contruindo-um-framework-web-de-brinquedo-s-com-python – essa é uma outra apresentação que fiz onde eu crio um framework web em Python. Essa é avançada mesmo. Deixe ela por último.
5. SQL e modelagem de Banco de Dados Relacional
   1. Livro: Introdução a Sistemas de Bancos de Dados https://amzn.to/3xcgU5t (livro muito completo e não fala de nenhum banco de dados específico)
   2. Livro: PostgreSQL Up & Running https://amzn.to/3ah8iRW (esse foi o que li para aprender mas tem outros livros que também parecem bons da editora Novatec e Casa do Código)
6. Programar, programar e programar mais
   1. https://github.com/practical-tutorials/project-based-learning#python – ideias de projeto para colocar em prática o que aprendeu
7. Continuar estudando pra sempre
   1. https://roadmap.sh – Esse site aqui tem vários roadmaps de carreira. Siga pelo de Backend e depois pelo de Python. Os roadmaps são assustadoramente grandes mas não se desespere porque não precisa ir atrás de tudo aquilo (nem eu sei tudo o que está neles). Siga as caixinhas com um “check” roxo e foque em 5 grandes tópicos. Foque só neles e não se distraia com outras linguagens ou tecnologias nesse momento.

[1] CRUD é uma sigla para Create (Criar), Read (Ler), Update (Atualizar), Delete (Remover) que são as operações básicas que fazemos em qualquer sistema de cadastro.

Imagem destacada: (c) 2013 http://www.exampapersplus.co.uk/

Esse artigo é uma adaptação do meu vídeo no YouTube.

Neste artigo, vou falar sobre como conseguir um emprego em uma empresa de tecnologia. Vou colocar aqui algumas dicas partindo da visão de quem já esteve dos dois lados do balcão: o lado de alguém que já procurou uma vaga e o lado de quem já contratou profissionais de desenvolvimento de software.

Também vou trazer alguns tópicos aqui para vocês terem atenção no momento em que vocês forem participar de um processo seletivo.

Primeiro de tudo é preciso dizer que mesmo eu, que já tenho uma experiência grande em TI, ainda falho em alguns processos seletivos.

Quando participa de um processo seletivo e não passa nele, a causa nem sempre é relacionada com a nossa capacidade técnica ou intelectual de trabalhar para aquela empresa.

Geralmente, isso acontece quando a gente não tem um alinhamento cultural, alinhamento de posicionamentos ou outras características. Então, não passar em um processo seletivo não significa que você falhou, significa que você tem pontos que você pode melhorar ou aperfeiçoar. Sempre que você reprovar em um processo seletivo, entenda isso como uma oportunidade de melhorar para a próxima tentativa e não como uma incapacidade.

Preparação

Uma coisa importante para participar de processos seletivos é estar sempre se preparando, estudando, vendo quais tecnologias as empresas estão usando e acompanhando o mercado de vagas, entre outros.

Quem está participando de processos seletivos também precisa manter sua presença na internet bem atualizada, ou seja, manter seu perfil no LinkedIn e no GitHub sempre bonito, organizado, com seus projetos mais importantes em destaque. Não se esqueça de deixar seus contatos disponíveis para os recrutadores conseguirem te encontrar mais fácil.

Mantenha sempre seu currículo atualizado, revise sempre, peça recomendações para seus colegas de trabalho, atualize seus cursos, treinamentos e as atividades que você tem feito ultimamente. Isso sempre será útil quando um recrutador bater o olho no seu perfil.

É legal manter sempre uma wishlist, uma lista de desejos, de empresas que você acha bacana. Empresas com um produto bacana, que usam tecnologias nas quais eu tenho interesse, que possuem uma cultura alinhada com seus valores, etc. Eu tenho uma lista dessas empresas que eu gostaria de trabalhar.

Crie essa lista de desejos, mas entenda o momento da sua carreira. Se você é um iniciante e a empresa contrata pessoas mais experientes, é importante estar ciente de que o momento certo para tentar uma vaga ainda não chegou. Mas não deixe isso te intimidar também. Às vezes, é legal correr um certo risco. Vou falar um pouco mais sobre isso mais adiante.

Processos Seletivos

Quando estamos precisando muito de um emprego, é interessante participar de vários processos de forma simultânea e, para isso acontecer de forma saudável, é preciso tomar alguns cuidados:

1. Priorize os processos de modo a conseguir dar a atenção necessária a todos eles;
2. Limite o número de processos simultâneos (o meu limite é 3, o seu pode ser maior ou menor). Processos com testes práticos podem pedir projetos que exijam um tempo grande;
3. Qualidade é mais importante que quantidade;
4. Organize os processos seletivos em um Kanban.

Faça um quadro no Kanban e crie um calendário dedicado. O Kanban pode ter as seguintes colunas:

• Contactar – empresas que você ainda precisa contactar para uma vaga.
• Entrevista Inicial – processos que já tem uma data/hora para a entrevista inicial.
• Teste técnico – processos que já tem um teste prático com prazo para realização e finalização.
• Entrevista Complementar – processos com outras entrevistas complementares.
• Aguardando Resposta – processos finalizados onde você espera por uma resposta da empresa.
• Aprovado – a vaga é sua!
• Reprovado – a vaga ainda não é sua. Peça feedback do contratante e anote o motivo da rejeição. Se a empresa possibilitar um novo processo futuro, é bom anotar a data aqui.

E se você está com uma dúvida entre duas ou mais empresas, tente manter a negociação com as duas empresas no mesmo pé, se você se sente confortável com isso. Lembre-se de que é legal informar para todos os recrutadores que você está participando de outros processos em paralelo.

Entrevista

Treine bastante para as entrevistas. As orientações são bem simples:

1. Jamais minta. Omitir é permitido. Mas recrutadores são ótimos em trazer omissões para superfície.
2. Tenha explicações claras e objetivas para eventuais “problemas” no seu curriculum:
   • Períodos de permanência muito curtos em empresas;
   • Intervalos vazios no curriculum;
3. Algumas empresas ainda fazem perguntas pessoais para os candidatos (principalmente no Brasil). Gostaria de dizer que você não precisa responder elas, mas eu estaria mentindo. Se você não quiser responder algo, tente preparar uma resposta bem limitada.
4. Passe a impressão de que você está no processo seletivo porque quer trabalhar na empresa. Falar mal de oportunidades anteriores sempre pode causar problemas.
5. Fale sempre de suas experiências sem emitir juízo de valor. No lugar de “o processo lá era muito ruim e por isso os prazos estouravam”, prefira usar “era muito difícil cumprir os prazos lá. O processo de priorização era muito simples e era centralizado na gestão”. Note que você não qualifica os problemas, mas traz os fatos. O recrutador vai saber interpretar esses fatos e ver os problemas.
6. Se pedirem a sua opinião sobre uma experiência anterior, é importante evitar julgamentos de valor ou qualificações rasteiras. No lugar de “eu acho que a gestão era uma porcaria e por isso as prioridades eram uma bagunça”, prefira usar “eu acho que era bem difícil entender bem as prioridades do time porque o gestor não colocava elas com clareza”.
7. Atraia a atenção do recrutador para os pontos positivos do seu curriculum. Se ele pergunta algo sobre um projeto problemático, é importante responder e tentar complementar a resposta com um contraponto de outro projeto onde o problema não existia. Exemplo: “Vi aqui que você trabalhou só em um projeto nessa empresa, você teve alguma outra experiência além dessa?” e você responde: “Sim, eu trabalhei só nesse projeto porque ele era importante para a empresa e eu conhecia ele muito bem. Então era muito difícil para eles me colocarem em outros projetos… entretanto, na empresa XPTO eu me envolvi em vários projetos que precisavam ser criados… “.

Entrevista Técnica ou Teste Prático

Do mesmo jeito que recomendo treino para entrevistas, é interessante investir um tempo treinando para as entrevistas técnicas ou para os testes práticos.

Treine algoritmos, estruturas de dados, linguagens, framework, POO, banco de dados, etc. Desenvolva projetos, brinque em sites de desafios técnicos, leia livros, e assim por diante. Programação é uma atividade de prática deliberada. Você não aprende a programar sem praticar.

Nas entrevistas técnicas valem as mesmas dicas da entrevista convencional que mencionei acima. Mas vale alguns complementos:

1. Alguns recrutadores fazem algumas perguntas que não possuem resposta correta ou possuem várias respostas satisfatórias. O objetivo dele não é a resposta e sim o desenvolvimento dessa resposta. Como você pensou para chegar a ela.
2. Pense em voz alta. O recrutador não lê a sua mente e o seu raciocínio oferece dicas valiosas para ele te avaliar bem (ou te dar um feedback mais completo em caso de rejeição).
3. Toda solução para um problema tem aspectos positivos e negativos. Ter consciência disso vai te ajudar bastante.

Aprovação e Feedback

Terminando as entrevistas e os testes a gente chega na fase final de aprovação e feedback. Nessa etapa é comum acertar os últimos detalhes sobre a vaga, empresa e candidato. Coisas como cargo, salário, carga horária, time, projetos, etc. entram na conversa.

Algumas empresas oferecem um momento para que o candidato faça perguntas. Prepare-se de antemão para essa oportunidade. Monte uma lista de perguntas que demonstre o seu interesse na empresa, no produto, no mercado, na vaga, no time, nos projetos, nos processos, nas finanças, etc. Pesquise sobre a empresa e as tecnologias usadas na Internet e anote umas perguntas.

Se a empresa não seguir adiante com o processo, é legal você solicitar um feedback técnico do recrutador. Peça, educadamente, indicações de material de estudo, quais pontos precisam ser melhorados, quando você poderá aplicar para uma vaga novamente, etc.

Por fim, é importante lembrar que, às vezes, o salário não é tudo. É legal pesar isso. Se você é uma pessoa que gosta muito de dinheiro, realmente buscando isso, vá atrás de empresas grandes. Mas se você está buscando uma empresa mais familiar, onde você vai ter um ambiente de trabalho mais legal, não vai ter tanto estresse, às vezes vale a pena pesar um pouco isso na balança.

Enfim, essas são algumas dicas que eu acredito que podem te ajudar na sua busca por um emprego em uma empresa de tecnologia. Espero que você tenha sucesso em sua jornada. Boa sorte!

Eu tenho dois filhos que fazem parte das gerações Z e Alpha. Essas últimas gerações tem algumas características em comum e uma delas é a de que eles querem tudo na hora, só clicando um botão. Eles não querem profundidade. Preferem respostas rápidas. On-demand. Just in Time.

Eu sou de outra geração (acho que é a Gen X) mas já tinha essa mesma ansiedade. Quando eu era criança falava que iria aprender tudo o que a humanidade sabia. Achava que todo o conhecimento da humanidade era o que estava dentro dos 10 volumes da Enciclopédia Trópico que a gente tinha em casa. Era bastante coisa para uma criança mas, ei!, eu tinha uma vida toda pela frente!

Aí a criança cresceu e o mundo foi crescendo junto. Os horizontes se expandiram. Começou a ficar claro que a humanidade sabe muito mais coisas do que aquilo que estava na Trópico. O entusiasmo de aprender tudo virou um: ih! fodeu!

Acabei deixando meu plano de saber tudo o que a humanidade sabe on hold (mais um na lista de projetos paralelos sem finalizar) e optei por desenvolver um MVP: aprender tudo sobre computação. Como já dá pra ver a primeira característica de um bom programador já estava presente: subestimar o tamanho dos problemas.

Trinta anos depois de ter estabelecido essa meta eu posso dizer com tranquilidade: tá foda! 🙂 Não desisti ainda, mas preciso dizer para todo mundo que está começando na computação que não é fácil e leva tempo.

Não conheço muito sobre outras áreas e profissões mas imagino que não seja muito diferente. Se embrenhar por uma carreira sempre vai exigir dedicação e tempo.

É claro que hoje eu consigo aprender uma nova linguagem de programação muito mais rápido do que acontecia 20 anos atrás. Também consigo entender o que uma ferramenta faz com poucos parágrafos de texto ou em uma boa conversa no boteco com amigos da área (saudades disso!).

Porque eu consigo entender e aprender algumas dessas ferramentas tão rápido? Porque depois desse tempo todo eu adquiri experiência.

Experiência é o produto de dois fatores: prática deliberada e tempo.

Sem a prática deliberada você não ganha experiência. Sem tempo você também não ganha experiência.

Oportunidades

Grandes Oportunidades requerem Grandes Experiências

Tio Benedito (eu acho)

Já faz algum tempo que o setor de Tecnologia da Informação anda muito aquecido. Tem um mundo vagas abertas para diversos tipos de posições e com o aumento de oportunidades de trabalho remoto esse mercado expandiu ainda mais.

Por conta dessa efervescência tem muitas pessoas chegando ou migrando para a área de TI. E eu acho isso ótimo! Pra falar a verdade eu acho até que “tá pouco, manda mais”!

Nesse processo tem chegado todo tipo de pessoas com todo tipo de experiências, expectativas, e necessidades. Para alguns é uma jornada para a vida. Para outros é só mais uma ‘corrida pelo ouro’. Pra ser honesto eu não ligo muito para as motivações dessas pessoas porque cada um sabe quando o boleto vence.

Mas no meio desse pessoal que está chegando tem um grupo que me preocupa um pouco mais: os jovens que anseiam por resultados rápidos.

Eles me preocupam porque, como meus filhos, eles anseiam por resultados e respostas rápidas para tudo. Inclusive para suas carreiras. E é mais provável que esses resultados não cheguem tão rápido para quem está só começando. Bons resultados surgem com boas oportunidades e a probabilidade de uma boa oportunidade surgir para uma pessoa com pouca experiência é muito baixa.

Então é preciso adquirir muita XP antes de encarar os chefões do jogo.

É fácil. Mas é Difícil.

Sempre que alguém me pergunta se é muito difícil aprender a programar eu respondo: é fácil mas é difícil. Obviamente, depois da brincadeira boba, eu explico melhor.

Para se tornar um programador é necessário dominar várias técnicas (ex. dividir um problema grande em problemas menores, experimentação, etc), algumas ferramentas (ex. computador, linguagem de programação, editor de texto, controle de versão, banco de dados, etc) e algumas práticas (ex. escrever testes, revisar código, etc).

Como você pode ver um programador não aprende só programação. Tem um portfólio completo de coisas que precisam ser estudadas em maior ou menor profundidade para se tornar um programador melhor e melhor.

Algumas dessas coisas vão ser fáceis de aprender e entender. Outras serão bem desafiadoras. E eu não consigo fazer uma lista classificando quais são fáceis e quais são difíceis porque isso varia muito de pessoa para pessoa. Eu sofri para aprender programação OO. Amigos meus ‘sacaram’ o paradigma lendo um livro.

Mas insisto em dizer que todo mundo consegue se tornar um programador mas não espere que seja só fazer um curso mágico e pimba! Sou um programador! Nem mesmo uma boa universidade sozinha vai fazer isso pra você.

Se você pode fazer uma boa universidade aproveite a oportunidade e faça. Vai te ajudar muito na sua jornada. Mas lembre-se de que a jornada é sua e é você que precisa praticar programação.

Aprender programação se parece muito com aprender uma arte marcial. Você não aprende Kung fu lendo um livro ou assistindo vídeo de aulas no Youtube. A menos que você seja o Neo no filme Matrix você só aprenderá Kung fu praticando.

Señor Developer

O que eu disse até aqui não tem relação com a discussão infrutífera sobre “Senior Developer” que vez ou outra explode em algumas redes sociais.

Essa classificação de senioridade é muito aberta e subjetiva. Ela varia de empresa para empresa e de programador para programador.

Eu tenho minha definição sobre o que é um programador Senior e ela inclui o atributo experiência (ter um bigode grosso é outra coisa que conta para senioridade… brincadeirinha 🙂). Mas para outras empresas ou até mesmo para outros amigos meus isso não é tão relevante. E tudo bem!

Algumas pessoas atribuem senioridade para programadores com experiências relevantes, outros definem que um profissional senior é capaz de ajudar outros colegas de trabalho. Como eu disse, isso varia muito e ficar discutindo o assunto é pura perda de tempo.

Não seja fiscal de senioridade. Se importar muito com isso é um sinal de que algo precisa melhorar em você.

Ceja Bem Vindos!

No mais eu gostaria de dizer à todos que estão chegando e deixar aberto minhas redes sociais para todos vocês que sentirem que precisam de alguma ajuda nesse processo.

… para pessoas programadoras

Como sou programador eu procuro sempre ter uma abordagem voltada para solução de problemas. Mesmo quando o problema que se apresenta não seja solucionável com software.

No momento que a empresa onde eu trabalhava precisou aumentar a equipe fiquei de frente com alguns problemas importantes: como encontrar e contratar profissionais com o perfil que a gente precisava? Qual o perfil de profissional que a gente precisava?

A empresa estava construindo os alicerces de uma plataforma de software. A pequena equipe que já trabalhava com a gente era muito qualificada e experiente. Também valorizavam a qualidade das práticas e processos de desenvolvimento para entregar sempre o melhor resultado.

Então a gente tinha que contratar programadores que prezam a qualidade das soluções desenvolvidas e fazer essas contratações em ritmo bom.

Perceberam que os dois requisitos podem soar contraditórios? Qualidade ou velocidade? Ambos!… Nessas situação a gente travou um limiar no aspecto qualidade e criou um processo que pudesse agilizar e uniformizar todas as contratações.

Processos & Práticas

Nesse artigo eu vou descrever o processo de seleção que construi, junto com minha equipe e o departamento de Recursos Humanos da empresa. Essa é a versão do processo que estava em uso até o momento que eu deixei a empresa. Não sei se eles ainda estão usando mas eu suspeito que não.

O processo não é perfeito e, como disse, prioriza um perfil de profissional bastante específico: profissionais apaixonados por programação que querem trabalhar em uma equipe que desenvolve software. São profissionais que priorizam muita qualidade e boas práticas.

Falei esse monte de coisas aqui em cima mas o que eu realmente queria fazer era criar o ambiente perfeito para o programador que existe em mim amaria trabalhar. ?

Esse processo não é muito eficaz para empresas que precisam crescer o seu time de desenvolvimento de forma muito rápida ou que estejam em um estágio onde o mais importante é criar soluções rápidas para os problemas que se apresentam. E vocês verão que ele é bem longo.

O processo todo é dividido em 8 fases. Cada prospecto/candidato tinha um card no JIRA que tinha algumas customizações que exigia o preenchimento de certas informações fossem feitas antes de se avançar para a próxima fase. Cada fase do processo era representado por uma coluna no JIRA.

Aviso para candidatos

Algumas informações desse artigo podem ser muito valiosas para vocês também. Entender como um desse processos funciona te permite fazer engenharia reversa e hackear o sistema. Espero que vocês façam bom uso desse material.

Etapas do processo

Etapa 0: Captação

Antigamente as empresas descreviam as vagas com seus requisitos, colocavam em alguns forums e sites de emprego e ficavam esperando a enxurada de candidatos. Aí era só jogar todos esse candidatos nos diversos filtros, avaliar eles e escolher o mais adequado entre todos os finalistas. Essa abordagem passiva para contratar programadores não funciona mais tão bem.

Hoje é muito difícil contratar bons programadores. Contratar bons programadores com experiência está se tornando quase impossível. Não sei se isso vai ser assim pra sempre mas já é uma realidade faz vários anos.

Por conta disso a abordagem passiva para buscar candidatos precisa ser modificada e as empresas, agora, precisam ser pró-ativos na captação de bons prospectos/candidatos (leads). Uma vez que você encontra esses candidatos devemos iniciar o processo de “venda” da vaga para ele.

Na empresa onde eu trabalhava a gente tinha diversas técnicas de captação. Eu vivia me embrenhando em redes sociais e grupos de desenvolvimento de software em busca de projetos bacanas e sempre que esbarrava em um programador interessante eu criava um card no JIRA com as referências desse prospecto.

A empresa também incentivava (e financiava) os programadores da nossa equipe a participar de eventos de tecnologia e levar a palav… digo… apresentar as oportunidades que trabalho que a gente tinha aberto. A gente também tinha um orçamento para patrocinar esses eventos e poder ter uma presença mais marcante nessas ocasiões.

A equipe de RH também ajudava muito na captação buscando leads em plataformas como Linkedin, Stackoverflow, etc.

Eu fiz um breve “treinamento” (uma reunião rápida pra passar umas dicas) com a equipe de recrutadores explicando como abordar esse leads sem soar muito intrusivos. Ensinando a não ter nenhuma abordagem massiva (spam, mail marketing, etc) e sempre abordar cada lead depois de ter lido perfil e se informado sobre o possível candidato. Também expliquei como se comportar em comunidades de FLOSS e nunca postar uma vaga sem antes se apresentar e perguntar quais são as regras daquele grupo para anunciar vagas abertas.

As descrições das vagas precisam “vender o produto”. Então elas precisam ser muito completas e contar até mesmo detalhes das tecnologias, processos, benefícios, etc. Apesar disso, nessa empresa, a gente não anunciava a faixa salarial e sempre dávamos respostas vagas como ‘acima da média de mercado praticadas no Glassdoor’. Não consegui convencer todo mundo sobre a importância de divulgar a faixa salarial. Mas esse assunto é complicado o suficiente e provavelmente merece um artigo só sobre ele.

O processo todo deveria ter como alicerce o respeito total com os candidatos. Respeito com a pessoa, com o tempo da pessoa, e com a dedicação dela ao processo.

Etapa 1: Entrevista Inicial

Com o contato do prospecto e o estudo prévio dele já podemos entrar em contato e marcar a entrevista preliminar caso ele tenha interesse em nos atender.

O dia e horário que você marcar essa entrevista já vai dizer um pouco sobre o ritmo de trabalho da empresa. Então fique esperto com entrevistas em horários bizarros como fins-de-semana ou tarde da noite. A menos que o candidato peça um horário diferente tente falar com ele em horário comercial.

Se ele topou envie o convite por e-mail e marque em sua agenda e JAMAIS se atrase para essa entrevista. É crucial que você respeite o candidato desde o primeiro contato. Lembre que é a sua empresa que precisa dele.

Essa parte do processo é a que vou detalhar menos porque ela era conduzida majoritariamente pelas psicólogas do RH da empresa que, por questões de ética profissional, não podiam detalhar o que faziam. Recomendo muito usar profissionais de psicologia no processo de recrutamento das empresas. A quantidade de informações úteis que eles conseguem trazer para o processo é incrível.

Na entrevista inicial uma das psicólogas iniciava o contato online com o candidato, fazia algumas perguntas para ver se o candidato se encaixava no perfil de profissional que a empresa dava preferência e começava algumas anotações sobre pontos de atenção para serem explorados nas próximas etapas.

Um exemplo: a empresa tem trabalho remoto e o candidato diz que nunca trabalhou remoto antes. Isso obviamente não desclassifica o candidato mas prepara os avaliadores das próximas etapas para ver se o candidato consegue se desenrolar bem nessa modalidade de trabalho.

Aliás, essa etapa dificilmente ‘desclassificava’ alguém. Ela era muito mais útil para fornecer subsídios para os avaliadores. Em alguns raros casos a recrutadora era desrespeitada durante essa entrevista e, nestes casos, obviamente, o candidato caia por ali mesmo.

Uma vez que a psicóloga estava confortável pra enviar o candidato para a próxima fase ela já apresentava o teste técnico (próxima fase), explicava como proceder com o teste e já deixava um contato para eventuais dúvidas. O teste não tinha prazo máximo pra ser feito mas a psicóloga contactava o candidato regularmente (semanalmente) pra perguntar se estava tudo ok com o teste. Algumas vezes os candidatos abortavam o processo e não avisavam nada pra gente e essas ligações serviam pra gente mover o card desse candidato pra coluna de finalização.

Uma observação importante: a recrutadora também era a coordenadora do processo de cada candidato. Ela que “batia o bumbo” para que os processos andassem e os prazos fossem cumpridos. Ela também centralizava a comunicação com o candidato para garantir que ela estava dentro dos padrões.

Etapa 2: Teste Técnico (Candidato)

Eu não gosto de testes de quadro branco e acho esses testes de sites como HackerHank bastante limitados. Por mais que seja bem difícil e trabalhoso especificar um teste técnico que consiga abranger a avaliação de todas as habilidades importantes em um candidato eu acho que vale o investimento.

O teste técnico é peça muito importante de todo o processo. Não só porque ele vai avaliar se o candidato tem o mínimo de conhecimento para trabalhar nos projetos que a empresa precisa. O teste técnico serve como subsídio para algumas etapas posteriores.

O teste técnico que criamos possuíam as seguintes características:

1. Venda seu peixe. O documento com o teste é uma boa oportunidade para mostrar como vai ser legal trabalhar junto com você na empresa.
2. Projeto completo. O teste tem que pedir um projeto completo. Do desenvolvimento até o deployment em produção. Indique sites que possibilitem o deploy gratuito desse teste para o candidato (ex. Heroku).
3. Definição de escopo e requisitos objetiva. O teste tem que ser enviado para o candidato com um único documento contendo todo o escopo do projeto. Se você espera que o candidato saiba inglês, por exemplo, envie esse documento em inglês. O documento deve especificar apenas o Quê precisa ser feito. Nunca diga como fazer à menos que isso faça parte das práticas que o candidato precise dominar mas que seja muito difícil ou demorado para ensinar. Exemplos de coisas que você pode pedir:
   1. Código com strings e identificadores em inglês;
   2. Usar alguma linguagem que a empresa use (para que possa ser avaliado);
   3. Testes automatizados;
   4. Documentação (no idioma que você quer avaliar no candidato);
   5. Armazenado em controle de versão;
   6. Seguir um coding style específico;
   7. Praticar conceitos de 12 Factor-App;
   8. API em um estilo específico (ex. REST, GraphQL, gRPC, etc)
4. Simples e factível em 1 dia. Bons profissionais, geralmente, já estão trabalhando. É importante entender que eles não tem tempo para investir em um teste longo e trabalhoso.
5. Não-relacionado à atividade da empresa. Não faz muito tempo algumas empresas usavam testes técnicos para obter desenvolvimento gratuito de candidatos. Por conta disso programadores são bastante desconfiados de testes que pedem o desenvolvimento de algo que a empresa possa usar sem pagar.
6. Código aberto por padrão. Exceto em casos onde o candidato pede explicitamente para manter o teste dele fechado deixe ele como opensource. Isso diminui as dúvidas sobre o uso do código sem pagamento. Algumas pessoas me perguntavam se isso não pode ser usado por outros candidatos para copiar testes. Sim. E tudo bem, afinal, todo desenvolvedor sempre acaba copiando um código aqui e ali. Nas etapas seguintes é possível levantar o que foi copiado e a motivação para isso. Se foi plágio completo você consegue detectar fácil.
7. Exercitar vários aspectos do trabalho. O teste pode ter uma regra de negócio elaborada, implementar uma API REST, armazenar os dados em um DB, ter modelos diferentes interagindo, etc. Problemas pontuais com coisas como carrinho de compras, gestão de assinaturas e pagamentos, gestão de conteúdo, logística e entregas, etc são ótimas fontes de ‘problemas de negócio’ que podem ser explorados para criar um teste. Lembre apenas de limitar bem o escopo para que seja possível criar algo em um dia.
8. Validade limitada. O teste tem que ter uma validade limitada. A validade serve para que você reabilite candidatos que eventualmente não foram selecionados em um processo anterior a participar novamente. Ele fez o teste-1 e não foi adiante 6 meses atrás mas ele estudou os pontos que você indicou e quer aplicar para uma vaga novamente. Se o teste mudou ele pode reaplicar.
9. Produzir contexto extra-código. O teste precisa permitir que o programador trabalhe nele como ele trabalharia na sua empresa porque não devemos avaliar apenas o código produzido. Precisamos ver a documentação do projeto, a linha do tempo dos commits e as mensagens de commit, abordagens alternativas para solução do problema, etc.
10. Sem prazo para entrega. É importante deixar claro para o candidato que o objetivo dele é fazer o melhor teste que ele puder e não o tempo que ele leva para fazer isso. O tempo para realizar o teste precisa ser descartado completamente da avaliação porque cada candidato tem uma situação completamente diferente de outro candidato. Tem candidato que tem emprego e outro que não tem. Tem candidato que tem atividades paralelas e outros que não tem. Tem candidato que está estudando um tópico novo para fazer o teste e outros que já sabem tal tópico. É importantíssimo reforçar isso para o candidato sempre que entrarmos em contato com ele para que esse contato não se pareça com alguma forma de pressão por entrega. Diga que ele será avaliado pelo que ele entregar e não pelo tempo que ele levou pra entregar.

Abaixo você consegue ver um exemplo de teste técnico:

Assim que o candidato concluir o teste e enviar o material pra você a próxima etapa começa. Chegou a hora de avaliar o teste.

Etapa 3: Avaliação Técnica

A avaliação do teste precisa ser feita por um programador da equipe ou gestor que tenha trabalhado como programador da equipe. Ele vai pegar o código do candidato e uma ficha de avaliação com perguntas claras e objetivas sobre tudo o que a empresa espera do candidato e preencher essa avaliação.

Mais do que a avaliação em si, nesse momento é bem importante que apareçam dúvidas na cabeça do avaliador. Essas dúvidas precisam ser anotadas juntamente com os resultados da avaliação porque elas serão extremamente úteis na próxima etapa do processo seletivo.

Na empresa onde implementamos esse processo a gente criou uma planilha com um questionário com perguntas bem objetivas agrupadas em tópicos. Cada pergunta dessa gerava uma nota entre 0 (min) e 3 (max). Cada nota dessas tinha um peso variando entre 1 e 3 que posteriormente era usada em uma média ponderada.

No final a gente gerava um gráfico do tipo radar com um eixo em cada tópico (ex. Documentação, Modelagem de Banco, Commits, etc) e uma lista de notas e observações do avaliador.

Você pode baixar um modelo dessa avaliação aqui:

Quando o volume era menor a gente colocava dois programadores para avaliar o mesmo teste e depois fazia uma ‘acareação’ mediada entre os avaliadores para evitar problemas de interpretação. Mas em um determinado momento o volume de testes para revisar ficou grande demais e só um programador fazia a avaliação de cada teste.

Fizemos essa mudança porque raramente encontrávamos divergências muito grande e em todas as vezes o motivo da divergência era a falta de objetividade na pergunta do questionário que era prontamente corrigido.

Essa avaliação não pode demorar muito pra ser feita e, se isso acontecer por algum motivo, é importante manter o candidato informado.

Em alguns casos o candidato vai muito mal e recebe avaliações muito ruins e seguir com o processo provavelmente seria um desperdício de tempo para todos.

Nesses casos é muito importante devolver uma resposta para o candidato e, se possível, indicar os pontos de estudo e melhoria para ele. Eu tinha uma lista de links para artigos ou livros para indicar que ajudariam o candidato a cobrir todos os pontos onde ele precisava melhorar.

Esse feedback precisa ser mais abrangente do que específico:

From: [email protected]
 
Olá [candidato],

Após a avaliação do seu teste técnico [url do
teste] nós optamos por não seguir adiante com
seu processo seletivo nesse momento.

Agradecemos o seu tempo e dedicação até aqui e
gostaríamos de vê-lo novamente no futuro quando
lançarmos um novo teste técnico para a vaga.

Para isso gostaríamos de sugerir a leitura dos
seguintes materiais:

* [link para um artigo sobre apis rest]
* [link para um livro sobre modelagem OO]
* [link para livro sobre TDD]
* [link para um bom curso de Python no youtube]

Se você tiver qualquer dúvida ou tiver
interesse em nos dar um feedback sobre
o processo até aqui é só entrar em contato.

Obrigado,
Equipe Empresa Co.

Esse e-mail não é o lugar para escrever coisas como ‘você não foi aprovado porque a sua modelagem de banco estava toda errada’. Prefira indicar um bom livro sobre modelagem relacional. Dê preferência para conteúdo gratuito. Lembrem-se que o candidato pode estar numa situação financeira complicada.

Na empresa onde eu trabalhei eu pedi verba para comprar ebooks e enviar para candidatos que não eram aprovados. Mas a verba não foi aprovada.

Etapa 4: Entrevista Técnica

Assim que a avaliação do teste técnico ficava pronta um gestor de tecnologia poderia prosseguir com o agendamento da entrevista técnica com o candidato. Ele fazia isso sempre buscando o melhor horário para o candidato. A entrevista também precisava ter uma duração fixa pré-determinada. Deve-se evitar dividir essa entrevista em etapas distintas. Ter ela em uma única sessão garante que você vai avaliar o candidato em sua plenitude de humores.

Conduzir uma boa entrevista exige mais técnica do que experiência. Pode ser que eu escreva só sobre isso em um artigo futuro então vou só pontuar algumas coisas que a gente fazia lá.

Antes de ir para a entrevista técnica o gestor já se preparava usando as informações das avaliações feitas pela recrutadora na entrevista inicial, as anotações da avaliação técnica e dando uma conferida no Linkedin ou no Github do candidato. Eu evitava redes sociais não profissionais (Twitter, Instagram, Facebook, etc) porque nas poucas vezes que olhei essas redes acabei sentindo que a entrevista ficou enviesada de forma negativa.

Os gestores que faziam essas entrevistas já tinham alguma experiência com processos de recrutamento mas, mesmo assim, a gente ainda sugeria certos procedimentos para tentar padronizar a experiência. A gente sugeria que o entrevistador criasse um plano para a entrevista com algumas perguntas-guia para fazer para o candidato. Meus planos geralmente tinham umas 3 perguntas padrão que giravam em torno de relacionamento com equipe, processos e experiências anteriores, e umas 2 ou 3 perguntas que variavam em função do resultado das avaliações. Nem sempre eu usava essas perguntas mas sabia que elas estavam lá caso a entrevista ficasse meio truncada.

Condução da entrevista

Essa etapa não era muito padronizada então vou descrever como eu conduzia as minhas entrevistas. Como eu já disse eu iniciava a entrevista com um plano construído sobre as avaliações anteriores e uma breve olhada nas redes sociais profissionais do candidato.

Sabendo que essa entrevista costuma ser a que deixa os candidatos mais nervosos e que muitos candidatos, mesmo aqueles com muita experiência, podem ‘travar’ nesse momento eu dedicava um bocado de tempo no começo só para deixar o ambiente mais leve e as coisas mais calmas. Você precisa que o candidato esteja tranquilo para conseguir uma boa entrevista.

A entrevista técnica sempre começava com algumas perguntas básicas e despretensiosas sobre o candidato. Começar a conversa perguntando sobre algum hobby ou coisas positivas que surgiram na entrevista inicial tira o peso da entrevista e diminuíam o nervosismo do candidato.

Um exemplo do que eu fazia era só perguntar coisas que o candidato sabe como responder com 100% de certeza. Perguntas como: “Qual seu nome?” ou “Qual sua idade?” estão nessa categoria. “Quais linguagens de programação você gosta?” não está nessa categoria porque o candidato vai começar a pensar sobre qual é a resposta que o entrevistador quer ouvir.

Eu tomava muito cuidado com perguntas sobre a intimidade do candidato (ex. “Você é tem namorada(o)?”). Até pra perguntar se o candidato era casado(a) ou tinha filhos eu evitava. Se eu não estivesse 100% certo de que essas perguntas eram seguras eu não fazia. Por isso o planejamento prévio é essencial.

Uma dica que sempre dou para quem está começando a fazer entrevistas é: você não precisa ser algo que você não é. Se você não é engraçado não precisa ser engraçado. Só tente ter empatia pelo candidato para poder ajudar ele.

Quando você sentir que o candidato está mais calmo você pode serguir com o seu plano para a entrevista. Chegou a hora de falar pouco e ouvir muito.

Aqui eu partia para as perguntas técnicas. É muito comum que programadores estejam mais confortáveis com a parte de hard skills então a transição para essas perguntas acontecia de modo mais natural.

Eu usava o teste do candidato para formular questões bem objetivas. Perguntas do tipo: “Aqui nesse ponto do seu código você fez isso. Porque você fez assim e não assado?” (ex. “Vi aqui nessa parte do seu teste que você modelou esse relacionamento em 1-para-N… mas e se essa entidade estiver em M contextos, não seria melhor um N-para-M?”).

Eu prestava atenção no que estava sendo dito (ex. “eu optei por modelar 1-para-N porque na descrição do problema não existia o requisito que pediria uma modelagem N-para-M”), mas também observe o que não está sendo dito. No exemplo anterior dá pra inferir que o candidato segue bem as especificações mas pode não ser muito pró-ativo em questionar essas especificações. Eu encadeava mais perguntas pra dirimir essa dúvida e não ficar só com a minha “inferência”.

Também gostava de fazer perguntas que podiam ser respondidas corretamente de vários modos diferentes e emendar uma segunda pergunta contrapondo a resposta. Exemplo: “Se você tivesse desenvolvendo um ORM como você faria pra persistir um objeto no banco de dados? Faria obj.save() ou storage.save(obj)?” e a próxima pergunta seria: “Mas [a outra abordagem] não teria a vantagem de [vantagem da outra abordagem]?”. Esse tipo de pergunta permite ver o candidato reagindo à uma situação de argumentação e defesa de seus pontos de vista. Alguns candidatos até explicaram a teoria e as referências para as duas abordagens (Active Records vs. Data Mappers). Esse foi contratado, né? ?

Uma vez que as questões técnicas foram esclarecidas eu partia para as “perguntas difíceis”. Aqui eu queria entender mais sobre os soft skills do candidato. Nesse momento o candidato estava mais amaciado com as coisas que ele (teoricamente) sabia e conseguiria responder com a guarda mais baixa.

Eu voltava então a fazer perguntas relacionadas ao comportamento e relacionamento do candidato com as equipes que ele teve.

Queria saber como era a relação dele com gestores, o que ele gostava no trabalho, o que ele detestava, o que ele gostaria de mudar, o que ele conseguiu mudar, o que ele não conseguiu mudar, porque ele não conseguiu mudar, etc.

Eu sempre tomava notas durante a entrevista. Precisava fazer isso para alimentar o nosso relatório sobre o candidato.

Finalmente chegamos ao fim da entrevista. Você agradece o candidato e avisa que ele receberá um retorno num prazo específico. Cumpra esse prazo.

Retorno

O retorno para o candidato podia ser de 2 tipos:

1. Paramos: agradecíamos o candidato pelo tempo investido no processo, informávamos que ele pode voltar a tentar a vaga no futuro, indicávamos caminhos que ele poderia tomar para ser melhor sucedido na próxima oportunidade, e deixávamos um canal sempre aberto para comunicação com ele. Esse retorno era por e-mail mas eventualmente o RH entrava em contato direto com o candidato.
2. Continuamos: parabenizávamos o candidato e informávamos que a próxima etapa seria uma dinâmica de Pair Programming remoto com um dos nossos desenvolvedores. Pedíamos um espaço na agenda do candidato para essa atividade.

Etapa 5: Dinâmica de Pair Programming Remoto

A equipe de tecnologia da empresa onde implementamos esse processo sempre trabalhou remotamente. Trabalhar remoto é uma atividade que pede certos soft skills importantes (ex. auto-gestão, auto-organização, etc) e o nosso processo precisava avaliar se o candidato tinha essas características, se era necessário desenvolvê-las, ou se a empresa seria incapaz de desenvolver essas qualidades no profissional caso ele fosse contratado.

Quebramos a cabeça pra descobrir um modo de fazer essa avaliação e, certo dia, participando de um Coding Dojo com alguns amigos eu tive a ideia de tentar algo parecido para avaliar a dinâmica de trabalho remoto do candidato. Deu super certo e se tornou a etapa que me deixava mais entusiasmado com os resultados.

Montamos um servidor remoto (usando AWS Cloud9) com a linguagem Python, framework de teste, editor de textos e conectávamos um desenvolvedor da nossa equipe e o candidato para fazer pair programming. Além dos dois programadores um gestor (geralmente o mesmo que fez a entrevista técnica) ficava na audiência coordenando a atividade e observando a dinâmica.

O gestor então apresentava o problema que seria abordado na dinâmica. Eram problemas de Coding Dojo já conhecidos (ex. mostrar números decimais com algarismos romanos). Nenhum dos programadores pode saber qual vai ser o problema de antemão. Tem que ser uma surpresa para ambos.

É muito importante deixar claro para ambos que o objetivo da dinâmica é ver a dupla trabalhando e não a resolução do problema. Deixe claro para o candidato que se não der tempo de resolver o problema está tudo bem.

Uma vez apresentado o problema os programadores começavam a trabalhar nele usando TDD e baby steps. Em intervalos de 5 minutos (cronometrados) os programadores são obrigados a trocar de posições como piloto e co-piloto do teclado.

Assim que o timebox foi atingido o programador pode deixar a sala e o gestor pode conversar com o candidato sobre a dinâmica.

A gente usava essa oportunidade para perguntar sobre situações que aconteceram durante a sessão de pair programming. Fazíamos muitas perguntas sobre comportamento (ex. “naquele momento o [nome-do-dev] propôs algo que você não concordou/entendeu e mesmo assim você seguiu com a proposta dele, porque você não parou pra questionar ele sobre a decisão?”).

Também é possível ver se o candidato consegue expressar bem suas ideias e propostas.

Essa etapa tem que ter duração fixa e não precisa ser longa. Na empresa a duração dessa etapa começou com uma hora de duração e foi diminuindo até durar 40min.

Algumas vezes a gente colhia as impressões do programador da nossa equipe que fez pareou com o candidato para complementar nossa avaliação.

Era muito raro um candidato cair nessa etapa. Se o candidato foi muito mal e a gente entendesse que não daria para prosseguir a gente falava que ele receberia o feedback em alguns dias e procedia com o e-mail de agradecimento e etc.

Se o candidato tivesse ido bem nessa etapa ele já recebia uma lista de dias e horários para a entrevista final com o CEO. Era a única ocasião onde o candidato não tinha o controle total sobre a agenda do processo. Infelizmente a agenda do CEO era uma selva e tinha muito poucos buracos para ocupar com as entrevistas com candidatos. Mas ele fazia questão de entrevistar todo mundo de todos os setores da empresa.

Etapa 6: Entrevista Final

A entrevista final com o CEO era a etapa de consolidação & arremate do processo. Ela existia para determinar se o candidato tinha fit com a cultura da empresa mas também era usada para dirimir alguns questionamentos que ainda estavam aberto sobre o candidato.

Para isso o CEO recebia um “dossiê” com tudo o que foi levantado sobre o candidato nas etapas anteriores bem como alguns pontos de atenção que a gente detectou nas etapas anteriores. A gente chamava esses pontos de atenção de red flags (bandeiras vermelhas).

Uma das coisas que essa entrevista tentava avaliar era o nível de comprometimento com a empresa que a gente podia esperar do candidato. Para a empresa era importante que o candidato fosse trabalhar lá com um certo nível de comprometimento e não chegar lá como um trampolim para outra vaga que pagasse mais. Afinal o time dessa empresa era muito reconhecido no mercado e passar por ele “valorizava o passe” de qualquer profissional.

Nessa etapa todos os candidatos já chegavam travados pelo nervosismo. Afinal, era o CEO da empresa… Então o CEO com a maior calma e paciência ia acalmando o candidato antes de partir para as perguntas.

Durante a entrevista o CEO contrapunha as resposta do candidato com anotações do relatório que ele tinha recebido para tentar encontrar, explorar e esclarecer divergências.

Assim que a entrevista terminava o candidato era avisado de que ele receberia o resultado final do processo em alguns dias. Geralmente era no dia seguinte mesmo. Assim que o CEO terminava a entrevista com o candidato era bem comum ele já reunir o comitê que iria decidir sobre a contratação.

Decisão Final

Essa etapa era rápida e a decisão era colegiada. Um candidato só era contratado se houvesse unanimidade desse colegiado que era formado por todos os gestores e recrutadores que participaram do processo daquele candidato.

A decisão era rápida porque todos já tinham tido acesso ao relatório final com todas as informações levantadas ao longo de todo o processo. Bastava avaliar as forças e fraquezas de cada candidato, traçar um plano para potencializar as forças e lidar com os pontos de atenção do candidato e decidir sobre a contratação.

Feedback

A etapa de feedback tem duas versões. O feedback para o candidato que foi contratado e o feedback para o candidato que não vai seguir para contratação naquele momento.

Para os candidatos que não seguiriam a gente enviava um e-mail bastante completo para informar que a gente não seguiria adiante com a contratação, agradecíamos a dedicação do candidato, indicávamos alguns caminhos para futuras tentativas e deixávamos uma linha de comunicação aberta para esse candidato.

Na linha do respeito ao candidato, algumas vezes, a gente entrava em contato direto com o candidato. Geralmente quando eram candidatos muito jovens que, eventualmente, não conseguiriam lidar muito bem com a não-contratação. As psicólogas avaliavam se isso era necessário ou não e por isso disse que ter esse tipo de profissional envolvido no processo é super importante.

Para os candidatos que foram aprovados a gente mandava um e-mail de congratulações com as primeiras instruções do nosso processo de on boarding que, modéstia à parte, também ficou lindão (e provavelmente vou descrever aqui).

É possível que o candidato recuse a oferta nessa etapa. Esteja preparado para isso e peça, educadamente, que, se possível, o candidato explique o motivo da recusa para ver se é possível melhorar algo no processo. Lembrem que o feedback é uma via de mão dupla e o candidato é o protagonista.

A gente também colhia feedback dos candidatos contratados durante o on boarding. A gente tinha um formulário (Google Forms) interno onde o novo funcionário preenchia suas impressões, apontava problemas e sugeria melhorias. As recrutadoras do RH colhiam essas informações e traziam os feedbacks de forma anônima para nossas reuniões de processos.

Hoje eu estava lendo o artigo Stepping Back from Speaking do Martin Fowler e me identifiquei com muitas coisas que ele disse. Na verdade parece um artigo que eu teria escrito para falar sobre o assunto. Exceto pelo fato dele ser “O” Martin Fowler e eu ser só o Osvaldo, eu passo (ou passava) por tudo o que ele diz ter passado para dar palestras em eventos de tecnologia.

Quando eu era mais novo costumava ser bastante introvertido. Isso mudou quando uma professora de educação artística notou que meu talento para trabalhos manuais era bem limitado e decidiu organizar grupos de teatro na minha turma. Fiz ou ajudei a fazer do roteiro à cenografia e até atuei no palco. Ali eu pude perceber que conseguiria me apresentar para uma audiência.

O tempo passou e a vida aconteceu… veio o trabalho como programador e pude voltar a ser o cara que fica ali no canto, de cabeça baixa, codando.

Mas aí surgiu o meu envolvimento com as comunidades de FLOSS e, principalmente, com a comunidade Python. Nessas comunidades eu achava super importante compartilhar as coisas que eu aprendia. E a forma de fazer isso quase sempre envolvia falar para uma grande audiência (qualquer coisa maior que uma mesa de bar já conta como ‘grande audiência’ pra mim).

E aí acontece aquilo: as primeiras apresentações são péssimas, vão melhorando para ficarem muito ruins e um dia, quando menos se espera, eu estava mandando bem.

Uma das coisas que a gente aprende fazendo palestras é que é muito importante respeitar a audiência. Respeitar a audiência é garantir que você fez o seu melhor para trazer algo relevante para eles. Fazer isso com muito carinho e muita qualidade. Tem gente ali que investiu tempo e dinheiro que vão faltar mais na frente na esperança de ter um retorno por esse investimento. Eu me sinto obrigado a fazer valer esse investimento.

Em eventos de tecnologia é bastante comum ver os palestrantes montando suas apresentações em slides poucas horas antes de apresentar. Tem gente que tem esse talento mas eu não tenho. Sempre cheguei com minhas apresentações preparadas e ‘testadas’ (algumas vezes testava em encontros locais ou eventos menores). O dia antes da apresentação era só pra atualizar uma ou outra informação que eventualmente tinha surgido desde a última revisão.

Causo: durante a PythonBrasil de São Paulo alguns ladrões de notebooks entraram no evento e roubaram meu notebook (e mais um outro da minha amiga Karyn). Minha apresentação estava nele e infelizmente, por negligência minha, não estava sincronizado na nuvem. Eu pedi para retirarem a minha apresentação do evento porque eu não conseguiria fazer ela mesmo conhecendo bem o conteúdo dos slides. Eu entrei em pânico com a ideia de não entregar uma boa apresentação.

No dia em que tenho que fazer a minha apresentação, tal como acontece com o Martin Fowler, eu entro em um estado tão estressante e fico tão ansioso que fica parecendo que estou tendo um ataque de pânico. Eu chego a ter problemas intestinais nos momentos que antecedem a minha fala.

Não abandono o plano porque já sei, por experiências prévias, que essa sensação dura só até os primeiros minutos no palco. Nesse momento eu entro em flow com o conteúdo e consigo superar o mal estar.

Quando a apresentação acaba eu só peço para anotarem a placa do caminhão. Estou exausto e, algumas vezes, até com dores físicas.

Muitas vezes eu cogitei “tomar algumas” (“fumar” poderia funcionar também) para ver se quebrava um pouco a ansiedade mas desistia da ideia por respeito à audiência. Eu não sei exatamente o que aconteceria mas não me perdoaria se a apresentação ficasse ruim porque eu estava alterado.

Apesar disso tudo e, diferentemente do Martin Fowler, eu pretendo continuar fazendo apresentações. Sinto que devo isso à comunidade que me trouxe muitas coisas boas na vida e na profissão. Entretanto, tentarei restringir os convites que aceito e, provavelmente, enviarei propostas para poucos eventos.

Para iniciantes

Se tem algo que eu gostaria de trazer para quem vai começar a se apresentar em eventos, é que eles entendam que esse nervosismo é normal e bem comum. Até mesmo aquela pessoa no palco, que você admira muito, pode estar passando por essa provação.

Se você quer encarar essas experiências entenda que pode acontecer esses contratempos ao longo do caminho. E se você não quiser, ou não puder, encarar essas dificuldades tá tudo bem também.

Dentre vários assuntos que tenho interesse na computação um deles é sobre o aprendizado de programação. Principalmente para crianças e jovens. Já li muita coisa e ouvi opiniões muito distintas sobre as melhores formas de se ensinar e aprender a programar um computador.

Existe muita discussão sobre se ensinar crianças a programar seria algo bom ou não, mas não pretendo descer muito nesse aspecto do debate. Para fins práticos vou partir da premissa de que ensinar crianças e jovens a programar não faria mal para eles e acrescentaria algumas habilidades úteis aos seus repertórios.

Lembrando sempre que ensinar programação para crianças não tem nada a ver com encaminhar crianças para a profissão de programador.

Como ensinar programação?

Nas minhas conversas sobre esse assunto, com diversas pessoas, eu já vi abordagem bem variadas para ensinar alguém a programar. O nível de convicção desses interlocutores sobre sua abordagem favorita variava muito. Alguns “achavam” que sua abordagem era boa e outros tinham “certeza” de que a sua abordagem era a melhor.

Um padrão que eu detectei foi: quando mais fácil foi para o interlocutor aprender a programar, mais certo ele estava de que o método usado com ele é o mais adequado.

Isso complica muito a discussão porque faz parecer que reproduzir um desses métodos vai funcionar pra todo mundo. E isso não é assim.

O que esses bons resultados, com abordagens diferentes revelam é justamente o oposto. Revelam que o que dá certo é usar abordagens diferentes com pessoas diferentes.

Abordagens

Eu me deparei com sugestões para os mais diversos tipos de abordagens para ensinar programação para iniciantes.

Existe uma abordagem que busca ensinar teoria e “lógica de programação”. Com computadores de verdade ou com computadores de papel. Alguns sugerem escrever código em “Portugol” em um pedaço de papel para fazer os famigerados “teste de mesa” e só depois ir para o computador. Outros sugerem usar Portugol direto no computador (ou Pascal).

Outras pessoas já me disseram que programador tem logo que começar a aprender a programar em C pra já ficar mais próximo da máquina. Eles sugerem C porque seria uma espécie de “assembly multiplataforma”.

Estou lendo um livro muito bom que sugere ensinar computação (e não só programação) partindo de portas lógicas NAND até implementar um jogo de Tetris.

Por outro lado outros amigos imaginam que o melhor mesmo seria usar alguma linguagem de nível mais alto mas que ainda são linguagens de uso geral como Python, Javascript, Processing, Arduino/C++, etc.

Alguns outros adoram ver seus filhos se divertindo com plataformas especificamente criadas para crianças como Scratch.

O que eu acho dessas abordagens? Na verdade não importa o que eu acho porque não estamos falando do meu aprendizado. Eu já aprendi a programar (eu acho?) e cada uma dessas abordagens funcionou para algumas pessoas e também falhou com outras.

Qual abordagem é melhor?

Ok. Então significa que não existe uma abordagem que funcione para ensinar programação? Não exatamente. Não existe uma abordagem que funcione. Existem várias.

Pessoas diferentes aprendem de modo diferente e isso precisa ser respeitado. Então o certo seria iniciar o ensino com uma das abordagens apresentadas e ir iterando sobre ela para ir ajustando o curso. E focar muito nas práticas e atividades que funcionam melhor para aquele aluno ou para a média daquela turma (caso não seja possível individualizar o ensino).

Dentre várias práticas observadas por cientistas que já se debruçaram sobre o assunto as que mais se mostram positivas para facilitar o aprendizado são aquelas que apresentam o feedback mais amplo e rápido para o aluno.

Quando um aluno experimenta algo no computador e vê o resultado daquilo surgindo instantaneamente o cérebro dele dispara recompensas que ajudam muito a fixação do aprendizado. Por outro lado se ele observa o feedback com a visão, com o olfato, com o tato, com a interação com pessoas, etc o efeito dessa recompensa é potencializada ainda mais.

Essa potencialização do feedback é que fez com que o Seymour Papert, criador do ambiente LOGO para ensino de programação para crianças, disponibilizasse uma tartaruga robô no ambiente que ele desenvolveu. O robô existia para reforçar o feedback das crianças quando ela digitava um comando “PARAFRENTE 10” (ou “FRENTE 10” na variante Microsol LOGO) e via aquele robozão andando sozinho obedecendo à instrução fornecida pela criança. Isso tudo está descrito em seus dois livros.

A ideia de feedback rápido também é explorada nesse artigo incrível do Brett Victor chamado Learnable Programming que serviu de referência para a Apple criar o ambiente Swift Playgrounds.

Então, se voltarmos para as abordagens propostas que descrevi acima, podemos trabalhar com várias delas desde que seja possível obter feedback amplo e rápido nas atividades desenvolvidas.

Tanto o Seymour Papert quanto o Brett Victor apresentam outras práticas úteis no ensino de programação (e, acredito, de qualquer outro tipo de conteúdo). Sugiro a leitura de ambos para se preparar para a tarefa de ensinar programação.

Qual abordagem funcionou pra mim?

Eu sou um privilegiado sortudo. Tive pais que tinham uma boa condição de vida (aka classe média) e nunca pouparam grana e esforço em me apoiar.

Eu já contei um pouco essa história aqui mas resumidamente eu era uma criança de 9 anos que brincava com Eletrônica junto com um amigo e esse amigo ganhou um computador de natal. Eu fiquei completamente entusiasmado com aquilo e pedi um computador pro meu pai.

Demorou um pouco pro meu pai conseguir comprar o meu primeiro computador (MSX Expert) usado de um tio mas ele chegou lá e eu comecei a estudar com os livros que acompanhavam a máquina. Mas aí eu travei em um ponto do aprendizado e passei a usar a máquina só pra jogar.

Meu pai viu aquilo e me cobrou: poxa filho… investimos uma grana alta nesse computador pra você aprender a usar ele e você fica só jogando? Você já tinha um videogame pra jogar (um Atari), não precisava de um computador caro pra isso.

Expliquei pra ele que eu já tinha lido todos os livros e feito todos os experimentos que vinham nele e “não tinha mais pra onde ir”.

Ele entendeu o problema e perguntou se eu queria fazer um curso de computação? “- Claro!”.

Ele encontrou uma escola de computação no bairro onde eu morava através da lista telefônica (é… anos 80/90…) e me matriculou lá. Meu pai não entendia nada de tecnologia e me matriculou nessa escola só porque eu poderia ir sozinho até ela (bairro Boa Vista em São José do Rio Preto – SP).

E até aqui mostra como fui/sou uma pessoa privilegiada. Mas agora vem a parte onde eu fui sortudo…

Essa escola perto de casa, no interior de SP, era de um casal que tinha ganhado uma grana alta em um desses de plano de demissões voluntárias e foram para os Estados Unidos, no MIT, estudar no grupo LOGO do próprio Seymour Papert, pra trazer o método pro Brasil. Eles montaram essa escola usando essa abordagem.

E é aqui que eu ganhei na loteria.

No curso eu aprendi LOGO (variante Microsol LOGO) e BASIC em máquinas Apple II (TK3000 e Exato Pro). Eu saia da aula todo dia e tentava refazer tudo o que aprendi no meu MSX Expert (que não tinha LOGO e tinha um dialeto diferente de BASIC).

Depois eu ia para a casa daquele meu amigo que tinha um Apple II (um raríssimo Spectrum ED) onde ele já estava ralando pra aprender Assembly de 6502 (e eu ali do lado me aventurando junto).

Em dezembro de 1989 eu concluí o curso na “Escola Inteligente” (é… era o nome da escola) e me formei em programação LOGO e BASIC aos 12 anos de idade. Alguns meses depois eu comecei a trabalhar como programador em uma imobiliária da cidade, mas isso é outra história.

Conclusão

Depois desse tempo todo eu acho que não importa se você vai ensinar programação com Scratch, Python, C/C++, Arduino ou pela eletrônica. O importante é que você consiga produzir feedback rápido e amplo por todo o caminho do aprendizado.

Durante muito tempo da minha vida eu trabalhei como programador freelancer. Eu até tive empresa, sócio, etc. mas o fato é que eu era um freelancer como qualquer outro. Afinal eu vendia o serviço, elaborava proposta, negociava, executava o projeto, cobrava, emitia nota fiscal, e dava suporte. Durante esse tempo eu aprendi algumas coisas que gostaria de compartilhar.

Freelancing não escala

Trabalhar como freelancer é divertido e dificilmente enfrentamos problemas com a rotina quando trabalhamos desta forma. Não temos que lidar com a rotina porque cada projeto é único.

Essa variedade de projetos é legal mas tem algumas desvantagens. Como eles são razoavelmente diferentes fica difícil reaproveitar o conhecimento adquirido durante a execução de um deles.

Como o freelancer precisa aprender coisas novas em quase todos projeto perde-se boa parte do “ganho de escala” do negócio. E é o ganho de escala que permite reduzir custos que geram margens de ganho maiores ou preços menores para o cliente. Isso não é bom nem ruim. É uma característica inerente do trabalho do freelancer.

Se o freelancer opta por “crescer” o negócio e montar uma empresa com vários funcionários (ou freelancers) precisa observar que ele pode até ganhar escala mas esse ganho será praticamente linear: para fazer 1 projeto precisa de 1 pessoa e para fazer 2 projetos provavelmente precisará de 2 pessoas.

Você pode até mudar a inclinação do gráfico projetos x pessoas mas ele dificilmente se curvará.

Você vende horas? Cobre por horas

Uma armadilha bastante comum para freelancers iniciantes é a de negociar um contrato com um escopo fechado. A coisa piora se o escopo não estiver muito detalhado.

Essa armadilha é mortal porque na imensa maioria dos casos o contrato vincula o pagamento do serviço à entrega do escopo. E, acredite, os clientes vão expandir esse escopo ao ponto de tornar o projeto prejudicial para o freelancer.

Eu sei que é difícil negociar um contrato baseado em horas de trabalho mas você tem que negociar nesses termos. É melhor não pegar o projeto do que negociá-lo por escopo e/ou vincular o pagamento ao escopo.

Sei que isso é bem complicado porque as contas para pagar chegam todos os meses sem piedade e aquele contrato com escopo fechado oferece uma oportunidade de ter dinheiro para pagar essas contas. Mas no médio prazo você pode acabar se tornando um escravo do projeto e ficar trabalhando de graça nele (ou até pagando para trabalhar).

O melhor para você e para seu cliente é trabalhar com entregas parciais em intervalos curtos e rápidos. Isso nos leva ao próximo ponto…

Atualização: logo depois que enviei O Melhor da Internet o meu amigo Elvis enviou um link para um artigo que ele escreveu onde ele ressalta o fato de que um freelancer raramente consegue vender 100% das suas horas disponíveis.

Atualização 2: Depois que o artigo foi publicado me lembrei de uma outra dica importante relacionada à esse tópico. Quando você está elaborando a proposta e negociando o projeto é importante incluir o tempo usado nesse processo no valor final do projeto. Se você não fizer isso essas horas sairão “de graça” para seu cliente. Para isso funcionar direito as propostas também precisam ter um prazo de validade que permita uma revisão de valores nos casos onde a negociação demora muito.

Não cobre “50% no início e 50% na entrega”

É uma prática bem comum trabalhar dessa forma: o freelancer recebe 50% quando inicia o projeto e o restante quando entrega ele pronto.

Existem duas pegadinhas nesse modelo: uma é o conceito de pronto (veja o tópico anterior) e a outra tem relação com um negócio chamado fluxo de caixa.

Uma das coisas que certamente mata uma empresa é a má gestão do seu fluxo de caixa. E um freelancer é uma empresa de uma pessoa só. Precisa gerenciar seu fluxo de caixa com muita atenção.

Quando você fecha um negócio e recebe por ele 50%+50% fica mais difícil de gerenciar o fluxo de caixa da empresa porque a segunda metade do pagamento vira um alvo móvel. Quando você vai entregar o projeto? Quando ele estará “pronto”?

No lugar de negociar 50%+50% prefira receber parcelas em intervalos regulares (mensalmente? quinzenalmente?). Pode-se até vincular os pagamento às entregas parciais do projeto.

Receber pelo trabalho em intervalos regulares e vincular isso às entregas parciais é o cenário perfeito porque facilita a gestão do fluxo de caixa do freelancer e aumenta a segurança do cliente que pagará por algo que já recebeu.

“Produtize” seus serviços

No primeiro tópico eu falei sobre o problema de escala associado ao freelancing e aqui eu vou apresentar uma forma de amenizar esse problema.

É raro mas acontece: quando um freelancer está trabalhando no seu milésimo projeto ele percebe que certos padrões surgem em todos eles. Exemplo: quase todos os projetos tem um formulário de contato, ou uma página com um mapa mostrando a localização da loja do cliente, ou tem algum sistema de monitoramento, backup, etc.

Quando o freelancer detecta um padrão desses ele pode ter certeza que existe uma oportunidade de transformar essa parte do projeto em um produto que pode ser vendido para vários clientes. Se você fizer isso vai ter um ganho de escala ou até mesmo alguma receita recorrente.

Certos projetos também são genéricos ao ponto de poderem ser transformados em produtos (com a devida anuência do cliente contratante). Um exemplo? Um dos meus clientes solicitaram o desenvolvimento de um sistema de avaliação de funcionários para o RH da empresa.

O sistema usava uma metodologia conhecida como “Avaliação 360°” e gerava relatórios para o RH da empresa avaliar os seus funcionários. O sistema foi desenvolvido para um cliente específico mas, certamente, poderia ser útil para outras empresas. Não foi o caso mas esse projeto poderia ter se transformado em um produto.

Outros tipos de produtos que você pode criar estão na forma de conteúdo. Em meu caso, por exemplo, escrevi um livro e criei um video-curso de programação Python e Django para vender na Internet (que, por não manter mais, acabei disponibilizando gratuitamente).

Crie receitas recorrentes

Todo negócio tem seu risco e com o freelancing não poderia ser diferente. Quando o freelancer está trabalhando e vendendo suas horas de trabalho para alguém as coisas ficam bem. Mas quando, por algum problema, isso não acontece as coisas podem ficar bem complicadas.

Um freelancer pode adoecer, o mercado pode dar uma esfriada, pode acontecer uma entresafra de projetos (ex. o período de novembro a março costuma ser difícil para novos projetos).

Uma maneira de lidar com essas dificuldades é cuidar para poupar nos períodos fartos para ter algo nos períodos difíceis como na fábula da Cigarra e das Formigas. Outro modo de lidar com essa questão é criando formas de se obter receitas recorrentes.

Ofereça serviços de manutenção, suporte, apoio, etc para os clientes que desenvolveram projetos com você. Crie mecanismos (honestos) para continuar recebendo dinheiro deles mesmo depois que o projeto tenha terminado. Ou crie algum produto (tópico anterior) que seja vendido na modalidade de assinatura.

Recuse clientes ruins

Essa é uma das coisas mais difíceis de colocar em prática porque, a menos que alguém nos avise, é quase impossível saber se um cliente novo é bom ou ruim. Mas alguns indícios podem ser observados:

• Cliente que questiona demais os preços – pode ser uma preocupação legítima mas geralmente não é. Mostra que é um cliente mais preocupado com preços do que com qualidade. Ele vai apertar os seus ganhos e vai te trocar por outro mais barato na primeira oportunidade.
• Cliente que não sabe o que quer e não te ouve – existem muitos clientes que não sabem exatamente o que querem e isso isoladamente não é um problema. Mas se você tentar ajudá-lo a descobrir e ele recusar a sua ajuda isso pode virar um problema.
• Cliente que descumpre o combinado – você estabelece com o cliente que ele te pagará mensalmente e no dia do pagamento você tem que ficar lembrando e cobrando. Ou cliente que simplesmente te dá um calote. Eu costumava fazer um teste: eu “esquecia” de cobrar os meus clientes algumas vezes. É engraçado mas os meus melhores clientes sempre me enviavam e-mail avisando sobre meu “esquecimento”.
• Cliente que oferece uma “oportunidade única” de trabalhar para ele – tem muito cliente que pede um precinho camarada em um primeiro projeto com a promessa de valores maiores em projetos futuros. Não caia nessa armadilha porque esse cliente não é fiel à você. Ele é fiel ao teu preço baixo. E não se engane… tem muita empresa grande e famosa que usa o próprio nome para obter essas vantagens. Se usarem o discurso do “você vai colocar a nossa empresa no teu portifólio!” respondam de forma sarcástica: “eu já gastei a minha verba de marketing para esse ano”.

Para clientes pré-existentes é sempre importante gastar algumas horas do mês para reavaliar a sua carteira de clientes e projetos. Cliente bom é aquele que cumpre com suas obrigações, gera bons projetos, indica você para novos clientes e te dá um bom lucro.

Automatize as tarefas chatas

Coisas chatas que freelancers precisam fazer e precisam ser automatizadas o mais rápido possível:

Responder e-mails de sondagem

Eu recebia muitos e-mails assim: “Oi, Meu nome é Fulano e gostaria de saber quanto você cobraria por um projeto assim e assado”. Você tem que responder à esses e-mails mas 80% deles são de aventureiros. Pessoas que não tem dinheiro para te contratar, não sabem o que querem e não vão fechar negócio contigo.

O problema é que não dá pra você diferenciar as boas oportunidades daquelas que vão fazer você perder tempo.

Um das coisas que funcionou razoavelmente bem comigo foi colocar informações detalhadas sobre o tipo de projeto que eu desenvolvia e um valor aproximado para minha hora de trabalho no site da empresa. Colocava destaque na informação: “Esses valores são negociáveis”.

Com essas informações a pessoa já consegue ter uma idéia se ele consegue contratar o seu serviço. A outra informação (valores negociáveis) filtrava os aventureiros daqueles que realmente queriam realizar o projeto.

O cara pode até não ter o dinheiro para te contratar mas se ele quiser muito realizar o projeto ele vai entrar em contato contigo para tentar negociar o prazo de pagamento, os valores, o escopo, etc. E isso, por si só, mostra que ele pode ser um bom cliente e gerar negócios.

Algumas pessoas (por medo ou desconhecimento) acreditam que essas informações no site afugentam clientes. Pode ser que sim. Mas pergunte-se: “Que tipo de cliente eu estou afastando?”.

Produzir e enviar propostas

Depois que você entende melhor o projeto é o momento de enviar uma proposta para seu cliente.

Se você ainda estiver negociando projetos com escopo fechado fica impossível automatizar essa etapa porque cada proposta será única e precisará ser bem detalhada, mas se você negociar em termos de horas a proposta fica bem mais simples. Você precisa apenas preencher os milestones do projeto (entrego X na data Y, …) e fazer uma multiplicação de horas pelo teu valor/hora.

Eu tinha um template no meu editor de textos onde eu só alterava os dados, gerava um PDF, e enviava para o cliente. Se o cliente já era antigo, muitas vezes, eu só mandava um e-mail: “imagino que dê pra gente trabalhar nisso em uma semana por R$X”. E o cliente respondia: “Ok, pode fazer”. Esse é o tipo de relação de confiança que você precisa construir com seus clientes.

Cobrança e NFe.

Cobrar o cliente e ver se ele pagou é uma daquelas coisas que nunca consegui automatizar 100% mas cheguei à um ponto onde isso não atrapalhava o resto das atividades.

Eu criei uma conta de cobrança sem registro na conta da empresa no banco (dica: não misture sua conta pessoal com a conta usada para seu trabalho) e emitia boletos para meus clientes pagarem. Cerca de 5 dias depois da emissão dos boletos eu puxava um extrato e conciliava os pagamentos na mão. No site da prefeitura eu emitia as NFe daqueles que haviam pagado o boleto.

Comecei com um software que só emitia os boletos e depois migrei para outro que emitia os boletos e a NFe.

Seja parceiro dos bons clientes

É provável que você não consiga resolver todos os problemas de seus clientes e, nestes casos, você deve ajudá-lo a encontrar as soluções para esses problemas. Mesmo que para isso você tenha que encaminhá-lo para um outro prestador de serviços (freelancer, empresa, etc).

Se você fizer isso o cliente criará um modelo mental muito positivo sobre você: “quando eu tenho um problema é só eu entrar em contato com esse cara que ele resolve ou me ajuda a resolver”. Esse modelo mental é poderosíssimo para gerar novos negócios.

Cumpra combinados e faça com qualidade

Deveria ser o primeiro item mas resolvi deixá-lo para o final para que fique mais fresco na sua memória.

É da mais absoluta importância para um profissional que ele cumpra aquilo que foi combinado com o cliente. E mais do que isso… é importante que tudo seja feito com a maior qualidade.

Cumprir com o combinado manterá o seu cliente fiel à você. Fazer isso com qualidade transformará ele num canal de vendas.

O programador, empresário e investidor Paul Graham publicou um artigo afirmando que as leis de imigração americanas impedem que talentos de outros países possam trabalhar nos EUA. Em resposta à esse artigo alguns programadores e empresários conhecidos sugeriram à ele que o trabalho remoto seria uma solução melhor para esse problema. Outros reforçaram a opinião do Paul Graham e começou aí a discussão.

Já faz quase 2 anos que trabalho remotamente para uma empresa de São Paulo a partir de Curitiba. Eu fui o segundo funcionário da empresa a ser contratado para trabalhar desse jeito. Hoje já temos 7 profissionais trabalhando assim.

Não vou mentir pra vocês: no começo foi bem complicado. Erramos de todas as formas e falhamos miseravelmente várias vezes até conseguirmos fazer as coisas funcionarem bem. Ainda está longe da perfeição mas a empresa, as equipes e os remotos estão se esforçando muito para melhorar.

Entre o caos e a situação em que estamos hoje houve um “turning point”. Um momento em que decidimos fazer a coisa funcionar.

Primeiro resolvemos estudar o assunto. Eu comprei livros e mais livros, assisti palestras e mais palestras, busquei referências em artigos, e refleti muito sobre nossos problemas.

O problema principal era a interação deficitária da equipe. Mesmo sendo uma equipe ágil que pratica SCRUM existiam muitos vícios na forma como os membros da equipe interagia. Era uma interação “olho-no-olho”, extremamente verbal (offline) e síncrona.

Essas três características são péssimas:

• “Olho-no-Olho”: as reuniões diárias eram feitas com todos de pé (standup meeting) com todos os integrantes no escritório. Não preciso dizer que isso não rola para equipes remotas, certo?
• Comunicação Verbal Offline: para uma equipe remota toda comunicação verbal já é deficitária (precisa de headset, conexão, ajustar o áudio, etc). A comunicação verbal “offline” é ainda pior. Eles decidiam coisas lá em SP e a gente nem ficava sabendo.
• Comunicação Síncrona é aquela em que os intelocutores precisam estar “conectados” simultaneamente para transmitir a mensagem. Mesmo para trabalho local ela é ruim porque é uma comunicação que interrompe as pessoas. Exige a atenção delas. É o “cutucão no ombro”, o chamar no Skype, a “reuniãozinha rápida”, etc.

Enquanto ia refletindo sobre isso eu me lembrei sobre como foi trabalhar na Conectiva. A Conectiva foi o lugar onde trabalhei onde a comunicação da empresa era um exemplo de eficiência. Toda a comunicação da empresa funcionava pelos meios eletrônicos de forma extremamente eficaz:

• Listas de Discussão (mailman com histórico online): toda a comunicação “séria” da empresa era feita por email em listas. Todos policiavam o bom uso do email e davam puxões de orelha em quem não usava do jeito certo. Existia uma hierarquia de listas (toda a empresa, equipe técnica, desenvolvimento, etc) e listas para coisas informais (off-topic). O email era para comunicação assíncrona e gerava longas threads muito bem escritas e organizadas onde se discutia quase tudo. Não era para preguiçosos porque exigia bastante esmero dos participantes.
• IRC: a empresa tinha um servidor interno de IRC com salas organizadas também de forma hierárquica. Era usado majoritariamente pela equipe técnica (a parte administrativa da empresa usava ICQ… lembrem-se que era 2000). Aqui rolava a comunicação síncrona e a coordenação do trabalho.

Observem que não tinha nada de mais nas ferramentas. Mas elas eram usadas de forma correta e havia um policiamento por parte de todos para que isso não fosse desvirtuado.

Olhando pra isso é possível enxergar que a gente trabalhava “remotamente” no mesmo escritório. Não fazia diferença o local onde a gente estava. O trabalho aconteceria de qualquer forma porque tudo era comunicado o tempo todo pelos meios eletrônicos (salvo raras exceções e brincadeiras entre os integrantes da equipe).

Percebi que “tinha algo ali” mas guardei isso comigo.

Em 2013 a empresa onde trabalho mandou um ônibus para Brasília onde participaríamos da PythonBrasil[9]. Em Brasília tudo é “longe” e esse ônibus virou um transporte extra-oficial dos participantes do evento. Um dos convidados do ônibus foi o Sidnei da Silva e na época o Sidnei trabalhava remotamente para a Canonical. Uma grande oportunidade de aprender algo.

Entre as várias dicas que ele nos passou teve uma que me chamou a atenção: “a equipe tem que saber trabalhar remotamente mesmo que esteja no mesmo local”. Bingo!

Meu gerente (que também pesquisava o assunto) estava do meu lado quando o Sidnei disse isso e também percebeu a importância dessas palavras. Voltamos para o trabalho decididos a implantar esse sistema.

Não foi fácil mas conseguimos. Fizemos o seguinte:

• “Forçamos” o uso de um headset para todos os integrantes da equipe (inclusive quem está no escritório);
• As Dailys (usamos SCRUM) seriam feitas online (usamos o Mumble em um servidor próprio);
• Movemos a maioria das conversas e discussões para os meios eletrônicos (isso diminuiu as interrupções causadas pelo “cutucão no ombro”);
• Migramos todos os nossos whiteboards e post-its para o mundo virtual (usamos Scrumdo mas estamos avaliando alternativas melhores);
• Usamos Slack e estamos adorando. Avaliamos e usamos outras (IRC próprio, Grove.io, Hipchat) mas o Slack detona;
• Pareamos com tmate (temos um servidor pra isso) ou Teamviewer mas como a “fauna” de editores de texto e IDEs na empresa é abundante estamos sempre procurando algo melhor. E o Google Hangout é uma bosta. Nem adianta recomendar ele pra gente 😀 (Floobits?);
• Já usávamos Github mas passamos a aproveitar melhor o sistema.

Tudo isso foi legal e bacana mas o que realmente foi importante nessa mudança foi o compromisso de cada um para que o trabalho desse certo. Começamos a nos policiar e “brigar” para que as coisas funcionassem do jeito certo.

Foi importante mostrar para a equipe de SP que, se isso desse certo, eles também poderiam se beneficiar. Poderiam escolher entre ficar em casa ou encarar o trânsito de SP, por exemplo. Alguns poderiam até trabalhar mochilando!

Para a empresa? Só sucesso… ela consegue contratar os melhores funcionários mesmo que eles não queiram morar em SP. Conseguem economizar com infra-estrutura e com folha de pagamento (um salário bom em SP é excelente no interior de SC).

Quando eu era empresário sonhava em ter um escritório bacana cheio de gente foda trabalhando comigo. Hoje sou um defensor ferrenho do trabalho remoto. Acho que os governos deveriam incentivar essa forma de trabalho até mesmo como forma de melhorar o trânsito das grandes cidades.