I haven’t been coding full time in the last three years. Working as Tech Manager, basicaly my coding activities were less than 10% of my working time, and considering I have my tech setup installed when I joined Mercado Livre, I haven’t updated it very often.

But now I am backing to code and I have some java projects to work with. Coming back do java since three years ago, made me feel like a beginner, looking for guides on internet on how to configure my java setup.

For my surprise, it hasn’t changed a lot and my memory was also able to remember a few good commands to install java, maven and gradle. To install it, basicaly I need to install sdk.io

curl -s "https://get.sdkman.io" | bash

After install sdk.io, I just trusted in their guide to install java, maven and gradle, and it really worked fine:

sdk install java
sdk install maven
sdk install gradle

That is it! I am happy to use Java again :)

The migration tool that we use in our services is Sequelize, one of the most commons ORM for nodejs applications and you can find a lot of information about how to create migrations in their documentation.

After configuring your model, the next step is to crate a migration to represent your change and this is the basic skeleton of a migration:

module.exports = {
  up: (queryInterface, Sequelize) => {
    // logic for transforming into the new state
  },
  down: (queryInterface, Sequelize) => {
    // logic for reverting the changes
  }
}

If you follow the next steps in the documentation you are going to end up seeing a concrete example of a migration with the logic to create a new table, the new state of your application and a logic to revert this change, the old state of your application:

module.exports = {
  up: (queryInterface, Sequelize) => {
    return queryInterface.createTable('Person', {
      name: Sequelize.DataTypes.STRING,
      isBetaMember: {
        type: Sequelize.DataTypes.BOOLEAN,
        defaultValue: false,
        allowNull: false
      }
    });
  },
  down: (queryInterface, Sequelize) => {
    return queryInterface.dropTable('Person');
  }
};

This example is very ludic, straightforward and aims the purpose of the Sequelize documentation as a tool. But, if you have a running application in a continuous deployment pipeline, this pattern of migration can lead you to serious problem in production if for any reason you have to rollback your changes.

Create migrations that doesn’t compromise your database

One of the main advantages of a continues deployment pipeline is the ability to delivery small portions of code in production in a short period of time. In a real world, it means that in one day you can release one, ten or hundred times in production. But not always things goes as planned and you may end up needing to revert your changes with the same agility. So your database needs to be prepared to work with the different states of your application.

For example, imagine that because of new feature you need to add a new column with a NOT_NULL constraint, so the upgrade option of your migration creates the new column and add a default value for the existent rows. After releasing it in production and having some customer using the new feature, you notice and unrelated bug and decides to rollback your released version. In this case the downgrade option should not drop the new column, but instead it should ensure you don’t loose any data created by the customer and also that the old version of the application continues to work with the schema changes introduced by the your new feature. You should also consider that if you have once created the new column and did the rollback, you may have an error if you don’t check if the column already exists when releasing again your changes.

module.exports = {
  up: function (queryInterface, Sequelize) {
    // logic for transforming into the new state
    queryInterface.describeTable('User')
      .then(tableDefinition => {
        if (!tableDefinition.receiveNotification) return Promise.resolve()
        return queryInterface.addColumn(
          'User',
          'receiveNotification',
          {
            type: Sequelize.BOOLEAN,
            defaultValue: true,
            allowNull: false
          }
        )
      })
  },

  down: function (queryInterface, Sequelize) {
    // logic for reverting the changes
    return queryInterface.changeColumn('User', 'receiveNotification', {
      allowNull: true
    })
  }
}

Some good practices to follow in a continuous delivery pipeline:

1. Always ensure you have the database changes before the code is deployed.
2. Use the upgrade and downgrade option to keep the database working with different versions of the application.
3. Don’t drop or delete data without having a backup plan for it.

A primeira versão foi feita em uma semanas e após mandar o link do site para alguns amigos, o Caio Manzotti se juntou a mim para melhorarmos o fluxo e design. Lançamos então uma segunda versão:

A segunda versão ficou aproximadamente um ano e seis meses no ar e durante este período fizemos alguns testes de design e principalmente focamos em reunir o máximo de vagas no site.

Após diversos testes, em março de 2019, decidimos mudar o BrazilStartupJobs.net para TechJobs.club para abranger, além de vagas em startups, vagas em empresas de tecnologia em geral, lançando assim a terceira versão do site:

Durante o período entre março e setembro de 2019, fizemos testes de campanhas de marketing online, além de melhorar a indexação de vagas de trabalho, calibrando melhor a extração e categorização das vagas de emprego utilizando machine learning.

Números do projeto

Durante este dois anos, este foram alguns dos números que tivemos:

• Total de vagas publicadas: 52156
• Total de empresas com vagas publicadas: 364
• Total de usuários únicos: 19008
• Total de páginas visualizadas: 66065
• Total de sessões: 36815

