Le interviste tecniche tendono ad essere soggettive? [chiuso]

Sulla base della mia esperienza in interviste tecniche, ho scoperto che la maggior parte tende ad essere soggettiva perché l'intervistatore ha già una sua risposta. Anche se la risposta del candidato è corretta, poiché l'intervistatore non era preparato per quella risposta, il candidato non ottiene il lavoro.

In un'intervista di recente ho detto qualcosa sull'utilizzo di un algoritmo ad albero AVL per risolvere un problema specifico che è stato chiesto. L'intervistatore ha risposto: "Che cos'è un albero AVL?". Un altro esempio è qualcosa intorno alla sintassi; L'ho riscontrato principalmente nelle interviste che richiedono il codice Ruby perché ci sono molti modi per implementare una soluzione a un determinato problema. Un problema molto comune è rappresentato dai problemi relativi ai progetti orientati agli oggetti.

In questa situazione, non c'è modo per l'intervistato di avere successo. Qualcun altro si è sentito così o sono solo io? Se non sono solo io, come possiamo migliorare le interviste tecniche?

Penso che i tuoi punti ciechi ti portino a un'ipotesi non valida sul perché non ottieni il lavoro.

È possibile rispondere a tutto correttamente in un colloquio di lavoro e non ottenere il lavoro perché si è in competizione con altre persone che potrebbero anche aver ottenuto tutto corretto. Quando hai solo 1 lavoro e tre persone che ritieni possano svolgere il lavoro, puoi comunque assumerne solo uno. È un mercato difficile là fuori e molte persone esperte stanno cercando. Non si sa mai quanto bene sia andata la competizione nelle loro interviste.

Sì, le interviste sono soggettive, sono alla ricerca di persone che non solo abbiano competenze tecniche ma che si inseriscano nel gruppo esistente. Continua a provare alla fine se sei capace, troverai il posto giusto e loro ti assumeranno.

Qualsiasi intervistatore che ha licenziato un candidato semplicemente perché non ha fornito la risposta prevista è un cattivo intervistatore. Se un'azienda incoraggia questo e ho questa sensazione in un'intervista, questa è una grave bandiera rossa sulla squadra e sull'azienda che mi intervista.

Se un intervistato mi fornisse una risposta a cui non avevo pensato, mi aspetterei che fosse in grado di spiegare qual è la soluzione utilizzata e i vantaggi / svantaggi di essa. Come hai detto, ci sono spesso molteplici soluzioni, che vanno dalla scelta di un algoritmo alle strutture sintattiche utilizzate e quasi sempre ci sono compromessi. Avrei persino sondato l'intervistato alla ricerca di soluzioni alternative per vedere se potevano trovare altri, specialmente se si tratta di una soluzione ovvia, e chiederei i vantaggi / gli svantaggi di ciascuno.

Indipendentemente da come conduci l'intervista, sarà soggettiva. Ogni intervistatore, come persona, avrà pregiudizi. Come intervistato, puoi semplicemente fare il meglio che puoi, essere accurato (ma non eccessivamente prolisso) quando rispondi alle domande e spiegare le tue risposte e come ci sei arrivato. Ci vorrà molto.

Uno che ho scoperto di recente è quando ho detto qualcosa sull'utilizzo di un algoritmo ad albero AVL per risolvere un problema specifico che è stato chiesto. L'intervistatore mi ha chiesto di nuovo: "Che cos'è un albero AVL?".

Come intervistatore, lo chiederei anche a me, anche se sapessi tutto sugli alberi AVL (non lo so), per sapere quanto sa il candidato. La falsa ignoranza può essere un trucco per vedere se il candidato può spiegare bene. Ma ovviamente, se ti viene in mente un algoritmo / una struttura di dati che risolve il problema, che non conosco e che puoi spiegare correttamente, ti assumerei. Altrimenti, vergogna per me. Non assumere persone perché sono più intelligenti di te non è una buona strategia di assunzione.

Ma in generale: sì, le interviste tecniche sono sempre soggettive. E devono esserlo. Se hai intenzione di passare 8 ore + ogni giorno con una persona, non sarebbe ragionevole scegliere qualcuno che riesca a farti impazzire in un'intervista di 60 minuti.

Trivia Le domande sono anti-pattern per le interviste. Se ti trovi bloccato in un'intervista del genere, prova a riportarli a ciò che sai. Concentrati sul tuo curriculum. Se questo non funziona ... bene considera di cercare altrove.

