Líder técnico

Tech Lead — Plataforma

Buscamos um Tech Lead para liderar tecnicamente a construção do time de Plataforma na 3s Checkout.

Não contratamos alguém para operar uma plataforma madura. Contratamos quem vai construí-la do zero, com mão na massa. Aqui não existe desenhar e handar. Você constrói.

Isso exige tolerância à ambiguidade, priorizar sozinho o que destrava mais cedo, e disciplina para começar pelo mínimo que resolve em vez de perseguir o desenho ideal.

O time

Somos um time de plataforma. Nosso produto não é feature de negócio — é a capacidade de entrega dos times stream-aligned do Backoffice. Entregamos pipeline de deploy, observabilidade, gates de qualidade e segurança, e a infraestrutura do SLA. O objetivo: um time coloque código em produção rápido, com qualidade e segurança garantidas por construção, sem depender de nós no meio do caminho.

Seus usuários são engenheiros. Plataforma que ninguém quer usar falhou. O caminho pavimentado precisa ser mais rápido que o desvio — se for mais lento, os times contornam e o gate vira teatro.

Stack

Python e PostgreSQL sobre AWS: RDS, ECS e Lambda, com infraestrutura em Terraform. Containers no ECS para serviços de longa duração, Lambda para cargas assíncronas e event-driven, dado transacional no RDS.

Não precisa ter usado exatamente esse conjunto, mas precisa ter operado algo equivalente e saber justificar escolhas — pool de conexões do Postgres quando Lambda escala, quando uma carga deveria ser fila, por que um serviço fica no ECS.

O que você vai construir

Cada bloco é uma frente de construção, não operação herdada. Escopo, ordem e ambição você ajuda a definir com Produto, liderança de engenharia e os times que vão consumir o resultado.

PIPELINE DE ENTREGA COMO PRODUTO

• Pipeline padrão, reutilizável e versionado — workflow e módulos compartilhados, não YAML copiado em cada repo.
• Do commit ao ambiente: artefato imutável, promoção entre ambientes, migração de banco, deploy e rollback em minutos.
• Serviço novo em produção em horas, não semanas: scaffolding, provisionamento e primeiro deploy pelo caminho padrão.
• Evolução sem quebrar N times: versionamento das abstrações, deprecação com prazo, migração acompanhada.
• Migração de esquema desacoplada do deploy: expand/contract, compatibilidade entre versões, sem inconsistência.

GATES DE QUALIDADE E SEGURANÇA

• Barra mínima por construção: teste, contract test, lint, tipagem, análise estática, varredura de dependência, detecção de segredo, checagem de Terraform e imagem.
• Policy-as-code, não checklist em Confluence.
• Gate rápido, determinístico e acionável. Gate lento e cheio de falso positivo ensina o time a burlar.
• Você decide o que bloqueia merge e o que apenas avisa — sustenta essa linha com dado e risco, não autoridade.

OBSERVABILIDADE COMO SERVIÇO

• Instrumentação padrão que o time herda: log estruturado, métrica, tracing com correlation ID por ECS, Lambda e RDS.
• Dashboard e alerta que nascem com o serviço, não após o primeiro incidente.
• SLO: definição, medição e error budget que muda prioridade quando estoura.
• Alerta acionável e combate a ruído. Alerta que ninguém trata é sinal perdido.
• Custo da observabilidade é seu — log cresce sem ninguém olhar.

INFRAESTRUTURA E CONFIABILIDADE (SLA)

• O SLA é o compromisso de disponibilidade com o cliente. Redundância, degradação graciosa, retry, reprocessamento seguros, auto-recuperação e raio de dano são requisito de projeto.
• Estabilidade da infraestrutura: RDS, ECS, Lambda, rede, capacidade, escala.
• Módulos Terraform versionados e reaproveitáveis, com plan revisado em PR. Granularidade de state e raio de dano de um apply são decisão de arquitetura.
• Provisionamento: plan no PR, apply pelo pipeline com identidade federada. Ninguém roda apply da própria máquina.
• Incidente: processo claro, postmortem sem culpa, ação corretiva com dono e prazo. Incidente recorrente com intervenção manual é defeito de arquitetura.
• Continuidade: backup, PITR testado, plano de falha de dependência.
• Custo de infra sob controle, atribuível por time e serviço.

PLATAFORMA É PRODUTO, NÃO SERVIÇO INTERNO DE TICKETS

• Times stream-aligned são clientes: conversa, observa onde travam, prioriza, documenta e publica changelog.
• Thinnest viable platform. Constrói o mínimo que resolve. Sem adoção, é custo recorrente.
• Mede: DORA por time, tempo até o primeiro deploy, duração do pipeline, ruído de alerta, custo por serviço e SLO da plataforma.
• Autoatendimento é o alvo. Toda exceção que exige o time de plataforma é item de backlog, não operação.

IA NO DIA A DIA

