Por que não posso passar na minha entrevista no Google phone?

Muitas vezes, quando eu não sei a resposta completa à pergunta, vou fazer algumas pesquisas e recolher pensamentos interessantes de pessoas que responderam à sua pergunta e juntá-los de uma forma que faça sentido e responda à sua pergunta. (Plágio é roubar de uma fonte, pesquisa é roubar de muitas). Então, aqui está um pouco de incitação sobre o que acontece durante uma entrevista no Google phone. É uma questão de terra e crua, mas você sai do artigo vendo o que está acontecendo e o que você precisa fazer para melhorar. Espero que isto ajude, e Boa Sorte!>p>Round 1: um recrutador telefona-lhe. Eles vão fazer-lhe algumas perguntas simples. Coisas como "o quê's mais rápido, quicksort ou bubblesort". Se você responder o suficiente destas corretamente, você vai para a próxima rodada. Se você falhar aqui: pare de gemer, vá embora e melhore você mesmo, não há como você ter passado pelas etapas posteriores de qualquer maneira.

Round 2: um engenheiro irá chamá-lo, e entrevistar você por 45 minutos. Apenas os "melhores" entrevistadores podem fazer o que chamamos de "primeiras telas de telefone", porque é aí's que a maioria das pessoas é expulsa. Do ponto de vista do entrevistador, isto é o pior absoluto. Cerca de 1/10 candidatos passam esta etapa, porque a maioria dos candidatos (mesmo com mestrado e experiência de vários anos) são completamente incompetentes.

Não posso dizer o que exatamente vai acontecer durante esta entrevista, porque pessoas diferentes têm estilos diferentes, mas do que vi se resume a duas abordagens principais:

-A abordagem "cobrir o máximo de terreno possível". O entrevistador irá fazer-lhe 5-10 perguntas diferentes, espalhadas pelas suas áreas de especialização. Eu uso esta abordagem para pessoas que estão se candidatando para trabalhos de administração de sistemas ou engenharia de sistemas. Por exemplo, uma pergunta sobre redes, uma pergunta sobre unix, um pequeno problema de codificação, algo sobre segurança e algo sobre a web.

-A abordagem "um problema difícil". Eu uso isso para engenheiros de software, que eu sempre peço para escrever código. Você quer ser pago para escrever código, então é melhor você saber como. Na verdade, eu costumo dividir isso em duas perguntas: um "aquecimento" fácil seguido por uma pergunta "real".

Para dar uma idéia, uma pergunta de aquecimento pode ser algo como "inverter uma string no lugar" ou "implementar atoi" ou algo do tipo. Um bom e capaz engenheiro deve ser capaz de resolver isto em cerca de 5 minutos. Infelizmente, apenas uma minoria das pessoas que eu entrevisto já passou por essa questão de aquecimento nos 45 minutos alocados.

Se algum entrevistador começar com uma questão técnica, e depois mudar para "seu projeto mais interessante" ou "o bug mais complicado que você já corrigiu", isso significa uma de duas coisas:

a) Improvável: Você é tão fantástico que acabou com as perguntas do entrevistador. Isto acontece, mas muito raramente. b) Mais provavelmente, você é um fantoche tal que o entrevistador prefere esfaquear-se a si mesmo do que ouvir você falhar novamente. Então ele deixa que você conte uma história enquanto ele se zona. Na avaliação dele, ele lhe dará a pontuação mais baixa possível, e isto terminará o processo de entrevista para você.

>p>Agora assumindo que você passou da pergunta de aquecimento, que você - parabéns! - fazem parte da elite que sabe como escrever uma função recursiva, ou como dividir uma string por vírgulas - então chegamos à pergunta "real". Eu geralmente os escolho de modo que eles mal possam terminá-la nos 35 minutos restantes.

Exemplos podem incluir:

-remove duplicatas de uma lista de strings que é maior que a memória disponível (isto é, com recargas do disco)

-contar o número de objetos de disjoint num bitmap

-implementar um programa que toca tic-tac-toe

Estes são todos bastante difíceis de fazer em 35 minutos. A maioria das pessoas pode't, e it'não é necessariamente um fracasso se você não't chegar 100% lá.

Após a entrevista, nós escrevemos um relatório sobre a entrevista, que inclui uma pontuação. A propósito, don't pergunte como você fez, você ganhou't seja dito. Não nos é permitido, porque as pessoas podem nos processar. Esse relatório vai para o recrutador, que então decidirá se eles querem continuar. Se sim:

Round 3: exatamente o mesmo que o round 2, mas com um engenheiro diferente. Se você passar novamente: entrevistas no local!

P>Pomos você em um de nossos escritórios, onde você terá 3 entrevistas de 45 minutos, almoço, e mais 2 entrevistas. Estas são basicamente as mesmas que as telas telefônicas, mas você pode ver os entrevistadores cara a cara.

Se você não presta, eles às vezes te acompanham depois do almoço, e pulam as duas últimas entrevistas.

Outra forma: o feedback coletado vai para um comitê de engenheiros seniores que olham o feedback que foi coletado de você em 7 horas cansativas. Eles olham para ele durante 3-5 minutos e decidem se você está contratado ou não.

Se eles decidirem contratá-lo, o recrutador irá chamá-lo e fazer-lhe uma oferta. Você provavelmente vai dizer sim, porque nós pagamos muito, muito, muito bem.

Um par de dicas:

- Esta é provavelmente a dica mais importante, então eu vou colocá-la em primeiro lugar: Se nós pedirmos para você escrever um programa, NÃO comece a escrever código imediatamente. Pense no problema primeiro, e SAY OUT LOUD o que você está prestes a fazer, então faça-o. Se você estiver indo completamente na direção errada, nós lhe diremos, e você não vai perder 20 minutos indo lá.

-Os recrutadores são completamente idiotas e provavelmente irão esquecê-lo em algum lugar no meio do processo. Não tenha vergonha de chamar o seu recrutador se você não tiver notícias deles em (digamos) uma semana.

-Perguntas de sk se algo não estiver claro durante uma entrevista. Nós queremos vê-lo no seu melhor. Se você não tem certeza sobre o que é uma pergunta, ou o que queríamos dizer, pergunte imediatamente - você está jogando contra o relógio. Sim, alguns de nós demoramos quanto tempo você leva para obter uma resposta.

-Make your CV/Resume curto e doce. Nós olhamos para eles, mas apenas se eles forem curtos. A menos que você seja um professor no MIT, duas páginas. Não três. Duas. Coloque as suas habilidades no seu CV/Resume. Perguntamos-te no que és melhor. Se listar aquilo em que é melhor, perguntar-lhe-emos sobre isso. Se o seu CV/Resume diz "mestre em algoritmos", espere perguntas sobre algoritmos. Se não for óbvio pelo seu CV/Resume no que você é bom, nós perguntaremos como nos sentimos.

-Do não coloque sua experiência de colegial, banda de marcha, ou escoteira no seu CV/Resume. Ninguém quer saber e isso não vai te ajudar. É mais provável que te prejudique porque vai distrair das partes que importam.

-Quando te fizerem uma pergunta de codificação, não sejas pretensioso e começa a escrever cabeçalhos com "invariantes" ou "boas práticas de programação" se não souberes como resolver o problema. Não há problema em ser um picar pretensioso se você pode resolver o problema com facilidade, mas não se você não puder.