Por que o uso de abstrações (como LINQ) é tão tabu? [fechadas]

60

Sou um contratado independente e, como tal, entrevisto 3-4 vezes por ano para novos shows. Estou no meio desse ciclo agora e fui recusado por uma oportunidade, apesar de sentir que a entrevista foi bem. O mesmo aconteceu comigo algumas vezes este ano.

Agora, não sou um cara perfeito e não espero ser uma boa opção para todas as organizações. Dito isto, minha média de rebatidas é menor que o normal, então eu pedi educadamente ao meu último entrevistador algum feedback construtivo, e ele entregou!

O principal, de acordo com o entrevistador, era que eu parecia me inclinar muito mais para o uso de abstrações (como o LINQ), em vez de para algoritmos de baixo nível, cultivados organicamente.

Aparentemente, isso faz sentido - na verdade, também fez outras rejeições porque eu também falei sobre o LINQ nessas entrevistas e não parecia que os entrevistadores sabiam muito sobre o LINQ (mesmo sendo .NET. rapazes).

Portanto, agora fico com esta pergunta: se devemos estar "de pé sobre os ombros dos gigantes" e usar abstrações que estão disponíveis para nós (como o LINQ), por que algumas pessoas consideram isso um tabu? Não faz sentido retirar o código "da prateleira" se ele atingir os mesmos objetivos sem custo adicional?

Parece-me que o LINQ, mesmo que seja uma abstração, é simplesmente uma abstração de todos os mesmos algoritmos que alguém escreveria para realizar exatamente o mesmo fim. Somente um teste de desempenho poderia dizer se sua abordagem personalizada era melhor, mas se algo como o LINQ atendia aos requisitos, por que se preocupar em escrever suas próprias classes em primeiro lugar?

Não pretendo me concentrar no LINQ aqui. Tenho certeza de que o mundo JAVA tem algo comparável. Gostaria apenas de saber por que algumas pessoas ficam tão desconfortáveis ​​com a ideia de usar uma abstração que elas mesmas não escreveram.

ATUALIZAR

Como eufórico apontou, não há nada comparável ao LINQ no mundo Java. Então, se você está desenvolvendo na pilha do .NET, por que nem sempre tentar usá-lo? É possível que as pessoas simplesmente não entendam completamente o que isso faz?

Matt Cashatt
fonte
8
Eu acho que você não sabe o que é "abstração", porque o LINQ não tem nada a ver com isso.
Euphoric
8
"Estou certo de que o mundo JAVA tem algo comparável" Na verdade, o LINQ é uma das poucas coisas que o .NET possui e o Java não.
Euphoric
42
@ Eufórico - O LINQ não abstrai o trabalho de nível inferior de tarefas como classificação e filtragem, por exemplo? Tenho tanta certeza de que haveria algum código extra objectCollection.Where(oc=>oc.price > 100)para trás, por exemplo. Isso não seria um uso de uma abstração? Talvez você possa me dizer o que estou perdendo aqui. . .
Matt Cashatt
37
Sempre há a chance de eles simplesmente não entenderem o LINQ e não verem o valor em aprendê-lo. Os aspectos funcionais da escrita são muito muito diferentes da programação imperativa. Como contratado, em 2009, vi desenvolvedores Java "seniores" que não entendem SQL o suficiente para escrever consultas avançadas, e passam semanas otimizando o código que traz todos os dados para o lado Java e os filtra com código Java, em vez de ter o banco de dados fazendo isso. A ignorância é galopante no setor de desenvolvimento de software.
18
Se você entende o LINQ, mas seus entrevistadores não, você é melhor do que eles. Defina suas vistas mais altas.
Jay Bazuzi

Respostas:

74

Eu não acho que é o uso de abstrações per se que seja censurável. Existem duas outras explicações possíveis. Uma é que todas as abstrações estão vazando uma vez ou outra. Se você der a impressão, correta ou não, de que não entende os fundamentos subjacentes, isso pode refletir mal em uma entrevista.

A outra explicação possível é o efeito fanboy. Se você fala com entusiasmo sobre o LINQ e o apresenta repetidamente em uma entrevista com uma empresa que não o usa e não possui planos atuais, isso dá a impressão de que você ficaria insatisfeito ou até mesmo descontente ao trabalhar com tecnologias mais antigas. Também pode dar a impressão de que seu entusiasmo por um produto o cegou para alternativas.

