Quali standard ci si possono aspettare da ingegneri laureati / junior? [chiuso]

Gli overflow del buffer sono accettabili da uno sviluppatore laureato? Stiamo impostando la barra troppo in alto? Quali sono le capacità attese degli ingegneri laureati / junior?

Contesto:

Attualmente stiamo reclutando per una posizione di Junior Developer che lavora principalmente in C su Linux.

Come parte del processo, richiediamo ai candidati di completare un test del codice a loro piacimento in C.

Finora abbiamo rifiutato due candidati sulla base del fatto che il loro codice, sebbene leggibile e in un caso piuttosto idiomatico, soffriva di errori di overflow del buffer a causa di scritture di buffer illimitate.

[Modificare]:

• Chiediamo esplicitamente un codice di qualità della produzione controllato per errore.
• Forniamo un quadro di prova e costruzione per i candidati

[Aggiornare]:

Come risultato di questo thread e delle conversazioni che abbiamo avuto con altri sviluppatori in prima persona, stiamo cambiando il modo in cui eseguiamo i test del codice e chi miriamo al nostro reclutamento.

Abbiamo deciso che un candidato che non è in grado di correggere o comprendere un buffer overflow significa che non sarebbe adatto al lavoro che svolgiamo, in particolare prenderebbe più tutoraggio di quanto non ci si senta a proprio agio. Pertanto rifiuteremo ancora i candidati che non potranno eventualmente presentare un campione di codice valido.

Tuttavia, abbiamo messo in atto alcune misure per rendere il processo di assunzione più produttivo sia per noi che per i candidati.

In particolare:

• Rendiamo le nostre aspettative più esplicite, con una chiara spiegazione di cosa intendiamo per qualità della produzione e un avvertimento che il codice dovrebbe essere solido per quanto riguarda input ed errori.
• Colleghiamo ora i candidati alle risorse sulla programmazione difensiva e alla libreria standard C nella descrizione del test del codice.
• Abbiamo modificato il nostro target di riferimento da sviluppatori e laureati junior a persone con esperienza rilevante.
• Nel caso in cui il codice inviato fallisca in qualche modo ma venga altrimenti accettato, ora forniamo un caso di prova minimo che causa la condizione di errore e offre ai candidati la possibilità di correggere i propri errori (a meno che il codice non venga rifiutato per qualche altro motivo). Indicheremo anche linee / funzioni problematiche, se del caso.
• L'obiettivo dei test stessi è ora leggermente cambiato da un filtro front-end a una possibilità di creare un'immagine migliore del candidato, in particolare informerà la nostra discussione telefonica. Detto questo, siamo ancora disposti a rifiutare in base esclusivamente al codice.

[Aggiornamento 2015-07-09]: Andy Davis di Nujob ha scritto un articolo interessante e pertinente sull'uso di un test del codice dal punto di vista del candidato, e vale la pena guardare l'articolo. Lo trovi qui .

Non penso che tu abbia impostato la barra troppo in alto, penso che potresti aver bisogno di una barra diversa.

Penso che i test del codice siano utili per determinare la competenza di un candidato, ma non dovrebbero essere passati / falliti. È necessario utilizzare i risultati del test del codice per avviare una finestra di dialogo con il candidato.

Se vedi errori che hanno commesso (specialmente se sono sviluppatori junior), segnalali e chiedi loro cosa farebbero diversamente o se capiscono perché c'è un problema.

Penso che la qualifica junior sia ciò che fa la differenza qui. I giovani non dovrebbero essere testati per la competenza, dovrebbero essere testati per capacità di apprendimento, curiosità, passione, etica e sicuramente umiltà. Il presupposto con un junior dovrebbe essere che non sono competenti , è il tuo lavoro come senior renderli così.

Ovviamente dovrebbero essere in grado di scrivere codice base come fizzbuzz e avere una conoscenza generale dei concetti; se glielo facessi notare e loro non sapessero nemmeno cosa fosse un buffer overflow, allora direi che non c'è niente da fare, ma non mi aspetto che un junior scriva più di 5 righe di codice senza un bug.

Il giorno in cui ti fidi della competenza del tuo junior è il giorno in cui la tua dovrebbe essere messa in discussione, i junior dovrebbero essere trattati con un sacco di tutoraggio e una buona dose di "fiducia ma verifica". Ero una volta junior e per tutti quelli che erano lì in quel momento: mi dispiace. Ricordi le cose terribili che hai fatto da ragazzo? (Per favore, non dirmi che ero solo io; mi darai un complesso ..)

Vedo alcuni problemi qui.

