tl; dr Nas últimas décadas, a moda de entrevistar programadores mudou várias vezes, e cada um deles parece ridículo em retrospecto. Finalmente, descobrimos o verdadeiro segredo de entrevistas eficazes ou fomos levados pela próxima tendência da moda, que em dez a vinte anos parecerá igualmente ridícula.

Quando pergunto às pessoas das grandes empresas de tecnologia da moda por que é tão necessário perguntar sobre algoritmos em uma entrevista, a resposta mais comum é algo como: “Temos uma escala assim, não podemos permitir que ninguém escreva O(n^2) acidentalmente O(n^2) e bateu todo o sistema " ¹ . O que é especialmente engraçado, ultimamente, tenho aplicado muito esses algoritmos na prática e resolvido problemas reais, mas não posso passar por entrevistas nas quais as pessoas perguntam sobre eles! Você acha que estou falhando metade das entrevistas ou algo assim? Não, mais da metade. Eu participei de cerca de 40 entrevistas "reais" e talvez tenha passado uma ou duas. Ou não um único ² .

Quando escrevi um rascunho deste artigo, meus amigos o acharam chato porque eu falhei em muitas entrevistas. Eles dizem que todas as falhas devem ser tabuladas porque ninguém lerá dez páginas de texto com uma longa lista de falhas. Boa dica. Já trabalhando em uma mesa.

Vejamos alguns exemplos.

Em uma grande empresa em que trabalhei, a equipe escreveu uma biblioteca base com sua própria implementação de uma matriz dinâmica. Se não houvesse tamanho suficiente durante a operação, a implementação adicionou um número fixo de linhas à matriz e, em seguida, copiou a matriz antiga para uma nova matriz de tamanho um pouco maior. Este é um exemplo clássico de implementação inadequada de uma matriz dinâmica , pois leva a um aumento linear no tempo, em vez do tempo constante amortizado . Este é um exemplo tão clássico que é frequentemente usado como canônico na explicação da análise de depreciação.

Nas grandes empresas de TI, as entrevistas telefônicas típicas se enquadram em três categorias:

1. Uma pergunta “simples” sobre programação / algoritmo, talvez primeiro com uma questão de aquecimento “muito simples”.
   
2. Uma série de questões algorítmicas / de programação "muito simples".
   
3. Um monte de fatos conhecidos (raramente para boas posições, mas frequentemente para posições de baixo nível ou não criativas).

Esse problema de implementação de array é considerado tão simples que se enquadra na categoria "muito fácil" e é um aquecimento para uma pergunta "real" ou vem com várias perguntas simples. E, no entanto, em nossa empresa, essa matriz dinâmica foi responsável por cerca de 1% da carga total no coletor de lixo no código da JVM (foi a segunda maior fonte de alocações de memória em todo o código), bem como por uma parcela significativa da carga da CPU.

Felizmente, essa implementação não foi usada como uma matriz dinâmica universal, mas foi criada apenas com a ajuda de um shell semi-especializado, sendo responsável por "apenas" 1% da pressão no GC. Se perguntado na entrevista, a maioria dos membros dessa equipe responderia corretamente. Meu patch trouxe ao empregador mais dinheiro em um ano do que eu ganhei na minha vida.

Era a segunda maior fonte de alocações de memória, a principal era a conversão de um par de valores long em matrizes de bytes da mesma biblioteca base. Aparentemente, alguém escreveu ou copiou uma função hash que tomou uma matriz como entrada e, em seguida, alterou o código para pegar duas matrizes e trabalhar com elas em uma sequência de uma função hash antiga, como byte[], byte[] . Para chamar essa função em dois longos, eles usaram a conveniente função de conversão de long em byte[] na biblioteca de utilitários amplamente usada. Além de destacar byte[] e colar por long lá, essa função também altera a ordem de bytes long (aparentemente, a função foi projetada para converter valores long em ordem de bytes da rede).

Infelizmente, mudar para uma função hash mais apropriada foi considerada uma alteração muito séria; portanto, meu patch consistiu em alterar a interface da função hash para demorar um par de longos em vez de um par de matrizes de bytes e remover uma etapa separada para alterar a ordem dos bytes (uma vez que a função hash já foi alterada para ele, não foi necessário um passo separado). Eliminar essas operações desnecessárias trouxe ao empregador mais dinheiro em um ano do que eu ganhei na minha vida.

