Sovrascrive un segnale di avvertimento? [chiuso]

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

Se vuoi sapere se questo è il caso del tuo candidato, basta chiedere loro di rifarlo, dando loro alcune linee guida specifiche. Dì, "Posso vedere che stavi mettendo in mostra le tue capacità di progettazione orientata 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 squalifica per un candidato.

Ci sono due problemi separati che i candidati sembrano avere:

1. Manca il punto dell'esercizio - Questo è abbastanza allarmante. Tutte le abilità di programmazione nel mondo non creeranno un buon risultato se qualcuno non è in grado di risolvere il problema che stanno 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 in modo critico alla domanda che viene posta e magari riformularla in qualcosa di più semplice da risolvere è un'abilità critica. Manca il punto in cui il problema viene chiaramente indicato dovrebbe essere una grande bandiera rossa.
2. Overingegnerizzazione della soluzione - Questo è un problema secondario ed è spesso il risultato del primo problema. Esiste un paio di diverse patologie che possono avere questo risultato. In primo luogo, non comprendere correttamente il problema o eseguirlo in modo troppo ampio può portare a una soluzione troppo complessa. Questo è chiaramente correlato al primo punto sopra. In secondo luogo, cercando di "sfoggiare" pensando attraverso scenari futuri che potrebbero non essere rilevanti. Questo può essere problematico perché indica che il candidato non ha compreso il valore della semplicità nelle soluzioni e rinvia la complessità finché non è veramente necessario. Questo è qualcosa che può essere corretto con una buona guida, ma fa attenzione quando si porta qualcuno all'interno dell'organizzazione.

Suggerirei di dare seguito al candidato sulla loro risposta nel corso del processo. Piuttosto che limitarsi a guardare i loro risultati, cercare di accertare cosa li ha portati al risultato e, con una guida, come avrebbero risposto e cambiato la loro risposta. Questo probabilmente sarà più rivelatore delle loro capacità rispetto alla semplice risposta diretta al problema. I "perché" del loro approccio possono darti un'idea di se non lo stanno ottenendo o se la loro comprensione è stata leggermente diversa 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 spinge le persone a mettersi sulla 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 ponga ulteriori domande o presti attenzione alle questioni del mondo reale non menzionate esplicitamente.

Ecco alcune cose, in cima alla mia testa, che probabilmente i tuoi requisiti non menzionavano:

• Standard di codifica

• Commenti

• Gestione delle eccezioni

• Nomi descrittivi di variabili, classi, metodi

• Seguendo l'uso idiomatico della lingua

• Design appropriato orientato agli oggetti

• Attenzione a possibili problemi di concorrenza

• Scrittura di casi di test per il codice

Hai prestato attenzione a uno solo di queste cose senza specificarlo esplicitamente? Come fa il candidato a sapere a chi ti sta a cuore e quale no?

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

Generalmente, commettere un errore su tale ipotesi è piuttosto diverso da fare un errore sulle decisioni di progettazione del mondo reale. Se vuoi sapere se qualcuno sovrasterza 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 codifica ha avuto un compito chiaro
• ha requisiti ben definiti (ans anche ben scritti),
• i candidati hanno avuto la possibilità di porre domande per assicurarsi che risolvano il problema corretto.
• vuoi che le persone che sono siano intelligenti e facciano qualcosa nella tua squadra, non astronauti di architettura .

Segnale di avvertimento quasi uguale a quello di che non risolve il problema a portata di mano . Il fatto che abbia fallito il quiz e non abbia fornito la soluzione corretta è un segnale di avvertimento. Non è necessariamente uno scenario "no-go" perché dipende da come e perché non ha fornito la soluzione corretta.

Un sacco di volte la domanda è una schifezza completa e semplicemente irrisolvibile. Non fingere che gli intervistatori non commettano errori. È ancora un fallimento da parte sua scoprire perché la domanda è una schifezza. Se stai assumendo un ingegnere che dovrebbe contribuire 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 ha interpretato erroneamente il problema e andare nelle erbacce cercando di risolvere un problema che non c'era. Sì, è un segnale di avvertimento.

Forse.

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

Se hanno frainteso il problema, esamina attentamente le tue esigenze. Anche le cose che sembrano chiare per te possono non essere chiare per gli altri che non hanno familiarità con un dominio, o da uno sfondo diverso (locale, età, educazione). Se il candidato fosse presente nella stanza con te, o offrisse l'opportunità di porre domande e ancora non ci riuscissi, considererei un fallimento da parte loro. Se i requisiti fossero gettati oltre il muro, probabilmente darei loro il beneficio del dubbio (e pensare a risolvere il processo dell'intervista).