Il primo presuppone che un laureato medio in informatica sappia, beh, tutto. Non lo fanno. Francamente, sono piacevolmente sorpreso quando vedo un laureato in informatica che sa come installare e configurare Visual Studio . Diamine, di recente ho lavorato con un ragazzo che affermava di avere più di cinque anni di esperienza nello stack Microsoft scrivendo codice .NET che non riusciva a capire cosa fosse TFS o come connettersi.

Il secondo è il tuo pool molto limitato. Abbiamo anche candidati che fanno un test di programmazione. Esistono cinque "programmi" separati che devono scrivere. Lo fanno a casa e spediscono il codice. I test sono estremamente semplici (nessun database, nessuna dipendenza esterna) e possono essere facilmente eseguiti utilizzando la versione Express di Visual Studio. I test stessi sono facilmente completati da un ragazzo anziano in circa 30 minuti. Si noti che generalmente lo facciamo solo per neolaureati con un'esperienza lavorativa verificabile fino a tre anni.

Ciò che abbiamo quantificato è che circa il 70% di coloro che hanno dato il test semplicemente non ci rispondono mai. Circa il 15% si trasforma in elementi che non vengono compilati, in genere a causa di errori di sintassi palesi (ad esempio, mancanti ;). Un altro 10% viene compilato ma non riesce a eseguire le azioni richieste.

Questo lascia un enorme 5%. A questo punto, non stiamo nemmeno prendendo in considerazione condizioni come l'inserimento di un carattere alfa come input quando è richiesto uno numerico. È puramente dato un set molto limitato di X come input l'applicazione fa l'output appropriato. Inoltre, questi numeri provengono da circa 500 candidati negli ultimi quattro anni: abbiamo mantenuto le statistiche perché volevamo sapere.

Se dovessimo guardare di più alla struttura del codice e alle tecniche di codifica difensiva come smaltire correttamente le risorse non gestite o utilizzare le try .. catchistruzioni, quasi nessuno passerebbe.

La domanda, ovviamente, è perché?

Perché un bambino con una laurea in questo campo presso un'università di quattro anni non può realizzare quali sono semplici compiti di programmazione? La risposta è che le università sono completamente fuori contatto con le esigenze aziendali e sono in ritardo di molti anni rispetto a ciò che consideriamo all'avanguardia. 10 anni fa gli standard di codifica erano tali che la sicurezza era qualcosa che facevi dopo il fatto; e i test unitari non erano ancora in voga. Considerando che oggi la sicurezza è meglio essere all'avanguardia nella tua mente con ogni funzionalità o miglioramento. Ricorda: la maggior parte dei professori non ha mai lavorato in questo campo o non ci lavora da molto tempo. Una volta che lo sai, allora inizi a capire perché sono così indietro. Peggio ancora, alcuni di questi professori trascorrono troppo tempo su una particolare tecnologia ( Java , PHP, qualunque cosa) e non riescono a discutere di gravi problemi di base come la struttura del codice o approcci accettabili (e PERCHÉ!).

Solo un esempio secondario. Un neolaureato mi stava raccontando della sua esperienza nella scrittura di un sistema operativo mobile per una delle sue lezioni, ma non riusciva a spiegare, nemmeno in termini di base, come funzionasse un web server. Semplicemente non lo sapeva. 15 o 20 anni fa era probabilmente il momento giusto per capire come realizzare un sistema operativo. Oggi ... non così tanto. Eppure questa era una classe richiesta quando una lezione sulla programmazione difensiva sarebbe stata molto più utile per loro E per il mondo esterno.

Quindi cosa facciamo?

Di quel 5%, intervisteremo un po 'di più per avere un'idea della loro personalità e vestibilità. Quindi scegliamo i "migliori" con la piena consapevolezza che passeremo circa sei mesi a "riprogrammarli" per sbarazzarci delle schifezze che i loro professori li hanno riempiti.

Penso che tu stia guardando il problema nel modo sbagliato. Quello che dovresti chiederti è questo: che cosa abbiamo bisogno da un candidato per poter svolgere il lavoro? È necessario valutare correttamente la posizione e ciò che comporta. Di seguito sono riportati alcuni suggerimenti su quando assumere uno sviluppatore junior e quando non farlo.

Quando assumere uno sviluppatore junior: - Se c'è un overflow di lavoro facile da fare, sarebbe una perdita di tempo per uno sviluppatore più senior. - Se sei disposto a guidare e formare questa persona nei prossimi anni. - Se stai cercando di far crescere l'azienda e desideri qualcuno che rimarrà a lungo. Uno sviluppatore junior che rimane solo per un anno sarebbe uno spreco di risorse aziendali, farebbe poco per produrre qualsiasi cosa e la maggior parte dei risultati sarebbe nella propria crescita personale. - Quando hai voglia di spendere soldi per la crescita di qualcuno. Da allora, la maggior parte dei benefici sarà ciò che imparano.