Se você realmente acha que ficaria feliz em uma loja não-LINQ, tente perguntar sobre o que eles não usar e adaptar as suas respostas em conformidade. Mostre a eles que, embora prefira o LINQ, você é competente usando as ferramentas disponíveis.

Karl Bielefeldt
fonte
4
@MatthewPatrickCashatt Você não pode editar e continuar no depurador dentro de métodos que contêm instruções linq. Não é o suficiente para que eu não o use; mas foi a principal razão pela qual hesitei em fazê-lo por um tempo.
Dan Neely
3
+1, especialmente para o segundo parágrafo. Isso se aplica totalmente a mim, pois eu ficaria completamente infeliz em trabalhar em um código C # sem poder usar o LINQ.
Arseni Mourzenko
5
Há também o fato de que frequentemente há um desempenho atingido, além da abstração com vazamento. Você está trocando a facilidade de uso pela precisão, e essa perda de precisão inclui frequentemente detalhes que tornariam as coisas mais rápidas. E quanto mais você for removido da fonte, mais detalhes perderá e maior será a probabilidade de que esses detalhes sejam importantes para o desempenho.
jmoreno
6
+1, mas também pode funcionar de outra maneira. Se alguém me disser que não me contratou porque eu uso o Yacc para criar analisadores em vez de usar os meus, então não é um lugar que eu queira trabalhar.
Spencer Rathbun
5
@ MatthewPatrickCashatt: esta resposta (e meu comentário) não é específica do LINQ, mas de declarações gerais. Mas para o LINQ, aqui está um trecho do C # 4.0 / 5.0 em poucas palavras, falando sobre problemas de desempenho com o LINQ. Voltando às generalidades: em muitos casos, o desempenho atingido valerá a pena, sendo 5% +/- irrelevantes. Mas às vezes será maior e às vezes até 0,1% é inaceitável. Se você não acha que não pode nunca ser um problema, ou que o desempenho é apenas para empresas como Google ....
jmoreno
29

Alguns programadores .NET, particularmente aqueles provenientes de um background clássico de VB / ASP ou C ++, não gostam de coisas novas como LINQ, MVC e Entity Framework.

Com base no que observei, é provável que os ex-VB'ers deste grupo ainda estejam usando camadas de acesso a dados e outro código originalmente escrito há mais de 10 anos. Eles também usam chavões antigos, como "n-tier" e similares, e realmente não entendem nada além de .NET Framework 2.0, nem desejam aprender nada sobre isso.

Os C ++ tendem a ser programadores academicamente orientados que adoram codificar algoritmos legais, mesmo que isso signifique reinventar a roda. Eles odeiam, dependendo de qualquer coisa que não tenham entregue o código. Algumas dessas pessoas também gostam de fazer com que os entrevistados se sintam inferiores, especialmente aqueles com um histórico menos tradicional.

É provável que você encontre organizações como essa ao entrevistar. Mas você também encontrará alguns que estão usando métodos mais novos. Não deixe que algumas entrevistas ruins o joguem fora.

jfrankcarr
fonte
2
Obrigado jfrankcarr. Suspeitei que esse poderia ser o caso - havia perguntas sobre como abrir e fechar datareaders!
Matt Cashatt
2
+1 por chamar o MVC de "coisas novas". Me fez rir alto. Existe desde os anos 70. Você pode querer dizer MVVM, que é essencialmente MVP (uma variante MVC) que usa ligações.
14
@ GlenH7 Eu acho que ficou bem claro no contexto que ele quis dizer o produto "ASP.NET MVC", não o conceito básico de Model-View-Controller.
Carson63000
4
@ GlenH7 - Eu estava falando inteiramente dentro do contexto da linha de produtos .NET e Visual Studio e dos chavões de produtos da Microsoft.
Jfrankcarr
6
Bom Deus, existem realmente lojas que pensam no Linq como "novo"? Já existe há mais de 4 anos. Posso entender que não estou conseguindo aguentar os garçons de tarefas, ou o uso de dynamic/ ExpandoObject/ etc., Ou não me preocupo com o Azure e todas as outras coisas na nuvem ... Posso até entender como continuar usando a visualização WebForms da velha escola mecanismo no MVC ou Web Forms propriamente dito, ou escrever o código WPF / WinRT sem MVVM ... mas Linq? Se você ainda não descobriu isso, é hora de sair do seu trabalho como desenvolvedor .NET.
Aaronaught 21/10/12
16

