Simulação Comportamental

GOK | Inovação Digital — Pessoa Desenvolvedora Android Sênior

Como usar este material: Cada pergunta traz o que o entrevistador realmente avalia, os erros que eliminam candidatos e uma chave de resposta estruturada. Leia com atenção e pratique em voz alta — não para memorizar, mas para internalizar a estrutura.

Visão Geral das Perguntas

#	Pergunta	Nível
1	Trajetória e interesse na GOK	Aquecimento
2	Refatoração em produção sem interrupção	Intermediária
3	Trade-off entre velocidade e qualidade	Intermediária
4	Decisão arquitetural que faria diferente	Difícil
5	Plano de ação em código legado crítico	Difícil
6	Vulnerabilidade de segurança às vésperas de release	Difícil
7	Code review com desenvolvedor mais sênior	Difícil
8	Discordância técnica com decisão mantida	Difícil

Pergunta 1 — Aquecimento

“Me conta um pouco sobre sua trajetória técnica e o que te trouxe até aqui. Por que você está interessado nessa posição na GOK?”

O que o entrevistador avalia

Narrativa profissional coesa. Capacidade de conectar trajetória e vaga de forma natural — sem parecer decorado. Também serve como calibração inicial de autoconsciência e posicionamento.

Erros que eliminam candidatos

❌ Recitar o currículo em ordem cronológica sem filtrar o que importa para esta vaga
❌ Usar “estou procurando novos desafios” como motivação principal — é genérico e evasivo
❌ Não mencionar os contextos financeiros críticos que são o fio condutor da trajetória
❌ Falar mais de 4 minutos sem ser perguntado algo específico
❌ Não fazer nenhuma conexão entre experiência própria e o que a GOK faz

Sinais de uma resposta forte

✅ Estrutura clara: de onde veio → o que construiu → por que a GOK faz sentido agora
✅ Citar naturalmente os contextos críticos (Monnos, Banco Inter, Banco Master) como parte da identidade técnica
✅ Demonstrar que pesquisou a GOK — mencionar algo específico sobre o tipo de projeto ou contexto da empresa
✅ Finalizar com uma pergunta ou observação que abre diálogo

Chave de Resposta

A resposta ideal dura entre 2 e 3 minutos e segue uma estrutura de três atos.

Ato 1 — Âncora: onde está a identidade técnica

“Minha trajetória é quase inteiramente em Android com foco em ambientes financeiros críticos. Fui Head Android no Monnos Crypto Bank por quase cinco anos, onde conduzi as principais decisões arquiteturais do app — desde a escolha de stack até refatorações em produção sem interrupção de serviço. Depois disso, trabalhei em dois SDKs: um de pagamentos para o Banco Inter e um de segurança mobile para o Banco Master, envolvendo proteção contra engenharia reversa e criptografia de dados sensíveis.”

Ato 2 — Contexto atual: por que a mudança faz sentido

“O que me motiva agora é um ambiente onde eu possa continuar operando com essa profundidade técnica, mas com mais variedade de contextos e desafios. Gosto de lugares onde qualidade de engenharia é levada a sério — não apenas entrega de features.”

Ato 3 — Conexão com a GOK: por que esta empresa, não qualquer outra

“A GOK me chamou atenção por atuar em projetos de alta criticidade transacional com exigência real de performance e segurança. Esse é exatamente o ambiente em que trabalho melhor.”

Pergunta 2 — Intermediária

“Me conte sobre uma situação em que você precisou conduzir uma refatoração técnica significativa em um sistema que estava em produção, sem poder parar o serviço. Como você planejou, executou e garantiu que nada quebraria?”

O que o entrevistador avalia

Maturidade técnica real em ambientes de produção. Capacidade de planejamento incremental, gestão de risco e ownership sobre decisões com consequência direta ao usuário final. A GOK opera em ambientes onde falha não é aceitável.

Erros que eliminam candidatos

❌ Descrever uma refatoração feita em ambiente de desenvolvimento ou sem usuários reais
❌ Não mencionar estratégia de rollback ou plano de contingência
❌ Apresentar a solução como individual, ignorando a coordenação com time e backend
❌ Ser vago sobre o risco técnico — “foi refatorando aos poucos” sem detalhar como
❌ Não ter resultado mensurável

Sinais de uma resposta forte