Quando non assumere uno sviluppatore junior. - Quando il lavoro è troppo complicato. In questo caso è appena fuori dalla loro portata. - Quando vuoi risparmiare. Uno sviluppatore senior dovrebbe completare le stesse attività in una frazione del tempo con risultati di migliore qualità e quindi dovrebbe essere sempre più economico. - Quando il lavoro è esternalizzabile o non è sufficiente per tenere occupato un dipendente. In tali casi sarebbe meglio scaricare parte del lavoro a un appaltatore privato.

Un ultimo punto importante. Non assumere uno sviluppatore junior perché "questo è tutto ciò che possiamo permetterci" o "questo è tutto ciò che siamo disposti a spendere" quando non sono adatti al lavoro. Alla fine tutto ciò che finirai per fare è buttare i soldi nel water. Inoltre, una volta acquisite queste abilità, richiederanno comunque un sacco di soldi.

Riguardo a me:

• Laurea in fisica con quasi nessuna formazione formale.
• Due anni di esperienza lavorativa. Quindi so di cosa tratta il processo di apprendimento.
• Avviare lo sviluppatore di software. Ho svolto un lavoro molto impegnativo e ho visto tutti i diversi livelli di abilità di vari individui. Molti di loro non riescono a gestire molto quello che faccio.

Come altri hanno già detto, le posizioni junior possono avere poca esperienza con C. Personalmente mi è stato insegnato solo brevemente sugli overflow del buffer in C e anche se potessi fare attenzione a loro, è probabile che ne introdurrei alcuni (soprattutto se mi viene assegnato un incarico stesso alla creazione di overflow del buffer). Probabilmente, molti sviluppatori junior si troveranno in una situazione simile in cui potrebbero essere a conoscenza di buffer overflow, ma non sono stati preparati a identificarli e gestirli in modo esteso.

Detto questo, ritengo che la risposta appropriata sia quella di far emergere il problema nella prossima possibile interazione e chiedere loro cosa sanno sui buffer overflow per testare le loro conoscenze generali. Dopodiché, digli che ne hai trovato uno nel loro presunto codice pronto per la produzione. Questo ti darebbe una buona finestra per giudicare come avrebbero reagito alla correzione e alle istruzioni.

Il pensiero comune che uno sviluppatore junior che conosce meno ma è disposto e in grado di apprendere e migliorare ha più valore di uno sviluppatore junior che ne sa di più ma che non può o non può migliorare?

Detto questo, in uno dei tuoi commenti hai menzionato che hai consegnato loro dei test che avrebbero indicato l'overflow del buffer nel loro codice se li avessero usati. Quindi forse la domanda più grande è: perché non hanno eseguito i test (o se lo hanno fatto, perché hanno trasformato in codice errato)?

Un overflow del buffer è assolutamente no-go. Potresti avere una domanda di codice corrispondente. In ciò che è tutto sbagliato (può andare storto) con questo pezzo di codice, il candidato dovrebbe essere in grado di individuare il problema. La domanda è: se il problema è irrilevante, dato che si esegue comunque un indizio.

Tuttavia, in un test di codice in forma libera artificiale sarei lieve su una violazione come sprintf. Troppo poco tempo (ipotizzato), mente iperattiva, un bisogno troppo grande di presentare qualcosa che funzioni.

Penso che tu stia facendo la domanda sbagliata. Non esiste una barra obiettiva per essere un programmatore professionista. Se ci fosse, ci sarebbe un esame di programmazione standard, ma non lo è. La tua barra individuale deve solo essere impostata in base a quanto esigente puoi permetterti di essere, quanto puoi permetterti di pagare, quanto errore può permettersi il tuo software di accettare e quanto tempo puoi permetterti di trascorrere l'insegnamento.

In questo caso, suppongo che un sovraccarico del buffer probabilmente significhi che questo codice, che il candidato ha presentato come un esempio di lavoro esemplare, si arresta in modo anomalo con un errore di segmentazione anziché fare ciò che è stato chiesto. Quindi, dovresti accettare un programmatore che scrive codice che si arresta in modo anomalo con un errore di segmentazione invece di fare ciò che hai richiesto? Chiedere:

• La tua organizzazione è in grado di attrarre chiunque sia in grado di scrivere codice funzionante?

• Il tuo processo di sviluppo è abbastanza solido da consentire a chi è quasi in grado di scrivere codice di poter scrivere codice funzionante con l'aiuto di peer review e supporto ai test?

• Sei in grado di insegnare ai programmatori come essere programmatori e sei disposto a spendere tale sforzo e aspettare forse qualche anno e sperare che il talento interiore del candidato giunga a compimento?