Preguntas para la entrevista de Platform Engineer

Los responsables de contratación en empresas con equipos de plataforma maduros informan que el 60 % de los candidatos fracasan en las entrevistas técnicas no por falta de conocimiento específico de herramientas, sino por carencia de pensamiento en diseño de sistemas y la capacidad de explicar decisiones de infraestructura en términos de negocio [1]. Las entrevistas de Platform Engineering se diferencian de las entrevistas generales de DevOps en un aspecto crítico: los entrevistadores evalúan si piensas en la infraestructura como un producto interno. Un candidato que puede explicar cómo midió la satisfacción de los desarrolladores con su plataforma de Kubernetes demuestra una mentalidad fundamentalmente diferente a alguien que solo describe la configuración del clúster.

Puntos clave

• Espera una entrevista en tres etapas: ajuste conductual/cultural, profundización técnica y diseño de sistemas
• Las preguntas conductuales se centran en el pensamiento de plataforma como producto: empatía con el desarrollador, colaboración entre equipos y liderazgo en incidentes
• Las preguntas técnicas evalúan los componentes internos de Kubernetes, el diseño de IaC y la arquitectura de observabilidad — no solo el uso superficial de herramientas
• Los escenarios situacionales evalúan cómo priorizas demandas de plataforma en competencia de múltiples equipos
• Prepara 4–5 historias STAR que cubran impacto en la plataforma, respuesta a incidentes y mejoras en la experiencia del desarrollador
• Ten listas 3–5 preguntas que demuestren que has investigado los desafíos de infraestructura de la empresa

Preguntas conductuales (formato STAR)

1. Describe una situación en la que creaste una funcionalidad de plataforma que los desarrolladores rechazaron inicialmente. ¿Cómo impulsaste la adopción?

**Por qué hacen esta pregunta:** Los Platform Engineers construyen productos internos. La adopción es la métrica definitiva. Esta pregunta evalúa si comprendes la gestión del cambio y la empatía con el desarrollador, no solo la implementación técnica.

**Marco de respuesta STAR sólido:**

• **Situación:** Los desarrolladores creaban más de 50 tickets de infraestructura semanales para aprovisionamiento de bases de datos, con tiempos de espera promedio de 4 horas
• **Tarea:** Propusiste un sistema de aprovisionamiento de bases de datos en autoservicio a través del portal de la plataforma, pero los equipos de ingeniería eran escépticos sobre la seguridad y fiabilidad
• **Acción:** Realizaste entrevistas con desarrolladores para entender sus preocupaciones, construiste un piloto con un equipo dispuesto, demostraste que las bases de datos aprovisionadas cumplían los mismos estándares de seguridad que las creadas manualmente y publicaste métricas de adopción después del piloto
• **Resultado:** La adopción creció de 1 equipo a 12 equipos en 3 meses. Los tickets de infraestructura se redujeron un 67 %. La satisfacción de los desarrolladores con el aprovisionamiento aumentó de 3,2/10 a 8,4/10

2. Cuéntame sobre el incidente de producción más complejo que lideraste como comandante de incidentes. ¿Cuál fue la causa raíz y qué medidas preventivas implementaste?

**Por qué hacen esta pregunta:** Los Platform Engineers son responsables de la fiabilidad en producción. Esto evalúa el liderazgo en incidentes, la profundidad de depuración técnica y el seguimiento en prevención.

**Marco de respuesta STAR sólido:**

• **Situación:** Fallo de red multi-clúster que causaba errores intermitentes de comunicación servicio a servicio en 3 clústeres EKS durante horas pico
• **Tarea:** Comandante de incidentes responsable del diagnóstico, mitigación y comunicación a más de 200 ingenieros afectados
• **Acción:** Correlación de registros de error del proxy Istio con cambios de Calico NetworkPolicy desplegados 2 horas antes, identificación de una política que bloqueaba tráfico entre namespaces, reversión del cambio de política e implementación de un marco de pruebas de políticas de red previo al despliegue
• **Resultado:** MTTR de 23 minutos (dentro del SLO). Post-incidente: implementación de una política OPA que valida cambios de NetworkPolicy contra una matriz de pruebas antes del despliegue, reduciendo incidentes relacionados con políticas de red de 4 por trimestre a 0 en 6 meses

