Qual é o problema das linguagens de programação como requisitos estritos de trabalho? [fechadas]

Eu fui recentemente a uma "feira de empregos" e fiquei surpreso ao ver quanta ênfase os locais de trabalho parecem colocar nas linguagens de programação com as quais os candidatos estão familiarizados.

Da minha experiência (reconhecidamente limitada), embora dominar verdadeiramente uma linguagem de programação possa levar anos, aprendê-la a um nível razoável é um assunto bastante simples para alguém que já possui experiência com outras linguagens e pode definitivamente se encaixar no prazo que os empregadores costumam alocar para o aumento inicial.

Eu acho que um empregador se importaria mais com quantas linguagens / paradigmas eu estou familiarizado, ou qual é a minha experiência em design de algoritmos / software, em oposição à tecnologia específica com a qual estou qualificado no momento.

Digamos que eu já conheça Java, C ++, Smalltalk e Prolog ... um local de trabalho que se baseia no Objective-C realmente me considera desqualificado porque não tenho experiência nessa linguagem? Isso é uma falha no recrutamento de metodologias e, se for, o que posso fazer para convencer esse local de trabalho de que minha falta de experiência com o Objective-C não deve importar? Estou perguntando hipoteticamente, não especificamente sobre as linguagens de programação mencionadas.

Como alternativa, minha experiência é limitada e admito que possa estar faltando alguma coisa. A experiência anterior com uma linguagem de programação é mais crucial do que penso? Faz diferença se é uma posição júnior ou sênior? Deveria fazer a diferença?

Ao contrário dos comunicados de imprensa, é um mercado para empregadores no momento.

Isso significa que eles podem simplesmente ser exigentes quanto aos seus requisitos. Significa que eles podem exigir experiência no .NET 4.0, e não apenas na experiência 3.5 ... Significa que podem exigir experiência no Django, e não apenas em Pylons, etc ...

Claro, você pode aprender tudo o que precisa saber sobre Ruby em algumas semanas, e o Rails pode levar alguns meses (apenas supondo) para se tornar proficiente em ...

Mas o empregador pode selecionar currículos de pessoas que já são proficientes em Ruby & Rails.

TL; DR: Econ 101 ... Não acredite no hype sobre a escassez de programadores .

A questão principal é que ninguém realmente sabe como contratar bons programadores. A questão secundária é que os trabalhos de programação atraem muitos candidatos.

Dada uma grande pilha de currículos, seria muito bom poder examiná-los e escolher os bons programadores, mas ninguém sabe como fazer isso. Do jeito que a maioria das empresas trabalha, a classificação inicial geralmente é feita pelo RH. A pessoa de RH não conhece nada de Smalltalk ou C ++, exceto conforme listado na lista de requisitos, ao contrário de uma pessoa de software que pode pensar em "C ++ AND Smalltalk - esse cara não terá problemas com o Objective-C".

Mesmo quando a pilha vai para o gerente de contratação, é provável que seja muito grossa para entrevistar todo mundo; portanto, o gerente de contratação precisa jogar currículos por algum motivo ou outro. Se for um trabalho em C ++, e houver mais pessoas com mais de 5 anos de C ++ do que o gerente acha prático entrevistar, o gerente pode lançar todos os currículos que não possuem C ++. Não é o caminho para obter as melhores pessoas absolutas, mas ninguém sabe como contratar as melhores pessoas absolutas, e se você está limitado na tomada de decisões pelo que está no currículo, as pessoas com experiência em C ++ são pelo menos um pouco melhores apostas.

Vamos mudar de idéia - se você conhecesse o objetivo C, seria útil como programador em C ++? Eu diria que não, os idiomas são muito diferentes. Mesmo em linguagens simples como C, eu gostaria de ter 6 meses de experiência antes de contratar alguém, por C ++ vários anos.

Alguns anos atrás, eu me ensinei PHP. Eu diria que levou vários meses até que eu conseguisse algo bom, conseguisse encontrar o caminho pela biblioteca, entendesse expressões comuns etc. E eu já conhecia muitas línguas.

Depende de vários aspectos do contexto. Não apenas o nível da função, mas também o estado do projeto e da empresa.

No nível mais simples, qualquer linguagem imperativa entre chaves é praticamente a mesma que qualquer outra.

