Come ho superato il colloquio da software engineer in Adobe

TL;DR

• Ho superato il processo di selezione da software engineer in Adobe dopo aver quasi fallito il round in cui ti chiedono di raccontare una cosa che hai costruito tu.
• Il mio percorso è stato una call con recruiting, un technical screen di un'ora e quattro round di onsite: coding pratico, approfondimento su un progetto personale, un round di design con taglio di prodotto e una conversazione con l'hiring manager.
• L'asticella sul codice era molto più vicina al lavoro reale che al LeetCode difficile, e la profondità con cui ho difeso i miei compromessi tecnici ha pesato più della velocità sugli algoritmi.
• Se rifacessi la preparazione, dedicherei la prima settimana a scrivere il diario delle decisioni di tre progetti e solo la seconda a scrivere codice.

Introduzione

Ho mandato la candidatura ad Adobe a marzo dal telefono, in coda alla posta, con lo stesso curriculum che quel mese avevo spedito ad altre undici aziende. Facevo il full-stack da poco più di cinque anni in una software house di medie dimensioni a Milano, sul lato editor di un prodotto di documenti collaborativi, ed ero al terzo mese di un piano di preparazione molto disciplinato e molto sbagliato: 40 minuti di algoritmi prima del lavoro, 90 dopo, e un foglio di calcolo con una colonna rosso-giallo-verde per ogni pattern.

Sono finito con un'offerta per un ruolo di ingegneria di prodotto di livello intermedio, e sono arrivato a un round dal non prenderla per una ragione che con quel foglio di calcolo non c'entrava niente.

Come sono arrivato al colloquio

La candidatura in coda alla posta non ha prodotto nulla per sei settimane. Quello che l'ha smossa è banale: ho individuato un'ingegnera del team tramite una ex collega e le ho scritto un messaggio breve con la superficie di prodotto su cui volevo lavorare, una cosa concreta che avevo costruito lì vicino e la domanda se avesse senso una referral. Nove giorni dopo avevo la mail di recruiting.

Un dettaglio del mercato italiano che ho capito tardi: che una posizione sia pubblicata per l'Italia non vuol dire che il team stia in Italia. Nel mio caso era distribuito in Europa, la lingua di lavoro era l'inglese e Milano non era il centro di gravità di niente di quello che avrei toccato io. Chiedi dove vive davvero il team alla prima call.

La call con recruiting, 30 minuti, inizio aprile

Standard, ma non una formalità. Mi ha chiesto che lavoro volessi fare adesso e poi mi ha fatto due domande che da recruiting non mi aspettavo:

• «Qual è un prodotto che usi ogni giorno su cui hai un'opinione precisa riguardo a una specifica scelta di design?»
• «Raccontami una cosa che hai costruito dove oggi decideresti diversamente.»

Alla prima ho risposto bene, perché un'opinione sullo stack di undo di un editor di testo ce l'avevo. Alla seconda malissimo: qualcosa tipo «avremmo dovuto scrivere più test», l'equivalente da colloquio di dire che il tuo difetto più grande è che ci tieni troppo. L'ho vista annotare qualcosa.

Mi ha anche dato i nomi dei round: technical screen, poi coding, approfondimento su un progetto personale, design e hiring manager. Dalle quattro alle sei settimane fino alla decisione; il mio ne ha impiegate cinque.

Il technical screen, un'ora, metà aprile

Un editor condiviso con un ingegnere di un team vicino, e il primo segnale che la mia preparazione puntava dalla parte sbagliata. Avevo fatto sessioni a tempo su PhantomCodeAI prima della call, tutte su algoritmi, che era la prova generale sbagliata per quello che mi sono trovato davanti.

L'archetipo: fare il parsing di un piccolo formato di input strutturato, normalizzarlo in memoria e rispondere a un paio di query. Poi estenderlo. Poi gestire input malformati che non avevo considerato. Niente di difficile nel senso di LeetCode. Misurava se sapevo scrivere codice che un altro potesse mantenere: nomi sensati, una struttura dati scelta in base alle query e non per mettersi in mostra, errori che fallissero rumorosamente invece di restituire in silenzio una lista vuota.