Gli intervistatori dovrebbero porre domande aperte relative al tuo curriculum. Mentre è possibile farsi un'idea delle capacità comunicative di una persona, è difficile valutare le capacità di sviluppo di una persona semplicemente ponendo domande. Questo è in parte il motivo per cui così tante persone (incluso Joel sul software) raccomandano, non è necessario che gli intervistati scrivano codice (e saltino attraverso molti altri cerchi per quella materia).

Resta il fatto che lo sviluppo del software riguarda principalmente la risoluzione di una serie sconosciuta di problemi in un periodo di tempo sconosciuto. Non ci sono prove che dimostrano, ok, questo ragazzo può costruire "un ponte". Stiamo migliorando nel trasformare la creazione di software in un processo di ingegneria più definito, ma non ci siamo ancora.

Le "vere" interviste tecniche che ho avuto sono state tutte: "Ecco il problema, usa queste tecnologie, hai 3 ore". Successivamente abbiamo fatto una revisione del codice e abbiamo parlato del perché ho fatto quello che ho fatto. In questo modo ha visto quello che già so e dove mi manca conoscenza.

Poi abbiamo parlato un po 'delle tecnologie e dei miei obiettivi in ​​generale e basta. Le interviste sono, a mio avviso, progettate per far sentire il candidato. Non puoi testare tutto. Ci vuole molto tempo per conoscere qualcuno abbastanza bene in modo che, sempre secondo me, dovresti concentrarti sulle cose che sono importanti per il tuo progetto e vedere come le persone gestiscono questi problemi. Il resto arriva con l'esperienza nel tempo

Temo che la parte soggettiva non possa essere rimossa, ma solo diminuire. Ho interviste tecniche, in cui l'intervistatore "inquina" l'intervista con le sue idee soggettive.

Un semplice esempio, come dici tu, è che l'intervistatore vuole una risposta molto vicina alla propria risposta. Un altro esempio è quando un intervistatore è più interessato a sondare che conosce più del candidato. E un altro semplice, è quando l'intervistatore vuole che il candidato conosca la posizione specifica del menu per un'operazione di un IDE di programmazione (Visual Studio, Eclipse, NetBeans).

Sono stato su diversi come quello, ed è molto frustrante.

E, naturalmente, c'è anche la cosa della discriminazione nascosta, in cui l'intervistatore non vuole il candidato, da povero, genere, idee politiche, razza, scuola, qualunque cosa ti piaccia. E sta cercando una scusa per rifiutare il candidato.

La parte più strana è che, laureato in CS, conosco un po 'di psicologia (studiava quella professione) e, a volte, rilevano molte "interferenze" soggettive. Oppure, quando l'intervistatore si reca nell'ufficio della porta accanto e dice esplicitamente ai propri colleghi, non vuole assumere un candidato, per un motivo soggettivo.

Qualcosa di importante, da considerare, è che molte università o aziende insegnano alle persone IT / tecniche come fare colloqui di lavoro e che l'insegnamento include sia i fattori tecnici che quelli umani, non solo tecnici.

Ecco come lo faccio:

• Per prima cosa chiedo al candidato di risolvere un problema realistico. Di solito questo è un problema che posso risolvere facilmente; di solito in molto meno del tempo assegnato.

• Una volta terminato il candidato; Divento lo studente . Ho il candidato che parla e indica la loro soluzione e mi mostra come l'hanno risolto. Faccio domande sulle loro idee e se conoscono soluzioni alternative e perché hanno scelto questa soluzione.

Ecco cosa sto cercando.

• Solo perché mi capita di conoscere una buona soluzione al problema non significa che sto cercando quella soluzione. Qualsiasi soluzione valida entro i vincoli iniziali è accettabile. Sono interessato a come hanno pianificato la loro soluzione, a come hanno utilizzato gli strumenti forniti. Sono interessato a quali carenze sono in grado di identificare nelle proprie soluzioni.

• Sono anche interessato a quanto bene ascoltano e comunicano. Sono stati in grado di comprendere e implementare tutti i requisiti iniziali? Quanto bene hanno spiegato come funziona la loro soluzione?

Alla fine di tutto ciò, una volta che avrò una buona idea di ciò che il candidato sta effettivamente portando all'inaugurazione, potrei offrire alcuni punti della mia soluzione, dove penso che le mie scelte sarebbero migliori.

