Perché le interviste di ingegneria SW sono sproporzionatamente difficili (rispetto alle interviste di ricerca)? [chiuso]

Innanzitutto, alcuni retroscena su di me. Ho un dottorato di ricerca in CS e ho avuto lavori sia come ingegnere del software che come ricercatore di ricerca e sviluppo, entrambi presso società molto grandi che conosci molto bene. Di recente ho cambiato lavoro e intervistato per entrambi i tipi di posizioni (come ho fatto in passato).

La mia osservazione: le interviste di lavoro per ingegneri SW sono molto più sproporzionate rispetto alle interviste di lavoro di ricercatori CS, ma il lavoro di ricercatore è più remunerativo, più competitivo, più gratificante, più interessante e ha un rialzo più elevato.

Ecco un tipico ciclo di interviste per i ricercatori:

• Intervista telefonica per vedere se la mia ricerca è in linea con quella del laboratorio
• Di persona: fai una presentazione sulla mia recente ricerca per un'ora (che rappresenta forse un lavoro di 9 mesi) e rispondi alle domande del pubblico
• Interviste individuali con circa 5 ricercatori, dove mi fanno domande molto ragionevoli sul mio lavoro / pubblicazioni / brevetti, tra cui: domande tecniche, dove il mio lavoro si inserisce nel lavoro correlato e come posso estendere il mio lavoro a nuove aree

Ecco un tipico ciclo di interviste per l'ingegnere SW:

