Come non fallire un colloquio tecnico presso un'azienda informatica. Supera il colloquio tecnico

Su Internet si riversa molto dolore per le interviste infruttuose. Ad alcuni non sono piaciute le domande degli intervistatori, altri si sono offesi per il ridicolo, altri sono stati giudicati in base alla loro pagina VKontakte. Gli intervistatori tengono il passo con i candidati e giurano su quanto sia grave la situazione del personale in questi giorni e quali risposte stupide danno i programmatori inesperti alle loro domande difficili. questioni tecniche.

Sfortunatamente, non esistono regole universali per superare e condurre colloqui, e non possono esserlo, perché i dipendenti vengono selezionati non solo in base alle loro competenze tecniche e qualità personali, ma anche in base alla corrispondenza con alcuni “profili” (spesso impliciti e molto soggettivi) che, secondo agli intervistatori, si adatta alla loro squadra o azienda. Per quanto riguarda le guide della serie "come superare correttamente le interviste", di solito non causano meno dolore nei commenti, perché sono molto soggettive e sicuramente toccheranno i punti deboli di qualcuno.

Nel corso della mia carriera professionale, sono stato su entrambi i lati della barricata, anche se probabilmente ho dovuto fare interviste un po' più tecniche che superarle. Ma durante questo periodo ho accumulato una serie di “mode passeggere” che mi spaventano durante un colloquio tecnico e immediatamente nella mia mente mettono fine a ulteriori conversazioni. Questo è ciò di cui volevo parlare, dal punto di vista dell'intervistatore e del richiedente. Vorrei subito riservare che l'articolo rifletta le mie personali impressioni soggettive e non pretenda di essere una "guida alle interviste". D'altra parte, non si tratta di un momentaneo scoppio di rabbia per un colloquio fallito, ma di una serie di criteri ponderati a lungo che, anche se su base negativa, mi consentono di eliminare le opzioni o di non spaventare un candidato potenzialmente idoneo .

Cosa ti irrita o ti stressa durante le interviste? Condividi nei commenti.

Intervista dal punto di vista del richiedente

Ogni volta che un programmatore cerca lavoro, deve sostenere numerosi colloqui tecnici. Gira per gli uffici o parla su Skype, risolve problemi o fa test, risponde a domande tecniche difficili, cerca di dimostrarsi con il lato migliore. Lui stesso però valuta anche le persone che lo intervistano e lo mettono alla prova, pensando che domani potenzialmente dovrà lavorare con queste persone. E ci sono molti modi per farlo colloqui tecnici ers per spaventare il richiedente da una posizione interessante. Parlerò di ciò che mi ha sempre spaventato personalmente e di ciò che cerco di evitare come intervistatore.

1. “Che altro colloquio tecnico?»

La prima e più importante cosa che mi ha sempre allarmato riguardo ad un colloquio tecnico è la sua assenza. Succede che l'intera conversazione con specialisti tecnici - potenzialmente futuri colleghi - si basa su domande riguardanti l'esperienza professionale: dove ha lavorato, su quali progetti ha lavorato, quale funzione ha svolto in essi. Per quanto riguarda la tecnologia o la conoscenza, domande al livello di "di che colore è il libro di testo". Sai cos'è un Message Broker? Ottimo, ti portiamo noi!

Questo approccio al colloquio mi ha sempre messo nettamente contro un potenziale datore di lavoro. Non mi hanno fatto una sola domanda per verificare che conoscessi davvero il fatto mio. Sembra che le persone che mi intervistano o non capiscano nulla dell'argomento e stiano cercando almeno una persona che capisca, oppure siano semplicemente disperate e pronte ad affrontare chiunque. In ogni caso, difficilmente vorrei lavorare in un team reclutato in questo modo.

2. "Bene, cosa stavi facendo lì in quel..."

È sorprendente quanto spesso si manifestino atteggiamenti sprezzanti nei confronti dei candidati durante i colloqui tecnici. Sì, forse sei un programmatore severo ed esperto con un sacco di progetti alle spalle, sei stato strappato da un lavoro estremamente importante per il bene di alcune interviste inutili con persone, la maggior parte delle quali, secondo te, sono completamente incompetenti. Ma non dimenticare che in questo momento rappresenti la tua azienda e la tua squadra, e una persona valuterà sicuramente il clima nella squadra in base al tuo comportamento e il modo in cui lo tratteranno in questa squadra. Sii educato e rispettoso nei confronti del richiedente, anche se fin dai primi cinque minuti ti sei reso conto che non gli dovrebbe essere permesso di avvicinarsi al tuo prezioso codice.

3. "Il tuo nome/cognome/nome patronimico è scritto in modo errato sul tuo curriculum!"

Questo non è affatto tecnico, ma è comunque un problema comune anche nei colloqui tecnici. Fortunatamente, ho un nome abbastanza semplice e comune e tali problemi non mi sono capitati. Tuttavia, so che c'è un numero sorprendente di persone che credono fermamente che certi nomi e persino patronimici semplicemente non esistano. Ti convinceranno che il nome corretto non è “Danila”, ma “Daniil”, oppure che non esiste il nome “Alena”, ma solo “Elena”. Si offriranno di correggere e scrivere “correttamente” nei loro documenti. Le persone con rari o nomi insoliti e credimi, è incredibilmente fastidioso. Quindi, c'è una regola semplice: non esistono nomi che non esistano. Scrivi correttamente come scritto sul passaporto. Mostra rispetto al richiedente e non considerarlo così stupido da non essere in grado di copiare dal passaporto al curriculum nome di battesimo. Anche se sospetti un errore, puoi chiarirlo con più tatto.

4. “Quante palline da golf sarebbero necessarie per pulire tutti i finestrini rotondi di uno scuolabus ridotto alle dimensioni di un centesimo durante l’evacuazione di San Francisco, utilizzando non più di 3 pesate?”

Nessun articolo sulle interviste sarebbe completo senza menzionare i tombini. Puoi considerare questo il mio punto personale relativo all'incapacità di risolvere rapidamente e sotto pressione problemi non standard. Ma sono sicuro che i rompicapi siano assolutamente inutili durante le interviste. O meglio, lo è ottimo modo recluta un intero dipartimento di prodigi del cervello con le Olimpiadi del cervello, che si scambieranno nuovi rompicapo tutto il giorno invece di lavorare. Vero programmatore dentro ambiente naturale Nella sua vita quotidiana, anche quando ha a che fare con compiti molto interessanti e non standard, raramente codifica sotto stress e trascorre la maggior parte della giornata seduto e pensando tranquillamente in un'atmosfera relativamente calma a come può meravigliosamente trasformare il codice in metodi. Non usa mai i suoi “muscoli cerebrali” per risolvere problemi complicati in questo processo.

5. “Sbagliato. Ulteriore."

Naturalmente, non è compito dell'intervistatore formare le persone che vengono al colloquio. Tuttavia, se il richiedente non è riuscito a rispondere alla domanda, ma è comunque interessato, allora suggerirgli o almeno indicargli la soluzione corretta prima di passare alla domanda successiva è una domanda etica professionale, dimostrando che se succede qualcosa lo aiuteranno, gli insegneranno e non lo lasceranno solo con problemi tecnici. Digli almeno qualche parola, cosa cercare su Google, cosa leggere. Dopotutto, interesse per la decisione giusta i compiti sono in sé qualità positiva uno specialista tecnico e non dovresti demotivare tale persona denigrando i suoi errori o inesattezze.

