Senior .NET Backend Developer — Preguntas de entrevista .NET

¿Cuál es la diferencia entre el GC de workstation y el de server, y cuándo se ajusta?

El GC de workstation ejecuta las recolecciones en el hilo que las disparó, ajustado para pausas cortas en cargas cercanas a UI; el GC de server levanta un heap y un hilo por núcleo, favorece el throughput, y es el predeterminado para apps ASP.NET Core en la mayoría de los escenarios de hosting. El GC concurrente (en segundo plano) permite que las recolecciones de gen 2 corran junto a la app a costa de algo de throughput. Se recurre a dotnet-counters y dotnet-trace para ver tasas de recolección y tiempos de pausa antes de tocar cualquier ajuste — ajustar a ciegas cambia un problema por otro peor.

¿Qué compromiso implica Native AOT frente al modelo estándar de despliegue compilado por JIT?

Native AOT compila de antemano a un ejecutable nativo autocontenido — sin calentamiento de JIT, arranque casi instantáneo, huella más pequeña, lo cual importa en contenedores que escalan a cero o funciones donde el cold start es la métrica que importa. El costo es que la reflexión en tiempo de ejecución, la generación dinámica de código, y algunas librerías de terceros construidas sobre la semántica de JIT se rompen o necesitan anotaciones explícitas de trimming, y el build es específico de plataforma. Vale la pena para un servicio sensible a la latencia con un grafo de dependencias conocido y compatible con AOT, no como opción por defecto.

¿Cómo abordas la contenerización y el despliegue de un servicio ASP.NET Core a producción?

Un Dockerfile multi-etapa compila en la imagen del SDK, publica, y copia solo el resultado a la imagen de runtime de ASP.NET, lo que reduce notablemente el tamaño de la imagen y mantiene el SDK fuera de la superficie de ataque. La configuración viene de variables de entorno y un gestor de secretos — Azure Key Vault, AWS Secrets Manager — nunca embebida en la imagen. En producción importan más que el propio Dockerfile el apagado ordenado mediante IHostApplicationLifetime, los endpoints de health check para el orquestador, y el logging estructurado enviado a algún lugar consultable, porque docker logs sobre un contenedor muerto no es una estrategia de depuración.

Un junior de tu equipo despliega un servicio que pasa todos los tests pero da timeout bajo carga de producción. ¿Cómo lideras la investigación?

Empieza por lo que difiere entre producción y los tests — normalmente la concurrencia y el volumen de datos, que una ejecución de xUnit de un solo hilo por defecto oculta por completo. Saca datos de dotnet-trace o APM en lugar de adivinar, porque "parece la base de datos" es como se pierden horas; la inanición del thread pool por bloquear código async (.Result o .Wait() dentro de un request) se ve idéntica a una consulta lenta hasta que de verdad la investigas. Después del fix, lo más valioso es convertirlo en algo que el equipo pueda comprobar automáticamente — una regla de analizador o un ítem en el checklist de revisión —, para que la misma clase de bug no se despliegue dos veces.

¿Cómo evalúas si conviene migrar una aplicación legacy de .NET Framework a .NET moderno?

Parte de lo que realmente te está bloqueando — hosting exclusivo de Windows, una librería fuera de soporte o un techo de rendimiento real —, porque migrar por migrar consume meses sin hacer avanzar el producto. .NET Framework y .NET moderno divergen más en torno a Web Forms, WCF y algunas librerías muy dependientes de reflection, ninguna con un reemplazo limpio 1:1, así que el costo real está en inventariar justo esos puntos y no en el grueso del código habitual de ASP.NET MVC/Web API. El camino incremental — lo viejo y lo nuevo conviviendo detrás de un reverse proxy, migrando ruta por ruta — entrega valor de forma continua en vez de congelar al equipo en una reescritura de varios trimestres sin nada que mostrar hasta el final.