Se você pode codificar no imperativo, pode codificar no imperativo. Seja Java, C #, C, C ++ ou até javascript. Dado um livro de referência decente (e possivelmente um pouco de clichê), você deve poder executar um pequeno programa em qualquer um dos outros em uma tarde.

Seja qual for o seu histórico, você conhece ramificações e funções de loops, e a sintaxe é praticamente a mesma para todos eles. Se seu histórico é OO, você também conhece objetos, classes e interfaces.

No entanto, já vi muitos programadores imperativos lutando para escrever programas simples em linguagens declarativas ou funcionais. Se eu dirigisse uma loja de Erlang, preferiria fortemente alguém com experiência com Erlang, ou pelo menos Prolog,, em vez de alguém com C ++.

Como isso depende do nível do papel:

Recrutamento para uma função júnior:

Se eu estivesse escolhendo um programador para um trabalho em C ++, há certas armadilhas que eu gostaria de ter certeza de que o candidato é capaz de evitar, como a necessidade de prestar atenção à memória ou ao comprimento das matrizes, simplesmente para que elas não ocorram. atiram em si mesmos (e eu) no pé. Se eles nunca fizeram C ou C ++, então eu teria que resolver isso na entrevista.

E para um cargo sênior:

Uma das chaves para programar com eficiência é saber o que você não deve escrever. A chave para isso, são as bibliotecas padrão (e padrão de fato). A chave para isso é a experiência. Você não pode simplesmente sentar-se com "Teach yourself Java" por uma semana e transformar-se instantaneamente de um programador C ++ de 10 anos em um programa Java de 10 anos.

Como isso depende do estado do projeto / empresa

Dado um projeto Java que é praticamente uma lista limpa. Eu gostaria que um novo contratado sênior tivesse muito conhecimento sobre o ecossistema Java e pudesse aconselhar sobre as diferentes tecnologias disponíveis.

Dado um projeto Java maduro, eu consideraria feliz um desenvolvedor C ++ experiente, com pouca ou nenhuma experiência em Java para uma função Java sênior. A maioria das decisões do ecossistema já foi resolvida e o novo contratado poderá ganhar experiência com as bibliotecas Java enquanto a empresa aproveita a experiência do programador no desenvolvimento de software OO.

Depende do local de trabalho. Se estiverem muito ocupados, talvez não tenham tempo para esperar que você atinja um ponto em que você possa funcionar no Objective-C - eles podem querer alguém que possa bater no chão correndo.

Alguns locais de trabalho podem estar dispostos a arriscar você se perceberem que você está familiarizado com outros idiomas, além de ter fundamentos sólidos e conhecimento do domínio comercial. Isso realmente dependerá de como eles são abertos e de quão bom você é em convencer o recrutador a assumir esse risco.

Contratar é difícil; contratar pessoas boas é ainda mais difícil. Fiz a contratação onde me deparei com uma pilha de mais de 500 currículos. É claro que filtramos as pessoas com menos experiência no que queríamos reduzir a pilha a um tamanho razoável. Isso é justo com o excelente candidato que não conhece esse idioma, provavelmente não? Mas se eu encontrar 100 pessoas que possuem as qualificações que estou procurando, realmente não vou gastar muito tempo com as 400 que não tiveram - não importa quão boas elas sejam.

Agora, na contratação, posso ter uma longa lista de requisitos, mas geralmente apenas um ou dois são quebra de negócio. E se você não encontrar alguém com a lista inicial de qualificações que deseja entrevistar (ou mais tarde, se todos falharem na entrevista que eu vi acontecer), geralmente eles voltarão e olharão para as pessoas que estão perdendo das qualificações menos críticas ou pessoas que têm algo semelhante, mas não são as mesmas. Nesses casos, você geralmente procura algo sobre a experiência da pessoa que a torne melhor para o seu trabalho do que alguém com todas as qualificações técnicas. Por exemplo, eu consideraria um analista de dados com experiência em um banco de dados corporativo diferente se ela tivesse experiência no meu domínio comercial (na verdade, essa pessoa provavelmente faria meu primeiro corte se eu visse todos os currículos). A mesma coisa com algo como C # e Java. Se a pessoa estiver realizando um trabalho com um nível semelhante de complexidade e especialmente em um domínio comercial semelhante, ela poderá ser uma candidata muito boa, mesmo que tenha o outro idioma.