• Com agentes de código, escrever deixa de ser a restrição — verificar passa a ser. A verificação é o que esse time entrega.
• Uso do Claude Code é obrigatório. Avaliamos maturidade, não adoção nominal.
• Constrói o caminho pavimentado do dev com agente: CLAUDE.md, skills compartilhados, MCP internos, ambiente de execução seguro.
• Garante que código de agente não fura o gate. Responsabilidade pela main é humana.
• Segurança: dado real e segredo fora do contexto do agente; dependência passa pelo mesmo scanner.

REFERÊNCIA TÉCNICA E INFLUÊNCIA

• Desenha as soluções da plataforma de forma autônoma, sem depender de direcionamento de terceiros.
• Lidera por influência. O padrão se impõe porque é melhor e mais fácil — não porque foi decretado.
• Postura crítica com Produto e líderes técnicos: se existe caminho melhor, é sua responsabilidade dizer com argumento técnico.
• Pragmatismo arquitetural: resolve o problema de hoje sem criar o de amanhã, sem complexidade nem custo injustificados.

GESTÃO TÉCNICA E DESENVOLVIMENTO DO TIME

• Eleva o nível técnico via code review, mentoria e boas práticas.
• Identifica gap técnico, monta plano de evolução e acompanha. Você não carrega o time nas costas — constrói um time que se sustenta sozinho.

REQUISITOS

• Inglês fluente (leitura, escrita e conversação). Obrigatório.
• 7+ anos de desenvolvimento, sendo pelo menos 2 como referência técnica (Tech Lead, Staff, EM hands-on ou Sênior como referência).
• Ter respondido por sistema no ar: disponibilidade, incidente, observabilidade, SLO. Desenvolver funcionalidade não é a mesma coisa.
• Python em nível de produção, ou domínio equivalente em outra linguagem com disposição para migrar.
• AWS a fundo: ECS, Lambda, RDS, IAM, VPC, KMS, CloudWatch. Pooling, concorrência, timeout, retry, DLQ, autoscaling não podem ser conceito de slide.
• PostgreSQL: índices, planos de execução, transações, isolamento, locks, query lenta, migração sem downtime, réplica, backup e PITR.
• Ter construído, não só consumido: pipeline, ferramental ou automação que outras pessoas passaram a usar.
• CI/CD que você construiu: workflow reutilizável, artefato, promoção entre ambientes, migração de banco, rollback, federação de identidade.
• Terraform em uso real: módulos versionados, gestão de state, drift, refactor sem recriar recurso, evolução sem quebrar quem consome.
• Observabilidade prática: OpenTelemetry ou equivalente, log estruturado, métrica, tracing, SLO, alerta.
• Segurança aplicada: cadeia de dependências, SAST/SCA, gestão de segredo (inclusive state do Terraform), IAM com menor privilégio, multi-tenant, LGPD.
• Sistemas distribuídos: consistência eventual, particionamento, idempotência, resiliência, tolerância a falhas, CAP.
• Fundamentos: estruturas de dados, algoritmos, trade-off.
• Redes: HTTP/HTTPS, DNS, TCP/IP, TLS, timeout e política de retry.
• Uso real de agentes de IA em workflow de desenvolvimento.
• Git, GitHub, metodologias ágeis, gestão de qualidade.

DIFERENCIAIS

• Plataforma interna ou IDP com adoção medida — e saber contar o que não foi adotado e por quê.
• SRE, engenharia de confiabilidade, gestão formal de incidente.
• FinOps e otimização de custo em AWS com resultado mensurável.
• Team Topologies na prática, com times stream-aligned reais.
• Food service, PDV, varejo; backoffice e domínio fiscal.
• IA aplicada ao ciclo de desenvolvimento em escala de organização.

PODE NÃO SER O MOMENTO IDEAL SE…

• Sua motivação principal é entregar feature de negócio — aqui o produto é a plataforma e o cliente é engenheiro.
• Você prefere operar uma plataforma madura. Boa parte disso ainda não existe — vai existir porque você constrói.
• Você prefere ambientes com backlog e padrões definidos. No começo há problema e prioridade a definir.
• Seu estilo é desenhar e handar para implementação. Aqui o esperado é mão na massa do desenho ao deploy.
• Sua visão de governança é bloquear e reprovar. Aqui governança se impõe por caminho melhor, não por barreira.
• Você acredita que adoção se resolve por decreto. Aqui adoção se conquista porque o caminho é mais rápido e fácil.
• Infraestrutura, pipeline e alerta sempre foram de outro time. Aqui são parte do escopo.
• Faz tempo que você não escreve código com regularidade. Aqui mão na massa é parte do papel.
• Você prefere receber tarefa detalhada. Aqui o esperado é receber objetivo e definir o caminho.

BENEFÍCIOS

• 100% remoto
• Horário: 9h às 18h
• VR/VA — Cartão iFood: R$ 704,00
• Plano de Saúde (Porto Seguro, sem coparticipação): empresa cobre 70% + 30% de desconto em folha para o titular | Dependentes custeados 100% pelo profissional
• Plano Odontológico: 100% custeado pela empresa para o titular (sem inclusão de dependentes)
• Vale-presente de aniversário: R$ 200,00 (saldo livre iFood)
• PLR atrelado a avaliação de desempenho
• Seguro de vida