Dovrei aspettarmi che i neolaureati abbiano familiarità con i concetti di base della programmazione? [chiuso]

Sembra che ci sia un'enorme discrepanza tra ciò che mi aspetto qualcuno che ha studiato programmazione per alcuni anni all'università, e ciò che si sa realmente.

Non mi sento come se stessi facendo domande troppo complicate nelle interviste. Alcune delle mie solite domande sono:

• Qual è la differenza tra un tipo di riferimento e un tipo di valore?

  Se sembra che l'intervistato non capisca davvero la propria risposta, o se non conosce la terminologia che sto usando, ottengo maggiori dettagli chiedendogli di spiegarmi cosa succede quando scrivo int i = 0; in un metodo, che dire dell'oggetto o = 0, dell'oggetto o = new MyClass (), ecc ...

  Fondamentalmente, faccio tutto il possibile per indurre l'intervistato a parlarmi del callstack, dell'heap ecc. E cerco di rimanere nei concetti di linguaggio agnostico. Se l'intervistato mi dice che ha fatto molto C, o C ++, o c #, mi tuffo più a fondo nel linguaggio specifico, e possibilmente nei dettagli di implementazione.

  Se necessario, chiedo all'intervistato che cos'è un callstack o dove vengono archiviati gli argomenti passati a una funzione nella lingua imperativa di sua scelta.

  la maggior parte degli intervistati non ha idea di cosa sia un callstack, per non parlare delle considerazioni sulla boxe, ecc.

• Qual è la differenza tra una classe astratta e un'interfaccia. In quali casi dovresti usare l'uno sull'altro?

  Di solito, chiedo anche loro di immaginare un progetto di una piccola biblioteca con un caso d'uso che mira a utilizzare alcune eredità e alcune fabbriche astratte

  La maggior parte degli intervistati non ha idea di quale possa essere il vero scopo dell'ereditarietà. Di solito conoscono alcune parole chiave (virtuale, override, ecc.), Ma non sanno davvero quando usarle, figuriamoci spiegando cos'è una tabella virtuale.

Anche se previo screening dei CV, anche per persone con 5 anni di esperienza in progetti di vita reale che coinvolgono architetture complesse, direi che meno del 25% di tutti i miei intervistati può rispondere correttamente a queste due domande. E quando dico correttamente, non intendo "approfondito" ... solo per avere un'idea approssimativa di quale sia il concetto.

Per quanto riguarda i ragazzi, sto bene con l'assunzione di qualcuno che non sa organizzare molto bene il suo tempo, o qualcuno che non è abituato ai processi di costruzione industriale, ad esempio, ma ho la sensazione che se non si ha sentito la parola " callstack "dopo alcuni anni di studi in Informatica, è o stupido o non motivato, o ha scelto la sua università molto saggiamente.

Pensi che io sia troppo estremista qui? È comune imparare questi concetti di base dopo aver completato l'università? Conosci persone che non li conoscevano e sono diventate dei bravi ingegneri del software dopo pochi anni? E pensi che la mia azienda potrebbe avere un problema nell'attirare persone di talento o riscontri lo stesso tipo di problemi nel tuo processo di assunzione?

Modificare. per quanto riguarda il "tipo immediato", era solo una traduzione letterale dal francese all'inglese, come di solito facciamo le nostre interviste in francese. L'ho risolto nella mia domanda. Tuttavia, penso che tutti voi capiate perfettamente cosa volevo dire, che tipo di argomento ha ragione, no?

La terminologia è una caduta comune in una situazione di intervista.

Fai una domanda all'intervistato usando la terminologia che significa qualcosa per te ma l'intervistato può conoscerla con un termine diverso o può semplicemente conoscere la teoria generica senza applicazione a linguaggi o ambienti specifici. Ne derivano incomprensioni. Nessuna delle parti è felice.

In realtà risulta che l'intervistato comprende perfettamente che alcuni valori potrebbero essere archiviati direttamente in un registro e altri fanno riferimento a un pezzo di memoria altrove, ma poiché ponete la domanda in un dominio specifico, il punto di ciò che state chiedendo e ciò di cui vuoi che l'intervistato ti parli, in realtà non si fa strada.

Forse hai un sacco di situazioni in cui l'intervistato fa improvvisamente clic e dice "Oh - è di questo che stai parlando" - e poi spiega in modo abbastanza adeguato.

