Efeito do ReSharper nas entrevistas de codificação [fechado]

Qualquer pessoa que tenha usado R # ou CodeRush sabe com que rapidez você pode montar construções simples (e refatorar construções complexas) com um simples atalho de teclado. No entanto, esses plug-ins de produtividade causam uma falsa avaliação de capacidade durante as entrevistas?

Parte de ser um escritor de código produtivo (e causar uma boa primeira impressão em uma entrevista) é escrever um bom código - rápido.

Se eu tivesse dois candidatos:

1. Não usa plugins. Ela pensa no problema, senta-se em uma IDE de estoque na entrevista PC que se parece exatamente com a dela e digita o código em um ou dois minutos, como sempre. Feito. Passar.

2. Usa plugins. Ele pensa sobre o problema, senta-se em uma IDE de ações no PC da entrevista e percebe que "fe + tab" não escreve mais um loop foreach automaticamente e todos os atalhos desaparecem. Ele então toca no teclado, pressionando as teclas de atalho normais, abrindo janelas estranhas e ficando perturbado. Ele leva 3 minutos para escrever o que normalmente levaria 30 segundos. Feito. Parecia que eles não conheciam o IDE algumas vezes. Deve ser novo para este IDE e, portanto, não teve muita experiência com ele ou talvez com a linguagem. Passe, mas uma marca de 'meh' ao lado do nome.

Na sua experiência, como você lida com plug-ins durante as entrevistas como entrevistador ou entrevistado? Quais são as melhores práticas para obter o que o candidato realmente sabe? Pode haver candidatos que não entendem o código e usam o R # como muleta. Também pode haver candidatos que conheçam o código de entrada e saída e usem R # porque é muito mais rápido que os modelos VS ou Eclipse integrados. É melhor simplesmente não usar um IDE? Deixe-os trazer seu próprio PC? Outras?

Eu fui candidato 2 em uma entrevista muito recentemente . Foi-me dada uma instalação básica do IDE em um PC com um teclado não padrão e uma estrutura de teste desconhecida, e me pediram para escrever um aplicativo Fizz-Buzz simples com testes de unidade. Eu afofei. Eu devo ter parecido um novato completo, tropeçando no escuro tentando invadir o código. Escusado será dizer que não me foi oferecido o cargo.

O que aprendi é que confio muito nos meus plugins. Eles não apenas digitam o código mais rapidamente - eles realmente moldam o modo como penso sobre o código e o modo como codifico. Por exemplo, eu costumava pensar com muito cuidado sobre nomes de variáveis, porque eles poderiam ser difíceis de mudar após o fato. Agora, por outro lado, faço um palpite incompleto sobre como vou usar a variável, hackear algum código, deixar a variável me dizer para que serve e depois pressionar Refactor-> Rename para chamar de algo mais apropriado .

Isso me torna o candidato menos capaz? De certa forma, acho que sim . Alguém que pode escrever código no bloco de notas e compilá-lo e executá-lo corretamente tem certas vantagens sobre alguém como eu, que precisa de toda a bondade de IDE que pode obter. Desse ponto de vista, entendo perfeitamente por que qualquer empresa escolheria não contratar um chefe de ferramentas como eu.

Por outro lado , ainda sou um desenvolvedor sênior talentoso e capaz. Aprendi o que funciona para mim e pratico o tipo de preguiça que me torna produtivo, dadas minhas próprias fraquezas e limitações. Em resumo, sou o tipo de programador que poderia realmente beneficiar uma empresa como a que me rejeitou .

Curiosamente, eu tive outra entrevista algumas semanas atrás. Após minha experiência anterior, fiz questão de perguntar sobre ferramentas ou orçamento adicionais para comprá-las. Descobrir que não havia nenhum deles me deu mais uma razão para recusar a (bastante generosa) oferta que eles fizeram para mim .

Portanto, parafraseando Groucho, " eu não ingressaria em nenhuma empresa que tivesse alguém como eu para um empregado " .

A menos que eles me deixem usar o ReSharper, de qualquer maneira.

