Se eu tivesse que escolher apenas um método de entrevista para avaliar pessoas engenheiras, provavelmente seria system design. Não porque entrevistas de coding, comportamental, simulação de papeis ou estudo de caso sejam menos valiosas - eles são reveladores e ajudam a construir uma imagem mais complexa do(a) candidato(a). Se você tiver recursos para criar um processo que ofereça suporte à diversidade, uma estrutura justa para evitar bias e o tempo, as pessoas e o treinamento para executar um processo de vários estágios, provavelmente reduzirá a propensão de falsos positivos. No entanto, se eu fosse obrigado a escolher apenas um, escolheria system design.

Acho a mistura entre os critérios subjetivos e objetivos que a entrevista de design impõe muito útil para avaliar os candidatos de vários ângulos. Há uma estrutura razoavelmente bem definida para a avaliação técnica, mas apenas chegar a um bom design não é necessariamente suficiente. Da mesma forma, o comportamento do candidato tem um papel vital a ser avaliado, mas a falta de nexo causal e habilidade técnica revelará claramente a adequação à posição ou não.

Existem muitos recursos por aí que são uma base excelente para as partes mais objetivas. Fiz a curadoria de alguns dos meus favoritos no apêndice deste artigo. Eles merecem um grande foco na hora de estudar para uma entrevista, pois são a parte mais fundamental da avaliação que está sendo feita. Tendo passado por algumas entrevistas recentemente e praticado, pensei em escrever sobre alguns pontos que aprendi e que acredito que podem ajudar nos aspectos subjetivos, especialmente sobre postura.

§Não se limite a comunicar: colabore com os entrevistadores

Uma das coisas que considero muito úteis nas entrevistas técnicas é transformá-las em colaboração, em vez de apenas uma avaliação. O papel que os entrevistadores devem desempenhar fundamentalmente é avaliar se um candidato é adequado para ser seu colega. Eu acredito que quando você atinge uma atmosfera colaborativa ao entrevistar, você está dando às pessoas uma perspectiva muito melhor para avaliar sua adequação de forma justa.

Com isso em mente, uma vez que o entrevistador compartilha qual é o problema a ser resolvido, uma técnica que pode ajudar é reformular o objetivo com suas próprias palavras. Acho que isso ajuda a evitar situações em que você presume entender o que está sendo perguntado. É muito melhor esclarecer com o entrevistador do que desenhar a solução certa para o problema errado. Faça perguntas, por mais óbvias que possam parecer, e tente reunir todas as informações que puder antes de prosseguir.

Com o objetivo melhor definido, é essencial estabelecer o que está dentro do escopo e o que está fora. Estreitar quais são os limites do escopo para o problema da entrevista ajudará você a se concentrar no que é mais importante para o design em questão. Fazer concessões no escopo no início impedirá que você gaste o pouco tempo de que dispõe para falar sobre adjacências do problema.

Quando inferirir informações a partir do que lhe foi dito ou quando chegar a uma conclusão, expresse suas suposições e conclusões. Você precisa trazer seus entrevistadores para ver o problema do ângulo que você está olhando para fazer um julgamento justo se você está saindo do planejado e te colocar no trilho novamente, se necessário.

Então, ao trabalhar na solução proposta, evite transformar a experiência em um monólogo. Deixe espaços para feedback. Entrevistadores geralmente não se importam de sinalizar quando você sair do caminho esperado. Faça com que eles contribuam para a discussão, mesmo que de forma não verbal, independentemente se for sobre as implicações das decisões de design que você está escolhendo e por que, ou de forma mais específica, como se você deve dividir um componente em dois.

Em suma, comunicação é muito importante para as entrevistas técnicas. Além disso, buscar ativamente a colaboração aumenta suas chances de um bom desempenho na entrevista e também ajuda os entrevistadores a avaliar se gostariam de trabalhar com você - e vice-versa.