Intervista dal punto di vista dell'intervistatore

Ogni volta che si apre un nuovo posto vacante, uno specialista leader o un capo dipartimento deve condurre numerosi colloqui tecnici. Le persone vengono ai colloqui con esperienze tecniche, livelli di formazione e aspettative diverse. Per condurre un colloquio, è necessario elaborare un piano di conversazione, stilare un elenco di domande e quindi cercare di capire dalle risposte a queste domande se la persona è adatta o meno alla posizione. E a volte i candidati durante i colloqui dicono cose del genere che diventa immediatamente chiaro: no, non puoi lavorare insieme a questa persona. Ecco una selezione di frasi chiave dei candidati che mi allarmano personalmente.

1. “Alcune delle tue domande sono teoriche. Non sono forte in teoria, sono esperto in pratica! Facciamo un test migliore!”

La parola “teorico” viene solitamente pronunciata con una connotazione sprezzante, come se fosse qualcosa di brutto. Ma non è nemmeno questo il problema. Pensi che questa frase sia stata preceduta dalla richiesta dell'intervistatore di dimostrare il teorema di Cauchy? Dare definizione precisa terza forma normale? Affatto. Ho sentito tali esclamazioni in risposta alle seguenti domande:

In che modo il confronto per == è diverso dal confronto per uguali in Java?

dicci come funziona la mappa hash.

Spiega con parole tue cos'è REST.

Cosa sono le transazioni e perché sono necessarie?

Sì, da un certo punto di vista qualsiasi questione di programmazione è teorica se non richiede di scrivere una riga di codice qui e ora. Ma sono sicuro che una persona con un'esperienza sufficientemente vasta in un determinato campo dovrebbe essere in grado di spiegare le cose più basilari con parole sue, o almeno non fingere che ignorarle sia normale e naturale.

2. “Non mi aspettavo l’Inquisizione spagnola qui! È proprio come sostenere un esame all'istituto. Di solito gli chiedono semplicemente dove lavorava e cosa faceva”.

Sei venuto per un colloquio tecnico. In un colloquio tecnico ti verranno poste domande tecniche per testare le tue capacità tecniche. Lascia la metodologia del test e la scelta delle domande alla coscienza dell'intervistatore: le domande potrebbero non sembrarti sempre adeguate, ma l'intervistatore sa esattamente quali informazioni vuole ottenere su di te analizzando le tue risposte. Sono necessarie molte domande non per testare le tue conoscenze, ma per costringerti a pensare e guardare il tuo filo dei pensieri. Ricorda inoltre che non tutte le domande richiedono una risposta perfettamente precisa, e se rispondi in modo chiaro almeno alla metà di quello che ti hanno chiesto, questo farà già una buona impressione.

3. “Non ho bisogno di saperlo, sono specializzato in compiti di livello superiore!”

Non confondere la specializzazione con l'ignoranza delle basi della programmazione. Dagli sviluppatori applicazioni mobili Ho sentito cose simili sui protocolli dello stack TCP/IP da programmatori front-end, in risposta a domande sugli algoritmi di ordinamento e ricerca. "Perché dovrei saperlo, è tutto nella libreria standard, lavoro a un livello superiore." In risposta a tali affermazioni, molto tempo fa ho sollevato un paio di piccoli problemi con algoritmi subdolamente nascosti, nella speranza di dimostrare che una soluzione "ingenua", derivante dall'ignoranza degli algoritmi, non regge alle critiche, e almeno incoraggiare almeno l’autoeducazione. Inoltre, questi non sono compiti costruiti artificialmente, ma cose che accadono ogni giorno nello sviluppo. Qualsiasi codice è un algoritmo. Comprendere gli algoritmi di base e le strutture dei dati è importante per qualsiasi programmatore, e i protocolli Internet sono una base, senza la cui conoscenza è impossibile scrivere con competenza qualcosa che vada oltre i confini di un computer.

4. “E tu stesso! / Mostrami il tuo codice! / Ma sono andato sul tuo GitHub e c'è questo..."

L'ultima cosa che un intervistatore vuole è assumere una persona e poi doverla ascoltare criticare il suo codice di base. Sì, molto probabilmente è imperfetta. Sì, il debito tecnico è ovunque e tutti ce l’hanno. In ogni codice c'è qualcosa da criticare. Ma se ti consideri davvero così bravo da vedere evidenti problemi nel codice dei tuoi potenziali datori di lavoro, traducilo in un positivo costruttivo: so come migliorare, ho esperienza su questo argomento, posso esserti utile.

5. “Hai torto!”

Naturalmente tutto può succedere, ma è meglio mantenere la tua opinione sul fatto che l'intervistatore abbia torto o dubbi sulla sua competenza fino alla fine del colloquio. Quindi cercalo su Google e scopri chi di voi aveva ragione. Un colloquio tecnico non è un luogo di discussione o di autoaffermazione e le domande qui vengono poste principalmente a te. L'intervistatore non chiederà qualcosa che lui stesso non capisce.

Conclusione

Sai qual è la cosa più bella che ho sentito dai candidati durante i colloqui? “Non ho davvero risposto, vero? Puoi darmi un pezzo di carta? Scriverò le tue domande e risolverò la questione a casa, anche se non mi assumerai, almeno lo saprò ora. Lacrime di orgoglio sgorgano nei tuoi occhi: non è stato vano che hai trascorso un'ora e mezza su una persona, lui stesso ha imparato qualcosa da questa intervista. Anche se ora è troppo debole per questa posizione, forse questo lo incoraggerà a istruirsi, e tra un anno o due tornerà, mostrerà il suo lato migliore e troverà un lavoro, come è successo una volta nella mia carriera.

Come succede

Nella maggior parte dei casi, per condurre la valutazione viene invitato un altro specialista con un alto livello di competenza tecnica, il quale, di regola, non capisce nulla delle questioni relative al personale e delle metodologie per raccogliere informazioni sulla personalità di una persona, e un interrogatorio frontale di "chi sa di più” inizia semplicemente. Alcuni intervistatori hanno semplicemente una lista di domande. Molti utilizzano anche la pratica di un compito di prova, che deve essere completato prima di programmare un colloquio di persona. In generale, chi sa fare del suo meglio risolve il problema.

