TL;DR
- Non esiste «il colloquio Oracle».
- L'azienda ha circa 160.000 dipendenti e le sue organizzazioni assumono in modo quasi indipendente, quindi un loop di Oracle Cloud Infrastructure, uno dell'organizzazione database e uno delle applicazioni Fusion possono non avere nulla in comune tranne il logo.
- La prima cosa da preparare è capire a quale organizzazione appartiene la posizione, perché è questo a decidere se ti aspettano design di sistemi distribuiti, fondamenti di C e di sistema oppure SQL e modellazione dati seri.
- Dall'Italia serve un passaggio in più: verificare se la posizione è davvero di ingegneria di prodotto e in quale paese risiede il team, perché le sedi di Milano e Roma concentrano soprattutto ruoli commerciali, di consulenza e di supporto.
- Il panel di solito è composto dal team che assume, va in profondità invece che in ampiezza, e l'hiring manager è chi decide.
Introduzione
Quasi tutte le guide ai colloqui per azienda funzionano perché l'azienda ha un processo: impari i round, impari i criteri, ti prepari contro quelli. Oracle rompe questo modello, e lo rompe in un modo che costa l'offerta a candidati arrivati preparatissimi.
Oracle ha circa 160.000 dipendenti e le organizzazioni al suo interno assumono in modo quasi indipendente. Oracle Cloud Infrastructure costruisce e gestisce un cloud su scala hyperscaler. L'organizzazione database mantiene una delle basi di codice C più ossessionate dalle prestazioni del software commerciale. L'area applicazioni rilascia Fusion, NetSuite e una coda lunga di prodotti enterprise, e continuano a esistere team su linee con decenni di base installata. Culture ingegneristiche diverse, panel diversi, idee diverse di cosa sia un buon ingegnere.
Quindi la versione onesta di «come superare il colloquio Oracle» non è un elenco di round. È un metodo per capire con quale Oracle stai parlando, e poi prepararti contro quella. Questi dieci consigli nascono da qui, con sopra il livello italiano: da noi c'è una domanda preliminare che quasi nessuno fa e che decide tutto il resto.
1. Capisci in quale organizzazione stai entrando, prima di studiare qualsiasi cosa
L'ora più redditizia di tutta la tua preparazione è quella che passi a capire a quale organizzazione appartiene la posizione. Non il prodotto: l'organizzazione.
Il modo sbagliato: leggi «Software Engineer, Oracle», macini duecento problemi LeetCode di livello medio, ripassi un design da accorciatore di URL e ti ritrovi davanti a quattro ingegneri database che passano novanta minuti su eviction della buffer cache e lock escalation.
Il modo giusto: prima di risolvere un solo esercizio decidi se questa è OCI, il database, le applicazioni o una linea di prodotto matura, e lasci che quella decisione governi tutto il resto. Una posizione di networking in OCI e una di middleware Fusion sono, in termini di preparazione, due ricerche di lavoro diverse che per caso condividono il datore.
Questo pesa più in Oracle che nelle aziende con comitati centrali di assunzione, perché qui non c'è un organo che rinormalizzi la tua valutazione rispetto a uno standard aziendale. Il team che ti intervista è di solito il team che ti assume, e la sua idea dell'asticella è l'asticella. La preparazione generica in stile FAANG non è sbagliata in Oracle: semplicemente non è rivolta a nessuno in particolare.
2. Verifica che sia davvero ingegneria di prodotto e dove vive il team
È il passaggio che quasi tutti in Italia saltano, ed è quello che fa risparmiare più tempo.
La presenza storica di Oracle in Italia si concentra nell'area di Milano e a Roma, ed è molto sbilanciata verso ruoli commerciali, consulenza, cloud engineering rivolto al cliente, presales e supporto. Sono lavori tecnici veri e con prospettive reali, ma il loro processo di selezione non somiglia a quello di un team di prodotto: contano molto di più la conversazione con il cliente, l'architettura applicata e la conoscenza funzionale che i round di algoritmi.
Il fatto che esistano region Oracle Cloud in Italia non implica organici di ingegneria di prodotto qui. Una region è infrastruttura e presidio commerciale; chi scrive il control plane di solito sta altrove.
Il modo giusto è chiederlo alla prima call, con queste parole: questa posizione è di prodotto o di servizi professionali? In quale paese sono il manager e la maggior parte del team? L'assunzione è locale o è previsto un trasferimento? Se la risposta indica Bucarest, Dublino o l'India, hai in mano un dato di mobilità da risolvere prima di investire sei settimane di studio, non dopo. Se invece la risposta è «team distribuito, contratto italiano», chiedi anche chi sarà nel panel: è la stessa domanda travestita.
3. Leggi l'annuncio come una mappa organizzativa, non come una job description
Gli annunci Oracle contengono più segnale organizzativo di quanto la maggior parte dei candidati estragga, perché di solito nascono vicino al team che assume e non in una funzione centrale di employer branding.
Guarda l'ordine dei linguaggi. Un annuncio che mette C e C++ prima di Java quasi mai sta usando un eufemismo per il codice legacy: sta descrivendo quello che scriverai. Uno che apre con Java, Kubernetes e Terraform è un team di servizio. Uno che apre con SQL, PL/SQL, modellazione dati ed ETL è attaccato all'organizzazione dati, qualunque cosa dica il titolo.
Guarda i sostantivi di prodotto. «OCI», «control plane», «tenancy», «region build» ti collocano nell'infrastruttura cloud. «Fusion», «SaaS», «integrazioni REST», «BI Publisher» ti collocano nelle applicazioni. «Optimizer», «RAC», «redo», «storage engine» ti collocano nel database.
Guarda la sede e la lingua dell'annuncio. Una vacancy pubblicata in inglese per un centro specifico e una pubblicata in italiano per Milano raramente appartengono alla stessa organizzazione.
Il modo sbagliato è scorrere gli anni di esperienza richiesti e passare oltre. Quello giusto è trattare l'annuncio come l'unica intelligence gratuita che hai prima della call, e arrivarci con un'ipotesi verificabile con una sola domanda.
4. Trasforma la call con il recruiter in un programma di studio
I recruiter Oracle sono spesso allineati a una singola organizzazione, il che li rende una fonte ottima di informazioni strutturali. Ma solo se fai domande strutturali.
La maggior parte dei candidati usa quella call per raccontarsi e poi chiedere del prodotto. Così la spreca. Chiedi invece: in quale organizzazione sta questo team? Quanti colloqui prevede il processo e sono in un'unica giornata o distribuiti? Gli intervistatori sono tutti del team che assume o vengono da altri team? C'è un round di design, ed è sistemi distribuiti o design di componente? Ci sarà un esercizio di codice e in quale linguaggio?
Cinque domande che trasformano un vago «il colloquio Oracle» in un programma concreto. E le risposte variano parecchio: chi passa dall'organizzazione OCI racconta di solito uno screening tecnico seguito da un panel di quattro o cinque round, mentre alcuni team applicativi e di prodotto descrivono loop più corti, sbilanciati sulla conversazione con l'hiring manager.
Ripeti le stesse domande, in tono informale, con la prima persona che ti lascia spazio a fine round. «Tu in quale team sei e che rapporto ha con quello che assume?» ti dice se hai davanti un panel chiuso di un solo team o un processo trasversale, e questo cambia come dosi l'energia nel resto della giornata.
5. Se il ruolo è vicino al dato, aspettati SQL vero
È qui che la preparazione generica fallisce di più. Il materiale tipico tratta l'SQL come riscaldamento: scrivi una join, usa un GROUP BY, magari una window function. Nell'organizzazione database, nei data services di OCI e nei ruoli analitici delle applicazioni quel livello è dato per scontato e non viene chiesto.
Quello che viene valutato è il ragionamento sotto. Perché l'optimizer ha scelto una hash join qui e un nested loop lì? Cosa succede a questa query quando una chiave concentra il quaranta per cento delle righe? Quale indice aggiungeresti, quanto costa in scrittura e come verificheresti che venga usato? A quale livello di isolamento gira davvero questa applicazione e quale anomalia permette? Come diagnostichi una query rimasta veloce per un anno e ora lenta con lo stesso piano?
Il modo sbagliato di prepararsi è memorizzare altri rompicapo di query. Quello giusto è saper parlare a voce alta di esecuzione, costo e contesa partendo da un esempio del tuo lavoro: una query che hai ottimizzato, cosa hai misurato e cosa quella scelta ti è costata altrove.
Se hai arrugginito il livello meccanico, sistemalo a parte prima di arrivare al ragionamento: il set di domande SQL serve a quella base. Questo articolo non riproduce quel materiale di proposito.
6. Nell'infrastruttura il C e i fondamenti di sistema restano il filtro
Chi arriva da un profilo web o di piattaforma moderna spesso dà per scontato che le domande sulla memoria siano un reperto storico. Dentro alcune parti di Oracle sono il lavoro quotidiano.
I team di storage, rete, virtualizzazione e motore database mantengono basi di codice enormi in C e C++, e i loro intervistatori pescano lì con naturalezza. I candidati raccontano domande su semantica di puntatori e riferimenti, layout e allineamento delle struct, lifetime su stack e su heap, cosa succede davvero in una realloc e dove morde l'undefined behaviour. La concorrenza arriva come primitive e non come framework: mutex contro spinlock, a cosa serve una memory barrier, come individueresti una race condition in un frammento che ti mostrano.
Il modo sbagliato è rispondere nel linguaggio in cui sei comodo sperando che l'altra persona traduca. Se l'annuncio è un annuncio in C, rispondere in Python dice che non hai letto la stanza.
Quello giusto è scrivere C vero, in piccole dosi, nelle due settimane precedenti: un allocatore a blocchi fissi, un ring buffer, una coda thread-safe. Così le risposte poggiano su qualcosa che hai costruito e non su qualcosa che hai ripassato.
7. Progetta per multi-tenancy e region, non per scala consumer
I round di design di OCI hanno un accento tutto loro. La risposta canonica da scala consumer — sharda il database, metti una cache, davanti una CDN — cade nel vuoto, perché i problemi che definiscono un cloud provider sono altri.
Quello che di solito viene premiato è ragionare con i vincoli del provider stesso. Multi-tenancy: come eviti che un tenant rumoroso degradi gli altri e come misuri quello che ciascuno ha consumato? Control plane contro data plane: quali tuoi componenti possono restare giù dieci minuti senza rompere carichi cliente già in esecuzione? Region e availability domain: qual è il raggio d'impatto di questo guasto e il tuo design crea una dipendenza che attraversa un confine che non dovrebbe? Identità: chi è autorizzato a chiamare questo, e dove viene applicato il controllo?
Il modo sbagliato è presentare un'architettura e aspettare le domande. Quello giusto è dichiarare le ipotesi su multi-tenancy e failure domain senza che te le chiedano, subito, e progettare contro quelle: è proprio quell'ordine il segnale che hai lavorato su infrastruttura e non solo su funzionalità.
Per la struttura generale di una conversazione di design il set di domande di system design è il punto di partenza; la parte specifica dell'organizzazione è il vocabolario qui sopra.
8. In Fusion e nelle applicazioni l'asticella si sposta sulla produzione
Fusion, NetSuite e l'organizzazione applicativa selezionano un altro animale, e chi arriva sovrallenato sull'algoritmica viene spesso spiazzato da quanto siano pratici questi loop.
Aspettati domande su integrazione e flusso dei dati: come riconcili due sistemi che credono entrambi di possedere l'anagrafica di un cliente? Come rendi idempotente un'integrazione quando il sistema a monte ritenta? Cosa fai quando un batch notturno che durava quattro ore adesso ne dura nove? Come versioni un'API su cui clienti enterprise hanno già costruito e che non puoi obbligare ad aggiornarsi?
Il modo sbagliato è rispondere come se fossero rompicapo astratti. Quello giusto è rispondere come si racconta un incidente, con uno vero della tua storia, inclusa la parte in cui la prima correzione non ha funzionato.
C'è poi una componente di dominio che la preparazione generica ignora del tutto. Sapere cos'è un piano dei conti, o come si muove un flusso order-to-cash, non viene valutato formalmente ma cambia quanto suoni credibile. E attenzione a un equivoco frequente in Italia: molte posizioni Fusion pubblicate qui sono di consulenza applicativa, non di sviluppo di prodotto.
9. Preparati a un panel di un solo team che va in profondità, in inglese
Nelle aziende con loop centralizzati gli intervistatori vengono scelti apposta da aree diverse, perché nessuna prospettiva domini. I panel Oracle si compongono spesso con persone dello stesso team che assume, e questo cambia la fisica della giornata.
Primo, vanno a fondo. Se nel primo round è emersa una debolezza sul, mettiamo, ritardo di replica, c'è una possibilità concreta che il terzo ci torni: non per punirti, ma perché si sono confrontati. La ripetizione è diagnostica, non casuale.
Secondo, condividono il contesto. Non serve ricostruire il curriculum da zero a ogni round, e farlo a lungo suona come mancata lettura della situazione. Due frasi e dritti al problema.
Terzo, dall'Italia c'è lo strato pratico: il panel sarà in inglese tecnico e probabilmente spalmato su fusi orari diversi, con round a tarda sera se c'è gente negli Stati Uniti o molto presto se c'è gente in India. Ho fatto tre simulazioni su PhantomCodeAI la settimana prima proprio nella fascia oraria scomoda, e quello che ho scoperto non era una lacuna tecnica: alle sette e mezza di sera e in inglese cominciavo a parlare prima di avere un piano.
10. Metti in conto tempi lunghi e silenziosi, e ricorda che il «no» è del team
Oracle si muove a velocità enterprise. Gli intervalli di più settimane tra una tappa e l'altra sono normali. Le vacancy vengono sospese, riaperte o trasferite a un altro team a metà processo, e può darsi che il recruiter non possa spiegarti perché. È comune vivere un silenzio abbastanza lungo da darlo per rifiuto e ricevere poi una mail per fissare il round successivo.
Il modo sbagliato è leggere il silenzio come verdetto e o mollare o mandare solleciti settimanali. Quello giusto è fissare aspettative esplicite già alla prima call — «quale tempistica è realistica e quando ha senso che ti scriva?» — rispettare quella cadenza e portare avanti in parallelo gli altri processi senza sensi di colpa. In Italia conta più di quanto sembri, perché i processi locali corrono molto più in fretta e non ti aspettano.
Il corollario è la parte che quasi nessuno impara in tempo: poiché le assunzioni sono decentralizzate, un rifiuto è di solito circoscritto a quel team o a quell'organizzazione e non a Oracle intera. Persone che non passano l'asticella di un team database ed entrano mesi dopo in OCI non sono un'anomalia. Chiedi al recruiter se nel tuo caso vale un periodo di attesa aziendale, invece di assumere la convenzione dei sei mesi di altre grandi aziende tech. E se già lavori in Oracle, il passaggio interno tra organizzazioni è spesso una strada più corta che rientrare dall'esterno.
Cosa farne
Se da questa lista porti via una cosa sola, porta via la prima. Quasi tutti i rifiuti evitabili in Oracle che ho sentito raccontare finiscono su un candidato che si era preparato benissimo per l'organizzazione sbagliata.
Una volta nota l'organizzazione, il lavoro diventa stretto invece che enorme: la profondità giusta sull'argomento giusto, più la capacità di dirlo a voce alta sotto pressione e in una lingua che non è la tua. È la seconda parte quella che si salta. Nelle simulazioni fatte su PhantomCodeAI ho alternato di proposito un round in salsa database e uno infrastrutturale, e la scoperta utile non è stata una lacuna: raccontavo con scioltezza sul terreno noto e ammutolivo appena la domanda si spostava di lato.
Prima la ricerca sull'organizzazione. Poi preparazione profonda per quell'organizzazione, e il resto lascialo andare.
Domande frequenti
Esiste un unico processo di selezione tecnico in Oracle?No, e darlo per scontato è l'errore di preparazione più comune. Oracle Cloud Infrastructure, l'organizzazione database, l'area applicazioni e Fusion e le linee di prodotto storiche gestiscono loop propri con criteri propri. Chi ci passa racconta numeri di round, tipi di domanda e tempi di risposta molto diversi a seconda di dove si trova la vacancy dentro l'azienda.
Oracle assume ingegneri di prodotto in Italia?Storicamente la presenza italiana di Oracle, concentrata nell'area di Milano e a Roma, è fatta soprattutto di ruoli commerciali, consulenza, cloud engineering rivolto al cliente, presales e supporto, più che di team di prodotto core. Non significa che non esistano posizioni tecniche, ma conviene chiedere subito se la posizione è di prodotto o di servizi e in quale paese risiede il manager. La risposta cambia completamente il modo in cui devi prepararti.
Quanto SQL serve davvero in un colloquio Oracle?Dipende dalla vicinanza al dato. Per ruoli di compute, rete o piattaforma dentro OCI può non comparire quasi mai. Nell'organizzazione database, nei data services di OCI o nei ruoli analitici e Fusion aspettati domande serie su indici, piani di esecuzione, join su dati sbilanciati, livelli di isolamento e lock: non le query da manuale che trovi negli elenchi generici.
Nei ruoli infrastrutturali si chiede ancora il C?Molto spesso sì. Parti di OCI e dell'organizzazione database mantengono basi di codice enormi in C e C++, e chi intervista attinge a quel materiale con naturalezza: semantica dei puntatori, layout di memoria, undefined behaviour e primitive di concorrenza. Se l'annuncio cita C o C++ prima di Java o Python, tratta quell'ordine come un segnale e non come testo di riempimento.
Quanto durano i tempi e cosa succede se mi rifiutano?Il processo è lento e silenzioso: settimane tra una tappa e l'altra, vacancy che vengono sospese o spostate di team a metà strada. E poiché le assunzioni sono decentralizzate, un rifiuto di solito riguarda quel team o quell'organizzazione, non Oracle nel suo complesso. Chiedi direttamente al recruiter se nel tuo caso vale un periodo di attesa a livello aziendale, invece di dare per buona la convenzione dei sei mesi di altre grandi aziende tech.