Explícame tu método de resolución de problemas cuando un usuario informa de que la red no funciona.

Empiezo comprobando lo que resulta más rápido de verificar en lugar de asumir de entrada que es un problema del router. Primero confirmo el alcance: si es un solo usuario, una sola subred, una sola sede o todo, porque eso ya descarta la mayoría de las causas posibles. Reviso el estado de la capa física en el puerto o enlace afectado, luego la capa 2 con un ping a la puerta de enlace predeterminada, y después la capa 3 con un traceroute para ver exactamente dónde se rompe la ruta. Reviso el registro de cambios recientes antes de tocar nada, porque en mi experiencia un cambio hecho en las últimas 24 horas es la causa más a menudo que un fallo de hardware real. Una vez que aíslo el salto o el equipo que falla, reviso sus registros y los contadores de interfaz para detectar errores, pérdidas o problemas de CRC en lugar de adivinar. Voy anotando cada paso, tanto para tener claro lo que realmente he descartado como para que la siguiente persona no repita mi trabajo.

¿Cómo decides entre OSPF y BGP para un diseño de red concreto?

OSPF es mi opción por defecto para el enrutamiento interno dentro de una sola organización, porque converge rápido, gestiona bien los cambios de topología y no requiere la carga de gestión de políticas que exige BGP. Lo uso dentro de un campus o un centro de datos donde todos los routers están bajo una misma administración y el objetivo es simplemente la ruta más corta y eficiente. BGP entra en juego cuando enruto entre sistemas autónomos: conexión con un proveedor de internet, peering con una red asociada, o una WAN multisede donde necesito control por política sobre qué rutas toma el tráfico y no solo la más corta. BGP también me da atributos de ruta como el AS-PATH y la preferencia local para dirigir el tráfico de forma deliberada, algo que OSPF no permite. En la práctica he usado ambos juntos: OSPF internamente, redistribuido con cuidado hacia BGP en el borde, con filtrado de rutas para que un cambio de enrutamiento interno no pueda filtrarse por accidente hacia internet.

¿Cómo abordas la documentación de red?

Mantengo tres cosas actualizadas en todo momento: un diagrama de topología que refleja la red real en producción, no la del diseño original; un sistema IPAM que rastrea cada subred, VLAN y asignación de dirección para que nadie duplique una dirección; y un registro de cambios ligado a cada despliegue de configuración, incluyendo quién lo hizo, por qué y el plan de reversión. Escribo runbooks para todo lo que ocurre más de una vez, especialmente los pasos de respuesta a incidentes, para que la solución no dependa solo de la memoria de una persona. He visto incidentes que duraron el triple simplemente porque la documentación no coincidía con la realidad, así que trato la actualización de la documentación como parte del cambio en sí, no como una tarea opcional posterior. Comparo el diagrama de topología con la red real cada trimestre para detectar desviaciones antes de que se conviertan en un problema durante un incidente.

¿Cómo usas la IA o las herramientas de automatización en tu trabajo de ingeniería de redes?

Uso plataformas de monitorización con detección de anomalías integrada para detectar patrones de tráfico o picos de latencia que se salen de los valores normales, lo que permite detectar problemas antes de que los usuarios los reporten. Para tareas de configuración repetitivas, como aplicar el mismo cambio de VLAN o ACL en veinte switches, uso playbooks de Ansible y scripts de Python en lugar de hacerlo manualmente, lo que también reduce los incidentes causados por errores de escritura. Donde no delego el control es en cualquier cosa sensible a nivel de seguridad o de cara al cliente: los cambios de reglas de firewall, los cambios de política BGP y todo lo que toque el borde de internet pasan por una revisión manual mía antes de entrar en producción, sin importar la confianza que tenga en la automatización. Trato las herramientas asistidas por IA como buenas para la detección de patrones y la ejecución repetitiva, y mantengo mi propio criterio como el último control sobre cualquier cosa que pudiera tumbar un segmento de la red.

Cuéntame sobre una vez que diagnosticaste y resolviste una caída de red importante.

