Pregunta de entrevista para Ingeniero de software

¿Cómo es un buen pipeline de CI para un servicio de backend?

Qué evalúa el entrevistador, cómo estructurar tu respuesta y un ejemplo hablado que puedes adaptar.

Respuesta rápida

Se ejecuta en cada push, devuelve feedback en menos de diez minutos y bloquea el merge si falla. Ordena las etapas de la más barata a la más cara: lint y comprobaciones de tipos, tests unitarios, luego tests de integración contra dependencias reales en contenedores, y luego un único artefacto de build que promocionas en vez de reconstruir por entorno. Mantenlo determinista, pon en cuarentena los tests inestables en vez de reintentar a ciegas, y haz que las mismas comprobaciones se puedan ejecutar en local.

Por qué lo preguntan los entrevistadores

Los entrevistadores quieren saber si tratas la CI como una red de seguridad o como un trámite. Las señales son la velocidad, porque un pipeline que nadie espera acaba esquivado, el orden de etapas para fallar rápido, construir el artefacto una vez y promocionarlo, y una postura real sobre los tests inestables. Decir que la CI se debe poder reproducir en local demuestra que has sufrido el pipeline en verde y el portátil en rojo.

Cómo estructurar tu respuesta

  • Empieza por el bucle de feedback y un presupuesto de tiempo.
  • Ordena las etapas de la más barata a la más cara.
  • Construye una vez y promociona el mismo artefacto.
  • Enuncia una política explícita sobre los tests inestables.

Ejemplo de respuesta

Ejemplo hablado, en primera persona

La primera propiedad es la velocidad, porque un pipeline que tarda cuarenta minutos es uno que la gente esquiva. Quiero lint y comprobaciones de tipos fallando en menos de un minuto, tests unitarios en unos pocos, y todo el conjunto por debajo de diez. Así que las etapas van de la más barata a la más cara: comprobaciones estáticas, tests unitarios, luego tests de integración contra Postgres y Redis reales en contenedores y no contra mocks, porque los bugs que me importan viven en la frontera. Después construye un artefacto, una imagen de contenedor etiquetada con el sha del commit, y todos los entornos posteriores despliegan esa imagen exacta. Reconstruir por entorno significa que lo que probaste no es lo que enviaste. Con los tests inestables soy estricto: un reintento automático es una forma de esconder una carrera real, así que un test inestable se pone en cuarentena y alguien se hace cargo de arreglarlo esa semana. Y quiero que los mismos comandos se puedan ejecutar en local, normalmente detrás de un makefile, porque depurar subiendo commits para ver qué dice la CI es una forma miserable de pasar una tarde.

¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.

Mira cómo funciona

Preguntas de seguimiento que puedes esperar

  • ¿Cómo acelerarías una suite que tarda treinta minutos?
  • ¿Qué comprobaciones ejecutarías en main pero no en los pull requests?
  • ¿Cómo gestionas los secretos en CI?

Más preguntas para Ingeniero de software

Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.

Predecir mis preguntas

Ensaya las preguntas difíciles antes de que te las hagan

Practica con un copiloto en vivo y entra preparado. Un Session Pass de $29 te lleva a través de la entrevista sin suscripción y sin ataduras.

Consigue GhostPilot