In generale, questo approccio può essere efficace, ma presenta una serie di svantaggi:
1. Esiste la possibilità che lo specialista tecnico intervistatore possa percepire la discrepanza tra l'esperienza del richiedente e la propria come una mancanza di esperienza. Ad esempio, possono essere specificati in modo abbastanza restrittivo domande pratiche, cosa che il richiedente non ha riscontrato nella pratica, che può essere interpretata come “Come fai a non saperlo, è così semplice”. Ma uno specialista delle risorse umane non sarà mai in grado di riconoscerlo a causa delle specificità del contesto.
2. Anche se vengono poste domande aperte come "Quali problemi hai dovuto risolvere?", ancora una volta, la discrepanza nell'esperienza può essere interpretata come "Non è adatto a noi perché non ha fatto quello che facciamo noi per diversi anni" .”
3. Alcuni specialisti tecnici, soprattutto quelli con già molta esperienza, riconoscono poco il fatto che l'ignoranza di strumenti specifici spesso non è un grosso ostacolo. Ad esempio, se una persona non ha lavorato con GIT, ma conosce bene CVS, ciò riduce significativamente la barriera all'ingresso nel possesso dello strumento.
4. Potrebbero sorgere problemi anche quando il richiedente ha una vasta esperienza pratica e risponde bene alle domande soluzioni specifiche, ma quando viene assunto, all'improvviso si scopre che commette errori abbastanza tipici in aree in cui non ha mai lavorato prima. Si ha l'impressione che queste persone "si comportino in modo stupido all'improvviso" o "copino attivamente il codice" dei loro progetti precedenti.
5. A volte ci si imbatte in uno specialista che dà l'impressione di un principiante e il suo curriculum mostra poca esperienza pratica, ma è importante capire se ci riuscirà. Perché se funziona, puoi inserire una buona “stella” nella squadra con un piccolo investimento. E non è chiaro come riconoscerlo nel modo più accurato possibile.

Questi sono solo alcuni degli scenari che si incontrano regolarmente quando si reclutano nuovi tecnici. Intervistare un tecnico è come un compito in cui hai un enorme dipinto nascosto dietro quadrati rotanti che giri uno per uno. E il tuo compito è indovinare l'intera immagine, a condizione che il tuo tempo sia limitato e che il numero di immagini possibili sia enorme.
Per poter filtrare maggiormente questi scenari negativi e condurre interviste con specialisti tecnici in modo più efficace, è possibile utilizzare uno speciale modello di raccolta delle informazioni.

Classificazione della conoscenza

Per prima cosa devi decidere la classificazione della conoscenza. Per fare ciò, devono essere divisi in 3 tipi:
1. Fondamentale- Questo conoscenza di base in un'area specifica. Ad esempio, questa potrebbe essere la domanda "Quali tipi base di query in SQL conosci?"
2. Applicatoè un'abilità per risolvere problemi specifici. Ad esempio, queste potrebbero essere attività attive ortografia corretta Query SQL per esempi specifici.
3. Strumentaleè la conoscenza di come utilizzare strumenti specifici. Ad esempio, qual è la differenza tra i negozi innodb e myisam?

Le conoscenze fondamentali sono necessarie per poterle utilizzare per capire come risolvere al meglio i problemi pratici. I compiti pratici formano la conoscenza applicata, cioè la comprensione di come e cosa è meglio fare. Con la consapevolezza che i problemi individuali si risolvono meglio con l'ausilio di strumenti specifici, si sviluppa anche la conoscenza strumentale. Spesso una persona inizia con qualche piccola pratica, poi studia "perché funziona in questo modo", quindi prova a fare qualcosa di simile e infine affina le sue capacità con l'aiuto di strumenti.
Ad esempio, una persona sviluppa le abilità linguistiche esattamente allo stesso modo: all'inizio cerca semplicemente di ripetere le parole dei suoi genitori singole parole; poi impara l'alfabeto; poi scrive saggi, articoli o lettere commerciali; e talvolta utilizza libri di consultazione e dizionari per questo.

Quando qualcosa è andato storto

Poiché la “formazione accademica” nel campo dell’informatica è ancora piuttosto debole, la maggior parte degli specialisti sono in gran parte autodidatti. Ciò crea alcune deviazioni, che possono essere ben comprese su questo modello se una delle aree della conoscenza è ipertrofica. Ecco i classici ritratti dei candidati e la loro spiegazione:
1. Sa tutto– ha una quantità significativa di conoscenze fondamentali, acquisite ad esempio attraverso alcuni corsi e leggendo libri/articoli, tuttavia non ha abilità pratiche nell'applicarle, il che non lo disturba in alcun modo. Anche se inizi a porgli qualche problema pratico, sentirai sempre molte conoscenze su come dovrebbe funzionare effettivamente, su come sono disposte le singole parti, ma sarà abbastanza difficile per un candidato del genere mettere tutto insieme per risolvere il problema , senza i tuoi consigli. Una situazione abbastanza comune se chiedi a un candidato informazioni sui modelli OOP poco utilizzati: ascolterai una descrizione del modello quando viene utilizzato in qualche esempio accademico, ma l'integrazione in un'attività dal vivo sarà difficile.
2. Sviluppatore StackOverflow– di solito, questi sviluppatori parlano piuttosto attivamente della loro esperienza, di quali problemi e come sono riusciti a risolverli, ma quando cercano di rispondere alla domanda “Come fare...?” da un'area pratica a loro sconosciuta, sentirai o un tentativo di “prendere per le orecchie” un'altra soluzione, oppure una risposta nello stile di “Sì, questo può essere cercato su Google in 5 minuti, l'ho già visto da qualche parte. " Tali sviluppatori spesso cercano di inserire alcune soluzioni già pronte che hanno già realizzato, argomentando come "Perché farlo 2 volte?", oppure semplicemente copiano e incollano codice da Internet e altri progetti. Quando chiedi "Perché funziona in questo modo?" o "Come si può fare diversamente?" spesso può perdersi e provare a tradurre l'argomento.
3. Sviluppatore di strumenti e framework. Mangiare vecchia battuta: “Come iniziare a creare un sito web nel 1995? Apri il blocco note e inizia a scrivere il codice. Come iniziare a creare un sito web nel 2015? Scarica e installa compositore, framework, estensione cms, bootstrap, jquery, bower, less, installa l'IDE, inizia a scrivere il codice. Questo è più o meno lo stesso per questo tipo di specialisti. La maggior parte dell'esperienza applicata di tali specialisti è esclusivamente correlata a uno strumento specifico. Il concetto di “brain bitrix” caratterizza in modo abbastanza specifico questo caso. Per tali candidati è molto difficile assegnare compiti utilizzando il codice "nativo", perché senza uno strumento è un compito quasi impossibile per loro.
Questi esempi sono forniti per i casi in cui una delle aree della conoscenza occupa una posizione di leadership e poiché il sentimento di "superiorità" in quest'area dà origine a un sentimento della propria "grandezza", lo specialista cerca di trattenerla con tutto la sua forza (“tutti vogliono essere cool”). Ad esempio, uno sviluppatore Stackoverflow, quando cerca di scoprire le conoscenze fondamentali, sosterrà fino all'ultimo che "non ho bisogno di saperlo, l'ho già fatto cento volte e tutto ha funzionato".

Come funziona lo sviluppo efficace

Lo scenario più efficace per lo sviluppo della conoscenza è proprio l’equilibrio tra ambiti. Puoi ottenerlo in modi diversi, ma è impossibile consentire “distorsione”. Ad esempio, volevi fare una home page e non ne capivi niente (tutti hanno iniziato con questa): hai scaricato wordpress (hai preso lo “strumento”); Abbiamo cercato su Google come impostare il tutto e creato il nostro primo blog con diversi articoli (conoscenza applicata acquisita); ora scopri come e perché funziona, ad esempio come sono strutturati il database e la cache, qual è l'architettura del motore, ecc. (acquisire conoscenze fondamentali). Quindi puoi vedere quali altri strumenti e come possono risolvere questo problema o scrivere il tuo strumento. Se ti fermi solo al primo o al secondo passaggio, puoi facilmente rientrare in una delle categorie di specialisti sopra indicate e sono sicuro che chiaramente non lo vuoi :)

