Não é estranho que, quando você está prestes a mudar de emprego e precisa passar por uma entrevista, a primeira coisa em que pensa é "preciso me preparar para a entrevista". Resolver desafios no HackerRank, ler Crack the Coding Interview, decorar como funciona o ArrayList e como ele difere do LinkedList. Ah, sim, também podem perguntar sobre ordenações, e seria claramente pouco profissional dizer que o quick sort provavelmente seria a melhor escolha.
Mas espere, você programa 8 horas por dia, resolve tarefas interessantes e não triviais, e no novo emprego você vai fazer mais ou menos a mesma coisa. No entanto, para passar na entrevista, você precisa se preparar de alguma forma, não apenas aperfeiçoar suas habilidades diárias, mas também aprender o que você não precisou no emprego atual e provavelmente não precisará no próximo. A sua objeção de que a ciência da computação está em nosso sangue, e que se nos acordar no meio da noite, devemos ser capazes de escrever com os olhos fechados o algoritmo para percorrer uma árvore em largura, mesmo sem estar plenamente consciente, eu responderei que se eu fosse me candidatar a um circo, e meu truque principal fosse exatamente isso – então, talvez, eu concordasse. É preciso verificar essa habilidade.
Mas por que testar habilidades irrelevantes para o trabalho atual? Apenas porque isso se tornou uma tendência? Porque o Google faz assim? Ou porque o seu futuro líder teve que aprender todos os métodos de ordenação antes de passar pela entrevista e agora ele acredita que "todo bom programador deve saber de cor a implementação de como encontrar um palíndromo em uma string"?
A questão é que você não é o Google (c). O que o Google pode se permitir, empresas comuns não podem. O Google, analisando os dados de seus funcionários, chegou à conclusão de que, especificamente para as suas tarefas, engenheiros com uma formação em olimpíadas conseguem desempenhá-las bem. Além disso, ao construir o processo de seleção, eles podem se dar ao luxo de aceitar o risco de não contratar alguns bons engenheiros porque eles não conseguem resolver questões matemáticas facilmente. Mas para eles isso não é um problema, há muitos interessados em trabalhar no Google, e a posição será preenchida.
Agora, vamos olhar pela janela, e se ainda houver engenheiros desejando trabalhar para você que não montaram um acampamento em frente ao seu escritório, e seus desenvolvedores costumam buscar no StackOverflow qual anotar 'Spring' precisam usar, e não os detalhes dos algoritmos de ranqueamento, então, provavelmente, é hora de você considerar se vale a pena copiar o Google.
Bem, se desta vez o Google falhou e não deu uma resposta, o que você deve fazer? Verifique exatamente o que o desenvolvedor fará no trabalho. O que você valoriza nos desenvolvedores?
Estabeleça critérios para quem você deseja contratar e desenvolva testes que verifiquem exatamente essas habilidades.
ThoughtWorks
E onde entra o ThoughtWorks? Aqui encontrei um exemplo exemplar de entrevista. Quem são os ThoughtWorks? Em resumo, é uma empresa de consultoria de alta qualidade com escritórios em todo o mundo, desde a China e Cingapura até as Américas, que atua na consultoria em desenvolvimento há cerca de 25 anos e possui seu próprio departamento de ciência, liderado por Martin Fowler. Se você procurar uma lista de 10 livros que devem ser lidos por engenheiros de software, provavelmente 2-3 deles serão escritos por pessoas do ThoughtWorks, como 'Refactoring' de Martin Fowler e 'Building Microservices: Designing Fine-Grained Systems' de Sam Newman ou 'Building Evolutionary Architectures'.
por Patrick Kua, Rebecca Parsons, Neal Ford.
O negócio da empresa é baseado na prestação de serviços bastante caros, mas o cliente paga por uma qualidade fenomenal, que resulta da expertise, padrões internos e, claro, das pessoas. Portanto, é vital contratar as pessoas certas.
Quem são as pessoas certas? Claro que isso varia para cada um. O ThoughtWorks definiu que, para seu modelo de negócio, os critérios mais importantes para os desenvolvedores são:
- Capacidade de programação em par. Trata-se de capacidade, e não experiência ou habilidade. Ninguém espera que venham pessoas que praticam programação em par há 5 anos. Mas ser receptivo à opinião dos outros, saber ouvir — essa é uma habilidade necessária.
- Habilidade para escrever testes, e idealmente praticar TDD.
- Compreender SOLID e OOP e ser capaz de aplicá-los.
- Apresentar sua opinião. Um consultor precisa trabalhar com os desenvolvedores do cliente, com outros consultores, e não adianta muito se a pessoa consegue fazer algo bem, mas é completamente incapaz de comunicar isso aos outros membros da equipe.
Agora é importante avaliar exatamente essas habilidades no candidato. E aqui quero compartilhar minha experiência em entrevistas na ThoughtWorks. Vou dizer de imediato que fui para Cingapura e passei, mas o processo de recrutamento é padronizado e não deve diferir muito de país para país.
Etapa 0. RH
Como é comum, a entrevista de 20 minutos com o RH. Não vou me alongar sobre isso, só vou dizer que nunca antes conheci um RH que pudesse falar por 15 minutos sobre a cultura de desenvolvimento da empresa, por que eles aplicam TDD, por que programação em par. Normalmente, nessa questão, os RHs desanimam e falam que o processo deles é comum: desenvolvedores desenvolvem, testadores testam, gerentes supervisionam.
Etapa 1. Como você é em OOP, TDD?
Uma hora e meia antes do início da entrevista, recebi a tarefa de criar um simulador do Mars Rover.
Tarefa do Mars RoverUm grupo de rovers robóticos deve ser aterrissado pela NASA em um platô em Marte. Esse platô, que é curiosamente retangular, deve ser navegado pelos rovers para que suas câmeras a bordo possam obter uma visão completa do terreno ao redor para enviar de volta à Terra. A posição e a localização de um rover são representadas por uma combinação de coordenadas x e y e uma letra representando um dos quatro pontos cardeais. O platô é dividido em uma grade para simplificar a navegação. Uma posição de exemplo poderia ser 0, 0, N, 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 do seu lugar atual. 'M' significa mover-se para frente um ponto da grade e manter a mesma direção.
Pressuponha que o quadrado diretamente ao Norte de (x, y) é (x, y+1).
ENTRADA:
A primeira linha de entrada são as coordenadas do canto superior direito do platô, as coordenadas do canto inferior esquerdo são consideradas 0,0.
O restante da entrada é informação sobre os rovers que foram implantados. Cada rover tem duas linhas de entrada. A primeira linha fornece a posição do rover, e a segunda linha é uma série de instruções dizendo ao rover como explorar o platô. A posição é composta por dois inteiros e uma letra separados por espaços, correspondendo às coordenadas x e y 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 tenha terminado.
SAÍDA:
A saída para cada rover deve ser suas coordenadas finais e direcionamento.
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 do usuário está fora do escopo.
Resolver o problema seguindo uma abordagem TDD (Desenvolvimento Orientado a Testes) será preferido.
No curto prazo disponível, estamos mais preocupados com a qualidade do que com a completude.
*Não posso divulgar a tarefa que me enviaram, é uma tarefa antiga que foi dada há alguns anos. Mas acredite, o fundamental permaneceu o mesmo.
É importante prestar atenção aos critérios de avaliação. Quantas vezes você se deparou com a situação em que coisas importantes para o candidato não têm relevância na avaliação e vice-versa? Nem todos pensam da mesma forma que você, mas muitos podem adotar seus valores e segui-los, se forem claramente descritos. Assim, dos critérios de avaliação, fica claro que as habilidades mais importantes nesta etapa são
- TDD;
- A capacidade de usar OOP e escrever um código mantível;
- habilidades em programação em pares
Então, fui avisado para que eu gastasse essas 1,5 horas pensando sobre como eu iria abordar a tarefa, e não escrevendo código. O código será escrito em conjunto.
Quando nos falamos, o pessoal resumiu quem são e no que trabalham e sugeriu que começássemos o desenvolvimento.
Durante toda a entrevista, em nenhum momento tive a sensação de estar em uma entrevista. A sensação é a de que você está desenvolvendo código em equipe. Se você fica preso em algum lugar, eles ajudam, orientam, discutem, até mesmo debatem entre si sobre a melhor forma de fazer. Na entrevista, eu esqueci como verificar se um método lança uma exceção no JUnit 5 — eles sugeriram continuar escrevendo o teste enquanto um deles pesquisava como fazer isso.
Literalmente algumas horas após a entrevista, recebi um feedback construtivo — o que foi bem e o que não foi. No meu caso, fui elogiado pelo uso de classes Seladas como alternativa ao objeto null; pelo fato de antes de escrever o código, ter escrito em pseudocódigo como eu gostaria de controlar o rover, e assim obtive um esboço das classes, pelo menos aquelas envolvidas na API do robô.
Etapa 2. Conte-nos
Uma semana antes da entrevista, pedi para preparar uma apresentação sobre qualquer tema que me interessasse. O formato é simples e familiar: 15 minutos de apresentação, 15 minutos de perguntas e respostas.
Escolhi Clean Architecture do Uncle 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 de estresse — eu não teria conseguido. Mas, mais uma vez, nunca tive a sensação de que estava em uma entrevista. Tudo como de costume — eu falo, eles escutam atentamente. Até mesmo a tradicional sessão de perguntas e respostas não parecia uma entrevista, viu-se que as perguntas não eram feitas para 'afundar', mas aquelas que realmente os interessavam na minha apresentação.
Algumas horas após a entrevista, recebi o feedback — a apresentação foi muito útil e eles realmente desfrutaram de ouvi-la.
Etapa 3. Código de Qualidade de Produção
Avisando que esta é a última fase das entrevistas técnicas, pediram que eu levasse o código para um estado pronto para produção em casa, após o qual enviaria o código para revisão e agendaria entrevistas, onde os requisitos da tarefa mudariam e o código exigiria modificações. Apressando-me, posso dizer que a revisão de código é feita às cegas, os revisores não conhecem nem a posição para a qual o candidato está se candidatando, não veem seu CV, nem mesmo sabem seu nome.
A chamada e, novamente, alguns caras do outro lado do monitor. Tudo como na primeira entrevista: o principal é não esquecer do TDD, contar o que você faz e por quê. Se você não praticou TDD antes, recomendo começar a fazer isso imediatamente, não porque é necessário nas empresas, mas porque simplifica muito a sua vida e reduz o nível de estresse, se você quiser. Lembre-se de como era tentar encontrar de forma frenética um erro com o debugger, que só se reproduz no navegador, e que você não conseguia reproduzir com os testes? Agora imagine ter que caçar esse tipo de erro durante uma entrevista — algumas mechas brancas de cabelo garantidas. O que o TDD nos proporciona? Você altera o código e, para sua surpresa, descobre que agora os testes falharam, e você não consegue identificar o erro de primeira? Ok, dizemos aos entrevistadores “Ops”, pressionamos Ctrl-Z e começamos a avançar em pequenos passos. E sim, a habilidade de desenvolver usando TDD é algo que você precisa cultivar, a capacidade de ir em direção ao objetivo de tal forma que seus testes estejam constantemente verdes, e não vermelhos por meio dia, porque “você está fazendo uma grande refatoração”. Isso é uma habilidade tão importante quanto saber escrever código mantível ou código de alto desempenho.
Portanto, quão bem seu código se adapta às mudanças depende da estrutura que você inicialmente implementou, de quão simples ela é e de quão bons são seus testes.
Após a entrevista, recebi um feedback em algumas horas. Neste ponto, percebi que praticamente passei e que falta pouco para “encontrar o Fowler”.
Etapa 4. Final. Bastante perguntas técnicas. Queremos saber quem você é!
Para ser honesto, essa abordagem me deixou um pouco perplexo. Como é possível entender quem eu sou em apenas uma hora de conversa? E, além disso, como se pode fazer isso falando um idioma que não é o meu nativo, e, para ser sincero, fazendo isso de forma bastante claudicante e desarticulada? Em entrevistas anteriores, para mim foi mais fácil contar sobre mim do que responder a perguntas, e a culpa é do meu sotaque. Pelo menos um dos entrevistadores era asiático — e seu sotaque, bem, digamos que é um tanto peculiar para o ouvido europeu. Portanto, decidi adotar uma abordagem proativa — preparar uma apresentação sobre mim e, no início da entrevista, sugerir apresentar isso. Se eles concordarem, ao menos haverá menos perguntas para mim; se rejeitarem a proposta, bem, três horas da minha vida gastas na apresentação não é um preço tão alto. Mas o que escrever na apresentação? Uma biografia — Nasceu aqui e ali, foi para a escola, se formou na universidade — quem se interessa por isso?
Se você pesquisar um pouco sobre a cultura da ThoughtWorks, pode encontrar um artigo de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], que descreve os 3 Pilares: Sustentabilidade nos Negócios, Excelência em Software e Justiça Social.
Supondo que já tenham checado a Excelência em Software, resta mostrar Sustentabilidade nos Negócios e Justiça Social.
E decidi me concentrar no último.
Para começar, falei sobre por que a ThoughtWorks — ainda na faculdade, li o blog de Martin Fowler, daí veio meu amor pelo Clean Code.
Os projetos também podem ser apresentados de diferentes ângulos. Desenvolvi software para a medicina que facilitou a vida dos pacientes e, segundo rumores, até salvou uma vida. Também desenvolvi software para bancos, que também é uma forma de simplificar a vida dos cidadãos. Especialmente se o banco for utilizado por cerca de 70% da população do país. Não estou falando do Sberbank e nem da Rússia.
Quer saber mais sobre mim? Ok. Meu hobby é fotografia, de uma forma ou de outra, tenho uma câmera nas mãos há cerca de 10 anos, tenho algumas fotos que não me envergonha mostrar. Também, durante um tempo, ajudei um abrigo de gatos: fotografei gatos que precisavam de um lar permanente. E com boas fotos, é bem mais fácil encontrar um novo lar para um gato. Provavelmente, fotografei cerca de cem gatos 🙂
No final das contas, 80% da minha apresentação estava preenchida com gatos.
Logo após a apresentação, o RH me escreveu que ainda não sabia os resultados da entrevista, mas que todo o escritório estava impressionado com os gatos.
No final das contas, recebi um feedback — todos se mostraram satisfeitos com minha pessoa.
Mas o RH, na conversa final, mencionou de forma cuidadosa que a Justiça Social é muito boa e necessária, mas nem todos os projetos são assim. E perguntou se isso me assustava. De forma geral, eu exagerei um pouco com a Justiça Social, acontece 🙂
Resultado
Como resultado, já trabalho há vários meses em Cingapura na Thoughtworks, e vejo que muitas empresas aqui também adotam as 'melhores práticas de entrevista' do Google, usando folhas e quadro branco para codificação, mesmo sabendo que conhecimentos além de Spring, Symfony, RubyOnRails (marque o necessário) não são exigidos no trabalho. Os engenheiros tiram uma semana de férias antes da entrevista para 'se preparar'.
Na Thoughtworks, além das exigências razoáveis para os candidatos, princípios como estes são priorizados:
Alegria de Entrevistar. Para ambas as partes. De fato, se você deseja atrair os melhores talentos (e quem não quer?), a entrevista não deve ser um mercado onde se escolhem escravos, mas uma oportunidade em que tanto o empregador quanto o candidato se avaliam mutuamente. E se o candidato associa emoções positivas à empresa, é bem provável que ele escolha exatamente essa empresa.
Múltiplos entrevistadores para mitigar viés. Na Thoughtworks, a programação em par é o padrão de fato. E se essa prática pode ser aplicada em outras áreas, a TW se esforça para fazê-lo. Em cada etapa, a entrevista é conduzida por duas pessoas. Assim, cada candidato é avaliado por no mínimo 8 pessoas, e a TW procura selecionar entrevistadores com diferentes formações, áreas (não apenas técnicos) e gêneros.
No final, a decisão de contratação será tomada com base na opinião de pelo menos 8 pessoas, e ninguém tem o direito de um voto de minerva.
Contratação baseada em atributos Em vez de tomar decisões com base no "gosto ou não gosto" do candidato, foi desenvolvida uma forma para cada função e cada etapa, incluindo os atributos avaliados. Ao avaliar, é muito recomendado focar na capacidade de aplicar certas habilidades, em vez da experiência em uma habilidade específica. Portanto, se um candidato não teve a oportunidade de aplicar habilidades como TDD, mas ainda assim tenta usá-las e ouve conselhos sobre o uso correto, ele tem todas as chances de passar na entrevista.
Certificados educacionais não são necessários A TW não exige certificados ou formação obrigatória em Ciência da Computação. Apenas habilidades são avaliadas.
Esta foi a primeira entrevista, das que fiz em empresas estrangeiras, para a qual não precisei me preparar. Após cada fase, não me senti espremido como um limão; pelo contrário, fiquei feliz por poder aplicar as melhores práticas e por perceber que as pessoas do outro lado da tela valorizam isso e também as utilizam todos os dias.
Após alguns meses, posso dizer que as expectativas foram completamente atendidas. O que torna a ThoughtWorks diferente de uma empresa comum? Em uma empresa comum, você pode encontrar bons desenvolvedores e pessoas agradáveis, mas na TW a concentração deles é muito maior.
Se você deseja se juntar à ThoughtWorks, pode conferir as vagas abertas
Também sugiro dar uma olhada nas vagas interessantes:
Líder de Engenharia de Software: , , ,
Engenheiro de Software Sênior: , , ,
Engenheiro de Software: , ,
Engenheiro de Dados Sênior:
Analista de Qualidade:
Infraestrutura: , ,
(Quero avisar honestamente que o link é de referência; se você passar na TW, receberei um bônus agradável). Escolha o escritório que mais lhe agrada, não é necessário se limitar apenas à Europa; afinal, a cada dois anos a TW terá prazer em transferi-lo para outro país, pois essa é parte da política da ThoughtWorks, assim a cultura se espalha e é equilibrada.
Sinta-se à vontade para fazer perguntas nos comentários ou pedir que eu recomende você.
Se o tema parecer interessante, escreverei sobre como é trabalhar na ThoughtWorks e como é viver em Cingapura.
Fonte: habr.com
