Como construí minha carreira na Amazon, onde fui levado por engano

Hoje estou comemorando cinco anos na Amazon. Durante este tempo, eu transferi mais de 500.000 linhas de código para produção, inspecionei o código de outra pessoa mais de 500 vezes, projetei, desenvolvi, implantei e suportei sistemas de grande escala que são usados ​​por milhares de clientes ao redor do mundo. Sou considerado um dos principais líderes técnicos da equipe.



Mas não foi sempre assim. Em 2015, consegui um emprego como desenvolvedor de software de primeira linha. E em vão. Eu era um verdadeiro impostor. Mas minhas escassas habilidades de engenharia não me impediram de ser promovido para o segundo lugar no final. Quero compartilhar minha história para ajudar outros impostores a terem sucesso nas empresas FAANG - bem, ou em qualquer outra.



Como entrei sorrateiramente na Amazon



Admiro as pessoas que conseguiram passar por todo o ciclo seletivo em uma das empresas FAANG. Trata-se de uma série de entrevistas, de manhã à noite, durante as quais o candidato é questionado sobre conhecimentos técnicos e qualidades pessoais de cinco diferentes colaboradores da empresa. Para passar neste exame, você precisa gastar centenas de horas preparando-se, estudando exaustivamente estruturas de dados e algoritmos complexos e resolvendo problemas durante meses. Tudo isso requer tanta paciência, determinação e perseverança quanto o processo de publicação de um livro.



Meu caminho contornou todas essas dificuldades. Em 2014, a Amazon estava fazendo entrevistas de emprego no campus para estagiários de verão. Alguns de meus colegas estudantes foram para lá antes de mim. Todos eles voltaram com histórias de perguntas intrigantes de programação que haviam sido feitas.



Fiz quatro exames naquela semana e dormi em média quatro horas por dia. Consegui reservar três horas de preparação. Houve duas entrevistas. As perguntas sobre programação que recebo são incrivelmente fáceis. Um era sobre manipulação de bits, o outro era sobre o uso de listas vinculadas e também tive que falar sobre tabelas de hash. Isso é tudo. Tive sorte.



Os estagiários da Amazon, se forem bem-sucedidos, recebem uma oferta para se mudar para um desenvolvedor em tempo integral do primeiro nível de entrada. Eles não precisam repetir as entrevistas. Eu estava fazendo meu estágio em Seattle - meticulosamente esculpindo um site Ruby on Rails do zero. Recebi uma oferta e comecei como desenvolvedor de software em 2015 na Virgínia.



Sobre a escassez de meu conhecimento



Os desenvolvedores do Rank 1 devem ser bem versados ​​em estruturas de dados avançadas: heaps, gráficos, árvores de prefixo. Eu nem sabia o significado dessas palavras. Os desenvolvedores do Rank 1 devem ser capazes de estimar a complexidade temporal e espacial dos algoritmos para classificação, pesquisa, inserção e divisão. Eu não diria a você a complexidade de tempo de uma pesquisa banal em profundidade em uma árvore binária.



Por que eu tenho tantas lacunas de conhecimento? Por duas razões.



Em primeiro lugar, estudei engenharia da computação, não ciência da computação. O foco estava na integração de software e hardware, e não no desenvolvimento de grandes sistemas. Essa orientação me ensinou a resolver problemas complexos em condições duvidosas, mas o programa não fornecia nenhuma análise detalhada de estruturas de dados e algoritmos. Em segundo lugar, não passei por um processo de preparação completo, não passei centenas de horas estudando - então não aprendi.



Eu mesmo percebi que não estava acompanhando. No início, a síndrome do impostor me atormentou com uma força terrível.



Primeiras panquecas



Cada inspeção de código foi um desastre. Enviei um snippet para revisão (na forma de um pedido de aceitação de alterações, por exemplo), ele me foi devolvido com oitenta comentários. Não vai dar certo. Corrigi e enviei uma nova versão. Mais cinquenta comentários. Não vai dar certo. E assim por diante.



Com alguns fragmentos, as coisas estavam tão ruins que os colegas simplesmente não sabiam explicar a essência do problema para eu entender. Eles tiveram que baixar o código e reescrevê-lo. Eles queriam me ajudar e foram muito amigáveis, mas eu literalmente fiquei exausto de vergonha. Eu vivia com medo de que as pessoas entendessem: não sou daqui. Não se passou um único dia de trabalho sem pensar que hoje seria demitido.



