Como se Preparar para Entrevista de Desenvolvedor de Jogos

Entrevista de desenvolvedor de jogos não é prova de faculdade. Ninguém vai te pedir pra recitar a definição de quaternion de cor. O que o estúdio quer descobrir, em uma ou duas horas de conversa, é se você consegue construir coisas que funcionam, se sabe explicar as decisões que tomou e se dá pra trabalhar com você sem atrito. Esses três pontos guiam praticamente tudo que acontece no processo.

Eu já estive dos dois lados da mesa: como candidato no começo da carreira e como quem contrata no Studio Married Games. Esse artigo é o que eu gostaria que alguém tivesse me contado antes da minha primeira entrevista, dividido nas três frentes que decidem o resultado: o teste técnico, as perguntas da conversa e a apresentação dos seus projetos.

Como funciona o processo seletivo em estúdios de jogos

O formato varia com o tamanho da empresa, mas o esqueleto costuma ser parecido:

1. Triagem de currículo e portfólio. Aqui o portfólio pesa mais que o currículo. Um link de jogo jogável vale mais que três parágrafos de descrição de cargo.
2. Conversa inicial. Geralmente com alguém de recrutamento ou com o lead. Serve pra alinhar expectativa de cargo, senioridade e remuneração.
3. Teste técnico. Um desafio pra fazer em casa (o mais comum no Brasil) ou uma sessão de código ao vivo.
4. Entrevista técnica. Conversa sobre o teste, sobre seus projetos e sobre fundamentos.
5. Entrevista final. Cultura, time, alinhamento. Em estúdio pequeno, essa etapa se mistura com a anterior.

Estúdios menores cortam etapas. Já vi processo inteiro resolvido em uma call de uma hora mais um teste de fim de semana. O importante é saber o que cada etapa avalia, porque a preparação de cada uma é diferente.

O teste técnico: o que avaliam de verdade

O teste técnico típico é algo como "faça um mini jogo de plataforma com inimigo e coleta de itens em uma semana" ou "implemente um sistema de inventário com essa especificação". E aqui vai o ponto que mais derruba candidato: o avaliador quase nunca está procurando o jogo mais bonito. Ele está lendo seu código.

O que eu olho quando avalio um teste, em ordem de peso:

Funciona? Parece óbvio, mas uma parcela grande dos testes chega com bug que impede de jogar, sem instrução de build ou com a cena errada como principal. Antes de entregar, baixe seu próprio zip em outra pasta, abra do zero e jogue. Se você usa Godot, confira se a cena principal está configurada no projeto.

O código é legível? Nome de variável que diz o que ela é, função curta que faz uma coisa, zero código morto comentado. Quem vai ler seu teste lê código o dia inteiro e identifica desorganização em segundos.

As decisões fazem sentido? Usar a ferramenta certa pro problema conta muito. Um exemplo concreto: se o teste pede inimigos com comportamento de patrulha e perseguição, uma máquina de estados simples mostra maturidade. Não precisa de framework, precisa de clareza:

extends CharacterBody2D

enum State { PATROL, CHASE }

const PATROL_SPEED = 60.0
const CHASE_SPEED = 120.0

var state: State = State.PATROL
var player: Node2D = null

func _physics_process(delta):
    match state:
        State.PATROL:
            patrol(delta)
        State.CHASE:
            chase(delta)
    move_and_slide()

func patrol(delta):
    velocity.x = PATROL_SPEED * patrol_direction()

func chase(delta):
    var dir = sign(player.global_position.x - global_position.x)
    velocity.x = CHASE_SPEED * dir

func _on_detection_area_body_entered(body):
    if body.is_in_group("player"):
        player = body
        state = State.CHASE

func patrol_direction() -> float:
    # Inverte ao chegar na borda da plataforma ou bater na parede.
    return -1.0 if is_on_wall() else 1.0

Esse código não é sofisticado, e é exatamente esse o ponto. Ele é fácil de ler, fácil de estender com um terceiro estado, e quem avalia entende a estrutura em trinta segundos. Em teste técnico, simples e claro ganha de esperto e ilegível, sempre.

Escopo respeitado. Se o teste pede três funcionalidades, entregue as três funcionando antes de pensar em adicionar uma quarta. Entregar metade do pedido mais um sistema de partículas bonito sinaliza que você não sabe priorizar, e priorização é metade do trabalho em produção de jogo.

Uma dica que poucos seguem: entregue um README curto explicando suas decisões. Três parágrafos dizendo "usei máquina de estados pelos motivos X, deixei Y de fora por falta de tempo e faria Z diferente com mais prazo" mostram autoconsciência técnica. Isso diferencia candidato no mesmo nível de código.

Perguntas comuns em entrevista de desenvolvedor de jogos

A entrevista técnica costuma misturar fundamentos, experiência prática e raciocínio. Perguntas que aparecem com frequência, com o que está sendo testado em cada uma:

"Qual a diferença entre atualizar lógica no loop de render e no loop de física?" No Godot, é a diferença entre _process e _physics_process. Na Unity, entre Update e FixedUpdate. Testa se você entende que movimento e física precisam de passo fixo pra serem consistentes entre máquinas. É pergunta de eliminação: errar essa em vaga de gameplay pesa muito.

