Che cosa fa la differenza tra "Noleggio" e un "quasi" onesto per le interviste finali sul posto? [chiuso]

9

Quindi, di recente ho avuto interviste sul posto con Google e Amazon e ho ricevuto lettere di rifiuto educate che mi informavano che ero vicino, ma non del tutto corretto per le competenze che stavano cercando.

Sono arrivato al round finale per tutte le interviste che ho fatto (ad eccezione di alcune offerte da posizioni poco interessanti che ho intervistato per la pratica), ma finora ho 5-8 interviste in un giorno abbastanza tempo per fare in modo che i miei errori si sommano quanto basta per mettermi fuori gioco.

So che ho fatto bene almeno sulle domande di codifica e su altre domande tecniche generali, apparentemente non sono bravo a progettare cose OOP come giochi di carte o parcheggi (mi sono tuffato troppo in profondità in un oggetto e ho consumato tutto il mio il tempo, invece di essere più ampio) e le mie risposte di codice anche se funzionano in generale non hanno avuto alcuni bug / casi limite che mi sono sfuggiti (come un caso in cui un nodo di input potrebbe effettivamente essere la risposta piuttosto che dover essere distinti). E non ho problemi a dire "Non lo so", ma forse sto vagando un po 'e devo dire che per le domande penso di poter rispondere, ma non posso dare una risposta nitida a ...

Quindi, quali sono le cose che ti spingono al di là dell'essere bravi, ma non del tutto a "Assumere"?

Qualche consiglio su ciò che cerchi o qualcosa che sai che ti ha dato quel piccolo extra in più?

    
posta Joshua Olson 04.06.2011 - 08:40
fonte

6 risposte

9

Prima di tutto, ti suggerisco di contattare il rappresentante delle risorse umane presso entrambe le società e chiedere se possono fornirti dettagli sul "perché". È molto probabile che siano in grado di darti qualche suggerimento su dove hai sbagliato o su quali cose dovresti lavorare.

In secondo luogo, non mollare! Se vuoi davvero lavorare per una di queste aziende, aspetta qualche mese, forse un anno e fai domanda per un altro lavoro. Potrebbe essere che non ti sei "gelificato" con un particolare intervistatore e se hai un colloquio con qualcun altro, ti diranno "assumi".

Infine, se pensi di aver fatto bene in termini di risposte tecniche, allora un aspetto importante che stanno cercando è se tu sia o meno un adattamento "culturale". Ovvero, se hai intenzione di adattarsi al resto della squadra e se la tua personalità è una buona partita. Cerca la cultura dell'azienda e decidi se è qualcosa che ritieni di poter soddisfare e assicurati di dimostrarlo anche nell'intervista.

Buona fortuna e non arrenderti!

    
risposta data 04.06.2011 - 09:24
fonte
3

Come ha detto Dean, ti stai valutando su più attributi e questi di solito sono:

  • Abilità tecniche
  • Se vuoi entrare nel team
  • Processo di pensiero
  • ecc.

Le abilità tecniche richieste per il ruolo variano a seconda del team con cui stai intervistando, quindi se non funziona con una squadra, potresti (a seconda della compagnia) riapplicare e trovare una soluzione migliore con un'altra squadra. Quindi non perdere la speranza!

La maggior parte delle abilità tecniche viene solitamente testata con problemi di codifica. Hai accennato al fatto che ti è sfuggito un caso di confine e che alcuni bug si sono insinuati (come fanno inevitabilmente quando viene richiesto di scrivere codice su una lavagna). Un buon approccio per rispondere a queste domande di codifica è quello di fare quanto segue:

  • Capisci cosa viene chiesto (chiedi di ripetere alcune parti se necessario)
  • Chiedere chiarimenti alle domande (iterativamente / ricorsivamente, esistono vincoli specifici ?, quale lingua? ecc.)
  • Identifica strutture dati appropriate, algoritmi, modelli di progettazione che possono essere utilizzati ( Interviste di programmazione esposte e Programmare perle sono utili per questo)
  • Scrivi il codice, mentre spiega ad alta voce all'intervista quale è il tuo processo di pensiero . Se l'intervistatore sa cosa stai pensando, potrebbe essere in grado di identificare i problemi nel tuo approccio in anticipo e guidarti verso una soluzione migliore.
  • Prima di dire all'intervistatore che sei completo, pensa e spiega all'intervistatore come testare il software che hai appena scritto. Pensa a casi semplici, casi limite, concorrenza, se l'approccio ha senso per altre culture, implicazioni sulla sicurezza, stress test, ecc.

