Artigo original: I just got a developer job at Facebook. Here’s how I prepped for my interviews.

Escrito por: Andyy Hope

Fiz sete entrevistas presenciais em empresas de tecnologia do Vale do Silício. Por fim, aceitei uma oferta de emprego em engenharia de software no Facebook.

Confira a seguir como me preparei para essas entrevistas e o que aprendi ao longo do caminho.

Minha jornada de anos rumo ao Vale do Silício

Quando eu fazia faculdade de Ciência da Computação na Austrália, sempre vislumbrava meu futuro como engenheiro de software no Vale do Silício.

Eu adorava a ideia de estar no centro das inovações tecnológicas, bem como de seus tropeços. Esse objetivo me manteve focado e motivado.

Larguei meu cargo de engenheiro líder de iOS em uma empresa incrível em Melbourne e voltei para minha cidade natal, Perth, para estudar. Lá, eu me preparei para o processo de entrevistas que me aguardava no Vale do Silício. Eu sabia que seria muito difícil.

Se você falar sobre o processo de entrevista técnica com engenheiros de software reunidos em uma sala, muitos serão contrários a suas práticas comuns. O maior argumento é que a resolução de algoritmos em um quadro branco não representa as tarefas diárias de um engenheiro de software.

Neste artigo, não vou entrar nesse mérito. Em vez disso, vou explorar essas diferentes práticas de entrevista da perspectiva do candidato, além de focar no que aprendi ao longo do processo.

Fazer entrevistas é uma habilidade

Durante minha preparação, eu já sabia que a entrevista seria um desafio, mas, sinceramente, não fazia ideia do nível de dificuldade até fazer a primeira.

Antes disso, usei serviços pagos e gratuitos que simulavam entrevistas de programação e whiteboarding (onde você faz os testes de programação com o auxílio de um quadro branco – em inglês, white board) por telefone com pessoas experientes em seleção. Aquelas provas práticas foram essenciais para eu me preparar para a pressão. Percebi mais tarde, no entanto, que elas representavam apenas uma fração do que era a realidade.

Não aconselho fazer entrevista para seu emprego dos sonhos sem já ter feito algumas antes — simuladas ou reais. O nervosismo pode ser avassalador e só pode ser dominado com a prática.

Assim como em muitas outras situações na vida, a prática eleva a confiança.

Os diferentes tipos de entrevista que encontrei

Se você se preparar e se sair bem nas entrevistas preliminares por telefone, vai ter a oportunidade de comparecer presencialmente para passar o dia fazendo entrevistas. Em geral, elas duram de quatro a seis horas, dependendo da empresa.

Em minha jornada até o Vale do Silício, consegui fazer sete entrevistas presenciais no total, o que me deu uma perspectiva única do panorama atual.

Normalmente, uma entrevista presencial tem três temas principais: algoritmos, design de arquitetura e comportamental (algo que estudei ao me preparar). Porém, algumas empresas parecem contrariar essa tendência ao abranger competências mais práticas.

Vou resumir cada um dos tipos que encontrei.

Entrevista sobre algoritmos

É o tipo mais comum. O entrevistador pede para que você resolva um problema em um quadro branco e avalia seus conhecimentos sobre estruturas de dados, algoritmos de ordenação, recursão e análise da complexidade de tempo/espaço, bem como reconhecimento de padrões e de casos extremos. O mais frequente é, primeiro, apresentar uma solução de força bruta e, em seguida, tentar refinar essa solução e discutir as eventuais vantagens de suas sugestões.

Durante seis semanas, todos os dias, o feijão-com-arroz da minha preparação foi resolver algoritmos em um quadro branco barato, analisar a sua complexidade temporal/espacial e tentar realmente compreender o que fazia cada linha de código.

Pessoalmente, eu adoro fazer algoritmos no quadro branco porque (em geral) não sou obrigado a me preocupar com uma sintaxe compilável, o que me permite focar só no problema em questão. Tem gente que não curte fazer algoritmo na lousa. A essas pessoas, eu diria: pratiquem consistentemente e talvez acabarão mudando de ideia.

Entrevista de design de arquitetura

É uma entrevista interessante e que subestimei demais. O entrevistador pede para desenhar (em um quadro branco, é claro) algo como um sistema de estacionamento, um chat ou um feed como o do Twitter.