"Me conta um bug difícil que você resolveu." Talvez a pergunta mais importante da entrevista inteira. Não testa o bug, testa seu processo: como você isolou o problema, que hipóteses levantou, como confirmou a causa. Prepare uma história real com começo, meio e fim antes da entrevista. "Não lembro de nenhum" é a pior resposta possível, porque sugere que você nunca debugou nada sério.

"Como você otimizaria um jogo que está rodando lento?" A resposta que querem ouvir começa com "primeiro eu mediria com o profiler". Quem sai listando otimizações antes de falar em medir está chutando, e otimizar no chute é como o time perde semanas.

"Por que você quer trabalhar com jogos?" Parece pergunta de RH, mas em estúdio ela filtra algo concreto: a pessoa entende que desenvolver jogos é diferente de jogar jogos? Resposta boa fala do que você gosta de construir, não só do que gosta de consumir.

Perguntas de design de sistema. Em vagas de nível pleno pra cima: "como você estruturaria um sistema de save?", "como faria um inventário que aguenta itens empilháveis e equipamento?". Não existe resposta única certa. O avaliador quer ver você quebrar o problema em partes, apontar trade-offs e fazer perguntas de esclarecimento. Aliás, fazer pergunta antes de responder ("esse save precisa funcionar em console também?") já é metade da resposta certa.

E uma orientação geral: quando não souber, diga que não sabe e raciocine em voz alta a partir do que sabe. Inventar resposta técnica em entrevista é tiro no pé, porque o entrevistador domina o assunto e percebe na hora.

Como mostrar seus projetos

Portfólio em desenvolvimento de jogos não é lista de coisas que você fez. É evidência de que você termina o que começa e entende o que construiu.

Jogo publicado vale mais que protótipo, e protótipo jogável vale mais que vídeo. Um jogo no itch.io que a pessoa clica e joga em trinta segundos é o melhor formato possível. Não precisa ser grande: um jogo pequeno e polido impressiona mais que um projeto ambicioso pela metade.

Dois ou três projetos bons batem dez medianos. Quem avalia portfólio gasta poucos minutos nele. Coloque na frente o que tem mais qualidade e corte o resto sem dó, incluindo aquele primeiro projeto de tutorial que todo mundo tem.

Prepare a narrativa de cada projeto. Na entrevista, vão pedir pra você falar sobre eles. Pra cada projeto, tenha na ponta da língua: qual era o objetivo, qual foi a parte tecnicamente mais difícil, o que você faria diferente hoje. Essa terceira resposta é a que mais revela senioridade, porque exige olhar crítico sobre o próprio trabalho.

Código no GitHub: limpe antes de mostrar. Se o repositório está no portfólio, ele vai ser aberto. README com gif do jogo, instrução de como rodar e estrutura de pastas organizada. Repositório com teste_final_v2_AGORA_VAI.gd na raiz conta uma história, e não é boa.

Game jams contam, e muito. Projeto de jam mostra exatamente o que estúdio quer ver: escopo fechado, prazo cumprido, jogo entregue. Se você ainda não tem portfólio, participar de duas ou três jams é o caminho mais rápido pra construir um com material honesto.

A preparação na semana da entrevista

Um roteiro objetivo pro que fazer quando a entrevista já está marcada:

1. Estude o estúdio. Jogue ou pelo menos assista gameplay dos jogos deles. Saber em que engine trabalham e em que gênero atuam muda completamente a conversa, e perguntar "que jogos vocês fazem?" na entrevista queima o candidato.
2. Releia a vaga e mapeie seus exemplos. Pra cada requisito da descrição, separe uma experiência sua que comprove. Vaga pede multiplayer? Tenha sua história com networking pronta, mesmo que seja de projeto pessoal.
3. Revise os fundamentos da sua área. Gameplay: loop de física, colisão, máquina de estados. Gráficos: pipeline de render, shaders. UI: anchors, resoluções, acessibilidade. Não dá pra revisar tudo, então revise o que a vaga pede.
4. Ensaie suas três histórias. Um bug difícil, um projeto do qual se orgulha, um conflito ou erro do qual aprendeu. Em voz alta, de preferência. A diferença entre ter a história na cabeça e conseguir contá-la bem é maior do que parece.
5. Prepare suas perguntas. "Como é o pipeline de vocês da ideia até a build?", "como o time lida com crunch perto de entrega?". Entrevista é via de mão dupla, e candidato que pergunta bem demonstra critério. Inclusive, a resposta sobre crunch te diz muito sobre onde você está se metendo.

Conclusão

Entrevista de desenvolvedor de jogos se resolve com o mesmo método que qualquer problema de desenvolvimento: entender o que está sendo avaliado e preparar pra isso, não pra um ideal genérico. Teste técnico avalia clareza e escopo, a conversa avalia raciocínio e comunicação, o portfólio avalia capacidade de entrega.

Se você está começando agora, a melhor preparação não é decorar resposta: é terminar um jogo pequeno, publicar, e repetir. Cada projeto terminado te dá código pra mostrar, história pra contar e segurança pra conversar de igual pra igual. E é exatamente isso que decide entrevista.