Se la soluzione era corretta, allora diventa meno chiaro. Personalmente, penso che un numero di persone prenda troppo lontano YAGNI . Se è possibile risolvere un problema specifico e creare una soluzione generale senza aumentare la complessità o danneggiare la manutenibilità, allora perché non creare la soluzione generale? (Pensare di invertire una stringa e invertire qualsiasi collezione) Quella sorta di "over-engineering" è chiaramente buona secondo me.

Tutto il resto è quella terra grigia e grigia. La soluzione affronta probabili assi di cambiamento? La soluzione aggiunge complessità o danneggia la manutenibilità? Aggiungere un po 'di complessità per risolvere problemi futuri che sono quasi garantiti per una vittoria. Danneggiare notevolmente la manutenibilità per spiegare qualcosa che è totalmente improbabile.

Essere un buon ingegnere del software significa trovare il giusto equilibrio qui. Essere un buon intervistatore significa colpire 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 considerazione pesantemente in ogni problema che dai a qualcuno

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

• A volte Less is More: preferirei avere alcuni punti elenco, frasi e / o esempi che mostrassero i requisiti principali e poi una discussione con qualcuno per porre domande e magari raggiungere fuori lungo la strada se necessario. Credo che quello che sto cercando di dire è che dovresti prima verificare che i tuoi requisiti di test non siano eccessivamente complicati per un semplice problema.

• Abilità comunicative: dovresti testare la capacità dei candidati di comunicare e porre per prima cosa domande intelligenti sul problema e una volta che sai che hanno dimostrato di aver compreso il problema, puoi impostarli avanti sulla loro attuazione.

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

Molto di questo potrebbe essere attribuito al modo in cui pronunci la domanda e al modo in cui hai messo in prospettiva l'intera intervista.

È come, "Vediamo quanto sei creativo. Cos'è 2 + 2?" Quattro? Tutto quello che potresti inventare è la risposta più semplice, ovvia e accurata? Gli sviluppatori giovani / principianti che sono così desiderosi di impressionare durante un colloquio prenderanno il "Vogliamo testare le tue capacità di codifica o vedere quanto sei bravo come programmatore." per significare "fare qualcosa di molto sofisticato". A tutti piace pensare che il semplice sia il migliore tranne quando rende le cose più difficili.

Ci sono modi per vedere se qualcuno è incline a fare sempre cose troppo ingegneristiche. Fornire un esempio di codice di qualcosa che è troppo complesso e chiedere una soluzione più semplice. Quando qualcuno fornisce una soluzione che non pensate possa funzionare, questa è una grande opportunità per vedere come reagiscono alle critiche. Personalmente, mi piacerebbe vedere qualcuno essere aperto a nuove idee e ricollegare una soluzione migliore di qualcuno che farà ripetutamente gli stessi errori.

E in realtà, non abbiamo sempre l'opportunità di cambiare il nostro codice quando non funziona? È possibile progettare o sovradimensionare 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 collegata da Marjan è generalmente buona.

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

Il loro modo di pensare 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 appieno il contesto in cui è stato sviluppato.

Data la progressione sopra riportata, un candidato con la soluzione sovra-ingegnerizzata potrebbe essere più avanti del candidato con quello semplice.

Inoltre: per quale posizione di livello stai assumendo? Il superingegnerizzazione di un candidato entry level o intermedio è meno problematico di un over-engineering di un candidato di livello senior.

Se il programmatore non risolve il problema, allora tutto il codice extra è il tentativo del codificatore di offuscare la mancata risposta. È la stessa tecnica usata in un saggio di uno studente che non sa molto sull'argomento. Lui o lei dividerà su un argomento avvincente, ma non correlato 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, considera lo sfondo del programmatore, in quanto alcune aree di programmazione richiedono tolleranze maggiori di altre.

Ad esempio, il codice che esegue il pilota automatico in un aereo passeggeri commerciale ha tolleranze di fallimento molto inferiori rispetto ad un gioco Android gratuito. Uno sviluppatore abituato a programmare dispositivi embedded difficili da raggiungere e quasi impossibili da aggiornare tenderà a codificare più cosa, se poi uno sviluppatore in grado di inviare 15 aggiornamenti in un giorno.