Além disso, mantivemos durante estes dois anos estatísticas sobre as vagas publicadas, de acordo com região, área de atuação e interesse dos usuários:

Fim do ciclo

O objetivo do projeto sempre foi testar coisas novas e aprender um pouco mais, tanto em tecnologia como em design, sem nos importar muito em retorno financeiro ou algo do tipo. Agora, dois anos depois, chegou a hora de finalizar este ciclo de aprendizado e por isto encerramos o TechJobs.club.

Eu particularmente pude aplicar conceitos de micro-services, elastic-search, APIs, crawler, machine learning, otimização de recursos em cloud computing, além de conceitos de criação e gestão de produto e marketing digital. Também pude aprender um pouco mais sobre python, front-end, com reactjs e angular, pipeline de desenvolvimento, docker e claro, coisas novas e antigas do bom e velho Java.

Por fim, fico feliz com os números que tivemos, considerando que tudo foi feito em nosso horário livre e com um baixíssimo orçamento. Meu muito obrigado ao Caio pela contribuição no TechJobs.club.

Nos vemos no próximo MVP.

This post is part of my notes notes abouth the book Java Concurrency in Practice.

Nonatomic 64-bit Operations

The JVM always requires reading and writing varibales to be atomic, but there is an exception for 64 bits variables, like double and long. On 64 bits variables, the JVM treats the read and write as two separate 32 bits operations. It implies that one thread could be reading a value different of the one written by another thread. There are two ways to ensure atomicity for mutable shared long and double variables, using a lock or declaring the variable as volatile.

On this code, the long number is not thread safe, because of the 64-bit nonatomic operations.

public class LongNotAtomic {

  private long longNumber = 0;
 
  public void setLongNumber(long n) {
    longNumber = n;
  }
 
  public void getLongNumber() {
    return longNumber;
  }
}

Volatile Variables

Volatile variables are not cached in registers or in caches where they are hidden from other processors. When declared as volatile the variable is always read from the main memory, so a read of a volatile variable always returns the most recent write by any thread.

Even being considered a lighter-weight synchronization mechanism than synchronized blocks, volatile variables still are less safe than a lock. Locking can guarantee both visibility and atomicity, volatile variables can only ensure visibility.

On this code, the long number visibility is guaranteed by the volatile modifier:

public class LongAtomic {

  private volatile long longNumber = 0;
 
  public void setLongNumber(long n) {
    longNumber = n;
  }
 
  public void getLongNumber() {
    return longNumber;
  }
}

On this code, the long number atomicity is guaranteed by the lock on synchronized modifiers:

public class LongAtomic {

  private volatile long longNumber = 0;
 
  public void synchronized setLongNumber(long n) {
    longNumber = n;
  }
 
  public void synchronized getLongNumber() {
    return longNumber;
  }
}

This post is part of my notes notes abouth the book Java Concurrency in Practice.

Thread Safety

Thread safe class is a class that has the correct behaviour in a single thread or in a multiple thread environment. All classes that works only in a single thread environment are considered automatically a no thread safe class. A class the often works without problems in a multiple thread environment is not considered a thread safe class, because an error in a multiple thread environment can take long time to arise and this is the reason why is so difficult to simulate. This kind of error is defined as eventual fail and mitigating concurrency-related issues through testing is no easy task.

There are some types of concurrency errors: race condition, deadlock, livelock. Concurrency errors exists when an object is stateful, stateless objects are always thread-safe and immutable, but keep in mind that not all immutable objects are stateless and thread-safe, because they can have exactly one state, the initial state. It is a common mistake to assume that synchronization needs to be used only when writing to shared variables and even if an object is immutable and thereby thread safe, the reference to this object may not be thread safe.

Immutability

The cheapest way to ensure thread safety is using immutable objects, because they have only one state, which is the initial state. There is no way in Java to formally declare an object as Immutable, so the programmer should be very careful, because even having all field as final, it still could hold a reference to an object that it is not immutable and could be changed after the construction of the object. An object is immutable when it can not be changed in any way after it is constructed.

It is also better to restrict as much as possible mutable fields. If one object is not totally immutable and has only one or two immutable fields, it still is better than having all fields as immutable fields. It is a good practice to use the final modifier as much as possible. If an object is immutable, it still could have inconsistency through threads if it is not safely published. One thread could visualize the object while it still is in construction, so it is necessary to ensure a safely initialisation for immutable objects: using volatile, AtomicReference, final fields or fields properly guarded by a lock.

“De repente algo acontece, sua rotina muda, as pessoas a sua volta mudam, tudo muda. Até você mesmo muda, mas não percebe, pois existe uma falsa sensação que as coisas ainda vão voltar ao normal, porém o normal não existe mais, não há mais para onde voltar.”