3. Describe una situación en la que dos equipos de producto tenían requisitos conflictivos para la plataforma. ¿Cómo lo resolviste?

**Por qué hacen esta pregunta:** Los Platform Engineers atienden a múltiples clientes internos simultáneamente. Esto evalúa la priorización, la gestión de stakeholders y el pensamiento de producto.

**Marco de respuesta sólido:** Un equipo necesitaba pools de nodos GPU para cargas de trabajo de ML; otro necesitaba el mismo presupuesto para capacidad adicional de cómputo general. Analizaste patrones de uso, propusiste un pool de nodos GPU compartido con instancias preemptibles y planificación basada en colas que atendía ambas necesidades al 60 % del costo combinado, y estableciste un marco de gobernanza de recursos para conflictos futuros.

4. Cuéntame sobre una situación en la que tuviste que convencer al liderazgo de ingeniería de invertir en infraestructura de plataforma en lugar de desarrollo de funcionalidades.

**Por qué hacen esta pregunta:** El trabajo de plataforma compite con las funcionalidades de producto por la inversión en ingeniería. Esto evalúa tu capacidad para comunicar el valor de la infraestructura en términos de negocio.

**Marco de respuesta sólido:** Cuantifica el costo de no invertir: horas de desarrollador perdidas en aprovisionamiento manual, frecuencia de incidentes por desviación de configuración, tiempo de incorporación para nuevos ingenieros. Presenta la inversión en plataforma como un multiplicador de fuerza: «Una inversión de 400.000 $ en plataforma elimina 8.000 horas-desarrollador de trabajo rutinario de infraestructura anualmente, equivalente a 4 ingenieros a tiempo completo.»

5. Describe cómo has medido el éxito de una plataforma que construiste. ¿Qué métricas monitoreaste?

**Por qué hacen esta pregunta:** El pensamiento de producto requiere medición. Esta pregunta revela si tratas las plataformas como productos con KPIs o simplemente como infraestructura que funciona.

**Marco de respuesta sólido:** Monitorea métricas DORA (frecuencia de despliegue, tiempo de entrega, tasa de fallo de cambios, MTTR), encuestas de satisfacción de desarrolladores (NPS o CSAT trimestrales), tasas de adopción de autoservicio, tiempo hasta el primer despliegue para nuevos ingenieros, SLOs de disponibilidad de plataforma y costo de infraestructura por despliegue.

6. Cuéntame sobre una decisión técnica que tomaste para la plataforma y que luego te diste cuenta de que era incorrecta. ¿Qué hiciste?

**Por qué hacen esta pregunta:** Evalúa la honestidad intelectual, la orientación al aprendizaje y la capacidad de corregir el rumbo a escala de infraestructura.

**Marco de respuesta sólido:** Ejemplo: elegiste Helm para toda la gestión de configuración, luego te diste cuenta de que Kustomize era más adecuado para superposiciones de entornos. Cuantifica el impacto del error, describe el plan de migración, explica qué aprendiste sobre los criterios de evaluación y describe cómo cambiaste tu proceso de toma de decisiones (p. ej., implementación de ADRs con criterios de evaluación explícitos).

Preguntas técnicas

1. Guíame a través de lo que sucede cuando se programa un pod en Kubernetes, desde el momento en que aplicas un manifiesto de Deployment hasta que el contenedor está en ejecución.

**Qué se evalúa:** Profundidad del conocimiento de los componentes internos de Kubernetes. Respuesta superficial: «kubectl lo envía al servidor API y se ejecuta.» La respuesta profunda traza: kubectl → servidor API (autenticación, autorización, admission controllers) → persistencia en etcd → scheduler (filtrado, puntuación, vinculación) → kubelet en el nodo seleccionado → llamada CRI al runtime de contenedores (containerd) → plugin CNI para networking → prueba de readiness superada → registro del endpoint. Menciona preemption, impacto de resource requests/limits en la programación y topology spread constraints para puntos adicionales.