Se il candidato dice qualcosa del tipo "Questa è una buona idea, vorrei averci pensato" o "Oh, non sapevo di quella tecnica" o addirittura "Ci ho pensato, ma ho usato questo invece" e fornisce una ragione ragionevole come "Capisco meglio questo metodo" o "Pensavo che stavi cercando questo tipo di soluzione", tutti contano fortemente a favore del candidato.

Se si scopre che il candidato ha scelto diversamente da me, potrebbe significare che mi sbaglio. Oppure, se ho ragione, e il candidato è abbastanza aperto da discutere delle differenze nelle soluzioni, è un buon segno che il candidato può essere spinto abbastanza facilmente per fare scelte migliori.

Ecco come so che un candidato è una scelta sbagliata:

• il candidato prova a cercare una soluzione prevista dall'intervistatore.
• la soluzione fornita non risolve il problema dichiarato, o in qualche modo viola alcuni dei vincoli dichiarati in un modo che il candidato non può spiegare.
• il candidato discute con i vincoli per provare a cambiare il problema che si aspetta risolva (ricorda che questo è un problema per il quale ho una soluzione che può essere implementata in molto meno tempo di quanto previsto).
• il candidato viene "bloccato" e trascorre gran parte del tempo assegnato a non fare nulla. Idealmente un candidato attaccherebbe il problema da un'altra prospettiva o cercherebbe l'intervistatore per sapere cosa dovrebbe fare quando non può procedere.
• il candidato non sa "perché" ha usato una tecnica, anche se non conosce alternative. Risposte come "Non conosco nessun altro strumento che fa questo" o "Non so come funziona questo strumento, ma funziona" va bene, ma "perché l'ho fatto" sono discutibili.

Pensi che, in qualità di intervistato, la tua accettazione di un lavoro non sia soggettiva, in una certa misura? L'assunzione è un processo a due vie.

Come intervistatore, se io e i miei colleghi "facciamo clic" con un candidato, hanno buone probabilità di essere in corsa per il lavoro, supponendo che altri fattori come un esercizio di codifica domestica e i problemi della lavagna vadano bene. "Fare clic" significa essere sulla mia lunghezza d'onda, avere una conversazione fruttuosa, condividere valori comuni sul processo di sviluppo. Quanto può essere obiettivo?

Sulla domanda dell'albero AVL sarei interessato a spiegare al candidato come funziona e fornire approfondimenti sulle proprietà e sull'uso. Fare meglio della spiegazione su Wikipedia. Ricorda che il tuo pubblico potrebbe essere qualcuno in un ambiente aziendale aziendale in cui l'ultimo riferimento a O (log n) in una discussione tecnica è stato praticamente ... mai.

Come intervistatore voglio dare a un candidato ogni occasione per brillare. Immagino che questo si applicherebbe a qualsiasi organizzazione per la quale vorresti lavorare.

Un buon intervistatore non farà una domanda in cui si aspettano una risposta specifica, a meno che la domanda non sia qualcosa di banalmente semplice in cui esiste una sola risposta corretta. Un buon intervistatore vedrà come affronti un problema, come pensi attraverso esso e come arrivi alla tua risposta - se la tua risposta è valida non dovrebbero tenerla contro di te perché non hai fatto le cose nel modo in cui lo farebbero .

Sembra che tu sia appena stato sottoposto a pessimi intervistatori più preoccupati di mostrare la loro "superiorità" al candidato che di valutare effettivamente le abilità tecniche.

Un'abilità molto importante quando si lavora in gruppo è quella di essere in grado di giustificare la propria soluzione e valutare equamente qualcun altro. Devi essere in grado di imparare dai tuoi colleghi e insegnare loro.

Se vuoi usare un albero AVL per risolvere un problema, e gli altri membri del tuo team li ricordano vagamente dal college e non ci hanno pensato da allora, è meglio che tu possa spiegare loro i loro vantaggi. Se qualcuno presenta una soluzione che non capisci, è meglio che tu sia disposto a porre domande fino a quando non lo fai. Se qualcuno presenta una soluzione chiaramente inferiore, faresti meglio a capire il perché. Se qualcuno presenta una soluzione superiore, faresti meglio a riconoscerlo e mettere da parte il tuo ego.

Queste sono le competenze che cerco quando faccio una domanda tecnica durante un'intervista. Il fatto che abbiano trovato la risposta "corretta" al di sopra della testa è in gran parte irrilevante. Questo è importante solo a scuola.