L'ingegneria eccessiva è un segnale di avvertimento? [chiuso]

Quindi presentiamo un semplice esercizio di codifica a nuovi candidati con requisiti ben definiti. Occasionalmente riceviamo soluzioni che non risolvono realmente il problema, ma sono troppo progettate per risolvere un problema percepito, spesso al di fuori dei limiti dell'esercizio.

Ora la mia domanda è: è un segnale di avvertimento?

EDIT: Gran parte della discussione si basa sul test che è imperfetto, il che è un punto giusto. Come ho descritto in un commento, la premessa di base del test è mostrare come è possibile leggere i dati dal file in modo ragionevole (e rimarrai stupito dalla varietà di approcci che vediamo) e come abbinare il elementi prima di calcolare la latenza tra gli aggiornamenti. Ora affinché ciò funzioni, è necessario formulare alcune ipotesi sui dati e cerchiamo queste ipotesi e dichiariamo anche esplicitamente che vogliamo vedere l'approccio adottato (incluso l'approccio OO ecc.) Tutto questo in due ore lasso di tempo.

IMHO, quando stavo intervistando, è stato l'esercizio più completo che mi sono imbattuto.

Lo scenario particolare di cui sto riflettendo è in cui un candidato, anziché leggere dal file, ha accettato l'input "rete" in un'applicazione multi-thread, che chiaramente non rientra nell'ambito.

Il problema è che il test è distorto. Stai chiedendo a qualcuno di dimostrare la sua capacità di scrivere software complessi a livello aziendale usando un semplice esercizio che richiede solo pochi minuti. Ci sono altri intervistatori di altre aziende che lamentano che i candidati non mostrano abbastanza abilità nella progettazione orientata agli oggetti con questi esercizi, quindi le persone tendono a compensare eccessivamente. Ciò non significa necessariamente che il tuo candidato non sia in grado di utilizzare un codice più semplice quando la situazione lo giustifica.

Se vuoi sapere se è il caso del tuo candidato, basta chiedere loro di rifarlo, dando loro alcune linee guida specifiche. Dì: "Vedo che hai messo in mostra le tue abilità progettuali orientate agli oggetti, ma sembra eccessivo per un problema così semplice. Puoi riscriverlo usando solo due piccole funzioni?"

Direi che questo è un chiaro segnale di avvertimento, ma non necessariamente squalificante per un candidato.

Esistono due problemi distinti che i candidati sembrano avere:

1. Manca il punto dell'esercizio - Questo è abbastanza allarmante. Tutta l'abilità di programmazione nel mondo non creerà un buon risultato se qualcuno non è in grado di esprimere il problema che sta risolvendo correttamente. Ho scoperto che gli ingegneri più produttivi sono quelli che sono in grado di identificare il vero problema da risolvere, anche se non è esattamente il problema posto. Avere la capacità di pensare criticamente alla domanda posta e forse riformularla in qualcosa che è più semplice da risolvere è un'abilità fondamentale. Manca il punto in cui il problema viene chiaramente indicato dovrebbe essere una grande bandiera rossa.
2. Ingegnerizzazione eccessiva della soluzione - Questo è un problema secondario ed è spesso il risultato del primo problema. Ci sono un paio di diverse patologie che possono avere questo risultato. Innanzitutto, non comprendere correttamente il problema o lanciarlo in modo troppo ampio può portare a una soluzione troppo complessa. Ciò è chiaramente correlato al primo punto sopra. Secondo, cercare di "mettersi in mostra" pensando a scenari futuri che potrebbero non essere realmente rilevanti. Questo può essere problematico perché indica che il candidato non ha compreso il valore della semplicità nelle soluzioni e nel rinviare la complessità fino a quando non è veramente necessario. Questo è qualcosa che può essere corretto con una buona guida, ma fa attenzione quando si porta qualcuno nell'organizzazione.

Suggerirei di dare seguito al candidato in merito alla sua risposta nel corso del processo. Piuttosto che limitarsi a guardare il loro risultato, prova ad accertare cosa li ha portati al risultato, e dato una guida, come avrebbero risposto e cambiare la loro risposta. Questo sarà probabilmente più rivelatore delle loro capacità che della loro diretta risposta al problema. I "perché" del loro approccio possono darti la sensazione se non lo stanno capendo, o se la loro comprensione era leggermente offuscata nel modo in cui hanno scelto di rispondere. Questo tipo di follow-up rivelerà anche di più sul loro approccio generale alla risoluzione dei problemi.

Inoltre, riesamina il problema stesso e vedi se forse non è chiaro e forse induce le persone a prendere la strada sbagliata mentre formulano le loro risposte.

No, non durante un colloquio di lavoro. Troppi intervistatori fanno cose come intenzionalmente sottostimano i requisiti e si aspettano che l'intervistato faccia ulteriori domande o guardi l'attenzione a questioni del mondo reale non esplicitamente menzionate.