2. Necesitas diseñar una estrategia de módulos de Terraform para una organización con 15 equipos de producto. ¿Cómo estructuras los módulos, el estado y los permisos?

**Qué se evalúa:** Pensamiento de arquitectura IaC, no solo conocimiento de sintaxis. Cubre: composición de módulos (módulos base para primitivas, módulos compuestos para patrones), aislamiento de estado (por equipo, por entorno o por servicio), configuración de backend remoto (S3 + DynamoDB locking), RBAC a través de IAM y workspaces de Terraform Cloud/Spacelift, versionado de módulos y flujo de trabajo de releases, y estrategia de detección de drift.

3. Explica cómo implementarías actualizaciones de Kubernetes sin tiempo de inactividad para un clúster con más de 500 pods en 30 namespaces.

**Qué se evalúa:** Madurez operativa. Cubre: PodDisruptionBudgets para todas las cargas de trabajo críticas, actualizaciones progresivas de pools de nodos (cordoning, draining, reemplazo), política de desviación de versión del servidor API (kubelet puede estar una versión menor por detrás), validación previa a la actualización (verificaciones de APIs obsoletas con kubent o pluto), estrategia de clúster canario (actualizar primero no-producción, luego un clúster de producción antes de toda la flota), monitoreo durante la actualización (tasas de reinicio de pods, tasas de error, latencia de scheduling) y procedimientos de rollback.

4. ¿Cómo diseñarías un stack de observabilidad para una plataforma que sirve 50 microservicios? Guíame a través de métricas, logs y trazas.

**Qué se evalúa:** Arquitectura de observabilidad. Cubre: capa de métricas (Prometheus con federation o Thanos para almacenamiento a largo plazo, recording rules para SLOs), logs (Fluent Bit DaemonSet → Loki con políticas de retención apropiadas, estándares de logging estructurado), trazas (instrumentación con SDK de OpenTelemetry → collector → Tempo/Jaeger), correlación (exemplars que vinculan métricas con trazas, trace IDs en logs), alertas (alertas de error budget basadas en SLO en lugar de alertas por umbral) y autoservicio (Grafana con dashboards con alcance por equipo y plantillas con variables).

5. Un desarrollador informa que su despliegue tarda 45 minutos. ¿Cómo diagnosticas y optimizas esto?

**Qué se evalúa:** Depuración sistemática y optimización. Traza el pipeline: tiempo de checkout de código, instalación de dependencias (estrategias de caché), tiempo de build (Docker builds multi-etapa, caché de build, optimización de capas), ejecución de tests (test runners paralelos, splitting de tests), tiempo de push de imagen (proximidad del registro, deduplicación de capas), tiempo de sync de ArgoCD (sync waves, resource hooks) y tiempo de scheduling de pods (image pull, init containers, readiness probes). Identifica el cuello de botella antes de optimizar — pregunta cuál es el desglose actual.

6. Explica la diferencia entre Kyverno y OPA/Gatekeeper. ¿Cuándo elegirías cada uno?

**Qué se evalúa:** Profundidad en herramientas de seguridad. OPA/Gatekeeper usa el lenguaje de políticas Rego (poderoso pero con curva de aprendizaje pronunciada), se ejecuta como webhook de admisión y sobresale en políticas complejas entre recursos. Kyverno usa políticas YAML nativas de Kubernetes (curva de aprendizaje más baja), soporta políticas de validación, mutación y generación, y se integra más naturalmente con los conceptos de Kubernetes. Elige Gatekeeper para organizaciones con experiencia existente en Rego o requisitos de políticas complejas. Elige Kyverno para equipos que desean gestión de políticas nativa de Kubernetes con menor fricción de adopción.

7. ¿Cómo funciona la reconciliación de ArgoCD y cómo la configurarías para un entorno multi-clúster con más de 200 aplicaciones?

