Salesforce è un'azienda di circa 70.000 persone che vende software agli amministratori di altre aziende, non ai consumatori. È un dettaglio che riscrive il colloquio di ingegneria più di quanto ci si aspetti: il round di design parla di organizzazioni cliente e non di utenti, e la conversazione sulla cultura è un round valutato, non un saluto cordiale.
Il loop che i candidati descrivono più spesso comprende una call con l'hiring manager, live coding, system design e un round sui valori costruito sul vocabolario di casa: Ohana, il termine con cui Salesforce indica la propria comunità estesa di dipendenti, clienti, partner e community, e V2MOM, il framework interno di pianificazione (Vision, Values, Methods, Obstacles, Measures) con cui si fissano gli obiettivi e si misura l'avanzamento. Nessuno dei due è decorativo: entrambi finiscono dentro le domande.
Il modo di fallire è prevedibile. Ingegneri solidi superano il coding senza affanno e poi rendono sotto le attese nella call con l'hiring manager e nel round valoriale, dove vive una fetta scomodamente grande della decisione. Questi dieci consigli sono ordinati intorno a quell'asimmetria, e il primo vale se ti candidi dall'Italia.
1. Verifica se stai facendo un colloquio con Salesforce o con un partner dell'ecosistema
In Italia la maggior parte degli annunci che citano Salesforce non è di Salesforce. Sono società di consulenza e system integrator dell'ecosistema che cercano profili Apex, Lightning Web Components, flow e certificazioni Trailhead per progetti presso clienti. È un lavoro molto richiesto, ma il suo colloquio non assomiglia a quello di un software engineer di prodotto.
La versione sbagliata: studiare tre settimane di strutture dati e sistemi distribuiti per poi ritrovarsi davanti a domande sui governor limit di Apex, sui trigger e sul modello dei permessi. O il contrario, presentarsi a una posizione di piattaforma ripassando le certificazioni.
La versione giusta è risolverlo nella prima mail, prima di studiare qualsiasi cosa: chiedi se la vacancy è di Salesforce Inc. o di un partner, se si lavora sulla piattaforma o su implementazioni per clienti, dove risiede il team e se la posizione è da remoto dall'Italia o prevede trasferimento. Salesforce ha una presenza italiana con baricentro su Milano, ma l'organico locale è in larga parte commerciale, presales e servizi professionali, mentre molte posizioni di ingegneria fanno capo a team basati altrove in Europa.
Perché la versione pigra fallisce: ottimizzi la preparazione sbagliata per settimane e te ne accorgi al primo round tecnico, quando non c'è più spazio per correggere. È la domanda più economica del processo e quasi nessuno la fa.
2. Tratta la call con l'hiring manager come un round tecnico
Nella maggior parte delle aziende la call con il manager è una verifica di interesse reciproco dopo il filtro tecnico. Salesforce la mette spesso all'inizio, e quel manager è di solito chi ha aperto la posizione e chi ti sosterrà nel debrief. Presentarsi in modalità chiacchierata brucia l'ora con la leva più alta del processo.
La versione sbagliata: «sono da tre anni nel team pagamenti e cerco più scope». È il curriculum letto ad alta voce. Non lascia al manager niente con cui difenderti.
La versione giusta è arrivare con due progetti che reggono tre livelli di profondità e aprire dall'architettura, non dall'organigramma. «Sono responsabile del livello di idempotenza dell'ingestion dei pagamenti. Gestisce circa 40.000 webhook all'ora, e il guasto interessante è stato un regolamento duplicato quando il provider ha ritentato durante una partizione di rete. Ti racconto cosa abbiamo costruito e cosa cambierei oggi.» Poi lasciati interrompere.
Perché la prima fallisce: l'hiring manager non sta decidendo se sei simpatico, sta scrivendo mentalmente la tesi che dovrà sostenere davanti ad altri, e può difendere solo quello che gli hai dato. Ho fatto due simulazioni di questa call su PhantomCodeAI prima della mia, perché il mio istinto era partire dal ruolo invece che dal sistema.
3. Racconta i progetti con la logica del V2MOM senza mai dire «V2MOM»
V2MOM è il framework di pianificazione interna di Salesforce: Vision, Values, Methods, Obstacles, Measures. I team lo scrivono e lo usano per litigare sulle priorità. Nessuno ti interrogherà sull'acronimo, e recitarlo suona per quello che è.
Il valore sta altrove: quel framework ti dice cosa considera una storia completa un ingegnere di Salesforce. Il racconto tipico è pieno di metodi (cosa ho costruito) e vuoto di misure (come abbiamo saputo che funzionava).
La versione sbagliata: «abbiamo migrato il servizio di reportistica su un nuovo motore di query e adesso va molto più veloce».
La versione giusta: «l'obiettivo era permettere al supporto di rispondere sulle anagrafiche cliente senza escalare a ingegneria. Abbiamo spostato la reportistica su uno store colonnare. L'ostacolo è stato che un terzo delle query era filtrato dai permessi, quindi non potevamo precalcolare in modo ingenuo. La misura erano le escalation ogni mille ticket, passate da 18 a 4 in due trimestri».
Perché la prima fallisce: «molto più veloce» non è falsificabile, e la cultura di pianificazione interna di questa azienda è orientata alle misure. Un ingegnere che non sa nominare il numero che ha spostato sembra uno a cui venivano assegnati ticket. Attacca una metrica reale a ogni storia, incluse quelle andate male.
4. Nel live coding pubblica il contratto prima dell'algoritmo
Salesforce costruisce software di piattaforma sopra cui altri costruiscono. Lì un'interfaccia è una promessa, e romperla rompe il codice su misura di migliaia di clienti. All'intervistatore interessa quanto definisci il bordo almeno quanto come lo riempi.
La versione sbagliata: senti il problema, dici «qui mi serve una mappa» e cominci a scrivere. Dieci minuti dopo ti chiedono cosa succede con un campo nullo e va spostata tutta la struttura.
La versione giusta è spendere i primi tre minuti scrivendo la firma e i casi limite come commenti, prima di qualsiasi logica. «La funzione riceve una lista di record e restituisce un risultato più una lista di errori per record invece di sollevare un'eccezione, perché i chiamanti qui sono job batch che non possono abortire per una riga sbagliata. Comportamento non definito: id duplicati, input vuoto, record senza chiave di ordinamento. Gestisco i primi due e segnalo il terzo.» Poi scrivi il codice.
Perché la prima fallisce: produce una soluzione corretta in astratto e inutilizzabile come primitiva di piattaforma. La domanda vera è se progetteresti un'API da cui dipendono mille amministratori.
5. I test non si propongono: si scrivono, spiegando perché
C'è un fatto di piattaforma che conviene conoscere: il codice rilasciato su un'organizzazione Salesforce di produzione deve superare una soglia minima di copertura dei test Apex, storicamente il 75 per cento, verificata dalla piattaforma stessa al deploy. Lì testare non è un'aspirazione culturale, è un cancello che il runtime impone a ogni cliente.
Questo cambia come viene letta la tua chiusura. Chi finisce e dice «fatto» segnala qualcosa di diverso da chi finisce e comincia a elencare cosa verificherebbe.
La versione sbagliata: finire la funzione, restare in silenzio e poi dire «posso aggiungere dei test se vuoi».
La versione giusta: appena l'implementazione ti compila in testa, dici «faccio tre casi: batch vuoto, un id duplicato e un record con chiave di ordinamento nulla. Il duplicato è quello di cui davvero non mi fido, perché il mio merge tiene l'ultima scrittura e non sono sicuro che sia il default corretto qui». E li scrivi, se c'è tempo.
Perché la prima fallisce: offrire i test come cortesia li rende opzionali. Su una piattaforma dove il codice non coperto letteralmente non si può rilasciare, quella sfumatura si vede.
6. Metti la multi-tenancy sulla lavagna nei primi cinque minuti
È la differenza più grande rispetto ai colloqui di design su scala consumer che quasi tutti provano. Non progetti per un milione di utenti di un prodotto, ma per migliaia di organizzazioni cliente che condividono infrastruttura e danno per scontato che i propri dati siano privati e le proprie prestazioni siano sue.
La versione sbagliata: disegnare load balancer, application tier, database, partizionare per id utente e partire con la cache. Quel design è rotto in silenzio: un import notturno enorme di un solo cliente può affamare tutti gli altri.
La versione giusta: nei primi minuti, «prima di scalare voglio fissare il confine di tenant. I dati sono partizionati per id organizzazione e ogni query lo porta con sé, imposto nel livello di accesso ai dati e non per convenzione. Poi voglio quote per organizzazione sulla coda dei job asincroni, perché il vicino rumoroso qui è il caricamento massivo di un cliente grande che monopolizza i worker.» E a quel punto progetti le quote, che è la parte interessante.
Perché la prima fallisce: risponde a una domanda di capacità quando la domanda era di isolamento. La piattaforma di Salesforce è nota per i governor limit proprio perché condividere infrastruttura obbliga a imporre tetti per cliente. Il nostro banco di domande di system design è un buon posto per allenare questa forma.
7. Progetta per l'amministratore del cliente, non solo per l'utente finale
I prodotti Salesforce vengono configurati pesantemente da amministratori del cliente che aggiungono campi, cambiano regole di validazione e costruiscono automazioni senza coinvolgere ingegneria. Un design che assume uno schema fisso è sbagliato per l'intero modello di business.
La versione sbagliata: uno schema relazionale normalizzato con un elenco fisso di colonne per l'entità principale, e «il cliente vuole un campo nuovo» risolto con una migrazione.
La versione giusta è portare l'estendibilità in superficie. «I clienti aggiungeranno campi a questo oggetto, quindi separerei le colonne di proprietà della piattaforma da un livello di metadati definiti dal cliente, con le definizioni dei campi salvate come dati e indicizzate in modo selettivo invece di aggiungere colonne fisiche per tenant. Il prezzo è una pianificazione delle query peggiore, che mitigherei con viste materializzate per organizzazione sui campi su cui filtrano davvero.»
Perché la prima fallisce: costringe a una release di ingegneria per ogni modifica di configurazione di un cliente, esattamente l'accoppiamento che il SaaS enterprise esiste per eliminare. Non serve riprodurre l'architettura interna di Salesforce: serve dimostrare di aver notato che lo schema non è tuo, e dichiarare il costo della tua flessibilità.
8. Progetta il guasto e la comunicazione al cliente, non solo il percorso felice
Salesforce pubblica lo stato dei propri servizi e i clienti ci costruiscono sopra processi operativi. La disponibilità è un impegno commerciale, non uno SLO su una dashboard interna. Una risposta che si ferma a «e aggiungiamo i retry» manca il punto del round.
La versione sbagliata: «se l'integrazione a valle è giù, ritentiamo con backoff esponenziale». Punto.
La versione giusta scende di un livello, verso la degradazione e la comunicazione. «Se la sincronizzazione non è disponibile, le scritture vanno in coda con un tetto per organizzazione e le letture servono l'ultimo valore noto con un timestamp di obsolescenza visibile in interfaccia, perché per un cliente enterprise un dato vecchio in silenzio è peggio di un dato dichiaratamente vecchio. Oltre una soglia lo pubblichiamo sulla pagina di stato invece di lasciare che ogni amministratore lo scopra per conto suo.»
Perché la prima fallisce: i retry sono igiene di base e li dicono tutti. L'istinto che distingue nel software enterprise è che i guasti hanno un pubblico, e quel pubblico è fatto di amministratori paganti che devono sapere cosa raccontare ai propri utenti.
9. Rispondi al round valoriale con un episodio che ti è costato qualcosa
Il round sui valori viene valutato ed è quello dove i candidati preparati suonano peggio. Restituire all'intervistatore la definizione di Ohana è il modo più comune di non superarlo.
La versione sbagliata: «mi ritrovo molto nell'idea di Ohana perché credo in una cultura familiare in cui ci si sostiene e si mette il cliente al primo posto». È la parafrasi di una pagina pubblica e non contiene nessuna informazione su di te.
La versione giusta: un episodio con un compromesso reale e il prezzo detto ad alta voce. «Avevamo un cliente bloccato su un formato di export deprecato. La risposta pulita da ingegneria era costringerlo a migrare. Ho passato tre settimane a costruire uno strato di compatibilità che sapevamo che avremmo cancellato, e questo ha fatto slittare di uno sprint una feature mia. Lo rifarei, ma su una cosa ho sbagliato: non ho detto al mio manager che sarebbe slittata finché non era già slittata.»
Perché la prima fallisce: questi round misurano se hai mai pagato per un principio, non se sai riconoscerne uno. E c'è un livello locale: si fanno in inglese, e una storia piena di sfumature in una lingua che non è la tua si improvvisa male. Ho ripetuto questo round tre volte in inglese su PhantomCodeAI proprio per quello. Il banco di domande comportamentali copre la meccanica generale; la mossa specifica di Salesforce è il costo dichiarato.
10. Fai domande da chi sa che Salesforce non è una sola azienda
Salesforce è cresciuta in buona parte per acquisizioni, e la realtà ingegneristica cambia tra i gruppi di prodotto: linguaggio, cadenza di rilascio e quanto un team poggi sulla piattaforma comune. Le domande generiche sprecano l'unico momento in cui puoi interrogare l'intervistatore.
La versione sbagliata: «com'è una giornata tipo?» e «cosa ti piace di lavorare qui?». Producono risposte che potevi prevedere.
La versione giusta, rivolta all'hiring manager: «il tuo team rilascia sul treno di release della piattaforma o in modo indipendente?», «quanta parte dello stack è condivisa con il core e dove avete infrastruttura vostra?», «nei prossimi due trimestri, come si divide il ruolo tra piattaforma multi-tenant e feature di prodotto?».
Poi il follow-up, entro ventiquattro ore e indirizzato all'hiring manager e non solo al recruiter: tre frasi con dentro un'idea nuova. «Un pensiero in più sulle quote per organizzazione: avevo detto tetto ai job concorrenti, ma la primitiva migliore è una coda equa pesata per organizzazione, così un tenant grande degrada a lento invece che a bloccato.» Il ringraziamento generico compete con quello di tutti; una nota tecnica breve consegna al manager una frase concreta per il debrief.
Cosa fare con la settimana che ti resta
Se il tempo è poco, la ripartizione che serve a questo processo non è quella di un loop FAANG. Il coding deve essere automatico, ma raramente è il round che chiude una candidatura in Salesforce. Dedica tempo sproporzionato alla narrativa per l'hiring manager, raccontata con misure vere, e a un design multi-tenant che sai costruire da una lavagna bianca, quote e livello di schema configurabile e storia di degradazione compresi.
Metti in ordine anche due questioni pratiche che in Italia arrivano sempre tardi: il tuo preavviso reale, che secondo CCNL e livello può essere di uno o due mesi e che un recruiter estero quasi mai stima correttamente, e se la posizione comporta lavorare sul fuso di un altro paese o trasferirsi. E se ti fanno confrontare un'offerta con la tua situazione attuale, normalizza tu i numeri prima di rispondere: una multinazionale ragiona di solito su dodici mensilità, mentre molti contratti italiani ne includono tredici o quattordici, quindi il confronto diretto tra RAL inganna.
Quello che ho fatto la settimana prima del mio processo è stato incatenare la call con l'hiring manager e il round valoriale due volte di fila su PhantomCodeAI, perché erano proprio i due che non riuscivo a provare con un amico senza sentirmi ridicolo. Il pattern che usciva dalle trascrizioni era sempre lo stesso: spiegavo bene l'architettura e male i risultati, che è esattamente la lacuna che nota un'azienda ossessionata dalle misure.