O que é avaliado é como se pega um conceito geral para conceber um sistema que satisfaça todos os requisitos e restrições. Cabe ao candidato, no entanto, fazer as perguntas certas para definir os requisitos e as restrições. Essa entrevista está mais para um bate-papo com diagramas sendo desenhados e talvez até estruturação de classes. Tudo é feito em alto nível. Então, você não escreve um código realmente implementável.

Naturalmente, você deve conduzir a conversa de modo a cobrir seu conhecimento sobre como os sistemas funcionam. Se você for um engenheiro de back-end, não entrará em detalhes sobre a aplicação no client (a menos que tenha algum conhecimento prévio nessa área). Como sou engenheiro de iOS, falei sobre padrões de arquitetura, modularização de funcionalidade e padrões de design em vez de como dimensionar as extremidades da API, adicionar workers, AWS e essas coisas.

Entrevista comportamental

O entrevistador faz perguntas sobre você e sobre como lida com determinadas situações. A preparação para essa entrevista não é tão difícil quanto as outras, mas requer muita reflexão da sua parte.

As perguntas geralmente seguem essa linha:
・Como você lida com o fracasso?
・Qual é seu maior ponto fraco?
・Como você resolve um conflito?
・O que você teria feito de diferente?

Creio que seria muito difícil fazer besteira nessa parte, mas ouvi que muita gente faz. Muitos tentam disfarçar os seus defeitos como se fossem qualidades e elaboram a sua resposta conforme o que acham que o entrevistador gostaria de ouvir. Isso quando não transferem a culpa de projetos que não deram certo para outras pessoas:
・"Meu ponto fraco é que sou focado demais"
・"A culpa foi de Jerry, que passou a maior parte do projeto doente"

Entrevistadores são treinados e especializados para identificar gente problemática, sem contar que eles têm um faro apurado para conversa fiada. Então, essa etapa pode fazer sua candidatura ir por água abaixo. Basta ser sincero, mostrar paixão pelo que faz, assumir suas falhas e mostrar interesse em melhorar que tudo vai dar certo.

Adequação cultural

Normalmente, essa entrevista é feita junto com a comportamental, e visa determinar se você está de acordo com os valores da empresa. Por exemplo, o Facebook segue a cultura hacker de ser ousado e lançar novas ideias, experimentar e não ter medo de quebrar algo. Já a Airbnb quer criar um mundo onde as pessoas se sintam acolhidas em todo lugar. Por isso, buscam por gente mais hospitaleira.

Muitas big techs dão ênfase na cultura e contratam com base no alinhamento do candidato com os seus valores. Se você fizer entrevista em uma dessas empresas, é importante pesquisar antes os valores dela para encontrar experiências prévias suas que tenham a ver com ela para informar a seu entrevistador.

Programação em dupla

É uma categoria interessante, em que o candidato é colocado com outro engenheiro em frente a um computador com um ambiente de desenvolvimento semelhante ao que utilizaria no mundo real. Você recebe uma tarefa básica e uma lista de requisitos que deve completar. Conforme você termina cada tarefa, o entrevistador pede que você implemente mais funcionalidades, até o tempo acabar. É liberado usar o recurso que você quiser, como o Stack Overflow ou a documentação on-line.

Creio que muito do sucesso de um candidato nessa entrevista será determinado pela exposição dele a experiências práticas no mundo real. Ao contrário do que acontece no quadro branco, é necessário escrever código sintaticamente correto. Portanto, você deve dominar a sua linguagem e o seu ambiente para não perder muito tempo buscando resposta na internet ou na documentação.

Em meu trabalho anterior, eu escrevia código limpo enquanto trabalhava em uma tarefa, depois otimizava o código quando sentia que já estava pronto. Essa maneira de trabalhar não deu certo nesse tipo de entrevista. Acabei me encurralando por ter escrito um código limpo e o otimizado antes da hora, o que dificultou seu manuseio. Descobri que bastava ter feito um esboço de código e mencionado o que faria de diferente durante a produção, em vez de escrever o código de maneira limpa e otimizada.

Busca e correção de bugs

Muito do que fazemos como engenheiro de software gira em torno de encontrar e corrigir erros que nos são reportados por várias fontes. Nesse tipo de entrevista, você recebe uma lista de bugs para encontrar e corrigir, bem como identificar qualquer outro código potencialmente problemático ao longo do caminho.