L'ho passato, ma con due osservazioni. I primi quattro minuti li ho passati a digitare in silenzio, perché quello era il muscolo che avevo allenato. E quando mi ha chiesto di estendere il codice, il design iniziale mi si è messo di traverso, perché avevo ottimizzato per il primo requisito invece che per la forma del problema. L'ho sentito nella domanda dopo: «se avessi saputo che sarebbe arrivato questo, cosa avresti fatto diversamente all'inizio?». Quella domanda, travestita in mille modi, si è rivelata essere l'intero processo.

L'onsite: quattro round in due blocchi

Il mio onsite si è spezzato in due per un problema di agenda dalla loro parte: due round un giovedì e gli ultimi due il martedì successivo. Quei cinque giorni di intervallo sono l'unica ragione per cui ho un'offerta.

Round 1: coding pratico, 55 minuti

Un problema pratico con una cornice di prodotto. L'archetipo: dato un flusso di azioni utente, mantenere una vista derivata che risponda a basso costo a una domanda precisa e permettere di annullare le ultime N azioni.

La parte dell'undo è dove è diventato interessante. Il mio primo design ricalcolava la vista da zero, corretto e lento. L'intervistatore mi ha lasciato finire e ha chiesto cosa succede quando N è grande e il log è lungo. Ho confrontato un'operazione inversa per tipo di azione con snapshot ogni K azioni, ho scelto snapshot più replay perché l'inversa di un tipo era ambigua, e ho detto che così scambiavo memoria per semplicità. L'ho visto più soddisfatto del ragionamento che del codice, e oggi credo sia il senso del round.

Round 2: l'approfondimento sul progetto personale, 50 minuti — il round che ha rischiato di farmi fuori

Qui mi sono sfaldato. La consegna era semplice: «scegli una cosa che hai costruito negli ultimi due anni e raccontamela». Ho scelto il salvataggio automatico e la cronologia versioni del nostro editor. Bel progetto, esecuzione pessima.

Quello che ho consegnato è stato un giro turistico. Ecco il client, ecco la coda, ecco lo storage, ecco come funzionava la risoluzione dei conflitti, e reggeva qualche migliaio di documenti concorrenti. Cronologico. A forma di diagramma di architettura. Un talk da conferenza.

Lui continuava a tirarmi fuori dal giro turistico con domande a cui non sapevo rispondere bene:

• «Perché il debounce su un timer e non sui confini semantici del documento?»
• «Cosa avete perso scrivendo il documento intero invece di un delta?»
• «Chi si è lamentato per primo quando è andato in produzione, e di cosa?»
• «Cosa avete misurato prima di decidere che quello fosse il compromesso giusto?»

Avevo una risposta per due domande su quattro, e ricostruite a posteriori. La verità scomoda: alcune di quelle decisioni le aveva prese un tech lead in una riunione in cui ero presente senza obiettare, e non avevo mai ricostruito il ragionamento. Così ho fatto la cosa peggiore: ho coperto i buchi dicendo «abbiamo deciso» un sacco di volte.

Al quarantesimo minuto ha smesso di incalzarmi e ha iniziato a spiegarmi come il suo team affronta un problema simile, cosa che ho interpretato, correttamente, come il fatto che avesse finito di valutarmi. Ho chiuso la call e l'ho saputo.

C'è una trappola molto italiana qui dentro. Nei processi locali, quando ti dicono «raccontami un progetto», il giro turistico basta e avanza: racconti l'architettura, fai una figura decorosa e passi. Io avevo allenato quel formato per anni, e qui non vale niente.

I cinque giorni di intervallo

Avevo un weekend e tre serate. Non ho aperto un solo problema di algoritmi. Ho fatto due cose.