A Microsoft tem uma longa história de lançar novas tecnologias quentes e depois esquecê-las 5, 10 ou 20 anos depois. O LINQ pode parecer outro para algumas pessoas. Eles observam que a Microsoft não pode descontinuar o SQL, mas o LINQ pode estar seguindo o Silverlight . Assim, você pode ver a paranóia resultante de uma experiência difícil ou apenas pessoas que foram deixadas para trás pela tecnologia moderna e que se ressentem.

RalphChapin
fonte
12
Honestamente, enquanto vejo o ponto básico, não acho que Linq vá embora tão cedo. Linq2SQL, sim, eles o preteriram em favor da EF muito mais poderosa. Mas o Linq em si é a base de tantas outras novidades brilhantes nos últimos 3 lançamentos do .NET que, se o preterissem, estariam desfazendo metade de sua nova tecnologia de camada de persistência, como Azure e EF, para não falar em prejudicar praticamente todos os ORM lá fora e muito processamento de lista na memória.
Keiths
6
espere ... "apavorado em se afastar da tecnologia antiga e fora de moda, porque funciona" ... WTF. Chegamos ao ponto em que o trabalho que é experimentado, testado, compreensível e sustentável e maduro NÃO é bom.
precisa saber é o seguinte
7
@ gbjbaanb - Não. Mas - como uma anedota - você gostaria que um médico diagnosticasse suas dores no peito com uma radiografia de tórax porque esse método é 'experimentado, testado, compreensível' ou você deseja uma ressonância magnética mais recente, mas com maior resolução? , melhor prognóstico e mais informações? Ninguém está dizendo para se afastar dos princípios clássicos aqui; muito pelo contrário. Você vê, o LINQ (como exemplo) é construído sobre esses princípios. Eu acho que, como outros já mencionaram, é o aprendizado das partes que fazem o LINQ e o uso adequado que causa os momentos 'WTF' como o seu.
Matt Cashatt
2
@ MatthewPatrickCashatt: depende, se o médico não tiver sido treinado para ler os resultados da ressonância magnética, eu faria o raio-x em vez de fazê-lo adivinhar um diagnóstico. Se eu ficasse doente em uma represa, eu preferiria ter um médico que pudesse diagnosticar nada além de um estetoscópio do que ser incapaz de lidar sem o que há de mais moderno nas ferramentas mais recentes.
Gbjbaanb
2
@MatthewPatrickCashatt Entendo o seu ponto, mas um fator de equilíbrio é que você não deseja seguir todas as tendências apenas porque é mais recente. Felizmente seguirei uma nova tecnologia que se encaixa em uma de duas categorias. 1. Isso me excita e estou disposto a gastar meu tempo livre nele. 2. Prova-se realmente melhor e parece que vai durar o suficiente para fazer valer a pena o investimento. Tendências que não se encaixam em uma das duas categorias são uma aposta na melhor das hipóteses.
TimothyAWiseman
15

Não faz sentido retirar o código "da prateleira" se ele atingir os mesmos objetivos sem custo adicional?

Sempre há um custo extra.

A curva de aprendizado para coisas prontas está sempre lá. A dor de obter atualizações (e dependências) está sempre lá. A incapacidade de mexer nas entranhas está sempre presente.

Para o LINQ, o primeiro realmente se aplica. Muitas pessoas consideram o código com aparência "estranha" difícil de ler e de depurar. A sintaxe do tipo sql é praticamente persona-non-grata em todos os shows profissionais que trabalhei desde que foram lançados. O LINQ to SQL (e outras fontes de dados) tem várias dicas e opções limitadas de otimização.

Esses são os argumentos gerais contra as ferramentas de terceiros e o LINQ especificamente. Tudo isso dito, o LINQ é uma ferramenta útil e deve ser preferida na maioria das situações. O choro não inventado aqui, e as abstrações não devem ser favorecidas cheira fortemente à dissonância cognitiva .

Eles não sabem / não podem aprender o LINQ, mas são "obviamente" bons desenvolvedores, portanto o LINQ não deve valer a pena. É uma armadilha comum.

