Dev na Gringa: Processos Seletivos e Onde Estudar Para Eles
Tags: braziliandevs, career
Published: 2024-05-27 00:42:43

Originalmente postado no [Dev na Gringa Substack](https://open.substack.com/pub/devnagringa/p/dev-na-gringa-processos-seletivos?r=gb7rl&utm_campaign=post&utm_medium=web). Caso queira receber novos artigos no seu e-mail, increva-se!

---

Você encontrou a vaga, aplicou para uma vaga de dev na gringa, e foi chamado para a entrevista.

Chegou a hora de entender como você será avaliado.

Nesse artigo, vou mostrar os principais métodos usados no mercado internacional.

Não vou entrar em muitos detalhes individualmente. Pois o objetivo é dar uma visão ampla sobre os diferentes processos seletivos.

Vou compartilhar todos os recursos que eu utilizo quando estou me preparando.

Como vocês podem ver neste diagrama, todas as etapas são eliminatórias.

Sim, são muitos pontos que são sem volta.

Por isso, é importante estar bem preparado para cada uma delas.

Vou deixar algumas dicas específicas minhas também no final, que não encaixam em uma etapa específica. Baseadas em experiências anteriores.

Mais um último lembrete. Esse guia detalha todas as etapas que eu já fiz e tenho experiência. Porém, certamente existem empresas que possuem processos diferentes.

Inclusive, se você participou de um, peço que comente neste artigo! E assim podemos ter mais conhecimento difundido para todos também.

## 1. Conversa inicial com recrutador

Durante essa conversa, o recrutador irá te contar um pouco mais sobre a posição e o processo seletivo.

Se for um vaga de dev na gringa, sua comunicação já começa a ser avaliada nessa primeira conversa.

Ler um pouco sobre a empresa também é algo que faz maravilhas. Procure entender a situação que a empresa está. Se estão buscando crescimento. Diminuindo os gastos. Quais as últimas iniciativas que trabalharam.

Mostre um interesse genuíno.

Tenha algumas perguntas preparadas.

No final da entrevista, o recrutador irá perguntar se tem algo que você queira saber.

É uma ótima oportunidade de fazer perguntas de assuntos pertinentes para a sua posição.

Alguns exemplos:

- Você pode me contar um pouco mais sobre a cultura da empresa?
    
- Existem oportunidades para participar de conferências ou ter acesso à material educativo?
    
- Como está a diversidade na empresa?
    
- Tem algo específico que preciso me preparar para a próxima etapa?
    

Perguntar mostra que você tem um interesse genuíno na empresa. E também ajuda você a determinar se a empresa se encaixa naquilo que você está buscando.

## 2. ‌Entrevista técnica inicial ou _Phone Screen_

É uma conversa técnica, com duração de 45min até 1 hora.

Nessa entrevista, você irá fazer _pair_ com algum desenvolvedor.

Existe a possibilidade de você receber um problema grande, que dure a entrevista inteira. Ou até três perguntas menores.

Se você estiver aplicando para uma vaga de front, você deve focar nos domínios de HTML, CSS e JavaScript.

Também é possível ser um problema de algoritmos e estruturas de dados.

Recursos para aprofundar:

1. [GreatFrontEnd](https://devnagringa.substack.com/p/%5Bhttps://greatfrontend.com/%5D(https://greatfrontend.com/)): para entrevistas de vagas em front.

2. [NeetCode](https://devnagringa.substack.com/p/%5Bhttps://neetcode.io/%5D(https://neetcode.io/)): para algoritmos e estruturas de dados.

3. [LeetCode](https://devnagringa.substack.com/p/%5Bhttps://leetcode.com/%5D(https://leetcode.com/)): para problemas específicos das empresas que você está aplicando.

4. Livro: Cracking the Coding Interview por Gayle Laakmann McDowell.

## 3. Teste prático ou _Take Home Exercise_

Esse é o teste técnico que você faz em casa.

A empresa vai te dar um prazo e te enviar todos os requisitos do projeto.

Neste tipo de projeto, existem duas opções:

1. A empresa o pede com uma stack específica.

2. Você tem a liberdade de escolher a stack que preferir.

As dicas dependem um pouco do tipo de teste.

Caso seja uma stack específica, tenha certeza de estar atualizado com as práticas de mercado.

Por exemplo, se for uma aplicação React, opte por usar Nextjs ou Vite como o framework/ferramenta de _build_. TypeScript também é comum. Para testes, eu usaria Vitest/Jest, React Testing Library e Playwright.

Se você tiver a liberdade de escolha, faça escolhas sensatas. Use a ferramenta apropriada para o trabalho.

Por exemplo: se é um aplicação de AI/dados, Python é uma boa escolha. Para frontend web, o ecossistema JavaScript é o mais usado. Backend? Python, Node, Ruby, Go, várias opções.

O importante é que você saiba justificar todas as suas escolhas.

Algumas dicas de como se destacar nesta etapa:

1. Clarifique os requisitos e quaisquer dúvidas que você possa ter. Depois de ler a especificação, pergunte se tiver dúvidas. Não deixe a dúvida ficar para depois da entrega.

2. Dedique um tempo a documentação. Como rodar o seu app? Ele está hospedado em alguma infraestrutura? Que abordagens você usou para teste? Inclua esse tipo de informação no README.

3. Faça diagramas com a sua arquitetura. Seja da informação, dos fluxos de usuário, ou talvez do seu modelo de dados. Use o que precisar para que fique claro qual foi sua abordagem.

4. Se tiver tempo, faça entregáveis extras que possam impressionar o revisor. Exemplos: um app de frontend? Faça animações que façam o usuário experimentar algum sentimento novo. De backend? Explique como você faria a observabilidade do sistema. Surpreenda as pessoas.

## 4. Entrevistas onsite / _Onsite Interviews_

A última etapa antes da oferta é o que chamamos como dev na gringa de _onsite interview_.

Pode ser em um dia só, ou dividir em mais dias. Em especial quando são muitas etapas.

Elas podem ser uma variação dos vários tipos de entrevistas que vamos falar abaixo.

Se você quiser saber quais serão as etapas, recomendo você perguntar ao recrutador.

Quanto mais senior você é, menos ênfase tem as etapas de programação. A entrevista comportamental e de _system design_ passam a ter maior relevância.

### Algoritmos e estruturas de dados

Uma das fundações da computação são algoritmos e estruturas de dados.

Sim, são problemas que muitas vezes não são utilizados no nosso dia a dia.

Mas existe, sim, um motivo pelo qual empresas perguntam esse tipo de problema.

É um conhecimento que já está presente há **décadas**. E que continua sendo relevante até hoje.

Sim, pode ser que no dia a dia você não interaja diretamente com elas.

Mas elas estão, sim, presentes nos sistemas que utilizamos.

Pense nas redes sociais, que são usadas por bilhões de usuários diariamente.

A maneira eficiente de guardar os dados sobre conexões entre pessoas é um clássico exemplo da utilização de grafos.

Agora, vamos supor que você tenha um sistema distribuído. E você quer fazer o balanceamento de carga entre os vários nós do seu sistema. Quais algoritmos e estruturas vem ao caso aqui? Filas, _round-robin_ e _least-connections_ me vem a cabeça.

Então, pode ser que você não use essas estruturas no seu dia a dia.

Mas o conhecimento que elas trazem é algo que superou o teste do tempo.

Com isso a parte, vamos falar das dicas.

Problemas de algoritmos e estruturas de dados são sobre o reconhecimento de padrões.

Esses padrões vão ficam mais claros conforme você resolve mais problemas.

Então, quando você ver um problema novo, tente pensar em quais padrões podem ser aplicados a ele.

Vamos supor que você precise encontrar um caminho em algum tipo de rede ou grafo. Provavelmente será algum problema que será usado BFS ou DFS.

Ou que talvez você precise computar alguma _subarray_ ou _substring_. O padrão de _sliding window_ deve ser útil.

Lembre-se também de comunicar o seu raciocínio. Se tiver alguma dúvida, pergunte.

Também escreva alguns testes de caso que você possa executar no final do seu código. Procure pensar em potenciais _edge cases_ que podem vir a acontecer.

Recursos extras:

1. [NeetCode](https://devnagringa.substack.com/p/%5Bhttps://neetcode.io/%5D(https://neetcode.io/)): para algoritmos e estruturas de dados.

2. [LeetCode](https://devnagringa.substack.com/p/%5Bhttps://leetcode.com/%5D(https://leetcode.com/)): para problemas específicos das empresas que você está aplicando.

3. Livro: Cracking the Coding Interview por Gayle Laakmann McDowell.

Os recursos daqui são os mesmos que já falamos na entrevista técnica.

### _Pair Programming_

É um tipo de entrevista que tenta simular como você trabalharia com alguém no dia a dia do trabalho.

A lição mais importante aqui é a comunicação. Mostre que você é alguém que se preocupa com o código que está escrevendo. Em particular sobre como a pessoa que irá ler ele depois.

Lembre-se que código é muito mais lido do que ele é escrito.

Eu sinto que eu repito isso em basicamente todas as entrevistas.

Mas, sério, a comunicação aqui é muito importante. Assim como em todas as outras etapas. 😅

Especialmente se for uma vaga de dev na gringa. Tudo fica um pouco mais difícil quando você se comunica com uma língua diferente.

Por isso, a minha dica é respirar fundo sempre que você estiver se sentindo confuso.

Diga que você precisa pensar um pouco, se precisar. Mas, se possível, pense alto. Deixe que o seu entrevistador entenda o seu raciocínio.

Tome cuidado para não falar muito rápido. Essa é uma dificuldade minha até hoje, que venho tentado melhorar.

Mas, às vezes, quando fico nervoso, começo a acelerar e falar rápido. E, devido ao meu sotaque, pode ser que meu inglês fique difícil de entender.

Por isso, recomendo sempre estar atento a sua respiração. De modo que você não esteja correndo com o que você fala.

Recursos que podem ajudar:

1. Faça _side projects_. Se você gostar de programar no seu tempo livre, acho que essa é uma das melhores maneiras de aprender.

2. [GreatFrontEnd](https://devnagringa.substack.com/p/%5Bhttps://greatfrontend.com/%5D(https://greatfrontend.com/)): mencionando o GFE de novo. Acho que é uma ótima plataforma para praticar problemas de front.

3. Pratique com um amigo! Se tiver alguém que está praticando para entrevistas também, acho que é uma ótima lição.

### Projeto de Sistema / _System Design_

Essas entrevistas são as minhas favoritas.

É uma etapa que é altamente relevante pra qualquer engenheiro de software. Dev na gringa ou no Brasil mesmo.

Mostra a sua capacidade de projetar um sistema. Analisar quais serão o seu gargalo. Avaliar diferentes arquiteturas para se resolver um problema.

Eu gosto de pensar nessa entrevista como uma jornada.

Uma jornada onde o seu objetivo final é chegar a uma solução. Que será feita de maneira colaborativa com o seu entrevistador.

Aqui muitas vezes não existe uma resposta correta. Uma das principais razões pelo qual desenvolver software é difícil é porque não existe uma solução que resolva tudo.

É tudo sobre os _trade-offs_.

Para qualquer problema técnico complexo, sempre haverão diversas soluções.

O que é importante é que você saiba discutir as diferentes abordagens possíveis.

Tenha certeza de clarificar todos os requisitos do projeto. Funcionais e não-funcionais.

Trabalhe com o seu entrevistador para entender o escopo do projeto. Essa é uma entrevista com tempo limitado.

Muitas vezes o seu entrevistador quer ver o seu foco em uma parte específica do sistema.

Existem cinco princípios para um projeto de software que você deve estar atento:

1. Robustez

2. Escalabilidade

3. Performance

4. Extensibilidade

5. Resiliência

Quando você faz um sistema, essas são as principais áreas onde você pode encontrar problemas. Veja como o seu design se comporta em cada uma delas.

Recursos para consulta:

1. Livros: System Design Interview 1, 2 por Alex Xu, Sahn Lam. Designing Data-Intensive Applications por Martin Kleppmann.

2. Blogs de engenharia de empresas.

3. Canal do YouTube [ByteByteGo](https://devnagringa.substack.com/p/%5Bhttps://www.youtube.com/@ByteByteGo/videos%5D(https://www.youtube.com/@ByteByteGo/videos)).

### Entrevista de Valores e Comportamental

Junto com a entrevista de _system design_, essa também é uma das minhas etapas favoritas.

Pois é uma etapa onde você também tem a chance de entrevistar a empresa que você está pensando em trabalhar.

Venha com perguntas preparadas.

Em especial se for sua primeira entrevista como dev na gringa. Você pode ter dúvidas quanto a cultura, que talvez seja diferente de como é a sua empresa no Brasil.

Essa é uma oportunidade de você também se exibir. Falar sobre suas vitórias passadas. Sobre como você conseguiu influenciar seu time de uma maneira positiva.

Porém, algo que é importante lembrar é que raramente existem vitórias de **sucesso absoluto.** Muitas vezes, o sucesso é atingido com algumas falhas e deslizes no caminho.

Fale sobre estes deslizes. Deixe que o seu entrevistador veja que isso é um caso real. Infelizmente, não temos muitos conto de fadas no mundo da engenharia de software. Resolvemos problemas, mas também pensamos em o que poderíamos fazer diferente.

Traga essa perspectiva para o seu entrevistador. Deixe que ela veja sobre como você reflete sobre o seu passado.

Recursos:

1. Canal no Youtube [A Life Engineered](https://devnagringa.substack.com/p/%5Bhttps://www.youtube.com/@ALifeEngineered%5D(https://www.youtube.com/@ALifeEngineered)).

2. [Tech Interview Handbook](https://devnagringa.substack.com/p/%5Bhttps://www.techinterviewhandbook.org/behavioral-interview/%5D(https://www.techinterviewhandbook.org/behavioral-interview/)).

3. O método STAR. Use ele como um framework de como moldar as suas histórias.

## 5. Oferta

Parabéns por ter chegado até aqui! 🎉 🎉 🎉

Sim, a oferta é a etapa final! Mas ainda existem algumas coisas que podemos fazer aqui para deixar melhor.

Este artigo já está ficando grande, então vou falar a mensagem principal: **negocie o seu salário**.

Existem três mitos quanto à negociação:

1. "Minha oferta será cancelada se eu tentar negociar"

2. "Negociação faz com que eu pareça mesquinho"

3. "Alguém vai ganhar menos dinheiro se eu ganhar mais"

Nenhuma dessas frases é verdade.

Você não perde nada por negociar o seu salário.

Em algumas vezes, pode até ganhar. Por você mostrar o valor que você realmente acha que pode agregar a empresa.

[Aqui existe um bom resumo](https://www.techinterviewhandbook.org/negotiation-rules/) sobre as principais regras de negociação salarial.

## Considerações finais

Não leve o processo de entrevistas tão a sério.

É normal ser rejeitado. Não quer dizer que você é um engenheiro ruim. Ou que você nunca irá conseguir se tornar um dev na gringa.

Trate os processos seletivos como uma oportunidade de conversar com pessoas novas.

Se mostre interessado nos problemas delas. Compartilhe de experiências suas que você acha que podem ser relevantes.

Aprenda novas tecnologias no caminho. Descubra casos novos de engenharia que você não conhecia. Diferentes domínios tem diferentes desafios técnicos.

Tenha um interesse genuíno na empresa. **Ouça ativamente** o que seus entrevistadores te contam. O que os preocupa, e aquilo que os motiva.

Pratique a empatia. Se coloque no lugar deles, e procure entender o que eles estão procurando.

**Trate todo este processo como apenas uma** _**quest**_ **no enorme RPG que é a vida. Mesmo se ela der recompensas, ou falhar, você irá ganhar experiência da mesma forma.**