TL;DR
- Um developer sénior não é alguém com muitos anos de CV. É alguém que reduz risco técnico, comunica trade-offs e entrega sem precisar de supervisão diária.
- Em Portugal, tentar contratar séniores bons com processo lento, vaga genérica e orçamento desalinhado quase sempre falha.
- Testes técnicos úteis avaliam decisões reais: dados, APIs, segurança, deploy, observabilidade e manutenção. LeetCode raramente mede o que interessa num SaaS B2B.
- O maior erro é contratar “um sénior salvador” quando o problema é falta de direcção de produto, arquitectura confusa ou dívida técnica acumulada.
- Antes de contratar, decide se precisas de colaborador permanente, freelancer ou equipa externa. Cada modelo resolve problemas diferentes.
O que significa “sénior” na prática
Há muita gente em Portugal com o título “Senior Software Engineer” no LinkedIn que, em produção, ainda precisa de bastante acompanhamento. Isto não é uma crítica pessoal. É uma consequência normal de empresas que promovem por antiguidade, não por impacto.
Para mim, um developer sénior tem cinco características concretas.
Primeiro, sabe decompor ambiguidade. Se lhe dizes “precisamos de um portal de cliente”, não começa logo a criar componentes em React. Faz perguntas sobre autenticação, permissões, origem dos dados, auditoria, integração com ERP ou CRM, SLAs, migração, suporte e quem vai operar aquilo às 3 da manhã.
Segundo, percebe dados. Não tem de ser DBA, mas tem de saber quando usar uma transacção, quando criar um índice, como ler um EXPLAIN ANALYZE em PostgreSQL 16, porque é que uma migration pode bloquear escrita em produção e como evitar queries N+1. Quem trabalha em SaaS B2B, fintech, retail ou healthtech e não domina o ciclo de vida dos dados está a construir problemas futuros.
Terceiro, comunica trade-offs. Um sénior decente não diz apenas “eu faria microserviços” ou “eu usaria Supabase”. Explica custo operacional, limites, dependências, latência esperada, impacto na equipa e caminho de reversão.
Quarto, deixa rasto. Pull requests legíveis, decisões documentadas, logs úteis, métricas mínimas, runbooks e testes nos sítios certos. Não é burocracia. É a diferença entre uma equipa que consegue operar software e uma equipa refém da pessoa que escreveu o código.
Quinto, sabe dizer “não”. Em projectos reais, a senioridade aparece quando alguém trava uma solução bonita mas perigosa. Por exemplo, recusar uma integração directa entre checkout e ERP sem fila, retries e idempotência. A documentação da Stripe sobre idempotency, em https://docs.stripe.com/api/idempotent_requests, devia ser leitura obrigatória para qualquer developer que toque em pagamentos.
Antes da vaga, percebe o problema que queres resolver
Muitas empresas começam pelo anúncio: “Procuramos senior full-stack developer com React, Node.js, PostgreSQL, AWS, Docker, Kubernetes e boa capacidade de comunicação.” Isto é fraco. Não diz nada sobre o problema real.
Antes de publicar a vaga, escreve uma página interna com isto:
- Produto: o que a pessoa vai construir nos primeiros 90 dias.
- Risco principal: performance, segurança, legacy, velocidade de entrega, integrações, dados ou equipa.
- Estado da stack: versões, dívida técnica, cobertura de testes, deploy, incidentes recentes.
- Nível de autonomia esperado: vai liderar decisões ou executar dentro de uma arquitectura já definida.
- Métrica de sucesso: reduzir bugs críticos, entregar módulo, estabilizar integração, cortar tempo de deploy, melhorar p95 de uma API.
Na Impact Origin, quando entramos em clientes ainda numa fase muito inicial, incluindo clientes activos há cerca de dois meses e ainda sem facturação definida, a primeira recomendação raramente é “contratem já um sénior caro”. Muitas vezes é clarificar produto, fluxo de dados e modelo operacional. Contratar uma pessoa sénior para compensar falta de foco é uma forma cara de adiar uma decisão difícil.
A pergunta certa é: qual é o risco que esta contratação tem de remover?
Se o risco é arquitectura, precisas de alguém que já tenha operado sistemas com tráfego real, dados reais e falhas reais. Se o risco é velocidade de produto, talvez precises de alguém pragmático, bom a cortar escopo e a entregar incrementos semanais. Se o risco é equipa júnior, precisas de capacidade de mentoria, revisão de código e standards técnicos.
São perfis diferentes. Meter tudo no mesmo anúncio reduz a probabilidade de encontrares a pessoa certa.
Permanente, freelancer ou consultoria: não são equivalentes
Há três caminhos comuns. Todos podem funcionar. Todos podem correr mal.
Colaborador permanente faz sentido quando queres acumular conhecimento interno, construir cultura de engenharia e tens roadmap para 12 a 24 meses. É a melhor opção para produto core. O problema é o tempo. Entre sourcing, entrevistas, pré-aviso e onboarding, facilmente passam 2 a 4 meses. Para seniores fortes em Portugal, assumir custo total mensal inferior a €4.000 costuma ser optimista, sobretudo se competes com empresas remotas europeias ou norte-americanas. Além do salário, conta com TSU, equipamento, benefícios, gestão e custo de oportunidade.
Freelancer sénior faz sentido para diagnóstico, desbloqueio técnico, migração, integração ou aceleração temporária. Em Portugal, rates de €45 a €90 por hora são comuns para perfis experientes, variando muito com especialização e contexto. Um erro de 3 meses a €60 por hora, a tempo inteiro, custa cerca de €28.800 antes de IVA. Por isso, não contrates freelancer sem entregáveis semanais e critério claro de aceitação.
Consultoria ou equipa externa faz sentido quando precisas de resultado, não apenas de mãos. A vantagem é combinar perfis: arquitectura, produto, desenvolvimento, QA, DevOps. A desvantagem é que o custo por hora pode parecer mais alto. Digo “parecer” porque comparar apenas preço hora é uma armadilha. Se uma equipa experiente evita 6 meses de refactorização errada, o preço hora deixou de ser a métrica principal.
A regra prática: se o conhecimento tem de ficar dentro de casa durante anos, contrata. Se tens um problema delimitado, usa freelancer ou consultoria. Se não sabes diagnosticar o problema, começa por uma avaliação técnica curta antes de contratar alguém em definitivo.
Como desenhar um processo técnico que não afasta bons candidatos
Developers seniores bons não têm paciência para processos lentos, testes genéricos e entrevistas onde ninguém sabe explicar a arquitectura actual. Se o teu processo tem 6 fases e uma delas é um desafio de fim de semana não pago, vais perder candidatos bons para empresas mais directas.
Um processo decente pode ter 4 passos.
1. Triagem curta, 20 a 30 minutos. Objectivo: perceber motivação, disponibilidade, expectativas financeiras, inglês, modelo de trabalho e contexto. Não faças perguntas técnicas profundas aqui.
2. Conversa técnica, 60 minutos. Sem truques. Pede à pessoa para explicar um sistema que construiu, uma decisão errada que corrigiu, uma falha em produção e uma situação em que disse “não” a produto ou gestão. Bons seniores têm cicatrizes. Maus candidatos falam só de tecnologias.
3. Exercício prático, máximo 2 horas. Idealmente pago se for mais longo. O exercício deve parecer trabalho real. Por exemplo: “temos uma API Node.js 22 LTS que cria encomendas, grava em PostgreSQL 16 e envia pagamento para Stripe API 2024-04-10. Desenha os pontos de falha e propõe alterações para garantir idempotência, auditoria e retries.” Isto mede raciocínio, não memorização.
4. Pairing ou revisão de arquitectura, 60 a 90 minutos. Dá um PR pequeno ou um diagrama simples e pede revisão. O que procuras é qualidade de perguntas, capacidade de priorizar e clareza na comunicação.
Evita LeetCode como filtro principal para SaaS B2B normal. Algoritmos importam em certos domínios, claro. Mas para a maioria dos produtos empresariais, é mais valioso avaliar HTTP, filas, SQL, autenticação, permissões, observabilidade, deploy e manutenção. A especificação HTTP actual está na RFC 9110, em https://www.rfc-editor.org/rfc/rfc9110. Se a pessoa vai desenhar APIs, deve conhecer pelo menos os conceitos base: idempotência, códigos de estado, cache, headers e semântica dos métodos.
Sinais fortes e sinais perigosos numa entrevista
Há respostas que costumam separar séniores reais de perfis apenas experientes.
Um bom sinal é a pessoa perguntar por dados de produção. Volume de tabelas, p95 e p99 de endpoints críticos, número de tenants, RPS, tamanho de payloads, tempo de deploy, taxa de erro, custo mensal de cloud, tempo médio de recuperação. Mesmo que não tenhas estes números, a pergunta mostra maturidade.
Outro bom sinal é falar de reversibilidade. Feature flags, migrações em duas fases, deploys pequenos, rollback, compatibilidade entre versões, scripts idempotentes. Isto é engenharia adulta.
Também valorizo candidatos que sabem escolher tecnologia aborrecida. PostgreSQL 16, Redis quando faz sentido, filas simples, logs estruturados, OpenTelemetry, CI previsível. Nem tudo precisa de Kubernetes, Kafka e arquitectura distribuída. Já escrevemos bastante sobre isto noutros contextos: complexidade técnica antes da necessidade real é uma dívida, não uma medalha.
Sinais perigosos:
- Fala de “reescrever tudo” antes de perceber o sistema.
- Não consegue explicar falhas que causou ou ajudou a corrigir.
- Só avalia tecnologia por preferência pessoal.
- Não pergunta sobre utilizadores, operação, suporte ou dados.
- Trata segurança como tarefa final.
- Desvaloriza testes porque “sénior não precisa”.
- Nunca menciona logs, métricas ou alertas.
Em healthtech e fintech, por exemplo, permissões, auditoria e rastreabilidade não são pormenores. A OWASP ASVS 4.0.3, em https://owasp.org/www-project-application-security-verification-standard/, é uma boa referência para discutir autenticação, gestão de sessões, controlo de acesso e validação. Não precisas de transformar a entrevista num exame de segurança, mas um sénior deve perceber que dados sensíveis mudam a arquitectura.
A armadilha comum: contratar anos de experiência em vez de contexto
A gotcha que mais vejo é confundir “10 anos de experiência” com “10 anos de decisões relevantes”. Uma pessoa pode ter passado 8 anos no mesmo produto, com deploy manual, pouca escala, pouca pressão de negócio e quase nenhuma responsabilidade sobre operação. Pode ser competente, mas talvez não seja a pessoa certa para liderar um SaaS que precisa de integrações, billing, permissões por tenant, observabilidade e releases semanais.
O contrário também acontece. Alguém com 5 ou 6 anos muito intensos, em equipas boas, com exposição a incidentes, produto e clientes, pode ser mais sénior na prática.
Por isso, entrevista por contexto.
Pergunta:
- Que decisão técnica tomaste que depois tiveste de reverter?
- Como migraste dados sem parar produção?
- Como desenhas permissões por organização, equipa e utilizador?
- Como investigas um p99 a 2 segundos quando o p50 está a 80 ms?
- O que farias se uma fila começasse a acumular 100.000 jobs?
- Que logs queres ver quando um pagamento falha?
- Como separas bug, incidente e dívida técnica?
As respostas não têm de ser perfeitas. Mas têm de mostrar método. Um sénior não precisa de saber tudo. Precisa de saber reduzir incerteza.
Outra armadilha é contratar um “sénior full-stack” para tudo: frontend, backend, cloud, UX, segurança, produto, suporte e gestão de equipa. Isso não é uma vaga. É uma lista de ansiedade. Podes encontrar pessoas muito versáteis, mas ninguém é excelente em tudo. Define onde aceitas profundidade e onde aceitas suficiência.
Como não perder candidatos bons durante o processo
Portugal já não é um mercado isolado. Um developer sénior em Lisboa, Porto, Braga, Coimbra ou remoto a partir do interior pode trabalhar para empresas europeias, americanas ou equipas distribuídas. Se o teu processo for lento, opaco ou mal pago, perdes.
Coisas simples fazem diferença.
Publica intervalo salarial. Se não podes publicar, pelo menos diz na primeira conversa. Esconder orçamento é perder tempo dos dois lados.
Explica o modelo de trabalho com clareza. Remoto, híbrido, dias obrigatórios, fuso horário, equipamentos, horário de reuniões. “Somos flexíveis” sem detalhes não significa nada.
Mostra a stack real. Não digas apenas “AWS”. Diz se usam ECS, Lambda, RDS, S3, CloudWatch, Terraform, GitHub Actions. Diz versões quando relevante. Node.js 22 LTS, PostgreSQL 16, React 19.NET 8, Python 3.12. Isto atrai pessoas que gostam de rigor e afasta mal-entendidos.
Prepara quem entrevista. Nada mata mais depressa uma contratação sénior do que uma entrevista conduzida por alguém que não sabe responder a perguntas básicas sobre produto, arquitectura ou processo de decisão.
Dá feedback rápido. Mesmo que seja “não”. Um prazo de 48 horas após cada fase é razoável. Uma semana de silêncio transmite desorganização.
E não vendas caos como oportunidade. Se há legacy, diz. Se há pressão, diz. Se a equipa é pequena, diz. Bons seniores não fogem de problemas difíceis. Fogem de empresas que escondem a realidade.
Conclusão
Contratar developers seniores em Portugal sem te queimares exige clareza antes de sourcing, avaliação técnica ligada a problemas reais e honestidade sobre dinheiro, contexto e risco.
A minha opinião é simples: não contrates senioridade por título. Contrata capacidade de decisão, operação e comunicação sob incerteza.
Se estás a enfrentar um problema parecido, marca uma conversa em https://impact-origin.com/agendamento.