Expondo o impostor



Aos poucos, fui me levantando. Por fim, comecei a cumprir os prazos e a fornecer consistentemente o código para produção. Cerca de nove meses depois, desenvolvi autoconfiança. Decidi que era hora de me livrar da síndrome do impostor de uma vez por todas. Procurei problemas no LeetCode, apenas para provar a mim mesmo que estava no meu lugar. Lembro-me de pensar: “Agora sou um desenvolvedor completo na Amazon. Tenho commits em produção. Por que eu não consigo lidar com essas tarefas simples? "



Eu escolhi um dos mais fáceis no LeetCode - e não consegui resolver. Escolhi outro - e também não pude. E o terceiro e o quarto. Então ficou claro para mim que eu não sofria de nenhuma síndrome. Eu sou um impostor.



Ser, não parece ser



Depois de dois anos e meio, fui promovido a um desenvolvedor de segundo nível. Um desenvolvedor de segunda categoria é capaz de criar e manter um grande sistema por conta própria com o mínimo de ajuda externa. Então, como eu fiz isso? Como consegui reinterpretar as regras do jogo a meu favor?



Bem ... de jeito nenhum. Fraude não está em uso na Amazon. O sistema não pode ser reproduzido. “Finja ser um especialista até ter sucesso” é um conselho muito comum e muito ruim. Isso não funciona. A única maneira de ser apontado como desenvolvedor de nível 2 é se tornar um desenvolvedor de nível 2.



A promoção é um processo cansativo. Você precisa descrever seus méritos e realizações em mais de vinte páginas de documentação, tanto que seus colegas e chefes acreditem. Você precisa coletar constantemente métricas e evidências de que seu progresso está em um nível superior. Você pode contar com um aumento apenas se mantiver consistentemente a barra do próximo nível por seis meses, ou mesmo um ano inteiro.



Você provavelmente já ouviu a frase: "Nossa personalidade é formada pelo que fazemos regularmente." Abaixo, direi quais ações tomei para deixar de ser um impostor e me estabelecer como um desenvolvedor de nível superior.



O que eu fiz



Sintonizando para maximizar a aceitação do feedback Os



recém-chegados ao FAANG costumam ter egos inflados. Isso os priva da capacidade de aceitar e levar em consideração as críticas construtivas dos colegas. Mas esses colegas são pessoas inteligentes, cada um com sua experiência única no campo de TI por trás deles.



Não tive problemas de auto-estima. De forma amigável, não tive nada a ver com a empresa. Portanto, quando recebi feedback, ouvi e ouvi com atenção.



As observações dos colegas foram verdadeiras, controversas ou incorretas. Se a observação estava correta, segui o conselho sem reservas. Se fosse sobre algo polêmico, primeiro tentei entender o ponto de vista de outro desenvolvedor, e só então - transmitir o meu próprio. E, de repente, eu estava ouvindo até mesmo os comentários errados.



Nesse caso, a linha de pensamento era: “Por que tenho certeza de que estou certo? O que levou uma pessoa a essa ideia? Posso esclarecer de alguma forma para que tal reação não surja? " Isso é o que chamo de abertura máxima. Pessoas inteligentes, mesmo quando estão erradas, partem de algo em suas conclusões. Eu descobri de onde era e melhorei meu código com essas informações em mente.



Perguntas estúpidas feitas Os



recém-chegados às empresas FAANG frequentemente tentam não fazer perguntas - eles têm medo de ser mal pensados. Este elemento da síndrome do impostor paradoxalmente coexiste com a presunção exagerada. Bem, eu, como um verdadeiro impostor, entendi perfeitamente que minhas perguntas eram estúpidas. Isso não me incomodou.



Por exemplo:



« , . , ?»



« , ?»



« , . - ?»


Muito em breve, consegui centenas de marcadores, coletei toneladas de informações adicionais e tive muito sucesso na participação em reuniões.



Encontrou um Inspetor de código inquieto



A princípio, é muito importante que o maior número possível de outros desenvolvedores analise seu código. Cada funcionário conduzindo uma inspeção terá suas próprias preferências, irritantes, irritantes. Mas é ainda mais importante descobrir o inquieto inspetor.