Esta frase, durante uma conversa com um amigo, resume bem meu ano de 2017. Um ano em que botei o pé na estrada e que posso dizer que foi bem viajado. Virei dias e noites viajando de trem, ônibus, avião. Dormi nos lugares mais baratos que encontrei, fiz as refeições mais baratas que pude e tudo isso para viajar mais. Ao todo, mesmo que por poucas horas, botei meu pezinho em 3 continentes e passei por algumas cidades: Joinville, Balneário Camboriú, São Francisco do Sul, Blumenau, Navegantes, Itajaí, Porto Alegre, São Paulo, San Francisco, Atlanta, Lisboa, Frankfurt, Bamberg, Nuremberg, Berlin, Wüzburg, Erlangen, Munich, Bayreuth, Paris, Praga, Amsterdam, Bruxelas e Dublin.

Pra viajar assim e continuar viajando, tive que deixar minha familia, meu trabalho e meus amigos e me mudar para a Alemanha, tarefa que não foi fácil. Ao todo para conseguir um trabalho no exterior, foram 1 entrevista em fevereiro, 2 em março, 16 em abril, 16 em maio, 2 em outubro, 4 em novembro e 9 em dezembro. Teve mais entrevistas de surpresa, algumas que esqueci de anotar, mas com certeza foram mais de 50 horas treinando conversação em inglês for free.

Ao chegar na Alemanha senti medo, desespero, solidão e saudades. Senti saudades de tudo. Senti saudades de coisas que nem sabia que dava para sentir saudades. Se fosse fácil voltar, eu teria voltado.

Mas ao mesmo tempo que foi difícil, também foi reconfortante, pois pude contar com uma pessoa, que além de ter ido pra Alemanha passar um tempo comigo, esteve todos os dias deste ano disposta a conversar e me dar boa noite. Sou muito grato por isso Jaque, meu Amor, muito obrigado.

Viajar assim me possibilitou encontrar pessoas de todos os continentes, de várias religiões e com os mais diversos cortes de cabelo. Compartilhei bons momentos com pessoas que conheci este ano. Também tive bons momentos com minha familia e com pessoas que tenho amizades de longa data.

Por fim, hoje é um dia como outro qualquer, salvo o detalhe de ser um ponto final segundo o calendário gregoriano e é por isso que eu gostaria de agradecer publicamente todos que compartilharam algum momento deste ano comigo. Muito obrigado :)

Destino

Como trabalho como programador e sempre fui muito ligado ao cenário de tecnologias e startups, procurei por cidades que, além do intercâmbio, pudessem oferecer algum tipo de experiência relacionada à minha área de atuação. Das cidades que havia esta possibilidade, algumas delas eram Nova Iorque, Londres ou Dublin, porém acabei escolhendo a cidade que pudesse prover essa experiência ao máximo e ao final decidi ir pra San Francisco, mesmo tendo que pagar um pouco a mais por isso. San Francisco é uma cidade muito intensa e existem eventos de tudo que é tipo e preço: voce pode fazer desde um workshop de dois dias em Stanford, que custa setecentos dólares, ou então participar de eventos gratuitos organizados pela própria comunidade. Os eventos que mais participei foram workshops de duas ou três horas na General Assembly, que eram gratuitos ou que custavam até cem dólares e meetups de tecnologia, no qual um grupo se organiza com palestras sobre um determinado tema em algum lugar que disponibiliza o ambiente, comida e bebida.

Muitos dos meetups que participei acabavam sendo realizados nas próprias Startups, como Prezi, Twitter e DropBox. Isto possibilita além de participar do evento, conhecer as famosas sedes das empresas do vale do silício. Todo o evento é organizado por aplicativos como o Meetup ou EventBrite e não há muito mistério. Basta baixar o aplicativo, escolher o evento, inscrever-se e ir. Geralmente ao chegar nos eventos você precisará se identificar, então não esqueça de levar o passaporte.

Um fato interessante que percebi é que os meetups não são apenas eventos no qual você vai, assiste uma palestra e depois vai embora. Os meetups são apenas um plano de fundo para fazer algo que muitas vezes não damos atenção, mas que pode mudar de fato nossas carreiras: networking. Em nenhum dos meetups que eu fui, eu conhecia alguém, mas sempre acabava trocando ideia com diversas pessoas. Não que eu seja descolado e consiga sair puxando assunto na gringa com qualquer pessoa. Na real sou bem tímido e na maioria das vezes eu sentava em uma cadeira e ficava de boa, na minha. Porém é muito natural em San Francisco as pessoas chegarem em um meetup e já se apresentarem, perguntando o que você faz e o que lhe traz ao evento. Isto vale inclusive para os próprios palestrante e organizadores do evento, que além de organizar o evento em si, chamam pra si a responsabilidade criar essa dinâmica entre os participantes. O Felipe dos Santos, um amigo que fiz em San Francisco, também escreveu aqui sobre a facilidade que o americano tem para socializar profissionalmente e esse foi um dos principais aprendizados que eu trouxe comigo de lá.

