Problema

Muchas empresas buscan ingenieros de infraestructura que dominen Linux, automatización con Ansible/Terraform y conceptos de SRE, pero al mismo tiempo exigen experiencia en producción, on‑call y gestión de incidentes reales. Los candidatos autodidactas con homelabs robustos a menudo se encuentran frente a una pared: su CV muestra proyectos complejos, pero carece de la palabra “producción”. Los reclutadores y líderes de equipo deben decidir si esa falta de experiencia es un obstáculo insalvable o si la profundidad técnica compensa la ausencia de historial en entornos críticos.

Causa

  1. Sesgo hacia la experiencia “real”
    La cultura de muchas organizaciones valora la exposición a incidentes con impacto financiero porque asume que la presión del negocio es la única forma de validar habilidades de diagnóstico y gestión de cambios.

  2. Falta de métricas objetivas
    Sin un marco de referencia, los CV se evalúan de forma subjetiva. Un proyecto de homelab que incluye Terraform, Ansible y Kubernetes puede parecer similar a una implementación productiva, pero no hay indicadores claros de escala, SLA o blast radius.

  3. Desconocimiento de la calidad de los proyectos DIY
    Los entrevistadores a veces no saben distinguir entre “juguete” y “plataforma preparada para producción”. La ausencia de certificaciones oficiales refuerza la percepción de que el candidato no ha pasado por procesos formales de revisión.

  4. Miedo al riesgo de contratación
    Incorporar a alguien sin historial de on‑call puede percibirse como un riesgo para la continuidad del servicio, sobre todo en entornos financieros o de trading donde los costos de un error son altos.

Solución

Adoptar un proceso de evaluación estructurado que mida profundidad técnica y potencial de aprendizaje por separado de la experiencia operativa. El proceso consta de tres fases:

1. Pre‑screen técnico basado en artefactos

Solicita al candidato enlaces a repositorios, diagramas de arquitectura y documentación de procesos. Evalúa los siguientes criterios:

Criterio Qué buscar Por qué importa
Modularidad y separación de responsabilidades Terraform gestiona infraestructura, Ansible se encarga del bootstrap, GitOps controla despliegues. Demuestra comprensión de la cadena de suministro y evita “todo en un script”.
Idempotencia y pruebas de convergencia Playbooks con check_mode, pipelines CI que ejecutan terraform plan y ansible‑lint. Indica que el candidato piensa en reproducibilidad y en evitar drift.
Manejo de secretos Uso de Vault, sops o variables encriptadas, nunca hard‑codeado. Refleja buenas prácticas de seguridad, crucial en entornos de trading.
Observabilidad integrada Exporters de Prometheus, alertas predefinidas, dashboards de Grafana. Muestra que el candidato entiende que la monitorización es parte del ciclo de vida.
Documentación operativa Runbooks, procedimientos de rollback, checklist de cambios. Señala que el candidato está habituado a procesos de cambio controlado.

Califica cada criterio de 0 a 2. Un puntaje ≥ 8/10 indica que la base técnica es suficientemente profunda para pasar a la siguiente fase, independientemente de la falta de producción.

2. Entrevista práctica de troubleshooting

Diseña un escenario controlado que reproduzca un fallo típico en producción, pero sin riesgo real. Por ejemplo, un contenedor que no arranca porque el servicio systemd falla al montar un volumen. Provee al candidato acceso a una VM mínima con:

  • Un servicio myapp.service que depende de un socket TCP.
  • Un archivo de configuración generado por Ansible.
  • Un registro de logs con mensajes de error.

Pide que:

  1. Identifique la causa raíz usando journalctl, systemctl status y strace si es necesario.
  2. Proponga una solución que no requiera reiniciar todo el nodo.
  3. Documente brevemente el procedimiento de rollback.

Evalúa:

  • Metodología: ¿Empieza por los síntomas, revisa logs, verifica dependencias?
  • Conocimiento de herramientas: uso de systemd-analyze, tcpdump, diff de configuraciones.
  • Calidad de la solución: idempotencia, mínima interrupción, validación post‑cambio.
  • Comunicación: claridad del runbook generado.

Esta fase mide la capacidad de diagnóstico bajo presión, algo que la experiencia en producción suele desarrollar, pero que también puede observarse en candidatos autodidactas.

3. Evaluación de potencial de integración

En la entrevista de comportamiento, aborda temas como:

  • Gestión de cambios: “Describe cómo planificarías una actualización que afecta a 30 servidores críticos”.
  • Trabajo en equipo: “Cuéntame una vez que tu código fue revisado y necesitaste adaptarte a la opinión de otro”.
  • Aprendizaje continuo: “¿Qué recursos utilizas para mantenerte al día con nuevas versiones de Ansible o Kubernetes?”.

Busca evidencia de mentalidad de mejora continua y disposición a seguir procesos formales. Un candidato que ha documentado sus proyectos y ha adoptado CI/CD muestra que ya está familiarizado con la cultura de equipos de producción.

Cuándo aplicar esta solución

Utiliza este marco cuando:

  • El puesto requiere dominio de Linux, automatización y conceptos de SRE, pero la empresa está abierta a contratar talento emergente.
  • El número de candidatos con experiencia “clásica” es limitado y necesitas ampliar el pool.
  • Quieres reducir el sesgo de “solo experiencia en producción” y valorar la calidad del código y la capacidad de aprendizaje.

No lo apliques si:

  • El rol implica acceso a datos regulatorios críticos donde la certificación y la experiencia comprobada son requisitos legales.
  • La empresa no tiene capacidad para proporcionar un programa de mentoría o onboarding intensivo; en ese caso la falta de experiencia se vuelve un riesgo mayor.

Verificación

  1. Revisa el historial de commits: busca patrones de commits atómicos, mensajes claros y PRs revisados.
  2. Ejecuta los scripts en una sandbox: verifica que los playbooks sean idempotentes y que los terraform plan no generen cambios inesperados.
  3. Simula un incidente: durante la entrevista práctica, mide el tiempo que tarda el candidato en llegar a la causa raíz y la claridad del runbook.
  4. Solicita referencias: si el candidato ha colaborado en proyectos open‑source, revisa los comentarios de mantenedores para confirmar su capacidad de trabajo en equipo.

Notas adicionales

  • No sobrevalores los “certificados”. Un certificado de Ansible o Terraform es útil, pero no sustituye la evidencia de código real y pruebas de integración.
  • El “blast radius” en homelab puede escalar usando herramientas como kube‑kind o minikube con varios nodos simulados; esto permite observar cómo el candidato maneja fallos en clústeres distribuidos.
  • Mentoría interna acelera la curva de aprendizaje. Si decides contratar, asigna un SRE senior como “buddy” durante los primeros 90 días; esto reduce el riesgo de errores críticos.
  • Comunica claramente las expectativas durante la entrevista: si el rol incluye on‑call, explica la frecuencia típica de incidentes y los SLAs asociados. La transparencia evita sorpresas posteriores.

Adoptar este proceso permite a los equipos de infraestructura abrir sus puertas a talentos autodidactas que ya demuestran una base sólida, sin sacrificar la seguridad operativa que exige un entorno de producción. Con una evaluación estructurada, la falta de experiencia directa deja de ser un obstáculo y se convierte en una oportunidad para crecer junto a profesionales motivados.