Existe um em qualquer equipe. Seu trabalho nunca fica satisfeito. Ele se apega ao nome de cada variável, cada log, cada parâmetro de API selecionado. Fiz um esforço especial para encontrar essa pessoa e lançar meu código para ela com a maior freqüência possível. Por quê? Porque eu entendi: quanto mais comentários construtivos eu receber, mais rápido será o treinamento.



Usou padrões existentes para evitar erros Os



juniores frequentemente tentam reinventar a roda. A maioria das tarefas de desenvolvimento não são novas. Antes de começar a escrever o código solicitado, estava procurando soluções semelhantes em recursos internos. Examinei vários exemplos diferentes, investigando como o código é estruturado neles. Em seguida, voltei-me para o código da minha equipe e descobri a melhor forma de vincular o novo fragmento ao sistema geral.



Adotei a mesma abordagem ao escrever documentação de design e relatórios post mortem. Amostras primeiro, depois ações.



Focado na correção e adequação



Evitei a armadilha dos custos irrecuperáveis. Se estou fazendo algo errado, não importa se já gastei quatro horas nisso. Eu sabia que teria que deixar de lado o que havia desenvolvido e refazer da maneira certa.



Para cem linhas de código enviadas para inspeção, havia duzentas e cinquenta linhas de lixo que escrevi e joguei fora. Tentei garantir que cada uma dessas cem linhas fosse compreensível, escrita com propósito e necessária para alguma coisa. Agora meu código geralmente recebe luz verde após uma ou duas revisões.



Jogando-se no calor



Você nunca se sentirá "pronto" para trabalhar em funções-chave, implantar projetos na produção, conduzir entrevistas e eliminar emergências. A melhor maneira de se preparar para tudo isso é pegar e fazer.



Na primeira oportunidade, disse simplesmente ao meu chefe: estou pronto. Mesmo que antes não tivesse tido a oportunidade de observar detalhadamente as ações alheias, como costuma ser aconselhado. Às vezes tinha que pedir ajuda ou alguém dos meus colegas para acompanhar o meu trabalho. Mas, em última análise, me permitiu expandir minha zona de conforto e acelerar meu crescimento.



Tomando iniciativa nas pequenas coisas



percebi oportunidades de melhorar a excelência operacional da equipe, processos de trabalho, experiência de desenvolvimento. Mais de uma ou duas vezes, voluntariamente assumi tarefas chatas: automatizei procedimentos que eram executados manualmente, finalizei a documentação, melhorei o pipeline de CI / CD, refatorando o código legado.



Tentei ser profissional



A programação é um tipo de criatividade baseada na lógica. Cada tarefa, cada nova função, eu percebi como uma folha em branco na qual você pode mostrar sua habilidade e sair da criação.



O desenvolvedor de segunda camada deve ser um engenheiro de software ou um profissional, de acordo com Stephen Pressfield, autor de The War of Art. Usei toda a minha força para escrever um código limpo (você definitivamente deveria ler o livro de mesmo nome) e criar soluções bonitas e elegantes.



Ele indicou claramente seu desejo de um aumento



Nas empresas FAANG, ninguém oferece um aumento - você mesmo pergunta a eles, e mais de uma vez. Se isso não for feito, o processo se arrastará por muitos meses.



Em conversas privadas com o chefe, deixei claro que queria ser promovido. Pedi feedback para entender quais áreas estavam cedendo. Avaliei objetivamente os resultados do trabalho concluído e aceitei as críticas quando me referiram. Procurei oportunidades para aprimorar habilidades e fechar as lacunas. Se consegui mostrar algumas habilidades, tentei manter o feedback por escrito. Afinal, você não pode prever quando a próxima reestruturação ocorrerá e seu chefe mudará.



Colocando trabalho para promoção à frente de outros



Eu entendi: você não pode trabalhar única e exclusivamente para promoção. Se todos fizerem isso, a atmosfera de equipe definitivamente se tornará inadequada para a vida. Mas, ao mesmo tempo, literalmente coloquei as tarefas de que precisava para promoção em primeiro lugar.



Ou seja, se eu precisava focar em uma função importante, cujos prazos eram apertados, assumi desde a manhã. Assim, poderia ter certeza de que teria tempo suficiente para fazer bem o trabalho. Se eu precisasse conduzir mais ativamente a inspeção do código, as horas da manhã eram gastas nisso. Se eu precisasse comparecer às entrevistas com mais frequência, comecei meu dia de trabalho inscrevendo-me nas próximas.