**Qué se evalúa:** Profundidad en GitOps. Cubre: ArgoCD consulta repos git en intervalos configurables (3 minutos por defecto), compara el estado deseado (git) con el estado en vivo (clúster) y reconcilia las diferencias. Para escalar: ApplicationSets con generadores (git, cluster, matrix), patrón App of Apps para gestión jerárquica, RBAC a nivel de proyecto para control de acceso multi-tenant, exclusión de recursos para recursos ruidosos y ventanas de sync para control de cambios en producción. Discute triggers de sync basados en webhooks para reconciliación más rápida cuando sea necesario.

Preguntas situacionales

1. Tu equipo de plataforma de 5 personas recibe solicitudes de 8 equipos de producto simultáneamente. ¿Cómo priorizas?

**Qué se evalúa:** Habilidades de gestión de producto y stakeholders. Marco: categoriza por impacto (número de desarrolladores afectados × severidad del problema), urgencia (bloquea despliegues vs. deseable) y alineación estratégica (apoya iniciativas de toda la empresa vs. necesidades de un solo equipo). Establece un proceso de intake transparente: reunión semanal de priorización con líderes de equipo, hoja de ruta de plataforma publicada, SLAs claros para diferentes tipos de solicitudes (incidencias P0 bloqueantes: mismo día; solicitudes de funcionalidades: planificación de sprint).

2. Un nuevo CTO quiere migrar toda la infraestructura de AWS a GCP en 6 meses. ¿Cómo evalúas y planificas esto?

**Qué se evalúa:** Pensamiento estratégico bajo presión. Comienza con la evaluación de impacto: inventario de todos los servicios de AWS utilizados, identificación de equivalentes en GCP, estimación de costos de transferencia de datos y cronograma. Evalúa el riesgo: identifica servicios sin equivalente limpio en GCP (p. ej., servicios gestionados específicos). Propón un enfoque por fases: primero abstraer la infraestructura a través de módulos de Terraform (reduciendo el acoplamiento específico a la nube), migrar servicios no críticos como prueba de concepto, luego servicios de producción con capacidad de rollback. Cuestiona el plazo de 6 meses con evidencia si es poco realista.

3. Tu clúster de Kubernetes experimenta desalojos intermitentes de pods durante el horario laboral. Guíame a través de tu investigación.

**Qué se evalúa:** Resolución sistemática de problemas. Verifica la presión de recursos a nivel de nodo (memoria, disco, límites de PID) a través de kubectl describe node y busca eventos de desalojo del Kubelet. Examina resource requests vs. uso real — los pods sin requests son los primeros en ser desalojados. Verifica efectos de vecino ruidoso (un pod que consume recursos excesivos en nodos compartidos). Revisa los logs de Karpenter/Cluster Autoscaler para retrasos en el escalado. Verifica conflictos de recursos de DaemonSet. Implementa Resource Quotas y LimitRanges para prevenir el sobreaprovisionamiento futuro.

4. Descubres que el 40 % de tus archivos de estado de Terraform no se han aplicado en 6 meses y se ha acumulado drift. ¿Cuál es tu plan de remediación?

**Qué se evalúa:** Disciplina operativa de IaC. No ejecutes terraform apply a ciegas — eso destruye recursos de los que la gente puede depender. Comienza con terraform plan para cada archivo de estado, categoriza el drift en: (1) cambios intencionales hechos fuera de Terraform (necesitan ser importados o actualizar el código), (2) drift no intencional (necesita aplicarse), (3) recursos abandonados (necesitan limpiarse). Implementa detección continua de drift (Spacelift, Atlantis o ejecuciones de plan programadas) para prevenir recurrencias. Establece una política de gobernanza: todos los cambios de infraestructura deben pasar por PRs de Terraform.

5. Un VP de ingeniería te pide que des a su equipo acceso directo a los clústeres de Kubernetes de producción para depuración. ¿Cómo lo manejas?