È un equilibrio difficile perché i programmatori appena usciti dall'università non avranno l'esperienza diversificata che offre loro lo sviluppo del mondo reale in un ambiente di squadra. Nel frattempo gli sviluppatori esperti spesso non ricordano (o si interessano) di tutto ciò che hanno imparato all'università perché è semplicemente irrilevante per il loro uso quotidiano.

Questi due tipi di persone (sì - che è l'intervistato e l'intervistatore) necessità di imparare a comunicare con l'altro prima che si può imparare circa l'un l'altro. Spetta alla persona con maggiore esperienza (l'intervistatore) per garantire che ciò accada.

Per non parlare del fatto che alcune persone ottengono un completo fallimento della memoria nelle interviste. Me stesso incluso. Ricordo che mi era stato chiesto di scrivere un programma in C e non potevo per la vita di me ricordare il simbolo usato per accedere a un membro da un puntatore (->) e ho dovuto chiedere a qualcuno. Non era nemmeno per il mio primo lavoro. Il ragazzo mi ha tormentato per gli ultimi 15 anni :-)

Molto più utile secondo me è la capacità di comunicare, essere in grado di risolvere i problemi in modo efficiente e completo; raccogliere rapidamente le cose; mostrare un atteggiamento acuto positivo; interagire bene con altre persone e altri valori fondamentali.

Non rinunciare agli intervistati perché non sanno cosa sia un tipo immediato. Vai avanti.

Stai chiedendo una conoscenza specifica della lingua e i termini che utilizzi non sono usati lo stesso al 100% in tutte le lingue. Io - per uno - non ho idea di cosa sia un "tipo immediato".

Inoltre, considera che le cose insegnate in un'università non sono come estrarre il codice standard in X, ma aver appreso molti concetti di base e visto vari paradigmi di programmazione. In altre parole, è molto simile a una patente di guida - anche se conosci la teoria di base, hai ancora bisogno di molta pratica effettiva.

"Sento e dimentico. Vedo e ricordo. Faccio e capisco." (E, secondo me, la comprensione porta a una migliore conservazione della memoria.)

In parole povere, un neolaureato non ha molta esperienza, quindi, come ha notato qualcun altro, non avrà molto più del minimo indispensabile di conoscenza, indipendentemente dalla lingua "scelta".

Sono andato in un college che è stato progettato specificamente per semplificare l'apprendimento del maggiore prescelto (quindi, per esempio, non avresti letteratura storica se fossi un maggiore CS; il più vicino che potresti ottenere alla letteratura storica è fantascienza), e appena uscito dal college, non sarei stato in grado di dirti quale interfaccia era tanto meno la sua differenza rispetto a una classe astratta, anche se abbiamo imparato l'astrazione (e le interfacce abbondano in .Net, la tecnologia che ho imparato). Potremmo aver toccato le interfacce, ma si è perso in tutte le altre cose che dovevamo sapere per superare la lezione. Non è stato fino al mio primo lavoro fuori dal college che ho imparato a conoscere le interfacce, in particolare in modo significativo.

Hai citato di fare interviste in francese, il che rende evidente che siamo in diversi paesi, quindi il tuo chilometraggio può variare, ma qui negli Stati Uniti, i college sono notoriamente indietro rispetto ai tempi della tecnologia. Pertanto, a meno che tu non abbia a che fare con le lingue mature (C / C ++, COBOL, ecc.), È anche molto probabile che ciò che stai usando anche da anni potrebbe non essere disponibile nella versione su cui gli studenti hanno imparato. Ad esempio .Net 3.0 ha introdotto Entity Framework, WPF, WCF e una miriade di altre cose interessanti, ma anche la mia scuola era ancora bloccata su .Net 1.1 e 2.0 (il che significava rimanere bloccati con ADO.NET e non conoscere nemmeno Object Mappatura relazionale). Una scuola che utilizza PHP può essere bloccata su PHP 4 (non OOP).

Tieni presente, inoltre, che uno studente deve prendere un sacco di informazioni che vengono spesso utilizzate solo per un breve periodo di tempo. I concetti "avanzati", come l'astrazione, vengono spesso insegnati verso la fine della lezione, in cui lo studente può avere solo una settimana circa per giocarci, mentre si contende con le altre classi che deve seguire, e possibilmente, su all'inizio di un lavoro part-time o full-time. Combina tutti quelli insieme ed è una meraviglia che la persona possa ricordare qualsiasi cosa , tanto meno mantenere tutto dritto.

Negli Stati Uniti, almeno, si presume che un laureato di recente non sappia nulla al di là delle basi generiche (la differenza tra il passaggio per valore e il passaggio per riferimento, forse), perché si comprende che la teoria generica e la risoluzione dei problemi sono la parte principale scuola, non imparando i dettagli di una determinata lingua.