Come valutare la conoscenza

Sulla base di questo modello, è anche possibile, e abbastanza facilmente, “sondare” gli specialisti tecnici riguardo alla loro strategia di apprendimento e alla misura in cui le loro conoscenze attuali consentono loro di risolvere efficacemente i problemi. La strategia del colloquio è la seguente: dopo aver posto una domanda su un'area tecnica di tuo interesse in qualsiasi area di conoscenza, spostati non "orizzontalmente" all'interno dell'area di conoscenza, ma "verticalmente" in una tipologia adiacente di conoscenza.
Hanno chiesto informazioni sulla conoscenza fondamentale, quindi hanno chiesto quali problemi la persona ha risolto utilizzandola, o hanno posto un problema pratico in cui questa conoscenza sarebbe richiesta, e poi hanno chiesto quali strumenti sono disponibili per utilizzare questa conoscenza e risolvere meglio i problemi pratici.

Per esempio: Cosa sono gli indici b-tree composti e come funzionano? Potete fare un esempio di quando tali indici potrebbero essere richiesti o quando, al contrario, sarebbero inappropriati? Come puoi capire che questi indici funzionano in modo efficace e cosa può essere utilizzato a questo scopo?

Se senti risposte esaurienti a tutte queste domande, significa che lo specialista ha davvero cercato di sviluppare solide conoscenze in quest'area e acquisire tutti i livelli di conoscenza. Ora bisogna trarne le giuste conclusioni. Ciò indicherà che lo specialista ha avuto un'enorme quantità di compiti relativi agli indici o che ha una buona strategia di apprendimento (che non esclude la prima). Per determinare se questa strategia esiste, è sufficiente sondare alcune aree in più in cui il candidato potrebbe non essere così esperto, come spesso si vede dal curriculum;

I candidati forti e promettenti dimostrano che, anche in assenza di conoscenza, capiscono cosa manca e scelgono approccio efficace per compensare la mancanza di conoscenza. Se controlli diverse aree in questo modo noterai che il candidato ha strategia efficace formazione, allora tutto ciò che devi fare è verificare le conoscenze fondamentali richieste per te. Dopotutto, avendoli e la giusta strategia di apprendimento, il candidato sarà, con un alto grado di probabilità, in grado di risolvere nuovi problemi nel modo più efficiente possibile.
Una strategia di apprendimento efficace è una strategia per ricostituire la conoscenza in qualsiasi area di tutti i tipi (fondamentale, applicata, strumentale): provare qualcosa, capire come e perché funziona, fare qualcosa di simile, apprendere gli strumenti per farlo ancora meglio.

Errori tipici di valutazione

Molte persone tendono a sopravvalutare l'importanza della conoscenza applicata in relazione ad altri ambiti, vale a dire che le persone con maggiore esperienza nello svolgimento dei compiti sono buoni specialisti, ma non è assolutamente così. Se la pratica non è supportata da conoscenze fondamentali o lo specialista non ha mai ampliato i suoi strumenti, l'efficacia di tale specialista può essere molto bassa. Cerca chi può sviluppare ogni area. Sono i migliori, anche se non hanno molta esperienza alle spalle.

Spesso puoi trovare attività di test focalizzate solo su questioni fondamentali, come costrutti linguistici, errori tipici quando si utilizza un "comportamento non intuitivo", domande sui modelli OOP, ecc. Come puoi già capire dal modello sopra, non identificherai i “teorici” in questo modo e, inoltre, la conoscenza fondamentale è perfettamente Googleable. Quindi l’efficacia di tali test è relativamente bassa.

C’è anche una convinzione comune secondo cui è importante “capire come pensa una persona”. Indubbiamente, questa è una frase “bella”, ma è molto soggettiva e, di conseguenza, è difficile avere fiducia nel risultato basato su tali valutazioni. Inoltre qui si può cadere nella trappola di una valutazione soggettiva: “non la pensa come me”. Tuttavia, se vedi che una persona sa come formulare efficacemente le sue conoscenze e risolvere i problemi, allora non importa come lo fa esattamente, perché la cosa principale è il risultato.

Se fornisci condizioni di cooperazione interessanti e il flusso di candidati è sufficientemente elevato, redigere compito di prova. Includere diverse domande non da un tipo di conoscenza, ma da diverse. In base alle risposte a queste domande, puoi ottenere un quadro approssimativo di quali siano i punti di forza e di debolezza del candidato.

Cosa cercare

Ci sono diversi punti a cui dovresti prestare attenzione anche durante il colloquio. Si riferiscono maggiormente alla componente del personale, tuttavia compaiono specificamente durante il colloquio tecnico.

Curiosità della mente. Quanto duramente un candidato cerca di risolvere un problema se non conosce subito la soluzione? Sta cercando percorsi alternativi, analizza gli indizi, pone domande e analizza la soluzione proposta. I candidati deboli “saltano” tutto ciò che non riescono a capire.
Sana fiducia in se stessi. In che misura il candidato ammette che potrebbe non sapere qualcosa? A causa della loro educazione, a volte le persone hanno dei complessi riguardo alle proprie conoscenze (“studenti con diploma onorato”, ecc.). A volte queste persone prendono decisioni in modo nettamente categorico e non riconoscono opinioni alternative se indicano una mancanza di conoscenza da parte del candidato.
Il desiderio di auto-sviluppo. I migliori candidati sono coloro che si sforzano di svilupparsi come specialisti o che si sforzano di “rendere il mondo un posto migliore” creando qualche tipo di beneficio. I candidati deboli credono di essere già “al limite delle loro conoscenze” e vogliono semplicemente guadagnare il più possibile da questo. Ci sono anche candidati che credono che il datore di lavoro dovrebbe svilupparli, e non loro stessi, perché è il datore di lavoro che stabilisce i compiti.

Strategia di intervista

Prima del colloquio, fai un elenco delle aree chiave in cui richiedi esperienza da uno specialista. Va bene se ce ne sono almeno 10. Ad esempio: pattern PHP + OOP; SQL + ottimizzazione delle query; architettura di progetti ad alto carico; lavorare con la cache, ecc.
In ogni area chiave, scrivi almeno 5 domande per ogni tipo di conoscenza, per un totale di almeno 15 domande per ogni area. È meglio farlo per non sollevare domande al volo. È auspicabile che tali questioni forniscano una connettività verticale tra loro.

Per esempio:
Regione: architettura di progetti ad alto carico.
Domande fondamentali: Quali parametri principali sono importanti da considerare quando si progettano sistemi ad alto carico? Quali soluzioni architettoniche tipiche conosci? Qual è la differenza tra ridimensionamento orizzontale e verticale?
Domande sull'applicazione: Se gli utenti possono caricare file, qual è il modo migliore per risolvere il problema del ridimensionamento orizzontale per la restituzione? Se hai una pagina con un RPM elevato e un blocco di informazioni che ha a lungo generazione, come puoi accelerare il rendering della pagina? Se un singolo database è diventato un collo di bottiglia in un progetto a causa dell'aumento del carico di lavoro, qual è il modo migliore per affrontare questo problema?
Domande strumentali: Quali strumenti possono essere utilizzati per bilanciare il carico del traffico HTTP? Quali server di cache conosci e quali sono le loro differenze? Come si possono misurare le prestazioni delle applicazioni sotto carichi pesanti?

