Uber DevOps Engineer: palavras-chave de curriculo e entrevista

Você quer concorrer a uma vaga de DevOps Engineer na Uber e não sabe o que o recrutador procura no currículo. Vou te mostrar o que colocar no papel, o que estudar para a entrevista e os erros que derrubam candidatos técnicos bons.

Antes de mais nada, um aviso honesto: eu não tenho acesso ao processo interno da Uber. Nada aqui é uma promessa de como a empresa contrata. O que dá para fazer é trabalhar com o que a própria empresa publica, com descrições de vaga reais e com o padrão do mercado de infraestrutura.

O que a vaga realmente pede#

Abra a descrição da vaga e leia linha por linha. Não resuma. Anote as tecnologias nomeadas, os verbos usados e o nível de senioridade pedido.

Se você não tem a descrição em mãos, use o decodificador de vagas para separar requisitos de ruído e entender o que é obrigatório e o que é desejável. Isso muda completamente o que você coloca no topo do currículo.

Em linhas gerais, vagas de DevOps para empresas de tecnologia grande pedem três blocos de competência: nuvem, automação e confiabilidade. Kubernetes, containers, CI/CD, infraestrutura como código e observabilidade aparecem quase sempre. Ferramentas específicas variam conforme a equipe.

Palavras-chave que precisam estar no currículo#

O filtro automático procura termos exatos da descrição. Se a vaga escreve "Terraform" e você escreve "infraestrutura como código" sem nomear a ferramenta, você perde o match.

Monte sua lista de termos a partir da vaga, não de uma lista genérica da internet. Os termos que costumam aparecer em vagas de DevOps sênior em empresas de tecnologia incluem:

• AWS, GCP ou Azure, com os serviços específicos que você usou
• Kubernetes, Docker, container orchestration
• Terraform, CloudFormation, Pulumi ou Ansible
• CI/CD com GitHub Actions, Jenkins, ArgoCD, CircleCI ou GitLab CI
• Observabilidade com Prometheus, Grafana, Datadog ou ELK
• Python, Go, Bash para automação
• SRE, SLI, SLO, error budget, incident response
• Linux, redes, segurança de infraestrutura, IAM
• GitOps, blue/green deploy, canary release

Não coloque tudo. Coloque o que você consegue defender por dez minutos numa entrevista técnica. Palavra-chave sem prática vira constrangimento.

Depois de montar o currículo, valide se ele passa por leitura automática. O verificador de currículo para ATS mostra onde o formato quebra e onde as palavras-chave não estão aparecendo.

Como escrever as experiências#

Currículo de DevOps não é lista de ferramentas. É lista de sistemas que você construiu, melhorou ou salvou.

O erro mais comum: escrever o que você era responsável por, e não o que mudou. "Responsável pela infraestrutura AWS" não diz nada. Diga o que aconteceu por causa do seu trabalho.

Um exemplo concreto de como reescrever:

Antes: "Responsável por pipelines de CI/CD e infraestrutura em AWS."

Depois: "Reduzi o tempo de deploy de 40 para 8 minutos reestruturando os pipelines em GitHub Actions e paralelizando os testes, atendendo 6 squads de produto."

O número pode variar conforme sua realidade. O formato é o que importa: ação, contexto técnico, resultado mensurável. Se você não tem número exato, use uma ordem de grandeza honesta, "de horas para minutos", e esteja pronto para explicar como mediu.

O que estudar para a entrevista técnica#

A entrevista técnica de DevOps costuma ter três partes: fundamentos de sistemas, prática de automação e discussão de incidentes. Prepare as três.

Fundamentos: Linux, redes, DNS, TLS, TCP, sistemas de arquivos. Isso derruba mais gente do que qualquer ferramenta nova. Se você automatiza infraestrutura sem entender o que acontece debaixo, aparece rápido.

Automação: conte uma história real com Terraform ou equivalente. Como você organizou o state, como gerenciou módulos, o que aconteceu quando um apply deu errado. Detalhe prático vale mais que adjetivo.

Incidentes: prepare dois ou três casos reais seus. Um erro de deploy, uma indisponibilidade, um problema de custo. Explique o que quebrou, como você diagnosticou, o que mudou depois.

Um exemplo de resposta para a pergunta "conte um incidente que você resolveu":

