Come verificare o valutare le capacità di debug di una persona? [chiuso]

Che tipo di abilità determina una persona che è in grado di eseguire facilmente il debug del codice? Qualche tempo fa il mio amico ha condotto un'intervista con un programmatore relativamente bravo. Il programmatore è stato assunto. Poteva scrivere un buon codice, comprendere le strutture e i modelli di progettazione. La cosa che gli mancava era: abilità di debug. Non è stato in grado di eseguire il debug e trovare problemi con il suo codice o quello di qualcun altro è stato un grande dolore per lui.

Da allora stiamo pensando a come valutare o stimare le capacità di debug di una persona.

Quindi la prima domanda è: quali competenze determinano se una persona può effettivamente eseguire il debug del software?

E il secondo: come testare quelle abilità durante l'intervista?

Se la prima cosa che la persona vuole fare è guardare il codice e sfogliarlo con un debugger, quella persona non è un ottimo strumento per la risoluzione dei problemi.

Se non hai già un piano d'azione e ti tuffi nel blind del debugger, sei sostanzialmente Easter Egging. Questo vale per QUALSIASI tipo di risoluzione dei problemi.

In una situazione di intervista, una persona che chiede come funziona il sistema e fa domande sulla storia del sistema sarebbe qualcuno che potrebbe essere un buon strumento per la risoluzione dei problemi. Una persona che pensa prima al sistema e alla meccanica in secondo luogo potrebbe essere un buon strumento per la risoluzione dei problemi.

Questo vale per qualsiasi sistema complesso.

Direi che la migliore misura di un buon sviluppatore di software in un particolare linguaggio o framework è la capacità di analizzare criticamente problemi complessi e di avere buone capacità di debug nel linguaggio o nel framework. Devono essere in grado di dimostrare il debug di basso livello e la competenza nel debug di alto livello con strumenti di debug comuni.

Ciò significa creare uno scenario per loro che mostri un'elevata attitudine agli strumenti di debug nell'IDE selezionato. Dovresti cercare cose come:

• Esecuzione di un'applicazione o server sandbox in modalità debug o creazione di un'applicazione con simboli per il debug

• Rendere disponibile e dimostrare le porte di debug remoto o il debug di applicazioni non sandbox create con simboli (se applicabile alla lingua)

• Uso strategico dei punti di interruzione

• Proprietà personalizzate dei punti di interruzione, espressioni condizionali sui punti di interruzione (se applicabile alla lingua)

• Uso di espressioni o orologi variabili per il monitoraggio di valori o riferimenti variabili

• Utilizzo di valore variabile ad-hoc o manipolazione di riferimenti o puntatori in tempo reale

• Dimostrare la capacità di entrare, uscire e uscire dal flusso dell'applicazione

• Valutazione critica dello stack di chiamate

• Debug di applicazioni multi-thread e comprensione di questo.

Dovrebbero essere dimostrate anche altre strategie di debug senza strumenti, come l'analisi dei log e del codice sorgente, nonché la capacità di eseguire un debug di basso livello senza l'uso di un IDE.

Direi distillare un bug che hai avuto nel tuo sistema su qualcosa che può essere discusso nel contesto di un'intervista. Accendi il debugger e lascialo fare.

Fagli domande come questa:

1. Come affronti un problema?

2. Qual è uno dei progetti complessi che hai realizzato e come lo hai realizzato?

3. Quali strumenti di debug hai usato?

4. Hai qualche preferenza per determinati strumenti?

5. Fai un esempio del tuo scenario personale e chiedigli come lo affronterà?

6. Come giudichi la tua capacità di entrare nel codice di qualcun altro?

Puoi rispondere alle tue preoccupazioni ponendo domande. C'è sempre il rischio che possa o meno essere bravo in certe abilità. Ma se è un bravo studente, questo sarà di grande aiuto.

Se vuoi vedere se un programmatore può eseguire il debug, dai loro il codice da correggere. È lo stesso approccio se vuoi vedere se riescono a scrivere codice. Dagli un problema e fagli scrivere il codice.

Ora, sono confuso su questo programmatore che non ha problemi a scrivere codice ma fallisce irrimediabilmente quando viene chiesto di eseguire il debug. Questa persona rigurgita esempi di codice o si limita ad aree che ha esperienza come leggere e scrivere in un database? A meno che non ottengano il codice giusto la prima volta, non possono ripararlo?

Forse alla persona non piace il debug e non fa alcuno sforzo? Non sono bravo in questo, quindi smettila di chiedermi di farlo - ho imparato l'impotenza.

Lavorare su una base di codice esistente richiede di esaminare il codice, la documentazione e possibilmente prendere appunti e progettare da soli.

So che pensiamo al debug come correzione del codice di produzione che non è riuscito, ma ho bisogno di eseguire il debug del codice mentre lo scrivo. O questa persona non è un ottimo programmatore o preferisce semplicemente scrivere un nuovo codice. Non tutti noi.

