Iniciante escreveu um bot em Go para entrevistas: voz, 860 perguntas e 25–35 MB de memória

Situação conhecida: você leu uma dezena de artigos sobre o runtime do Go, tem na cabeça uma confusão de slices, escalonador GMP e escape analysis, e na entrevista a língua trava. O autor deste projeto trabalha de dia numa oficina mecânica e à noite estuda backend. Resolveu o problema com código: escreveu um bot para Telegram que faz perguntas técnicas, ouve respostas por voz e as avalia sem fazer concessões.

Por que voz e por que não Whisper

A ideia do projeto é que, numa entrevista, ninguém pede uma redação: é preciso falar. Por isso o bot aceita justamente mensagens de voz. A primeira tentativa, com o Whisper local, fracassou: num VPS barato sem placa de vídeo, cada mensagem de áudio levava o processador a 100%.

O autor migrou para o Deepgram na nuvem, com o modelo Nova-2. Uma mensagem de voz do Telegram em formato OGG/Opus é processada em menos de um segundo. O jargão de TI em russo, como «goroutines», «mutex» ou «generics», não vira uma bagunça, o que é crítico para um bot desse tipo. A conclusão prática é simples: se você não tem GPU e o projeto é pequeno, hospedar o reconhecimento de voz por conta própria costuma sair mais caro que uma API pronta, contando tempo e paciência.

Como impedir o modelo de concordar com tudo

O grande problema dos avaliadores baseados em LLM é a bajulação. Pergunte «o que achou da minha resposta?» e quase certamente ouvirá «parabéns, excelente!», mesmo que a resposta tenha sido fraca. O autor montou uma base de 860 perguntas em 85 temas e adicionou a cada uma critérios de referência, os key_points. O prompt obriga o DeepSeek (que roda via API do Groq Cloud) a percorrer a lista: verificar cada critério, dar uma nota de 1 a 10, enumerar o que faltou e fazer uma análise curta e dura, sem elogios.

Exemplo do projeto. O candidato diz: «o slice dobra de tamanho quando estoura». Mas não mencionou o limite de 256 elementos nem a nova fórmula do Go 1.18+. Sem o checklist, o modelo facilmente aceitaria essa resposta. Com o checklist, ele aponta exatamente o que faltou.

A técnica é universal. Não peça ao modelo para «avaliar»; dê a ele uma rubrica com itens obrigatórios. O mesmo funciona para a verificação automática de code review, respostas de suporte ou testes técnicos.

Repetição, entrevista simulada e armadilhas

Decorar perguntas em sequência é inútil, então o autor adicionou repetição espaçada. Para cada usuário, o Redis monta uma fila para a sessão. Uma resposta com nota de 8 a 10 manda a pergunta para o fim da fila. Se a nota for menor que 6, a pergunta volta já em poucos passos. Todas as tentativas são gravadas no PostgreSQL, e as estatísticas são construídas a partir delas. Há também um modo de simulação de entrevista: você escolhe o nível, de estagiário a sênior, recebe 10 perguntas com esclarecimentos ao longo do caminho e um veredicto final, Hire ou No Hire, com análise dos erros.

As armadilhas foram típicas de qualquer bot para Telegram:

• Marcação HTML. Se o modelo devolveu código sem crases ou perdeu a tag de fechamento, o Telegram rejeita a mensagem. O autor escreveu um sanitizador: ele encontra código Go por palavras-chave (package, func, :=) e o envolve sozinho em pre/code com escape.
• Cliques duplos. Um toque rápido num botão inline gera dois callbacks seguidos, e no Redis surgia uma condição de corrida com duas sessões paralelas. A solução é desativar os botões via EditReplyMarkup antes das consultas pesadas ao banco.
• Segurança do deploy. Os contêineres não rodam como root, mas como um usuário separado, appuser. No docker-compose.prod.yml estão habilitados read_only: true e cap_drop: ALL, e as pastas do sistema foram movidas para tmpfs.

O que vale levar daqui

A stack é: Go 1.23, telebot.v3, PostgreSQL 16 via pgx/v5, Redis 7, Docker Compose, com estrutura em Clean Architecture. Segundo o autor, em produção o bot consome 25–35 MB de memória, inicia em frações de segundo e roda num servidor de 200 rublos por mês. Para um serviço leve, que basicamente consome APIs externas, é um bom argumento a favor do Go.

Há também limitações. É um projeto pessoal de um iniciante, e o próprio autor pede que desenvolvedores experientes revisem o código e a arquitetura. Não há dados sobre o quanto as notas do modelo coincidem com as de um entrevistador humano. Também não são apresentadas métricas de qualidade do reconhecimento e da análise, então a «rigidez» só pode ser julgada pela descrição do prompt.

Mas, como conjunto de soluções prontas, o texto é útil. Para voz, use reconhecimento na nuvem se não tiver GPU. Para uma avaliação honesta de um LLM, dê a ele um checklist em vez de pedir uma opinião. Para um bot de Telegram, proteja-se de antemão contra cliques duplos e marcação HTML quebrada. O código-fonte é aberto: github.com/powood/Tg_GO_Mentor, e o bot está disponível como @go_SikkiMentor_bot.