**Qué se evalúa:** Criterio de seguridad y comunicación con stakeholders. El acceso directo al clúster crea riesgo de seguridad y auditoría. Propón alternativas: acceso kubectl de solo lectura limitado a su namespace vía RBAC, dashboards de Grafana con observabilidad a nivel de pod, un flujo de trabajo de contenedores de depuración (ephemeral containers) que proporciona acceso a shell sin modificar pods en ejecución, y agregación de logs que da visibilidad sin credenciales del clúster. Si insisten, implementa acceso con tiempo limitado con registro de auditoría (Teleport, Boundary) y revocación automática.

Criterios de evaluación que usan los entrevistadores

**Profundidad técnica (40 %):** ¿Puedes explicar cómo funcionan los sistemas a nivel de componentes, no solo configurarlos? Las preguntas sobre programación de pods y arquitectura de Terraform evalúan esto.

**Diseño de sistemas (25 %):** ¿Puedes diseñar componentes de plataforma que sirvan a múltiples equipos a escala? Las preguntas sobre el stack de observabilidad y ArgoCD multi-clúster evalúan esto.

**Producto y comunicación (20 %):** ¿Puedes explicar decisiones de infraestructura en términos de negocio? ¿Puedes priorizar demandas en competencia? Las preguntas conductuales y el escenario de priorización evalúan esto.

**Incidentes y operaciones (15 %):** ¿Puedes diagnosticar sistemáticamente problemas de producción y prevenir recurrencias? La pregunta sobre comandante de incidentes y el escenario de desalojo de pods evalúan esto.

Ejemplos del método STAR para Platform Engineering

**Plantilla:**

• **Situación:** Establece el contexto con datos específicos (tamaño de la empresa, tamaño del equipo, escala de infraestructura)
• **Tarea:** Define tu responsabilidad específica (no la del equipo)
• **Acción:** Describe los pasos concretos que tomaste (herramientas, decisiones, comunicación)
• **Resultado:** Cuantifica el resultado (métricas, tasas de adopción, ahorro de costos, ahorro de tiempo)

**Ejemplo: Construcción de una plataforma de autoservicio**

• **S:** En [Empresa] (300 ingenieros, 40 microservicios), los desarrolladores esperaban un promedio de 3 días para el aprovisionamiento de infraestructura, creando más de 200 tickets mensuales
• **T:** Fui encargado de diseñar un catálogo de infraestructura de autoservicio para eliminar los cuellos de botella de aprovisionamiento
• **A:** Construí un catálogo basado en Crossplane con 12 plantillas de recursos gestionados (bases de datos, cachés, colas, buckets de almacenamiento), integrado con Backstage para una interfaz amigable para desarrolladores, implementé flujos de trabajo de aprobación para recursos de producción y creé documentación completa con tutoriales en video
• **R:** El tiempo de aprovisionamiento se redujo de 3 días a 15 minutos. Los tickets mensuales de infraestructura disminuyeron un 78 %. La satisfacción de los desarrolladores con el aprovisionamiento mejoró de 2,8/10 a 8,6/10. El catálogo procesó más de 150 solicitudes de aprovisionamiento en el primer trimestre sin configuraciones erróneas

Preguntas para el entrevistador

1. **«¿Cómo mide el éxito el equipo de plataforma? ¿Qué KPIs o SLOs monitorean?»** — Evalúa si tienen una mentalidad de producto o funcionan como soporte reactivo.
2. **«¿Cuál es el punto de dolor actual de la experiencia del desarrollador que el equipo de plataforma está priorizando?»** — Muestra que piensas en las necesidades de los desarrolladores y revela el trabajo real que harías.
3. **«¿Cómo está estructurado el equipo de plataforma en relación con los equipos de producto? ¿Siguen un modelo de Team Topologies?»** — Demuestra conciencia organizacional y te ayuda a evaluar la autonomía del equipo.
4. **«¿Cuál es su frecuencia de despliegue actual y dónde está el cuello de botella?»** — Señala que piensas en métricas DORA y te enfocas en mejoras medibles.
5. **«¿Cuál es la decisión de infraestructura más controvertida que el equipo ha tomado recientemente?»** — Revela la cultura de toma de decisiones, la conciencia de deuda técnica y la apertura a la discusión.
6. **«¿Cómo es la guardia para el equipo de plataforma? ¿Con qué frecuencia se alerta a los ingenieros y cuál es la severidad promedio de los incidentes?»** — Pregunta práctica que revela madurez operativa y equilibrio entre vida laboral y personal.
7. **«¿Existe un proceso de revisión de arquitectura o RFC para cambios significativos en la plataforma?»** — Muestra que valoras la toma de decisiones deliberada y la cultura de documentación.

