Cosa fa la differenza tra "Assumi" e un onesto "quasi" per le interviste finali sul posto? [chiuso]


9

Quindi, recentemente ho avuto interviste in loco con Google e Amazon e ho ricevuto lettere di rifiuto educate che mi facevano sapere che ero vicino, ma non del tutto giusto per le competenze che stavano cercando.

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

So di aver fatto bene lì almeno sulle domande sulla codifica e su altre domande tecniche generali, apparentemente sono cattivo nel progettare cose OOP come giochi di carte o parcheggi garage (mi sono tuffato troppo in profondità in un oggetto e ho usato tutto il mio tempo, invece di essere più ampio) e le mie risposte al codice sebbene funzionino nel complesso non avevano alcuni bug / casi limite che mi mancavano (come un caso in cui un nodo di input potrebbe effettivamente essere la risposta piuttosto che dover essere distinto). E non ho problemi a dire "Non lo so", ma forse sto vagando un po 'e devo dirlo per domande a cui penso di poter rispondere, ma non posso dare una risposta nitida a ...

Quindi, quali sono le cose che ti spingono oltre ad essere buono, ma non abbastanza da "assumere"?

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


Solo per notare che sono candidato per nuove posizioni di laurea (o approssimativamente lo stesso livello di esperienza).
Joshua Olson,

2
La prima cosa da fare è lavorare sul tuo inglese. Presumibilmente non è la tua lingua madre, ma comunque tutti i grandi programmatori che ho conosciuto si sono preoccupati di parlare e scrivere con precisione. Non è "ottenuto", ma "ottenuto" o "ottenuto" o "ricevuto". Non "interviste" ma "interviste". "Immergiti profondamente", non "immergiti in profondità".
Kevin Cline,

Ouch, un paio di colloqui e errori di battitura e "presumibilmente non è la tua lingua madre". Fa male. : P Va bene, ho corretto i miei errori di ghrammer.
Joshua Olson,

2
Un colloquio è un incontro.
Kevin Cline il

Colloquiale. Stupido controllo ortografico.
Joshua Olson,

Risposte:


9

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

Secondo, non arrenderti! Se vuoi davvero lavorare per una di queste aziende, aspetta qualche mese, forse un anno e fai domanda per un lavoro diverso. È possibile che tu non abbia "gelato" con un particolare intervistatore e se hai un'intervista con qualcun altro, loro diranno "assumere".

Infine, se pensi di aver fatto bene in termini di risposte tecniche, un aspetto importante che stanno cercando è se sei o meno una persona "culturale". Cioè, se hai intenzione di adattarti al resto della squadra e se la tua personalità è una buona partita. Fai una ricerca sulla cultura dell'azienda e decidi se è qualcosa in cui pensi di poter entrare e assicurati di dimostrarlo anche nell'intervista.

Buona fortuna e non mollare!


Sfortunatamente il mio reclutatore di Google aveva una rigorosa politica di non feedback (continuava a dire che era una politica, ma so che le persone hanno ricevuto "suggerimenti" su cosa lavorare).
Joshua Olson,

1
Ho notato che tutti in Amazon continuavano a parlare di appropriazione, quindi suppongo che avrei dovuto approfondire quell'aspetto.
Joshua Olson,

1
Questa è una buona risposta ... Aggiungerei due cose: in primo luogo , cerca di imparare a leggere il tono generale delle domande. Se hai diverse domande sulla "proprietà", allora potrebbero avere paura che tu possa entrare e che tu abbia bisogno di una guida eccessiva o che stia sempre riflettendo sul tema "Non è il mio lavoro". In secondo luogo , potrebbe davvero essere il caso che tu possa lavorare in azienda, ma non era la soluzione migliore per quella squadra. Qui, tutto può avere un impatto. Forse era tra te e un altro ragazzo, ma all'altro ragazzo piaceva il punk rock e la mountain bike, proprio come la metà della squadra.
terra rossa