A otimização não é tecnicamente uma questão de algoritmos, mas na prática é constantemente solicitada. Em resposta a uma pergunta sobre algoritmos, eles geralmente me perguntam: “Você pode acelerar?” A resposta a essa pergunta geralmente inclui uma otimização simples, que acelera o código várias vezes.

Um exemplo específico que me pediram duas vezes durante a entrevista: você armazena identificadores como ints, mas, a partir do contexto, segue que os identificadores são compactados densamente, para que possam ser armazenados como um campo de bits. Mas a solução existente no mundo real está tão longe da resposta esperada sobre o campo de bits que dificilmente é possível alcançar a aceleração várias vezes. Provavelmente, a entrevista terminará aí.

Outro exemplo de uma pergunta simples sobre algoritmos é a configuração real do BitFunnel , o índice de pesquisa usado no Bing ³ .

A descrição do contexto completo dessa empresa em particular levará muito tempo, mas, em resumo, você precisará configurar um conjunto de filtros Bloom. Uma maneira é escrever uma função de otimização de acordo com o modelo da caixa preta, que, usando descida gradiente, tenta encontrar a solução ideal. Eles fizeram isso, mas a função mostrou algumas propriedades estranhas e a configuração de saída nunca funcionou perfeitamente. Isso foi corrigido diluindo os filtros Bloom, ou seja, alocando ainda mais recursos (e, portanto, dinheiro) para o problema.

Ao analisar as oportunidades de otimização, você pode perceber que a operação fundamental no BitFunnel é equivalente à multiplicação de probabilidades. Portanto, para qualquer configuração específica, você pode simplesmente multiplicar algumas probabilidades - e determinar como a configuração funcionará. Como o espaço de configuração não é tão grande, você pode percorrer todas as opções possíveis e escolher a melhor. Na realidade, isso não é inteiramente verdade, porque a multiplicação de probabilidades implica alguma independência, o que não ocorre na realidade, mas o método ainda funciona bem pela mesma razão pela qual a filtragem de spam Bayesiana ingênua funcionou muito bem, o que incorretamente assume uma probabilidade independente de ocorrência na carta quaisquer duas palavras arbitrárias. Para uma solução completa, você pode analisar as interdependências. Embora isso esteja provavelmente fora do escopo da entrevista.

Estes são apenas três exemplos que me vieram à mente, e eu sempre me deparo com coisas semelhantes e posso criar dezenas de exemplos, talvez mais de cem, se me sentar e tentar listar tudo em que trabalhei. E mais de cem exemplos nos quais alguém (ou ninguém) trabalhou. Ambos os exemplos, bem como aqueles que omiti, têm as seguintes propriedades:

1. Um exemplo pode ser formulado como uma pergunta para uma entrevista.
   
2. Se a pergunta for formulada, você espera que a maioria (ou todos) os funcionários da equipe relevante saibam a resposta correta.
   
3. Economizar dinheiro com essa correção trará ao empregador mais dinheiro em um ano do que eu ganhei em minha vida.
   
4. O problema do exemplo persistiu por tempo suficiente, caso contrário, não teria sido percebido.

No início do artigo, observamos que as grandes empresas de TI fazem perguntas sobre algoritmos, pois a ineficiência em larga escala os custará muito. Minha experiência mostra que em todas as empresas entrevistadas há um milhão de exemplos de tais ineficiências. Acontece que as perguntas sobre os algoritmos da entrevista não ajudam a resolver problemas algorítmicos reais no trabalho.

Uma das razões é que as grandes empresas estão tentando encontrar pessoas capazes de resolver quebra-cabeças de algoritmos, mas proíbem esse raciocínio na produção.

Das três soluções para os exemplos acima, duas foram para o prod. Para mim, essa é uma porcentagem normal se eu fosse simplesmente convidado para um projeto aleatório, o qual eu não acompanho constantemente. Os cínicos podem dizer que a porcentagem é ainda alta. Em uma equipe aleatória, os resultados podem ser piores, porque não é benéfico para eles implementar qualquer solução, mesmo que seja eficaz. Afinal, exige que eles testem, integrem e implantem alterações. Novos riscos são criados. Ou seja, peço à equipe que faça algum trabalho e assuma alguns riscos para fazer algo útil para a empresa, mas inútil para si. Apesar de tudo isso, as pessoas geralmente aceitam o código, embora não estejam muito inclinadas a gastar tempo em otimização (o tempo de trabalho será gasto em coisas que são consistentes com os objetivos da equipe) ⁴ .