Telastyn
fonte
11
Bons pontos. Concorde com os custos mencionados e é um bom esclarecimento. Mais amplamente, no entanto, o desenvolvimento de classes domésticas com as quais nenhum novo funcionário pode estar familiarizado, porque não existe fora da organização, apresenta os mesmos desafios, além do custo do desenvolvimento primário.
Matt Cashatt
2
@MatthewPatrickCashatt - Oh absolutamente. Portanto, esse código criado em casa quase sempre deve ser mais esforço para a mesma vitória, mas não é necessariamente. Como muitas outras coisas, o custo / recompensa deve ser estimado e a melhor prática preferida , não seguida cegamente.
Telastyn
@Telastyn O código interno também é bom, já que você sabe o que faz e pode corrigi-lo em um instante. Além disso, você pode otimizar para circunstâncias específicas com base no seu próprio uso, e não na média do de todos.
Hawken
13

Outra coisa que você deve considerar é que seu entusiasmo por uma nova tecnologia legal pode simplesmente fazer as pessoas se sentirem desconfortáveis ​​e não quererem você por perto. Você não está "capacitando" eles, porque é você quem conhece essa tecnologia, não eles. Mesmo que eles próprios não percebam isso, eles podem estar procurando candidatos que reforcem o que já investiram tanto tempo.

Você deseja apresentar uma atitude que diz: "O que você estiver fazendo, eu quero ajudá-lo a alcançá-la", em vez de fornecer um subtexto que diz: "Você pode estar fazendo as coisas de um jeito ruim, e ter-me por perto provará isto."

John Wiegley
fonte
+1 - bem como dizer-lhes que você sabe sobre, perguntar-lhes o que eles estão fazendo eo que eles se especializam em.
Kirk Broadhurst
12

Minha opinião sobre isso (e TBH, eu acho, porque nenhum de nós pode dizer o que esses entrevistadores estavam pensando) é que frequentemente você vai a uma entrevista para explicar por que eles deveriam contratá-lo para se encaixar na equipe deles, na maneira de trabalhar deles .

Você pode ser o desenvolvedor perfeito, um deus do código inicial, mas isso não significa absolutamente nada se o que você quer fazer (enfatizado por você falar excessivamente e com muito entusiasmo sobre alguns gubbins legais de tecnologia) simplesmente lhes diz sobre você e que você não faria isso se encaixam com o que eles querem. Se eles têm um sistema de acesso a dados de estilo antigo, que não pode ser atualizado por qualquer motivo, não precisam de alguém que se esqueceu de como mantê-lo. Se eles estão desenvolvendo coisas novas e você realmente deseja colocar essa nova tecnologia legal em todos os lugares, é óbvio que eles terão um grande problema com a manutenção futura do código e / ou o treinamento da equipe.

Como freelancer, isso é muito mais problemático do que se eles estivessem contratando uma permissão. Com uma permissão, o treinamento e o desenvolvimento de novas formas de trabalhar não são coisas ruins, dentro do escopo do código e das práticas existentes - você estará lá por um longo tempo para melhorar as coisas. Com um freelancer, eles realmente não dão a mínima para o que você quer, você está lá apenas para fazer o trabalho da maneira que eles querem, e não é seu trabalho fazer qualquer outra coisa. (discordo - torne-se um funcionário permanente)

Provavelmente não tem nada a ver com o LINQ, rejeitei um candidato que apareceu e expliquei o quanto tudo seria melhor escrito em Haskell. Nós não fazemos Haskell. O mesmo se aplica a qualquer tecnologia que não seja usada pela empresa, geralmente não é um problema se você mencionar como algo bom. O problema surge quando você está entusiasmado e interessado demais.

