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

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 immergi nel debugger blind sei fondamentalmente Easter Egging. Questo è vero per QUALSIASI tipo di risoluzione dei problemi.

In una situazione di colloquio una persona che chiede come funziona il sistema e chiede informazioni sulla storia del sistema sarebbe qualcuno che potrebbe essere un valido strumento per la risoluzione dei problemi. Una persona che pensa per prima cosa al sistema e la meccanica in secondo luogo potrebbe essere un valido strumento per la risoluzione dei problemi.

Questo vale per qualsiasi sistema complesso.

Direi che la misura migliore 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 debugging nel linguaggio o nel framework. Devono essere in grado di dimostrare il debug a basso livello e la competenza nel debug di alto livello con strumenti di debug comuni.

Questo significa creare uno scenario per loro che dimostra l'attitudine elevata degli strumenti di debug nel proprio IDE scelto. Dovresti cercare cose come:

• Esecuzione di applicazioni o server in modalità sandbox in modalità di debug o creazione di applicazioni con simboli per il debug

• Rendere disponibili e dimostrative le porte di debug remoto o il debug di un'applicazione non in sandbox costruita 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 dei valori delle variabili o dei riferimenti

• Uso di valori di variabili ad hoc o riferimenti o manipolazione puntatore in tempo reale

• Dimostra la capacità di entrare, uscire e uscire dal flusso di applicazioni

• Valutazione critica dello stack di chiamate

• Eseguire il debug di applicazioni multi-thread e comprenderle.

Dovrebbero essere dimostrate anche altre strategie di debug senza strumenti, come l'analisi di log e codice sorgente, oltre alla possibilità di eseguire alcuni debug di basso livello senza l'uso di un IDE.

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

Fagli domande come questa:

1. Come affronta un problema?

2. Qual è uno dei progetti complessi che hai fatto e come l'hai realizzato?

3. Quali strumenti di debug hai usato?

4. Hai qualche preferenza per determinati strumenti?

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

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

Puoi rispondere alle tue preoccupazioni facendo domande. C'è sempre il rischio che possa o meno essere buono in certe abilità. Ma se è un buon discente, 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 possono scrivere codice. Dai loro un problema e invitali a scrivere codice.

Ora, sono confuso da questo programmatore che non ha problemi a scrivere codice ma fallisce quando gli 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 risolverlo?

Forse la persona non ama il debugging e non fa sforzi? Non sono bravo in questo quindi smetti di chiedermi di farlo - apprensione appresa.

Lavorare su una base di codice esistente richiede di guardare attraverso il codice, la documentazione e possibilmente di creare delle note e dei desgins personalizzati.

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

Allo stesso modo, determineresti la capacità di codifica di qualcuno, ponigli domande sul debugging.

Chiedi loro "come" rintracceranno un bug in una determinata situazione.

Fai un ulteriore passo avanti e mettili a sedere davanti a un computer e osservali mentre eseguono il debug di un problema.

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

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

Durante l'intervista, (a seconda della loro anzianità) puoi dare loro un incarico simile a un puzzle come un algoritmo o qualcosa del genere. Questo è il modo semplice.

Se puoi, puoi stampare un codice da un lavoro, chiedere alla persona se c'è qualcosa di sbagliato qui e, in tal caso, come risolverlo.

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

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

Fagli raccontare ciò che hanno fatto nel loro ultimo lavoro, i compiti a casa, ecc. E quello che hanno passato nel trovare il problema.

Condividerò un'esperienza insieme al punto di vista delle reclute sul test delle competenze di un candidato nel debugging. Ho ottenuto un'intervista con tre stadi. Il secondo stadio era un "caso pratico". Non ne sapevo di più in quel momento. Mentre ero lì sono stato informato che c'è un sistema che ha smesso di funzionare e loro 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 era costituito da alcune webform con alcuni controlli ASP.NET e il relativo codice di codice file. Il file di codice si riferiva a un tipo di strato aziendale per il quale ho solo una dll, nessun codice sorgente e descrizioni dei metodi. Le Webform hanno fatto le funzioni CRUD che puoi aspettarti. 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 foglio con sintomi. "Can not search" "Il campo 'region' è 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 ha portato a un SP rotto, 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 contro Sqlcommand è stato errato e ha causato il malfunzionamento di un modulo Web. È stato omesso anche un campo che era il campo mancante in GridView (colonne autogenerate). Un pulsante ASP.NET si riferiva a qualcosa che doveva essere un metodo duplicato, migliorato e "dimenticato" per puntare il pulsante al 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. C'erano anche degli errori con tag html chiusi non corretti ma che non funzionavano male. Non sono sicuro se tutto ciò fosse un puro progetto-errore-gioco o forse lo stesso progetto per diverse assunzioni. Non ho mai chiesto Il livello di difficoltà dovrebbe naturalmente corrispondere alle esigenze della recluta.