Deixe que eles ( candidatos ) usem o que quiserem. No antigo, construa um Wal-Mart com um canivete suíço apenas para mostrar que você pode se aproximar é tão antigo. Eles vão usar o que for preciso em seu trabalho diário (bem, espero que sim), então deixe-os usar o que quiserem em uma entrevista. O resultado final é tudo o que importa. E, com muito mais prazer, contratarei um candidato que saiba quais ferramentas estão disponíveis no mercado e como usá-las com eficiência, depois quem fará tudo manualmente. Esta é uma indústria assassina.

ps Como exemplo, pense no Vim (ou no Emacs) - você gostaria de usá-lo sem configurações personalizadas, plugins etc.?

Eu diria que ferramentas como ReSharper realmente fazem de você um candidato melhor do que tudo.

Por um lado, algo como o ReSharper vai ensinar sobre construções de linguagem que você talvez não conheça, bem como maneiras melhores de organizar seu código para pensar em um problema ou estruturá-lo para facilitar a leitura. O ReSharper, em certo sentido, mantém você informado sobre as práticas recomendadas para descartar códigos, em vez de permitir que você volte a hábitos ruins ou obsoletos, ou pior, o tipo ruim de preguiça.

Um bom codificador precisa entender construções básicas, mas não digitá-las manualmente. O bom tipo de preguiça permite que as ferramentas executem o trabalho pesado, e o tempo extra economizado é gasto pensando no problema. Isso torna um desenvolvedor melhor em geral.

Eu completaria a linha de raciocínio afirmando que, se o processo de entrevista favorece paus e facas de pedra, é fundamentalmente quebrado.

Essa é uma das razões pelas quais peço às pessoas que codifiquem no quadro branco, não no IDE. Nivela o campo de jogo. E as pessoas dizem "oh querido, o compartilhador lida com isso normalmente para mim". Caramba, os trechos incorporados manipulam loops e coisas do tipo, que o quadro branco não pode fornecer. Nesse caso, dizer algo como "Espero que a pontuação esteja lá; eu sou um cara do R #" é provavelmente tudo que você precisa para me impedir de manter alguns problemas de sintaxe contra você.

Preciso de alguma capacidade de escrever código compreensível no quadro branco para que possamos ter uma reunião em que descobrimos como faremos as coisas. E, é claro, quero ver se você realmente escreveu código em sua vida ou não. Suas entrevistas podem variar.

Grande questão a propósito - eu sempre pensei nisso.

O domínio de ferramentas é uma habilidade essencial para ser um bom desenvolvedor. Eu sempre senti o alarme tocar quando um desenvolvedor afirma que prefere codificar no bloco de notas a usar um IDE. Isso sugere que ele está mais interessado no processo do que no produto.

É como preferir cultivar o solo com uma enxada ou um trator - bom se você é um jardineiro de hobby, mas não é suportável como agricultor industrial em uma economia competitiva.

No entanto, nos tornamos dependentes de nossas ferramentas. As pessoas parecem surtar sobre como lidaríamos com a situação hipotética em que nossas ferramentas foram subitamente retiradas. Havia o mesmo argumento sobre a permissão de calculadoras para os exames.

A realidade é que as ferramentas ficam cada vez melhores e mais baratas e mais baratas a cada ano e não há razão para que você suponha que ficará sem elas. E as ferramentas são ótimas para fazer coisas repetitivas com um alto grau de qualidade - o que significa que podemos concentrar toda a força de nossos incríveis intelectos homo-sapien nas partes difíceis (e interessantes).

ReSharper é uma adição incrível ao Visual Studio. Minha empresa atual não tinha ReSharper quando fui entrevistada - mas eu fui tão evangélica na entrevista que me comprou uma cópia quando aceitei a posição e uma para o desenvolvedor que me entrevistou. Agora está sendo implementado em toda a empresa. Boas ferramentas se pagam em pouco tempo.

Portanto, para responder à pergunta: sua dependência de ferramentas pode causar uma avaliação falsa de suas habilidades em uma entrevista, mas elas sempre fornecerão uma avaliação correta das habilidades do entrevistador. Se uma empresa não reconhece o valor do suporte à ferramenta em sua entrevista - você precisa mostrar a luz. E se eles ainda não o verão, eu ficaria muito preocupado em aceitar uma posição lá.