gbjbaanb
fonte
2
Eu concordo com isso, mas notei muito mais pessoas que usam essa atitude para descartar boas idéias que elas simplesmente não entendem (por exemplo, testes, padrões de design, ORMs). Portanto, embora eu concorde que ser uma boa opção para a equipe é uma coisa boa, é importante perceber que você pode ser melhor que o resto da equipe e deve encontrar pessoas com ideias semelhantes em que não é uma coisa ruim conhecer bem abstrações.
Wayne Molina
11
@WayneM claro, mas o OP é um freelancer, por isso realmente não importa se ele é um deus da codificação, a menos que estejam preparados para contratá-lo permanentemente para manter o código que o resto da equipe não entende (hmm) ele precisa fazer o que eles querem, não o que ele quer.
Gbjbaanb
11
O @WayneM da mesma forma muitas pessoas usariam algo parecido com o que você acabou de dizer para promover as idéias delas sobre as de outras pessoas (estar confiante de que as pessoas com quem conversam simplesmente não entendem). No final, ambos os lados são tendenciosos, mas o OP é sobre ser contratado, não ganhar a grande guerra de bricolage / abstração. Todo mundo terá sua própria opinião, mas alguém precisa superar isso; Suponho que não será o empregador neste caso. :(
Hawken
10

Há uma preocupação válida que ouvi daqueles que não usam o Linq, e é uma que eu tenho em mente: "Só porque você não pode ver a implementação não significa que não é caro".

Pegue o seguinte trecho:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

Os iniciados por LINQ aqui estão se encolhendo. Por quê? Porque apenas porque esse código parece bonito e elegante, não significa que não seja terrivelmente ineficiente. Count (), com um predicado, avalia todos os elementos de seu pai enumerável e resume as vezes que o predicado retornou verdadeiro. Portanto, não é apenas este N ^ 2 (quando inputList e otherInputList são aproximadamente iguais à cardinalidade N), é o pior caso absoluto N ^ 2; TODOS os elementos de otherInputList são percorridos para TODOS os elementos de entrada. Em vez disso, o primeiro passo é usar Any () em vez de Count, porque é isso que você realmente quer saber, e ele será encerrado assim que a resposta for "sim". A configuração de um HashSet que armazena valores distintos também otherInputListObject.OtherPropertypode ajudá-lo; o acesso se torna O (1) em vez de O (N),complexidade de pior caso em vez de complexidade quadrática de melhor caso .

Portanto, vemos que esses métodos elegantes e agradáveis ​​têm sérios custos por trás deles, e se você não sabe quais são esses custos, pode codificar com facilidade um algoritmo de complexidade O (meu GD) no servidor de arquivos central de alto desempenho de seu empregador em potencial ou na página principal do portal de destino na próxima vez em que precisar de um ajuste. Demitir você depois de fazer isso não desfaz o que você fez, mas não contratá-lo se eles acharem que você faria isso impediria. Portanto, para evitar isso, você deve provar que estão errados; discuta o que esses métodos fazem (o que significa que você precisa conhecer a si mesmo) e sua complexidade, e como chegar à resposta em um tempo eficiente (NlogN ou melhor).

Outra preocupação é o bom e velho argumento "Quando sua única ferramenta é um martelo". Coloque-se no lugar do entrevistador entrevistando esse fanboy do Linq. O candidato gosta do Linq, quer usá-lo, acha que é a melhor coisa do mundo. Pode até parecer que o candidato não poderia codificar sem ele, pois todos os problemas de programação fornecidos foram resolvidos com o Linq. Bem, o que acontece quando não pode ser usado? Muitos códigos do .NET 2.0 ainda estão por aí, que, se fossem atualizados, exigiriam atualizações dolorosas para servidores, estações de trabalho de usuários, etc etc, tudo para que você possa usar seus métodos de extensão sofisticados. Como entrevistador, eu tentaria mostrar que você poderia codificar uma classificação eficiente ou usar os métodos de classificação 2.0, se necessário, não importa o quanto eu concorde com você que as bibliotecas Linq e os métodos de extensão semelhantes são bastante doce. Um entrevistador que não entende o ponto pode nem se importar em tentar fazer com que você mostre aptidão para qualquer outra coisa; eles assumem que você não o tem e seguem em frente.

KeithS
fonte
Por que você simplesmente não escreve sua consulta como var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? Eu poderia ter estragado tudo, mas o que quero dizer é que o LINQ tem maneiras melhores de executar a consulta mencionada acima (.Join () é outra maneira). Percebo que existem maneiras de usar o LINQ que podem não ser tão eficientes quanto outras, mas isso não significa que você precise confiar nessas implementações ruins.
Matt Cashatt
4
@MatthewPatrickCashatt Eu não acho que o argumento dele seja tanto o de afirmar que o LINQ é sempre ineficiente - enquanto você sempre pode vencer uma determinada consulta LINQ, alguns usos oferecem melhor desempenho por hora do desenvolvedor do que muitas abordagens não-LINQ. Em vez disso, pode ser relativamente fácil escrever uma consulta LINQ que seja ineficiente e não realizá-la, porque as ineficiências não são tão flagrantes.
Jon Hanna
3
@ JonHanna: Talvez mais ao ponto, o valor de uma abstração seja bastante reduzido se for necessário examinar o que o código está "realmente fazendo" para determinar quais cenários incomuns, mas plausíveis, podem fazer com que o desempenho seja muitas ordens de magnitude piores que o esperado. Se a alteração de uma estrutura de dados para outra fará com que o código seja executado 10.000 vezes mais lento, a capacidade de fazer essa alteração sem alterar nenhum outro código pode nem sempre ser uma coisa boa.
Supercat
11
@ supercat: sim e não. Só porque o conhecimento de como algo é feito em uma implementação de terceiros é fundamental para entender as implicações de desempenho e evitar ineficiências, não significa que as bibliotecas que encapsulam essas ferramentas tenham menos valor. São dois lados da mesma moeda; conheça a natureza da implementação e você pode usá-la pressionando algumas teclas em vez de uma hora. Mas você precisa conhecer os dois lados e o estereotipado fã de linq que acha que é perfeito, nada de errado, usa-o para tudo o que provavelmente não o faz.
Keiths
@KeithS: Uma coisa que acho que falta muito em Java e .net é um meio padrão de perguntar a objetos ou coleções várias coisas sobre si. Por exemplo, o código que recebe uma coleção enumerável pode se beneficiar ao saber se o número de itens e / ou a sequência de itens existentes pode mudar, se é sabido que o número de itens é finito ou infinito (ou não é conhecido de qualquer maneira), e se a coleção sabe inerentemente quantos itens estão nela. Tecnologias como LINQ muitas vezes precisam fazer suposições sobre coisas que podem ou não estar corretas e ... #
22612
10

Este ficou um pouco longo, mas pode ser útil para alguém, então eu deixarei.

Na verdade, encontrei algo semelhante, passando por pouco mais de 20 entrevistas no mês passado (uma mistura de telefone e face a face). Definitivamente, havia algo inesperado acontecendo que eu não conseguia entender.

Uma das coisas que notei, porém, foi que as coisas que geralmente têm sido o ponto central dos ciclos de entrevistas dos últimos cinco ou seis anos não foram decididamente discutidas ou pouco estudadas. Coisas como os fundamentos da análise / design de OOP, padrões (ambos de design e arquitetura), alguns dos recursos .net mais avançados / voltados para abstração (incluindo lambdas ou LINQ especificamente, genéricos, serialização / ligação de dados e similares) e até o tópico geralmente quente da metodologia preferida (ninguém parecia se importar muito com ágil versus cascata ou que sabor é ágil) e ferramentas ou escolha de ORM ou meios preferidos de colaboração ou gerenciamento de controle de origem. Em alguns casos não mencionados, em quase todos os casos aparentemente não preocupam.

O que recebeu o foco, em várias entrevistas e várias empresas não relacionadas em setores não relacionados, foi o seguinte:

  • Uma fixação estranha em convenções desatualizadas / fora de moda e limitações "de volta à idade da pedra". Como desenvolver um aplicativo Web primitivo no VS2003 com uma lista de restrições absurdas, proibindo ainda mais o uso de recursos explícitos naquela era do .net ... como se esse fosse um medidor real da capacidade de desenvolvedores modernos ... a capacidade de lembrar o paradigma e as limitações de 9 anos atrás, ainda mais prejudicados por restrições irrealistas / arbitrárias. Outro lugar era muito obstinado em matéria de coleções personalizadas, por volta de coleções pré-genéricas. Outro local exibiu uma amostra de código de um modelo de classe que eu rabisquei porque não usei construtores em cascata (eles pareciam desconhecer o suporte à inicialização da propriedade na declaração, o que era suficiente para a necessidade).

  • Foco extremo em detalhes específicos da implementação em um microcosmo e / ou definições de configuração, mesmo no caso de tecnologias focadas em agnóstico de plataforma ou protocolo (ou seja, o ponto principal é NÃO se fixar em uma implementação específica ou uso específico, mas sim reutilização / reutilização / extensibilidade / conforme a integração necessária).

  • Disposição de especificar / supervisionar / revisar o código / e de outro modo afastar o trabalho de e para uma equipe offshore, além de habilidades de não codificação relacionadas a isso.

  • Uso de versões específicas de produtos / plataformas / módulos / etc. Até um grau às vezes absurdo; "Então ... você usou as versões 1, 2 e 4? Mas não 3, hein? Hmmm ... {faz anotações no seu currículo com" no v3 !!!} ". O grau de uso não parecia importar; só que você tem ou não ter usado algo em tudo , ea coisa específica que eles estão pedindo também ... não substituições pareciam contar, até mesmo de um produto concorrente mais amplamente utilizado e com todos os recursos.

  • Uma quantidade muito maior de foco em "quão bem você vai se encaixar na nossa equipe" sobre "você é realmente bom como desenvolvedor de software" ou "você tem as habilidades e a experiência necessárias para agregar valor à empresa e nos ajudar a oferecer uma qualidade?" produto "ou até" você é um idiota perigoso que entra e destrói a loja ". Em alguns casos, meu currículo era apenas um dado adquirido, e até a chamada "tela técnica" ou entrevista técnica era uma avaliação da personalidade muito mais do que uma avaliação de habilidades. Mesmo para posições de contrato relativamente de curto prazo, onde você estaria lá e voltaria antes que duas temporadas mudassem.

  • Desta vez, as empresas pareciam ter muito menos foco na solução de problemas técnicos específicos, iniciando novos projetos de desenvolvimento green-field ou grandes 2.0, ou lançando um produto específico no mercado para capitalizar uma tendência ou oportunidade emergente ou os grandes arranques habituais . Um tema repetido que notei em pelo menos 15 dos locais foi que um pequeno grupo de 3 a 5 desenvolvedores, a maioria sobreviventes da queda do mercado em 08, conseguiu moer um produto ao longo dos últimos três anos. e encontraram algum sucesso ou a empresa como um todo está crescendo e eles estão contratando novos funcionários para acompanhar as crescentes demandas de recursos ou para resolver / superar as falhas de design que incorporaram a esses sistemas ou para assumir as plataformas mencionadas para liberar criar a equipe principal que a criou para realizar "outros projetos".