Inizia con una qualsiasi delle domande di tua scelta. Poni costantemente domande per ciascun tipo di conoscenza nell'area prescelta (in verticale). Se vedi che il candidato ha una padronanza sicura della teoria, della pratica e degli strumenti, allora puoi essere abbastanza sicuro che sarà anche in grado di risolvere con sicurezza i problemi pratici correlati.

Man mano che rispondi alle domande, spostandoti tra le aree, formerai un quadro di come è distribuita la conoscenza del candidato. Ad esempio, potresti accorgerti di una significativa mancanza di conoscenze teoriche o di lacune nella conoscenza degli strumenti. Sulla base di ciò, puoi trarre una conclusione sull'efficacia della strategia di formazione del candidato e delle sue attuali conoscenze in generale. Di norma, la strategia di apprendimento è la stessa per tutte le aree, ovvero è molto raro trovare candidati che conoscano molto bene la teoria in un'area, ma in un'altra abbiano risolto solo problemi pratici e non abbiano nemmeno provato a porre la domanda "Come funziona?"

Bene, allora, a seconda dei requisiti del posto vacante, sarà molto più facile per te prendere una decisione. Cerchi un junior? Assicurati non solo di provare a risolvere problemi pratici, ma anche di reintegrare le conoscenze fondamentali e anche di cercare e apprendere nuovi strumenti. Cerchi una via di mezzo? Assicurati che le sue capacità siano radicate in ogni tipo di conoscenza e che capisca dove andare dopo per colmare le lacune. Cerchi un anziano? Assicurati che abbia un'ottima conoscenza fondamentale e possa effettivamente "assemblare" qualsiasi problema pratico con giustificazioni fondamentali e strumenti adeguati.

Se noti delle lacune nelle conoscenze richieste e non sono fondamentali per te, ma sono comunque importanti, assicurati di scriverle e lavorarci sopra periodo di prova un piano per colmare queste lacune, utilizzandolo durante la certificazione. Ciò ti consentirà di aumentare l’efficacia dei tuoi dipendenti in modo metodico e deliberato. Tuttavia, la questione della formazione e dello sviluppo dei dipendenti è una storia completamente diversa e molto importante.

Dove altro puoi utilizzare il modello?

Il modello proposto, infatti, può essere utilizzato non solo per gli specialisti tecnici, ma per qualsiasi professione in generale. L’unica differenza sarà nel modo in cui determinati tipi di conoscenza vengono realizzati in queste aree. Prendiamo ad esempio il custode: quali criteri di pulizia conosce? Se devi pulire 10 case in un giorno, qual è il modo migliore per farlo? Per quali superfici quali prodotti per la pulizia è meglio utilizzare?

Come conclusione

Recentemente ho deciso di compilare i miei appunti sulle domande dell'intervista per gli sviluppatori PHP e di pubblicarli accesso aperto(il progetto è “in ginocchio”, quindi non biasimatemi). Certo, non è tutto lì, ma è sufficiente raccogliere le idee e prepararsi per il colloquio. Puoi vedere le domande al link:
pagerton.com/hr/question/all
Se ci saranno risposte positive svilupperò il progetto il più possibile, vorrei anche inviare link a buoni corsi per sviluppatori, quindi ve ne sarei grato feedback.
Spero che questo modello possa essere utile anche a te. Non solo come intervistato, ma anche come intervistato, perché comprendere i propri punti di forza e punti deboli ti aiuterà a svilupparti in modo più efficace.
Ti auguro di essere il migliore e di lavorare con i migliori.

Ciao a tutti, Javarashiti! È successo che di recente ho avuto un colloquio e vorrei dirti quali domande mi sono state poste partendo dal presupposto che stavo facendo domanda per la posizione Junior++. Quelli. non ancora una persona di mezzo, ma nemmeno una junior verde. Quindi, l'intervista è andata secondo questo piano

JavaCore
Database.
Gli strumenti che usi.

JavaCore

