A minha pior entrevista

Todos nós sabemos que o processo de entrevista é sempre difícil: ambiente de estresse, perguntas difíceis, fazer e explicar código para outras pessoas, e às vezes em outra língua?! Sabemos, é hard.

Mas hoje eu não queria falar sobre técnicas somente, tipo “utilize o método STAR/xyz e blá”, não, eu quero falar sobre como essa entrevista me ensinou.

O contexto

Ao longo deste ano de 2025 eu vinha flertando com Go, e decidi dar uma chance real. Estudei bastante, fiz projetos e tudo mais, aí decidi apenas entrar em um processo de Go para validar meu nível até ali, e foi o melhor dos cenários: 7 dias para estudo, uma breve descrição de como seria a minha entrevista técnica, porém sem muitos detalhes.

Era o cenário perfeito! Eu organizei meu estudo em tópicos, peguei exercícios mais pedidos em Go, por exemplo, algoritmos e LeetCode, como criar uma micro-lib de cache com thread safe, como utilizar go-routines, channels e afins. Também estudei a base da linguagem, coisa que nem na minha linguagem principal eu fiz em 10 anos! eu sei, tenho que ter vergonha na cara haha

Eu achei que estava tranquilo, foquei muito na linguagem, estava até um pouco confiante para ser sincero.

A entrevista

Aí chegou o momento da entrevista, eram dois rapazes. Logo de cara já comecei com um papinho bad vibes: “Bom dia, tudo bem? Blábla, desculpe que estou nervoso!” Olha, as palavras têm poder, e elas podem te salvar ou te derrubar rsrs.

Papo vai, papo vem, perguntando aquelas coisas que já estavam decoradas: maior desafio, projetos que mais me orgulhava, o que eu gostava de fazer e por aí vai. Até o momento estava ótimo!

Logo chegou o momento que um dos rapazes perguntou: “Bora pro código?” A tarefa de início era simples: criar uma API em Go, e dado uma interface que eles deram, aplicar uma função para trazer dados de um Elasticsearch. Uma espécie de proxy, nada de grande coisa.

O momento da verdade

Aqui, neste exato momento eles disseram: “Leia com calma, leve o tempo que precisar, estaremos aqui para responder suas perguntas sobre isso”.

E sabe o que eu fiz? Perguntei, mas eu não fiz perguntas honestas. Eu só fiz mais ou menos “ah então é pra fazer isso, e isso né?”, eles confirmaram e pronto, comecei. E neste momento acabou a entrevista.

Eu estava tão preocupado de aplicar padrões, estrutura de pastas seguindo os padrões da comunidade, tudo ao mesmo tempo falando sobre tudo aqui o TDH bateu forma rs, falando uma coisa e escrevendo outra. Chegou um momento onde eu tinha 10 pastas e só um main.go.

Aí um dos entrevistadores me interrompeu, até brincou que geralmente ele fazia o papel de policial mau, mas que ele queria conversar comigo. Ele me perguntou por que eu não estava falando com eles.

POR DEUS!!! O BÁSICO!!!

O que eu errei

Eu estava tão focado para mostrar que eu sabia o suficiente de Go, que nem perguntei de verdade. Eu assumi muitas coisas, e isso, por mais que eu soubesse de tudo que eu estava fazendo, por mais que verbalizasse o que eu queria fazer pudesse ser uma ótima ideia, o problema é que eu não compartilhei com eles isso. Apenas fui fazendo, digitando, digitando e digitando.

Sabemos que a vida real não funciona assim: você conversa com as pessoas, faz alinhamentos, valida se você está indo na direção certa, recebe feedbacks.

E claro, a entrevista acabou mais rápido do que o previsto após esse feedback e eu bombei!

A reflexão

Foi ótimo, eu nunca tinha tido uma entrevista tão ruim! Eu já tive entrevistas onde travei na hora que estava falando inglês, já tive experiências de não terminar código, não saber resolver algoritmo e etc, mas essa foi a que mais doeu, porque foi no básico.

A minha afobação e vontade de mostrar acabou externalizando um problema. Às vezes a gente não quer conversar, a gente só quer ter o nosso turno da conversa, e isso é horrível!

Em uma entrevista, você tem que entender que isso não pode acontecer. Também não estou dizendo que tem que perguntar sobre tudo né? É importante ter um equilíbrio.

As lições que aprendi

Pensando neste tipo de entrevista de live coding, algumas dicas que eu passo são:

Primeiro de tudo: pegue um papel, ou compartilhe a tela e abra um txt.

1. Tempo para anotações

Peça um tempo sozinho somente para fazer anotações e questionamentos, apenas pra sumarizar a proposta.

2. Valide suas dúvidas com o entrevistador

Agora, pense que o entrevistador neste momento é seu amigo, ele não quer te lascar. Então leia suas dúvidas em voz alta, compartilhe suas anotações com ele. Ele quer ser inserido de verdade no processo.