Suponha que uma empresa se recuse a oferecer quebra-cabeças para entrevistas aos candidatos e incentive os desenvolvedores a usar algoritmos mais simples e relativamente eficientes. É improvável que qualquer um dos exemplos acima possa passar despercebido por muitos anos. O problema provavelmente seria corrigido. Algum desenvolvedor hipotético em uma empresa com criação de perfil de código veria os elementos mais "quentes" no perfil para a biblioteca com mais recursos.

Em dois casos, a solução prática não é algum tipo de mágica de algoritmo, mas apenas uma análise abrangente. O terceiro exemplo é menos óbvio, pois não há ferramenta padrão para analisar o problema. Você pode tentar apresentar o resultado como uma espécie de domínio supremo, afinal, este exemplo é baseado em um artigo científico, que recebeu um prêmio pelo melhor artigo na conferência de maior prestígio em seu campo, mas, na realidade, há matemática no ensino médio, ou seja, para uma solução real para o problema, você só precisa estudar onde esses métodos matemáticos são aplicáveis.

Eu realmente trabalhei em uma empresa que não fazia perguntas sobre algoritmos em entrevistas, mas me concentrava em questões práticas. Durante a minha estadia lá, encontrei apenas uma oportunidade de otimização que quase atende aos critérios acima (devido ao seu tamanho pequeno, ela não vai muito além do terceiro ponto, ou seja, naquela época eu ganhava mais na minha vida do que as economias anuais com a fixação este bug).

Por que essa empresa quase não teve problemas com os plugues de desempenho? Eu acho que o principal motivo é que muitas pessoas pensaram que melhorar a empresa era o seu trabalho. Portanto, os sistemas foram originalmente projetados quase de maneira ideal. Com raras exceções, havia especialistas suficientes que tentaram continuar a beneficiar a empresa, em vez de pessoalmente para eles e sua equipe (o que é completamente diferente do benefício global para a empresa). Assim, sempre houve alguém que resolveu o problema antes que ele me ocorresse.

Em grandes empresas de TI, entrevistar algoritmos com habilidades de codificação de teste geralmente é mais simples do que a triagem inicial por telefone. Normalmente, os problemas de design do sistema não são abordados aqui.

Algum tempo atrás, tentamos fazer uma pergunta sobre algoritmos em uma entrevista presencial. Uma pergunta bastante difícil, mas dentro da estrutura do que você pode encontrar pela triagem por telefone em grandes empresas (mas ainda mais fácil do que você esperaria de entrevistas pessoais). Abandonamos essa prática, porque absolutamente todos os candidatos falharam nessa parte (não perguntamos aos candidatos experientes uma pergunta sobre os algoritmos). Nossa empresa não é tão conhecida a ponto de conseguir novatos que possam responder facilmente a essas perguntas; portanto, esses filtros de triagem de candidatos à moda não funcionam para nós. Nos artigos modernos de contratação, o que fizemos é frequentemente chamado de "abaixar a barra", mas não entendo por que devemos nos preocupar com a altura máxima do salto do candidato se seu trabalho quase (ou nunca) envolve saltos altos. E naqueles casos em que você realmente precisa pular, a barra é ajustada a uma altura de cerca de cinco centímetros.

A julgar pelo desempenho real, era a empresa mais produtiva em que trabalhei. Acredito que as razões estejam na cultura e sejam complexas demais para serem completamente desmontadas em um artigo, mas provavelmente nos ajudou a não filtrarmos bons candidatos usando testes por algoritmos. Sugerimos que as pessoas possam estudar esse material no trabalho se tivermos a cultura certa e os funcionários fizerem a coisa certa, em vez de se concentrarem nas tarefas locais para si ou para seu departamento.

Se outras empresas desejam que as pessoas resolvam no trabalho problemas de algoritmos do mesmo nível que solicitam nas entrevistas, você precisa basicamente incentivar as pessoas a resolver problemas de algoritmos (quando apropriado). Isso pode ser feito além ou mesmo em vez de selecionar candidatos para problemas teóricos.

Apêndice: como chegamos a isso?

Nos bons velhos tempos, perguntas "triviais" eram feitas em entrevistas. As versões modernas podem ficar assim:

• O que é MSI? MESI? MOESI? MESIF? Qual é a vantagem do MESIF sobre o MOESI?
  
• O que um destruidor faz? E se for C ++ 11? E se você chamar o destruidor de subobjetos a partir do destruidor de nível superior, que outros destruidores de subobjetos serão executados? E durante a promoção da pilha? Sob quais circunstâncias você pode evitar chamar std::terminate ?

Ouvi falar dessas entrevistas simples na escola e até vi em algumas empresas a “velha escola”. Isso foi durante a liderança da Microsoft, quando todo mundo procurou uma empresa de sucesso e copiou a Microsoft. O blogueiro de programação mais lido (Joel Spolsky) disse que todos precisam adotar algumas práticas de desenvolvimento do X porque a Microsoft faz isso. Por exemplo, em um dos artigos de programação mais influentes da época, Joel Spolsky introduziu o chamado teste de Joel, que determina o quanto você acompanha empresas como a Microsoft:

12 pontos é excelente, 11 pontos são toleráveis, mas com uma classificação de 10 ou menos, você tem sérios problemas. A verdade é que a maioria dos softwares trabalha em um nível de 2 a 3 pontos, e eles precisam de ajuda séria , porque empresas como a Microsoft trabalham no nível 12 em tempo integral.

De acordo com lendas populares da época, a Microsoft fez perguntas sobre essas perguntas em entrevistas (e eu realmente fiz uma dessas tarefas durante uma entrevista na Microsoft na região de 2001, sem perguntas sobre algoritmos ou programação):

• Como sair do liquidificador se a sua altura é de 1 cm?
  
• Por que as tampas de bueiro são redondas?
  
• A sala sem janelas tem três lâmpadas, cada uma delas controlada por um interruptor do lado de fora. Você está fora da sala e pode entrar apenas uma vez. Como determinar qual interruptor controla qual lâmpada?

Desde que fui entrevistado em uma época de mudanças, pediram-me muitas perguntas simples e várias tarefas (incluindo todas as anteriores). Nas entrevistas da época, as perguntas de Fermi , que tecnicamente não são quebra-cabeças, ainda eram populares. Outra tendência da época foram entrevistas comportamentais sem um único problema técnico.

Seja como for, as pessoas tentaram copiar entrevistas no estilo da Microsoft. Quando perguntei quais quebra-cabeças ou as perguntas de Fermi eram boas, eles me responderam que dessa maneira é possível verificar se o candidato é capaz de refletir, em oposição às questões de conhecimento, que dizem apenas que uma pessoa se lembra de alguma informação. E precisamos de candidatos que possam realmente pensar!

Olhando para trás, agora ficou claro para todos que isso era ineficiente, e copiar todos os truques da Microsoft não tornaria sua empresa tão bem-sucedida porque a Microsoft usava muitos outros truques - eles só são eficazes juntos por causa do efeito de rede. Ao copiar as entrevistas da Microsoft, você será uma empresa que simplesmente realiza entrevistas no mesmo estilo, mas não pode tirar proveito dos efeitos de rede que a Microsoft usou.

Para os candidatos, o procedimento de entrevista era basicamente o mesmo que agora com os algoritmos. Apenas para se preparar para uma entrevista, em vez de "Hackear uma entrevista de programação", você tinha que ler "Como mover o Monte Fuji". Ou seja, você precisava aprender muito conhecimento sobre tarefas que nunca usará no trabalho, em vez de conhecimentos sobre algoritmos que nunca usará da mesma maneira.

Naqueles dias, os entrevistadores encontravam perguntas em livros de preparação de entrevistas, como Como mover o Monte Fuji. Essas perguntas foram feitas aos candidatos que aprenderam as respostas nos mesmos livros. A juventude moderna acha isso ridículo - é óbvio que as perguntas não têm nada a ver com o trabalho, e a probabilidade de uma boa resposta depende mais da preparação da entrevista do que da competência do candidato. Mas a abordagem de hoje não é tão diferente.

Nas últimas décadas, a moda de entrevistar programadores mudou várias vezes, e cada um deles parece ridículo em retrospecto. Finalmente, descobrimos o verdadeiro segredo de entrevistas eficazes ou fomos levados pela próxima tendência da moda, que em dez a vinte anos parecerá igualmente ridícula.