Mas ... se há uma coisa que eu sei sobre esse negócio é que é cíclico. Na próxima vez que eu estiver procurando por um novo show, não ficarei surpreso se o jogo mudar novamente. Você só precisa permanecer mentalmente flexível, ouvir ativamente, evitar fazer declarações absolutas se elas forem desnecessárias, mas também não são uma doninha e não são unidimensionais (você é um idiota ou um fanático, nem desejável) ou como sendo muito bom (pode ser ameaçador e custar um show).

Apenas ajuste sua abordagem e tente dar uma resposta mais ponderada na próxima vez ... mencione algumas maneiras diferentes de abordar um problema ... mas mesmo que seja um conhecimento rotineiro, você age como se estivesse realmente pensando nisso e raciocinar no local. Parece mais humilde e menos intimidador ou ofensivo dessa maneira.

É claro que a Lei de Murphy é o que é, a próxima entrevista depois que você deixa de ser "apaixonado pelo meu atual cara favorito da tecnologia" e adota uma postura mais equilibrada / com barba é o show que você teria se tivesse ficado louca cara fanático. ;)

Experiência recente semelhante
fonte
6

Acho que você está tirando uma conclusão falsa, porque seu conjunto de amostras é muito limitado. Embora eu tenha visto uma parcela justa de lojas de TI com forte aversão a qualquer coisa "não inventada lá" 1 , nenhuma delas desqualificaria os candidatos com base em suas preferências na pilha de tecnologias: eles estavam legitimamente convencidos de que poderiam ensinar o candidato certo a usar suas bibliotecas caseiras.

