Como devo preparar-me para uma entrevista com a Microsoft?

Espero ter um bom conhecimento sobre este assunto. Entrevistei há cerca de um ano para um estágio da SDET no Bing e não me saí muito bem nas minhas entrevistas. Foi a primeira vez que tive grandes entrevistas de software, e foi um despertar definitivo sobre o que eu precisava fazer se eu realmente quisesse um trabalho como este.

Acabei tendo entrevistas em várias empresas de software no último ano; algumas correram bem, outras nem tanto. Eu acabei entrevistando novamente na Microsoft no outono passado para uma posição na SDET em tempo integral, e desta vez me saí bem o suficiente para receber (e aceitar) uma oferta. Aqui's o que aprendi:

1. Conheça suas estruturas de dados, especificamente Linked Lists, Queues, Stacks, Heaps, Hash Maps, e Trees (incluindo, mas não limitado a, BSTs, árvores AVL, etc). Você pode ser perguntado desde o simples "Let's insert into a Linked List?" até o abstrato "Que estrutura de dados resolve este problema de forma mais eficiente? Você deve saber os tempos de execução básicos fora do topo de sua cabeça, mas concentre-se no caso médio, em oposição ao melhor/pior caso.

2. Especificamente para testes, leia sobre os tipos de testes realizados nos principais softwares hoje. Você provavelmente será perguntado "Como você testaria esta função/produto/serviço"? Há mais maneiras de testá-lo do que você poderia pensar:

>p>

ul>Teste funcional - funciona? >li>caso de teste - limites de teste de um único parâmetro>caso de teste - limite de teste de múltiplos parâmetrosTeste de estresse - simular muitos usuários de um serviço>li>Teste de escala - como ele lida com entradas de tamanho absurdamente grande?<Testes interfuncionais - como é que tem impacto noutras partes da base de código?Testes de acessibilidade - a usabilidade é afectada se o utilizador for daltónico, surdo, etc?>li>Testes geopolíticos - ainda faz sentido em outras áreas com culturas diferentes? (Eu soube disso durante entrevistas)

3. Não comece, em nenhuma circunstância, a escrever código sem planejar sua solução, desenhar exemplos, etc. Descobri que depois de trabalhar na minha solução com o entrevistador, eles diriam algo na linha de: "Está bem, parece-me bem. Let's ver algum código". Isso'é a sua deixa que você'tenha planejado bem o suficiente para realmente implementá-lo, bem feito. Don'não se esqueça de rever uma vez que você acha que você'terminou (dica: você provavelmente esqueceu um caso de borda ou algo assim).

4. Se você ficar preso (a maioria das pessoas fica preso em algum ponto), don'não tenha medo de andar pelas coisas com o entrevistador. Diga-lhes como você'está tentando resolver o problema, ou talvez que você não'nem necessariamente vê uma solução de imediato. Volte para a prancheta de desenho, se for preciso. Tente pensar no seu entrevistador como um colega que pode ajudá-lo a chegar à solução, não alguém apenas julgando o seu desempenho naquele momento.

5. Conhecer paradigmas básicos como programação dinâmica, algoritmos gananciosos, etc., pode ser útil mas nem sempre necessário. Em vez disso, descobri que estar exposto a muitos problemas e soluções diferentes é uma boa maneira de obter experiência pensando nas coisas de uma maneira diferente. Vá procurar perguntas de entrevista online, tente pensar como você resolveria isso, e veja qual é a solução de fato. Isto não se aplica a problemas onde a solução é simplesmente um algoritmo popular.