✅ Mencionar abordagem incremental: strangler fig pattern, feature flags, módulos isolados
✅ Descrever como código antigo e novo coexistiram temporariamente
✅ Falar sobre testes de regressão e cobertura antes de iniciar a migração
✅ Citar comunicação proativa com stakeholders sobre riscos e timeline
✅ Mencionar monitoramento pós-deploy: Crashlytics, logs, métricas de estabilidade

Chave de Resposta

Use o formato STAR com ênfase no como, não apenas no o que.

Etapa	O que cobrir
Situação	Qual era o app, qual era o problema técnico, qual era o risco de parar o serviço
Tarefa	Qual era a sua responsabilidade direta — não a do time, a sua
Ação	Como mapeou dependências, qual foi a estratégia incremental, como criou ou usou testes para garantir paridade de comportamento, como coordenou com backend, QA e produto
Resultado	O que mudou objetivamente — estabilidade, tempo de build, velocidade de entrega, redução de crashes

Dica estratégica: A Monnos é o cenário natural para essa resposta. Quase cinco anos de liderança técnica em um crypto bank inevitavelmente envolveram refatorações em produção. Parta dali — com detalhes reais e específicos.

Pergunta 3 — Intermediária

“Você já trabalhou em projetos com pressão explícita por velocidade de entrega e, ao mesmo tempo, expectativa alta de qualidade. Como você navega esse trade-off na prática — não em teoria?”

O que o entrevistador avalia

Pragmatismo com responsabilidade. A GOK atende projetos críticos em contexto consultivo — o candidato vai enfrentar pressão de cliente e pressão técnica simultaneamente. O entrevistador quer saber se você sabe tomar decisões difíceis, comunicar riscos e defender qualidade sem ser inflexível ou ingênuo.

Erros que eliminam candidatos

❌ Resposta purista: “nunca aceito débito técnico” — sinaliza inexperiência com contextos reais de produto
❌ Resposta capitulante: “entregávamos o que o produto pedia” — sinaliza ausência de ownership técnico
❌ Não ter exemplo concreto — responder em teoria é insuficiente para uma pergunta que começa com “na prática”
❌ Não mencionar comunicação de riscos — o entrevistador quer ver que você sabe escalar a conversa certa com a pessoa certa

Sinais de uma resposta forte

✅ Diferenciar débito técnico deliberado de débito acidental — saber quando aceitar e quando resistir
✅ Mencionar o conceito de “decisão registrada”: documentar o débito aceito com contexto e custo futuro estimado
✅ Descrever como priorizou o que garantia não-regressão mesmo em entregas rápidas
✅ Ter um exemplo de quando disse “não” ou “não assim” — e como conduziu essa conversa

Chave de Resposta

A resposta ideal tem três partes:

1. Seu framework mental

Como você distingue o que pode ser feito rápido do que não pode. Não toda velocidade é débito — mas alguns atalhos têm custo composto.

Raciocínio esperado: “Há uma diferença entre simplificar uma implementação hoje sabendo que vai refatorar depois, e pular tratamento de erro em um fluxo crítico por causa do prazo. O primeiro é pragmatismo. O segundo é risco assumido sem consciência.”

2. Um exemplo real com tensão genuína

Uma situação específica onde havia pressão real, onde você fez uma escolha difícil — e as consequências dessa escolha.

3. Como você comunica isso

Quem são seus interlocutores quando há conflito entre velocidade e qualidade — produto, tech lead, cliente. Como você apresenta o risco de forma que a decisão seja informada, não unilateral.

Pergunta 4 — Difícil

“No Monnos você ficou quase cinco anos como Head Android. Me dê um exemplo de uma decisão arquitetural que você tomou nesse período que, olhando para trás, faria diferente — e por quê.”

O que o entrevistador avalia

Autoconsciência técnica e capacidade real de aprendizado. Candidatos que não conseguem criticar suas próprias decisões passadas são um sinal de alerta — ou nunca tomaram decisões reais, ou não têm maturidade para revisitá-las.

Erros que eliminam candidatos

❌ Resposta falsa-modesta: “trabalhei demais” ou “poderia ter documentado mais” — não é uma decisão arquitetural
❌ Evasão total: “fiz as melhores escolhas possíveis com o contexto” — sinaliza arrogância ou medo
❌ Arrependimento genérico que qualquer pessoa poderia ter — sem especificidade técnica
❌ Não explicar por que a decisão fazia sentido na época — isso demonstra pensamento situado, não apenas hindsight