Allo stesso modo determineresti l'abilità di codifica di qualcuno, poni loro domande sul debugging.

Chiedi loro "come" avrebbero rintracciato un bug in una determinata situazione.

Fai un passo avanti e mettili di fronte a un computer e guardali mentre eseguono il debug di un problema.

Ho spesso dato ai candidati situazioni ipotetiche ... per esempio, un sistema di produzione ha smesso di rispondere. cosa fai? Potrebbero rispondere "controlla i registri" e io dico "i registri non mostrano nulla di anormale, tranne per il fatto che non c'è scritto nulla da quando il problema ha iniziato a verificarsi". E così continua, finché non sono soddisfatto di aver valutato la capacità dei candidati di risolvere i problemi.

Di solito le persone con una buona attitudine sono anche quelle con buone capacità di debug.

Durante il colloquio, (a seconda della loro anzianità) puoi dare loro un compito simile a un puzzle come qualche algoritmo o giù di lì. Questo è il modo semplice.

Se è possibile, è possibile stampare un codice da qualche lavoro chiedere alla persona se qualcosa non va qui e in tal caso come risolverlo.

Non preferisco fare domande di intervista offuscate che tendono a concentrarsi sulla capacità delle persone di leggere e correggere la sintassi.

Durante un'intervista, chiedi loro di parlarti di un bug che hanno risolto in passato e dei passaggi che hanno usato per il debug.

Fai in modo che ti raccontino cosa hanno fatto nel loro ultimo lavoro, compiti a casa, ecc. E cosa hanno passato per trovare il problema.

Condividerò un'esperienza insieme a una prospettiva di reclutamento sul test delle abilità di un candidato nel debug. Ho ottenuto un'intervista in tre fasi. Il secondo stadio era un "caso pratico". Non ne sapevo di più in quel momento. Mentre sono stato informato, c'è un sistema che ha smesso di funzionare e non lo sanno. Alcuni bug si trovano dietro.

È stato organizzato come desktop remoto in un vecchio ambiente di test. Probabilmente in un ambiente scollegato o isolato. Il progetto consisteva in alcuni moduli web con alcuni controlli ASP.NET e relativo codice del file di codice. Il file di codice si riferiva a un tipo di livello aziendale per il quale ho solo una dll, nessun codice sorgente e descrizioni dei metodi. I moduli Web hanno fatto le funzioni CRUD che ci si può aspettare. Anche una piccola funzione di ricerca. Il livello aziendale, a sua volta, ha parlato con Views e SP in un server sql.

Hanno rotto alcune parti a diversi livelli. Mi è stato dato un documento con i sintomi. "Impossibile cercare" "Il campo 'regione' è scomparso dopo l'ultimo aggiornamento" e così via. Come puoi ricevere dai tuoi utenti.

Non ricordo tutti i dettagli, ma almeno un campo tabella è stato rinominato, il che porta a un SP interrotto, che è stato utilizzato dalla funzione di ricerca. Ciò significa che nessun errore in VS e nessun codice sorgente BL per tracciare i nomi dei campi. Un parametro SELECT su Sqlcommand è stato errato e ha causato un malfunzionamento di un modulo web. Inoltre è stato omesso un campo che era il campo mancante in GridView (Autogeneratecolumns). Un pulsante ASP.NET era riferito a qualcosa che doveva essere un metodo duplicato, migliorato e "dimenticato" per puntare il pulsante a un nuovo metodo.

Anche una cosa minore che usa il titolo in un tag html che non lo consente. Anche il tag ALT opposto è stato omesso in un controllo che lo richiedeva. Ci sono stati anche alcuni errori con tag html chiusi non corretti ma che non hanno funzionato male. Non sono sicuro se tutto ciò fosse un puro errore del progetto del teatro o forse lo stesso progetto per diverse assunzioni. Non l'ho mai chiesto. Il livello di difficoltà dovrebbe ovviamente corrispondere all'esigenza del reclutamento.

Tale test dovrebbe probabilmente essere sottoposto a screening (non seguito) per vedere, dopo l'intervista, come è stato eseguito il debug. Per quanto mi riguarda in quella fase, ho trovato il test un po 'ridicolo, ma questo sarebbe anche il punto più importante. Se è stato o no, dovrebbe valere la pena avere il candidato nel posto giusto.

* Penso che sia stato dimostrato che i candidati / le mie capacità sono stati
* per analizzare un sistema straniero
* Utilizzare un minimo di informazioni per trovare errori e bug
* Sotto stress nel tempo e senza che qualcuno ti aiuti, codifica ipotizzato correzioni
* Diversi livelli di conoscenza;
** sql db e stored procedure,
** utilizzo di dll nel progetto,
** tecnica asp.net,
** architettura a strati
** aspetto orientato al problema