• Intervista telefonica in cui mi vengono poste domande sull'algoritmo e magari fare un po 'di programmazione. Piuttosto standard.
• Interviste di persona alla lavagna in cui eseguono il drill out di te su minutia C ++ esoterica (ad es. Come funziona una funzione polimorfica virtuale), algoritmi (per far funzionare l'algoritmo a tutto il percorso più corto per vertici 1B) , progettazione del sistema (progettazione di un bilanciamento del carico del database), ecc. Questo continua per sei o sette interviste. Ridicolo.

Perché qualcuno dovrebbe essere disposto a sopportarlo? Qual è lo scopo di chiedere informazioni su C ++ o scrivere codice per metterti alla prova? Perché non rendere l'intervista di SE più simile all'intervista di un ricercatore in cui parli di quello che hai fatto?

Come sono le interviste di lavoro tecniche per altri settori, come la fisica, la chimica, l'ingegneria civile, l'ingegneria meccanica?

È relativamente facile stabilire se sei abbastanza tecnicamente competente per fare la ricerca: hai pubblicazioni che i responsabili delle assunzioni possono leggere e quelle pubblicazioni probabilmente suggeriscono ad altre persone con cui possono parlare per darti un'occhiata.

L'ingegneria del software, d'altra parte, è una disciplina così piena di sprechi di spazio incompetenti che occorre fare con la dovuta diligenza per assicurarsi che il ragazzo che stai assumendo possa effettivamente scrivere il codice che stai pianificando di assumerlo per scrivere.

Uscire su un arto qui.

Come ricercatore con un dottorato di ricerca, hai già dimostrato a più organizzazioni riconosciute il tuo valore e le tue qualità minime di ricercatore. Hai difeso con successo una tesi davanti a una commissione dei tuoi colleghi e hai convinto almeno una pubblicazione peer review a pubblicare il tuo lavoro.

Lo sviluppo del software, d'altra parte, non ha standard di qualificazione. Le persone abitualmente aumentano la propria base di conoscenza. Di conseguenza, le interviste sullo sviluppo del software devono svolgere tutto il lavoro svolto dalla difesa di dottorato e dalla revisione tra pari in ambito accademico. Ti fanno provare che sai davvero di cosa stai parlando.

Consideralo per un momento.

Se avessi cercato di candidarmi per questo lavoro di ricercatore CS, non avrei potuto vedere il mio CV / CV. Non vorrei arrivare a un'intervista in primo luogo. Avrei ricevuto una lettera standardizzata "senza titolo avanzato" che mi diceva che non ero nemmeno qualificato per vedere il mio CV.

Le mie domande sono queste: "Perché è così difficile ottenere un dottorato di ricerca?" E "Perché ho bisogno di un dottorato di ricerca per essere ricercatore CS?" "Perché così tante barriere ed ostacoli?"

Perché qualcuno dovrebbe essere disposto a sopportarlo?

Qual è lo scopo di fare tutto quel lavoro del corso e di far stampare la ricerca su riviste e conferenze? Perché non posso semplicemente fare la ricerca e essere pagato più di quanto faccio per l'ingegneria?

Perché affidarsi a scuole di specializzazione e pubblicazioni per stabilire le credenziali? Perché non rendere l'intervista di ricerca più simile alle interviste di SE in cui tutto dipende da cosa puoi ricordare in questo momento durante l'intervista?

Bene, ho una teoria. La ricerca è generalmente finanziata da sovvenzioni, quindi l'offerta di denaro è elevata. Hanno un secchio di soldi da spendere e hanno solo bisogno di trovare qualcuno per spenderli. Indipendentemente dal fatto che tu realizzi qualcosa in quella posizione o meno, la società / istituzione non registra una perdita netta perché era comunque solo una spesa contabilizzata. C'è poco rischio nell'assumere la persona sbagliata. Lo scenario peggiore è che buttano via tutto ciò che hai fatto.

D'altra parte, il successo o il fallimento dei prodotti esistenti dipende dalle sviluppatori quotidiane. Soprattutto se sei nello sviluppo del prodotto, sei un centro di profitto per l'azienda. Gli sviluppatori buoni o cattivi hanno un impatto enorme che va ben oltre il costo del loro stipendio. Un cattivo sviluppatore in realtà provoca danni. Possono arretrare una squadra, lanciare un prodotto, ecc. Le conseguenze dell'assunzione di un cattivo ingegnere SW sono molto più alte.

La nostra azienda "pone anche molte domande difficili" e spiegherò perché. Ci importa se sai davvero come viene eseguita una chiamata di funzione virtuale, ma non perché è così critico per il lavoro che farai.

Invece ci interessa perché dobbiamo sapere quanto velocemente puoi imparare cose fondamentali. Hai X anni di esperienza? Ok, faremo domande difficili per scoprire se hai una solida conoscenza.

Non sai come viene effettuata una chiamata di funzione virtuale sotto il cofano, ma sai tutto sulla profilazione e sull'ottimizzazione? Fantastico, probabilmente ti assumiamo: hai acquisito solide conoscenze in un campo e quindi acquisirai sicuramente solide conoscenze in un altro.

Sostieni X anni di esperienza nello "sviluppo, debug e correzione del codice C ++" e non puoi spiegare in parole semplici come un puntatore punta a un oggetto? Spiacenti, non possiamo assumerti: se non puoi farlo, come spiegherai problemi più difficili quando dovremo prendere decisioni tecniche complesse?

Risposta breve: ci sono molte persone sul mercato che affermano di conoscere la programmazione, ma non possono programmare.

Nota a margine : sono sorpreso che nessuno abbia pubblicato un link al saggio di FizzBuzz .

Prenderò una strada diversa e dirò che il problema potrebbe non essere tanto che le interviste di ingegneria del software sono intrinsecamente più difficili, ma piuttosto che settori diversi sono alla ricerca di cose diverse che mostrino nel loro stile di intervista.

Ho intervistato in una vasta gamma di settori (ad es. Start-up, piccola azienda, grande azienda, dipartimento IT interno, società di software, organizzazione di ricerca) e tutti hanno un modo diverso di intervistare che ho trovato di solito tende a seguire il seguente schema:

• Start-up tendono ad essere preoccupati di sapere che si può iniziare a scrivere codice in questo momento e in grado di gestire un ambiente percorso veloce veloce. In quanto tali, tendono a preoccuparsi di quanto sai dalla cima della testa in quanto a quanto pare non vogliono vederti passare molto tempo a cercare ciò che ritengono essere una conoscenza "fondamentale". Ammettere di non sapere qualcosa potrebbe non essere una buona cosa in questo ambiente se è qualcosa che si aspettano che tu sappia.
• Le piccole aziende tendono a cercare le stesse cose delle start-up per quanto ne sai, ma non sono così preoccupate di come gestisci gli ambienti frenetici (dipende dal lavoro) e di più con quale tipo di soft skills tu portare e quanto bene ti adatterai alla compagnia.
• Le grandi aziende e i dipartimenti IT interni sembrano essere più preoccupati di garantire di avere un determinato standard di conoscenza tecnica, ma non sono così preoccupati se non si conosce tutto al di sopra della testa poiché anticipano che ci saranno alcuni tempo impiegato per farti addestrare su ciò che l'azienda si aspetta. Pertanto, questo è un ambiente in cui ammettere che non si conosce qualcosa ma si è disposti a imparare e studiare può essere visto come un vantaggio.
• Nell'ambiente di ricerca (ovvero supporto allo sviluppo di software per scienziati nella mia esperienza) tendono a preoccuparsi se è possibile scrivere software, ma ancora di più se si è disposti a fare ciò che è necessario per assicurarsi di poter apprendere ciò che stanno facendo non devono tenerti per mano mentre stai cercando di risolvere un problema. Dal momento che è anche un ambiente di ricerca, sembrano anche interessati a quanto sei interessato a imparare cose nuove.

Ora, ho trascurato di menzionare le società di software (ad esempio Google, Microsoft) poiché tendono a fare le proprie cose e, a seconda della maturità dell'azienda e del gruppo che stai intervistando, stanno cercando cose diverse.

Alla fine della giornata però e come nella maggior parte delle cose nella vita, tutto dipende. Personalmente ho scoperto che alcune aziende si concentrano molto sulla "conoscenza del libro" che potrebbe comportare il costo di essere in grado di risolvere effettivamente i problemi di livello superiore, mentre altre società sembrano essere molto preoccupate di come si gestiscono i problemi di livello superiore (ad es. puoi progettare uno schema per x ) e operare presupponendo che siano disposti a investire da tre a sei mesi per ottenere la massima velocità prima che tu sia pienamente produttivo.

Sono uno sviluppatore di software (c / c ++) con oltre 20 anni nel settore. Il tipo di interviste che vediamo abitualmente ora (i rompicapo, l'implementazione di strutture di dati, gli algoritmi di ricerca ecc. Sulla lavagna) non si verificavano molto, tranne che per i neolaureati. Se una persona lavorava per un'azienda rispettabile per un ragionevole periodo di tempo, quella era considerata la prova della propria capacità di scrivere codice. Ora è diventato molto scolastico e non sono sicuro del perché. Davvero, le cose tipiche che ti chiedono di codificare, POSSONO essere memorizzate, quindi farlo sulla lavagna non dimostra nulla. In un progetto di lavoro, utilizzeresti Internet per cercare qualcosa e non scriveresti mai le btrees o le liste collegate.

Penso che sia un'altra mania gestionale - proprio come Scrum - con questo probabilmente avviato da Google, Amazon e Microsoft. Tutti gli altri hanno copiato proprio come hanno fatto con il grado di Jack Welch e lo strattone ... ricordi GE?

Se sei un gestore delle assunzioni che legge i miei commenti, ciò che DOVREBBE chiedere ai candidati è COME farebbero per risolvere determinati problemi. Invece di chiedere loro di codificare una tabella hash, dai loro un problema che coinvolge una tabella hash e chiedi come potrebbero risolverlo.

Concordo anche con lo sviluppatore sopra questo post che ha detto "dai loro un problema reale che la società ha dovuto risolvere"!

"ma tenderei a bombardare le domande OOP / Ereditarietà. Perché? Una volta aggiunto il supporto per i modelli, ho usato il C ++ quasi esclusivamente per la Programmazione generica."

Sono anche d'accordo con quanto sopra. Quando lavori per un'azienda, scrivi il codice LORO modo. A volte faccio ancora fatica a ricordare la sintassi del richiamo del C ++ dalla cima della mia testa perché l'architetto senior della società per cui ho lavorato 15 anni, ha preferito usare puntatori, non riferimenti. Vedete, era un vecchio programmatore C. Questo è quello che abbiamo usato tutti.

Ancora una volta, l'intervista tecnica è arbitraria e capricciosa.

C'è una grande differenza tra grigliare una persona in minuzie e vedere se conoscono il loro CS. Come ho detto sopra, ho più di un decennio di esperienza con il C ++, ma tenderei a bombardare le domande OOP / Ereditarietà. Perché? Perché una volta aggiunto il supporto per i modelli, ho usato C ++ quasi esclusivamente per la programmazione generica .

Ho intervistato diverse aziende di BigHouseHoldNameTech nell'area della baia e di Seattle, e una delle migliori interviste ha riguardato domande reali con cui hanno dovuto confrontarsi sul lavoro, coinvolgendo strutture di dati e algoritmi [ovvero: hai 300 miliardi di punti dati costituito da XYZ. Come archiviate e cercate in modo efficiente? ].

Questo praticamente ti fa sapere come un candidato potrebbe intervenire e aiutarti a risolvere i problemi reali che stai affrontando. Il peggio è stato anche con un'altra società BigHouseHoldNameTech, ma hanno posto ore di domande incredibilmente arcane che dovresti davvero cercare in un manuale [ cioè descrivere le principali differenze tra il PCB in Windows vs Linux - e questo non era ' t per una posizione a livello di kernel ]

Gli hedge fund sono bizzarri con la loro intenzione di torturare ... aspettarsi 8 ore per risolvere i problemi del tipo a zaino su una lavagna.