La prima: ho scritto quello che adesso chiamo il diario delle decisioni di tre progetti. Una pagina per progetto, con un formato rigido di proposito: la decisione, le due alternative che non abbiamo preso, il motivo concreto, il costo pagato, la cosa misurata e cosa cambierei oggi. Da tre a cinque decisioni per progetto. Quando non riuscivo a riempire una riga onestamente, andavo a cercarla in un vecchio documento di design, in un thread Slack di quattordici mesi prima o nella dashboard, per avere numeri invece che aggettivi.

La seconda: quattro mock loop su PhantomCodeAI concentrati soltanto su quel tipo di round. Le trascrizioni hanno reso il pattern imbarazzantemente evidente: all'inizio di ogni risposta raccontavo cronologia («prima abbiamo costruito X, poi ci siamo accorti che Y») invece di aprire con la decisione e il suo costo. Più di due minuti di media prima di dire qualcosa di valutabile. Alla quarta sessione aprivo con «la decisione interessante qui era A contro B, abbiamo scelto A, e ci è costata C».

Un dettaglio che in Italia conta e nessuno racconta: tutto questo lo stavo facendo in inglese, e la cronologia era anche il mio rifugio linguistico, perché raccontare una sequenza in un'altra lingua è più facile che difendere un compromesso tecnico. Provare le prime frasi direttamente in inglese mi ha tolto secondi di latenza per risposta.

Cambio piccolo. Valeva l'intero processo.

Round 3: design e architettura, 60 minuti

Con taglio di prodotto, non di infrastruttura. Non «progetta un accorciatore di URL», ma: progetta il comportamento offline e il modello di sincronizzazione di uno strumento di editing dove l'utente si aspetta che il suo lavoro sopravviva alla chiusura del portatile a metà frase. Due cose si staccavano nettamente dal system design in stile FAANG che avevo macinato per mesi.

I vincoli erano di esperienza utente, non di throughput. I follow-up: «cosa vede l'utente mentre questa roba si riconcilia», «cosa succede se due dispositivi non sono d'accordo e uno è il telefono», «quali fallimenti sono accettabili da rilasciare». Quando ho tirato fuori numeri di capacità, mi ha lasciato parlare novanta secondi e mi ha riportato sulla semantica dei conflitti.

Lo scoping è stato valutato esplicitamente. Intorno al minuto 40: «hai un ingegnere e sei settimane, cosa entra nella v1?». Ho tagliato l'editing offline completo, tenuto il recupero dopo crash da un buffer locale e lasciato la v1 con last-writer-wins e un banner di conflitto visibile, perché un merge silenzioso sbagliato è peggio di uno onesto e brutto. Lei ha insistito chiedendo se il banner non fosse una scappatoia; le ho detto di sì, che era quella giusta per sei settimane, e che avrei voluto telemetria su quante volte compariva prima di decidere sulla v2.

Lì il processo ha girato: ha smesso di essere una valutazione ed è diventato due persone che discutono una decisione di prodotto, e ho scelto di continuare a difendere la mia posizione invece di darle ragione.

Round 4: l'hiring manager, 50 minuti

Poco tecnico, e ha contato parecchio.

Mi ha chiesto cosa volessi fare fra due anni, quale feedback incasso male e cosa farei se un designer e io non fossimo d'accordo sul fatto che una feature sia pronta. Poi mi ha dato una situazione reale del suo team, una feature in uscita con uno spigolo noto, e mi ha chiesto cosa avrei tagliato, tenuto o rimandato.

Ho usato l'abitudine del diario senza averlo pianificato. Invece di una filosofia generale, ho nominato quale cosa avrei tagliato, perché quel taglio fosse economico e cosa avrei misurato dopo il rilascio per capire se avevo sbagliato. Ha discusso una delle mie scelte. Ho tenuto due punti, ho ceduto sul terzo e ho spiegato perché.

Verso la fine: «c'è qualcosa che facciamo su cui ci contesteresti?». Vale la pena prepararla. Ho nominato un comportamento preciso del prodotto che uso, ho spiegato perché fosse il default sbagliato e cosa avrei bisogno di sapere prima di fidarmi di quella opinione. Alla fine mi ha chiesto che domande avessi e io ne avevo sei scritte, che non è un tratto caratteriale ma il segnale più economico che puoi comprare.

