È principalmente una prova della tua comprensione dei fondamenti dell'informatica (che dovrebbe essere un prerequisito per qualsiasi programmatore).

Lo sviluppo del software si è evoluto al punto che i fondamenti della creazione di un buon prodotto sono stati astratti dallo sviluppatore medio. I linguaggi "di alto livello" hanno generato un nuovo raccolto di programmatori copia-incolla che non sanno perché funziona, solo che lo fa. Anche se non è facile, quasi tutti possono imparare un'API al giorno d'oggi.

Chiedere algoritmi, strutture dati e modelli di progettazione aiuta molte aziende a eliminare i programmatori che possono razziare Stackoverflow per ottenere buone risposte, senza capire il funzionamento principi alla base. Scoprirai anche che molte aziende che chiedono informazioni su tali fondamenti, costruiscono in una varietà di piattaforme. Piuttosto che chiedere cose peculiari a una lingua / piattaforma specifica, apriranno l'intervista con domande più generali sull'informatica.

Conoscere i fondamenti di CS ti aiuta a prendere decisioni migliori di livello superiore durante la programmazione. Se fossi un datore di lavoro, vorrei assumere un programmatore che conosca la differenza tra Stack e Queue; un ArrayList da un LinkedHashSet; Bubble sort da Quick Sort; Ci sono implicazioni in termini di prestazioni / progettazione per queste decisioni. È importante capirli, piuttosto che strappare qualcosa dalla rete (da un autore che potrebbe aver preso la decisione sbagliata senza la tua comprensione / conoscenza). Conoscere la soluzione non significa capire la soluzione

• Sai scrivere codice funzionante?

  Questo ovviamente presuppone che ti venga effettivamente chiesto di scrivere codice effettivo durante l'intervista (lavagna stile).

  Non si tratta tanto di non avere nemmeno un singolo errore di battitura nel codice, ma piuttosto di sapere come sono fatti i costrutti di base come i cicli for, sapere come mettere insieme i bit e dimostrando che hai effettivamente scritto un po 'di codice in una lingua per conoscere la maggior parte dei metodi / classi più comuni (apparentemente gli intervistatori hanno un po' di problemi con i candidati che non riescono nemmeno a superare il fizz buzz test).

• Riesci a pensare a un problema?

  Questo sicuramente non si applica solo agli algoritmi.

  È necessario essere in grado di comprendere il problema, analizzare i requisiti, scegliere strutture di dati e algoritmi appropriati, scrivere il codice / seguire l'approccio e analizzarlo: ciò è richiesto per molti / la maggior parte (non bug -fix) attività di programmazione.

• Puoi com comunicare bene (sulla programmazione)?

  Capisci il problema come descritto?

  Chiedi chiarimenti quando richiesto?

  Puoi spiegare l'approccio di alto livello prima di iniziare a scrivere il codice?

  Sei in grado di spiegare il tuo codice dopo il fatto?

  La capacità di comunicare bene è importante nella tua giornata un lavoro quotidiano come programmatore.

  Il tuo capo non dovrebbe preoccuparsi che tu non sia in grado di capire la spiegazione di un problema, non chiedere chiarimenti quando le cose non sono chiare (e alcuni presupposti radicali), non sono in grado di spiegare come intendi risolvere un determinato problema e / o non hanno la capacità di spiegare il codice che hai scritto a nessun altro.

• Hai una discreta conoscenza delle strutture dei dati e degli algoritmi?

  Anche se ti potrebbe essere chiesto di una struttura dati avanzata o di un algoritmo che non utilizzerai mai, la conoscenza di questa struttura dati potrebbe essere un indicatore abbastanza accurato del fatto che conosci abbastanza bene tutti quelli di base.

  Sono anche abbastanza sicuro che puoi attenersi a semplici strutture dati o algoritmi (lista collegata, array, albero di ricerca binario, ricerca binaria, ecc.) In molti casi e ancora fare bene in questo aspetto specifico - mentre un dato avanzato struttura o algoritmo possono essere più adatti a risolvere il problema in questione, spesso potresti risolvere il problema in modo abbastanza efficiente con una combinazione di quelli di base: c'è ancora da scegliere tra loro in base all'adeguatezza e combinarli in modo appropriato.

  E hai sicuramente bisogno di una discreta conoscenza delle strutture dei dati e degli algoritmi: non puoi essere bravo in quello che fai se non sai quando usare quali strumenti nella tua cassetta degli attrezzi.

• Riesci ad analizzare la complessità del tempo e dello spazio e valutare le scelte l'una contro l'altra tenendo conto di esse, fare la scelta più appropriata per la situazione?

  Qualsiasi domanda sulla struttura dei dati o sull'algoritmo dovrebbe comportare complessità e sarà molto significativa per il tuo lavoro quotidiano: nessuno ti vuole per, ad esempio, scrivere codice che esegue ricerche lineari all'infinito attraverso un grande array immutabile perché non sai cosa sta succedendo a basso livello.

Faccio interviste tecniche. Molto spesso non chiedo affatto alle persone le cose che faranno, ma le cose vagamente correlate che hanno fatto. La logica alla base di questo è semplice:

• posso vedere quanto a fondo alla persona piace entrare nei dettagli tecnici.

• Posso confronta la persona con i suoi pari

• Posso testare meglio la sua forza analitica su qualcosa in cui sa effettivamente qualcosa su quella cosa sconosciuta.

• Vedo anche l'auto-riflessione e le capacità di squadra. Per esempio. quando una persona CS parla della propria tesi di laurea e afferma esplicitamente di aver lasciato una certa parte da fare per un compagno di squadra o di come si è impadronita di qualcosa

