💠 🌙 🔭 O que eu estou no ACID ou em uma perspectiva diferente 🤨 🤣 🧖🏼

Depois de ler este post escrito por farwayer , no começo eu só queria deixar um comentário, mas depois de pensar em algumas dezenas de minutos, decidi que o tópico era profundo e tenho algo a dizer para todo o post. Mesmo assim, por um lado, sou daqueles que não olham o código nas entrevistas e ficam desapontados com a falta de conhecimento da complexidade da pesquisa de índice nos DBMSs relacionais; por outro lado, acredito que posso entender como um grupo bastante grande de entrevistadores pensa: por que eles fazem (à primeira vista) ilógicos e destrutivos, e que problemas eles mesmos querem resolver. Espera-se que a compreensão da imagem do mundo do "inimigo" responda a muitas perguntas.

Para começar, vou falar sobre mim. Espero que isso ajude você a entender melhor o que está descrito abaixo. No desenvolvimento de software por 9 anos, por algum tempo ele trabalhou por si mesmo (criou robôs de troca e negociou com seu próprio dinheiro), na maioria das vezes ele era um desenvolvedor contratado (incluindo desenvolvedor líder). Recentemente, eu estive na posição de supermercado. Reuniu 2 equipes de nível sênior. Ele conduziu várias dezenas (embora menos de 100) de entrevistas técnicas nos cargos de líder sênior de middle2s. Eu ~~não trabalhei~~ na terceirização por ~~um dia~~ na minha vida passei 18 dias. Portanto, posso dizer que toda a experiência está associada ao produto (próprio ou empregador), e todas as entrevistas foram conduzidas com a motivação “para encontrar a pessoa que trará o máximo benefício ao produto”. Admito que a experiência do autor do artigo original é mais que a minha, mas o objetivo não é dizer como fazê-lo corretamente, ou dar conselhos sobre como agir, mas mostrar como você pode ver as mesmas coisas de outra alternativa, e não o fato de estar correto, ponto de vista.

Vamos continuar (os nomes são retirados da postagem original).

Ninguém se importa com o seu código

Antes de tudo, a questão é: o que é um bom código e quais são as expectativas do código produzido por um programador experiente. Para mim, um bom código é uma função da tarefa, as condições em que essa tarefa é definida, as diretrizes adotadas na equipe (empresa), as expectativas do gerente técnico (arquiteto), gerente de produto, líder de controle de qualidade. Por exemplo, considere várias tarefas:

Desenvolver uma API para a emissão subsequente dela a todos os quinhentos clientes B2B da empresa para integrar o produto em suas soluções - uma solução bem pensada e documentada com a estrutura mais compreensível, conformidade com os padrões aceitos no mercado, validação de dados mais rigorosa, cobertura completa de testes, cobertura completa de testes, extensibilidade e registro de pensamentos. conformidade com todos os requisitos de segurança, escalabilidade no desempenho, resistência a pelo menos exemplos primitivos de DoS e DDoS ;
Para implementar a conformidade do produto com os requisitos do regulador, que entra em vigor em um mês e pode levar ao desligamento de toda a empresa - é esperada uma solução confiável com ênfase nos testes ;
Corrigido um bug no produto relacionado ao armazenamento em cache, que ficou conhecido uma hora antes da Black Friday, é esperado que a solução seja gravada e implantada no produto em 30 minutos e não quebre nada. Outros requisitos vão pelo caminho ;
Teste a hipótese para a qual você precisa analisar 250 páginas do site de um concorrente de uma só vez e, em seguida, forme um documento de planilha do Google para o analista de negócios - é esperado que o programador não trabalhe muito e grave código somente de gravação sem gastar muito nele tempo ;
Para verificar o desempenho do Aerospike em uma tarefa para a qual o PostgreSQL é tradicionalmente usado na empresa, e há problemas de desempenho, espera-se que as nuances algorítmicas e o perfil de carga sejam levados em consideração, mas todo o código será descartado independentemente dos resultados experimentais .

Concorde que é errado avaliar o código que fecha todas essas tarefas nos mesmos padrões. Afinal, é esperado que um bom programador em desenvolvimento de produtos resolva efetivamente todos os problemas acima. A prática mostra que a eficácia de um programador em todos esses casos é mais fácil de determinar por perguntas de casos e discussão de experiência do que por examinar código escrito com variáveis desconhecidas pelo entrevistador. Além disso, o código que o entrevistado deseja mostrar! = O código que ele escreve ao resolver problemas de negócios.

O triunfo do conhecimento inútil

Excelente entendimento da indignação associada à

