Casi todas las guías de entrevistas por empresa funcionan porque la empresa tiene un proceso: aprendes las rondas, aprendes los criterios y te preparas contra ellos. Oracle rompe ese modelo, y lo rompe de una forma que le cuesta la oferta a gente muy bien preparada.
Oracle tiene alrededor de 160.000 empleados y sus organizaciones internas contratan de manera casi independiente. Oracle Cloud Infrastructure construye y opera una nube a escala de hiperescalar. La organización de base de datos mantiene una de las bases de código en C más obsesionadas con el rendimiento del software comercial. La parte de aplicaciones publica Fusion, NetSuite y una cola larga de producto empresarial, y siguen existiendo equipos sobre líneas con décadas de base instalada. Culturas de ingeniería distintas, paneles distintos e ideas distintas de lo que es un buen ingeniero.
Así que la versión honesta de «cómo superar la entrevista de Oracle» no es una lista de rondas. Es un método para averiguar con qué Oracle estás hablando y prepararte contra esa. Estos diez consejos van sobre esa idea, con la capa española encima: desde aquí hay una pregunta previa que casi nadie hace y que decide el resto.
1. Identifica la organización antes de preparar nada
La hora más rentable de toda tu preparación es la que dedicas a averiguar a qué organización pertenece la vacante. No el producto: la organización.
La forma equivocada: lees «Software Engineer, Oracle», haces doscientos problemas de LeetCode de dificultad media, ensayas un diseño de acortador de URL y te sientas delante de cuatro ingenieros de base de datos que se pasan noventa minutos hablando de expulsión de buffer cache y escalado de bloqueos.
La forma correcta: antes de resolver un solo problema de práctica, decides si esto es OCI, base de datos, aplicaciones o una línea de producto madura, y dejas que esa decisión gobierne todo lo demás. Una vacante de redes en OCI y una de middleware de Fusion son, en términos de preparación, dos búsquedas de empleo distintas que casualmente comparten empleador.
Esto pesa más en Oracle que en empresas con comités centrales, porque aquí no hay un órgano que renormalice tu evaluación contra un estándar corporativo. El equipo que te entrevista suele ser el que te contrata, y su idea del listón es el listón. La preparación genérica estilo FAANG no es incorrecta en Oracle: simplemente no apunta a nadie en concreto.
2. Comprueba si la vacante es de ingeniería de producto y dónde vive el equipo
Es el paso que casi nadie da desde España, y el que más tiempo te ahorra.
La presencia histórica de Oracle en España se concentra en la zona de Madrid y en Barcelona, y está muy escorada hacia perfiles comerciales, consultoría, cloud engineering orientado a cliente, preventa y soporte. Son trabajos técnicos reales y con buen recorrido, pero su proceso no se parece al de un equipo de producto: pesan mucho más la conversación con cliente, la arquitectura aplicada y el conocimiento funcional que las rondas de algoritmos.
Que exista una región de Oracle Cloud en España tampoco implica plantilla de ingeniería de producto aquí. Una región es infraestructura y operación comercial; los equipos que escriben el plano de control suelen estar en otros países.
La forma correcta es preguntarlo en la primera llamada, con estas palabras: ¿esta vacante es de producto o de servicios profesionales? ¿En qué país están el manager y la mayoría del equipo? ¿La contratación es local o hay que reubicarse? Si la respuesta apunta a Bucarest, Dublín o India, tienes un dato de movilidad que conviene resolver antes de invertir seis semanas de estudio, no después.
3. Lee la oferta como un mapa organizativo, no como una descripción de puesto
Las ofertas de Oracle llevan más información organizativa de la que la mayoría de candidatos extrae, porque suelen escribirse cerca del equipo que contrata y no en un departamento central de marca empleadora.
Mira el orden de los lenguajes. Una oferta que pone C y C++ por delante de Java casi nunca está siendo educada con el código heredado: está describiendo lo que vas a escribir. Una que abre con Java, Kubernetes y Terraform es un equipo de servicio. Una que abre con SQL, PL/SQL, modelado de datos y ETL está pegada a la organización de datos aunque el título diga otra cosa.
Mira los sustantivos de producto. «OCI», «control plane», «tenancy» o «region build» te sitúan en infraestructura cloud. «Fusion», «SaaS», «integraciones REST» o «BI Publisher» te sitúan en aplicaciones. «Optimizador», «RAC», «redo» o «motor de almacenamiento» te sitúan en base de datos.
Mira la ubicación y el idioma de la oferta. Una vacante publicada en inglés para un centro concreto y otra publicada en español para Madrid rara vez pertenecen a la misma organización.
La forma equivocada es ojear los años de experiencia y pasar página. La correcta es tratar la oferta como la única inteligencia gratuita que tienes antes de la llamada, y llegar a ella con una hipótesis que puedas confirmar con una sola pregunta.
4. Convierte la llamada con recruiting en un temario
Las personas de recruiting en Oracle suelen estar alineadas a una organización concreta, lo que las convierte en una fuente excelente de información estructural. Pero solo si haces preguntas estructurales.
La mayoría de candidatos usa esa llamada para contar su carrera y luego preguntar por el producto. Eso la desperdicia. Pregunta en su lugar: ¿en qué organización está este equipo? ¿Cuántas entrevistas tiene el proceso y van en un solo día o repartidas? ¿Los entrevistadores son todos del equipo que contrata o vienen de otros equipos? ¿Hay ronda de diseño, y es de sistemas distribuidos o de diseño de componentes? ¿Habrá ejercicio de código y en qué lenguaje?
Esas cinco preguntas convierten un vago «la entrevista de Oracle» en un temario concreto. Y las respuestas varían mucho: quienes pasan por la organización de OCI suelen describir una pantalla técnica seguida de un panel de cuatro o cinco rondas, mientras que algunos equipos de aplicaciones y de producto describen procesos más cortos que se apoyan sobre todo en la conversación con el hiring manager.
Repite las mismas preguntas, en tono informal, con la primera persona que te dé espacio al final de su ronda. «¿En qué equipo estás tú y qué relación tiene con el que me contrataría?» te dice si tienes delante un panel cerrado de un solo equipo o un proceso transversal, y eso cambia cómo dosificas la energía el resto del día.
5. Si el puesto está cerca del dato, espera SQL de verdad
Aquí es donde más falla la preparación genérica. El material típico trata el SQL como calentamiento: escribe un join, usa un GROUP BY, quizá una función de ventana. En la organización de base de datos, en los servicios de datos de OCI y en los roles analíticos de aplicaciones, ese nivel se da por supuesto y no se pregunta.
Lo que se examina es el razonamiento de debajo. ¿Por qué el optimizador eligió aquí un hash join y allí un nested loop? ¿Qué le pasa a esta consulta cuando una clave concentra el cuarenta por ciento de las filas? ¿Qué índice añadirías, qué cuesta en escritura y cómo confirmarías que se usa? ¿A qué nivel de aislamiento corre de verdad esta aplicación y qué anomalía permite? ¿Cómo diagnosticas una consulta que llevaba un año siendo rápida y ahora es lenta con el mismo plan?
La forma equivocada de prepararse es memorizar más acertijos de consultas. La forma correcta es saber hablar en voz alta de ejecución, coste y contención usando un ejemplo de tu propio trabajo: una consulta que optimizaste, qué mediste y qué te costó ese arreglo en otro sitio.
Si tienes oxidada la mecánica, arréglala aparte antes de llegar a la capa de razonamiento; el banco de preguntas de SQL sirve para esa base. Este artículo no reproduce ese material a propósito.
6. En infraestructura, C y los fundamentos de sistemas siguen siendo la puerta
Quien viene de un perfil web o de plataforma moderna suele asumir que las preguntas de memoria son una reliquia. Dentro de partes de Oracle son el trabajo diario.
Los equipos de almacenamiento, red, virtualización y motor de base de datos mantienen bases de código gigantes en C y C++, y sus entrevistadores recurren a ese material con naturalidad. Los candidatos describen preguntas sobre semántica de punteros y referencias, disposición y alineación de estructuras, tiempo de vida en pila frente a montículo, qué ocurre realmente en un realloc y dónde muerde el comportamiento indefinido. La concurrencia aparece como primitivas y no como frameworks: mutex frente a spinlock, para qué sirve una barrera de memoria, cómo detectarías una condición de carrera en un fragmento que te enseñan.
La forma equivocada es responder en el lenguaje en el que estás cómodo y confiar en que la otra persona traduzca. Si la oferta es de C, contestar en Python indica que no leíste la sala.
La correcta es escribir C de verdad, en pequeñas dosis, las dos semanas previas: un asignador de tamaño fijo, un buffer circular, una cola segura entre hilos. Así tus respuestas se apoyan en algo que construiste y no en algo que repasaste.
7. Diseña para multitenencia y regiones, no para escala de consumo
Las rondas de diseño de OCI tienen acento propio. La respuesta canónica de escala de consumo —particiona la base de datos, mete una caché, pon una CDN delante— cae plana, porque los problemas que definen a un proveedor cloud son otros.
Lo que suele premiarse es razonar con las restricciones del propio proveedor. Multitenencia: ¿cómo evitas que un inquilino ruidoso degrade a otro y cómo mides lo que ha consumido cada uno? Plano de control frente a plano de datos: ¿qué componentes tuyos pueden estar caídos diez minutos sin romper cargas de clientes que ya están corriendo? Regiones y dominios de disponibilidad: ¿cuál es el radio de impacto de este fallo y tu diseño crea una dependencia que cruza una frontera que no debería cruzar? Identidad: ¿quién puede llamar a esto y dónde se aplica esa comprobación?
La forma equivocada es presentar una arquitectura y esperar preguntas. La forma correcta es enunciar las hipótesis de multitenencia y de dominio de fallo sin que te las pidan, al principio, y diseñar contra ellas: ese orden es en sí mismo la señal de que has trabajado en infraestructura y no solo en funcionalidades.
Para la estructura general de una conversación de diseño, el banco de preguntas de system design es el punto de partida; lo específico de la organización es el vocabulario de arriba.
8. En aplicaciones y Fusion el listón se mueve a producción, no a algoritmos
Fusion, NetSuite y la organización de aplicaciones entrevistan para otro animal, y quien llega sobreentrenado en algoritmia se lleva sorpresas por lo prácticos que son estos procesos.
Espera preguntas de integración y flujo de datos: ¿cómo reconcilias dos sistemas que creen los dos ser dueños de la ficha de un cliente? ¿Cómo haces idempotente una integración cuando el sistema de origen reintenta? ¿Qué haces cuando un batch nocturno que tardaba cuatro horas ahora tarda nueve? ¿Cómo versionas una API sobre la que clientes empresariales ya han construido y a los que no puedes obligar a actualizar?
La forma equivocada es responderlas como puzles abstractos. La correcta es responderlas como incidentes, con uno real de tu historial, incluida la parte en la que el primer arreglo no funcionó.
Hay además un componente de dominio que la preparación genérica ignora del todo. Saber qué es un plan contable, o cómo se mueve un flujo de pedido a cobro, no se examina formalmente, pero cambia lo creíble que suenas. Y ojo con una confusión frecuente en España: muchas vacantes de Fusion publicadas aquí son de consultoría de implantación, no de desarrollo de producto.
9. Prepárate un panel de un solo equipo que profundiza, en inglés
En empresas con procesos centralizados, los entrevistadores se eligen a propósito de distintas áreas para que ninguna perspectiva domine. Los paneles de Oracle se montan con frecuencia con gente del propio equipo que contrata, y eso cambia la física del día.
Primero, van a fondo. Si en la primera ronda asomó una debilidad en, digamos, tu comprensión del retraso de replicación, hay una posibilidad real de que la tercera vuelva sobre ello: no para castigarte, sino porque han comparado notas. La repetición es diagnóstica, no accidental.
Segundo, comparten contexto. No necesitas reconstruir tu currículum en cada ronda, y hacerlo largo se lee como falta de lectura de la situación. Dos frases y al problema.
Tercero, desde España añade la capa práctica: el panel será en inglés técnico y probablemente repartido entre husos horarios, con rondas a última hora de la tarde si hay gente en Estados Unidos o muy temprano si la hay en India. Yo hice tres simulacros en PhantomCodeAI la semana anterior precisamente en la franja horaria mala, y lo que descubrí no fue una laguna técnica: era que a las siete y media de la tarde y en inglés empezaba a hablar antes de tener un plan.
10. Cuenta con un proceso largo y silencioso, y recuerda que un «no» es de un equipo
Oracle se mueve a velocidad de empresa grande. Los huecos de varias semanas entre etapas son normales. Las vacantes se pausan, se reabren o se transfieren a otro equipo a mitad de proceso, y puede que recruiting no pueda contarte por qué. Es habitual vivir un silencio largo, darlo por rechazo y recibir después un correo para agendar.
La forma equivocada es leer el silencio como veredicto y o bien rendirte o bien mandar seguimientos semanales. La correcta es fijar expectativas explícitas en la llamada inicial —«¿qué plazo es realista y cuándo debo escribir?»— cumplir esa cadencia y llevar en paralelo tus otros procesos sin mala conciencia. En España eso importa más de lo que parece, porque los procesos locales van bastante más rápido y no van a esperarte.
El corolario es lo que casi nadie aprende a tiempo: como la contratación está descentralizada, un rechazo suele estar acotado a ese equipo u organización y no a Oracle entera. Gente que no pasa el listón de un equipo de base de datos y entra meses después en OCI no es una anomalía. Pregunta a recruiting si en tu caso aplica algún periodo de espera corporativo en vez de asumir la convención de seis meses de otras grandes tecnológicas. Y si ya trabajas en Oracle, el movimiento interno entre organizaciones suele ser más corto que volver a entrar desde fuera.
Qué hacer con todo esto
Si te llevas una sola cosa de la lista, que sea la primera. Casi todos los rechazos evitables de Oracle que he oído contar acaban en un candidato que se preparó a fondo para la organización equivocada.
Una vez sabes la organización, el trabajo es estrecho en lugar de enorme: la profundidad correcta en la materia correcta, más la capacidad de decirlo en voz alta bajo presión y en un idioma que no es el tuyo. Esa segunda parte es la que la gente se salta. En los simulacros que hice en PhantomCodeAI alterné a propósito una ronda con sabor a base de datos con otra de infraestructura, y el hallazgo útil no fue una laguna de conocimiento: fue que narraba con soltura en terreno conocido y me callaba en cuanto la pregunta se movía de lado.
Primero la investigación de la organización. Después, preparación profunda para esa organización, y el resto lo dejas ir.