A volte non si traducono affatto nel core business dell'azienda. Questo è un dato di fatto.
Tuttavia, almeno una volta, sono associati a un problema aziendale principale del team o dell'azienda con cui stai intervistando i volti.
In una società con cui ho intervistato, principalmente noto per aiutare gli utenti a trovare un volo economico, mi è stato chiesto un paio di problemi con le radici nella complessità combinatoria e nel routing. Uno di questi era un problema di tipo "n", che può certamente verificarsi quando si dispone di un numero elevato di insiemi ed è necessario enumerare tutti i sottogruppi di elementi, ad esempio 1, 2 o 3; c'è almeno un caso plausibile che la ricerca di tutti i voli non-stop, one-stop e 2-stop potrebbe trarre beneficio dal sapere come risolvere il problema astratto. Separatamente, mi è stato chiesto un problema con lo scafo convesso 2D, che è strettamente correlato a una serie di problemi usati per esempio, rilevamento di collisioni in computer grafica, alcune classi di riconoscimento dell'immagine e problemi di trasformazione da grafica a testo e, in effetti, alcuni classi di problemi di routing; avrebbero potuto anche chiedermi del problema dello spanning tree minimo, che è stato precedentemente utilizzato, ad esempio, dalle compagnie telefoniche per capire dove posizionare quasi in modo ottimale pali e interruttori telefonici e simili, e anche in problemi di trasporto .
In questa particolare squadra, non avrei avuto alcun coinvolgimento nella risoluzione dei problemi di routing; Sarei stato principalmente concentrato sul lavoro di internazionalizzazione. Ma forse a causa della cultura dell'organizzazione e dei loro problemi principali di business, questi tipi di problemi ora pervadono il loro processo di intervista agli sviluppatori di software, indipendentemente da ciò su cui si potrebbe effettivamente lavorare.
Anche se non ho risolto particolarmente bene questi problemi, dato il mio background non-algoritmico, non accademico nel software, in qualche modo mi è stato offerto un lavoro; Immagino che in alcune organizzazioni, vogliono solo vederti sudare e vedere come ti avvicini ai problemi fuori dalla tua zona di comfort sotto pressione. In alcuni team, potrebbe essere stato davvero importante risolvere il problema bene, piuttosto che solo dimostrare il tuo processo di pensiero.
Anche se non penso che questa sia la migliore strategia possibile per identificare i buoni sviluppatori, Google, Amazon, Microsoft e dozzine di altre ben note aziende hanno adottato il processo di intervista per il nocciolo ritualizzato pesantemente algoritmatico, quindi potrebbe essere inevitabile dipende da dove vuoi lavorare. Puoi prepararti leggendo il Algorithm Design Manual di Skiena, che ti aiuterà a modellare i problemi concreti con quelli astratti e ti indurrà a proporre soluzioni appropriate, anche se non puoi implementarle in un'ora lungo colloquio di programmazione.
Se intervistassi un candidato per un ruolo che implicava una profonda conoscenza algoritmica, sarei incline a sondare proponendo problemi che richiedono loro di estrarre dal proprio kit di strumenti algoritmici. Tuttavia, nella maggior parte del mio lavoro, mi concentro principalmente sulla ricerca di candidati che capiscono perché fare tre strati di cicli nidificati per emettere query separate su un'origine esterna un ID alla volta è una cattiva idea e provare a trovare la prova che sanno come fare meglio di così Mi concentro sulla ricerca di prove che abbiano escogitato alcune strategie sensate per scrivere codice mantenibile, che abbiano una curiosità intellettuale e che abbiano abilità sociali di base. Cerco di verificare che hanno lavorato a fondo abbastanza con alcuni problemi che hanno imparato abbastanza da essere l'esperto locale su di esso.
Se finisci per intervistare in una società la cui attività è basata sulla risoluzione di alcuni problemi difficili con l'aiuto di algoritmi intelligenti, ci sono buone probabilità che cercheranno di trovare prove che anche tu puoi risolvere i problemi con l'aiuto di algoritmi intelligenti. Penso anche che, anche se si finisce per scrivere software aziendale "noioso", è utile avere una solida conoscenza del panorama degli algoritmi, perché riconoscerai approcci follemente cattivi quando li vedi e farai un passo indietro e proverai a trovare soluzioni migliori Ora ho visto un sacco di codice di produzione scadente che le scienze informatiche di base applicate al problema avrebbero impedito.
Per questo motivo, anche se non trovo l'intervista pesante con l'algoritmo tanto utile quanto alcune aziende sembrano, sono convinto che, se non riesci a vedere la connessione tra algoritmi astratti e reali problemi di business, il problema è, almeno in parte, tu. Puoi fare pratica sull'abbinamento dei pattern con l'aiuto del libro di Skiena e pensando ai problemi del mondo reale che ti piacerebbe risolvere e implementare soluzioni difendibili, quindi fallo.