Amazon non mi ha detto nessun feedback. Che tipo di schifo perché sono sicuro che avrebbero avuto un ottimo riscontro ...
Cervo,

No. Amazon non fornisce feedback né MSFT. Ho avuto esperienze simili. Google fornisce comunque un feedback completo quando vai all'intervista in casa. Ho anche la stessa esperienza di fallimento in tutti i grandi 3 interni. Le conoscenze che ho acquisito da loro sono piuttosto significative. Oltre al tuo set di abilità e alle tue prestazioni, attribuisce anche un po 'di fortuna. Migliora il tuo set di abilità e riprendi la battaglia e ricorda sempre Robert Bruce e il ragno: D
Venki

3

Come diceva Dean, vieni valutato su più attributi e questi sono di solito:

  • Abilità tecniche
  • Se ti adatteresti alla squadra
  • Processo di pensiero
  • eccetera.

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

La maggior parte delle competenze tecniche viene generalmente testata con problemi di codifica. Hai detto che occasionalmente ti sei perso un caso limite e che alcuni bug si sono introdotti (come inevitabilmente quando viene chiesto di scrivere un codice su una lavagna). Un buon approccio per rispondere a queste domande di codifica è quello di fare quanto segue:

  • Comprendi cosa ti viene chiesto (chiedi di ripetere alcune parti se necessario)
  • Poni domande chiare (iterativamente / ricorsivamente, esistono vincoli specifici ?, quale lingua? Ecc.)
  • Identificare strutture dati appropriate, algoritmi, schemi di progettazione che possono essere utilizzati ( interviste di programmazione esposte e perle di programmazione sono utili per questo)
  • Scrivi il codice, spiegando ad alta voce all'intervista quale sia il tuo processo di pensiero . Se l'intervistatore sa cosa stai pensando, potrebbe essere in grado di identificare tempestivamente i problemi del tuo approccio e guidarti verso una soluzione migliore.
  • Prima di dire all'intervistatore che sei completo, pensa e spiega all'intervistatore come testeresti il ​​software che hai appena scritto. Pensa a casi semplici, casi limite, concorrenza, se l'approccio ha senso per altre culture, implicazioni di sicurezza, stress test, ecc.

Ammettere infine che non sai che qualcosa è (IMHO) preferibile inciampare nel tentativo di fingere. Certo, il colloquio ti sta chiedendo di risolvere un problema, ma se non sai da dove cominciare, ti consiglierei di parlare degli approcci validi e di provare a restringere il dow a uno corretto che affronti le controversie fornite. Se non hai idea di dove iniziare, potrebbe essere il momento di spiegarlo (questo si collega anche al modo in cui ti adatti alla squadra. Direi che è meglio chiedere una direzione in anticipo). Quindi non penso che dire che non sai sia una cosa negativa (supponendo che non sia tutto ciò che viene detto =])

Non c'è molto che puoi fare per adattarti, come spesso si riduce a un'opinione personale dell'intervistatore, ma conversare con l'intervistatore su ciò che stai pensando / facendo è preferibile codificare in silenzio per 15 minuti e poi dichiarare "Ho finito".

Tieni presente che queste cose sono di solito un'intervista a due vie . Non stanno solo intervistando te, ma anche intervistandoli. Sentiti libero di porre domande sul lavoro / team / azienda.

Infine, i recruiter di Microsoft pubblicano una discreta quantità di informazioni su ciò che stanno cercando durante uno schermo / intervista del telefono, quindi ho raccomandato di leggere. 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 le domande di intervista con MS / Google / Amazon / Apple / ecc. Produrrà risultati.

In bocca al lupo.


3

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

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

Questa intervista con Laszlo Bock sembra essere d'accordo. Google non si preoccupa di gradi o voti o punteggi dei test:

Una delle cose che abbiamo visto da tutti i nostri dati crunch è che i GPA sono privi di valore come criterio per l'assunzione e che i punteggi dei test sono privi di valore - nessuna correlazione affatto tranne per i laureati nuovi di zecca, dove c'è una leggera correlazione. Google notoriamente chiedeva a tutti una trascrizione, punteggi GPA e punteggi dei test, ma non lo facciamo più, a meno che tu non sia a pochi anni da scuola. Abbiamo scoperto che non prevedono nulla. ... Ci sono cinque attributi di assunzione che abbiamo in tutta l'azienda. Se si tratta di un ruolo tecnico, valutiamo la tua capacità di codifica e metà dei ruoli nell'azienda sono ruoli tecnici. Per ogni lavoro, tuttavia, la cosa n. 1 che cerchiamo è la capacità cognitiva generale, e non è il QI. È la capacità di apprendimento. È la capacità di elaborare al volo. È la capacità di mettere insieme frammenti di informazioni disparate. Valutiamo che utilizzando interviste comportamentali strutturate che convalidiamo per assicurarci che siano predittive.


5
Elitario e completamente inutile. A che serve rispondere a una domanda se tutto ciò che stai dicendo è "non provare a essere troppo stupido"?
Joshua Olson,

Inoltre, assumere per Google e Amazon non è nemmeno nella stessa classe di un violoncellista di livello mondiale, non sto intervistando per il lavoro di Peter Norvig. Le loro barre di assunzione non sono così vicine.
Joshua Olson,

4
Mi dispiace, ma ho sicuramente avuto l'idea che non hai compreso appieno il processo di intervista. Ho intervistato molte persone e sono stato intervistato molte volte. Studiare per un'intervista da una squadra d'élite è efficace quanto studiare per il SAT. L'intervista non è un test di conoscenza. È una prova della capacità di risoluzione dei problemi e della chiarezza del pensiero, in cui il codice è il mezzo di espressione. Queste abilità sono il prodotto di molte ore di programmazione e di pensiero sulla programmazione. Molte ore qui significano "molta programmazione indipendente, non correlata agli incarichi scolastici".
Kevin Cline,

Lol. Spero che. No, probabilmente il processo di intervista "non dovrebbe" essere un test di conoscenza, ma in SV di solito è specialmente in aziende come Google, Facebook o Amazon. Intervistare è assolutamente un'abilità e più la studi e la pratichi, meglio la ottieni.
Joshua Olson,

2
@josh - Anche io ho avuto interviste del genere. Se l'intervista sembra un gioco insignificante, probabilmente non è un buon posto di lavoro. Se l'intervista è organizzata male, è probabile che lo sia anche il progetto. I team che pensano al loro processo software penseranno anche al loro processo di intervista.
Kevin Cline,

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, consiglierei un po 'di sforzo dal punto di vista ingegneristico , essendo in grado di progettare software pratico e comunicare chiaramente quel design. Piuttosto che apprendere di più dalla teoria CS, leggi alcuni libri come Programming Pearls , Refactoring , C ++ Coding Standards e Code Complete . Se uno dei lavori "poco interessanti" ti dà la responsabilità sulla progettazione di software reale, prendi il lavoro e rendilo interessante. Nel mondo reale, ti senti spesso come questo ragazzo, ma può comunque essere molto soddisfacente sapere che hai affrontato un problema difficile, anche se potrebbe essere in un'applicazione banale.


Non sono davvero così esigente. Voglio solo lavorare su un vero software. Non piccoli script qua e là o semplicemente cambiando alcune dichiarazioni if ​​che sono state scritte 10 anni fa per funzionare con questa regola aziendale leggermente diversa o formula di algebra.
Joshua Olson,

Lavorare sull'aspetto ingegneristico è il motivo per cui sto cercando lavoro presso aziende di software (non aziende di b2b che hanno un prodotto software o due).
Joshua Olson,

1

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