Ti consiglio di usare le domande che hai avuto più come indicatore di ciò che devi insegnare / re-insegnare loro (ricorda, è del tutto possibile che non abbiano imparato il termine che stai cercando di usare, anche se pensi che sia onnipresente), al contrario del fatto che l'intervistato sia "senza valore". Combina ciò con la valutazione di quanto siano disposti a imparare e quali sono le loro capacità generali di risoluzione dei problemi (seriamente, dai loro un indovinello per risolvere e vedi come si comportano così), e puoi benissimo avere una futura rockstar che tu potrebbe essere passato perché non sapevano cosa intendevi per "callstack".

Hai parecchie viste ristrette e le assumi implicitamente.

• Sembra che ci sia un'enorme discrepanza tra ciò che mi aspetto qualcuno che ha studiato programmazione per alcuni anni all'università, e ciò che si sa realmente.

  Per quanto ne sappia, non esiste un'università, dove le persone studiano programmazione per alcuni anni. Le università offrono corsi di informatica, di cui la programmazione è un aspetto.

• Qual è la differenza tra un tipo di riferimento e un tipo di valore?

  Regola empirica: se Lisp può fare a meno della distinzione, è solo disordine;)

• Fondamentalmente, faccio tutto il possibile per indurre l'intervistato a parlarmi del callstack, dell'heap ecc. E cerco di rimanere nei concetti di linguaggio agnostico.

  Parlare di concetti indipendenti dalla lingua è una buona idea. Né l'heap né lo stack sono però indipendenti dalla lingua.

• Se l'intervistato mi dice che ha fatto molto C, o C ++, o C #, mi tuffo più a fondo nel linguaggio specifico, e possibilmente nei dettagli di implementazione.

  Tutte queste lingue hanno specifiche. L'implementazione non è definita dalla lingua. C e C ++ possono essere compilati in modo incrociato usando LLVM per essere eseguiti su Flash Player o su qualsiasi runtime JavaScript. Ciò rende nulle le vostre ipotesi sull'allocazione di heap e stack.
  Con C # è praticamente lo stesso. C # è JIT prima dell'esecuzione con molta ottimizzazione, che può essere fatta. Le variabili locali, che vengono catturate dalle chiusure alla fine, finiranno nello heap, anziché nello stack, mentre l'analisi di escape consente di memorizzare gli oggetti scope-local (che normalmente dovrebbero andare nell'heap) per essere memorizzati nello stack. Una corretta allocazione dei registri ridurrà notevolmente la necessità di allocazione dello stack.

• Se necessario, chiedo all'intervistato che cos'è un callstack o dove vengono archiviati gli argomenti passati a una funzione nella lingua imperativa di sua scelta.

  Cosa vorresti chiedere a qualcuno che ha una vasta esperienza di programmazione con Haskell? : P

• La maggior parte degli intervistati non ha idea di cosa sia un callstack, per non parlare delle considerazioni sulla boxe, ecc.

  L'idea alla base dell'autoboxing è che le primitive possono anche essere trattate come oggetti (o almeno valori il cui tipo può essere scoperto in fase di esecuzione). Per quanto riguarda quell'astrazione, ci sono tre tipi di lingue:

  1. quelli dove non esiste. Suppongo che Objective-C sia l'esempio cannonico.
  2. quelli che detiene veramente
  3. quelli dove esiste ma non regge. Immagino che Java sia il miglior esempio (suppongo che sia stato risolto ormai).

  Non vedo perché le persone non dovrebbero usare linguaggi di categoria 1 (in realtà è una buona idea). Non vedo perché le persone che usano le lingue della categoria 2 dovrebbero davvero preoccuparsi. E penso che tutti coloro che usano un linguaggio di categoria 3, ovvero uno in cui una caratteristica semantica di base è semplicemente rotta, stia usando un linguaggio sbagliato.

• Qual è la differenza tra una classe astratta e un'interfaccia. In quali casi dovresti usare l'uno sull'altro?

  Questo è altamente soggettivo e dipende davvero dalla lingua. C ++ non ha interfacce. Objective-C non ha classi astratte. Direi che qualsiasi linguaggio che abbia entrambi abbia un serio bisogno di riprogettazione. Molti linguaggi moderni usano tratti, mixin, categorie, ruoli e costrutti simili per fornire soluzioni molto più pulite per il riutilizzo del codice rispetto all'ereditarietà di implementazioni parziali. Le lingue basate sul prototipo non hanno comunque classi del tutto.

  In definitiva questo è un argomento difficile e contestato. Un'intervista non è certo il posto giusto per risolvere questa domanda e non vorrei davvero inchiodare nessuno che si candida a una posizione junior per non darmi una buona risposta.