"Um deploy de sexta-feira à noite derrubou o serviço de pagamentos por 25 minutos. Eu estava de plantão. O rollback automático não disparou porque a health check apontava para o endpoint errado. Corrigi o manifest, fiz rollback manual e o serviço voltou. Na segunda-feira, refiz as health checks em staging, adicionei alerta de erro 5xx acima de 2% e passei a exigir revisão de plantão para deploy fora do horário comercial. Depois disso não tivemos mais esse tipo de queda por erro de health check."

Note o que a resposta tem: contexto, diagnóstico, ação, prevenção. Sem isso, vira só uma história de plantão.

Preparação específica para esta empresa#

Pesquise o que a empresa publica sobre engenharia. Blog de engenharia, palestras em conferências, repositórios abertos. Isso mostra o tipo de problema que a empresa resolve e o vocabulário que ela usa.

Leia sobre escala. Empresas desse porte lidam com picos de tráfego, custo de nuvem alto e times distribuídos. Prepare exemplos seus que tocam em escala, custo ou confiabilidade, mesmo que em outra dimensão.

Não invente ter trabalhado lá dentro ou ter usado processos internos. Se a pergunta for sobre algo que você não conhece, diga: "não trabalhei com isso diretamente, mas pelo que entendo o desafio seria X e eu começaria por Y". Curiosidade técnica honesta pesa mais que jargão.

O mercado brasileiro e o que muda por aqui#

Vagas de DevOps para empresas de tecnologia global podem ser remotas do Brasil, híbridas ou exigir realocação. Cada caso é diferente. Leia o anúncio com atenção antes de se candidatar.

Remuneração varia muito entre contrato local, contractor PJ e realocação. Não vou dar número fixo porque ele muda por senioridade, modelo de contratação e câmbio. Consulte fontes oficiais e a própria proposta para o dado atual.

Para vagas internacionais, o processo de visto depende do país de destino e do tipo de contrato. Nenhum número aqui é garantia. Verifique sempre na fonte oficial do governo do país e com o recrutador.

Se você está começando a buscar, o painel de vagas de tecnologia ajuda a ver o que está aberto agora e quais termos o mercado está usando.

Checklist antes de enviar#

• O currículo nomeia as tecnologias exatas da descrição da vaga
• Cada experiência tem ação, contexto técnico e resultado
• Você consegue defender cada palavra-chave por dez minutos
• Dois ou três incidentes reais estão preparados com diagnóstico e prevenção
• O formato passa por leitura automática sem quebrar tabelas ou colunas
• Você leu o blog de engenharia da empresa e entende o vocabulário dela
• Você sabe se a vaga é remota, híbrida ou exige realocação

Ferramentas grátis#

• jobrise.io/pt/free-ats-checker/
• jobrise.io/pt/free-jd-decoder/
• jobrise.io/pt/jobs/
• jobrise.io/pt/blog/

Perguntas frequentes#

Preciso ter experiência com todas as ferramentas listadas na vaga?

Não. Foque nas obrigatórias e deixe as desejáveis como familiaridade. É melhor dizer "usei Terraform em produção, conheço Pulumi pela documentação" do que fingir domínio e ser desmascarado na entrevista técnica.

Faz diferença escrever o currículo em inglês?

Para vaga em empresa global, sim, quase sempre. Tenha as duas versões e mantenha os termos técnicos em inglês mesmo na versão em português. Se a vaga for para time local, siga o idioma do anúncio.

Devo mencionar projetos pessoais de infraestrutura?

Sim, se eles mostram prática real. Um laboratório de Kubernetes no GitHub vale mais que uma linha dizendo "interesse por DevOps". Descreva o que o projeto resolve e o que você automatizou.

Como responder perguntas sobre ferramentas que não conheço?

Diga que não usou e explique como você aprenderia. Um exemplo: "não usei ArgoCD, mas já automatizei deploys com GitOps no GitHub Actions e o princípio de reconciliação é o mesmo". Honestidade técnica é mais valorizada que invenção.

Quanto tempo leva para se preparar para esse tipo de entrevista?

Depende do seu ponto de partida. Se os fundamentos de Linux e redes estão frágeis, conte meses. Se você já opera infraestrutura em produção, algumas semanas de revisão focada costumam bastar. Monte um plano com base nos seus gaps reais, não em prazos genéricos.