Per prima cosa mi è stato chiesto di disegnare la gerarchia delle interfacce per le Collezioni (non è stato difficile, ce ne sono solo alcune (Collezione, Elenco, Set, Coda, Mappa).

Qual è la differenza tra ArrayList e LinkedList (questa è una delle domande e risposte più banali su Internet, solo oscurità).

Abbiamo discusso della velocità di esecuzione delle query al loro interno e della differenza tra i fogli.

Domanda sulla classe Object. Quali sono i suoi metodi, cosa fanno?

Riflessione. Cosa fa il metodo getClass(). Molto domanda interessante, smontalo. Soprattutto su come ottenere tutto su una classe, anche se contiene metodi o variabili privati.

Hanno chiesto informazioni sul multithreading. È debole, penso, dirti come capire cos'è il multithreading. Cosa è necessario per iniziare una nuova discussione. Realisticamente, se sei di livello 20+, queste domande ti sembreranno divertenti.

Cosa puoi dire di Stream? Non si tratta di Java 8. Si tratta di flussi di input e output. Come le interfacce di base, cosa sono (carattere e byte). Per capire, nessun dettaglio.

Eccezioni. Anche in questo caso ci è stato chiesto di tracciare una gerarchia di eccezioni, quali tipi esistono, quali sono controllati e quali non sono controllati. Cosa fare con le eccezioni di runtime. Assegna un nome alla NullPointerException più comune.

La domanda è cosa si dovrebbe fare con le eccezioni verificate (avanti ulteriormente o processo: entrambi sono chiari).

Ops

Cos'è l'OOP in poche parole?

Quali altri paradigmi di programmazione esistono? In cosa differiscono dall'OOP?

Quali sono i principi di base dell'OOP (ereditarietà, polimorfismo e incapsulamento)? Raccontaci di ciascuno di essi. Fin qui tutto è astratto, non legato ad alcun linguaggio.

Compito di comprensione della progettazione del sistema: c'è un cavallo e un uccello. Dobbiamo prendere Pegasus. principio "ha un" ed "è un"

RIPOSO

Cos'è il RESTO. Wikipedia ne parla in modo molto freddo. In effetti, è sufficiente un articolo di Wikipedia per conoscerlo.

HTTP. Ci sono anche frasi generali qui. I suoi metodi, a cosa serve ciascuno di essi.

Codici di stato HTTP. In quali dovrebbero essere divise le cinque parti, parlaci di quelle più famose (200.204.404.500.501). Perché lo fanno? Mi hanno chiesto anche del 401 e del 403. Ma non li conoscevo. Dicevano che erano importanti.

Database

Qui ti ho detto che conosco MySQL. Ne ho parlato circa tre forme normali. Ho parlato dei join, di cosa sono e ho disegnato l'intersezione delle aree in cui vengono utilizzati i diversi join. Ho parlato di come intendo un database relazionale. Inoltre, non mi sono dimenticato di MongoDB: questo è un database NoSQL , scriverò anche di questo.

Altri strumenti

Qui abbiamo esaminato il mio curriculum. È stato scritto che utilizzo Maven/Gradle per l'assembly, utilizzo JIRA per le attività, git, Docker, Swagger. Per un'integrazione continua: Stash, Bamboo, Puppet. Per testare JUnit, Mockito, JMeter. Potrei aver dimenticato qualcosa, quindi se ti interessa... chiedi nei commenti Proverò a rispondere. Questa è stata la prima parte dell'intervista. Adesso aspetto i risultati e se sì, allora ci sarà una seconda parte. Ne scriverò al più presto possibile. Chiunque abbia apprezzato l'articolo e lo abbia trovato utile - metta "+". Scrivi nei commenti. Vedi anche gli altri miei articoli:

Su Internet c'è molto materiale dedicato alle interviste ai responsabili delle risorse umane, ma non si dice quasi nulla sulla complessità delle interviste con gli specialisti tecnici. Questo articolo è dedicato alle qualità e alle competenze che un candidato deve avere per superare con successo questa fase e ricevere un'offerta in un'azienda IT.

Dialogo dalla vita:
Candidato: Dobbiamo eseguire l'operazione “A” finché la condizione “B” non è soddisfatta.
Io: Ottimo piano. Implementiamolo.
Il candidato scrive un per ogni ciclo. Anche se è ovvio. Se un candidato supera questo livello, prima o poi diventerà un buon programmatore. Ma qui il 70% dei candidati fallisce.
Bogdan Gusev, stazione di servizio

Correggiamo questo fastidioso malinteso.

while (offerta bool == false)(

Regola 0

Se stai facendo un colloquio per il ruolo di sviluppatore Java, devi avere una buona conoscenza di Java e delle tecnologie correlate

//Non ci sono commenti.

Regola 1

Preparati per il colloquio in anticipo

Scopri in anticipo dal reclutatore tutti i possibili dettagli sul progetto.

Cerca su Google le domande che vengono comunemente poste durante le interviste. Alcuni di loro si incontreranno sicuramente.
Alexander Pitz, responsabile del progetto

Regola 2

Non mentire sul tuo curriculum

Cercare di ingannare esagerando le tue conoscenze è una perdita di tempo per te e per l’azienda. Devi essere in grado di rispondere a domande su tutte le tecnologie elencate nel tuo curriculum.

Un curriculum pieno di parole chiave, di cui non hai una corretta comprensione, rovina le tue possibilità di ricevere un'offerta.

Regola 3

Allinea i tuoi valori con i valori dell'azienda

Ogni azienda ha i suoi valori. Una squadra apprezza la dedizione e l'attenzione ai risultati e, di conseguenza, non disdegna lavoro straordinario. L'altro è innovativo sul lavoro ed è disposto ad apprendere e applicare innovazioni ogni due mesi. Il terzo è affidabilità e stabilità: tecnologie collaudate, persone dedicate che non lasceranno l'azienda se i cookie scompariranno improvvisamente.

Esiste un limite accettabile di discrepanza tra i valori, se superato, molto probabilmente l'azienda deciderà di non presentare un'offerta, anche se il candidato ha l'esperienza necessaria e le conoscenze tecniche necessarie.

Regola 4

Sviluppare capacità di comunicazione

Voglio che il candidato abbia migliori capacità di comunicazione alto livello rispetto a quello di base. Nella nostra epoca di completa agilità, questa qualità viene in primo piano tra le competenze necessarie. Il candidato non dovrebbe avere difficoltà a comunicare con le risorse umane e gli specialisti tecnici, nonché con i clienti.

Regola 5

Migliora il tuo inglese

A differenza dei fallimenti acritici nella conoscenza di qualsiasi tecnologia, non sarai in grado di migliorare le tue abilità linguistiche in un paio di mesi. Ci vogliono anni qui. Pertanto, nella maggior parte dei casi, un livello insufficiente di inglese costituisce un motivo sufficiente per il rifiuto.

Una piccola motivazione: il livello di inglese e lo stipendio dei middle e senior di Kyiv Java e .NET con 3-5 anni di esperienza corrispondono.

Regola 6

Mostra la tua passione per la tua professione

Secondo Bogdan Gusev, il fatto che ti piaccia il tuo lavoro può essere indicato dalla presenza di progetti Open Source, dalla partecipazione a conferenze tematiche e dalla padronanza dell'editor di testo o delle funzionalità IDE. E, naturalmente, interesse per i dettagli ulteriore lavoro. I programmatori indifferenti al proprio lavoro non sono molto richiesti dai datori di lavoro.

Regola 7

Mostra intelligenza e pensiero astratto

Il candidato deve:
- essere in grado di risolvere problemi corrispondenti alla sua posizione;
- conoscere il linguaggio di programmazione e i framework richiesti;
- navigare tra le tecnologie del progetto per il quale viene intervistato.

Se la posizione è poco definita, vengono messe alla prova l’erudizione generale e l’intelligenza, nonché la capacità di pensare in modo strutturale e di trovare soluzioni.

È molto importante dimostrare la capacità di utilizzare le proprie conoscenze. Se conosci approcci e metodi per risolvere i problemi e sai come ottenere le informazioni mancanti, sarai in grado di far fronte ai compiti che riceverai.

Regola 8

Dimostrare il desiderio di acquisire nuove conoscenze

A volte un candidato dirà: “Ho studiato la tecnologia X e voglio solo lavorarci. Perché dovrei studiare la tecnologia Y se conosco la X?” Le possibilità che un candidato del genere riceva un'offerta sono drasticamente ridotte. Le tecnologie sono solo strumenti. Dopo qualche tempo X diventerà irrilevante, e con esso lo specialista stesso, che solo lo sa.
Maxim Kovtun, Architetto di soluzioni

Regola 9

Mostra l'orientamento ai risultati

Valuto:
- la capacità di scendere a compromessi con le proprie “credenze religiose” (ad esempio, se un rilascio lo richiede, utilizzare una “hot fix” piuttosto che affrontare la soluzione in modo fondamentale);
- la capacità di insistere per conto proprio quando necessario;
- e ancora più importante - la capacità di mantenere il giusto equilibrio tra i due punti sopra indicati.
Andrey Mudry, responsabile del progetto

Regola 10

Non dire "non lo so"

Eccezione: se non hai mai lavorato con questa tecnologia e non è elencata nel tuo curriculum. In questo caso è meglio essere onesti e chiedere all’intervistatore di spiegarti la risposta corretta.

Se non capisci di cosa stiamo parlando fai una domanda chiarificatrice.

Se la domanda è specifica e non sei sicuro della risposta, dovresti ammetterlo ed assicurarti di fare ipotesi basate sulla tua esperienza. Spiega il tuo processo di pensiero. Se la domanda è aperta, non esiste un'unica risposta corretta.

La risposta peggiore è il silenzio o “non lo so”. Devi provare a risolvere il problema, non importa quanto stupida possa sembrare la tua soluzione. Anche la risposta più ingenua è meglio di niente. Due o tre opzioni di risposta sono generalmente ottime. Completa queste risposte con considerazioni sulla loro applicabilità e domande aggiuntive per chiarire il problema - e sarà fantastico.
Alexey Kolupaev, stazione di servizio

Regola 11

Non essere timido nell’imparare anche durante un colloquio.

È impossibile sapere tutto. Una volta ho lavorato a un progetto che richiedeva la conoscenza di uno stack tecnologico e di una cartografia piuttosto specifici. L'esperienza ha dimostrato che pochi programmatori sono in grado di convertire la classica notazione delle coordinate da WGS84 alla notazione decimale. In questi casi, penso che una buona risposta in un’intervista sia la domanda: “Posso guardare su Google?”
Artem Polyukhovich, direttore tecnico

Regola 12

Pensa a quello che dici in risposta

Non devi fingere di essere mentalmente attivo per un minuto, ma cerca di pensare al problema nel modo più ampio possibile. Inoltre, durante le interviste ci sono spesso domande trabocchetto.

Va bene se il candidato cerca di "dedurre" la risposta corretta alla domanda. Non indovina, ma utilizza le sue conoscenze esistenti, nonché logica, intelligenza, intraprendenza e capacità di prendere rapidamente decisioni sotto pressione. Questa qualità è molto utile in un approccio di sviluppo flessibile, quando il cliente lo richiede soluzione rapida problemi, a volte anche durante una conferenza online.
Sergey Chirkov, responsabile del progetto

Regola 13

Ammetti gli errori che hai commesso

La capacità di analizzare e ammettere i propri errori indica che sarai interessato sia al tuo sviluppo professionale che al risultato di un lavoro specifico.

Regola 14

Non rovinare la tua reputazione

Una risposta imprudente alla domanda "Perché hai lasciato questa o quella compagnia?", la disorganizzazione, il ritardo per un colloquio senza preavviso o il rifiuto di completare un compito di prova possono rovinare un'opinione su di te.

Regola 15

Costruisci una partnership con l'intervistatore

Mi sembra che nell'espressione “rapporto di lavoro” molti si concentrino su “lavoro”, ma dovrebbero mettere più enfasi su “relazioni”. In questo senso, un colloquio è simile a un appuntamento: entrambi vi guardate più da vicino, scoprite se starete bene insieme. E quando qualcuno si sforza di sembrare migliore di quello che è, può essere irritante. A volte un candidato può essere così accattivante che è facile chiudere un occhio anche di fronte a carenze gravi.
Alexey Kolupaev, stazione di servizio

Regola 16

Comportarsi correttamente

“Correttamente” significa educatamente, rispettosamente. L'arroganza, l'ingraziamento o l'adulazione nei confronti dell'intervistatore non faranno altro che rovinare l'impressione. Anche l'umorismo non è sempre appropriato.

È possibile identificare diversi modelli di comportamento falliti:
Amico- sposta la conversazione a un livello informale per evitare risposte specifiche a domande specifiche.
conquistatore- prende l'iniziativa nelle proprie mani, parla a voce alta e molto e non permette che vengano poste domande.
Pigro- dopo un'ora di colloquio, mostra di provare un vero tormento - è improbabile che una persona del genere sia in grado di lavorare intensamente per più di 1 ora al giorno.
architetto- crea un gran numero di classi inutili prima di delineare un piano di soluzione. Di conseguenza, esso stesso non può trarre vantaggio dalla propria “architettura”.
teorico- il tipo più pericoloso, pronto a comunicare su qualsiasi argomento, purché non sia costretto a mostrare conoscenze pratiche. Può facilmente descrivere un algoritmo risolutivo, ma non è in grado di programmarlo.

Quest’ultimo è facilmente determinabile dal seguente dialogo:
Io: porta il tuo portatile al colloquio
Candidato: Perché?

Dopo un simile dialogo, è immediatamente chiaro che il candidato crede che la cosa principale nell'essere un programmatore sia parlare di tecnologie interessanti in cucina. Non sa che programmare su una tastiera familiare è molto più semplice che su una straniera. Di conseguenza, ci dedica poco tempo. Mi chiedo come sta andando la sua giornata lavorativa?
Bogdan Gusev, stazione di servizio

Regola 17

Sii adeguato :)

L’adeguatezza è un concetto abbastanza ampio. Prima di tutto, include una reazione a situazioni difficili. Cosa fa una persona di fronte a un pezzo di codice incomprensibile o a un algoritmo complesso? Come si comporterà con i colleghi quando avrà bisogno di qualcosa da loro (o ne avrà bisogno)? Cosa fa se sorge un conflitto di interessi? Cosa succede se gli viene assegnato un compito impossibile o difficile?
Artem Polyukhovich, direttore tecnico

Regola 18

Sii ottimista

Atteggiamento positivo - molto qualità utile. È molto più piacevole lavorare con una persona che sa notare i momenti positivi nella vita, nel lavoro, in ogni cosa.

Regola 19

Sentiti libero

Un colloquio è una discussione tra due specialisti alla pari. Pertanto, la rigidità è più un aspetto negativo che un vantaggio. Ti impedirà di esprimerti al livello adeguato.

Ma anche troppa fiducia in se stessi è un aspetto negativo. Un monologo di 20 minuti senza interruzioni può servire come motivo di rifiuto.

Comportati in modo naturale, non essere timido. Ad esempio, se trovi più semplice elaborare le informazioni visivamente, non aver paura di chiedere carta e penna.

Regola 20

Se fallisci, impara dai tuoi errori

Pensa al colloquio come a un'opportunità per imparare qualcosa di nuovo e ottenere feedback. Ciò sarà vantaggioso anche se non ricevi un'offerta di lavoro.
Alexander Kaganovsky, stazione di servizio

Le interviste sono in cima alla lista delle più grandi paure della maggior parte delle persone, insieme a parlare in pubblico. Non solo ti esibisci davanti a qualcuno, ma vieni anche costantemente valutato per tutto il tempo... brrrr!

Naturalmente, siamo lontani dal cercare di comprendere e superare le tue barriere psicologiche, ma è sicuramente meglio vedere le interviste come un'opportunità per mostrare tutte le cose interessanti che hai creato e tutte le nuove abilità interessanti che hai imparato. Le migliori interviste- queste sono conversazioni entusiastiche con un taglio tecnico.

Il primo passo prima di tutto questo è la preparazione. Ti consigliamo di pensare alle possibili domande (e alle risposte più comuni che mettono in risalto la tua genialità) e ricercare l'azienda assumente. La tua conoscenza dell'azienda ti aiuterà a presentarti in un modo adatto alle loro esigenze e ti consentirà anche di porre domande intelligenti sui loro prodotti e tecnologie quando sarà il momento. Ancora una volta, fate riferimento all'articolo di Happy Bear per consigli pratici.

Cos'è l'intero processo?

Basta dare una rapida occhiata al processo che l'azienda tecnologica media segue quando assume sviluppatori:

Colloquio preliminare telefonico (Phone Screen)
Colloquio tecnico
Testare i termini di riferimento
Interviste di follow-up per garantire che tu sia adatto (Interviste di idoneità)
Offerta di lavoro
Discussione dei termini dell'offerta (Negoziazione dell'offerta)
Accettazione dell'offerta