Ma anche le cose più ovvie come gestire l'ambiente degli sviluppatori, trovare e comprendere lo strumento di gestione dei server Db. Sicuramente ci sono candidati che sembrano davvero carini sulla carta ma, in pratica, potrebbero rimanere bloccati su tali compiti.

Scelgo un problema reale che ho riscontrato che è rilevante per la posizione e lo presento al candidato così come mi è stato presentato. Ovviamente offro loro un background generale e una piccola quantità di documentazione pertinente come uno snippet di codice o un diagramma schematico.

Dico loro che il loro compito è quello di risolvere il problema e offro di rispondere a tutte le domande tecniche che hanno e di dire loro il risultato di tutti gli esperimenti che vogliono eseguire. Se dicono: "Metterei qui un probe scope", allora traccerò loro una traccia di ciò che potrebbero trovare. Se vogliono inserire un printfin un ciclo, dirò loro che non esce mai (!) O prima stampa "7" e poi ripetutamente "5". Se si allontanano così tanto dalle erbacce che non posso dare risposte significative, ammetto che siamo sulla strada sbagliata e torniamo da qualche altra parte. Se rimangono bloccati, farò domande importanti o darò suggerimenti fino a quando non potremo andare avanti.

Quello che voglio vedere sono processi di pensiero ordinati, determinazione per arrivare alla soluzione, domande ed esperimenti ben ponderati e idealmente un'identificazione riuscita del problema. A volte scelgo problemi che sono troppo complessi perché qualcuno possa eseguire il debug completo in un'intervista di un'ora e alla fine do loro la vera risposta. A quel punto sto cercando una reazione che dimostri che sono stati coinvolti con il problema e sperimentano quel momento "aha" e la gratificazione nel raggiungere la causa. I migliori candidati faranno spontaneamente domande di follow-up a quel punto, cercando di collegare la loro mappa mentale del problema con ciò che stava realmente accadendo.

Siedili su un computer con alcuni semplici simboli binari (con debug) che segfault con riferimento a puntatore null o tale + codice sorgente + gdb e vedi se riescono a trovare la causa del crash?

Se i tuoi candidati devono fare un test preliminare del codice, chiedi loro di modificare il codice durante il colloquio per risolvere un bug o aggiungere una nuova funzionalità o meglio ancora entrambi. Se rendi le specifiche del test del codice piuttosto vaghe, ciò faciliterebbe la creazione di casi di test con "bug".

Trovare "il bug" in un piccolo frammento di codice è una situazione molto artificiale. Suppongo che potrebbe essere utile allo stesso modo degli enigmi e dei rompicapo.

Un approccio più completo porrebbe domande comportamentali su come il candidato ha eseguito il debug in passato citando incidenti specifici e quindi dando seguito a domande.

Qualcuno che è bravo a risolvere i problemi sarà in grado di parlare di più delle semplici strutture di debug nell'IDE. Che dire di ... strumenti di segnalazione dei bug, interazione dell'utente finale, riproduzione del bug, analisi dei file di registro, verifica?

Esiste MOLTO ALTRO nel debug che nel tracciare un blocco di codice e qualsiasi valutazione delle abilità di qualcuno nel debug dovrebbe respingerlo.

Dai a qualcuno del fantastico codice che la tua azienda esegue in produzione. Chiedi loro di introdurre un bug sottile. Chiedi loro perché hanno scelto quello. Chiedi loro come farebbero per trovarlo e risolverlo.

Punto bonus se trovano un bug nel codice originale.

Raddoppia il punto bonus se riescono a correggere l'errore nel codice originale.

Tendo a chiedere alle persone di descrivermi il bug più difficile che abbiano mai dovuto rintracciare e correggere e cosa hanno fatto per trovarlo e risolverlo. So anche che se il bug più difficile era qualcosa che ti aspetteresti che solo un principiante trovasse difficile, allora probabilmente non sono buoni strumenti per la risoluzione dei problemi (a meno che non si tratti di un'intervista per il livello base). Se è qualcosa di veramente difficile e descrivono il loro processo di pensiero mentre cercavano di rintracciarlo, allora posso avere un'idea di quale sia il loro livello di abilità. Ciò che mi ha sempre stupito è il semplice numero di persone che hanno un aspetto da "cervo nei fari" e non riescono a pensare a un singolo esempio di qualcosa che hanno fatto che fosse complicato. Beh, mi dispiace che qualcuno che lasci i problemi difficili da risolvere per qualcun altro non sia qualcuno a cui sono interessato per nulla, tranne un semplice fuori scuola,

Farei un paio di domande agnostiche sulla tecnologia come le seguenti:

• Seguimi in tutti i passaggi che segui per identificare la causa principale e correggere un bug (difetto)
• Come useresti lo stack di chiamate durante il debug di un'app multi threading

Funziona molto bene specialmente nelle interviste telefoniche poiché hai solo bisogno che la persona ti dia una risposta convincente che mostri come fa davvero le cose mentre risolve un problema.