Lavoro per una di queste società di software d'élite e non trovo che le nostre politiche di assunzione siano orientate a "non perdere" grandi talenti ma a "non assumere" talenti mediocri. Ho visto che alcune di queste aziende vogliono davvero assumere persone fantastiche, ma lo fanno intervistando molti sviluppatori (su carta) davvero belli e poi eliminando quelli che non vogliono. Una volta che qualcuno viene assunto, è molto difficile sbarazzarsene, quindi è utile rifiutare un candidato che ritieni possa essere davvero adatto, ma che uno degli intervistatori abbia visto alcune bandiere rosse.

Nell'azienda per cui lavoro attualmente, sono stato rifiutato perché uno e solo uno degli intervistatori (il più importante) mi ha dato un pollice in giù. Questa intervistatrice mi ha posto una domanda molto specifica per il dominio e non parlava inglese fluentemente. Non mi hanno assunto, ma il team ha pensato che la compagnia avrebbe perso un noleggio potenzialmente buono. Mi hanno inviato a un'altra serie di interviste con un team diverso la settimana successiva e ho ottenuto il lavoro (con segni di "forte assunzione" che potrei aggiungere).

Il mio consiglio è che se credi davvero di avere quello che serve, continua a intervistare questa società e impara da ogni esperienza fino a quando non ottieni il lavoro. La maggior parte di queste aziende tiene un registro di tutti coloro che intervistano e inserisce nella lista nera i candidati poveri (quindi non ottengono mai un altro colpo). Tuttavia, i candidati che erano buoni candidati ma 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 nella lista nera quando le telefonate del reclutatore si fermano un giorno e ogni contatto futuro sembra colpire le orecchie dei non udenti. Se ricevi richieste future dalla società, sai che stai bene. Non c'è assolutamente nulla di male nel creare più interviste dopo il tuo primo rifiuto, purché tu non sia nella lista nera. Infatti, Consiglio vivamente di intervistare più team contemporaneamente. Gli intervistatori ti respingeranno al primo segnale percepito di difficoltà, indipendentemente dal fatto che si tratti o meno di un problema reale. Sono cauti e non vogliono fare assunzioni sbagliate molto più di quanto non vogliano fare assunzioni buone.

Qualche altro pensiero:

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

- Ho parlato personalmente con un geniale ingegnere quando ho intervistato Microsoft che mi ha detto che gli ci sono voluti 5+ tentativi prima di essere finalmente assunto. Questo ragazzo era un SDE di livello senior, quindi MSFT ovviamente convalidò che era un buon assunto promuovendolo.

Alcuni suggerimenti:

Conosci le tue strutture dati e i tuoi algoritmi avanti e indietro. Hai bisogno di sapere tutto fino al punto di attraversare graficamente.

Conoscere l'architettura, in particolare i sistemi distribuiti e i 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 a cui rispondere nell'intervista (interviste comportamentali). Puoi essere perfetto dal punto di vista tecnico e se non sopravvivi all'intervista comportamentale non verrai assunto.

Non preoccuparti di quali linguaggi di programmazione stanno cercando. Conoscere un linguaggio orientato agli oggetti avanti e indietro e codice in quello. All'intervistatore di solito non importa in quale lingua codifichi e non ti giudica in base a questo.

Infine, inviami il tuo curriculum via email. ; =)


0

Non necessariamente perso per errore

Forse non hai fatto niente di male, ma qualcun altro ha fatto di meglio. Forse in termini di personalità, capacità comunicative, interrelazioni, esperienza di progetto passata simile ecc.

Potresti essere andato bene per essere assunto, ma non eri solo tu nella lista. Non mi preoccuperei troppo. Tutto accade per uno scopo.


È vero, ma ho trovato più difficile lavorare su qualcosa, più sono fortunato, quindi sto solo cercando di trovare modi per rendermi "più fortunato". :)
Joshua Olson,

1
No, molto raramente hanno un limite su quante assunzioni. Se fai il taglio, ti assumono. Troveranno un posto nell'azienda per chiunque soddisfi i loro standard. Personalmente ho scoperto che questo è vero per Google, Amazon e MSFT.
Jonathan Henson
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.