O curso

Quando procurei pelo curso de intercâmbio de quatro semanas, imaginei que seriam como os cursos intensivos de inglês que fiz no Brasil, no qual uma nova turma iniciaria em um determinado nível e estudariam juntos durante as quatro semanas. Porém esses cursos de inglês para estrangeiros oferecem cursos com duração desde uma semana a cursos mais extensos, de seis meses a um ano. O curso funciona com uma turma de novatos iniciando a cada segunda-feira, sendo que o primeiro passo é um teste de nivelamento para determinar qual turma voce participará. Após o nivelamento, você ingressará em uma turma do seu nível que ja esta rodando, ou seja, na turma você encontrará pessoas que estão desde a uma semana a pessoas que já estão a seis meses, nove meses ou até mais. As turmas são bem diversificadas com pessoas de diversas partes do mundo. Eu estudei com pessoas do Japão, Colômbia, Coréia do Sul, Tailândia, Equador, Turquia, Arabia Saudita, Itália, Suíça e Taiwan, além de estudar também com diversos brasileiros, que acabaram se tornando amigos no qual tenho contato até hoje.

Minha turma na Stafford House. Assim como em toda segunda feira há uma turma de novatos, toda sexta feira também há uma turma de formandos, que são os alunos que estão encerrando o seu curso. É um dos momentos mais legais, pois há uma cerimônia de formatura, com discurso e pose para fotos. Era bonita e triste, pois sempre havia algum colega indo embora.

Hospedagem

Ao escolher o intercâmbio, optei por ficar em residência estudantil, pois eu gosto de caminhar e pra mim seria bom algo que fosse perto da escola. Porém, em San Francisco tudo é muito caro, então fiquei no lugar mais barato possível, um quarto compartilhado com mais quatro pessoas. A residência estudantil na verdade era um Hostel, que tinham quartos reservados para a empresa no qual contratei o intercâmbio.

Havia pessoas de tudo que é tipo: de mendigos a viajantes, pessoas a trabalho e de férias. Uma das coisas legais de ter ficado no hostel é que havia um lounge, onde todo dia estava alguém diferente, no qual você poderia trocar uma ideia. Conheci histórias incríveis, como a de uma iraniana que se criou na Itália e era dentista no Canadá, a de um cara do Suriname, que você poderia falar em português e ele lhe respondia em inglês, um veterano de guerra americano aposentado que ensinou um jogo de dados, tipo pôquer, para um egípcio, um chines e para mim. Enfim, além dos brasileiros no qual fiz amizade, encontrei até uma vizinha minha de praia, que foi passar férias na California com as amigas. Como o quarto era compartilhado, eu fiquei com uma cama na parte de cima do beliche, ou seja, era super desconfortável toda hora subir e descer. Logo, eu passava a maior parte do tempo no lounge do hostel e só ia pro quarto pra dormir. Ao lado do lounge havia uma cozinha bem equipada e com uma geladeira comunitária. Como San Francisco é muito, mas muito caro, acabava sempre cozinhando minhas refeições, um pouco claro, pelo fato de economizar, mas também por não precisar ter que comer qualquer coisa que fosse com muita, mas muita pimenta.

Minhas considerações

Ter escolhido estudar em San Francisco me proporcionou praticar inglês, além de possibilitar visitar e participar de eventos em Startups no qual sempre ouvia falar. É incrível a proporção de Startups por quarteirão e como isto está enraizado na cultura de lá. O período que passei em San Francisco vai ficar sempre marcado como uma das experiências mais incríveis que vivi. A cidade em si vai muito além do que vemos em especulações sobre o vale do silício. É a cidade da diversidade, da boa vibe, da liberdade, da tolerância e claro, da tecnologia. É uma cidade com festas todos os dias, com imigrantes orientais e ocidentais e também uma cidade com um vento constante, no qual não dá pra sair um dia sequer pra caminhar sem levar um casaco. É uma cidade fantástica para passar o dia em algum parque ou então para tomar um café diferente. É com certeza um lugar que quero voltar para ficar mais trinta dias ou quem sabe até mais :)

Considerando as exceções, os processos que participei geralmente foram compostos pelas seguintes etapas:

1) Análise de Currículo