L'attesa e la telefonata

Undici giorni di niente. All'ottavo ho mandato al recruiter una nota breve e per niente ansiosa chiedendo se servisse altro, che è la quantità massima accettabile di sollecito. La chiamata è arrivata un venerdì pomeriggio: offerta per il ruolo di livello intermedio, sul team con cui avevo parlato. Il dettaglio del debrief a cui ripenso spesso è che il round sul progetto personale è entrato come il segnale più debole del mio loop, e design e hiring manager l'hanno compensato.

La negoziazione, e cosa cambia in Italia

Non pubblico numeri: un dato singolo di una persona sola è peggio di nessun dato. La forma di quello che ho chiesto invece trasferisce, e in Italia ci sono verifiche che nelle guide scritte negli Stati Uniti non trovi.

1. La banda e la mia posizione dentro la banda. Non «riesci a fare di meglio?», ma «qual è il range per questo livello e questa sede, dove si colloca questa offerta e cosa concretamente la sposterebbe».
2. Su quante mensilità è distribuita la RAL. È la prima fonte di confronti sbagliati da noi: se vieni da un contratto con tredicesima e quattordicesima e confronti il lordo annuo senza normalizzare, decidi male in entrambe le direzioni. Chiedilo per iscritto, insieme al livello di inquadramento e alla parte variabile.
3. Se c'è una componente azionaria, il calendario. Fuori dalle grandi aziende tech è rara sul mercato italiano e molti la valutano malissimo. Chiedi durata del vesting, eventuale cliff iniziale e politica di refresh annuale.
4. Data di ingresso e primo progetto. Ho chiesto tre settimane in più per coprire il preavviso previsto dal mio contratto e me le hanno date subito. E ho chiesto per iscritto quale sarebbe stato il mio primo progetto: non è contrattuale, è chiarezza.

Ho chiesto anche di welfare aziendale e buoni pasto, che da noi sono una voce normale e quasi tutti valutano a occhio, e dell'accordo sul lavoro da remoto nero su bianco. Una componente si è mossa, le altre no. Esito normale.

Il piano di due settimane che rifarei

Con quattordici giorni, li spenderei così. Nota quanto poco codice c'è dentro.

Giorni 1-3: diari delle decisioni. Tre progetti, una pagina ciascuno, il formato di sopra. Se una riga resta vuota, cerca la risposta nei vecchi documenti di design, nei ticket e nelle dashboard. Almeno un numero reale per progetto. È la voce con il rendimento più alto e quasi nessuno la fa.

Giorno 4: provare le aperture. Per ogni decisione che esce da quei diari, dì la prima frase ad alta voce finché non apre con il compromesso invece che con la cronologia. Se il processo sarà in inglese, provala in inglese. Registrati. Fallo lo stesso.

Giorni 5-7: coding pratico, in un editor vero, niente rompicapi. Scegli problemi a cui puoi attaccare un secondo e un terzo requisito dopo averli chiusi, e scrivi i test. Se tutta la tua preparazione vive su una piattaforma che ti valuta contro test case nascosti, stai allenando il riflesso sbagliato; la raccolta di domande di coding serve per il pattern di estendere il proprio codice.

Giorni 8-10: design con taglio di prodotto. Progetta una sotto-funzionalità difficile di tre strumenti che usi: undo attraverso la rete, editing offline, versionamento, permessi su risorse condivise. Rispondi a «cosa entra nella v1 con un ingegnere e sei settimane» e a «cosa vede l'utente quando si rompe». Salta i calcoli di capacità.

Giorno 11: il round del manager. Scrivi perché quel team, cosa vuoi fare fra due anni, un disaccordo che hai perso e una cosa del prodotto su cui li contesteresti. Le domande comportamentali funzionano come traccia di partenza. Poi scrivi le tue sei domande.