Sem levar em conta a eficiência, os métodos de entrevista no nível meta não mudaram (com exceção da tecnologia de alto nível da empresa de maior prestígio), então tudo é muito parecido com outro hobby da moda, que não difere das práticas ridículas anteriores. Pesquisas empíricas ou uma verificação independente da eficácia de diferentes métodos podem abalar minha opinião.

Inspirado pelo comentário de Wesley Pharmacist-Cassels , recentemente perguntei especificamente aos representantes dos empregadores como eles verificam a eficácia de suas entrevistas e como eles lidam com o viés. Aqui está o que eles responderam (em ordem decrescente de frequência):

• O que? Nada, por que isso?
  
• Realmente não sabemos se nosso processo é eficaz.
  
• Nós apenas sabemos que tudo funciona.
  
• Nós não temos preconceitos.
  
• Teríamos notado viés se houvesse um processo de avaliação.
  
• Alguém estudou e / ou conduziu uma pesquisa, mas não pode dizer nada concreto sobre como foi estudada e por qual metodologia o estudo foi conduzido.

Aplicação: Treinamento

Como na maioria dos problemas reais, é impossível encontrar a única razão pela qual os erros no valor de dezenas e centenas de milhões de dólares permanecem sem produção na produção. Por um lado, encontramos uma espécie de defesa em profundidade com incentivos incompatíveis. Por outro lado, o aprendizado é subestimado .

Eu já mencionei que em quase todas as empresas, o sistema não incentiva as pessoas a dedicar tempo a melhorar a eficiência, mesmo que um simples cálculo mostre que a correção de bugs pode economizar facilmente dezenas ou centenas de milhões de dólares. E, na ausência de incentivos, os desenvolvedores não têm onde obter experiência em fazer esse trabalho. O trabalho desconhecido sempre parece mais complicado do que realmente é. Assim, mesmo que um dia de trabalho possa trazer US $ 1 milhão por ano na forma de economia ou lucro (isso é bastante comum em grandes empresas, na minha experiência), as pessoas não entendem que este é apenas um dia de trabalho e pode ser feito sem distração do resto dos casos. Uma maneira de resolver esse último problema é através do treinamento. No entanto, é ainda mais difícil para um gerente justificá-lo do que aumentar a eficiência, o que não faz parte das principais tarefas!

Por exemplo, quando escrevi um pequeno guia (4500 palavras, menos que este artigo, exceto a imagem) sobre como encontrar várias ineficiências no sistema: como usar o criador de perfil para alocar memória e tempo de CPU, como configurar nosso GC para tarefas especializadas, como usar algumas das minhas ferramentas para encontrar automaticamente gargalos nas configurações da JVM, contêineres etc. Esses são basicamente truques simples e muito eficazes, fáceis de executar. Algumas pessoas foram capazes de depurar e resolver o problema por conta própria e, em segunda mão, ouvi dizer que alguém havia aumentado a eficiência de seu serviço. Bem, se 10% dos engenheiros se beneficiaram com este manual, espero que tenha ajudado dezenas de engenheiros e talvez mais.

Se, em vez de um guia, eu passasse uma semana em um trabalho "real", obteria algo específico, com valor quantitativo, que fica bonito em um pacote promocional ou avaliação de desempenho. Em vez disso, tenho algum tipo de conquista vaga, que na melhor das hipóteses pode ser considerada em parte como um "mérito extra". Não estou reclamando - esse é exatamente o resultado que eu esperava. Mas, em média, as empresas conseguem o que elas próprias estimulam os funcionários. Se eles esperam que o treinamento venha dos próprios desenvolvedores (sem financiar a produção de materiais de treinamento), mas não o valorizam tanto quanto o trabalho dos desenvolvedores, o treinamento se tornará raro.

Eu acredito que é fácil perceber a baixa qualidade dos materiais de ensino públicos devido à relativa dificuldade de monetizar a educação e o treinamento. Se você deseja monetizar programas de treinamento, existem alguns bons métodos. Aparentemente, a monetização de cursos em vídeo valiosos funciona bem (centenas ou milhares de dólares para um curso curto). Os treinamentos corporativos, quando as empresas o convidam para conversar com 30 pessoas e você recebe US $ 3.000 de cada um, também funcionam muito bem.

