Come gestite le domande basate sulla conoscenza nelle interviste? [chiuso]

Nelle interviste tecniche che intervistano programmatori esperti, gli intervistatori pongono molte domande basate sulla conoscenza. [per esempio. Ad esempio come configurare questo e quello nell'xml]. Queste domande hanno esattamente una risposta ed è molto probabile che un buon programmatore possa non conoscere la risposta (e quindi essere respinto). C'è un buon modo per rispondere a queste domande? [Come dire educatamente all'intervistatore che la risposta è solo una ricerca su Google].

Penso che dovrebbe essere OK dire all'intervistatore che onestamente non conosci la risposta, e quindi procedere a dire loro come lo scopriresti (come chiedere ai colleghi, consultare il manuale, cercare sul web, ecc ...) . Ciò dovrebbe mostrare all'intervistatore che sei pieno di risorse e adattabile a nuove situazioni e disposto a imparare - e anche onesto nell'ammettere quando non lo sai piuttosto che cercare di bluffare e fallire. Non ho avuto questa esperienza personalmente, quindi non sono sicuro al 100% di come funzionerebbe, ma accetterei quel tipo di risposta se fossi l'intervistatore. In bocca al lupo!

Il mio tipo di intervista preferito ... La mia risposta tipica se non conosco la risposta dalla mia testa è dire altrettanto, ma poi procedere a descrivere come risolverei il problema.

Ad esempio, "Qual è la chiamata API per Shazbut il Fuzzer?"

Risposta , vorrei andare ai documenti API "Fuzzer" online e scoprirlo. Per essere onesti, non ho usato "Fuzzer" ma ho usato "Fubar" che fa la stessa cosa. Abbiamo usato Fubar nel nostro ultimo progetto a causa di X, Y e Z.

Questo tipo di approccio dimostra una serie di cose:

1. Hai una comprensione più che casuale del problema
2. Sai come trovare le risposte (Howard Hughes non conosceva tutte le risposte sull'aviazione, ma aveva un team di persone che lo sapevano)
3. Capisci che ci sono alternative e ragioni per scegliere l'una rispetto all'altra.

Se fossi l'intervistatore, vorrei qualcuno con la conoscenza più completa di qualcuno che potesse dire la risposta.

Se è una domanda che non sembra corretta, lo menzionerei anche io. A volte trovi persone che vogliono ingannarti - forse è per vedere se stai prestando attenzione o se stai per dare una risposta ovviamente sbagliata come se fossi l'autorità su di essa. Usando la stessa ipotetica domanda, potresti avere una risposta simile a questa: "Questa è la prima volta che ne ho mai sentito parlare. Se non ti dispiace, dove posso trovare maggiori informazioni al riguardo?"

Questo dice all'intervistatore che non farai finta di sapere qualcosa che non conosci, ma sei disposto a imparare. Decidi tu se dedicare del tempo a cercare l'API Fuzzer da solo.

Penso che in un'intervista sia importante essere in grado di dimostrare come gestire il confronto con i limiti delle proprie conoscenze. Il tuo datore di lavoro vorrà essere in grado di scaricare un documento di 200 pagine su una tecnologia che non conosci e si aspetta che tu diventi l'esperto residente su di esso.

Quando ho intervistato per la mia posizione attuale, non avevo scritto alcun C ++ nei vari anni dal college e l'ho ammesso. Quando qualcuno ha scritto class A : public Bcome parte di una domanda sulla lavagna, non riuscivo a ricordare quale fosse la classe base e quale fosse derivata, ma dopo aver chiesto all'intervistatore la sintassi, sono stato in grado di rispondere con successo alla domanda in base alla mia conoscenza dei concetti sottostanti e gli fu offerto il lavoro. D'altra parte, qualcuno che afferma di aver programmato in C ++ ogni giorno negli ultimi 5 anni dovrebbe sapere che la sintassi è in cima alla sua testa.

Tuttavia, anche qualcuno che usa sempre una lingua particolare, può essere arrugginito in alcune aree che potresti non aspettarti, ma dovrebbe avere una buona ragione per farlo. Ad esempio, eseguo la programmazione integrata e non ho scritto codice per aprire o leggere da un file da molto tempo, o ottenere input da un utente, interrogare un database o disegnare una GUI. Ciò non significa che non potrei riacquistare rapidamente quelle abilità, ma dovrei essere pronto a dimostrare la capacità di farlo e non aspettarmi solo che credano nella mia parola.

Come altro esempio, in un lavoro precedente, tutta la nostra memoria doveva essere allocata staticamente, per rendere semplice la prova dei requisiti RAM massimi per l'ultra affidabilità. Nella rara eccezione non era possibile, dovevi ottenere un peer per firmare e la memoria non poteva mai essere liberata. Sono stato molto bravo a evitare l' allocazione dinamica, ma non è la stessa cosa di essere bravo a farlo.

Se facessi una domanda su quelle aree, ammetterei di essere arrugginito, e darei il motivo, quindi procedere a rispondere al meglio che potessi ricordare, ponendo chiarimenti se necessario.

Sono ambivalente su di loro. A una parte di me non piace quanto siano banali (" qual è il terzo parametro della funzione Stampa ") ma riconosco anche che se qualcuno lavora con una tecnologia, nel tempo l'hai vista così tante volte che la conosci a memoria . Sono abbastanza disposto a dire "Non lo so, lo farei su Google prima di infastidire i miei colleghi." D'altra parte, se rispondi a tutte le domande con la stessa risposta, ti dà l'impressione di non conoscere la tecnologia e di andare su google tutto, incluso il codice che hai presumibilmente scritto.

Lavoro con .NET. Le prime versioni del framework avevano oltre 40.000 oggetti diversi. Nessuno può conoscerli tutti.

Ho avuto un'intervista o due come questa e posso capire che può farti sentire a disagio. Di solito è quando un datore di lavoro tocca alcune tecnologie che ho nel mio CV / Riprendi che non ho usato per un buon anno o due.

Rispondo dando loro la comprensione della tecnologia che chiedono e come viene applicata, quando viene applicata e quando non viene applicata. Dal punto di vista tecnico, farò del mio meglio per rispondere, anche una mezza risposta è utile per loro, e li rassicurerò che sì, se fossi sul mio PC, Google aiuterebbe e che la risposta tecnica non è altro che un minuto o due per ritardare nel portare avanti il ​​lavoro.

Tutto sommato, penso che un intervistatore possa porre abbastanza domande per sapere se hai il calibro per il lavoro e quanto rischi sei per loro.

Tuttavia, se hai effettivamente risposto a tutte le domande tecniche in modo errato o hai ricevuto una domanda molto ovvia come, come fai a dichiarare una variabile sul linguaggio X, sbagliata, allora sarebbe molto preoccupante per loro e sentiranno di non avere il tempo di investire per farti accelerare o allenarti sui fondamenti.

Mi è successo questo durante un'intervista telefonica in cui mi è stata presentata una domanda riguardante un'utilità BASH che non avevo mai usato prima. Ho spiegato che, sebbene non lo avessi mai usato prima, ero sicuro di poterlo fare dopo aver controllato Google o la sua pagina man.

Essendo un'intervista telefonica, l'intervistatore mi ha rapidamente messo sul posto chiedendomi se fossi di fronte a un computer e mi ha chiesto di farlo. Pochi istanti dopo sono stato in grado di dare una chiara spiegazione di come potesse essere utilizzato per risolvere il problema presentato.

Poco dopo mi hanno offerto il lavoro.