Tutto questo può funzionare solo se presento loro qualcosa che in realtà posso aspettarmi che sappiano. Se sono bravi in ​​queste cose, di solito lo sono anche in altri argomenti.

Ci sono probabilmente due risposte principali:

Primo, perché è un'opportunità per vedere come un candidato affronta un problema. Anche se non conosci immediatamente la soluzione specifica del problema, il modo in cui spieghi come affronteresti il ​​problema potrebbe rivelare la tua capacità di pensare chiaramente, di comprendere il problema e di dimostrare altre qualità come la pazienza.

La seconda risposta è che lo stanno facendo semplicemente perché è un modo per dimostrare quanto sa un candidato e che credono che altre società facciano lo stesso, quindi la domanda agisce come un ostacolo abbastanza arbitrario che vogliono candidati per saltare.

L'autore ha chiesto: "perché controllano gli algoritmi, anche se il lavoro non li richiede"

Nella maggior parte dei casi, perché:

1) è il modo più semplice per un programmatore immaturo, fresco di uni o semplicemente un buon "googler", per discutere con un candidato, che ne sa più di un intervistatore.

2) a causa dell'inconsapevolezza della complessità dei linguaggi moderni di alto livello e del loro API.

Quando chiedono algoritmi, pensano di "controllare come pensa un candidato".

Dopo 20 anni di programmazione, dimentichi naturalmente la maggior parte del materiale sugli algoritmi proveniente da un'università, perché è usato raramente a basso livello.

(Eccezione: programmatori C / Assembly in alcuni livelli, programmatori core del linguaggio, data mining)

Ti sei concentrato più frequentemente sulle API e strutture di dati di alto livello. Inoltre, le caratteristiche del linguaggio di concorrenza, i modelli di progettazione, gli angoli bui degli stili orientati agli oggetti e funzionali SONO molto più importanti nell'80% dei lavori dei programmatori, quindi li conservi naturalmente in memoria. L'80% dei programmatori inizia a richiamare / aggiornare la conoscenza degli algoritmi solo per le interviste. Questa è la realtà.

Quindi, hai chiesto "ciò che il tuo intervistatore sa o è in grado di cercare su Google", non "ciò che richiede il lavoro", i requisiti reali del lavoro potrebbero essere un segreto molto oscuro per il tuo intervistatore! !!

L'API moderna, i problemi di concorrenza e le strutture di dati di alto livello sono dieci / centinaia di volte più complessi degli algoritmi scolastici e il requisito di conoscere tutto ciò costantemente è folle.

Quindi, hai effettivamente chiesto "la parte più sicura", cose che il tuo intervistatore è in grado di grattare dalle pagine web,

la parte non algoritmica potrebbe essere 1000 volte più complessa, ma è per questo che raramente hai chiesto quella parte - l'intervistatore ha paura - qui è richiesta esperienza, non solo "googling".

A mio avviso, l'industria è paralizzata da quegli intervistatori, la maggior parte di loro sono capi di team che sono entrati nella loro posizione dopo una carriera di programmatore troppo breve.

Queste domande sono un marchio di ignoranza e di esperienza insufficiente.

Invece di porre 10 domande in ciascuna delle 10 aree di programmazione coinvolte da questa azienda / posizione, ad esempio, modelli di progettazione, concorrenza, protocolli, web, concorrenza, client, server, UML, framework, ecc ... (100 domande è un minimo per avere una visione ampia) per scoprire tutti i lati deboli e forti di un candidato, di solito iniziano il colloquio in questo modo:

"Di solito faccio solo due domande!". (È obbligatorio seguito da uno sguardo molto narcisistico - nota che - come questo ragazzo ha scoperto il segreto di una buona intervista e non si preoccupa mai di molte altre domande!) Una domanda sarà un puzzle, la seconda - algoritmo. È abbastanza! Questo è ciò che è veramente importante per un lavoro: risolvere enigmi e un ricordo dei tuoi giorni di scuola !!!

Ciò significa semplicemente: "Penso di essere intelligente, perché l'ho cercato su Google una settimana fa, leggi la soluzione e capito, ora tocca a te, hai 10 minuti, ma niente google ".

Puoi dire" non esagerare, la gente sa cosa chiede ". Davvero? Pensi davvero che se chiedessi un altro "puzzle" avrò una risposta chiara?

A mio avviso, l'intervistatore deve sforzarsi di chiedere cosa è in grado di fare da solo, non di meno, ma non di più. Altrimenti, è un circo, il cui unico scopo è costruire un altro ego per conto del candidato.

Ciò porta a un progresso di un nuovo amore per i puzzle, ma nella pratica debole il tipo, al contrario, il cavallo da lavoro che sa 1000 volte di più, ma meno concentrato su un aspetto sconcertante di solito fallisce - una buona memoria raramente mantiene l'impressione spazzatura, che puoi google, una buona memoria "operativa" mantiene giorno per giorno (Tranne, come ho detto, alcuni campi, in cui gli algoritmi sono affari quotidiani, non su di loro la domanda posta qui!)

Richiederei algoritmi solo nei campi in cui sono richiesti per un lavoro, non per ogni lavoro di programmatore.

A proposito, questa base di "due domande" è un Klondike per le società di outsourcing.

Di solito inviano un tipo "sonda" per scoprire quelle domande, e poi un "vero candidato", che finalmente risponderà (dopo aver cercato su Google).

Lo so per certo: in questo modo quelle domande divertenti di solito si risolvono e anche il lavoro vero e proprio viene svolto bene. Nel 99% dei casi puoi averne solo uno: un buon "algoritmista" O un buon "linguagista", non entrambi.

Questo è uno dei motivi per cui le società di outsourcing crescono e vivono eccezionalmente bene, sebbene dare valore 0 sia per i propri lavoratori che per le aziende in cui lavorano.