it-swarm.it

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

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 su come 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 ciò che hai fatto?

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

40

È 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 bisogna 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.

45
Wyatt Barnett

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 di sviluppo 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.

30
Ryan Michela

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?

17
S.Lott

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 rallentare un team, lanciare un prodotto, ecc. Le conseguenze dell'assunzione di un cattivo ingegnere SW sono molto più elevate.

6
Scott Whitlock

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 a Saggio FizzBuzz .

5
Nikita Barsukov

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? Siamo spiacenti, non possiamo assumerti: se non puoi farlo, come spiegherai problemi più difficili quando dovremo prendere decisioni tecniche complesse?

5
sharptooth

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 programmare, POSSONO essere memorizzate, quindi farlo sulla lavagna in realtà non dimostra nulla. In un progetto di lavoro, utilizzeresti Internet per cercare qualcosa e non scriveresti mai album o elenchi collegati da zero. Ciò di cui le aziende hanno veramente bisogno ora sono gli innovatori e chiedere a qualcuno di dimostrare di poter scrivere dalle strutture di memoria del college non dimostra innovazione.

Penso che sia un'altra moda - proprio come Scrum - con questa probabilmente avviata 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, quello 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é? Poiché 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 di chiamata C++ per riferimento nella parte superiore della mia testa perché l'architetto senior dell'azienda per cui ho lavorato 15 anni, ha preferito usare puntatori, non riferimenti. Vedete, era un vecchio programmatore C. Questo è quello che abbiamo usato tutti.

3
guest

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 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:

  • Le start-up tendono a preoccuparsi di sapere che puoi iniziare a scrivere codice in questo momento e puoi gestire un ambiente frenetico. 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 qualunque cosa ritengano 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 tempo impiegato per farti addestrare su ciò che l'azienda si aspetta. Quindi, 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 riesci a scrivere software, ma ancora di più se sei disposto a fare ciò che è necessario per assicurarti di poter imparare cosa 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) mentre tendono a fare le proprie cose e in base alla maturità dell'azienda e al gruppo per cui 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 il massimo della velocità prima che tu sia pienamente produttivo.

3
rjzii

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é? Poiché una volta aggiunto il supporto per i modelli, ho usato C++ quasi esclusivamente per Generico Programmazione.

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 affrontare sul posto di lavoro, che coinvolge strutture di dati e algoritmi [cioè: Hai 300 miliardi di punti dati costituiti da XYZ. Come archiviare e cercare in modo efficiente?].

Ciò ti consente praticamente di sapere come un candidato potrebbe intervenire e aiutare a risolvere i problemi reali che stai affrontando. Il peggio in assoluto è 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 per una posizione a livello di kernel]

Gli hedge fund sono bizzarri con la loro intenzione di torturare ... si aspettano 8 ore di risoluzione zaino problemi di tipo su una lavagna.

2
red-dirt