Conclusiones finales

Las entrevistas de Platform Engineering evalúan tres dimensiones: profundidad técnica en Kubernetes, IaC e infraestructura en la nube; pensamiento de producto sobre experiencia del desarrollador y adopción de plataforma; y madurez operativa en respuesta a incidentes y depuración de sistemas. Prepárate construyendo historias STAR en torno a resultados medibles de plataforma (no solo uso de herramientas), practicando preguntas de diseño de sistemas que abarquen múltiples componentes de infraestructura, e investigando los desafíos específicos de infraestructura de la empresa a través de su blog de ingeniería, repos open source y charlas en conferencias. Los candidatos que se destacan explican no solo qué construyeron, sino por qué lo construyeron, cómo midieron su éxito y qué harían diferente la próxima vez.

Preguntas frecuentes

¿Cuántas rondas de entrevista debo esperar para un puesto de Platform Engineer?

Típicamente 4–5 rondas: filtro con reclutador (30 min), conductual con el gerente de contratación (45–60 min), profundización técnica con un ingeniero senior (60–90 min), diseño de sistemas con un ingeniero staff+ (60 min) y panel de equipo/ajuste cultural (45–60 min). Algunas empresas añaden un ejercicio para llevar a casa (diseño de módulo de Terraform, escenario de resolución de problemas de Kubernetes) como filtro previo o alternativa a la ronda técnica en vivo. Duración total del proceso: 2–4 semanas desde el primer contacto hasta la oferta.

¿Debería prepararme de manera diferente para una startup versus una empresa grande?

Sí. Las startups enfatizan amplitud y velocidad — quieren ingenieros que puedan construir una plataforma desde cero en múltiples dominios (CI/CD, observabilidad, Kubernetes, seguridad) sin esperar a miembros especializados del equipo. Las empresas grandes enfatizan profundidad en dominios específicos y la capacidad de trabajar dentro de patrones establecidos a escala. Las entrevistas en startups a menudo incluyen ejercicios prácticos (construir/arreglar algo); las entrevistas en empresas grandes tienden a sesiones de diseño de sistemas en pizarra.

¿Qué tan importante es la capacidad de programación en Go en las entrevistas de Platform Engineering?

Cada vez más importante a partir del nivel medio. Si la empresa construye operadores de Kubernetes, proveedores de Terraform o herramientas CLI personalizadas, Go es prácticamente obligatorio. Los candidatos junior pueden demostrar competencia en Python y Bash como punto de partida. Cuando aparecen preguntas de Go, típicamente se centran en comprender la biblioteca client-go de Kubernetes, escribir loops de reconciliación y entender patrones de concurrencia de Go relevantes para herramientas de infraestructura.

¿Qué pasa si no tengo experiencia con las herramientas específicas que usa la empresa?

Céntrate en conceptos transferibles. Si conoces ArgoCD pero ellos usan Flux, explica los principios de GitOps y los patrones de reconciliación — los conceptos son idénticos. Si conoces AWS pero ellos usan GCP, discute Kubernetes (agnóstico del proveedor) y patrones de diseño de módulos de Terraform. Los entrevistadores en empresas bien gestionadas evalúan la comprensión conceptual por encima de la experiencia específica en herramientas, porque las herramientas cambian más rápido que los principios.

**Citas:** [1] DORA / Google Cloud, "2024 Accelerate State of DevOps Report," dora.dev, 2024.