Giorni 12-13: due mock loop completi, uno dietro l'altro. I miei li ho fatti su PhantomCodeAI perché mi serviva la trascrizione più di un'opinione gentile, e verificavo se sotto pressione scivolassi ancora nella cronologia. Fanne almeno uno da stanco, che è lo stato in cui arriverai al quarto round.

Giorno 14: niente. Rileggi i diari e dormi.

Cosa direi a me stesso a marzo

I tre mesi di algoritmi non sono stati tempo buttato: hanno reso i round di coding tranquilli. Ma erano proporzionati male. Il mio processo premiava la profondità su un sistema che avevo costruito davvero e la capacità di difendere una decisione di prodotto sotto un disaccordo garbato, e io non avevo dedicato tempo né all'una né all'altra.

Se ti alleni da mesi sul pattern FAANG e stai per fare un colloquio dove si vive di mestiere di prodotto, l'aggiustamento non è prepararsi di più. È prepararsi su un'altra cosa, puntando alla parte della tua esperienza che non hai mai dovuto spiegare a uno sconosciuto autorizzato a continuare a chiederti perché. Vai a scrivere il diario per primo: mi è costato quasi un'offerta impararlo.

Domande frequenti

Quanti round ha il processo di selezione Adobe?

Il mio ha avuto una call di 30 minuti con recruiting, un technical screen di un'ora su un editor condiviso e quattro round di onsite divisi in due blocchi. La forma del loop cambia in base al team e alla vacancy, quindi trattalo come l'esperienza di una singola persona e chiedi il calendario esatto al tuo recruiter. Quando l'ho chiesto io, mi ha mandato i nomi dei round e il focus di massima senza fare storie.

Il livello di coding è più difficile di LeetCode?

Non è più difficile, è diverso. I problemi del mio loop somigliavano più a un compito piccolo e realistico con requisiti che si aggiungono strada facendo che a un rompicapo con un trucco elegante. Mi hanno chiesto di dare nomi sensati, gestire input malformati ed estendere due volte il mio stesso codice, e questo punisce l'abitudine alla soluzione memorizzata costruita in tre mesi di grind.

Qual è stato il round che ha rischiato di farmi fuori?

L'approfondimento su un progetto costruito da me. Ho fatto un giro turistico cronologico dell'architettura invece di difendere le tre o quattro decisioni che c'erano dentro, e non sapevo dire perché avessimo scartato le alternative. In questo processo quel round è un segnale vero, non un riscaldamento, e lì ho rischiato l'offerta.

Si può affrontare il processo dall'Italia?

Io l'ho fatto interamente da remoto da Milano e tutti i round erano in inglese. La cosa da chiarire alla prima call è dove risiede davvero il team, perché una posizione pubblicata per l'Italia non significa automaticamente che il team sia qui, e questo cambia fuso orario, trasferte e aspettative di presenza in ufficio. Io l'ho chiesto tardi e mi è andata bene.

Quanto pesa la conversazione con l'hiring manager?

Nel mio caso ha pesato davvero. Non è stata una formalità finale, sono stati 50 minuti di discussione su compromessi di prodotto in cui ho dovuto dire cosa avrei tagliato da una feature e perché. Il recruiter mi ha raccontato dopo che quel round e quello sul progetto personale sono stati i due più discussi in debrief.

Cosa si negozia su un'offerta del genere in Italia?

Non pubblico cifre, perché il pacchetto di una singola persona è un pessimo riferimento per chi ha un altro livello e un'altra vacancy. La forma di quello che ho chiesto però trasferisce: la banda del livello, dove si collocava la mia offerta dentro quella banda e cosa la muoverebbe, la data di ingresso e quale sarebbe stato il mio primo progetto per iscritto. In Italia aggiungi due verifiche locali: se la RAL è distribuita su dodici, tredici o quattordici mensilità, perché il confronto senza normalizzare è il primo errore che facciamo tutti, e se c'è una componente azionaria quali sono vesting e politica di refresh.