Se você deseja alcançar (e potencialmente ajudar) um grande número de pessoas, a publicação na Internet é eficaz, mas não espera monetização. Quanto aos tópicos técnicos, é improvável que o público sem bloqueadores de anúncios seja grande o suficiente para gerar receita com conteúdo por meio de publicidade (em oposição ao acesso pago).

Por exemplo, Julia Evansrenda suficiente para a venda de quadrinhos de computador, que recentemente trazem cerca de US $ 100 mil por ano. Um especialista em treinamento corporativo pode ganhar isso em um a dois dias.

Apêndice: defesa em profundidade com incompatibilidade de incentivos, parte 3

Dos três exemplos acima, em dois casos, recebi algum incentivo por economizar o dinheiro da empresa. Na minha experiência, isso raramente acontece em grandes empresas, mas, mesmo assim, a distribuição de incentivos acabou sendo bastante pobre. Em algum momento, após a promoção e o aumento salarial, calculei a proporção do meu aumento e economia que trouxe para a empresa. A proporção era de aproximadamente 0,03% diretamente em dinheiro, sem levar em conta as ferramentas desenvolvidas por mim, para as quais é difícil calcular um valor específico. Provavelmente, esse valor é realmente mais do que um valor quantificável. Portanto, podemos concluir que recebi significativamente menos de 0,01% do valor que a empresa trouxe. E esta é uma avaliação superestimada: na realidade, suspeito fortemente que, de fato, o trabalho realizado não me trouxe nada,e o aumento não tem nada a ver com esse projeto, que salvou a empresa dezenas de milhões de dólares. Após os primeiros US $ 10 milhões por ano, ou talvez US $ 20 milhões por ano, não há mais incentivo para trabalhar em termos de avaliação de eficácia, promoção, melhoria etc. Como não há vantagens, mas existem algumas desvantagens (você pode envolver-se em intrigas secretas, derrubar o site acidentalmente etc.), para que o retorno da execução de um trabalho opcional provavelmente se torne negativo.mas existem algumas desvantagens (você pode se envolver em intrigas secretas, derrubar acidentalmente um site etc.), de modo que o retorno da execução de um trabalho opcional provavelmente se torne negativo.mas existem algumas desvantagens (você pode se envolver em intrigas secretas, derrubar acidentalmente um site etc.), de modo que o retorno da execução de um trabalho opcional provavelmente se torne negativo.

Algumas empresas costumam oferecer bônus muito grandes, mas eu não a possuía e, na realidade, o empregador não pode avaliar um funcionário por trabalho adicional, exceto como a classificação máxima na avaliação de desempenho, e ela representa uma quantidade "suficiente" de trabalho. Em termos de design de mecanismos , a empresa realmente pede aos funcionários que parem de trabalhar assim que fizerem o suficiente.

Assim, mesmo nessa equipe relativamente profissional, o sistema de recompensas da empresa limita as pessoas sem estimulá-las a maximizar a eficiência.

Também aconteceu que os gerentes recebem um orçamento de equipe para aumentar os salários, que depende principalmente do número de funcionários, e depois são distribuídos entre os funcionários. Basicamente, a equipe possui apenas desenvolvedores produtivos, para que ninguém se destaque entre outros. Ao mesmo tempo, a rotatividade é muito baixa porque os programadores gostam de trabalhar com bons colegas. Para incentivar as pessoas a se mudarem para equipes menos eficazes, a empresa usa uma das alavancas mais poderosas - a remuneração.

Como esse é um esquema comum, em algumas empresas, os gerentes tentam manter funcionários inofensivos, mas ineficazes, para contornar as restrições de bônus. Se alguém teoricamente se perguntar se as empresas precisam contratar e reter pessoas ineficazes, a resposta é não. Mas, na prática, o esquema de bônus universais para uma equipe indiretamente estimula isso.

Links relacionados

• Contras do culto às práticas de recrutamento de tendências
  
• Normalização do desvio
  
• O livro de Zvi Mousovitsa , “Labirintos Morais”, sobre problemas sistêmicos que causam incoerências incoerentes em todos os níveis da corporação.
  
• Randomsong escreve sobre como você pode ensinar programação para quase todo mundo. A idéia é que a programação não é tão difícil quanto muitos programadores gostariam de acreditar.
  
• , — ,
  
• ,
  
• 
  
• HN Google, 10% ,

---