No entanto, a menos que eu tivesse um programa de treinamento bastante formal para pessoas iniciantes, seria menos provável que eu contratasse pessoas que não encontrassem meu conjunto mínimo de idiomas. E quase nunca de um grupo que não tinha nada do que eu estava procurando. Pessoas sem experiência têm menos para levar à mesa em termos de alguma qualificação compensatória e menos histórico para provar que podem fazer um trabalho de nível profissional em qualquer idioma. Eles têm o suficiente para aprender com seu primeiro show profissional, sem entender o idioma mais importante que usamos. Contratá-los é mais um risco de levar meses para que você possa obter um trabalho útil deles.

Um outro ponto entra em jogo se o oficial contratante estiver movendo a equipe para uma nova tecnologia. Se ninguém na equipe é realmente especialista em tecnologia e eu tenho que contratar alguém novo também, procurarei contratar alguém com o máximo de experiência possível nessa tecnologia, porque eles têm uma idéia de onde as "minas terrestres" "evitar são.

Por fim, inscreva-se nos empregos nos quais está interessado, mesmo que não atenda a todos os requisitos estabelecidos (mas tente atender a alguns, contratar funcionários não gosta de perder tempo com pessoas que nunca seriam contratadas). Você nunca sabe qual é a concorrência que terá por um emprego ou o que mais impressionará as pessoas que examinam os currículos ou fazem as entrevistas. O que pode lhe proporcionar uma entrevista na empresa A pode ser exatamente o que impede você de obter a entrevista na empresa B, mesmo que eles tenham requisitos semelhantes no papel. Além disso, eles podem ter um emprego que melhor atenda às suas qualificações que ainda não foram anunciadas. Mas você nunca será considerado para o trabalho se eles não souberem sobre você.

Deveria ? Não faz isso? Sim, infelizmente. Essa é a síndrome do "esquilo roxo": a empresa também quer comer o bolo e conseguir um candidato que possa fazer tudo sob o sol de que precisa ou pode precisar. Freqüentemente, mas nem sempre, isso ocorre porque eles A) Não têm idéia do que realmente envolve o desenvolvimento e apenas supõem que alguém que atenda a todos os seus critérios possa fazer o trabalho, B) Eles estão sendo exigentes porque conseguem se safar, ou C) Eles planejam apresentar um H-1B / Green Card / Promover a partir de dentro, mas precisam fazer parecer que estão anunciando um emprego real.

"Digamos que eu já conheça Java, C ++, Smalltalk e Prolog ... um local de trabalho que confie no Objective-C realmente me considere não qualificado, porque não tenho experiência nessa linguagem?"

Se você tem mais de 20 anos de experiência em 3 ou 4 idiomas com recursos semelhantes ao Objective-C, provavelmente contrataria você para fazer o Objective-C e esperaria que você fosse produtivo em 6 a 8 semanas. (isso se baseia na minha experiência pessoal com a aprendizagem do Objective-C há alguns anos).

Se você é verde logo após a escola e não tem nenhuma experiência prática real tangível, provavelmente não será contratado para fazer algo com o qual não está familiarizado.

Objective-C é um homem de palha interessante aqui. Requer que você conheça C muito bem, exige que você conheça muito bem a Análise e o Projeto Orientados a Objetos; na maioria dos casos, exige que você conheça C ++ em uma extensão não trivial, porque existem bibliotecas C ++ com as quais você provavelmente desejará interagir.

Exige que você entenda o gerenciamento manual de memória, como funciona o gerenciamento automático de memória / coleta de lixo e quando usar cada técnica no mesmo programa.

Não é apenas o Objective-C que você precisa conhecer também o Cocoa e o POSIX, porque, para isso, o Objective-C é inútil para todos os fins práticos fora dos ambientes da Apple e você também deve conhecer o Cocoa.

E quando o Cocoa falhar, você precisará saber quais APIs do POSIX usar quando não puder fazer o que deseja com os invólucros do Cocoa.

Isso também implica que você também deve conhecer o Unix em uma extensão não trivial.

Depende do idioma / indivíduo.

Se eu sou um local C # e se alguém com experiência em JAVA / J2EE se aplica, darei uma chance. A sintaxe entre C # e JAVA não é tão diferente. Codificação é codificação e eu acho que, uma vez que eles se acostumem a algumas das diferenças, ficarão bem.

O mesmo vale para JAVA -> C #.