Durante el fallo de un switch núcleo, todo un edificio perdió conectividad, afectando a unos 400 usuarios durante lo que terminó siendo una interrupción de 45 minutos. Confirmé que el fallo estaba aislado a ese switch comprobando que el switch redundante del stack seguía activo pero no pasaba tráfico, lo que apuntaba a un problema de spanning tree y no a un fallo de hardware. Revisé la topología de spanning tree y encontré un valor de prioridad mal configurado tras un cambio hecho el día anterior, lo que había provocado un bucle que los mecanismos de protección del switch intentaban contener sin resolverlo limpiamente. Corregí el valor de prioridad, forcé un recálculo del spanning tree, y confirmé que el tráfico volvía a fluir con normalidad unos seis minutos después de identificar la causa. Después escribí el informe del incidente, añadí un paso de revisión por otro compañero para cualquier cambio de prioridad de spanning tree, y actualicé el runbook para que el siguiente ingeniero reconociera el mismo síntoma más rápido.

Describe una vez que tuviste que explicar un problema de red a alguien no técnico.

Durante un periodo de lentitud intermitente que afectaba a un equipo comercial antes de una llamada importante con un cliente, la directora quería una actualización cada quince minutos y no tenía paciencia para la jerga técnica. Expliqué la situación como un atasco en una carretera concreta entre su oficina e internet, no como toda la red caída, lo que estableció la expectativa correcta de que la mayoría de los sistemas funcionaban bien. Di un cronograma claro: sabemos dónde está la congestión, estamos redirigiendo el tráfico ahora mismo, y esperamos resolverlo en menos de una hora. Evité términos como pérdida de paquetes o MTU y en su lugar describí lo que realmente iban a notar, como páginas que cargan lento frente a páginas que no cargan en absoluto. Cuando se resolvió, lo confirmé con una cifra concreta de antes y después: la latencia bajó de unos 400 milisegundos a menos de 20, así que tuvieron algo concreto en lugar de solo mi palabra de que estaba resuelto.

Cuéntame sobre una vez que estuviste de guardia y tuviste que gestionar un incidente fuera del horario laboral.

Me avisaron sobre las 2 de la madrugada por una sesión BGP inestable con nuestro proveedor de internet secundario, que estaba cortando de forma intermitente nuestra ruta de respaldo. Todavía no afectaba a los clientes porque la ruta principal seguía activa, pero una sesión BGP inestable puede escalar rápido si se deja sin atender. Me conecté, revisé la interfaz en busca de errores de capa física, y no encontré nada local, lo que apuntaba a un problema del lado del proveedor. Abrí un ticket con el proveedor con las marcas de tiempo y los contadores de errores exactos, amortigüé la sesión temporalmente para detener el ruido excesivo en los registros, y dejé programado un recordatorio para hacer seguimiento por la mañana si no habían respondido. Documenté toda la secuencia en nuestro canal de incidentes para que el equipo tuviera contexto sin necesidad de despertar a nadie más. Al día siguiente el proveedor confirmó un problema de fibra en su lado, y cerré el tema retirando el amortiguamiento una vez que la sesión se estabilizó.

Explica la diferencia entre una VLAN y una subred, y por qué se podrían usar ambas juntas.

Una VLAN es una construcción de capa 2: segmenta los dominios de difusión dentro de los switches, de modo que los equipos en VLANs distintas no ven el tráfico de difusión de las demás aunque estén conectados físicamente al mismo switch. Una subred es una construcción de capa 3: una agrupación lógica de direcciones IP que determina cómo se toman las decisiones de enrutamiento. En la práctica, hago corresponder una subred con una VLAN como convención estándar, porque simplifica el diagnóstico: si conozco la VLAN, conozco la subred, y viceversa. La razón para usar ambas juntas en lugar de solo una es que las VLANs aportan aislamiento físico y de difusión a nivel de switch, mientras que las subredes aportan el límite de enrutamiento y control de acceso a nivel de router o firewall. Por ejemplo, podría poner finanzas e ingeniería en VLANs y subredes separadas para aplicar políticas de firewall distintas a cada una sin ninguna ambigüedad sobre a quién pertenece el tráfico.

¿Cómo segmentas una red por seguridad, y cuál es tu enfoque para el diseño de reglas de firewall?

Diseño en torno a zonas basadas en el nivel de confianza y la función, no en la ubicación física: una DMZ para todo lo expuesto a internet, una zona interna para el tráfico corporativo general, y una zona restringida para sistemas sensibles como finanzas o bases de datos de producción. El tráfico entre zonas tiene que pasar por un firewall, y escribo las reglas sobre una base de denegación por defecto, lo que significa que nada está permitido salvo que sea explícitamente necesario, en lugar de empezar de forma permisiva e intentar cerrarlo después. Cada regla lleva una descripción de quién la pidió y por qué, porque una regla sin documentar es lo más difícil de eliminar de forma segura dos años después. Reviso el conjunto completo de reglas cada trimestre para eliminar lo que ya no se necesita, porque los conjuntos de reglas de firewall tienden a crecer y rara vez se reducen sin un esfuerzo deliberado. Para cualquier segmento nuevo, también pienso en el tráfico este oeste, no solo norte sur, porque muchas brechas reales se propagan lateralmente una vez que están dentro de una sola zona de confianza.