E o fato de que pesquisar em índices de árvore B no PostgreSQL tem complexidade logarítmica? Eu descobri ontem, e agora você está

Mas o que, por outro lado? Erros relacionados à complexidade algorítmica são alguns dos mais desagradáveis para uma empresa. Eles não são cobertos por testes de unidade (O (N ^ 2) durante uma execução de teste, onde N = 10, isso é realmente rápido), não são cobertos por testes automáticos, de integração, de regressão e manuais pelo mesmo motivo. Eles não aparecem no dbe, uat, sit (afinal, para N = 1000 ainda é rápido). Eles podem esperar anos pelo seu tempo, sem se lembrar, até que um cliente adicione 250 produtos à sua cesta ou até que apareça um cliente de uma corretora que decida montar um robô HFT no joelho. Mas, quando eles aparecem, todo o negócio pode ficar doente.

Digressão lírica sobre testes de desempenho

Antecipando comentários sobre a necessidade de testes de desempenho, responderei imediatamente que está longe de estar sempre claro onde exatamente o N notório precisa ser elevado ao céu. E, dadas as tentativas maliciosas de organizar o DoS no nível do aplicativo, torna-se quase impossível prever todas as opções. Portanto, sim, também sou a favor do Teste de Desempenho, mas isso não anula minha expectativa do desenvolvedor de que ele deva entender intuitivamente onde a avaliação da complexidade se torna crítica e perigosa para os negócios.

Isso também inclui perguntas sobre o ACID. Bugs relacionados ao bloqueio no DBMS, condição de corrida, transações no DBMS - essa também é a pasta para os negócios. Eles, assim como os bugs relacionados à complexidade algorítmica, podem ficar quietos por anos e atingir muito dolorosamente. Quando o principal DBMS operacional de uma empresa, implantado em um servidor monstruoso com redundância máxima para tudo, para com carga zero na CPU e no IO no momento da atividade máxima do cliente, acredite, isso é extremamente desagradável e, sim, pode custar o salário anual de uma equipe de programadores. Portanto, você não precisa conhecer cada letra do ACID de cor (pelo menos eu nunca solicito o conhecimento de abreviações de decifração e não as lembro de cor), mas a ignorância da essência de cada letra já é uma aplicação séria para introduzir esses erros no código. Se houver dois programadores com tanta ignorância na equipe, a revisão de código também não será uma cura.

Digressão lírica sobre legado e NoSQL

Talvez o exemplo seja exagerado (embora seja real para a minha experiência) e seja principalmente relevante apenas para sistemas antiquados e sistemas de dois links, mas as arquiteturas modernas de NoSQL com microsserviços têm suas próprias piadas com dados fora de sincronia e incompatibilidade do esquema de dados em nós diferentes, em versões diferentes dados. Não vejo razão para investigar agora.

Derrubar você

E aqui está. E os caras parecem ser adequados. Fig entender. E então você vê que a vaga está aberta meio ano. Bem, bem.

O fato de haver uma vaga disponível no site da empresa (ou no agregador de tarefas) não significa que a empresa esteja procurando uma pessoa em uma equipe. A realidade das empresas de alimentos durante o crescimento é uma eterna greve de fome. Ou você escala, captura o mercado, comprime concorrentes ou morre. E o gerente de produto tem uma dor de cabeça eterna - “o que jogar fora”. Não "por que você pensaria em algo bacana para que 100 programadores possam fazer o download por um mês, para que você não fique entediado", mas que você deve jogar fora dos planos os clientes legais, necessários, planejados e esperados (e prometidos) dos planos para não atrasar o próximo lançamento por um ano. Portanto, não há mãos extras, e o fato de a vaga estar suspensa por seis meses não anula o fato de que 10 pessoas já a encontraram e contrataram, e elas farão o mesmo com prazer. Novamente, nem em todos os lugares e nem sempre, mas a situação que descrevi é normal e aceitável para o desenvolvimento de produtos.

O pensamento de extensa expansão

A prática mostra que a extensa extensão do recurso dos programadores raramente é eficaz e frequentemente destrutiva. Mas, apesar disso, as condições atuais do mercado exigem isso do negócio de alimentos. De fato, enquanto a taxa de crescimento dos negócios é mais valorizada do que o lucro operacional (não vejo razão para discutir aqui se isso é correto), os fundadores aceitam esse desafio e (às vezes) vencem. A opção “vamos crescer organicamente sem perder eficiência” também está funcionando, mas, como regra, a eficácia de cada estratégia de crescimento depende da situação do mercado, e uma discussão sobre isso atrairá pensamentos e fatos para um grande cargo.

