Problema

Los candidatos a roles de Linux/Fleet Ops, SRE o infraestructura suelen recibir una lista de temas (troubleshooting, networking, storage, scripting) pero no saben cómo priorizar su estudio. El reto es convertir esa lista en una ruta de preparación que maximice la probabilidad de resolver los escenarios que los entrevistadores plantean, sin perder tiempo en detalles que rara vez aparecen en entrevistas early‑career.

Causa

  1. Entrevistas basadas en escenarios reales – Los entrevistadores buscan observar el proceso de diagnóstico, no la memorización de comandos aislados.
  2. Amplio espectro de conocimientos – Linux, redes, SAN/NFS y algoritmos de programación compiten por el mismo tiempo de estudio, lo que genera dispersión.
  3. Expectativas poco claras – Algunas empresas enfatizan la escritura de código, otras la capacidad de leer logs o de interpretar métricas de rendimiento.
  4. Sobre‑preparación en áreas de bajo impacto – Es fácil caer en la trampa de repasar cada flag de iptables o cada versión de systemd cuando la entrevista solo tocará los conceptos básicos.

Solución

1. Construir un mapa de “escenarios críticos”

Agrupa los temas en cuatro bloques de acción que se alinean con la mayoría de entrevistas early‑career:

Bloque Pregunta típica Acción clave
Diagnóstico de rendimiento “El servidor está lento, ¿cómo lo investigas?” Analizar carga (top, htop), identificar procesos D‑state, revisar iowait con iostat, validar uso de CPU vs. I/O.
Conectividad y DNS “Puedes conectar por IP pero no por nombre, ¿qué haces?” Verificar /etc/resolv.conf, dig, nslookup, systemd-resolved, y probar rutas con traceroute.
Almacenamiento y SAN/NFS “Un mount NFS se cuelga, ¿cómo lo depuras?” Revisar showmount, rpcinfo, latencia con dd y iostat, validar multipath con multipath -ll.
Automatización y parsing “Escribe un script que cuente los 10 errores más frecuentes en syslog.” Usar Bash/AWK/Python para filtrar, agrupar y ordenar.

Este mapa permite al candidato ciclar entre teoría y práctica, enfocándose en los pasos que realmente se evalúan: identificación del síntoma, recolección de datos, análisis y propuesta de solución.

2. Priorizar profundidad según ROI

Tema Nivel recomendado Por qué
CPU / Load / D‑state Medio (comandos top, ps, systemd-cgtop) Aparece en >70 % de casos de “servidor lento”.
OOM Killer Bajo‑medio (revisar dmesg, /proc/meminfo) Suele ser pista de configuración, no foco principal.
DNS y resolución Alto (dig, resolvectl, /etc/hosts) Fallos de hostname son muy comunes en pruebas de conectividad.
Routing / ARP Medio (ip route, arp -n) Necesario cuando la red funciona pero el tráfico no llega.
Firewall básico Bajo (ver iptables -L o nft list ruleset) Rara vez se profundiza en entrevistas de nivel inicial.
NFS / SAN / multipath Medio (conceptos de showmount, multipath -ll, iostat) Preguntas de almacenamiento suelen centrarse en diagnóstico, no en configuración avanzada.
DSA (hash, arrays) Bajo (algoritmos de ordenamiento simples) La mayoría de entrevistas early‑career prefieren scripting sobre estructuras complejas.
Scripting Bash/Python Alto (parsing de logs, generación de reportes) Es la herramienta principal para demostrar lógica y automatización.

3. Simular entrevistas con “mock scenarios”

  1. Escenario de alta carga

    • Genera carga con stress-ng y registra top, iostat.
    • Practica identificar si el cuello de botella es CPU o I/O.
  2. Fallo de NFS

    • Desmonta el export y vuelve a montar con opciones hard,intr.
    • Usa tcpdump para observar paquetes RPC y verifica latencia.
  3. Parsing de logs

    • Crea un archivo syslog.sample con varios tipos de mensajes.
    • Escribe un script que devuelva los 10 mensajes más frecuentes y su recuento.
  4. Problema de DNS

    • Modifica /etc/resolv.conf para apuntar a un DNS no funcional y muestra cómo revertirlo con resolvectl.

Al final de cada ejercicio, escribe brevemente qué datos recopilaste, qué descartaste y cuál fue la solución. Ese registro sirve como “portafolio” para la entrevista.

4. Enfocar el estudio de DSA

Para roles early‑career, la expectativa es capacidad de razonamiento lógico, no de implementar árboles AVL. Dedica 1‑2 horas a:

  • Operaciones con diccionarios/sets en Python (collections.Counter).
  • Manipulación de listas (slicing, sorting).
  • Algoritmos de búsqueda lineal y uso de expresiones regulares para extraer datos de logs.

5. Checklist rápido de comandos esenciales

Mantén una hoja de referencia con los siguientes comandos, ordenados por bloque de acción. Practícalos sin opciones avanzadas; la mayoría de entrevistas solo requiere la forma básica.

Cuándo aplicar esta solución

  • Síntomas de rendimiento: alta carga, procesos en D‑state, I/O elevado.
  • Fallas de conectividad: ping funciona, curl no; hostname no resuelve.
  • Problemas de montaje: NFS o dispositivos SAN que no aparecen o se cuelgan.
  • Necesidad de automatizar: extracción de métricas de logs, generación de reportes.

No es adecuada cuando la entrevista se centra exclusivamente en arquitectura de clústeres (Kubernetes, Docker Swarm) o en programación avanzada (algoritmos de grafos), ya que esos temas suelen pertenecer a niveles senior.

Código

#!/usr/bin/env bash
# top‑10 errores más frecuentes en /var/log/syslog
log="/var/log/syslog"
awk -F'[:]' '{print $5}' "$log" | \
  tr -d '[:space:]' | \
  grep -v '^$' | \
  sort | \
  uniq -c | \
  sort -nr | \
  head -n 10

Este script extrae el mensaje después del quinto : (formato típico de syslog), elimina espacios vacíos, cuenta repeticiones y muestra los diez más comunes. Es suficiente para demostrar manejo de pipes, awk, sort y uniq.


## Verificación
1. Ejecuta el script en una máquina con logs reales.  
2. Verifica que la salida muestre una lista de mensajes y un número al inicio (recuento).  
3. Cambia la variable `log` a otro archivo (por ejemplo, `auth.log`) y confirma que el script sigue funcionando sin modificaciones.  

Si el script falla por un formato inesperado, ajusta el delimitador `-F` de `awk` según la estructura del log.

## Notas adicionales
- **No memorices flags**; entiende qué hace cada uno. En una entrevista, el entrevistador puede preguntar “¿qué harías si `iostat` muestra 90 % de %iowait?” y espera que describas el razonamiento, no que cites la opción `-x`.  
- **Mantén la calma con los “trivia”**. Si te piden el número de bits de una máscara `/24`, responde rápidamente y pasa a la parte práctica.  
- **Documenta tus mock scenarios** en un repositorio Git; muestra al entrevistador tu proceso de aprendizaje y tu capacidad de versionar scripts.  
- **Revisa los logs del systemd journal** con `journalctl -p err -b` para filtrar errores del último arranque; es una forma rápida de detectar problemas de servicios que no arrancan.  
- **Practica en entornos virtuales** (Vagrant, libvirt) para recrear fallos de red y storage sin afectar sistemas de producción.  

Con este enfoque estructurado, la preparación se vuelve más eficiente y alineada con lo que realmente evalúan los entrevistadores de Linux/Fleet Ops en sus primeras etapas. ¡Éxitos en la entrevista!