Constantemente coletando evidências do meu sucesso



Não se pode prescindir da capacidade de apresentar as próprias realizações por meio de uma combinação de indicadores quantitativos e qualitativos.



Antes de colocar a tarefa em prática, procurei métricas que descrevessem o estado atual do sistema. Após a conclusão do trabalho, examinei os novos indicadores e fiz cálculos para entender em que medida minhas ações influenciaram a situação. E, por fim, registrei tudo relacionado à tarefa na documentação que deveria servir de justificativa para o aumento: análise STAR, indicadores quantitativos, links para resultados de inspeção de código, gráficos e outras relíquias de trabalho.



Eu percebi o que depende de mim e o que não



Eu entendi que tudo pode acontecer. Às vezes, uma equipe perde funções importantes. Às vezes, os projetos são fechados. Às vezes, devido à reestruturação, mudanças de gestão. Às vezes, o pipeline de CI / CD já é perfeito e simplesmente não há nada a ser melhorado.



E ao mesmo tempo, percebi que se me concentrar em trabalhar até o limite das possibilidades e abordar as tarefas profissionalmente, estarei pronto para o momento em que surgir a oportunidade de me mostrar. A oportunidade surgiu - ele se mostrou um profissional. Isso trouxe mais algumas oportunidades - novamente, fiz tudo no nível. Etc.



Reflexões



A “cultura Leetcode” que se desenvolveu no processo de contratação está prejudicando o negócio?



Consegui ganhar uma posição segura na Amazon, embora quando cheguei pela primeira vez, as tarefas com Leetcode eram muito difíceis para mim. Então, quando eu mesmo comecei a conduzir entrevistas, é claro que desmontei propositalmente todos os algoritmos e estruturas de dados necessários para poder avaliar as respostas dos candidatos.



Acho que a abordagem atual compensa. As empresas estão interessadas em pessoas que tenham perseverança e motivação para aprender coisas novas e usar essas informações em conjunto com as habilidades existentes. Os processos estabelecidos fazem um bom trabalho na seleção dessas pessoas.



Então é mais fácil entrar no rank 1 de desenvolvedores por meio de um estágio?



Eu não diria isso. Essas duas entrevistas geralmente não são mais fáceis para estagiários do que cinco entrevistas para funcionários em tempo integral. Quando fiz uma entrevista em 2014, parei sem sorte. Se alguém decidir que vai definitivamente receber as mesmas perguntas simples que eu, então está se sabotando.



Na empresa, os mesmos requisitos são impostos aos estagiários e aos desenvolvedores de primeira linha. Cada aspecto do trabalho é examinado quase sob um microscópio. Conheci muitos programadores que concluíram o estágio, mas nunca receberam uma oferta de emprego.



Durante esses cinco anos, eu mesmo dei aulas para vários estagiários e agora, olhando o processo do outro lado, entendo o quão alto é a barreira para eles. Agora, olhando para trás e avaliando meu trabalho de estágio, percebo que fiz um bom trabalho naquele verão e realmente merecia ser promovido a desenvolvedor.



Então a Amazon não deveria ter contratado você?



Até recentemente, eu estava inclinado a responder afirmativamente. Não há dúvida de que meu conhecimento de programação na época não atendia aos requisitos. Mas aos poucos cheguei à conclusão de que, no longo prazo, a empresa tomou a decisão certa de me contratar. Eu definitivamente trouxe benefícios tangíveis para a Amazon.



Tornei a AWS mais segura, participei de programas de educação e vendas. Forneci soluções para um grande número de clientes internos e externos. Eu dei cursos introdutórios para públicos de várias centenas de pessoas. Tornei-me um mentor de muitos programadores que aspiravam a entrar em desenvolvedores de segundo nível. Antes de entrar para a Amazon, fui capitão dos times de futebol e basquete, que chegaram às quartas de final na Virgínia. Ao longo dos anos, aprimorei minhas habilidades de trabalhar com pessoas e liderar pessoas - essas habilidades foram úteis na Amazon. No futuro, espero dar ainda mais à comunidade de desenvolvedores porque sei o que é ser um impostor.



All Articles