Eu duvido seriamente que a empresa tenha banido o uso do LINQ completamente. Provavelmente, eles queriam que você lhes mostrasse suas habilidades em um nível mais profundo.

Por exemplo, uma maneira de descobrir se você conhece suas tabelas de hash é pedir para implementar uma primitiva em um quadro branco. Este exercício simples revela uma quantidade surpreendente de dados sobre seu conhecimento para o revisor: ele aprende instantaneamente se você sabe sobre código de hash / iguais e o que você sabe sobre colisões de hash. Ao mesmo tempo, é difícil imaginar alguém em sã consciência reimplementando uma tabela de hash, porque a Microsoft fez um bom trabalho nela. O mesmo vale para muitos algoritmos, como classificação e pesquisa: os entrevistadores geralmente desejam saber se sua experiência é suficiente para entender interações de baixo nível, em vez de verificar se você possui um conhecimento prático das bibliotecas .NET.

É quase certo que eles insistiriam em que você usasse implementações de bibliotecas, e não as suas, quando for contratado para trabalhar na empresa deles. Mas, durante a entrevista, eles o empurrariam para o código de baixo nível, a fim de obter uma melhor compreensão de suas verdadeiras habilidades.


1 uma loja foi tão longe como a construção de sua própria ferramenta de construção bastante primitiva!