• La maggior parte degli intervistati non ha idea di quale possa essere il vero scopo dell'ereditarietà. Di solito conoscono alcune parole chiave (virtuale, override, ecc.), Ma non sanno davvero quando usarle, figuriamoci spiegando cos'è una tabella virtuale.

  Esistono numerosi linguaggi orientati agli oggetti, che non usano l'ereditarietà o le classiche vtables.

Il mio consiglio:

• Fai molta attenzione a supporre che tutto ciò che sai sulla programmazione sia davvero un concetto di programmazione di base . Puoi presumere che ogni buon programmatore abbia la curiosità di scoprire le risposte a tale domanda. Tuttavia non puoi presumere che chiunque li conosca sia buono. Tendo a credere che quelli che danno troppa importanza a tali dettagli probabilmente non vedano la foresta per gli alberi.
• Preoccupati meno dei dettagli di implementazione. I linguaggi di programmazione hanno lo scopo di creare astrazioni. Devi pensare in termini di quelle astrazioni e solo in termini di esse. Il buon codice non è scritto rispetto ai dettagli di implementazione di una lingua. È stato scritto per integrare al meglio la semantica della soluzione nelle funzionalità del linguaggio. Se riesci a farlo, il tuo codice non solo diventerà robusto, ma ben leggibile per chiunque abbia familiarità con la lingua e più facile da ottimizzare per un compilatore.
• Conoscere le risposte che ti aspetti non è così importante. Capirli è. Se qualcuno li conosceva, perché li leggeva in un libro di testo o glielo diceva il suo professore, allora ha poco valore. In realtà puoi spiegarti tutte queste cose in poche ore.
  Ciò che è importante è la comprensione di come questi fatti semplici e isolati possano essere applicati all'ingegnerizzazione di soluzioni flessibili e sostenibili a problemi complessi.

Per arrivare alla vera domanda:

E pensi che la mia azienda potrebbe avere un problema nell'attirare persone di talento o riscontri lo stesso tipo di problemi nel tuo processo di assunzione?

Tutte le aziende hanno problemi ad attirare persone abili, tranne forse i grandi giocatori. Questo perché ce ne sono pochi. E a causa del presupposto, quell'università rende le persone abili. Non Li rende ben informati (supponendo che sia lo studente che l'università resistano alla loro parte dell'affare). L'esperienza è ciò che rende le persone abili.

Ci sono alcuni che hanno raccolto esperienza prima di entrare all'università e che continuano a farlo durante gli studi. Perché a loro piace programmare e perché quando prendono una nuova idea durante un corso, cercheranno di vedere come possono usarlo, la prima cosa che tornano a casa. Questo è il tipo di persone che ti piacerebbe assumere. Ma ce ne sono alcuni.
È la passione per la programmazione e l'auto-miglioramento e la sua ricerca che rendono buoni i programmatori. In tempo.

Penso che ciò che devi capire è che purtroppo la maggior parte delle persone entrerà e lascerà l'università senza una sufficiente esperienza di programmazione.
Allo stesso tempo, il nostro settore non ha bisogno di programmatori esperti. Pertanto, credo che la missione del nostro settore sia effettivamente quella di intervenire. E intervistando i candidati per le posizioni junior, quello che stai realisticamente cercando sono le persone disposte a imparare e migliorare. E dovresti scegliere con cura, perché dovrai investire molta energia e non vuoi che vada sprecato.

Pensalo come assumere un nuovo sangue per diventare un pilota per il tuo team di corse: un buon pilota ha una comprensione sufficiente dei meccanici per sfruttare al meglio la sua auto, ma questa conoscenza da sola non è di alcuna utilità (non è nemmeno molto di una testa inizio). Quello che stai cercando è qualcuno disposto a lavorare sodo per il proprio miglioramento e bene con la tua squadra.