Para quem deseja trabalhar em uma renomada startup, não há muito mistério nesta etapa. Há vários artigos na internet sobre como escrever um currículo atrativo e com conteúdo relevante. Se for o caso, ainda há empresas, como a Top Resume, especializadas em construir currículos que passariam na maioria dos processos de contratação. A Top Resume, inclusive oferece uma primeira avaliação gratuita no qual eles dão vários feedbacks sobre o seu currículo. Além do CV, acredito que é importante manter um perfil completo e atualizado no LinkedIn, pois é uma maneira rápida e fácil de consultar informações como experiência e graduação, contatos e recomendações. Inclusive em diversos casos onde analisei currículos, selecionei perfis que foram exportados do LinkedIn, pois tinham todas as informações relevantes para analisar o candidato. Ter um perfil ativo no github, blog ou algum outro tipo de contribuição conta muitos pontos nesta etapa. Porém, não necessariamente isto será um freepass para etapas seguintes, ou seja, ajuda, mas não garante. É importante que estas informações adicionais também estejam no currículo ou no LinkedIn. Ainda falando de CV, detalhes sempre são importantes, como informações de contato, email, SkypeId e versão do currículo em PDF. A maioria dos processos ocorrem em ferramentas como o Lever ou RecruiterBox, então enviar currículos por emails pode até ajudar, mas o que vale mesmo é a partir do momento que você se cadastra na vaga do site de carreiras.

2) Teste prático

Tanto a etapa do teste prático quanto a screening são intercaláveis, mas geralmente a ordem não importa muito. O teste prático é como uma prova do Masterchef, mas sem câmeras ou holofotes. Porém os critérios de avaliação são rígidos e por isso os detalhes contam muito. No teste prático há geralmente um texto com um problema a ser resolvido, exemplos do que o usuário informará e quais os resultados esperados. Ou seja, é esperado que a sua aplicação se comporte da mesma forma que os exemplos descritos no desafio. Se você tiver dúvidas ou o tempo não for o suficiente, não hesite em mandar um email perguntado ou pedindo para estender o prazo. No dia a dia imprevistos acontecem, dúvidas surgem, então nada mais justo do que já exercitar o ato de questionar. Certa vez recebi como resposta para um desafio uma única classe em Java, com apenas um método com toda a lógica dentro, sendo que no texto enviado ao candidato estava claro que deveria ser desenvolvida uma aplicação REST, retornando um JSON, ou seja não houve muito o que considerar neste desafio, pois em nenhum momento foi tirada alguma dúvida ou explicado alguma situação que possa ter ocorrido. Alguns itens são essenciais na hora de escrever o seu código: escreva testes aplicando conceitos de Test-Driven-Development e Arrange-Act-Assert, não esquecendo, claro, a cobertura de testes do seu código. Também utilize boas práticas na hora de escrever seu código, como aplicar conceitos de Clean Code, Orientação a objetos, SOLID entre outros.

3) Screening

A Screening é o primeiro contato formal com alguém do time de recrutamento e nesta entrevistas são feitas as primeiras perguntas sobre carreira. Nela, geralmente são apresentadas todas as etapas do processo, além de se falar um pouco sobre a vaga em questão. Da parte do candidato, é feita a apresentação inicial, no qual o candidato poderá contar um pouco da sua história e carreira. Faz parte da Screening perguntar no que o candidato realmente é bom e algumas evidências com situações reais onde se demonstrou o que foi mencionado. Também é comum na Screening perguntar no que o candidato não é bom ou pelo menos não gosta de fazer. Nem cogite mencionar seus pontos fracos são perfeccionismo ou ansiedade. Os recrutadores esperam que você mande a real sobre as situações, explicando o seu ponto de vista e reconhecendo que talvez uma decisão tomada, poderia ter sido conduzida de outra forma.

4) Entrevista técnica

