Quali standard ci si può aspettare dagli ingegneri laureati / junior? [chiuso]

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

Penso che i test di codice siano utili per determinare la competenza di un candidato, ma non dovrebbero essere pass / fail. Dovresti 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), indicali e chiedigli 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à. L'assunzione con un junior dovrebbe essere che non sono competenti , è il tuo lavoro come senior per renderli tali.

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

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

Qui vedo alcuni problemi.

Il primo presuppone che un laureato in informatica medio sappia, beh, qualsiasi cosa. 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 sosteneva di avere più di cinque anni di esperienza nello stack Microsoft scrivendo codice .NET che non riuscivo a capire cosa fosse TFS o come collegarmi.

Il secondo è il tuo pool molto limitato. Abbiamo anche candidati che fanno un test di programmazione. Ci sono 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. Gli stessi test sono facilmente completabili da un ragazzo anziano in circa 30 minuti. Nota che generalmente facciamo solo questi per neolaureati su un massimo di tre anni di esperienza lavorativa verificabile.

Ciò che abbiamo quantificato è che circa il 70% di coloro che hanno ricevuto il test semplicemente non ci restituiscono mai. Circa il 15% trasforma cose che non verranno compilate, in genere a causa di errori di sintassi evidente (ad esempio, manca ; ). Un altro 10% compila ma non riesce a eseguire le azioni richieste.

Questo lascia un enorme 5%. A questo punto, non stiamo nemmeno considerando condizioni come l'inserimento di un carattere alfa come input quando è richiesto un valore numerico. È puramente dato un insieme 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 tenuto statistiche perché volevamo sapere.

Se dovessimo esaminare più a fondo la struttura del codice e le tecniche di codifica difensive come disporre correttamente le risorse non gestite o l'utilizzo di dichiarazioni try .. catch , quasi nessuno passerebbe.

La domanda, ovviamente, è perché?

Perché un bambino con una laurea in questo campo di un'università quadriennale non può realizzare compiti di programmazione semplici? La risposta è che le università sono completamente fuori dal mondo degli affari e sono in ritardo di molti anni rispetto a ciò che consideriamo lo stato dell'arte. 10 anni fa gli standard di codifica erano tali che la sicurezza era qualcosa che hai fatto dopo il fatto; e le unit test non erano ancora in voga. Considerando che oggi la sicurezza è meglio essere in prima linea nella tua mente con ogni funzionalità o miglioramento. Basta ricordare: la maggior parte dei professori non ha mai realmente lavorato in questo campo o non ci ha lavorato per molto tempo. Una volta che lo sai, allora inizi a capire perché sono così indietro. Peggio ancora, alcuni di quei professori trascorrono troppo tempo su una particolare tecnologia ( Java , PHP , qualunque sia) e non riescono a discutere questioni fondamentali come la struttura del codice o approcci accettabili (e PERCHÉ!).

Solo un esempio secondario. Un neolaureato mi ha raccontato della sua esperienza nella scrittura di un sistema operativo mobile per una delle sue lezioni, ma non è riuscito a spiegare, anche in termini di base, come funzionava un server web. Semplicemente non lo sapeva. 15 o 20 anni fa era probabilmente il momento giusto per capire come creare 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 questi 5%, intervisteremo un po 'di più per avere un'idea della loro personalità e del loro adattamento. Poi selezioniamo i "migliori" con la piena consapevolezza che stiamo andando a spendere circa sei mesi per "riprogrammarli" per sbarazzarsi della merda che i loro professori hanno riempito con loro.

Penso che stai guardando il problema nel modo sbagliato. Quello che dovresti chiedere a te stesso è questo: cosa chiediamo a un candidato affinché siano in grado di fare il lavoro? Dovresti valutare correttamente la posizione e cosa comporta. Di seguito sono riportati alcuni suggerimenti su quando assumere uno sviluppatore junior e quando no.

Quando assumere uno sviluppatore junior: - Se c'è un eccesso di lavoro facile da fare, che sarebbe una perdita di tempo per uno sviluppatore più anziano. - Se sei disposto a guidare e guidare questa persona nei prossimi anni. - Se stai cercando di far crescere la compagnia e vuoi qualcuno che resterà a lungo. Uno sviluppatore giovane 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 loro crescita personale. - Quando hai voglia di spendere soldi per la crescita di qualcuno. Di nuovo, la maggior parte dei benefici sarà ciò che apprenderanno.

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

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

Informazioni su di me:

• Laurea in fisica con quasi nessuna formazione formale.
• Due anni di esperienza lavorativa. Quindi so di cosa tratta il processo di apprendimento.
• Avvia lo sviluppatore del software. Ho svolto un lavoro molto impegnativo e ho visto tutti i diversi livelli di abilità da vari individui. Molti di loro non sono in grado di gestire gran parte di ciò che faccio.

Come altri hanno menzionato, le posizioni junior possono avere poca esperienza con C. Personalmente mi è stato insegnato solo brevemente su buffer overflow in C e anche se potevo stare attento a loro, è probabile che ne introdurrei ancora alcune (specialmente se le assegnazione che si presta alla creazione di buffer overflow). Probabilmente, molti sviluppatori junior si troveranno in una situazione simile in cui potrebbero essere a conoscenza di overflow del buffer, ma non sono stati preparati a identificarli e gestirli in maniera estesa.

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

Non è comune pensare che uno sviluppatore minore che ne sa di meno ma è disposto e in grado di imparare e migliorare è più prezioso di uno sviluppatore junior che ne sa di più ma che non può o non vuole migliorare?

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

Un buffer overflow è un assoluto no-go. Potresti avere una domanda di codice corrispondente. In una cosa che è tutto sbagliato (può andare storto) con questo pezzo di codice il candidato dovrebbe essere in grado di individuare il problema. La domanda è, indipendentemente dal fatto che il problema sia irrilevante, dato che stai eseguendo comunque clint.

Tuttavia in un test di codice in forma libera artificiale sarei mite su una violazione come sprintf. Troppo poco tempo (presunto), mente iperattiva, troppo grande voglia di presentare qualcosa di funzionante.

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 è. Il tuo bar individuale deve essere impostato in base a quanto puoi permetterti di essere, quanto puoi permetterti di pagare, quanto errore il tuo software può permettersi di accettare e quanto tempo puoi permetterti di spendere l'insegnamento.

In questo caso, suppongo che un sovraccarico del buffer probabilmente significhi che questo codice, che il candidato ha presentato come esempio di lavoro esemplare, si blocca con un errore di segmentazione invece di fare ciò che hai chiesto. Quindi, dovresti accettare un programmatore che scrive codice che si blocca con un errore di segmentazione invece di fare ciò che hai chiesto? Chiedi:

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

• Il tuo processo di sviluppo è abbastanza solido da consentire a chiunque possa scrivere quasi codice di scrittura con il supporto di peer review e supporto di test?

• Sei in grado di insegnare ai programmatori come essere un programmatore, e sei disposto a spendere questo sforzo e aspettare forse qualche anno e spero che il talento interiore del candidato possa realizzarsi?