dasblinkenlight
fonte
2
Todos os seus pontos de vista estão bem fundamentados, mas eu deveria lhe dar um pouco de cor na última entrevista: o entrevistador insistiu que o LINQ estava sendo "reprovado". Eu perguntei: "você não quer dizer que a MS não estará mais investindo no Linq-to-SQL, mas que o Linq-to-Entities estará presente" e sua resposta foi que ele quis dizer o que disse: LINQ está sendo "deprecado" então, não, acho que ele não sabia muito sobre o LINQ ou insistia em usá-lo.
Matt Cashatt
11
@MatthewPatrickCashatt Se alguém confundisse o LINQ para o LINQ2SQL em termos de depreciação da tecnologia, eu inventei uma desculpa boba para deixar a entrevista mais cedo e nunca liguei para a empresa. Se isso fosse realmente o caso, você deve estar feliz sobre eles não contratá-lo :)
dasblinkenlight
11
100% certo de que era esse o caso. Na verdade, eu não pude resistir a enviar-lhe alguns links para colocá-lo no caminho certo sobre o assunto, não como um soco desde que eu não recebi o show, mas porque realmente me senti envergonhado por ele e esperava poder ajudá-lo a não cometer o mesmo erro duas vezes;).
Matt Cashatt
4
Então isso parece ter menos a ver com a pilha de tecnologia e mais com o fato de que você o corrigiu. As pessoas não gostam de ser corrigidas. É apenas a natureza humana. Quando as pessoas tomam decisões como contratar pessoas, 99% vão com sua intuição. Eles pensam se você os fez sentir emoções positivas ou negativas. Corrigi-lo pode ter causado emoções negativas. E ele associa essa negatividade à situação.
Codificador
11
Não sei como as hashtables funcionam internamente. Testes técnicos profundos como esse expulsam pessoas com treinamento prático, que são bons candidatos, no entanto. Exigir que as pessoas tenham conhecimento de baixo nível que nunca usarão me parece desnecessário. Os princípios de design tornaram-se muito mais importantes!
Tjaart 22/10/12
4

Acho que você está fazendo algumas generalizações loucas do tipo "eu vi uma vaca preta na Escócia, então todas as vacas escocesas são negras".

Se eu o entrevistei, ficaria desapontado se você não pudesse responder minhas perguntas do linq.

No entanto, o Linq é complicado, muitas pessoas o veem como vodu, o que é injusto, pois na verdade é muito simples e ainda mais inteligente.

Ian
fonte
3

Para bancar o advogado do diabo, a razão é que muitos desenvolvedores simplesmente não se importam com coisas novas e pensam que tudo precisa ser resolvido com ferramentas domésticas (geralmente inferiores). Não há nada de errado em usar abstrações. Inferno, geralmente não há boas razões para não usar essas abstrações.

Parece que você acabou de entrevistar um desenvolvedor ruim que não se mantém atualizado com as coisas e adota a abordagem de martelo e prego em tudo. Esses são os tipos de desenvolvedores que não sabem nada sobre ferramentas úteis de código aberto, como NUnit, NHibernate ou vários contêineres IoC; aqueles que tentam resolver todos os problemas com um processo armazenado em massa no banco de dados; aqueles que não sabem absolutamente nada sobre o MVC, apesar de já estar fora há vários anos.

Wayne Molina
fonte
Você pode lançar o LINQ em um conjunto de chavões contendo Nhibernate, etc ... Eu não faria isso. Na verdade, acho que chavões exemplificam nossa incapacidade de explicar abstrações em expressões apropriadas.
AndreasScheinert
Você está falando sobre 'manter-se atualizado', bem, acho que o inverso seria muito mais apropriado. Muitos conceitos úteis foram descobertos e usados ​​no passado, por exemplo, DSLs. Cabe a nós melhorar nossa comunicação e compreensão de conceitos como o de que não precisamos inventar novas palavras de efeito para conceitos antigos.
AndreasScheinert