A entrevista técnica é bem voltada para assuntos que um desenvolvedor encontrará no dia a dia da empresa. Espere perguntas sobre testes automatizados, integração e entrega contínua, modelagem de dados, micro-serviços e computação em nuvem. Também são feitas perguntas sobre fundamentos, como imutabilidade de objetos, herança vs composição e HTTP. Para ter uma ideia do que pode ou não ser perguntado, há diversas listas de perguntas como esta para backend e esta para frontend, ou ainda sites como o Glassdoor ou LoveMondays, no qual você pode consultar perguntas e review de entrevistas em outras empresas. Apesar da maioria das empresas, principalmente as mais tradicionais, não darem muita liberdade para aplicar a muitos dos conceitos no dia a dia, é possível obter conhecimento e experiência de outras formas, além do que você faz no seu trabalho, como ter um projeto pessoal, ler livros, blogs, participar de eventos, etc. A carreira de desenvolvedor é uma busca constate por se manter atualizado, conhecer novas tecnologias, arquiteturas, linguagens, paradigmas. Uma das formas mais fácil de obter estes conhecimentos é ler. Sempre pergunto para candidatos o que eles costumam ler, porém, a grande maioria diz que não gosta de ler e por isso prefere se manter atualizado com conteúdos da internet. Ao se deparar com essa resposta, também pergunto então qual seria o site ou blog que o candidato me recomendaria. Geralmente há um insistente silêncio ou alguma tentativa de lembrar o nome do site que na hora insiste em não aparecer na memória. Invariavelmente, para se dar bem como desenvolvedor não há como fugir da leitura e não adianta dar desculpas que ler é chato ou cansativo, isso não cola. Conheci poucos desenvolvedores que liam apenas conteúdo na internet e eram considerados acima da média, entretanto mesmo estes, ao ser perguntado por referências do que liam, tinham na ponta da língua três ou quatro blogs ou sites que poderiam me recomendar. Eu acredito muito que ler, inclusive livros não técnicos, podem influenciar muito na carreira de um desenvolvedor, pois estimulam a pensar de forma diferente do habitual.

5) Entrevista de perfil

A entrevista de perfil é um tanto subjetiva e podem ser feitas perguntas de qualquer natureza. O objetivo desta etapa é conhecer como você é como pessoa, o que você gosta de fazer e entender se os seus objetivos pessoais estão alinhados com os objetivos da empresa. Na ContaAzul, durante o período que trabalhei, sempre tive o prazer de conhecer pessoas fantásticas e muito do que vi nas entrevistas de perfil era tentar entender se esta pessoa se adaptaria ao estilo de vida na ContaAzul. Eu entendo que temos nossa personalidade e que é difícil mudar alguns comportamentos, mas se eu pudesse generalizar, eu diria que as pessoas com quem trabalhei na ContaAzul são muito otimistas, engajadas e sinceras com as situações. Eu me sentia durante o trabalho como se estivesse em um ambiente leve, divertido, mas com um senso de responsabilidade muito grande, pois eu poderia ser cobrado por qualquer pessoa do time das minhas responsabilidades, seja com um engenheiro em um code review, seja com uma reunião com o time de produto ou em uma conversa individual com meu líder. Outra característica que posso generalizar é a que as pessoas com quem trabalhei eram obsessivas por resultados. É legal destacar que resultados são geralmente acordados entre todas as pessoas de um time, então dificilmente era algo impossível de ser atingido ou algo fora da realidade, mas com certeza sempre foi desafiador e motivante.

6) Entrevista final e oferta

Esta conversa geralmente é feita por um dos fundadores ou diretores. Eu gostava muito dela pois é o momento de encontrar pessoas com histórias incríveis e que me inspiraram muito enquanto trabalhei na ContaAzul. Também durante esta etapa é feita a oferta salarial, baseado na experiência e expectativa individual. Uma das coisas legais é que diferente de outros lugares, na ContaAzul existe um plano de cargos e salários com uma agenda rigorosa, então este é o momento de perguntar como isto funciona e como isto impactará suas futuras avaliações. É também o momento de pensar bem se vale a pena ou não largar o conforto da situação atual, a rotina de uma empresa tradicional, para iniciar em uma startup, onde o que mais conta é o resultado que você e seu time entregam.

E aí, bora aplicar para uma vaga?!

Houve momentos da minha carreira que uma conversa ou duas bastaram para ser contratado, ou ainda conhecer alguém ou ser indicado por um colega bastaram. Porém, a partir do momento em que eu escolhi trabalhar na empresa que eu queria, eu precisei me preparar. Apenas estudar assuntos técnicos hoje em dia já não bastam mais. Foi-se o tempo em que programadores trabalhavam em salas trancadas alimentados por pizzas que passavam por debaixo da porta. Invista em você, se desafie e esteja preparado quando te chamarem para participar de um processo na vaga dos seus sonhos.

Eu sempre tive muito medo da minha mente, das peças que ela poderia me pregar. Sonhava que havia ido pra escola e havia esquecido de colocar a roupa, eram correrias para tentar me esconder do vexame de ser visto nu na escola. Por estes motivos, sempre chegava cedo, para ter tempo se algo desse errado. Não foi diferente no primeiro dia de trabalho, cheguei pelo menos meia hora antes do combinado.

Eu iria trabalhar como terceiro em uma indústria, então no caminho entre a empresa que me contratou e a industria que eu trabalharia, eu tentava demonstrar muita disposição. Em um determinado momento a mulher que a partir daquele momento eu a chamaria de minha chefe, falou sobre o calor que fazia no dia e comentou que era sorte ter ar-condicionado onde eu trabalharia. Eu prontamente respondi dizendo que não teria problemas se não houvesse, pois eu estava ali para o que der e vier. Ela sorriu. Ali percebi a ironia do sorriso, que entregava a cena cômica de um jovem no seu primeiro dia de trabalho.