Tale test dovrebbe probabilmente essere sottoposto a screening (non seguito) per vedere, dopo l'intervista, come è stato eseguito il debug. Per me stesso in quel momento, ho trovato il test un po 'ridicolo, ma sarebbe anche il punto principale. Se fosse o non fosse, dovrebbe valere molto avere il candidato nel posto giusto.

* Penso che il test sia stato dimostrato dai candidati / le mie competenze per *
* Analizzare un sistema straniero
* Usa un minimo di informazioni per trovare errori e bug
* Sotto stress del tempo e senza qualcuno che ti aiuti, il codice ha assunto correzioni
* Diversi livelli di conoscenza;
** sql db e stored procedure,
** uso di dll nel progetto,
** tecnica di asp.net,
** architettura a strati
** Aspetto orientato al problema

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

Scelgo un problema reale che ho riscontrato pertinente alla posizione e lo presento al candidato tanto quanto mi è stato presentato. Naturalmente offro loro un background generale e una piccola quantità di documentazione rilevante come un frammento di codice o un diagramma schematico.

Dico loro che il loro compito è risolvere il problema e offro di rispondere a qualsiasi domanda tecnica e dire loro l'esito di qualsiasi esperimento che desiderano eseguire. Se dicono "Metterei una sonda ottica qui", poi traccerò loro una traccia di ciò che potrebbero trovare. Se vogliono inserire un printf in un ciclo, dirò loro che non esce mai (!) O prima stampa "7" e poi ripetutamente "5". Se sono così lontani dalle erbacce che non posso dare risposte significative, ammetterò che siamo sulla strada sbagliata e torniamo da qualche altra parte. Se si bloccano farò domande importanti o darò suggerimenti finché non potremo andare avanti.

Ciò che voglio vedere sono processi di pensiero ordinati, determinazione per arrivare alla soluzione, domande e esperimenti ben ponderati, e idealmente un'identificazione riuscita del problema. A volte scelgo problemi troppo complessi per consentire a qualcuno di 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 mostri che sono stati coinvolti nel problema e sperimentano quel momento "aha" e la gratificazione per arrivare alla causa. I migliori candidati faranno spontaneamente domande di follow-up a quel punto, cercando di collegare la loro mappa mentale del problema con quello che stava realmente accadendo.

Mettili a un computer con alcuni semplici simboli binari (con debug) che codificano con riferimento al puntatore nullo o tale + codice sorgente + gdb e vedi se riescono a trovare la causa dello schianto?

Se i tuoi candidati fanno un test preliminare di codice, chiedi loro di modificare il codice durante l'intervista per risolvere un bug o aggiungere una nuova funzione o ancora meglio entrambi. Se rendi le specifiche del test del codice piuttosto vago, allora sarebbe più facile creare casi di test con "bug".

Trovare "il bug" in un piccolo frammento di codice è una situazione molto artificiale. Suppongo che potrebbe essere utile nello stesso modo in cui sono puzzle e rompicapo.

Un approccio più completo porrà domande comportamentali su come il candidato ha eseguito il debug in passato citando incidenti specifici e poi seguendo domande.

Qualcuno che è bravo nella risoluzione dei problemi sarà in grado di parlare più delle semplici funzioni di debug nell'IDE. Che dire ... degli strumenti di segnalazione dei bug, dell'interazione dell'utente finale, della riproduzione del bug, dell'analisi dei file di log, della verifica?

C'è molto di più nel debugging del tracciamento attraverso un blocco di codice e qualsiasi valutazione delle abilità di qualcuno nel debug dovrebbe rifarlo.

Offri a qualcuno un codice fantastico in cui la tua azienda è in produzione. Chiedi loro di introdurre un insetto sottile. Chiedi loro perché l'hanno scelto. Chiedi loro come farebbero per trovarlo e risolverlo.

Punto bonus se trovano un bug nel codice originale.

Doppio punto bonus se possono correggere il bug 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 di iscrizione). Se è qualcosa di veramente difficile e descrivono il loro modo di pensare mentre cercano di rintracciarlo, allora posso capire qual è il loro livello di abilità. Ciò che mi ha stupito di più è il numero di persone che hanno un aspetto da "cervo ai fari" e non riescono a pensare a un singolo esempio di qualcosa che hanno fatto che è stato complicato. Beh, scusami qualcuno che lascia i problemi difficili per qualcun altro da risolvere non è qualcuno a cui sono interessato per qualcosa, tranne un semplice lavoro di livello elementare, molto giovane.

Vorrei fare un paio di domande indipendenti dalla tecnologia come le seguenti:

• Portami attraverso tutti i passaggi da te intrapresi per identificare la causa principale e correggere un bug (difetto)
• Come utilizzeresti lo Stack di chiamate mentre esegui il debug di un multi-threading App

Funziona molto bene specialmente nelle interviste telefoniche in quanto hai bisogno solo della persona per darti una risposta convincente che mostri come sta realmente andando a risolvere un problema.