Colloquio telefonico preliminare

Congratulazioni! Il tuo curriculum si è rivelato non dei più disastrosi e sei stato invitato per un colloquio telefonico (nota che a volte svolgi prima un compito di prova). Il vero scopo di questo passaggio, che spesso prevede una conversazione di mezz'ora con qualcuno delle risorse umane (piuttosto che con il decisore per l'assunzione), è quello di assicurarsi di avere buone possibilità di superare il resto del processo di colloquio. Quindi consideralo come una versione più leggera degli altri passaggi.

Probabilmente ti verranno chieste alcune delle cose tecniche che inserisci nel tuo curriculum, ma non andare troppo in profondità (anche se alcuni datori di lavoro fanno alcune domande piuttosto complicate), e probabilmente ti verranno poste alcune domande "più morbide" su perché hai scelto questo lavoro e cosa hai fatto prima. Le interviste telefoniche possono variare notevolmente da azienda ad azienda. La tattica principale qui non è affatto una tattica, sii solo onesto, energico e aperto. E non aver paura di esercitarti a parlare di te stesso davanti allo specchio.

UNA NOTA FINALE - Questo non è un metodo valido per tutti e molte aziende lo saltano preferendo immergersi direttamente nelle profondità di un colloquio tecnico, quindi è necessario prepararsi per ogni evenienza. Il collegamento sottostante a Coding Horror è il più illustrativo di questo caso.