Sinais de uma resposta forte

✅ Identificar uma decisão real com nome, contexto e consequência
✅ Explicar o raciocínio que levou àquela decisão na época
✅ Descrever o que aprendeu e como isso mudou sua forma de decidir
✅ Conectar o aprendizado com algo que você aplica ativamente hoje

Chave de Resposta

Esta pergunta exige honestidade e especificidade. Não existe resposta “certa” — existe resposta verdadeira ou inventada, e entrevistadores sêniores percebem a diferença.

Etapa	O que cobrir
Contexto da decisão	Quando foi, qual era o estado do produto, quais eram as pressões e restrições da época
A decisão em si	O que foi escolhido — arquitetura, tecnologia ou processo
Por que fazia sentido então	Mostrar que foi uma decisão com trade-offs conscientes, não ignorância
O que ficou claro depois	Qual consequência real evidenciou o problema — escala, manutenção, estabilidade
O que faria diferente	A resposta técnica alternativa, com o porquê fundamentado

Atenção: Não exagere o erro para parecer humilde, nem o minimize para parecer competente. O entrevistador quer raciocínio maduro — não performance de autohumildade.

Pergunta 5 — Difícil

“Imagine que você acabou de ser alocado em um projeto na GOK. Ao entrar no repositório, você percebe arquitetura altamente acoplada, sem testes, com lógica de negócio dentro de Activities — e o app está em produção com usuários ativos. Qual é seu plano de ação nos primeiros 30 dias? Como você decide o que tocar primeiro sem quebrar o que está funcionando?”

O que o entrevistador avalia

Capacidade de diagnóstico técnico sem julgamento precipitado, planejamento incremental em ambientes com risco real e postura de ownership sem caos. Esse cenário é exatamente o que a GOK encontra em projetos de clientes — código legado crítico que não pode parar.

Erros que eliminam candidatos

❌ “Proporia reescrever o app do zero” — sinal imediato de inexperiência com produção real
❌ Começar a tocar no código antes de entender o domínio e os fluxos críticos
❌ Não mencionar comunicação com o time ou produto antes de agir
❌ Tratar todos os problemas como equivalentes — sem priorização baseada em risco
❌ Não mencionar testes como pré-requisito para qualquer mudança estrutural

Sinais de uma resposta forte

✅ Começar pela compreensão, não pela solução: mapear fluxos críticos, entender o negócio, conversar com quem mantém o código
✅ Diferenciar risco imediato (crashes, falhas de segurança) de débito técnico de longo prazo
✅ Mencionar a estratégia de adicionar testes como primeiro passo antes de refatorar
✅ Falar em mudanças incrementais e validadas — não grandes PRs que ninguém consegue revisar
✅ Comunicar proativamente a produto e stakeholders o que foi encontrado e qual é o plano

Chave de Resposta

Semana 1 — Diagnóstico sem tocar no código

Rodar o app em diferentes condições: fluxo feliz, falha de rede, estados de erro
Ler o código para entender o domínio — não para julgar, mas para aprender
Identificar os fluxos críticos de negócio: o que não pode falhar sob nenhuma hipótese
Conversar com quem construiu ou manteve o código — há contexto que não está no repositório
Mapear pontos de maior instabilidade: Crashlytics, issues conhecidos, código que ninguém toca com medo

Semana 2 — Priorização e plano técnico

Criar um mapa de risco: probabilidade de quebrar × impacto se quebrar
Identificar onde não há testes nos fluxos críticos — esse é o maior risco para qualquer mudança
Propor ao time um backlog técnico com justificativa de negócio para cada item — não apenas “precisa refatorar”
Separar o que é bug ou risco imediato do que é melhoria arquitetural de médio prazo

Semanas 3 e 4 — Primeiras intervenções cirúrgicas

Adicionar testes nos fluxos mais críticos antes de refatorar qualquer coisa
Fazer a menor mudança possível que reduz o maior risco — sem tentar resolver tudo de uma vez
Revisar cada mudança com o time — não agir de forma isolada em código que outros dependem
Documentar as decisões tomadas e o estado encontrado para criar memória técnica do projeto

Dica estratégica: Use esta frase na resposta: “Minha regra em legado é: primeiro entender, depois adicionar testes, depois refatorar. Nunca na ordem inversa.”

Pergunta 6 — Difícil