Não me importo com projetos passados

Eu sempre pergunto. Então, aqui eu concordo completamente com o autor. Mas o ponto de vista de quem não pergunta é claro para mim também. Essas pessoas geralmente não entendem como comparar as diferentes experiências de diferentes candidatos entre si. As respostas às perguntas fechadas são mais fáceis de comparar.

Comparando candidatos entre si

Infelizmente, os RHs e autores de livros inteligentes , sentados em um fluxo interminável de pecadores e arquitetos selecionados, ansiosos para entrar na empresa dos sonhos a todo custo, gostam de construir vários sistemas de comparação que permitem classificar dezenas e centenas de candidatos entre si e escolher o melhor. Em seguida, essas abordagens são impostas aos entrevistadores técnicos e, como resultado, aparecem questionários padronizados que dão o modo de Deus na entrevista durante a alta. Mas o problema real não é nem isso, mas que, para fins de comparação, os entrevistadores arrastam o processo, esperam até que a base comparativa seja reunida e, ao mesmo tempo, criam problemas com a velocidade de contratar o empresário e colocar os candidatos em uma posição desagradável, forçando-os a esperar semanas por uma resposta. Eles também forçam os recrutadores a mentir constantemente como um bônus, porque a resposta "você parece ser bom, mas teríamos mais cinco para comparação" não aparece, e você tem que criar algo da categoria "nossa bisavó morreu com nosso techlide, então ele voltará em uma semana e isso algo vai decidir. " Decidi por mim mesmo que a comparação é má. É adequado - faça uma oferta (embora a% de ofertas para mim seja muito menor do que para os colegas de comparação).

Desenvolvedores experientes

Há um ponto importante. Que, sim, um desenvolvedor experiente e perspicaz mergulha rapidamente nele. Mas se uma pessoa afirma que trabalhou muito com o OAuth condicional em vários projetos (é importante assim, e não "usou uma vez no protótipo") e o entrevistador também trabalhou com o OAuth, por que não perguntar? A profundidade das respostas mostrará o quanto uma pessoa se aprofundará nas novas tecnologias encontradas no caminho, se entende os princípios do compartimento do motor ou copia com a SO, se tenta antecipar um rake.

Mais alguns pensamentos

Mas aqui você pode sair, fazendo um pequeno teste por uma ou duas horas (mas não no lugar: para muitos, a entrevista ainda é estressante).

Pode haver pensamentos diferentes sobre esse assunto, mas, pessoalmente, acho a tarefa de teste ofensiva mesmo para o nível intermediário. Mesmo assim, a tarefa de teste é uma desproporção muito forte no tempo gasto pela empresa e pelo candidato. Condicionalmente, o solicitante passa 3 horas escrevendo um código e mais 5 em lamber e procurar práticas recomendadas no Google, e um representante da empresa emite um veredicto em 1 minuto. Para isso, o candidato precisa de motivação. Portanto, é uma boa prática, mas não para a avaliação de programadores experientes e procurados que estão prontos para fazer sem um teste.

E pensamentos sobre um comentário interessante de loppi

E se houver um problema para o qual não conheço a solução imediatamente - você sempre pode estudar o problema e encontrar essa solução.

É importante para o entrevistador não apenas o fato de o candidato estudar o problema e encontrar uma solução. É importante como ele fará isso - se ele considerará todas as opções ou encontrará a primeira que surgir, como ele reagirá à colisão com o fato de que a solução escolhida não é válida e que uma nova deve ser buscada, e assim por diante. Pode haver expectativas diferentes para diferentes circunstâncias.

Apenas uma entrevista se destacou radicalmente da multidão, a conversa ficou cara a cara com o diretor técnico, ele perguntou com quais tecnologias eu trabalhava e depois conversamos sobre vários problemas em seus projetos e em meus projetos anteriores, e como esses problemas foram resolvidos ou podem ser resolvidos. decidir.

Sim, uma ótima maneira de entrevistar (eu penso e uso ela mesma), o que complementa bem outras questões. E, estranhamente, há uma enorme porcentagem de desenvolvedores seniores que conhecem muito bem a teoria e têm muitos anos de experiência real, mas ao mesmo tempo se mostram muito mal ao tentar resolver um problema com um grande número de graus de liberdade. Das desvantagens deste método de entrevista, que exige preparação demorada (é necessário extrair a essência de casos reais, omitindo detalhes e resumos desnecessários) e pode ser ineficaz se os principais desafios do candidato e do entrevistador forem específicos.