Perguntas para Entrevista de Engenheiro de Plataforma

Gerentes em empresas com times de plataforma maduros reportam que 60% dos candidatos falham em entrevistas técnicas não por conhecimento de ferramentas, mas por pensamento de design de sistemas e capacidade de explicar decisões de infraestrutura em termos de negócio [1]. Entrevistas de platform engineering diferem de DevOps geral em um ponto crítico: entrevistadores avaliam se você pensa em infraestrutura como um produto interno.

Principais Conclusões

• Espere 3 estágios: comportamental/fit cultural, aprofundamento técnico e design de sistemas
• Perguntas comportamentais focam em pensamento plataforma-como-produto: empatia com desenvolvedores, colaboração cross-team, liderança de incidentes
• Perguntas técnicas testam internals de Kubernetes, design de IaC e arquitetura de observabilidade
• Cenários situacionais avaliam como você prioriza demandas concorrentes de múltiplos times
• Prepare 4-5 histórias STAR cobrindo impacto de plataforma, resposta a incidentes e melhorias de developer experience

Perguntas Comportamentais (STAR)

1. Descreva quando construiu feature de plataforma que desenvolvedores inicialmente resistiram.

**Por que perguntam**: Engenheiros de plataforma constroem produtos internos. Adoção é a métrica definitiva.

2. Conte sobre o incidente de produção mais complexo que liderou.

**Por que perguntam**: Testa liderança de incidentes, profundidade de debugging e prevenção.

3. Dois times de produto tinham requisitos conflitantes para a plataforma.

**Por que perguntam**: Testa priorização, gestão de stakeholders e pensamento de produto.

4. Como convenceu liderança a investir em infraestrutura de plataforma ao invés de features?

**Por que perguntam**: Testa comunicação de valor de infraestrutura em termos de negócio.

5. Como mediu o sucesso de uma plataforma que construiu?

**Por que perguntam**: Métricas DORA, satisfação de desenvolvedores, taxas de adoção self-service, SLOs de uptime.

Perguntas Técnicas

1. O que acontece quando um pod é agendado no Kubernetes, do momento que aplica um Deployment até o container rodar?

**Avaliação**: kubectl → API server (autenticação, autorização, admission controllers) → etcd → scheduler (filtragem, scoring, binding) → kubelet → CRI (containerd) → CNI → readiness probe → registro de endpoint.

2. Projete estratégia de módulos Terraform para organização com 15 times.

**Avaliação**: Composição de módulos, isolamento de estado, backend remoto, RBAC, versionamento, detecção de drift.

3. Upgrades zero-downtime de Kubernetes para cluster com 500+ pods.

**Avaliação**: PodDisruptionBudgets, rolling update de node pools, política de version skew, validação pré-upgrade, estratégia canary, monitoramento, rollback.

4. Projete stack de observabilidade para 50 microsserviços.

**Avaliação**: Métricas (Prometheus + Thanos), logs (Fluent Bit → Loki), traces (OpenTelemetry → Tempo/Jaeger), correlação, alertas baseados em SLO, dashboards self-service Grafana.

5. Desenvolvedor reporta deploy de 45 minutos. Como diagnostica?

**Avaliação**: Rastrear pipeline sistematicamente: checkout, dependências, build, testes, push de imagem, sync ArgoCD, agendamento de pod. Identificar gargalo antes de otimizar.

6. Kyverno vs OPA/Gatekeeper — quando escolher cada?

**Avaliação**: OPA/Gatekeeper — Rego, curva íngreme, políticas cross-resource complexas. Kyverno — YAML nativo, barreira menor, validação/mutação/geração.

Perguntas Situacionais

1. Time de 5 pessoas, 8 times de produto com demandas simultâneas.

**Abordagem**: Categorizar por impacto × severidade, urgência, alinhamento estratégico. Processo transparente de intake: reunião semanal, roadmap público, SLAs por tipo.

2. Novo CTO quer migrar de AWS para GCP em 6 meses.

**Abordagem**: Avaliação de impacto, abordagem faseada — abstrair via Terraform primeiro, POC em non-prod, produção com rollback. Questionar timeline com evidências se irreal.

3. Evictions intermitentes de pods em horário comercial.

**Abordagem**: Verificar pressão de recursos nos nós, requests vs uso real, noisy neighbors, logs do autoscaler. Implementar ResourceQuota e LimitRange.

4. 40% dos arquivos de estado Terraform sem apply há 6 meses.

**Abordagem**: Não fazer terraform apply cegamente. Plan para cada arquivo, classificar drift, implementar detecção contínua, estabelecer política de governança.

5. VP de engenharia pede acesso direto ao cluster Kubernetes de produção.

**Abordagem**: Alternativas: kubectl read-only via RBAC, dashboards Grafana, containers efêmeros, agregação de logs. Se insistir — acesso com tempo limitado e audit logging.

Critérios de Avaliação

**Profundidade técnica (40%)**: Explica como sistemas funcionam no nível de componentes? **Design de sistemas (25%)**: Arquiteta componentes de plataforma para múltiplos times em escala? **Produto e comunicação (20%)**: Explica decisões em termos de negócio? **Incidentes e operações (15%)**: Diagnostica problemas sistematicamente?

Perguntas para Fazer

1. "Como o time de plataforma mede sucesso?"
2. "Qual o pain point atual de developer experience que estão priorizando?"
3. "Como o time está estruturado relativo aos times de produto?"
4. "Qual a frequência atual de deploy e onde está o gargalo?"
5. "Qual a decisão de infraestrutura mais controversa recente?"
6. "Como é o on-call para o time de plataforma?"
7. "Existe processo de revisão de arquitetura ou RFC?"

Conclusões Finais

Entrevistas avaliam três dimensões: profundidade técnica, pensamento de produto sobre developer experience e maturidade operacional. Prepare histórias STAR com resultados mensuráveis de plataforma.

Perguntas Frequentes

Quantas rodadas?

Tipicamente 4-5: triagem, comportamental, técnica, design de sistemas, painel cultural. 2-4 semanas total.

Startup vs empresa grande?

Startups enfatizam amplitude; empresas grandes enfatizam profundidade em domínios específicos.

Quão importante é Go?

Crescentemente importante em mid+. Se a empresa constrói operators Kubernetes — praticamente obrigatório.

Sem experiência nas ferramentas específicas?

Foque em conceitos transferíveis. ArgoCD vs Flux — princípios de GitOps são idênticos.

**Citações:** [1] DORA / Google Cloud, "2024 Accelerate State of DevOps Report," dora.dev, 2024.