Infine ammettere che non sai che qualcosa è (IMHO) preferibile inciampare nel tentativo di fingere. Certo, l'intervista ti chiede di risolvere un problema, ma se non sai da dove cominciare, ti consiglio di parlare degli approcci validi e di cercare di restringere quello corretto che risolve i contrari dati. Se non sapete da dove cominciare, potrebbe essere il momento di spiegarlo (questo si lega anche al modo in cui vi adattate al team. Direi che è meglio chiedere una guida anticipata). Quindi non penso che affermare di non sapere sia una cosa brutta (supponendo che non sia tutto ciò che viene detto =])

Non c'è proprio molto che si possa fare per adattarsi, come spesso si arriva a un'opinione personale dell'intervistatore, ma conversare con l'intervistatore su ciò che stai pensando è preferibile codificare in silenzio per 15 minuti e quindi dichiarando "I'm finished".

Ricorda che queste cose sono solitamente un colloquio bidirezionale . Non ti stanno solo intervistando, ma li stai anche intervistando. Sentiti libero di porre domande sul lavoro / squadra / azienda.

Infine, i Microsoft reclutatori pubblicano abbastanza informazioni su ciò che stanno cercando durante una schermata / intervista sul telefono, quindi mi sono raccomandato avere una lettura Inoltre GlassDoor ha molte informazioni sui processi di intervista per le aziende (ma le risposte inviate dall'utente non sono sempre corrette). Anche una ricerca su google per MS / Google / Amazon / Apple / etc intervista produrrà risultati.

Buona fortuna.

    
risposta data 04.06.2011 - 12:39
fonte
3

Questo può sembrare elitario, ma la verità brutale è che potrebbe non esserci nulla che potresti aver fatto per essere assunto. Stanno cercando un certo talento e non tutti ce l'hanno. Accettiamo questo fatto difficile nelle arti dello spettacolo - non importa quanto alcune persone praticano, non potranno essere assoldate alla Filarmonica di New York. Un dottorato in inglese non ti consentirà di scrivere un grande romanzo. Questo vale anche per i team di élite del software. Non intervistano per trovare persone che conoscono una tecnologia specifica. Intervistano per trovare persone che si adattano: persone con una visione profonda della programmazione, che possono tenere il passo con il team, seguire discussioni tecniche in rapido movimento, prendere nuove lingue, introdurre nuove idee, creare nuove tecnologie.

==== 3/7/2014 ====

Questa intervista con Laszlo Bock sembra essere d'accordo. A Google non interessano i gradi, i voti o i punteggi dei test:

One of the things we’ve seen from all our data crunching is that G.P.A.’s are worthless as a criteria for hiring, and test scores are worthless — no correlation at all except for brand-new college grads, where there’s a slight correlation. Google famously used to ask everyone for a transcript and G.P.A.’s and test scores, but we don’t anymore, unless you’re just a few years out of school. We found that they don’t predict anything. ... There are five hiring attributes we have across the company. If it’s a technical role, we assess your coding ability, and half the roles in the company are technical roles. For every job, though, the No. 1 thing we look for is general cognitive ability, and it’s not I.Q. It’s learning ability. It’s the ability to process on the fly. It’s the ability to pull together disparate bits of information. We assess that using structured behavioral interviews that we validate to make sure they’re predictive.

    
risposta data 04.06.2011 - 22:22
fonte
1

Sembra che tu abbia già identificato alcune aree in cui puoi migliorare.

Combinando questi aspetti con la tua domanda precedente , senza sapere altro su di te, ti consiglierei qualche sforzo su il lato engineering , essendo in grado di progettare software pratico e comunicare chiaramente quel progetto. Piuttosto che imparare più teorie di CS, leggi alcuni libri come Perla di programmazione , Rifattorizzazione , Standard di codifica C ++ e Codice completo . Se uno dei lavori "non interessanti" ti dà la responsabilità di progettare software reale, prendi il lavoro e rendilo interessante. Nel mondo reale, ti senti spesso questo ragazzo , ma può comunque essere molto soddisfacente sapere che hai affrontato un problema difficile, anche se potrebbe essere in una banale applicazione.

    
risposta data 04.06.2011 - 10:12
fonte
1

Ok, solo per fare un po 'di esperienza pratica qui.

Lavoro per una di queste ditte di software d'élite, e non trovo che le nostre politiche di assunzione siano orientate a "non perdere" un grande talento ma a "non assumere" un talento mediocre. Ho visto che alcune di queste aziende vogliono davvero assumere persone fantastiche, ma lo fanno intervistando molti sviluppatori (su carta) davvero di bell'aspetto e cercando di eliminare quelli che non vogliono. Una volta che qualcuno viene assunto, è molto difficile sbarazzarsi di loro, quindi vale la pena di rifiutare un candidato che si ritiene possa essere una buona idea, ma che uno degli intervistatori ha visto alcune bandiere rosse.

Alla società per cui lavoro attualmente, sono stato rifiutato perché uno e solo uno degli intervistatori (il più importante) mi ha dato un pollice in giù. Questo intervistatore mi ha fatto una domanda molto specifica e non parlava inglese fluente. Non mi hanno assunto, ma il team ha pensato che la compagnia avrebbe perso un noleggio potenzialmente buono. Mi hanno mandato in un'altra serie di interviste con una squadra diversa la prossima settimana e ho ottenuto il lavoro (con i "forti assegni" che potrei aggiungere).

Il mio consiglio è che se davvero credi di avere quello che serve, continua a fare interviste con questa compagnia e impara da ogni esperienza fino a che non arrivi a destinazione. La maggior parte di queste aziende tiene un registro di tutti quelli che intervistano e fa una lista nera dei candidati poveri (in modo che non ottengano mai un altro colpo). Tuttavia, i candidati che erano buoni candidati ma che non si sono comportati bene quel giorno, o non si sono adattati bene alla squadra, rimarranno nel pool di assunzioni. Saprai immediatamente se sei stato inserito nella lista nera quando il telefono del reclutatore si ferma appena un giorno e ogni contatto futuro sembra non udire. Se ricevi richieste future dall'azienda, sai che stai bene. Non c'è assolutamente alcun danno nel creare più interviste dopo il tuo primo rifiuto fino a quando non sei stato elencato in nero. In effetti, raccomanderei vivamente di intervistare con più team contemporaneamente. Gli intervistatori ti rifiuteranno al primo segno di disturbo percepito, indipendentemente dal fatto che sia un vero problema. Sono cauti e non vogliono fare brutte assunzioni molto più di quanto vogliano fare dei buoni assunti.

Alcuni altri pensieri:

- Nessuna di queste società ti darà feedback. È una responsabilità legale. Fa schifo che sia così com'è, ma posso prometterti che non succederà.

- Ho parlato personalmente con un ingegnere geniale quando ho intervistato Microsoft che mi ha detto che gli ci sono voluti più di 5 tentativi prima che venisse assunto. Questo ragazzo era un SDE di livello senior, quindi MSFT ovviamente convalidato che era un buon noleggio promuovendolo.

Alcuni suggerimenti:

Conoscere le strutture dati e gli algoritmi avanti e indietro. Devi conoscere tutto fino al grafico degli attraversamenti.

Conoscenza dell'architettura, in particolare dei sistemi distribuiti e problemi di scala

Fai memorizzare un elenco di progetti che hai guidato. Avere un elenco con esempi di principi di leadership che hai esposto nel tuo lavoro memorizzato. Queste sono le domande più difficili da rispondere nell'intervista (interviste comportamentali). Puoi essere perfetto nel lato tecnico e se non sopravvivi al colloquio comportamentale non sarai assunto.

Non preoccuparti dei linguaggi di programmazione che stanno cercando. Conoscenza di un linguaggio orientato agli oggetti avanti e indietro e codice in questo. L'intervistatore di solito non si cura di quale lingua si codifica e non ti giudica in base ad esso.

Infine, per favore mandami una email con il tuo curriculum. ; =)

    
risposta data 07.03.2014 - 19:07
fonte
0

Non necessariamente lo ha mancato essendo sbagliato

Forse non hai fatto nulla di sbagliato, ma qualcun altro ha fatto di meglio. Forse in termini di personalità, capacità comunicative, interrelazioni, esperienze passate simili del progetto ecc.

Potresti essere stato giusto per essere assunto ma non era solo tu nella lista. Non mi preoccuperei troppo. Tutto accade per uno scopo.

    
risposta data 04.06.2011 - 23:19
fonte

Leggi altre domande sui tag