Um erro aqui é pensar que um live coding é sair programando. Pense nisso como design system interview.

Exemplo: “Então, eu fiz minhas anotações aqui, e eu queria ir validando elas com você para saber se estou no caminho certo, pode ser?”

3. Levante cenários e possíveis problemas

Coloque alguns casos e talvez possíveis problemas que você vê como dúvida, e valide se isso deve ser levado em consideração.

Exemplo: “Eu tenho que construir uma API, mas eu tenho que me preocupar neste momento com camadas de segurança tipo cache, rate-limit, api-keys?”

Ele vai te dizer geralmente quais coisas são boas ou ruins. É bom ter um feeling aqui, mas se ele deu um foco em algum assunto, vá junto com ele. Ele talvez está querendo saber o nível de profundidade do seu conhecimento. Feeling é sempre importante.

4. Confirme o escopo completo

Após anotações, correções e validações feitas, confirme os requisitos mínimos (DE NOVO). Separe em uma seção diferente o que é Bonus.

Agora a chave: pense que você vai pedir para alguma IA construir isso para você, mas você só tem uma única frase. Crie essa frase e leia ela novamente, peça para o entrevistador validar todo o escopo. Sim, adicione na sua frase aquilo que é bonus.

Exemplo:

“Ok, só para confirmar o entendimento do problema, então a ideia aqui é criar uma API para fazer X, e nessa API as regras são ‘caso idade > que 20’ então J senão K, e como bonus os pontos a se considerar nessa solução são cache, logs e testes, entendi correto?”

Isso vai te dar uma segurança e um guia de como fazer e onde focar primeiro, e vai ganhar muitos pontos, confia!

5. Organize em passos incrementais

Perfeito, agora com tudo que você precisa ter, pense até nos bonus, e tente organizar isso em passos sequenciais e incrementais, mas sempre focando no requisito mínimo! Não esqueça: anote essa sequência também, vai ser bom pra você como uma forma de check-list.

Exemplo prático de checklist:

1. Ter uma API onde GET /user?name=john retorne o JSON abaixo:

   {
     "id": 1,
     "name": "john",
     "role": "admin"
   }
   

2. Regras da API:

• Query param name:
  • não pode ser vazio
  • não pode ser menor que 3 caracteres
  • não pode ser maior que 10 caracteres
• não pode receber outros parâmetros

6. Escolha sua abordagem: Test-first vs Code-first

Aqui podemos ter 2 abordagens: test-first ou code-first. Você tem que lembrar que você está sendo avaliado, e quanto tempo tem. Se você tem tempo sobrando e está tranquilo, vá de test-first.

6.1. Utilizando test-first

Aqui você demonstra senioridade, muito lindo, top! Mas não caia na armadilha de fazer todos os testes tudo de uma vez. Seus testes devem evoluir com seu código. Não estou falando de TDD, lembre que você tem que demonstrar como você trabalha apenas.

Dica: Crie apenas um teste para bater na sua API trazendo 200, e criando 1 arquivo principal com o servidor, rota, resposta mocada tudo junto. Explique que você está apenas estruturando o código, e que isso não ficará assim, e que você só quer garantir este primeiro cenário básico. Conforme você for evoluindo seu código, você vai sentir que precisa de novas camadas.

6.2. Utilizando code-first

Digamos que você está sem tempo, então você vai no code-first. Deixe claro para o entrevistador o seu sentimento, diga que você sabe da importância dos testes, mas que não está seguro de implementar eles com o tempo disponível. Isso pode te custar alguns pontos, mas melhor algum ponto do que falar que não conhece ou não fazer código nenhum né? 🤡

E aqui a ideia é a mesma: comece fácil. As camadas, os ports/adapters, tudo irá vir naturalmente quando você implementar aquele seu checklist.

6.3. Padrões de código

Aqui sempre é bom você ir implementando sempre que possível bons padrões de código. Me refiro ao SOLID. Se for pra lembrar de algum nessa hora, lembra só da parte de injeção de dependência. Se você estiver no test-first já vai vir natural; se não, só cita que com isso você desacopla o servidor do seu service/use-case e afins, só pra demonstrar que você sabe como fazer.

Conclusão

E pra concluir, quero dizer que antes de tudo, entrevistas são sempre difíceis e mesmo sabendo dessas coisas eu mesmo assim errei 🫠. Eu nunca tinha tido uma entrevista tão marcante haha.

E não se sinta mal também por uma entrevista ruim que você fez. Eu fiquei tanto destruído que cheguei a um ponto de escrever isso aqui, sobrevivi e ainda aprendi mais coisas. É sempre win-win no final! O importante é não desistir e entender onde foi que você errou.

Se possível, tenta sempre ter aquele “caderninho da vergonha” - ele é útil para te fazer lembrar dessas coisas a cada entrevista. Ou você ganha a vaga ou lança ele como livro, viu? É sempre win-win no final 😜