Ecco alcune cose, fuori dalla mia testa, che probabilmente le tue esigenze non hanno menzionato:

• Standard di codifica

• Commenti

• La gestione delle eccezioni

• Nomi descrittivi di variabili, classi, metodi

• A seguito dell'uso idiomatico della lingua

• Corretto design orientato agli oggetti

• Attenzione a possibili problemi di concorrenza

• Scrivere casi di test per il codice

Hai prestato attenzione a una di queste cose senza dichiararla esplicitamente? Come farebbe il candidato a sapere quali ti interessano e quali no?

Un'intervista è un ambiente altamente artificiale. L'intervistatore sta spesso cercando di "ingannare" un po 'il candidato in modo da rendere difficile per l'intervistato dirgli quello che vuole sentire, e l'intervistato sta cercando di indovinare cosa l'intervistatore realmente vuole .

In generale, fare un errore su questa ipotesi è piuttosto diverso che fare un errore nelle decisioni di progettazione del mondo reale. Se vuoi sapere se qualcuno progetta troppo le cose, probabilmente devi parlare di design piuttosto che guardare un esercizio di codifica molto artificiale.

IMHO la risposta è chiaramente sì , è un segnale di avvertimento, se

• l'esercizio di programmazione aveva un compito chiaro
• ha requisiti ben definiti (e anche ben scritti),
• i candidati hanno avuto la possibilità di porre domande per assicurarsi di risolvere il problema corretto.
• vuoi persone intelligenti e che fanno le cose nella tua squadra, non gli astronauti dell'architettura .

Un segnale di avvertimento non così grande come non risolvere il problema in questione . Il fatto che abbia fallito il test e non abbia fornito la soluzione corretta è un segnale di avvertimento. Non è necessariamente uno scenario vietato perché dipende da come e perché non ha fornito la soluzione corretta.

Molte volte la domanda è una schifezza completa e semplicemente senza risposta. Non far finta che gli intervistatori non commettano mai errori. È ancora un fallimento da parte sua scoprire perché la domanda è una schifezza. Se stai assumendo un ingegnere che dovrebbe aiutare a soddisfare i requisiti, questo è un problema. Se stai assumendo un programmatore, non ti aspetti che lo faccia.

Presumendo che l'esercizio di codifica non sia orribilmente incasinato, sembra che il modo in cui ha fallito sia stato interpretare erroneamente il problema ed entrare nelle erbacce cercando di risolvere un problema che non c'era. Sì, è un segnale di avvertimento.

Può essere.

Non risolvere il problema è ovviamente un chiaro segnale di avvertimento che qualcosa non va. Che cosa è andato storto? O hanno frainteso il problema o hanno fatto una cattiva soluzione. Una cattiva soluzione per qualcosa di semplice è un chiaro segno che il candidato è povero.

Se hanno frainteso il problema, dai un'occhiata alle tue esigenze. Anche le cose che ti sembrano cristalline potrebbero non essere chiare per gli altri che non hanno familiarità con un dominio o da un background diverso (locale, età, educazione). Se il candidato fosse lì nella stanza con te, o offrisse l'opportunità di porre domande e continuasse a fallire, lo considererei un fallimento da parte loro. Se i requisiti venissero gettati oltre il muro, probabilmente darei loro il beneficio del dubbio (e penso a risolvere il processo di intervista).

Se la soluzione era corretta, diventa meno chiara. Personalmente, penso che un certo numero di persone prenda YAGNI troppo lontano. Se riesci a risolvere un problema specifico e creare una soluzione generale senza aumentare la complessità o danneggiare la manutenibilità, perché non creare la soluzione generale? (Pensa di invertire una stringa anziché invertire qualsiasi collezione) Quel tipo di "sovraingegneria" è chiaramente buono secondo me.

Tutto il resto è quella via di mezzo grigia. La soluzione affronta probabili assi di cambiamento? La soluzione aggiunge complessità o danneggia la manutenibilità? Aggiungendo un po 'di complessità per risolvere i problemi futuri che sono quasi garantiti per una vittoria. Danneggiare notevolmente la manutenibilità per tenere conto di qualcosa che è totalmente improbabile non lo è.

Essere un buon ingegnere informatico significa trovare qui il giusto equilibrio. Essere un buon intervistatore significa trovare il giusto giudizio / inferenza su come e perché il candidato ha scelto quell'equilibrio, spesso usando altre parti dell'intervista per valutare.

Forse, ma considera quanto segue:

• Le interviste sono difficili: le persone sono sotto stress. Questo dovrebbe essere preso in seria considerazione per qualsiasi problema che dai a qualcuno

