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

È relativamente facile stabilire se sei sufficientemente competente tecnicamente per fare la ricerca - hai pubblicazioni che i responsabili delle assunzioni possono leggere e quelle pubblicazioni suggeriscono probabilmente ad altre persone con cui possono parlare per controllarti.

L'ingegneria del software, d'altra parte, è una disciplina così piena di sprechi incompetenti di spazio che è necessario fare un sacco di due diligence facendo in modo che il ragazzo che si sta assumendo possa in realtà scrivere il codice che si prevede di assumerlo a 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 qualità minime come ricercatore. Hai difeso con successo una tesi davanti a una commissione dei tuoi colleghi e hai convinto almeno una pubblicazione peer reviewed per pubblicare il tuo lavoro.

Lo sviluppo del software, d'altra parte, non ha standard di qualifica. La gente di solito gonfia la propria base di conoscenze. Di conseguenza, le interviste sullo sviluppo del software devono fare tutto il lavoro che la difesa e la revisione tra pari fanno nel mondo accademico. Ti fanno provare che sai davvero di cosa stai parlando.

Considera questo per un momento.

Se avessi provato a candidarmi per questo lavoro di ricercatore CS, non avrei esaminato il mio CV / curriculum. Non vorrei arrivare a un'intervista, in primo luogo. Avrei ricevuto una lettera standardizzata "no advanced degree" che mi diceva che non ero nemmeno qualificato per vedere il mio CV.

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

Perché qualcuno dovrebbe essere disposto a tollerare questo?

Che senso ha fare tutto ciò che il corso funziona e ottenere la ricerca stampata su riviste e conferenze? Perché non posso semplicemente fare la ricerca e pagarmi più di quello che 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 SE in cui tutto dipende da ciò che puoi ricordare in questo momento durante l'intervista?

Anche la nostra azienda "fa molte domande difficili" e spiegherò perché. Ci interessa sapere se sai davvero come viene eseguita una chiamata di funzione virtuale, ma non perché sia così criticamente richiesta per il lavoro che farai.

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

Non sai come viene chiamata una funzione virtuale sotto il cofano, ma sai tutto sulla profilazione e sull'ottimizzazione? Fantastico, è probabile che ti assumiamo - hai acquisito una solida conoscenza in un campo e così acquisirai sicuramente una solida conoscenza in un altro campo.

Hai rivendicato X anni di esperienza nello sviluppo, nel debugging e nel fixing del codice C ++ e non puoi spiegare in parole semplici come un puntatore punta a un oggetto? Siamo spiacenti, non possiamo assumerti - se non puoi farlo, come spiegheresti i problemi più difficili quando dobbiamo prendere decisioni tecniche complesse?

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

Nota a margine: sono sorpreso che nessuno abbia postato un link a FizzBuzz saggio .

Ho intenzione di prendere una strada diversa e dire che il problema potrebbe non essere così tanto che le interviste di ingegneria del software sono intrinsecamente più difficili, ma piuttosto che diversi settori sono alla ricerca di cose diverse che mostrano nel loro stile di intervista.

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

• Le start-up tendono a preoccuparsi di sapere che puoi iniziare a scrivere codice adesso e gestire un ambiente a ritmo rapido. In quanto tali, tendono a preoccuparsi di quanto tu sappia dalla cima della tua testa poiché apparentemente non vogliono vederti passare molto tempo a cercare ciò che ritengono una conoscenza "di base". Ammettere di non sapere qualcosa potrebbe non essere una cosa così positiva in questo ambiente se è qualcosa che si aspetta che tu sappia.
• Le piccole aziende tendono a cercare le stesse cose delle start-up per quanto ne sai, ma non sono così preoccupate per quanto bene gestisci ambienti frenetici (dipende dal lavoro) e più con che tipo di le abilità soft che porti e in che misura ti ritroverai con la compagnia.
• Le grandi aziende e i dipartimenti IT interni sembrano essere più interessati a garantire un livello standard di conoscenza tecnica, ma non sono preoccupati se non si sa tutto di testa perché si aspettano che lì ci vorrà un po 'di tempo per farti addestrare su ciò che la compagnia si aspetta. Quindi, questo è un ambiente in cui ammettere di non sapere qualcosa ma di voler imparare e studiare può essere visto come un vantaggio.
• Nell'ambiente di ricerca (ad esempio, il supporto allo sviluppo di software per gli scienziati nella mia esperienza) tendono a preoccuparsi se è possibile scrivere software, ma ancora di più se si è disposti a fare ciò che è necessario per garantire che si possa imparare cosa stanno facendo in modo che non debbano tenere la mano mentre stai cercando di risolvere un problema. Dal momento che è anche un ambiente di ricerca, sembrano anche interessati a quanto sei interessato all'apprendimento di cose nuove.

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

