Domina las preguntas de entrevista sobre dependencias de Spring Boot: starters, BOM, POM padre y exclusiones. Responde con claridad y pasa la entrevista.
La mayoría de los candidatos que se preparan para una entrevista de Spring Boot pueden recitar `spring-boot-starter-web` y `spring-boot-starter-data-jpa` sin dudarlo. La pregunta de entrevista sobre dependencias de Spring Boot que realmente separa a los candidatos no es "nombra un starter", sino "¿qué hace ese starter en tu classpath y qué ocurre cuando dos starters incorporan versiones incompatibles de la misma librería?" Ahí es donde se acaban las respuestas memorizadas.
Esta guía está pensada para candidatos que conocen los nombres de los starters, pero necesitan explicar la mecánica: qué incluyen realmente los starters, cómo la gestión de dependencias mantiene alineadas las versiones, qué hacen en realidad el BOM y el POM padre, y cómo describir una exclusión sin dar rodeos. Si puede responder esas preguntas en lenguaje claro, podrá afrontar la mayoría de las preguntas sobre dependencias de Spring Boot en una entrevista técnica.
Por qué a los entrevistadores deja de importarles el nombre de los starters después del primer minuto
El problema de las respuestas memorizadas
El patrón es predecible. Un entrevistador pregunta "¿cómo gestiona Spring Boot las dependencias?" y el candidato responde "añades starters a tu pom.xml y Spring Boot se encarga del resto". Esa respuesta no es incorrecta, pero es la de alguien que ha leído un tutorial de inicio, no la de alguien que ha depurado un conflicto de classpath a las 11 de la noche antes de una publicación.
El problema no es que el candidato no conozca los nombres de los starters. Es que la respuesta se desmorona en cuanto llega una repregunta. "¿Qué incorpora realmente `spring-boot-starter-web`?" "¿Por qué no especificaste una versión para Jackson?" "¿Qué pasó cuando tenías dos starters que necesitaban versiones distintas de la misma librería de logging?" Si la respuesta a las tres es una pausa seguida de "Spring Boot lo gestiona automáticamente", la entrevista básicamente ha terminado.
Este es el modo de fallo de las respuestas memorizadas en una entrevista sobre dependencias de Spring Boot: el candidato conoce el vocabulario, pero no el razonamiento que hay detrás.
Qué tiene que demostrar una respuesta real en una entrevista
La exigencia no es conocer a fondo los entresijos del framework. Son tres cosas: que el candidato entiende cómo funciona la ensambladura de dependencias (los starters son conjuntos seleccionados de artefactos, no magia), que entiende la alineación de versiones (algo tiene que decidir qué versión de Jackson acaba en el classpath, y ese algo es el BOM), y que entiende los compromisos (añadir un starter tiene consecuencias transitivas, y las exclusiones son la forma de gestionar las que no quiere).
La documentación oficial de Spring sobre starters los describe explícitamente como "un conjunto de descriptores de dependencias convenientes". Esa formulación importa en una entrevista porque le dice al entrevistador que usted entiende el mecanismo, no solo el atajo. Según una investigación de SHRM sobre cribado técnico, los entrevistadores valoran de forma consistente más la "capacidad de explicar el porqué de una elección tecnológica" que el recuerdo de hechos — y la gestión de dependencias es exactamente el tipo de tema en el que esa diferencia se nota.
Trate los starters de Spring Boot como descriptores de dependencias, no como paquetes mágicos
Qué incluyen realmente los starters
Un starter es una lista seleccionada de dependencias Maven agrupadas en torno a una tarea concreta. No hay magia en el nivel de starter: es un pom que declara un conjunto de librerías compatibles para que usted no tenga que montarlas a mano ni adivinar si las versiones encajan entre sí. El starter para web incorpora lo necesario para construir una aplicación web. El starter para JPA incorpora lo necesario para hablar con una base de datos relacional. La idea es la coherencia: todos los proyectos que usan el mismo starter obtienen el mismo grafo de dependencias, lo que dificulta mucho más que las versiones se desvíen dentro de un equipo.
La palabra "seleccionado" aquí tiene peso real. El equipo de Spring Boot mantiene estos starters y prueba las combinaciones. Cuando añade `spring-boot-starter-web`, no solo obtiene Spring MVC: obtiene una combinación probada de Spring MVC, Jackson, Tomcat (el servidor incrustado) y soporte de validación. Nada de eso es magia. Es solo una lista que otra persona ya mantuvo para que usted no tuviera que hacerlo.
Cómo se ve esto en la práctica
Un `pom.xml` con dos starters se ve así:
Sin versiones. Sin el artefacto de Jackson. Sin el artefacto de Hibernate. Sin el artefacto de Tomcat. En una entrevista, la explicación segura sería: "Cada starter es un descriptor de dependencias: un pom que enumera los artefactos necesarios para esa tarea. `starter-web` incorpora Spring MVC, Jackson para serialización JSON y Tomcat incrustado. `starter-data-jpa` incorpora Spring Data JPA, Hibernate como proveedor JPA predeterminado y soporte JDBC. No especifico versiones porque las gestiona el BOM."
Esa última frase es el puente hacia el siguiente tema, y es la parte que la mayoría de los candidatos omite.
La gestión de dependencias es lo que le salva del caos de versiones
Por qué las declaraciones normales de Maven no son suficientes
En un proyecto Maven convencional, cada declaración de dependencia especifica una versión o la hereda de un padre. Si tiene diez dependencias y cada una incorpora Jackson de forma transitiva, puede acabar con tres versiones distintas de Jackson en el classpath efectivo, y la estrategia de resolución "la más cercana gana" de Maven elige una sola, no necesariamente la que usted quería. El resultado es deriva de versiones: comportamiento inconsistente entre módulos, misteriosas excepciones `NoSuchMethodError` y sesiones de depuración que duran horas porque, a simple vista, el classpath parece correcto.
La gestión de dependencias de Spring Boot resuelve esto centralizando las versiones compatibles en un solo lugar. Cuando usa dependencias gestionadas por Boot, no especifica versiones para los artefactos que el BOM conoce. El BOM ya ha decidido qué versión de Jackson funciona con qué versión de Spring, y esa decisión es coherente para todas las dependencias que lo usan. Esta es la solución estructural que las declaraciones Maven normales no ofrecen.
Cómo se ve esto en la práctica
Cuando añade `spring-boot-starter-web` sin una versión, Maven resuelve la versión a través del BOM. El pom efectivo muestra algo como:
Usted no declaró esa versión. Lo hizo el BOM. En una entrevista, la explicación limpia sería: "El BOM es una lista de materiales — un pom que define un conjunto seleccionado de versiones de dependencias. Cuando heredo de `spring-boot-starter-parent` o importo el BOM directamente, esas versiones se aplican a cualquier dependencia que declare sin versión. Confío en las pruebas de compatibilidad del equipo de Spring Boot en lugar de ensamblar yo mismo las versiones."
Esa respuesta demuestra comprensión del mecanismo, no solo del resultado.
Qué hacen realmente el BOM y el starter parent
Tanto `spring-boot-starter-parent` como el BOM de Spring Boot (`spring-boot-dependencies`) resuelven la misma clase de problema desde ángulos distintos. El BOM es el catálogo de versiones: define versiones compatibles para cientos de librerías. El POM padre importa el BOM y además añade configuración de plugins, valores predeterminados de codificación y ajustes del compilador. Si su proyecto ya tiene un POM padre corporativo, no puede usar `spring-boot-starter-parent` como padre, así que importa el BOM directamente en la sección `<dependencyManagement>`. La misma alineación de versiones, con menos herencia superflua.
Muestre el POM padre, el BOM y las dependencias transitivas juntos
Cómo spring boot starter parent cambia la configuración por defecto
Añadir `spring-boot-starter-parent` como padre del proyecto le da tres cosas de inmediato: las versiones gestionadas del BOM, valores predeterminados razonables para los plugins de Maven (versión del compilador, filtrado de recursos, configuración de pruebas) y menos repetición en cada módulo. La contrapartida es que ya ha usado su única ranura de padre. Los equipos con un POM padre corporativo importan el BOM directamente en su lugar: misma alineación de versiones, pero la configuración de plugins la gestionan ellos.
Cómo se ve esto en la práctica
Un `pom.xml` mínimo usando el padre:
Ejecutar `mvn dependency:tree` en este proyecto muestra cómo llegan las dependencias transitivas sin ninguna declaración explícita:
Ninguno de esos artefactos fue declarado. Llegaron porque los starters los enumeraban.
Por qué las dependencias transitivas importan en una respuesta de entrevista
Esta es la parte a la que los entrevistadores están prestando realmente atención. Cuando añade `spring-boot-starter-web`, no añade un artefacto: añade un grafo de dependencias. Si otro starter de su proyecto incorpora una versión distinta de `jackson-databind`, tiene un conflicto. Si no entiende que el conflicto procede de una dependencia transitiva, no podrá resolverlo. Los candidatos que entienden esto dicen "ejecuté el árbol de dependencias para encontrar de dónde venía el conflicto". Los que no entienden dicen "añadí una exclusión y funcionó". La segunda respuesta no demuestra comprensión; demuestra suerte.
Explique los starters que realmente esperan que conozca los entrevistadores
Web, JPA, seguridad, test y actuator son los cinco básicos
Estos cinco starters aparecen en casi todas las entrevistas para backend, y conocerlos al nivel de "qué incorporan y por qué los usaría" es el mínimo exigible.
`spring-boot-starter-web` es para construir API REST y aplicaciones web. Incorpora Spring MVC, Jackson, Tomcat incrustado y soporte de validación. No afirme que gestiona el acceso a base de datos: ese es otro starter.
`spring-boot-starter-data-jpa` es para acceso a bases de datos relacionales mediante JPA. Incorpora Spring Data JPA, Hibernate y soporte JDBC. La nota segura para entrevista: Hibernate es el proveedor JPA predeterminado, pero puede cambiarse.
`spring-boot-starter-security` es para autenticación y autorización. Incorpora Spring Security y configura una cadena de filtros de seguridad predeterminada. Los candidatos suelen equivocarse diciendo que "asegura su aplicación automáticamente": establece la infraestructura, pero la configuración sigue siendo su responsabilidad.
`spring-boot-starter-test` es para pruebas. Incorpora JUnit 5, Mockito, AssertJ y utilidades de prueba de Spring. Tiene un ámbito de test por defecto, así que no llega a su artefacto de producción.
`spring-boot-starter-actuator` es para monitorización en producción. Incorpora endpoints para comprobaciones de salud, métricas e información del entorno. En un servicio de producción, esto no es opcional: es la forma de saber si la aplicación sigue viva.
Cómo se ve esto en la práctica
En una API CRUD sencilla, normalmente usaría `starter-web`, `starter-data-jpa` y `starter-test`. Añadiría `starter-actuator` y `starter-security` cuando el servicio se acerque a producción. Los starters que elija definen el grafo de dependencias; la capa de auto-configuración lee ese grafo y ensambla los beans en consecuencia. Los starters son la entrada. El contexto de aplicación ensamblado es la salida.
Use exclusiones para resolver conflictos, no para parecer ingenioso
Por qué aparecen conflictos en primer lugar
Las dependencias transitivas son la causa de casi todos los conflictos de dependencias en un proyecto Spring Boot. Dos starters pueden incorporar la misma librería en versiones distintas. La resolución "la más cercana gana" de Maven elige una, pero "la más cercana" no significa "la correcta". El resultado suele ser una versión que satisface a un starter pero rompe al otro, y el fallo aparece en tiempo de ejecución como `ClassNotFoundException` o `NoSuchMethodError`, no en compilación.
La solución limpia es una exclusión: eliminar la versión problemática del starter que la está incorporando de forma transitiva y declarar después la versión que realmente quiere en el nivel superior.
Cómo se ve esto en la práctica
Un escenario de conflicto habitual: `spring-boot-starter-web` y una librería de terceros incorporan `commons-logging`, pero en versiones distintas. La solución:
Después de la exclusión, ejecutar `mvn dependency:tree` confirma que el artefacto ha desaparecido de esa rama del grafo. Si la aplicación sigue necesitando la librería, la declara directamente con la versión que desea. Si no la necesita, la omite.
Cómo describir la solución sin sonar vago
La explicación segura para entrevista es de tres pasos: "Ejecuté el árbol de dependencias para encontrar qué artefacto causaba el conflicto y de dónde venía. Añadí una exclusión a la dependencia que estaba incorporando la versión incorrecta de forma transitiva. Después comprobé si la aplicación seguía necesitando esa librería; si la necesitaba, la declaré directamente con la versión correcta." Esa respuesta demuestra que entiende el mecanismo. "Simplemente la excluí" no lo demuestra.
La documentación oficial de Maven sobre exclusiones de dependencias cubre la sintaxis y el razonamiento. La documentación de referencia de Spring Boot también aborda patrones conocidos de exclusión, en particular para librerías de logging.
Deje de confundir auto configuración con gestión de dependencias
Resuelven problemas distintos
Este es el error conceptual más habitual en entrevistas sobre dependencias de Spring Boot, y conviene ser directos: la gestión de dependencias decide qué entra en el classpath, mientras que la auto-configuración decide qué ensambla Spring Boot a partir de lo que ya está ahí. Son mecanismos separados. Confundirlos es una señal de alarma para el entrevistador porque sugiere que el candidato no entiende cómo funciona realmente Boot: solo sabe que funciona.
La gestión de dependencias ocurre en tiempo de compilación. El BOM y los starters determinan qué artefactos acaban en su artefacto compilado. La auto-configuración ocurre al arrancar la aplicación. Spring Boot analiza el classpath, encuentra las librerías presentes y crea beans en función de anotaciones `@Conditional` que comprueban su existencia.
Cómo se ve esto en la práctica
Añadir `spring-boot-starter-data-jpa` coloca Hibernate y Spring Data JPA en el classpath. Eso es gestión de dependencias. Cuando la aplicación arranca y Spring Boot encuentra Hibernate en el classpath, auto-configura un `DataSource`, un `LocalContainerEntityManagerFactoryBean` y un `JpaTransactionManager`, sin que usted escriba ninguna de esas configuraciones. Eso es auto-configuración.
La respuesta limpia en una entrevista sería: "La gestión de dependencias es una cuestión de compilación: controla qué hay en el classpath. La auto-configuración es una cuestión de ejecución: controla qué ensambla Spring a partir de lo que hay en el classpath. Añadir un starter no configura nada por sí mismo. Solo pone las librerías a disposición para que la auto-configuración haga su trabajo."
La documentación de auto-configuración de Spring Boot deja clara esta distinción y merece la pena leerla antes de cualquier entrevista técnica.
Responda a las preguntas de entrevista sin caer en sopa de palabras de moda
Las respuestas breves que los candidatos deberían tener preparadas
Las preguntas siguientes aparecen en casi todas las entrevistas sobre dependencias de Spring Boot. Tener una respuesta clara de un párrafo para cada una es la preparación mínima.
¿Qué es un starter de Spring Boot? "Un starter es un descriptor de dependencias: un pom que enumera un conjunto seleccionado de librerías compatibles para una tarea concreta. Cuando añado `spring-boot-starter-web`, no añado magia; añado una combinación probada de Spring MVC, Jackson y Tomcat incrustado. La idea es que otra persona ya haya averiguado qué versiones funcionan bien juntas."
¿Qué hace la gestión de dependencias de Spring Boot? "Centraliza las decisiones de versión en el BOM. Cuando declaro una dependencia sin versión, el BOM proporciona la versión compatible. Eso evita la deriva de versiones en el proyecto y significa que no estoy reconciliando manualmente las versiones de las librerías."
¿Por qué importa `spring-boot-starter-parent`? "Hereda el BOM, que me da versiones gestionadas para cientos de librerías. También configura valores predeterminados sensatos para los plugins de Maven, así que no tengo que repetir esa configuración en cada proyecto. Si no puedo usarlo como padre, importo el BOM directamente en `<dependencyManagement>`."
¿Cómo funcionan las exclusiones? "Ejecuto el árbol de dependencias para encontrar el artefacto conflictivo y ver qué dependencia lo está incorporando de forma transitiva. Añadо una exclusión a esa dependencia para eliminar la versión incorrecta y, luego, declaro la versión correcta directamente si la aplicación sigue necesitándola."
Cómo se ve esto en la práctica
La diferencia entre una respuesta memorizada y una real aparece de inmediato cuando llega la repregunta. "¿Qué incorpora `spring-boot-starter-web`?" — una respuesta memorizada dice "dependencias web". Una respuesta real dice "Spring MVC, Jackson para serialización JSON, Tomcat incrustado y la API de validación". Una de esas respuestas le dice al entrevistador que usted realmente ha mirado el árbol de dependencias. La otra le dice que ha leído un resumen.
Los reclutadores detectan la comprensión real más rápido de lo que los candidatos creen
Cómo suena una buena respuesta para un reclutador
Los reclutadores y evaluadores técnicos que hacen entrevistas de backend no buscan conocimiento enciclopédico. Aplican una prueba sencilla de tres partes: ¿puede el candidato definir el concepto, nombrar la consecuencia y explicar un compromiso? Para las dependencias de Spring Boot, eso significa: qué es un starter (definición), qué hace en el classpath (consecuencia) y qué pasa cuando dos starters entran en conflicto (compromiso). Un candidato que pueda hacer las tres cosas en dos minutos de conversación aprueba la sección de dependencias de la entrevista.
Cómo se ve esto en la práctica
Las señales de alarma son muy consistentes. Recitar nombres de starters sin explicar qué incorporan. Usar "Spring Boot lo gestiona automáticamente" como respuesta a cada repregunta. Describir exclusiones como algo que "simplemente se añade" sin explicar cómo identificó el conflicto. Confundir auto-configuración y gestión de dependencias en la misma frase.
La señal positiva es igualmente consistente. El candidato ejecuta el árbol de dependencias antes de adivinar. Puede nombrar lo que incorpora un starter concreto sin buscarlo. Describe un conflicto que realmente ha encontrado y explica cómo lo resolvió. Conoce la diferencia entre el BOM y el POM padre y puede explicar cuándo usaría uno sin el otro. Esa combinación —definición, consecuencia, compromiso y un ejemplo real— es lo que suena como una buena respuesta para cualquiera que evalúe candidatos para backend.
FAQ
P: ¿Qué son las dependencias starter de Spring Boot y en qué se diferencian de las dependencias Maven normales?
Un starter es un pom seleccionado que agrupa un conjunto de dependencias de librerías compatibles en torno a una tarea concreta: web, persistencia, seguridad, pruebas. Una dependencia Maven normal es un único artefacto que usted declara por su cuenta, con una versión que usted gestiona. La diferencia es que los starters le proporcionan una combinación probada de librerías sin que tenga que ensamblarlas ni versionarlas manualmente, mientras que las dependencias normales le dejan esa responsabilidad a usted.
P: ¿Qué hace realmente la gestión de dependencias de Spring Boot internamente?
Proporciona versiones compatibles para cada librería listada en el BOM. Cuando declara una dependencia sin versión en un proyecto Boot, Maven busca la versión en la sección de versiones gestionadas del pom efectivo, que procede del BOM. Esto evita la deriva de versiones en el proyecto y significa que usted confía en las pruebas de compatibilidad del equipo de Spring Boot en lugar de ensamblar las versiones por su cuenta.
P: ¿Cómo ayuda spring-boot-starter-parent con la alineación de versiones y las dependencias transitivas?
El POM padre hereda el BOM de Spring Boot, que define versiones gestionadas para cientos de librerías. Cualquier dependencia que declare sin versión recibe automáticamente esa versión gestionada. Las dependencias transitivas incorporadas por los starters también usan las versiones del BOM, salvo que algo las sobrescriba, por eso el classpath permanece coherente sin declaraciones manuales de versiones.
P: ¿Qué starters debería poder explicar un candidato en una entrevista y qué incorpora cada uno?
Los cinco que aparecen con más frecuencia son `starter-web` (Spring MVC, Jackson, Tomcat incrustado), `starter-data-jpa` (Hibernate, Spring Data JPA, JDBC), `starter-security` (Spring Security, cadena de filtros predeterminada), `starter-test` (JUnit 5, Mockito, AssertJ) y `starter-actuator` (endpoints de salud, métricas y entorno). Saber qué incorpora cada uno a alto nivel —no todos los artefactos transitivos, pero sí los clave— es el mínimo.
P: ¿Cómo funcionan las exclusiones cuando aparece un conflicto de dependencias y cómo debería explicarse con claridad?
Ejecute `mvn dependency:tree` para encontrar el artefacto conflictivo y qué dependencia lo está incorporando de forma transitiva. Añada una exclusión a esa dependencia en su pom para eliminar la versión incorrecta de esa rama del grafo. Si la aplicación sigue necesitando la librería, declárela directamente con la versión correcta. La versión segura para entrevista de esta respuesta nombra los tres pasos: identificar, excluir, sustituir si hace falta.
P: ¿Cuál es la diferencia entre auto-configuración y gestión de dependencias en Spring Boot?
La gestión de dependencias es una cuestión de compilación: controla qué artefactos llegan al classpath. La auto-configuración es una cuestión de ejecución: controla qué beans crea Spring en función de lo que hay en el classpath. Añadir un starter coloca librerías en el classpath. La auto-configuración lee el classpath al arrancar y ensambla beans de forma condicional. Son mecanismos separados con responsabilidades distintas.
P: ¿Cuáles son los errores más comunes que cometen los candidatos al responder preguntas sobre dependencias de Spring Boot?
Aparecen tres errores de forma consistente: confundir auto-configuración con gestión de dependencias, describir exclusiones sin explicar cómo identificaron el conflicto y usar "Spring Boot lo gestiona automáticamente" como respuesta a preguntas de seguimiento. Los tres indican que el candidato conoce el vocabulario, pero no ha trabajado la mecánica.
P: ¿Cómo puede un reclutador saber si un candidato realmente entiende las dependencias de Spring Boot o si solo ha memorizado nombres de starters?
Haga una repregunta: "¿Qué incorpora realmente ese starter?" Un candidato que entiende la pila puede nombrar las dependencias transitivas clave sin consultarlas. Un candidato que solo memorizó nombres no puede. La segunda señal es si puede describir un conflicto real que haya resuelto —el árbol de dependencias, la exclusión, la solución— en lugar de describir el concepto en abstracto.
Cómo Verve AI puede ayudarle a prepararse para su entrevista sobre dependencias de Spring Boot
El problema estructural de prepararse para una entrevista sobre dependencias de Spring Boot es que el contenido es fácil de leer, pero difícil de reproducir bajo presión. Puede entender perfectamente el BOM en papel y aun así dar una respuesta enrevesada y circular cuando un entrevistador pregunta "¿cuál es la diferencia entre gestión de dependencias y auto-configuración?" en una entrevista en vivo. Leer es pasivo. Responder en voz alta, en tiempo real, a una repregunta que no esperaba —eso es una habilidad completamente distinta.
Verve AI Interview Copilot está diseñado precisamente para cubrir esa diferencia. Escucha en tiempo real sus respuestas durante las sesiones de práctica y reacciona a lo que usted realmente dijo, no a una indicación prefabricada. Si da la versión memorizada de una explicación sobre un starter y omite el detalle de las dependencias transitivas, Verve AI Interview Copilot plantea la repregunta que revela la laguna, igual que haría un entrevistador real. Sugiere respuestas en vivo en función de la pregunta concreta y de su respuesta concreta, de modo que la retroalimentación se ajusta a su respuesta real y no a una rúbrica genérica. Y permanece invisible mientras hace todo esto: la aplicación de escritorio es indetectable para la compartición de pantalla a nivel de sistema operativo, así que puede practicar en el mismo entorno en el que va a rendir. Para un tema como las dependencias de Spring Boot, donde la prueba real es si puede reconstruir el razonamiento bajo presión, ese tipo de práctica en vivo y reactiva es la preparación que realmente se transfiere.
Conclusión
La versión para entrevista del conocimiento sobre dependencias de Spring Boot es más sencilla de lo que parece desde fuera. Si puede explicar qué es un starter y qué incorpora, describir cómo el BOM mantiene alineadas las versiones, recorrer un árbol de dependencias transitivas y narrar una solución real con exclusiones en tres pasos, podrá afrontar la mayor parte de lo que una entrevista de backend le plantee sobre este tema. No necesita memorizar cada artefacto del ecosistema de Spring. Necesita entender el mecanismo lo bastante bien como para razonar una pregunta que no haya visto antes.
Antes de su próxima entrevista, ensaye dos cosas: una explicación clara de la relación entre starter, BOM y padre en lenguaje sencillo, y una historia de conflicto en la que ejecutó el árbol de dependencias, encontró el problema y lo solucionó con una exclusión. Esas dos respuestas, dadas sin dudar, harán más por su entrevista que un catálogo de nombres de starters.
Verve AI
Contenido