§Amplo primeiro e fundo depois

É fácil se aprofundar prematuramente nos detalhes do sistema, pois as perguntas da entrevista de design geralmente não cabem no intervalo de tempo disponível, ao contrário de uma entrevista de coding, por exemplo, onde o problema provavelmente se encaixa no tempo disponível. Ninguém espera que você encontre a solução perfeita para um sistema que é operado por dezenas, centenas ou mesmo milhares de pessoas - embora o ideal seja você ter um esboço para resolver o problema de ponta a ponta ao fim da entrevista.

Como nos sistemas da vida real, o design irá evoluir. Feito geralmente é melhor do que perfeito. Comece simples antes de se tornar complexo, favorecendo a extensibilidade em vez da perfeição. Apresente o design mais simples que não apresentará problemas óbvios de escalabilidade primeiro, mantenha quem está te entrevistando informado(a) sobre sua estratégia e, quando você cobrir os requisitos propostos, entre em otimizações mais profundas.

Uma maneira que descobri de enquadrar o problema no nível certo como ponto de partida é colocar-se no lugar do usuário do sistema que você está prestes a projetar. Basicamente, converse com o entrevistador sobre as etapas que o usuário levaria para usar o produto/sistema que você está projetando para as funcionalidades presentes no escopo. Estar atento às necessidades do usuário ajudará a esclarecer as características deste sistema, por exemplo, o que precisará de APIs públicas à internet, quais componentes terão mais leituras do que escritas, ou quando favorecer consistência em relação à disponibilidade. Olhar para o sistema através da perspectiva de experiência do usuário geralmente sugere o que é fundamental para aquele sistema e ajudará a definir alguns porquês mais adiante.

Quando você sentir que entendeu o todo, criou um design em alto nível e mostrou ao entrevistador que você tem controle sobre o problema no geral, escolha a parte com a qual se sente mais confortável para ir fundo e explore-a. Foque suas forças ao invés das suas áreas para desenvolvimento. Provavelmente, o problema em questão tem alguns desafios de escala interessantes para qualquer disciplina. Escolha o seu aspecto favorito do problema sobre o qual você possa falar profundamente, por exemplo otimização de bandwidth no lado do cliente, modelo de dados e particionamento, automação de infra de machine learning ou o que você quiser.

Dito isso, resista ao impulso de entrar em detalhes antes de entender totalmente o problema. Elevar a conversa às motivações e aos resultados esperados primeiro te ajudará a tomar decisões de design mais assertivas e a tornar alguns porquês mais evidentes para você e para a pessoa que te entrevista posteriormente.

§Fale sobre nuances e edge-cases

O que acontecerá se o seu sistema parar de enviar dados para um componente downstream do seu sistema? Como você notifica os sistemas upstream para reverter algo que foi alterado por engano? Como o sistema funciona para o 99º percentil de seus power users? Todas essas são questões que podem influenciar suas escolhas de design, portanto, pensar no que pode dar errado lhe dá a oportunidade de alterá-lo ou de confirmar que tomou as decisões corretas de design.

Especialmente em sistemas distribuídos de grande escala, você geralmente terá que otimizar para características específicas. Isso introduz inexoravelmente comportamentos indesejados - dos quais você precisa estar ciente para tomar a decisão certa. Fale sobre as compensações que você fez e por que escolheu uma abordagem ao invés de todas as outras opções que você tinha.

Além disso, explorar cenários de falha e opções de recuperação mostrará que você entende o design que você se comprometeu. Isso pode se tornar especialmente interessante quando você pode cobrir não apenas as falhas de sistema, mas como os usuários podem abusar o sistema, quais riscos são introduzidos que você terá que aceitar, ou até mesmo erro humano. Quando possível, fale sobre como você recupera ou evita que isso aconteça.

