Senior Backend Engineer in Lisbon

Construir sistemas, não apenas serviços. Trabalhar em produtos, não dentro de uma única base de código. Assumir problemas desde a primeira pergunta até a produção.

A nossa equipa de engenharia trabalha em um portfólio de produtos móveis utilizados por milhões de pessoas. Você não se juntará a uma equipe permanente ligada a um único aplicativo. Você pode passar as suas primeiras semanas melhorando o backend de um produto porque é onde está a maior necessidade técnica. Um mês depois, você pode estar projetando um serviço para outro, ajudando a resolver um incidente de produção em outro lugar ou melhorando a infraestrutura utilizada em vários produtos.

Estamos à procura de um Engenheiro Backend Sênior que combine profundidade em engenharia backend com amplitude em sistemas, infraestrutura, arquitetura e produto. Pense em T-shaped: profundo em engenharia backend, amplo o suficiente para entender os sistemas ao seu redor.

Como a engenharia funciona aqui: Não há sempre um ticket perfeitamente especificado esperando por você. Geralmente, há um problema. Um serviço está lutando sob carga. Um modelo de banco de dados não se encaixa mais no produto. Uma equipe precisa testar algo rapidamente. Uma API precisa ser redesenhada. Algo quebra na produção. Seu trabalho é entender o contexto, decidir o que a engenharia deve fazer a seguir e construí-lo.

Isso significa fazer perguntas além da implementação: Que problema estamos realmente resolvendo? O que acontece a montante e a jusante? O que quebra se o uso crescer 5x? Que trade-off estamos fazendo? Isso precisa de um novo serviço? Cuidamos mais de como você raciocina sobre todo o sistema do que de quão bem você conhece um único framework.

O que você vai trabalhar: Go é nosso padrão de backend. Aproximadamente 80–90% do nosso trabalho de backend é em Go, com o restante principalmente em Node.js e Python. Você não precisa ter passado toda a sua carreira escrevendo Go. Você pode vir de Java, Kotlin, Python, Node.js ou outro ecossistema de backend. O que importa é que você possa se tornar produtivo em Go e não trate uma linguagem como sua identidade profissional.

Você também deve entender a infraestrutura por trás do código, incluindo: bancos de dados relacionais, design de esquemas, migrações, indexação e comportamento de consultas; sistemas distribuídos, filas de mensagens e corretores como Kafka; Docker e Kubernetes; infraestrutura em nuvem e APIs; observabilidade, desempenho, confiabilidade e modos de falha.

O que você realmente fará: Você projetará, construirá, executará e melhorará sistemas backend em vários produtos. Você levará problemas de um ponto de partida pouco claro através da arquitetura, implementação, implantação e iteração. Você investigará sistemas que não construiu. Você trabalhará diretamente com produto, frontend, dados e outros engenheiros. Você melhorará sistemas existentes em vez de assumir que tudo precisa ser reescrito. E quando algo quebrar, você ajudará a resolver, mesmo que não fosse parte do seu plano naquela manhã.

Quando dizemos propriedade, não queremos dizer completar suas tarefas de engenharia atribuídas sem lembretes. É ser capaz de pegar um problema, entender o contexto, falar com as pessoas certas, identificar os desconhecidos, tornar os trade-offs visíveis e colocar a solução em produção. Então, verificar se funcionou.

Você provavelmente prosperará aqui se: Você naturalmente amplia a visão antes de se aprofundar. Você pode discutir arquitetura pela manhã, depurar um problema de produção à tarde e trabalhar em uma base de código desconhecida no dia seguinte. Você se preocupa mais em resolver o problema do que em proteger sua pilha preferida. Você pode tomar uma decisão sensata sem ter 100% das informações. Você faz perguntas sobre o produto e o usuário em vez de tratar requisitos como instruções fixas. Você aprende tecnologia desconhecida quando o problema exige. Você muda de ideia quando novas evidências tornam sua abordagem original errada. E quando você nota um problema fora da sua tarefa atual, sua primeira reação não é: "Isso não é meu."

Isso provavelmente não funcionará se: Você quiser passar os próximos 2 anos dentro de um produto, base de código ou área definida de forma estreita. Você precisa de uma especificação detalhada antes de começar a pensar em um problema. Você quer arquitetura separada da implementação. Você prefere entregar infraestrutura, bancos de dados, implantações ou problemas de produção para outra equipe. Você se identifica fortemente com uma linguagem de programação e não quer trabalhar fora dela. Mudanças frequentes de contexto drenam você mais do que interessam. Ou você mede senioridade principalmente pelo quão pouco trabalho prático de engenharia você tem que fazer.

O que estamos procurando: Como guia, isso geralmente significa 5+ anos de experiência em engenharia backend, mas o número importa menos do que o que você possui. Você deve ser capaz de mostrar exemplos onde você: projetou ou mudou significativamente um sistema backend; tomou decisões arquitetônicas e explicou os trade-offs; trabalhou com bancos de dados além de usar um ORM; operou e depurou serviços em produção; entendeu a infraestrutura em vez de tratá-la como uma caixa preta; levou o trabalho de um problema pouco claro a um resultado enviado; aprendeu nova tecnologia quando necessário. Experiência em produção com Go é útil. Forte experiência em backend em outra linguagem, além de evidências de que você aprende novas pilhas rapidamente, também pode funcionar.

Como trabalhamos: Trabalhamos em um portfólio de produtos ao vivo com usuários reais e sistemas existentes. Alguns sistemas precisam ser escalados. Alguns precisam ser simplificados. Alguns precisam ser migrados. Alguns devem ser deixados em paz. Ser capaz de diferenciar isso é importante. Somos remotos e trabalhamos em vários países e fusos horários. Documentamos decisões, comunicamos diretamente e nos preocupamos mais com resultados do que com atividade visível. As prioridades podem mudar quando novas informações aparecem. Um problema de produção pode se tornar mais importante do que o plano de ontem. Esperamos que as pessoas entendam o novo contexto, se ajustem e continuem avançando.

A mentalidade que valorizamos: Pense em sistemas. Entenda como as partes se conectam antes de otimizar uma delas. Pense sobre o produto. A solução tecnicamente elegante não é automaticamente a útil. Assuma a responsabilidade pelo resultado. Não pare em "meu código funciona." Mantenha-se flexível. Seu projeto atual, tecnologia ou prioridade não é seu território. Aprenda rapidamente. O que você sabe importa. Quão rápido você pode entender o que não sabe também importa.

Use julgamento. Alguns problemas merecem 3 dias de investigação. Outros precisam de uma boa decisão em 30 minutos. Mude de ideia quando as evidências mudam.

Uma última coisa: Não estamos contratando você para um aplicativo. Estamos contratando você porque queremos alguém que possa se tornar útil onde quer que esteja o problema de backend mais importante. Se sua pergunta favorita de engenharia é "Como isso tudo realmente funciona?", provavelmente teremos muito o que conversar.

Igualdade de oportunidades para todos: Para representar verdadeiramente nossa vibrante e diversa comunidade BlueThrone, priorizamos diversidade e inclusão. Estamos comprometidos em promover um ambiente onde todos possam fazer o seu melhor trabalho. Encorajamos fortemente candidatos de todas as origens. Consideramos todos os candidatos, independentemente de idade, etnia, religião, sexo, orientação sexual, identidade de gênero, status familiar ou parental, origem nacional, status de veterano, neurodiversidade ou deficiência. Se você precisar de ajustes razoáveis em qualquer momento do processo de candidatura ou entrevista, por favor, nos avise.