¿Cómo abordas el networking en la nube, como el peering de VPC, frente al networking on premise?

El networking on premise es en gran parte físico: gestiono switches, cables y modos de fallo de hardware reales, y las decisiones de enrutamiento están ligadas a la topología física. En la nube, el networking se define por software: una VPC es una red aislada lógicamente dentro de un proveedor, y el peering de VPC permite que dos VPC se enruten tráfico entre sí de forma privada sin pasar por internet público, pero no es transitivo: emparejar A con B y B con C no permite que A llegue a C sin una conexión de peering directa o una puerta de enlace de tránsito. He usado puertas de enlace de tránsito para conectar varias VPC entre sí en lugar de construir una malla completa de conexiones de peering individuales, algo que se vuelve inmanejable a partir de unas pocas VPC. Para configuraciones híbridas he configurado tanto VPN como conexiones dedicadas como Direct Connect hacia el entorno on premise, y la pregunta de diseño principal es siempre la misma: cuál es el requisito de latencia y fiabilidad, porque una VPN sobre internet está bien para rutas de respaldo pero no para nada sensible a la latencia.

Ingeniero de redes

Las entrevistas para ingeniero de redes evalúan tu capacidad para diagnosticar problemas de conectividad bajo presión, y la solidez de tus fundamentos en enrutamiento, conmutación y seguridad. Los entrevistadores buscan un método de resolución de problemas repetible, no solo comandos de configuración, además de cómo documentas tu trabajo y das soporte en las guardias. Esta guía cubre las preguntas más frecuentes y las respuestas que consiguen ofertas.

Para consejos generales de preparación, consulta nuestra guía sobre las preguntas de entrevista más frecuentes.

Prepárate más

Dominar la entrevista conductual (método STAR)Cómo prepararse para una entrevista técnica

Preguntas de entrevista habituales para Ingeniero de redes

Preguntas conductuales para puestos de Ingeniero de redes

Preguntas técnicas para candidatos a Ingeniero de redes

Lo que buscan los reclutadores en las entrevistas para Ingeniero de redes

Lo que los responsables de selección buscan realmente en los candidatos a ingeniero de redes:

Un método de resolución de problemas repetible. Los buenos candidatos aíslan el alcance del problema y avanzan de forma sistemática por las capas de red en lugar de adivinar una solución.
Soltura con los protocolos de enrutamiento junto con un criterio real sobre cuándo usar cada uno, no solo definiciones de manual de OSPF o BGP.
Instintos de seguridad por defecto. La segmentación, las reglas de firewall en denegación por defecto y el control de cambios documentado deberían salir sin que se pregunte directamente por seguridad.
Hábitos de documentación. Pide un ejemplo concreto de runbook o diagrama de topología que hayan mantenido, porque las afirmaciones de buenas prácticas sin un ejemplo son una señal débil.
Buen criterio sobre la escalada durante las guardias. Saber que un problema puede esperar hasta la mañana siguiente vale tanto como la profundidad técnica.

Preguntas que puedes hacer al entrevistador

→¿Qué stack de monitorización y alertas usa el equipo, y cuánto ruido hay en las alertas actuales?
→¿Cómo está organizada la guardia, y cuál es el número medio de avisos por semana?
→¿Qué parte de la red está documentada hoy, y qué actualizada está esa documentación?
→¿Cómo es el proceso de gestión de cambios para un despliegue de configuración habitual frente a una corrección de emergencia?
→¿Qué proporción de la infraestructura es on premise frente a cloud, y se espera que ese equilibrio cambie?

Practica estas preguntas antes de tu entrevista

El simulador de entrevista prepara una sesión de práctica basada en una oferta de empleo concreta y tu perfil, para que repases las preguntas con más probabilidad de aparecer.

Empezar a practicar

Gratis en tu primer puesto guardado.

Puestos relacionados

Ingeniero DevOps

Tech9 preguntas

Especialista en ciberseguridad

Tech9 preguntas

Administrador de sistemas

Tech10 preguntas

Técnico de soporte informático

Tech10 preguntas

Disponible en otros idiomas

English Français