Como Fazer uma Simulação de Entrevista para Engenheiro de Software

Você provavelmente já resolveu muitos problemas e ainda se sente despreparado, e o motivo geralmente é que resolver sozinho não é o que a etapa avalia. Esta seção separa as três etapas que um processo de engenharia de software usa, porque cada uma exige um ensaio diferente e misturá-las desperdiça a sessão.

• Codificação. 35 a 45 minutos, um ou dois problemas, pensando em voz alta enquanto digita. O objetivo do ensaio é narrar uma solução que você ainda está formando.
• Design de sistemas. 45 a 60 minutos, um prompt aberto, sem esclarecimentos a menos que você pergunte. O objetivo do ensaio é delimitar o problema antes de projetá-lo.
• Comportamental. 45 minutos de histórias de projetos com follow-ups hostis. O objetivo do ensaio é sobreviver ao terceiro follow-up sobre uma decisão da qual você se arrepende.

Faça apenas uma dessas por sessão. Um loop completo de três horas parece produtivo, mas gera quase nenhum feedback utilizável, porque na terceira etapa você está ensaiando cansaço, não habilidade. Se você quer o banco de perguntas em vez da mecânica, isso está em uma página separada no hub de simulações de entrevista.

Simulações solo falham de um jeito previsível: você escolhe um problema que consegue resolver, para o cronômetro quando trava e termina se sentindo bem. Cada uma dessas atitudes é o oposto das condições reais. Reproduza as restrições em vez disso.

• Não escolha seu próprio problema. Pegue de uma lista que você não leu, ou peça para alguém escolher. Escolher significa escolher algo confortável.
• Inicie o cronômetro e nunca o pare. Tempo travado é dado. Pausar remove exatamente a pressão para a qual você está ensaiando.
• Combine com as ferramentas. Se a etapa usa um editor compartilhado sem autocompletar, sem botão de executar e sem suíte de testes, pratique assim.
• Fale para uma sala vazia. Parece absurdo e é a parte de maior valor. Resolver problemas em silêncio treina uma habilidade que ninguém avalia.
• Grave. Assistir a si mesmo é desagradável e mostra enrolação, retrocessos e o minuto em que você ficou quieto.
• Projete sem uma ferramenta de diagramas no início. Muitas etapas de design são uma chamada de voz e um documento em branco.

A única coisa que uma simulação solo não pode oferecer é a interrupção, e a interrupção é a maior parte do que torna uma etapa real difícil. Um entrevistador de IA pode cobrir exatamente essa lacuna: ele faz o follow-up enquanto você está no meio de uma frase e não espera educadamente você terminar. O modo simulação de entrevista conduz as etapas dessa forma.

A maioria das pessoas termina uma simulação e registra um veredito, o que é inútil uma semana depois. Colete observações específicas ligadas a comportamentos que você pode mudar.

• Tempo até a primeira pergunta de esclarecimento. Se passar de noventa segundos, você está resolvendo o problema errado.
• Maior silêncio. Qualquer coisa acima de vinte segundos precisa de um marcador falado no lugar.
• Você declarou sua abordagem antes de digitar? Sim ou não, sempre.
• Como você se recuperou ao travar? Reformulou o problema, tentou um caso menor, ou congelou.
• A discussão sobre complexidade foi solicitada ou espontânea? Espontânea pontua melhor.
• Para design: você delimitou antes de desenhar? Restrições e escala primeiro, caixas depois.

Uma engenheira backend se preparando para um processo sênior fez doze simulações e passou em todas, depois foi reprovada na etapa real de codificação após ficar quatro minutos em silêncio numa variante desconhecida. Suas simulações nunca haviam incluído um problema que ela não conseguia resolver, então ela nunca havia ensaiado a única coisa que realmente deu errado. Ela mudou uma regra, permitindo problemas acima do seu nível, e o problema do silêncio surgiu imediatamente.

Não existe um número mágico, e o volume além de certo ponto deixa de compensar. Um padrão útil é duas ou três simulações por tipo de etapa, distribuídas ao longo de duas semanas, com a revisão entre elas importando mais do que as próprias sessões. Seis simulações sem revisão é pior do que três com anotações cuidadosas.

Seja claro quanto aos limites. Uma simulação não pode dizer qual problema você vai receber, não pode prever o estilo do seu entrevistador e não substitui realmente conhecer o material. O que ela corrige é a camada de entrega: falar enquanto pensa, delimitar antes de construir e se recuperar em voz alta quando trava. Isso se transfere completamente, e também são coisas que a leitura não ensina.

Prática e assistência ao vivo são perguntas diferentes com respostas diferentes. O ensaio é incontroverso. A assistência durante uma entrevista real depende do formato e das regras do empregador, e etapas de codificação com tela compartilhada ou monitoradas ficam totalmente fora de escopo. Os limites honestos estão no hub de detectabilidade.