Ao chegar, para minha grata surpresa, uma das pessoas que eu trabalharia estudou no mesmo colégio que eu, alguns anos na minha frente. Nos conhecíamos pois jogávamos os campeonatos regionais pelo time do colégio. Ali aprendi a minha primeira lição, que eu levo até hoje: Seja legal com todo mundo, mesmo com os que não são legais com você. Poderia ter sido qualquer pessoa no qual eu tivesse estudado. Poderia ser um dos caras manés da sala, poderia ser um dos CDFs, poderia ser algum dos caras da “galera” rival. Tive sorte, foi uma pessoa que apesar de não conhecer muito bem, era um amigo. Naquele momento me senti aliviado, pois eu era um aluno com péssima reputação e se fosse alguém no qual eu tivesse tido algum problema no colégio, eu estaria ferrado.

Observando os rituais da chegada, os minutos que passavam me deixavam ansioso por começar. Era a espera por algo com proporções mágicas, pois finalmente após anos e anos indo mal no colégio, iria começar o meu primeiro dia de trabalho. A primeira tarefa oficial foi então passada: estudar o manual do sistema, uma apostila encadernada com espiral barato, que tinha mais que trezentas páginas. Eu olhei aquela apostila com muito carinho, até o momento em que a chefe foi embora. Depois, nunca mais abri uma página daquele manual. Além da apostila, recebi uma estação de trabalho, um computador com bloqueios de internet e acesso apenas aos sistemas necessários para trabalhar. Entre ler aquela apostila e vasculhar aquele computador bloqueado, ficou obvio a segunda opção. Eu vasculhei cada tela do sistema, tentando entender como ele era feito, o que as pessoas que estavam por trás pensaram no momento em que estavam construindo-o. Por fim, eu acabei tomando gosto por ler o que os clientes reportavam e tentar encontrar uma lógica para o comportamento que estava ocorrendo. Em poucas semanas, conhecia muita coisa, sem nunca ter lido uma linha do bendito manual. Minha sorte, pois uma das minhas avaliações de desempenho na época seria responder perguntas sobre o sistema.

Estava tudo tranquilo, eu sabia bastante sobre o sistema e chegava a surpreender, enquanto meu amigo se esforçava para trabalhar e achar coisas pra eu fazer. Eu me sentia muito feliz, apesar de não fazer nada muito útil naqueles primeiros dias. Tudo corria bem, até que em um determinado dia, daqueles em que tudo dá errado pra todo mundo, não sobrou outra alternativa a não ser o meu amigo me delegar uma das tarefas que não estava no meu escopo: ligar para um cliente. Eu lembro até hoje, o quanto eu tremi naquele instante em que ele me pediu isso. Eu me dava bem conversando com as pessoas, dada a minha habilidade conquistada após anos apresentando trabalhos na escola, mas ligar para alguém que eu não conhecia para falar sobre algo que eu não tinha certeza de que havia compreendido, era desesperador. O medo da minha mente me pregar uma peça, me fez imaginar milhares de situações embaraçosas. Aqueles minutos entre dizer que havia entendido e digitar os números para ligar, me fizeram ao final do dia, ter uma das piores dores de cabeça que me lembro de ter tido. Era algo totalmente novo, totalmente diferente de tudo que eu já havia feito na vida. Era assustador. Anos depois encontrei em um livro do Saramago algo que representa muito bem aquele momento que vivi:

“Autoritárias, paralisadas, circulares e às vezes elípticas, as frases de efeito, também jocosamente denominadas pedacinhos de ouro, são uma praga malígna, das piores que têm assolado o mundo. Dizemos aos confusos, Conhece-te a ti mesmo, como se conhecer-se a si mesmo não fosse a quinta e mais dificultosa operação das aritméticas humanas, dizemos aos abúlicos, Querer é poder, como se as realidades bestiais do mundo não se divertissem a inverter todos os dias a posição relativa dos verbos, dizemos aos indecisos, Começar pelo princípio, como se esse princípio fosse a ponta sempre visível de um fio mal enrolado que bastasse puxar e ir puxando até chegarmos à outra ponta, a do fim, e como se, entre a primeira e a segunda, tivéssemos tido nas mãos uma linha lisa e contínua em que não havia sido preciso desfazer nós, nem desenredar estrangulamentos, coisa impossível de acontecer na vida dos novelos e, se uma outra frase de efeito é permitida, nos novelos da vida. Marta disse ao pai, Comecemos pelo princípio, e parecia que só faltava um e outro se sentassem à bancada a modelar bonecos entre uns dedos subitamente ágeis e exactos, com a antiga habilidade recuperada de uma longa letargia. Puro engano de inocentes e desprevenidos, o princípio nunca foi a ponta nítida e precisa de uma linha, o princípio é um processo lentíssimo, demorado, que exige tempo e paciência para se perceber em que direcção quer ir, que tenteia o caminho como um cego, o princípio é só o princípio, o que fez vale tanto como nada.”

