Perguntas de entrevista para Programador Full Stack em Portugal

Resposta-modelo

Para mim, ser Full Stack é ter responsabilidade end-to-end por uma funcionalidade: desenho a interface, construo a API, modelo os dados e coloco tudo em produção. O valor não está em dominar todas as tecnologias ao mesmo nível, mas em compreender a costura entre as camadas e tomar boas decisões de trade-off — por exemplo, decidir o que resolver no cliente e o que resolver no servidor. Tenho maior profundidade em backend, mas sinto-me confortável a fechar o ciclo até ao ecrã.

Resposta-modelo

Construí o módulo de faturação de uma plataforma de e-commerce. No frontend, desenvolvi o formulário de emissão em React, com validação e acessibilidade; no backend, uma API REST em Node.js que gerava o recibo e comunicava com a Autoridade Tributária; na base de dados, modelei as tabelas em PostgreSQL com atenção à integridade referencial. Coloquei o serviço em produção com Docker e monitorização. O resultado foi a emissão automática de mais de 12.000 recibos por mês, sem intervenção manual.

Resposta-modelo

Parto de três critérios: segurança, desempenho e experiência do utilizador. As regras de negócio críticas e as validações de segurança ficam sempre no backend, porque não posso confiar no cliente. No frontend, trato da resposta imediata ao utilizador — validação de formulário, estados de carregamento, feedback visual. Na dúvida, penso no custo de cada pedido à rede e na manutenção futura. Esta decisão de fronteira é, para mim, o cerne do trabalho de um Full Stack.

Resposta-modelo

A minha ponta mais forte é o backend, por isso invisto conscientemente em manter uma base sólida de frontend. Domino React, TypeScript e boas práticas de acessibilidade e acompanho a evolução do ecossistema, mas reconheço que não sou especialista em animações complexas nem em otimizações finas de renderização. Em equipa, sei quando pedir apoio a um especialista de frontend — e o mesmo aconteceria ao contrário.

Resposta-modelo

Já trabalhei nesse contexto e gosto da responsabilidade, mas encaro-a com disciplina. Documento as decisões, automatizo o que posso (testes, CI/CD, cópias de segurança) e priorizo pela criticidade para o negócio. Também defino limites claros: sendo responsável por tudo, tenho de resistir à tentação de fazer tudo ao mesmo tempo. Quando o risco técnico cresce, sinalizo à gestão a necessidade de reforçar a equipa ou de trazer um especialista.

Resposta-modelo

Uso testes automatizados a vários níveis — unitários, de integração e alguns end-to-end — e integro-os na pipeline de CI/CD, para que nada chegue a produção sem passar. Em segurança, sigo boas práticas como a validação no servidor, a proteção contra injeção de SQL e XSS, e a gestão cuidada de segredos. Em Portugal, tenho ainda especial atenção ao RGPD: minimização de dados, encriptação e registos de acesso, em linha com as orientações da CNPD.

REST expõe recursos em endpoints distintos, é simples, tira partido da cache HTTP e é amplamente suportado. GraphQL expõe um único endpoint e permite ao cliente pedir exatamente os campos de que precisa, reduzindo o over-fetching. Escolheria REST para APIs simples ou públicas, ou quando a cache HTTP é importante; escolheria GraphQL quando o frontend tem necessidades de dados muito variáveis e quero evitar múltiplos pedidos. Já usei ambas e a decisão depende sempre do consumidor da API.

O problema N+1 surge quando, para uma lista de registos, se faz uma consulta adicional por cada elemento. Resolvo-o carregando os dados relacionados de uma só vez — com JOIN ou com eager loading no ORM — em vez de consultas dentro de um ciclo. Monitorizo as consultas efetivamente executadas (por exemplo, pelos registos do ORM ou por uma ferramenta de APM) e acrescento índices nas colunas de junção. É um dos pontos em que a minha experiência de backend melhora diretamente o desempenho que o utilizador sente no ecrã.

Um JWT é um token assinado que transporta informação sobre o utilizador; o servidor valida a assinatura sem guardar estado. Uso-o para autenticação sem sessão no servidor, mas com cuidados: tempos de expiração curtos, refresh tokens guardados de forma segura e nunca colocar dados sensíveis no payload, porque este é apenas codificado, não encriptado. Em aplicações web, prefiro guardar o token em cookies HttpOnly para mitigar ataques de XSS.

Trabalho as duas pontas. No frontend, faço code splitting, carregamento diferido de imagens, minificação e uso da cache do navegador. No backend, otimizo consultas, acrescento índices e uso cache (por exemplo, Redis) para respostas frequentes. Meço sempre o antes e o depois com ferramentas como o Lighthouse e reduzo o número de pedidos à rede. A vantagem de ser Full Stack é poder atacar o gargalo onde ele realmente está, seja no cliente, seja no servidor.

Começo por estabilizar: consulto a monitorização e os registos para avaliar o impacto e, se for necessário, faço rollback para a última versão estável. Depois isolo a camada — reproduzo o pedido diretamente à API para separar o que é backend do que é frontend e analiso a consola do navegador e o separador de rede no lado do cliente. Sendo Full Stack, consigo seguir o fluxo de ponta a ponta sem esperar por outra equipa, o que acelera o diagnóstico. No fim, documento a causa e acrescento um teste para evitar a repetição.

Explico o trade-off em termos de negócio, não apenas técnicos: proponho uma versão mínima que entregue valor rapidamente e um plano para a solução completa a seguir, deixando claro o que fica como dívida técnica. Assim, a decisão passa a ser informada e partilhada com a gestão, em vez de eu assumir sozinho um risco que afeta o produto. Registo o compromisso para que a dívida não seja esquecida.

Primeiro procuro compreender o raciocínio dele, porque pode existir contexto que desconheço. Depois exponho a minha preocupação com dados — um teste, um valor de desempenho ou um risco concreto — em vez de opiniões. Se, ainda assim, a decisão for outra, alinho-me e acompanho o resultado; se o meu receio se confirmar, trago-o de volta com factos. O objetivo é o melhor resultado para o produto, não ter razão.

Começo por criar uma rede de segurança: escrevo alguns testes de caracterização que capturam o comportamento atual, mesmo antes de compreender tudo. Depois faço pequenas alterações incrementais, sempre com os testes a correr, e vou documentando o que descubro. Evito a tentação de reescrever tudo de imediato; primeiro entrego a funcionalidade com risco controlado e proponho a melhoria gradual da base de código.