Senior .NET Backend Developer — Perguntas de entrevista .NET

Qual é a diferença entre o GC workstation e o server, e quando você ajusta isso?

O GC workstation executa coletas na thread que as disparou, ajustado para pausas curtas em cargas próximas de UI; o GC server sobe uma heap e uma thread por núcleo, favorece throughput, e é o padrão para apps ASP.NET Core na maioria dos cenários de hospedagem. O GC concorrente (em segundo plano) deixa coletas de gen 2 rodarem junto com a aplicação ao custo de algum throughput. Você recorre a dotnet-counters e dotnet-trace para ver taxas de coleta e tempos de pausa antes de mexer em qualquer configuração — ajustar às cegas troca um problema por outro pior.

Que troca o Native AOT faz em relação ao modelo padrão de deploy compilado por JIT?

O Native AOT compila antecipadamente para um executável nativo autocontido — sem aquecimento do JIT, início quase instantâneo, footprint menor, o que importa para containers que escalam a zero ou functions onde o cold start é a métrica que importa. O custo é que reflection em tempo de execução, geração dinâmica de código, e algumas bibliotecas de terceiros construídas em torno da semântica do JIT quebram ou precisam de anotações explícitas de trimming, e o build é específico de plataforma. Vale a pena para um serviço sensível a latência com um grafo de dependências conhecido e compatível com AOT, não como padrão para todo projeto.

Como você aborda a containerização e o deploy de um serviço ASP.NET Core em produção?

Um Dockerfile multi-stage compila na imagem do SDK, publica, e copia apenas o resultado para a imagem de runtime do ASP.NET, o que reduz bastante o tamanho da imagem e mantém o SDK fora da superfície de ataque. A configuração vem de variáveis de ambiente e um gerenciador de segredos — Azure Key Vault, AWS Secrets Manager — nunca embutida na imagem. Em produção, importam mais que o próprio Dockerfile o graceful shutdown via IHostApplicationLifetime, endpoints de health check para o orquestrador, e logging estruturado enviado para algum lugar pesquisável, porque docker logs num container morto não é uma estratégia de debug.

Um júnior do seu time entrega um serviço que passa em todos os testes, mas dá timeout sob carga de produção. Como você conduz a investigação?

Comece pelo que difere entre produção e os testes — geralmente concorrência e volume de dados, que uma execução padrão de thread única do xUnit esconde completamente. Puxe dados do dotnet-trace ou de APM em vez de chutar, porque "parece coisa do banco" é como se perdem horas; a inanição do thread pool por bloquear código async (.Result ou .Wait() dentro de um request) parece idêntica a uma consulta lenta até você realmente investigar. Depois do fix, o movimento mais valioso é transformar isso em algo que o time possa checar automaticamente — uma regra de analyzer ou um item no checklist de revisão —, para que a mesma classe de bug não seja lançada duas vezes.

Como você avalia se vale a pena migrar uma aplicação legada em .NET Framework para o .NET moderno?

Comece pelo que realmente está limitando — hospedagem só em Windows, uma biblioteca fora de suporte ou um teto real de performance —, porque migrar por migrar consome meses sem fazer o produto avançar. O .NET Framework e o .NET moderno divergem mais em torno de Web Forms, WCF e algumas bibliotecas muito dependentes de reflection, nenhuma com substituto limpo 1:1, então o custo real está em inventariar exatamente esses pontos, não no grosso do código comum de ASP.NET MVC/Web API. O caminho incremental — o antigo e o novo convivendo atrás de um reverse proxy, migrando rota por rota — entrega valor de forma contínua em vez de congelar o time numa reescrita de vários trimestres sem nada para mostrar até o fim.