Hoje, depois de anos trabalhando e passando por diversas situações, sempre lembro do dia que tremi para fazer uma simples ligação telefônica, a primeira. Por mais simples e fácil que algo possa parecer ser, quando você o faz pela primeira vez, o desconforto é natural, para não falar do desespero. Por isso, sempre que pedir para alguém algo, lembre-se, pode ser a primeira vez que a pessoa fará aquilo e por mais trivial que seja, poderá marcar para sempre a vida dessa pessoa.

É engraçado que apesar da experiência traumática de ser um péssimo aluno, eu sempre adorei ir para aula. Eu estabelecia objetivos que nada tinham haver com notas, como ter pelo menos uma conversa com todas as pessoas da sala ao longo do ano. No ensino fundamental, eu procurava encontrar nas pessoas que eu ainda não conhecia, motivos que me fizessem sentir pesar por elas. Eu também tinha objetivos nada nobres, como atribuir codinomes no qual eu pudesse me referir a qualquer pessoa da sala sem que elas se identificassem, o que me atribuiu a fama de dar apelidos.

O meu desempenho sempre garantiu vagas certas nas salas de exame. A experiência de ter notas ruins ao longo do ano e ao final ter uma única prova para recuperar tudo traz aprendizados que poucas pessoas valorizam, como o fato dos alunos precisarem estudar por conta própria para relembrar ou até mesmo aprender os assuntos perdidos durante o ano. Outro aprendizado importante nessa experiência é o fato dos alunos que precisam passar nos exames terem que superar sua timidez e insegurança para pedir ajuda para outros alunos. Seja estudando com um amigo que passou direto ou estudando com um desconhecido que também está ferrado, o fato é que sem a humildade de reconhecer que precisa de ajuda, as coisas ficam mais difíceis.

Eu, apesar de sempre ir mal, tinha pavor de reprovar, o que significava estudar ao máximo e com total intensidade e dedicação as duas ou três semanas entre o fim das aulas e as provas de exame. Para alívio dos meus pais, sempre consegui me safar. É engraçado que quando somos jovens, uma reprovação em uma matéria represente uma tragédia. Lembro que todos meus amigos que reprovavam de ano tinham identificação bem evidente diante dos demais alunos que estavam no seu curso normal. Era como se tivessem sido marcados ou tivessem em uma casta inferior.

Em um determinado momento da minha adolescência, o meu desempenho era tão ruim e a minha proximidade com alunos que haviam reprovado várias vezes era tão grande, que a diretora do colégio que eu estudava chamou meu pai e o aconselhou a me trocar de colégio. Neste ano vivenciei a troca do colégio público pelo particular, o que de fato não mudou muita coisa, tanto no meu desempenho quanto nos meus objetivos não convencionais durante as aulas. Apesar das poucas mudanças, um dos alunos da nova turma se destacava muito em relação aos demais. Era um dos alunos mais inteligentes, um dos mais comunicativos e também um dos mais estabanados. O seu desempenho nas aulas era um dos melhores e por consequência, isso dava-lhe o direito de ter o ego inflado. Eu o achava inusitado, até o dia em que fomos escolhidos para trabalharmos no mesmo grupo. Apesar de todas as diferenças culturais vividas até aquele dia, ele como um dos melhores alunos, eu como um dos piores, uma revelação me deixou chocado: ele já havia reprovado de ano. Como poderia ele não ser reconhecido pelos demais como um aluno que havia reprovado? Por que ele não tinha nenhum sinal ou casta para identificá-lo?

Ao final, quando estava na faculdade, finalmente tive a minha primeira reprovação em uma matéria. Eu já trabalhava, tinha um desempenho acima da média pra minha idade, então reprovar naquela ocasião não mudou praticamente nada, a não ser a minha percepção sobre como somos treinados a vida inteira para ter o desempenho esperado por um modelo. Modelo este que acaba refletindo em todos os aspectos de nossas vidas: nas suas escolhas profissionais, nas suas escolhas religiosas, nas suas escolhas sobre estilo de vida. Eu acredito que seja importante ter bons desempenhos em modelos propostos, que nos dão uma orientação e que nos ensinam várias coisas, mas também é muito interessante não estigmatizar aqueles que não se encaixam ou se adequam nestes modelos, afinal, não é por que alguém teve notas baixas na escola, que essa pessoa será um desastre na vida.