Ottieni l'eccellenza nelle interviste telefoniche con Monster
7 passaggi per raggiungere l'eccellenza nelle interviste telefoniche

Colloquio tecnico

Il colloquio tecnico è solitamente la parte più spaventosa del processo di selezione. Qui valuteranno se possiedi le competenze tecniche richieste. Ciò significa che non solo ti chiederanno dettagliatamente del tuo lavoro, ma ti chiederanno anche di decidere problemi logici oppure scrivi il codice direttamente lì o abbozza un diagramma di alcuni nuovi componenti.

In effetti, uno degli scopi di un colloquio del genere è portarti al limite massimo delle tue capacità, solo per vedere come reagisci a cose non familiari. Se fai un esercizio troppo facile, passeranno a qualcosa di molto più difficile. Ci saranno sempre posti in cui inciampare, soprattutto per i principianti. La tua più grande risorsa è la tua onestà e curiosità.

Quando risolvi un problema, assicurati di farlo in modo chiaro e logico, spiegando ad alta voce perché stai eseguendo un determinato passaggio. Parla di tutti gli ostacoli che hai incontrato e fornisci esempi di come li risolveresti in " mondo reale". Spesso la risposta è "Google" alcuni funzione specifica. Dillo così! Sanno che non sei un esperto di Ruby, ma devono anche sapere che puoi trovare soluzioni ai problemi che inevitabilmente incontrerai sul lavoro.

È anche del tutto normale se usi la forza bruta, un metodo inefficiente, per risolvere un problema di codifica. Questo è spesso il miglior punto di partenza per avere un'idea corretta del problema. Molto probabilmente ti verrà chiesto come puoi migliorare la soluzione, ma questo è molto meglio che cercare di trovare la soluzione perfetta e non avere il tempo di scrivere nulla alla fine. Ancora una volta, il tuo compito non è quello di essere un candidato eccezionale, ma di dimostrare che sei adattabile e resiliente di fronte alle sfide.

E se non sai qualcosa, è meglio dirlo onestamente e provare a rifletterci con l'intervistatore. Credimi, vogliono che tu abbia successo tanto quanto te, perché non c'è niente di peggio per un intervistatore che vedere qualcuno che cerca silenziosamente di risolvere un problema, rimanendo sempre più bloccato senza chiedere aiuto e senza far sapere a nessuno cosa stava facendo. pensiero.

Dovrai leggere grandi quantità cose che non erano state enfatizzate nei corsi precedenti, ad esempio, strutture dati e algoritmi, semplicemente perché sono domande molto popolari al riguardo nelle interviste. Non sempre riflettono bene le capacità di programmazione, ma capita che dovrai rispondere a domande che rientrano in un'area più accademica della conoscenza informatica.

Collegamenti

Diamo un'occhiata all'intervista per i programmatori: DEVE LEGGERE IL MATERIALE chi sarà tuo migliore amico. Dà uno sguardo completo a tutti i tipi di sfide che dovrai affrontare in un colloquio. Va oltre ciò che abbiamo già trattato in questo corso e tocca cose che è bene sapere perché è probabile che le incontrerai. Prendetevi il tempo per conoscerne quanti più possibile un gran numero materiale.
Interviewing.io ti dà la possibilità di praticare interviste tecniche in modo anonimo e online.
Come ottenere un punteggio perfetto in un colloquio tecnico
Come distinguersi nel prossimo colloquio di lavoro da sviluppatore web
Leggi 40 concetti chiave dell'informatica spiegati in un linguaggio di facile comprensione
Guida alle competenze tecniche di Google(per avanzato)

Attività di test di programmazione:

8 regine è un problema classico.
Programmazione per le interviste: conoscere le librerie standard può essere eccessivo per un principiante, ma non fa mai male se ti prendi il tempo per farlo.
Nel Progetto Euler troverai problemi più generali e complessi che devono essere risolti in modo efficiente (potrebbero richiedere molti calcoli).
Le domande pratiche per Java e Python sono pubblicate su Coding Bat.

Addestramento dell'algoritmo:

Corso di algoritmi di Udacity (non sincronizzato)
Corso di algoritmi di Coursera (parzialmente sincronizzato)

Architettura:

Compito di prova tecnica

Test compiti a casa può avvenire prima o dopo un colloquio personale, a seconda dell'azienda. Ti verrà assegnato un compito che richiederà un'intera giornata per essere completato in qualsiasi momento conveniente per te. Esempi di tale compito potrebbero essere la creazione di un'applicazione Web di esempio con test o la risoluzione di un problema algoritmico complesso con la scrittura di codice.

La valutazione si baserà sulla completezza della soluzione e sulla qualità del tuo codice. Se ciò avviene prima del colloquio tecnico, allora lo è buon metodo verifica il tuo interesse (fino alla metà dei candidati non torna nemmeno con una soluzione).

Colloquio finale (“Idoneità”)

L’ultimo passo prima di prendere una decisione è solitamente conoscere per qualche ora il team e gli uffici. Potresti essere messo alla prova tecnicamente, ma l'obiettivo principale è assicurarti che sarai un buon collega. Se qualche altro membro del team dice che non lavorerai bene, molto probabilmente non ti assumeranno. Consiglio? Non c'è bisogno di essere strani o imbarazzanti, anche se sei a casa :)

Questa è anche un'opportunità per te. Se sei arrivato fin qui per arrivare a questo passaggio, ci sono buone probabilità che tu sia generalmente idoneo. Devi pensare se vuoi lavorare per questa azienda, quindi prepara un elenco di domande e ottieni le risposte.

Un po' di salari

Non. Esprimilo. Il tuo. Stipendi. Aspettative.

Ti verrà sempre chiesto “quanto vorresti ricevere?” La tua risposta? “Vorrei essere pagato al prezzo medio di mercato” (a meno che tu non sia così arrogante da chiedere un prezzo superiore al prezzo di mercato. Vediamo come funziona per te). Non otterrai nulla nominando il livello di stipendio desiderato. Se risulta essere inferiore a quello che volevano offrirti, abbasseranno semplicemente questo livello. E se è più alto, interromperanno semplicemente l'intero processo, decidendo che sei troppo costoso per loro.

Una volta ricevuta un'offerta, puoi verificare come si confronta con la retribuzione media di mercato chiedendo ad alcune persone (si spera che tu conosca già alcune persone a cui chiedere) o andando su Glassdoor (ricorda solo che sei un principiante, il che significa che puoi non riceverà uno stipendio “medio”). La cosa più importante è non farti del male quando ti viene chiesto.