Só me deparei com um caso desse tipo de entrevista. Creio que deve ser bem difícil para alguém se preparar para ela, especialmente se for para uma vaga de júnior. Cada ambiente de programação tem as suas próprias particularidades e nuances. Muito do trabalho de correção que fiz veio de experiências prévias com IDE (ambiente de desenvolvimento integrado) e frameworks que acumulei ao longo dos anos.

Teste de domínio do conhecimento

Programação é basicamente a mesma coisa na maioria das linguagens que temos atualmente. Se você sabe programação orientada a objetos em uma linguagem, é provável que esse conhecimento também valha para as outras.

No entanto, essa entrevista foca no conhecimento que não pode ser transferido entre linguagens ou frameworks. As perguntas são sobre especificidades do ambiente relacionadas a API, gestão de memória, capacidade, restrições etc.

Praticar pode ser um desafio aqui. Assim como na entrevista de localização e correção de erros, creio que muitas das respostas resultam de experiências prévias. Dependendo do nível do cargo que você se candidatar, suas respostas podem ter um peso diferente. Por exemplo, se um candidato a uma função júnior não sabe por que uma API é estruturada de certa maneira, dá para relevar. Se, contudo, um candidato a um cargo sênior não souber, aí a avaliação pode ser mais rigorosa.

Compreensão de sistemas operacionais

Dependendo da função ou da equipe para a qual você esteja sendo entrevistado, é possível que as perguntas se concentrem exclusivamente em sistemas operacionais. Nesse tipo de entrevista, o que será avaliado é sua compreensão do funcionamento interno do sistema operacional de um computador.

Confesso que, nessa, fui pego desprevenido. Até aprendi sistemas operacionais nos primeiros anos de faculdade, mas meu conhecimento sobre o assunto foi se perdendo com o passar do tempo, o que refletiu em meu desempenho.

Como você deve se preparar

Como escrevi anteriormente, fazer entrevista é uma habilidade por si só. Mesmo que você já seja um excelente programador em seu trabalho diário ou tire ótimas notas em suas provas, essas habilidades não necessariamente vão servir quando você estiver em uma salinha de entrevista. A persistência, a repetição e a consistência tanto na preparação quanto na prática da entrevista determinarão seu resultado.

Conhecimento mínimo

Se alguém me perguntasse em que área focar, eu sugeriria o seguinte:

  • Aprenda a escrever o código à mão primeiro: em papel e no quadro branco, só depois jogue o código em uma IDE para realçar a sintaxe. Isso deve se tornar um hábito para você.
  • Desenvolva um conhecimento profundo das estruturas de dados: os pontos fortes e fracos de uma em relação às outras. Descobri que implementar estruturas de dados e seus comportamentos do zero me ensinou muito mais do que aprendi com seus conceitos abstratos.
  • Entenda totalmente a notação Big O: tanto a complexidade de tempo quanto a de espaço, o que vai ser importante em perguntas sobre algoritmos e organização de dados.
  • Entenda todos os principais algoritmos de ordenação: diferenças nas complexidades de tempo/espaço podem atrapalhar sua solução ideal para o problema que busca resolver.

Quando começar?

Dependendo do seu cronograma, pode ser que você prefira começar mais cedo ou mais tarde. Muitas das empresas onde fiz entrevistas tinham um período de espera de 12 meses antes que um candidato reprovado pudesse tentar novamente. No entanto, se você já sabe que não vai estar pronto em um ano, é melhor fazer o processo logo agora e ter uma amostra de como ele é para que, quando estiver pronto, ele não seja tão assustador.

Não se preocupe! Você vai conseguir.

Recursos (em inglês)

Entrevistas simuladas

Algoritmos

Sistemas operacionais

Design de arquitetura

Comportamental

95r0mH93-K8IGlgN9pNRPj5YekDfvdLiRkhb

Se você gostou do que leu, dê uma olhada em meus outros artigos sobre desenvolvimento em iOS e Swift. Se quiser entrar em contato, me mande um tweet ou me siga no Twitter, o que vai valer meu dia.

Andyy Hope (@AndyyHope) | Twitter
Engenheiro iOS. Blogger/Palestrante de Swift & iOS