Le interviste tecniche tendono ad essere soggettive? [chiuso]

Penso che i tuoi punti ciechi ti portino a presupporre che non sia valido il motivo per cui non ottieni il lavoro.

È possibile rispondere a tutto correttamente in un colloquio di lavoro e non ottenere il lavoro perché si sta competendo contro altre persone che potrebbero aver ottenuto tutto correttamente. Quando hai solo 1 lavoro e tre persone che pensi possano fare il lavoro, puoi comunque assumerne uno solo. È un mercato difficile là fuori e molte persone esperte stanno guardando. Non sai mai quanto bene ha fatto la tua competizione nelle interviste.

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

Qualsiasi intervistatore che ha licenziato un candidato semplicemente perché non ha fornito la risposta prevista è un intervistatore scarso. Se una società incoraggia questo e ho avuto quella sensazione in un'intervista, questa è una seria bandiera rossa sulla squadra e sulla società che mi intervistano.

Se un intervistato mi fornisse una risposta a cui non pensavo, mi aspetterei che fosse in grado di spiegare quale sia la soluzione utilizzata e i vantaggi / svantaggi di ciò. Come hai detto tu, ci sono spesso più soluzioni, che vanno dalla scelta di un algoritmo alle strutture sintattiche usate, e quasi sempre ci sono dei compromessi. Potrei anche sondare l'intervistato per soluzioni alternative per vedere se riescono a inventare altri, soprattutto se è una soluzione ovvia, e chiedere i vantaggi / gli svantaggi di ciascuno.

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

One that I found recently is when I said something about using an AVL tree algorithm to solve a specific problem that was asked. The interviewer asked me back: "What's an AVL tree?".

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

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

Le domande sulla banalità sono anti-schemi per le interviste. Se ti trovi bloccato in una simile intervista, prova a indirizzarli a ciò che sai. Concentrati sul tuo curriculum. Se questo non funziona ... beh, considera di cercare altrove.

Gli intervistatori dovrebbero porre domande aperte relative al tuo CV. Mentre è possibile avere un'idea delle capacità comunicative di una persona, è difficile valutare le capacità di sviluppo di una persona semplicemente facendo domande. Questo è in parte il motivo per cui così tante persone (tra cui Joel sul software) consigliano, non richiedono che gli intervistati scrivano il codice (e saltano attraverso molti altri cerchi per questo).

Resta il fatto che lo sviluppo del software si basa principalmente sulla risoluzione di una serie sconosciuta di problemi in una quantità di tempo sconosciuta. Non ci sono prove che dimostrano, ok questo ragazzo può costruire "un ponte". Stiamo migliorando la trasformazione della creazione del software in un processo di ingegneria più definito, ma non siamo ancora arrivati.

Le "reali" interviste tecniche che avevo erano tutte come: "Ecco il problema, usa queste tecnologie, hai 3 ore". Dopo di ciò 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 la conoscenza.

Poi abbiamo parlato un po 'delle tecnologie e dei miei obiettivi in generale, e così è stato. Le interviste sono, a mio avviso, progettate per dare un'idea del candidato. Non puoi testare tutto. Ci vuole molto tempo per conoscere qualcuno molto bene, quindi, a mio parere, dovresti concentrarti sulle cose che sono importanti per il tuo progetto e vedere come le persone gestiscono questi problemi. Il resto viene con l'esperienza nel tempo

Ho paura che la parte soggettiva non possa essere rimossa, solo diminuita. Ho periodicamente delle interviste tecniche, in cui l'intervistatore "inquina" l'intervista con le proprie idee soggettive.

Un semplice esempio, come dici tu, è che l'intervistatore vuole una risposta molto vicina alla sua risposta. Un altro esempio è che quando un intervistatore è più interessato a sondare lui / lei ne sa più del candidato. E un'altra semplice, è quando l'intervistatore vuole che il candidato conosca la posizione specifica del menu per un'operazione di programmazione I.D.E., (Visual Studio, Eclipse, NetBeans).

Sono stato in molti in questo modo, ed è molto frustrante.

E, naturalmente, c'è anche la cosa della discriminazione nascosta, in cui l'intervistatore non vuole il candidato, dal povero, il genere, le idee politiche, la razza, la scuola, qualunque cosa tu voglia. E sta cercando qualsiasi scusa per rifiutare il candidato.

La parte più strana, è che sono stato un laureato del C.S., conosco alcuni psicologi, (stavo per studiare quella professione) e, a volte, percepisco molte delle "interferenze" soggettive. Oppure, quando l'intervistatore va nell'ufficio accanto, e dice esplicitamente ai suoi colleghi, non vuole assumere un candidato, per una ragione soggettiva.

Qualcosa di importante da considerare è che molte università o società insegnano I.T. / La gente tecnica come fare colloqui di lavoro, e che l'insegnamento includa sia la parte tecnica che quella tecnica; fattori 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 previsto.