“Você identificou um problema de segurança relevante em um app em produção — algo que expõe dados sensíveis de usuários. O time de produto está em sprint final, com release marcada para dois dias. Como você age?”

O que o entrevistador avalia

Postura de ownership em situação de conflito real entre velocidade de negócio e responsabilidade técnica. Em ambientes financeiros críticos — contexto direto da GOK — problemas de segurança não são negociáveis. O entrevistador quer ver se você tem coragem técnica, sabe escalar corretamente e não se paralisa nem age de forma unilateral destrutiva.

Erros que eliminam candidatos

❌ “Não mencionaria antes da release para não travar o time” — capitulação com risco real ao usuário
❌ “Bloquearia o release imediatamente sem consultar ninguém” — ação unilateral sem contexto do risco real
❌ Não saber comunicar a severidade do problema de forma objetiva para não-técnicos
❌ Não ter opinião própria — “deixaria o time decidir” sem oferecer uma recomendação fundamentada
❌ Não mencionar documentação ou rastreabilidade da decisão tomada

Sinais de uma resposta forte

✅ Avaliar a severidade real antes de agir — nem todo problema de segurança tem o mesmo impacto imediato
✅ Escalar imediatamente para as pessoas certas com fatos, não com alarme
✅ Apresentar opções com trade-offs claros, não um ultimato
✅ Deixar a decisão informada nas mãos de quem tem autoridade — mas registrar a posição técnica por escrito
✅ Ter clareza sobre o que é negociável (prazo) e o que não é (exposição de dados de usuários)

Chave de Resposta

Passo 1 — Caracterizar o risco antes de agir

Qual é a superfície de ataque? Precisa de acesso físico ao device? É explorável remotamente? Afeta todos os usuários ou um subconjunto? Há dados já comprometidos ou é um risco futuro? Essa análise leva minutos e muda completamente o peso da decisão.

Passo 2 — Escalar com clareza

Não é o momento de resolver sozinho. É o momento de colocar as pessoas certas na mesma sala com a informação correta.

Modelo de comunicação: “Encontrei um problema de segurança com severidade X. Aqui está o que ele expõe, aqui está o que seria necessário para explorá-lo, e aqui estão as opções que vejo.”

Passo 3 — Apresentar opções, não ultimatos

Opção	Descrição
A — Hotfix cirúrgico	Pode ser feito em X horas; release adiada em Y dias
B — Mitigação temporária	Reduz o risco enquanto a correção definitiva vai para a próxima sprint
C — Release com risco conhecido	Requer decisão explícita e registrada de quem tem autoridade

Passo 4 — Registrar a posição técnica

Independente da decisão final, a recomendação técnica deve estar documentada. Não como proteção pessoal — como governança. Em ambientes transacionais críticos, rastreabilidade de decisões é parte do processo.

Dica estratégica: Use esta frase na resposta: “Meu trabalho não é bloquear o release — é garantir que a decisão de fazer o release seja tomada com todas as informações na mesa.”

Pergunta 7 — Difícil

“Como você conduziria um code review em que o autor do código é um desenvolvedor mais sênior que você — ou alguém com mais tempo de casa no projeto — e você identificou um problema real na abordagem dele?”

O que o entrevistador avalia

Maturidade interpessoal em contexto técnico de alta tensão. A GOK valoriza code review como prática real — não como formalidade. O entrevistador quer saber se você mantém a qualidade técnica sem deixar que hierarquia informal ou dinâmicas de time silenciem feedbacks importantes.

Erros que eliminam candidatos

❌ “Aprovaria mesmo discordando para não criar conflito” — ausência de ownership e cumplicidade com o problema
❌ “Apontaria o erro publicamente para o time ver” — postura destrutiva que revela falta de inteligência relacional
❌ Não ter um exemplo real de quando fez isso — resposta puramente teórica é insuficiente
❌ Tratar todo feedback como uma questão de “ter razão” — não demonstra abertura para estar errado também
❌ Não reconhecer que pode haver contexto que você não viu

Sinais de uma resposta forte

✅ Separar clareza técnica de postura combativa — é possível ser direto sem ser agressivo
✅ Fazer perguntas antes de afirmar
✅ Ter exemplos reais — um onde o feedback foi bem recebido e um onde gerou tensão
✅ Reconhecer que review é conversa, não julgamento
✅ Demonstrar abertura genuína para estar errado e aprender com a resposta do autor

Chave de Resposta