• Lunghezza dei requisiti: quanto sono lunghi e diretti i requisiti? Li hai resi più prolissi per assicurarti di aver incluso tutto. Di conseguenza, potrebbero essere chiari per te, ma i requisiti potrebbero essere troppo ingegnerizzati! Ho fatto un colloquio di lavoro una volta per un'ora con circa 3 pagine di testo per un problema relativamente semplice. A volte tutto quel testo può essere difficile da leggere e interpretare in un'intervista e può anche essere male interpretato.

• A volte meno è di più: preferirei avere alcuni punti elenco, frasi e / o esempi che mostrano i requisiti principali e quindi una discussione con qualcuno a cui porre domande e magari raggiungere la strada, se necessario. Immagino che cosa sto cercando di dire è che dovresti prima controllare che i requisiti del tuo test non siano eccessivamente complicati per un semplice problema.

• Abilità comunicativa: dovresti testare la capacità dei candidati di comunicare e porre prima domande intelligenti sul problema e una volta che sai che hanno dimostrato di aver compreso il problema, puoi metterli in pratica sulla loro implementazione.

• Bottom Line: Se non hai verificato che il problema sia compreso, non sai davvero cosa fare del sovraingegneria. Come altri hanno già detto, potrebbe essere una cosa buona o cattiva, ma se non hai verificato la comprensione o comunicato con il candidato il problema in anticipo, è più difficile conoscere la loro comprensione generale del problema e cosa farne.

Molto di questo potrebbe essere attribuito a come pronunci la domanda e come hai messo l'intera intervista in prospettiva.

È come "Vediamo quanto sei creativo. Che cos'è 2 + 2?" Quattro? Tutto quello che potresti trovare è la risposta più semplice, ovvia e accurata? Gli sviluppatori giovani / entry level che sono così desiderosi di impressionare durante un'intervista prenderanno il "Vogliamo testare le tue abilità di programmazione o vedere quanto sei bravo a programmare." per dire "fai qualcosa di molto sofisticato". A tutti noi piace pensare che semplice sia meglio, tranne quando rende le cose più difficili.

Ci sono modi per vedere se qualcuno è incline a essere sempre troppo ingegneristico. Fornisci un esempio di codice di qualcosa che era troppo complesso e chiedi una soluzione più semplice. Quando qualcuno fornisce una soluzione che non pensi possa funzionare, questa è una grande opportunità per vedere come reagiscono alle critiche. Personalmente, vorrei vedere qualcuno essere aperto a nuove idee e ricongiungere una soluzione migliore di qualcuno che farà gli stessi errori più e più volte.

E in realtà, non abbiamo sempre l'opportunità di cambiare il nostro codice quando non funziona? È possibile sotto il design o sopra il design inizialmente. Una volta riconosciuta la soluzione semplice, non dovrebbe essere più facile da implementare?

Dipende, ma generalmente no.

Il design in generale è un'abilità appresa con esperienza. La descrizione di Aaronaught di quella progressione legata da Marjan è generalmente buona.

La comunicazione in qualsiasi forma dipende anche molto dal contesto. Ciò che può sembrare perfettamente chiaro significare una cosa in un contesto, può significare altrettanto chiaramente qualcos'altro in un contesto diverso. Sapere quali domande porre è anche qualcosa che viene fornito con l'esperienza.

Il loro processo di pensiero e il modo in cui ragionano sulle loro decisioni è molto più importante della loro soluzione. Senza rivedere la loro soluzione e le loro decisioni con loro non è possibile valutare completamente il contesto in cui è stata sviluppata.

Data la progressione sopra, un candidato con la soluzione troppo ingegnerizzata potrebbe benissimo essere più avanti del candidato con la soluzione semplice.

Inoltre: quale posizione di livello stai assumendo? L'ingegnerizzazione eccessiva di un candidato entry level o di livello intermedio è meno problematica dell'ingegnerizzazione eccessiva di un candidato di livello senior.

Se il programmatore non ha risolto il problema, tutto il codice aggiuntivo è il tentativo del programmatore di offuscare la non risposta. È la stessa tecnica utilizzata in un test di saggio da uno studente che non sa molto sull'argomento. Lui o lei si dilungheranno su una questione convincente, ma non correlata, nella speranza che la sua ignoranza sia mascherata dal conteggio delle parole.

Se il programmatore ha risolto il problema ma ha aggiunto molto più codice, prendere in considerazione il background del programmatore, poiché alcune aree di programmazione richiedono tolleranze maggiori di altre.

Ad esempio, il codice che esegue l'autopilota in un aereo passeggeri commerciale ha tolleranze di guasto molto inferiori rispetto a un gioco Android gratuito. Uno sviluppatore abituato a programmare dispositivi integrati che sono difficili da raggiungere e quasi impossibili da aggiornare tenderà a programmare più what-if di uno sviluppatore che può inviare 15 aggiornamenti in un giorno.