1. Em primeiro lugar, as entrevistas do Google costumam copiar pequenas empresas para as quais esse argumento é inadequado. Mas mesmo nenhuma das grandes empresas desenvolve ou implementa algoritmos de larga escala (o Google pode ter feito isso pela última vez em 2003, mas nas grandes empresas modernas de TI ninguém se concentra particularmente no desenvolvimento de algoritmos). [voltar]

2. O "real" está entre aspas porque passei por várias entrevistas por motivos não relacionados ao próprio processo de entrevista. Talvez eu tenha recebido ótimas recomendações, ou talvez alguém tenha lido meu blog ou tenha consultado ex-colegas ou tenha visto meus projetos de código aberto (tanto quanto sei, isso aconteceu uma ou duas vezes). Normalmente, após uma falha clara na entrevista, pergunto por que me foi oferecido um emprego, então já coletei uma coleção desses motivos.

Sugiro também a possibilidade de um resultado nulo, porque a única entrevista de programação "real" foi no Google, mas os caras errados vieram me entrevistar. Fui trabalhar com hardware e os programadores me entrevistaram, então basicamente recebi uma entrevista padrão do programador, exceto que um entrevistador fez algumas perguntas sobre a máquina de estado e a coerência do cache (ou algo assim). Em seguida, eles marcaram uma entrevista por telefone com um engenheiro de hardware para garantir que eu não mentisse sobre trabalhar em uma startup de hardware de 2005 a 2013. É possível que eu tenha falhado na parte de programação da entrevista e tenha sido contratado apenas devido à conversa telefônica subsequente.

Observe que meus fracos resultados se referem apenas a entrevistas de programação, não a hardware. Sou muito bom em entrevistar ferro, embora não pratique neste trabalho há muito tempo. Um amigo meu diz que as entrevistas de hardware são muito boas para mim por causa do jargão específico: "falo como um engenheiro de hardware" e, de fato, falamos a mesma língua com engenheiros eletrônicos. Por outro lado, dizemos algumas coisas de tal maneira que parecem incrivelmente estúpidas para a maioria dos programadores, mas o problema está no vocabulário, no jargão e não no conhecimento ou nas habilidades. [voltar]

3. Essa é uma pergunta um pouco mais complicada do que você poderia esperar por telefone, e essa pergunta pode ser esperada em uma entrevista pessoal. Embora meu amigo em uma entrevista por telefone com o Google já tenha feito uma pergunta nas finais mundiais do Google Code Jam , portanto, para a máxima complexidade, realmente não há limite, dependendo de quem está perguntando a você.

A propósito, se você estiver interessado, meu amigo realmente sabia a resposta, porque resolveu esse problema no Google Code Jam. Na competição, ele não encontrou a resposta correta, mas depois procurou por diversão. No entanto, ele não considerou razoável responder imediatamente por telefone, mas pediu ao entrevistador para fazer outra pergunta. Ele recusou, então meu amigo falhou em uma entrevista por telefone. Embora eu duvide que haja mais de duas centenas de pessoas no mundo que possam responder corretamente a essa pergunta por telefone, e quase todas elas provavelmente entenderiam o absurdo da situação. Tendo falhado na entrevista, meu amigo procurou um emprego por quase meio ano antes de passar por uma entrevista para uma startup, para a qual acabou desenvolvendo vários sistemas-chave (em termos de impacto nos negócios e dificuldades técnicas). Ele continua a trabalhar lá depoiscomo a empresa realizou um IPO de mais de um bilhão de dólares. A empresa entende como é difícil substituir essa pessoa e a trata muito bem.[voltar]

4. Além dos flagrantes problemas arquitetônicos que simplesmente levam a uma queda no serviço, há outro ponto. As equipes geralmente resolvem problemas de desempenho simplesmente solicitando recursos de computação adicionais. Algumas empresas estão tentando lidar de alguma forma com isso. Ouvi dizer que no Facebook, muitas equipes que trabalham para melhorar a eficiência reportam a um departamento especial que lhes permite bloquear solicitações de expansão de capacidade se perceberem uma extrema ineficiência em uma equipe que se recusam a corrigir. Mas, pessoalmente, eu não encontrei essas empresas. O Google tentou resolver esse problema com um sistema que, entre outras coisas, correlacionava o número de funcionários com recursos de computação, mas ouvi dizer que ele acabou sendo abandonado em favor de um sistema mais tradicional por algum motivo.. [voltar]