Não lhe parece estranho que quando você está prestes a mudar de emprego e surge a necessidade de passar em uma entrevista, a primeira coisa que você pensa é “você precisa se preparar para a entrevista”. Resolva problemas no HackerRank, leia a entrevista de codificação, memorize como o ArrayList funciona e como ele difere do LinkedList. Ah, sim, eles também podem perguntar sobre a classificação, e obviamente seria pouco profissional dizer que a classificação rápida provavelmente seria a melhor escolha.
Mas espere, você programa 8 horas por dia, resolve problemas interessantes e não triviais, e no seu novo emprego fará a mesma coisa, mais ou menos. Mesmo assim, para passar em uma entrevista, você precisa se preparar de alguma forma, nem mesmo aprimorar suas habilidades diárias, mas aprender algo que você não precisava em seu trabalho atual e que provavelmente não precisará no próximo. Às suas objeções de que a informática está em nosso sangue, e se você nos acorda no meio da noite, somos obrigados a escrever com os olhos fechados em uma fronha um passeio pela largura de uma árvore sem nem mesmo recuperar a consciência, eu responderei que se eu conseguir um emprego no circo, e meu principal truque seria exatamente esse - então talvez sim, eu concordo. Essa habilidade precisa ser testada.
Mas por que testar habilidades que são irrelevantes para o seu trabalho atual? Só porque virou moda? Porque o Google faz isso? Ou porque o seu futuro líder de equipe teve que aprender todos os métodos de classificação antes da entrevista e agora ele acredita que “todo bom programador deve saber de cor a implementação de encontrar um palíndromo em uma string”.
Bem, você não é o Google (c). O que o Google pode pagar, as empresas comuns não podem. O Google, depois de analisar os dados de seus funcionários, chegou à conclusão de que os engenheiros com experiência em Olimpíadas são bons no desempenho de suas tarefas específicas. Além disso, ao projetar seu processo de seleção, eles podem correr o risco de não contratar alguns bons engenheiros porque não conseguem resolver problemas matemáticos facilmente. Mas isso não é problema para eles, tem muita gente que quer trabalhar no Google, a vaga será fechada.
Agora vamos olhar pela janela, e se na frente do seu escritório os engenheiros que querem trabalhar para você ainda não montaram um acampamento e seus desenvolvedores estão procurando com mais frequência no stackoverflow qual próxima anotação do Spring precisa ser instalada, em vez das complexidades dos algoritmos de classificação, então, aparentemente, é hora de você pensar se deve copiar o Google.
Bem, se desta vez o Google falhou e não deu uma resposta, o que você deveria fazer? Verifique exatamente o que o desenvolvedor fará no trabalho. O que você valoriza nos desenvolvedores?
Faça critérios para quem você quer contratar e desenvolva testes que testem exatamente essas habilidades.
ThoughtWorks
O que a ThoughtWorks tem a ver com isso? Foi aqui que encontrei um exemplo de entrevista modelo para mim. Quem é a ThoughtWorks? Em suma, esta é uma empresa de consultoria High-End com escritórios em todo o mundo, desde a China, Singapura aos continentes americanos, que presta consultoria na área do desenvolvimento há cerca de 25 anos, tem a sua própria divisão de Ciência, liderada por Martin Fowler. Se você procurar uma lista de 10 livros de leitura obrigatória para um engenheiro de software, talvez 2 ou 3 deles sejam escritos pelos caras da ThoughtWorks, como Refactoring, de Martin Fowler, e Building Microservices: Designing Fine-Grained Systems, de Sam. Newman ou Construindo Arquiteturas Evolucionárias
por Patrick Kua, Rebecca Parsons, Neal Ford.
O negócio da empresa baseia-se na prestação de serviços bastante caros, mas o cliente paga por uma qualidade fenomenal, que consiste em experiência, padrões internos e, claro, pessoas. Portanto, contratar as pessoas certas é vital aqui.
Que tipo de pessoa está certa? Claro, existem diferentes para cada pessoa. A ThoughtWorks determinou que os critérios mais importantes para seu modelo de negócios de desenvolvedor são:
- Capacidade de se desenvolver em pares. É habilidade, não experiência ou habilidade. Ninguém espera que venham pessoas que praticam programação em pares há 5 anos, mas ser receptivo às opiniões de outras pessoas e ser capaz de ouvir é uma habilidade necessária.
- Capacidade de escrever testes e, idealmente, praticar TDD
- Compreenda SOLID e OOP e seja capaz de aplicá-los.
- Apresente sua opinião. Como consultor, você tem que trabalhar com os desenvolvedores do cliente, com outros consultores, e não há muito benefício se uma pessoa sabe fazer algo bem, mas é completamente incapaz de transmitir isso para o restante da equipe.
Agora é importante avaliar essas habilidades específicas do candidato. E aqui quero falar sobre minha experiência de entrevista na ThoughtWorks. Direi desde já que fui para Singapura e passei, mas o processo de recrutamento é unificado e não vai diferir muito de país para país.
Estágio 0. RH
Como sempre acontece, uma entrevista de 20 minutos com o RH. Não vou me alongar nisso, apenas direi que nunca conheci um profissional de RH que pudesse falar por 15 minutos sobre a cultura de desenvolvimento na empresa, por que usam TDD, por que programação em pares. Normalmente, os RHs respondem a essa questão e dizem que seu processo é normal: os desenvolvedores desenvolvem, os testadores testam, os gerentes conduzem.
Estágio 1. Você é bom em OOP, TDD?
1.5 horas antes do início da entrevista, recebi a tarefa de fazer um simulador do Mars Rover.
Missão do rover em MarteUm esquadrão de robôs robóticos será pousado pela NASA em um planalto em Marte. Este planalto, que é curiosamente retangular, deve ser percorrido pelos rovers para que as suas câmeras a bordo possam obter uma visão completa do terreno circundante para enviar de volta à Terra. A posição e localização de um rover são representadas por uma combinação de coordenadas x e y e uma letra que representa um dos quatro pontos cardeais da bússola. O planalto é dividido em uma grade para simplificar a navegação. Um exemplo de posição pode ser 0, 0, N, o que significa que o rover está no canto inferior esquerdo e voltado para o norte. Para controlar um rover, a NASA envia uma simples sequência de letras. As letras possíveis são ‘L’, ‘R’ e ‘M’. 'L' e 'R' fazem o rover girar 90 graus para a esquerda ou para a direita, respectivamente, sem se mover de seu local atual. 'M' significa avançar um ponto da grade e manter o mesmo rumo.
Suponha que o quadrado diretamente ao norte de (x, y) seja (x, y+1).
ENTRADA:
A primeira linha de entrada são as coordenadas superiores direitas do platô, as coordenadas inferiores esquerdas são consideradas 0,0.
O resto da entrada são informações relativas aos rovers que foram implantados. Cada rover possui duas linhas de entrada. A primeira linha fornece a posição do rover e a segunda linha é uma série de instruções que informam ao rover como explorar o planalto. A posição é composta por dois números inteiros e uma letra separados por espaços, correspondendo às coordenadas xey e à orientação do rover.
Cada rover será finalizado sequencialmente, o que significa que o segundo rover não começará a se mover até que o primeiro termine de se mover.
SAÍDA:
A saída para cada rover deve ser suas coordenadas finais e direção.
NOTAS:
Simplesmente implemente os requisitos acima e prove que um aspirador de pó funciona escrevendo testes unitários para ele.
Criar qualquer forma de interface de usuário está fora do escopo.
Será preferível resolver o problema seguindo uma abordagem TDD (Test Driven Development).
No pouco tempo disponível, estamos mais preocupados com a qualidade do que com a integridade.
*Não consigo postar a tarefa que me foi enviada, esta é uma tarefa antiga que foi entregue há vários anos. Mas acredite, fundamentalmente tudo permanece igual.
Gostaria de chamar especialmente a atenção para os critérios de avaliação. Quantas vezes você já se deparou com uma situação em que coisas que são importantes para um candidato são completamente sem importância durante a auditoria e vice-versa. Nem todos pensam da mesma forma que você, mas muitos podem aceitar e seguir seus valores se eles forem claramente declarados. Assim, dos critérios de avaliação fica imediatamente claro que as competências mais importantes nesta fase são
- TDD;
- Capacidade de usar OOP e escrever código sustentável;
- habilidades de programação em pares
Então, fui avisado para passar aquela hora e meia pensando em como faria a tarefa, em vez de escrever código. Escreveremos o código juntos.
Quando falamos ao telefone, os caras nos contaram brevemente quem são e o que fazem e se ofereceram para iniciar o desenvolvimento.
Durante toda a entrevista, nunca tive a sensação de estar sendo entrevistado. Há a sensação de que você está desenvolvendo código em equipe. Se você ficar preso em algum lugar, eles ajudam, aconselham, discutem e até discutem entre si sobre a melhor forma de fazer isso. Na entrevista, esqueci como verificar no JUnit 5 se um método lança uma exceção - eles se ofereceram para continuar escrevendo o teste, enquanto um deles estava pesquisando no Google como fazer isso.
Literalmente algumas horas após a entrevista, recebi um feedback construtivo - o que gostei e o que não gostei. No meu caso, fui elogiado por usar classes Sealed como alternativa ao objeto nulo; pelo fato de que antes de escrever o código, escrevi em pseudocódigo como gostaria de controlar o rover, e assim recebi um esboço das classes, pelo menos aquelas que estão envolvidas na API do robô.
Etapa 2: conte-nos
Uma semana antes da entrevista, fui solicitado a preparar uma apresentação sobre algum tema que me interessasse. O formato é simples e familiar: 15 minutos de apresentação, 15 minutos de resposta a perguntas.
Escolhi Clean Architecture do Tio Bob. E novamente fui entrevistado por algumas pessoas. Esta foi minha primeira experiência de apresentação em inglês e, talvez, se eu estivesse em uma situação estressante, não teria conseguido lidar com isso. Mas, novamente, nunca tive a sensação de estar em uma entrevista. Tudo está como sempre - eu digo a eles, eles ouvem com atenção. Mesmo a tradicional sessão de perguntas e respostas não foi como uma entrevista; ficou claro que as perguntas não foram feitas para “afundar”, mas sim aquelas que realmente os interessavam na minha apresentação.
Algumas horas depois da entrevista, recebi feedback – a apresentação foi muito útil e eles realmente gostaram de ouvir.
Etapa 3. Código de Qualidade de Produção
Tendo avisado que esta era a última etapa das entrevistas técnicas, fui solicitado a deixar o código em casa para um estado pronto para produção, depois enviar o código para revisão e agendar entrevistas nas quais os requisitos da tarefa mudariam e o código seria requerem modificação. Olhando para o futuro, posso dizer que a revisão do código é feita às cegas, os revisores não sabem a vaga a que o candidato se candidata, não veem o seu CV, nem sequer veem o seu nome.
O telefone tocou e novamente havia alguns caras do outro lado do monitor. Tudo é igual à primeira entrevista: o principal é não esquecer do TDD, contar o que você faz e por quê. Se você ainda não praticou TDD, recomendo começar a praticá-lo imediatamente, não porque seja necessário nas empresas, mas porque simplifica significativamente sua vida, reduz seu nível de estresse se quiser. Lembra como você teve que procurar freneticamente com um depurador por um erro que só pode ser reproduzido por meio do navegador, mas você não consegue reproduzi-lo com testes? Agora imagine que você terá que perceber esse erro durante uma entrevista - você tem a garantia de alguns cabelos grisalhos. O que ganhamos com TDD? Mudamos o código e inesperadamente percebemos que agora os testes estão vermelhos, mas qual é o erro que não conseguimos descobrir na primeira vez? Ok, dizemos “Oops” aos entrevistadores, pressionamos Ctrl-Z e começamos a dar pequenos passos à frente. E sim, você precisa desenvolver em si mesmo a habilidade de desenvolver usando TDD, a habilidade de ir em direção ao objetivo para que seus testes fiquem permanentemente verdes, e não vermelhos por meio dia, porque “você tem muita refatoração”. Esta é exatamente a mesma habilidade que escrever código sustentável ou escrever código produtivo.
Portanto, o quão bem seu código pode ser alterado depende do tipo de design que você definiu para começar, de quão simples ele é e de quão bons são seus testes.
Após a entrevista, recebi feedback em poucas horas. Nesse estágio, percebi que estava quase terminando e que faltava muito pouco até “conhecer Fowler”.
Etapa 4. Final. Chega de perguntas técnicas. Queremos saber quem você é!
Para ser honesto, fiquei um tanto intrigado com esta formulação da questão. Como você pode entender que tipo de pessoa eu sou em uma hora de conversa? E mais ainda, como você pode entender isso quando falo uma língua que não é minha língua nativa e, francamente, muito péssima e com a língua presa. Nas entrevistas anteriores, foi mais fácil para mim falar pessoalmente do que responder perguntas, e a culpa era do sotaque. Pelo menos um dos entrevistadores era asiático - e o sotaque deles, bem, digamos apenas, é um tanto específico para o ouvido europeu. Portanto, decidi adotar uma abordagem proativa - preparar uma apresentação sobre mim e no início da entrevista me oferecer para falar sobre mim com esta apresentação. Se eles concordarem, pelo menos haverá menos perguntas para mim; se eles rejeitarem a oferta, bem, 3 horas da minha vida gastas numa apresentação não é um preço tão alto. Mas o que você deve escrever em sua apresentação? Biografia - Nasceu lá, naquela época, estudou, formou-se na universidade - mas quem se importa?
Se você pesquisar um pouco sobre a cultura da Thoughtworks no Google, encontrará um artigo de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] que descreve os 3 Pilares: Negócios Sustentáveis, Excelência em Software e Justiça Social.
Vamos supor que a Excelência de Software já tenha sido verificada para mim. Resta mostrar Negócios Sustentáveis e Justiça Social.
Além disso, decidi focar neste último.
Para começar, contei a ele por que a ThoughtWorks - li o blog de Martin Fowler na faculdade, daí meu amor por código limpo.
Os projetos também podem ser apresentados de diferentes ângulos. Ele também desenvolveu softwares para medicina que simplificaram a vida dos pacientes e até, segundo rumores, salvaram uma vida. Também desenvolvi softwares para bancos, o que também facilitou a vida dos cidadãos. Principalmente se este banco for utilizado por 70% da população do país. Não se trata do Sberbank e nem mesmo da Rússia.
Quer saber sobre mim? OK. Meu hobby é a fotografia, de uma forma ou de outra tenho uma câmera nas mãos há cerca de 10 anos, há fotos que não tenho vergonha de mostrar. Além disso, certa vez, ajudei um abrigo para gatos: fotografei gatos que precisavam de um lar permanente. E com boas fotografias fica muito mais fácil localizar um gato. Provavelmente fotografei uma centena de gatos :)
No final, 80% da minha apresentação foi preenchida com gatos.
Imediatamente após a apresentação, o RH me escreveu que ainda não sabia o resultado da entrevista, mas todo o escritório já estava impressionado com os gatos.
No final das contas, esperei por feedback - satisfiz a todos como pessoa.
Mas durante a conversa final, o RH disse com muito tato que a Justiça Social é muito boa e necessária, mas nem todos os projetos são assim. E ele perguntou se isso me assustava. No geral exagerei um pouco na Justiça Social, acontece :)
Total
Como resultado, estou trabalhando em Cingapura na Thoughtworks há vários meses e vejo que aqui muitas empresas estão adotando as “melhores práticas de entrevista” do Google, usando folhas e quadro branco para codificação, apesar de terem mais conhecimento do que Spring, Symfony, RubyOnRails (sublinhe o que for necessário) não é necessário no trabalho. Os engenheiros tiram uma semana de folga antes de uma entrevista para “se prepararem”.
Na Thoughtworks, além dos requisitos adequados para o candidato, os seguintes princípios estão em primeiro plano:
Alegria de entrevistar. Além disso, para ambos os lados. Na verdade, se você quer conseguir o melhor pessoal (e quem não quer?), então uma entrevista não é um mercado onde os escravos são escolhidos, mas um espetáculo onde tanto o empregador como o candidato se avaliam mutuamente. E se um candidato associa emoções agradáveis a uma empresa, é provável que escolha esta empresa em particular.
Vários entrevistadores para mitigar preconceitos. Na Thoughtworks, a programação em pares é o padrão de fato. E se esta prática pode ser aplicada a outras áreas, a TW tenta fazê-lo. Em cada etapa, a entrevista é realizada por 2 pessoas. Assim, cada pessoa é avaliada por pelo menos 8 pessoas, e o TW tenta selecionar entrevistadores com diferentes formações, diferentes direções (não apenas técnicos) e gênero.
Em última análise, a decisão de contratação será tomada com base na opinião de pelo menos 8 pessoas, e ninguém terá voto de qualidade.
Contratação baseada em atributos Em vez de tomar uma decisão com base no que o candidato gosta ou não, é desenvolvido um formulário para cada função e cada etapa que inclui os atributos que estão sendo avaliados. Ao mesmo tempo, ao avaliar, é altamente recomendável avaliar não a experiência em uma determinada habilidade, mas a capacidade de aplicá-la. Assim, se um candidato não conseguiu aplicar nenhuma habilidade, como TDD, mas mesmo assim tenta aplicá-la, ouve conselhos sobre como utilizá-la corretamente, ele tem todas as chances de passar na entrevista.
Certificados de educação não necessários A TW não exige nenhuma certificação ou formação em Ciência da Computação. Apenas as habilidades são avaliadas.
Esta é a primeira entrevista que tenho com empresas estrangeiras para a qual não tive que me preparar. Depois de cada etapa, não me senti exausto, pelo contrário, fiquei feliz por poder aplicar as melhores práticas, que as pessoas do outro lado do monitor valorizaram e aplicaram todos os dias.
Depois de vários meses, posso dizer que as minhas expectativas foram plenamente atendidas. Qual a diferença entre a ThoughtWorks e uma empresa normal? Em uma empresa normal você pode encontrar bons desenvolvedores e pessoas legais, mas na TW a concentração deles é extraordinária.
Se você estiver interessado em ingressar na ThoughtWorks, você pode ver nossas vagas abertas
Sugiro também prestar atenção às vagas interessantes:
Engenheiro de software líder: , , ,
Engenheiro de software senior: , , ,
Engenheiro de software: , ,
Engenheiro de dados sênior:
Analista de qualidade:
A infraestrutura: , ,
(Gostaria de avisar sinceramente que o link é um link de referência, se você for para o TW receberei um belo bônus). Escolha um escritório que você goste, você não precisa se limitar à Europa, afinal a cada 2 anos a TW terá prazer em transferi-lo para outro país, pois... isso faz parte da política da ThoughtWorks, para que a cultura seja difundida e homogeneizada.
Sinta-se à vontade para fazer perguntas nos comentários ou pedir recomendações.
Se o assunto parecer interessante, escreverei sobre como é trabalhar na ThoughtWorks e como é a vida em Singapura.
Fonte: habr.com