Atenção: Code review não é sobre hierarquia — é sobre o código e o usuário que vai usar o sistema. Um problema real não deixa de ser um problema porque o autor é sênior.

1. Começar com uma pergunta, não com uma afirmação

“Você considerou o comportamento desse código quando X acontece?” ou “Estou vendo que não há tratamento para Y — tem algum contexto que eu possa ter perdido?”

Isso abre espaço para o autor explicar algo que o revisor não viu e coloca o foco no problema técnico, não no julgamento da pessoa.

2. Se a pergunta confirmar o problema, ser direto

“Entendo o raciocínio, mas acredito que isso vai causar Z em produção quando X acontecer. Aqui está o que eu proporia como alternativa — o que você acha?”

Direto, técnico, com solução na mesa. Sem passivo-agressividade, sem suavização que obscurece o ponto.

3. Se houver resistência, escalar o argumento — não o conflito

Se não há consenso, a resposta não é ceder nem insistir em loop. É trazer um terceiro com mais contexto ou propor que o time discuta — tornando a decisão explícita e documentada.

4. Aceitar estar errado com a mesma abertura

Se a resposta do autor revelar contexto que o revisor não tinha, reconheça com clareza. Quem faz boas perguntas e aceita boas respostas é mais respeitado do que quem tem sempre razão.

Dica estratégica: Use esta frase na resposta: “Hierarquia não é argumento técnico. Se o código tem um problema, meu trabalho é levantar — com respeito, com contexto e com uma proposta alternativa.”

Pergunta 8 — Difícil

“Conte sobre uma situação em que você discordou de uma decisão técnica tomada pelo time ou por uma liderança — e a decisão foi mantida mesmo assim. Como você agiu depois?”

O que o entrevistador avalia

Resiliência profissional e capacidade de operar com ownership mesmo quando não concordou com a direção. Em contexto consultivo — como na GOK — você frequentemente vai trabalhar em decisões técnicas que já foram tomadas antes de você chegar. O entrevistador quer saber se você sabota, se abdica ou se age de forma madura.

Erros que eliminam candidatos

❌ “Nunca discordei de nenhuma decisão técnica do time” — não é crível e sinaliza que nunca teve voz real
❌ “Disse o que pensava e fiz do jeito deles sabendo que estava errado” — passivo, sem aprendizado
❌ Demonstrar ressentimento ou julgamento sobre quem tomou a decisão
❌ Não ter um exemplo real — resposta genérica em primeira pessoa do plural
❌ Não deixar claro o que você fez de forma diferente após a decisão ser mantida

Sinais de uma resposta forte

✅ Ter articulado a discordância de forma clara e técnica na época — não ficou em silêncio
✅ Registrar a posição de alguma forma (comentário no PR, documento, conversa registrada) sem drama
✅ Após a decisão mantida, comprometer-se genuinamente com a execução — sem sabotar passivamente
✅ Usar a experiência para aprender algo — sobre o contexto que não tinha ou sobre como influenciar melhor
✅ Distinguir decisões que mudaria retrospectivamente das que ainda discorda, mas respeita o processo

Chave de Resposta

Use o formato STAR com foco no “depois” — essa é a parte que mais interessa ao entrevistador.

Situação Qual era o contexto técnico — qual era a decisão, quem estava envolvido, qual era o impacto esperado.

Tarefa Qual era o seu papel — era uma decisão que impactava diretamente o seu trabalho? Você tinha responsabilidade técnica sobre aquela parte?

Ação — em dois momentos

Antes da decisão ser mantida: Como você articulou a discordância. Qual foi o argumento técnico, com quem conversou, que alternativas apresentou. A qualidade do argumento revela que você age com método, não com emoção.

Depois da decisão ser mantida:

Se comprometeu com a execução com a mesma qualidade que teria na sua própria decisão?
Monitorou os resultados e revisitou com dados quando a hipótese se confirmou?
Aprendeu que havia contexto que não tinha e revisou sua análise?

Resultado O que aconteceu com a decisão ao longo do tempo — confirmou sua preocupação? Não confirmou? O que você aprendeu sobre o processo de decisão técnica em times?

Dica estratégica: Use esta frase na resposta: “Discordar e depois executar com excelência não são contraditórios. Meu compromisso é com o produto e com o time — não com estar certo.”

Career Agent Pro — Material personalizado para Pessoa Desenvolvedora Android Sênior | GOK | Inovação Digital