Agora, se você era uma pessoa em C # e se candidatava a um emprego em C ++, quero ter experiência. Existem muitas diferenças.

Então sim, depende da situação

Embora eu ache que o OP está morto sobre como um programador experiente em muitos paradigmas pode facilmente adicionar mais um, tudo se resume à aversão do empregador ao risco. Um contratado em potencial que não esteja familiarizado com suas ferramentas é um curinga; elas podem ser realmente ótimas, mas também podem ser um fracasso, e será mais difícil do que o normal para o entrevistador diferenciar se não puderem fazer perguntas detalhadas sobre as tecnologias que usam.

Definitivamente, não estou dizendo que essa é a maneira correta de encarar isso, mas é o que alguns empregadores fazem. Os inteligentes exploram isso e juntam os incríveis programadores com 30 anos de experiência em C ++, enquanto os estúpidos os rejeitam porque não têm os 15 anos necessários de experiência em Ruby on Rails. Os programadores também podem explorar isso, evitando o emprego com empregadores que são tão mal informados. Afinal, quem quer trabalhar para um lugar que sistematicamente toma más decisões de contratação?

Em parte, trata-se de RH jogando palavras-chave em uma descrição do trabalho, pois elas realmente não entendem o papel. É por isso que você ocasionalmente encontrará a situação cômica de uma descrição de cargo especificando 3 anos de experiência em uma tecnologia que só existe por 6 meses.

Quanto a saber se é ou não deve fazer a diferença, que realmente depende do papel e os indivíduos envolvidos. Quase todos os gerentes que contratam (certamente todos os mais inteligentes) instruirão o RH a passar para eles candidatos que têm muita força na maioria das áreas, mesmo se eles não tiverem um ou dois pontos na descrição do cargo. No entanto, isso geralmente não se aplica a um recém-formado; Estou falando de pessoas com muita experiência profissional interagindo com clientes ou liderando equipes ou algo assim.

Eu acho que um empregador se importaria mais com quantas linguagens / paradigmas eu estou familiarizado, ou qual é a minha experiência em design de algoritmos / software, em oposição à tecnologia específica com a qual estou qualificado no momento.

Você já olhou para todos os elementos que compõem sua pilha de desenvolvimento? Por exemplo, qual IDE, estrutura de teste, integração contínua, controle de versão, metodologia de desenvolvimento e paradigmas de código que compõem um ambiente que alguém usa para criar software. Pode ser uma série de ferramentas que algumas empresas podem querer que alguém já conheça, em vez de precisar pegar do zero. O argumento da ironcode sobre o mercado de um empregador é outro fator aqui, pois pode haver alguns casos em que há muita concorrência por uma posição e, portanto, as empresas podem mirar no céu e possivelmente obtê-lo.

Apenas para dar um exemplo mais concreto sobre esse ambiente, aqui está o que tenho onde trabalho: Visual Studio 2008 usando o ASP.Net usando C # principalmente, nUnit, Cruise Control.Net, Subversion, Agile / Scrum, com uma mistura de procedimentos, OO e funcional, dependendo da localização. Se eu quisesse migrar para Java, isso pode significar me acostumar com novas ferramentas para muitas dessas funções que podem não ser o que um empregador deseja absorver como custo de contratar-me para essa função. Também pode haver alguns pontos complicados que aqueles com experiência nessa versão podem conhecer melhor que outros e evitar algumas armadilhas que, de outra forma, levariam alguém a dizer: "Por que eles construíram dessa maneira?"

Não, olhe. Esses requisitos não são reunidos pelos profissionais de TI. Eles são reunidos pelo pessoal de RH. E a maneira como o pessoal de RH obtém os requisitos é gritando perguntas para o pessoal de TI, enquanto cambaleiam para a máquina de café.

Então eles dizem "Do que você precisa?" e o idiota aleatório que acaba respondendo diz: "Um programador. Precisa de alguns anos de experiência. Tipo, eu não sei, 4? E seria bom se ele soubesse .Net". Uma resposta razoável.

Mas ele é traduzido para "4 anos de experiência em .Net 4" e é .Net 4 porque, quando você pesquisa no Google .Net, o primeiro link o leva a uma página que fala sobre .Net 4.

Há também a possibilidade, e já deparei com isso algumas vezes, de que eles tenham um requisito específico de linguagem porque desejam seguir nessa direção e acham que será mais suave se houver uma pessoa experiente na equipe.