Alla fine della giornata però e come con la maggior parte delle cose nella vita, tutto dipende. Personalmente ho scoperto che alcune aziende si concentrano molto sulla "conoscenza del libro" che potrebbe venire a scapito di essere in grado di risolvere effettivamente i problemi di livello più alto dove le altre aziende sembrano essere molto preoccupate di come gestire i problemi di livello più elevato (ad esempio, puoi progettare uno schema per x ) e operare nell'ipotesi che siano disposti a investire da tre a sei mesi per essere completamente aggiornato prima che tu possa essere pienamente produttivo.

Ancora una volta, il colloquio tecnico è arbitrario e capriccioso.

C'è una grande differenza tra grigliare una persona sulle minuzie e vedere se conoscono il proprio CS. Come ho detto sopra, ho più di un decennio di esperienza con 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 Programmazione generica .

Ho intervistato diverse compagnie BigHouseHoldNameTech nella Bay Area & Seattle e una delle migliori interviste hanno coinvolto le domande reali che hanno dovuto affrontare sul lavoro, coinvolgendo strutture dati e algoritmi [es: Hai 300 miliardi di punti dati composti da XYZ . Come memorizzi efficientemente & ricerca? ].

Questo ti consente di sapere in che modo un candidato può intervenire e aiutare a risolvere i problemi reali che stai affrontando. Il peggio è stato anche con un'altra società di BigHouseHoldNameTech, ma hanno chiesto ore di domande incredibilmente arcane che dovresti semplicemente cercare in un manuale [ i.e. descrivere le principali differenze tra il PCB in Windows e Linux - e questo non era per una posizione a livello di kernel ]

Gli hedge fund sono bizzarri con il loro intento di tortura ... aspettati 8 ore di risoluzione dei problemi di tipo zaino su un lavagna.

Sono uno sviluppatore di software (c / c ++) con oltre 20 anni nel settore. Il tipo di interviste che vediamo ora di routine (i rompicapo, l'implementazione delle strutture dati, gli algoritmi di ricerca ecc. Sulla lavagna) non era usato molto tranne che per i newgrad. Se una persona lavorava per una società stimabile per un ragionevole periodo di tempo, questa era considerata una prova della capacità di scrivere codice. Ora è diventato molto scolastico e non sono sicuro del perché. In realtà, le cose tipiche che ti chiedono di codificare, possono essere memorizzate, quindi farlo sulla lavagna non dimostra nulla. In un progetto di lavoro, dovresti utilizzare Internet per effettuare ricerche e non scrivere da btrees o elenchi collegati. Ciò di cui le aziende hanno veramente bisogno ora sono gli innovatori e chiedere a qualcuno di dimostrare che è possibile scrivere da strutture di memoria del college non dimostra innovazione.

Penso che sia un'altra moda passeggera - proprio come la mischia - con questa probabilmente avviata da Google, Amazon e Microsoft. Tutti gli altri hanno copiato proprio come hanno fatto con il grado e lo strattone di Jack Welch ... ricordi GE?

Se sei un gestore assumente che legge i miei commenti, quello che dovresti chiedere ai candidati è come faranno per risolvere determinati problemi. Invece di chiedere loro di codificare una tabella hash, dai loro un problema che riguarda una tabella hash e chiedi come lo risolveranno.

Sono d'accordo anche con lo sviluppatore sopra questo post che ha detto "dai loro un problema del mondo reale che l'azienda ha dovuto risolvere"!

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

Sono d'accordo anche con quanto sopra. Quando lavori per un'azienda, scrivi il codice THE THE way. A volte faccio fatica a ricordare la sintassi del C ++ per sintassi di riferimento dalla parte superiore della mia testa perché l'architetto senior della compagnia per cui ho lavorato per 15 anni preferiva usare i puntatori, non i riferimenti. Era un vecchio programmatore C che vedi. Questo è quello che abbiamo usato tutti.