Converse sobre como consertar as coisas quando as coisas dão errado. Um exemplo disso é uma experiência pessoal em que superestimei capacidade em uma entrevista. Ao invés de alocar 1GB de armazenamento para contas gratuitas do sistema que estava desenhando, dediquei 1TB. Percebi que algo estava errado à medida que o armazenamento e bandwidth começaram a parecer absurdos para o problema em questão com o volume de acessos que o entrevistador e eu havíamos combinado. Depois de reconhecer que algo estava errado, falei sobre as etapas que tomaria para reverter o erro se isso fosse ao ar, como manter os usuários que se inscreveram na proposta de 1TB com os benefícios pelos quais pagaram indefinidamente, conversar com equipes responsáveis por publicidade/marketing e growth sobre o erro, e outras medidas de controle de danos que poderiam ser tomadas. Acho que essa conversa acabou sendo ainda mais interessante do que se eu tivesse calculado a capacidade certa a princípio.

Resumindo, as coisas darão errado em algum ponto - mostrar prontidão para trilhar o caminho não tão feliz aumentará sua confiança nas suas escolhas de design, e se você tomou uma decisão errada, ainda tem tempo para se adaptar e torná-la melhor ou pelo menos reconhecer o erro.

§Fale brevemente sobre adjacências do problema

Novamente, dado que a entrevista de design é extremamente limitada em tempo, você precisa estar ciente do que deseja enfatizar. Embora seja ótimo ter um escopo estreito para trabalhar, tocar levemente em tópicos adjacentes ao design em si pode mostrar ainda mais amplitude de conhecimento. Aqui estão alguns exemplos de assuntos a serem cobertos, que podem estar fora do escopo, mas podem aumentar o número de sinais, aumentando assim suas chances de um bom desempenho.

Acredito que a maioria dos engenheiros aprecia o fato de operar sistemas de grande escala é muito difícil. Eu pessoalmente gosto de cobrir a operações, não apenas o design. Especialmente em grandes empresas, onde você geralmente tem funções dedicadas de infrastructure engineering, é fácil de achar que ops "vem de graça". Falar brevemente sobre assuntos como alerts, monitoramento, tracing e observabilidade pode revelar problemas ao escalar um design específico.

Especialmente para ambientes altamente regulamentados, como pagamentos e prevenção de abuso, tocar em segurança, compliance e restrições regulatórias pode ser uma vantagem. Algumas idéias de assuntos a abordar são retenção de dados ou anonimização de dados para sistemas com informações de identificação pessoal, ou gerenciamento de risco por meio da divisão de componentes em redes internas diferentes para separar escopo de auditorias.

Talvez um aspecto mais relacionado a liderança técnica ou gerenciamento, as decisões de design irão ditar inerentemente como as equipes serão mobilizadas para domínios específicos. Uma grande vantagem de microsserviços é tornar a escalabilidade independente - incluindo pessoas e design organizacional. Falar sobre como o design provavelmente afetará como você mobiliza as pessoas no conjunto de equipes responsáveis ​​pelo design e mostrar consciência de escalonamento não apenas de infra-estrutura e sistemas, mas também de organizações pode gerar conversas interessantes.

Meus exemplos aqui são altamente influenciados pela minha própria experiência, mas fazer um breve aparte enquanto você cobre algo dentro do escopo da entrevista pode servir como um sinal adicional e aumentar a confiança do entrevistador em você.

Para encerrar, é importante notar que todas essas dicas são baseadas em minhas próprias experiências e preferências. Organizações diferentes se concentrarão em coisas diferentes, e seu melhor ponto de partida é entender as expectativas da empresa para a qual você está se candidatando. Acredito que incorporar os tópicos acima destacados à minha postura quando entrevistando me ajudou, e espero que ajude você também.

§Apêndice

Abaixo, adicionei um pequeno apêndice para alguns recursos sobre o lado técnico das coisas. Espero que você goste!

Gostou deste post? Compartilhe: email/linkedin/twitter/whatsapp