• Una volta che il candidato ha finito; Divento lo studente . Ho il candidato per parlare e indicare la loro soluzione e mostrarmi come hanno risolto. Faccio domande sulle loro idee e, se conoscono soluzioni alternative, e perché hanno scelto questa soluzione per questo.

Ecco cosa sto cercando.

• Solo perché so che una buona soluzione al problema non significa che sto cercando quella soluzione. Qualsiasi soluzione valida entro i vincoli iniziali è accettabile. Mi interessa come hanno pianificato la loro soluzione, come hanno usato 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. Erano in grado di comprendere e attuare tutti i requisiti iniziali? Quanto bene hanno spiegato come funziona la loro soluzione?

Alla fine di tutto questo, una volta che ho avuto una buona idea di cosa sia portare in apertura, potrei offrire alcuni dei punti della mia soluzione, dove penso le mie scelte sarebbero migliori

Se il candidato dice qualcosa come "Questa è una buona idea, vorrei aver pensato a questo", o "Oh, non sapevo di questa tecnica", o anche "Ci avevo pensato, ma l'ho usato invece "e fornisce una ragione ragionevole come" Capisco meglio questo metodo "o" Pensavo che stavate cercando questo tipo di soluzione ", questi tutti contano strongmente nel favore del candidato.

Se risulta che il candidato ha scelto diversamente da me, potrebbe significare che ho torto. O se ho ragione, e il candidato è abbastanza aperto per discutere le differenze nelle soluzioni, è un buon segno che il candidato possa essere spinto abbastanza facilmente per fare scelte migliori.

Ecco come so che un candidato è una scelta sbagliata:

• il candidato prova a pescare per una soluzione attesa dall'intervistatore.
• la soluzione fornita non risolve il problema indicato, o in qualche modo viola alcuni dei vincoli indicati in un modo che il candidato non può spiegare.
• il candidato argomenta con i vincoli per cercare di cambiare il problema che si prevede di risolvere (ricorda che questo è un problema per il quale ho una soluzione che può essere implementata in molto meno tempo di quella prevista).
• il candidato si "blocca" e passa gran parte del tempo assegnato a non fare nulla. Idealmente, un candidato potrebbe attaccare il problema da un'altra angolazione o chiedere all'intervistatore di sapere cosa dovrebbe fare quando non può procedere.
• il candidato non sa "perché" ha usato una tecnica, anche se non sa delle alternative. Risposte come "Non conosco nessun altro strumento che faccia questo" o "Non so come funziona questo strumento, ma lo fa", ma "perché ho fatto" sono discutibili.

Pensi che, in quanto intervistato, la tua accettazione di un lavoro non sia soggettiva, in una certa misura? Il reclutamento è un processo a doppio senso.

Come intervistatore, se io e i miei colleghi "clicchiamo" con un candidato, hanno buone possibilità di essere in lizza per il lavoro, supponendo che altri fattori come un esercizio di codifica domestica e problemi con la 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 oggettivo questo?

Sulla questione dell'albero AVL sarei interessato al fatto che il candidato spieghi come funziona e fornisce approfondimenti su proprietà e utilizzo. Fare meglio della spiegazione su Wikipedia. Tieni presente 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 era fondamentalmente ... mai.

Come intervistatore voglio dare a un candidato ogni opportunità per brillare. Immagino che questo si applicherebbe a qualsiasi organizzazione per cui vorresti lavorare.

Un intervistatore buono non farà una domanda in cui si aspetta una risposta specifica, a meno che la domanda non sia banalmente semplice in cui esiste una sola risposta corretta. Un buon intervistatore vedrà come ti avvicini a un problema, come lo pensi e come arrivi alla tua risposta - se la tua risposta è valida non dovrebbero tenerla contro di te perché non hai fatto le cose in quel modo loro lo farebbe.

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

Un'abilità molto importante quando lavori in un team è quella di essere in grado di giustificare la tua soluzione e valutare equamente qualcun altro. Devi essere in grado sia di imparare dai tuoi colleghi che di insegnarli.

Se vuoi utilizzare un albero AVL per risolvere un problema, e gli altri membri del tuo team li ricordano vagamente al college e da allora non ci hai pensato, dovresti essere in grado di spiegargli i vantaggi. Se qualcuno presenta una soluzione che non capisci, è meglio che tu sia disposto a fare domande finché non lo fai. Se qualcuno presenta una soluzione chiaramente inferiore, è meglio essere in grado di articolare il perché. Se qualcuno presenta una soluzione superiore, è meglio essere in grado di riconoscerlo e mettere da parte il tuo ego.

Queste sono le competenze che cerco quando pongo una domanda tecnica durante un'intervista. Se hanno trovato la risposta "corretta" dalla cima della loro testa è in gran parte irrilevante. Questo è importante solo a scuola.