Indipendentemente dal termine "tipo immediato" di cui non ho idea (tipo di valore? OK, non ero sicuro, grazie per l'aggiornamento), penso che tu abbia ragione sulle tue domande e totalmente non estremista. Queste sono domande a cui rispondere se si esce da scuola. Tuttavia, non licenzierò immediatamente i candidati, ce ne sono ancora alcuni che potrebbero avere un potenziale perché vogliono imparare.

Per continuare con l'analogia della patente di guida: ad alcune persone non importa cosa succede quando inseriscono la chiave (o premono il pulsante "start"). Lo fanno e guidano. Questo non significa nemmeno che siano inutili, solo che ci vorrà del tempo per raggiungere la celebrità ;-)

Solo un'osservazione personale sul grado / diploma: attualmente sto lavorando con persone con biochimica e background industriale che hanno alcuni anni di esperienza nel campo IT e anche alcuni ragazzi "esperti" con background CS, e indovina chi sono i più informati su come funziona il motore del veicolo? Sì, non sono i ragazzi che hanno studiato CS! Quindi sto solo sperimentando il fatto che il diploma non ha sempre importanza!

In genere non faccio domande specifiche sulla terminologia o le definizioni durante le interviste. Come hanno notato altre risposte, le persone hanno termini diversi per concetti diversi e sebbene possano comprendere concettualmente l'argomento, potrebbero non essere in grado di comunicartelo.

Con Juniors mi concentro intensamente sui loro tirocini o progetti scolastici. Faccio domande su domande su di loro, lascio articolare le risposte e poi inizio a immergermi più a fondo nella loro effettiva realizzazione nel progetto, cosa hanno imparato, cosa hanno provato.

Generalmente se la persona era un peso morto nel progetto, in genere non può darmi risposte soddisfacenti, quindi di solito è abbastanza facile da dire. Fai solo attenzione a non confondere nervoso e introverso con disinteressato e non coinvolto.

Essere in grado di determinare il buon candidato che è timido e introverso è un po 'difficile, ma poi la cultura in cui lavoro non sarebbe buona per uno sviluppatore introverso e timido, quindi se non riescono a tenere una conversazione dettagliata produttiva con me, allora non sono adatti.

 or chose his university very unwisely.

È molto ingiusto. Quando sei uno studente, tutto ciò che puoi fare è scegliere l'università con il punteggio più alto in cui ti faranno entrare i tuoi voti, o forse quella che pubblicizza, permettendoti di giocare con i cani robot che giocano a calcio. Niente di più. Puoi valutare un corso universitario solo dopo averlo fatto, poi andare via e lavorare nell'industria per alcuni anni e costruire alcuni progetti non banali.

Anche se hai acceso un'enorme insegna al neon in ogni corso dicendo "NON INSEGNIAMO LO STACK DI CHIAMATA", allora cosa ti aspetti dagli studenti? Trascorrere mesi a ricercarlo in modo che possano effettivamente capire cosa significhi e quanto avrebbero bisogno di uno che lo insegni? Per ogni corso con ogni combinazione di segni?

Le persone non riescono a scegliere la loro educazione, realisticamente.

Quando intervista neolaureati mi attengo agli argomenti elencati nel loro CV. Se hanno usato Java, chiederò loro di Java. Se hanno usato Blub, allora trascorro mezz'ora a leggere su Blub, e glielo chiedo. Ma chiedo sempre di usare le parole chiave della lingua. Se è Java, allora chiederò "estende" e "implementa" ma non "sottoclasse" ed "eredita". Mi aspetto che i neolaureati possano parlare del codice che hanno scritto, essere in grado di risolvere un semplice problema di programmazione e avere una comprensione delle strutture di dati di base (tabelle hash e alberi).

In qualità di direttore che ha progettato il processo di intervista, posso fornirti informazioni su ciò che la nostra azienda si aspetta da nuovi laureati: mi aspetto che le persone possano leggere la documentazione e applicare le conoscenze. Pertanto, abbiamo alcuni compiti molto precisi che chiediamo loro di svolgere. Si tratta di semplici compiti di programmazione, non molto più difficili del normale esercizio di classe universitaria (gli sviluppatori "bravi" esperti possono eliminarlo in circa 15 minuti). Al candidato viene fornita una workstation con accesso a Internet, un compilatore (nel nostro caso Visual Studio) e file di aiuto.

Se non riescono a scrivere codice in queste condizioni, non prendono in considerazione l'assunzione. Semplice come quella. L'intera scusa "beh, non conosco la lingua" non ha mai avuto una vera scusa con me, perché tutti i candidati che intervistano qui sanno che ci sarà un test, conoscono le lingue e gli strumenti che utilizziamo in anticipo. Puoi scaricare Visual Studio Express a casa e fare alcune nozioni di base prima di entrare e superare il test entry level, quelli che non si preoccupano ... beh, questo è quello che chiamo bandiera rossa.