Foi realmente inapropriado escrever um pedido para a empresa que entrevistei?

É evidente que não foi uma boa escolha táctica para esta empresa, mas é bastante tolo dar-se ao trabalho de criar um repositório público e depois desprezar as pessoas por terem o chutzpah para apresentar pedidos de puxão. Dizer “não” a um pedido de “pull” não é um fardo. Raios, podiam simplesmente tê-lo ignorado.

Se eu tivesse sido o entrevistador, ter-vos-ia dado pontos bónus por demonstrarem um interesse real na empresa e mostrarem que sabem trabalhar com um projecto de código aberto num repositório público. Isso seria verdade mesmo que o código submetido fosse ingénuo quanto à resolução do problema.

Uma vez que uma oferta de emprego está em linha, deve ter a certeza de que o código submetido é de alta qualidade (peça a outra pessoa para o analisar), e manter qualquer comentário no código ou no pedido de extracção humilde e educado.

A parte que me dá mais pausa aqui é “uma forma muito mais simples e à prova de futuro de escrever uma função”. Eu não vi o seu código e não tenho conhecimento do contexto da sua mudança, mas não me parece que tenha corrigido um bug, adicionado uma funcionalidade, melhorado a performance, ou que tenha feito algo que os mantenedores do projecto consideraram significativo. Posso ver como submeter um pedido para uma alteração não solicitada desta natureza pode não ter deixado a melhor impressão.

Muitos projectos de código aberto (e frequentemente projectos de desenvolvimento de código fechado também) não são executados como os artigos da Wikipedia onde todos são encorajados a fazer pequenas alterações a toda a hora. Há um custo não zero que vem com qualquer mudança: o tempo para rever, testar e aprovar, o risco de quebrar algo (mesmo com uma suite de testes robusta), criar algo que menos membros da equipe entendem, etc… Como resultado, muitos projectos não são particularmente grandes em mudar as coisas só porque; há um número infinito de maneiras de escrever qualquer função, e nada seria feito se todos mudassem regularmente o código de trabalho existente para satisfazer a sua definição pessoal de “melhor”. Quando é altura de refactor, é mais provável que isso envolva um responsável pelo projecto, em vez de um primeiro contribuinte, e normalmente tem alguma espécie de justificação associada. Estas são normas, e como todas as normas, elas variam e são geralmente coisas que se espera que você pegue através de osmose, em vez de ser ensinado. Se foi recentemente formado, é provável que nada disto fosse particularmente evidente na altura.

A maioria dos pedidos de puxar aborda uma necessidade mais óbvia: corrigir um bug ou adicionar uma funcionalidade. E mesmo nesses casos, é muitas vezes melhor discutir a tarefa com o responsável primeiro, uma vez que podem ter contexto e preferências que você não conhece.

Por isso não acho que seja intrinsecamente inapropriado alguma vez submeter um pedido de puxar durante o processo de entrevista (certamente que mostra interesse e entusiasmo), mas da sua perspectiva, podem tê-lo visto como alguém que provavelmente reescreve o código de trabalho sem muita justificação e depois, infelizmente, reagiram de forma negativa e condescendente para consigo. O que, de forma útil, lhe diz muito sobre eles e como teria sido trabalhar com eles.

Entendeu mal o feedback que lhe foi dado e concentrou-se na parte errada

Disse que se deparou como se eu soubesse mais do que eles como um recém-licenciado, e que não considerei por que razão o codificaram como era.

O problema não é que tenha feito um pedido de puxão, mas sim que o fez por algo que o fez parecer arrogante, ignorante e inconsciente das suas próprias limitações. Descreve a sua alteração como tornando o código deles “muito mais simples e à prova de futuro”; parece óbvio na secção acima citada que eles não estão de acordo. Além disso, como eles são mais experientes do que você e familiarizados com a sua própria base de códigos, é muito provável que estejam correctos e que você esteja errado.

É comum que os licenciados saiam dos seus cursos sobrestimando fortemente a sua própria competência. Não ficaram aborrecidos por terem feito um pedido de extracção, mas sim por terem demonstrado uma falta de compreensão dos seus próprios limites e uma falta de respeito pelas suas competências na submissão que fizeram. É provável que tenha agravado esta impressão durante a entrevista.

Finalmente, não leia demasiado em nenhuma parte específica de nenhuma entrevista em particular: pode ser que isto não tenha nada a ver com o facto de não ter conseguido o emprego e de eles apenas terem um candidato melhor. Você não sabe. Não fique obcecado com este contratempo e concentre-se na próxima candidatura. Boa sorte com a sua procura de emprego!

“Inadequado” pode não ser a melhor palavra, mas “não estratégico” seria provavelmente correcto.

Como o que parece ser um trabalhador talvez ainda relativamente novo num campo técnico, uma das primeiras coisas que terá de aprender é que a tomada de decisões sobre como fazer algo, e quando vale a pena mudá-lo, não é uma questão simples. Dado que tem um ímpeto para mudar algo que já funcionou sem que lhe tenham pedido, é provável que se veja frequentemente acusado de “adorar o novo e brilhante” sem compreender o custo da mudança, os complexos razões por que algo foi feito da forma como foi, ou o âmbito total de novas questões que a sua ideia iria introduzir.

Ou talvez sejam apenas pessoas de mente pequena que o acharam irritante.

A questão é que, até certo ponto, não importa o que é objectivamente melhor, importa sobretudo o que é subjectivamente melhor para uma organização num determinado momento. A mudança tem um custo real na quebra da consciência existente, por isso um novo método precisa de ser substancialmente melhor em todos os aspectos que interessam e não apenas um pouco melhor em teoria ou um pouco mais alinhado com as tendências e pensamento contemporâneo.

Se quiser “voluntariar-se” em algo sem ser convidado, provavelmente obterá melhor recepção para lidar com bugs realmente excepcionais que tenham impacto nos utilizadores, do que para fazer reescritos ousados de coisas que já funcionaram. Se você chegar a compreender uma questão não resolvida, veja se consegue fazer uma mudança tão pequena e mínima quanto possível, com uma mensagem de compromisso de primeira classe. Torne óbvia a razão pela qual esta mudança é a forma correcta de resolver o problema, e torne-a uma mudança que se enquadre perfeitamente no estilo e na metodologia actuais do código. Dê-lhes um pedido que seja fácil de aprovar e não invoque quaisquer sentimentos complexos de compromisso.

Se realmente acredita que uma secção precisa de ser reescrita, guarde esse pensamento até que esteja a ser descrito para contribuir e esteja ciente das prioridades, história, e da natureza da base de código em geral. E esteja preparado para compreender porque é que a mudança que pretende fazer não é coerente com as suas prioridades e plano. De forma um pouco contra-intuitiva, quanto mais conseguir demonstrar compreensão do código actual, fazendo correcções que se enquadrem perfeitamente nas suas tradições, mais provável será que ganhe confiança para levar as coisas em novas direcções. Pode também flutuar casualmente mudanças drásticas de uma forma mais informal - “ei, eu estava a pensar que podíamos fazer esta parte muito melhor se a reescrevêssemos para usar o fuso dobrável” e aferir a reacção antes de o fazer realmente.

Falando do outro lado da secretária - a um nível pessoal, fico bastante contente quando um candidato até _ tem_ Github repos ou algum outro tipo de carteira, e fez alguma pesquisa de fundo sobre o que a empresa faz. Isto é como 3-5% de todos os candidatos.

Um candidato que potencialmente demonstra ambos daqueles muito directamente, ao corrigir / melhorar o nosso código? Provavelmente perderam uma grande contratação e certamente evitaram juntar-se a uma cultura terrível.

O senhor não fez nada de mal. Se um Pull Request que refactors uma função do código abalou o seu barco, isso não deixa muito espaço para interacções mais complexas.

O papel do mantenedor do projecto (ou Revisor) é separar qualquer política (percepção de arrogância, incompetência) do próprio código, e rever o código objectivamente. Se um revisor recebe um Pull Request e apenas se concentra na política (“Como se atreve a levantar este PR?”) e nem sequer revê o código, está a ser muito ineficaz no seu papel.

Para ser honesto, não parece que estejam à procura de alguém do seu calibre, fique feliz por se juntar a uma empresa melhor em breve.

Como disse @Kyralessa, pode ter sido o seu comentário e não o seu PR Qual foi o comentário ao seu pedido de extracção? Essa é a peça chave que falta aqui. Pode ter comunicado involuntariamente no seu comentário que os criadores originais eram idiotas e que você era muito superior. A palavra-chave aqui é “não intencionalmente”. Como programador, é muito fácil de fazer. Não digo que o tenha feito, mas é uma possibilidade definitiva.

… Ou têm medo de lidar com uma nova iniciativa Outra possibilidade, como outros já referiram, é que são superprotectores do seu código, e talvez não queiram lidar com o mentor de uma nova licenciatura com iniciativa, que vai precisar (como todos os outros no mesmo barco) de um mentor e supervisão significativos para se certificarem de que não cometem grandes erros (falo por experiência, tendo sido um deles há anos atrás).

…Ou eles não sabem como entrevistar Eles podem simplesmente não saber como entrevistar para o tipo de candidato que querem e estragaram o seu lado do processo de entrevista.

Na maioria das empresas, as suas acções seriam vistas positivamente, mesmo que houvesse uma boa razão técnica para rejeitar o seu pedido de puxão no final:

• Mostra o seu interesse genuíno nessa posição em particular
• É uma prova de que tem experiência prática com codificação

• Foi uma oportunidade de falar sobre código real durante a entrevista, em vez de exercícios inventados de codificação

• Ou seja, a menos que o código que escreveu fosse um completo disparate que as convencesse de que não tinha a experiência que supunham ter tido desde as primeiras entrevistas, ou de alguma forma conseguiu insultá-las no comentário.

Ele disse que se deu a entender que eu sei mais do que eles como um recém-formado universitário, e que eu não considerei por que eles o codificaram como era. Eu não acabei por conseguir o emprego.

** Considere-se sortudo por não ter conseguido o emprego** , porque o tratamento que recebeu para este pedido de atracção é provavelmente uma amostra do tratamento que teria recebido se tivesse trabalhado naquela empresa e proposto esta (ou qualquer outra) mudança.

Para ser perfeitamente claro: Sim, acho muito provável que as suas relações públicas não lhes convêm e que tenham realmente boas razões para terem o seu código da forma como o têm, em vez da forma como o senhor propôs. Por outras palavras, acredito muito que o seu código era provavelmente mais simples, mas pior. ** No entanto* , a menos que tenha incluído um comentário grosseiro no RP, a suposição do sénior* de que uma simples sugestão é “inapropriada”, que é uma forma arrogante de dizer “eu sei mais do que você”, e que um candidato com formação universitária cannot, na verdade, sabe tanto quanto eles ou mais, é uma tripla bandeira vermelha* porque:

• Levanta suspeitas de que se trabalhasses lá, ** mesmo as tuas boas ideias seriam despedidas** inteiramente com base no facto de seres um júnior, apenas ** para que os seniores possam justificar o seu próprio papel e salário***.
• Demonstra que eles têm algumas inseguranças sérias sobre os seus próprios conhecimentos - e eu estaria inclinado a pensar que estas inseguranças podem ser justificadas.
• Se esse sénior tiver falta de formação formal em software, há um incentivo adicional para tentarem minimizar a importância de um diploma e os conhecimentos que dele se retiram, para que os seus próprios gestores não acabem por substituí-los por programadores igualmente experientes que também tenham certificações.

Só para vos dar alguma perspectiva, uma vez fiz uma entrevista algures e no processo fiz uma sugestão algo radical aos seniores sobre um sistema que eles estavam em processo de construção. Não só o acolheram e consideraram, como também me fizeram uma oferta pouco depois.

Esses ambientes do existem - nem todas as empresas empregam um modelo de professor/estudante unidireccional onde o conhecimento flui estritamente dos seniores para os juniores. (E lembre-se, se você se formou então você é não um “estudante”, e muitos idosos nesta indústria também não são realmente “engenheiros”, independentemente do que uma empresa decide chamar-lhes).

O problema é que a sua “melhoria” foi ingénua e artificial, e eu sei que devido ao facto de ter sido muito mais curta.

Isto acontece-me a toda a hora. Eu construo um sistema complexo para permitir que os dados sirvam a muitos utilizadores. E depois aparece alguém e diz: “Não precisamos de toda esta estupidez! Estás a tornar um problema simples demais complexo”. E eles hackeam e cortam, e reduzem-no a um sistema simples _ que os serve bem_, e dão-se uma estrela dourada.

Exceto que não são o único utilizador. E as modificações apenas o quebraram para todos os outros utilizadores desses dados. Então tem de haver uma coisa… reuniões, reeducação, amargura, rollbacks, tudo isto foi desnecessário.

A codificação é a parte fácil. A parte difícil é compreender e expressar o problema. Você fez um curto-circuito na parte difícil, para facilitar a parte fácil.

Se você foi ensinado que a codificação é rei, bem, não realmente. O outro lado é onde está o dinheiro: ser capaz de escrever uma especificação que é codificável e lida com todos os utilizadores/necessidades. (no outro extremo da escala também é possível desenhar soluções que são todas cantadas/todas as danças, mas não escritas, é por isso que precisa de saber codificar para desenhar).

Era esse o cerne da questão. Não compreendeu totalmente o problema que o código estava a tentar resolver.

E mostrou-lhes isso de uma forma espectacular.

Nos jogos, um “novato” é um mero novato. Um “noob” é um novato cuja arrogância o impede de aprender, ou respeitar a experiência dos outros ou dos mais velhos em geral. Parece que este último é mais aplicável a si, porque foi tão facilmente capaz de tornar esse código muito mais curto, e não lhe ocorreu que isto era too easy* , tinha de haver uma razão para o terem escrito tão complexo.

e que eu não considerei porque é que o codificaram como era.

Sim, é verdade. Em alguns casos, o código é escrito para apoiar uma determinada função ou regra empresarial que os programadores não podem controlar.

Olhei para ele durante algum tempo e encontrei uma forma muito mais simples e à prova de futuro para escrever uma função, e abri um RP com a mudança sem mencionar que estava actualmente a entrevistar.

Como jovem, gostamos de pensar que somos inteligentes. Que já percebemos tudo. A verdade é que, se pensasse nisso, alguém mais poderia também ter pensado, uma vez que obviamente “encontrou” uma maneira melhor ao pesquisar no Google o que outras pessoas fizeram. Sempre que pensamos em algo tão óbvio, devemos parar e perguntar primeiro sobre isso para termos a certeza do que está a ser realizado da forma actual. Bill Gates não procurou no Google o seu caminho para construir o Windows, ele pensou nisso e implementou-o. A menos que você seja capaz de fazer o mesmo, você não encontrou uma “maneira melhor”. Você simplesmente pesquisou no Google de forma melhor que a última pessoa.

Foi realmente inapropriado para mim fazer isto?

Como RP para o seu mestre, sim, foi um pouco inapropriado. Talvez um ramo seu próprio que possa partilhar na entrevista. Eu vi como fez X e ao pesquisar encontrei Y que permite uma prova futura e uma modificação mais fácil. Sei que o escreveram por uma razão, mas estava curioso para demonstrar um conceito baseado no vosso código" _ “Sei que em git podem usar símbolos @ e até abrir uma cadeia de discussão. Talvez seja melhor da próxima vez comentar a secção que vocês modificaram com um,

@user Reparei que vocês estão a fazer X aqui, mas coloquei um Y. Queria mostrar a minha capacidade de ler o vosso código e fazer modificações, etc.

Ao fazer um RP ao seu mestre, é essencialmente o mesmo que a história do homem que queria ser canalizador, não conseguia encontrar emprego, por isso decidi "arranjar” uma fuga de gás no seu bairro. Podem imaginar o resultado final que aconteceu.

Para acrescentar a outras respostas,

** tem a certeza de que o seu código era de facto correcto e útil nessa base de códigos em particular?**

Pode parecer muito mais simples e mais robusto; no entanto, pode facilmente ser que o código antigo tenha sido escrito da forma como foi escrito de propósito.

Provavelmente o seu pedido de “pull” mudou alguns aspectos do comportamento (pode até pensar que corrigiu um bug), mas existe algum código distante que dependia desse bug.

Provavelmente não contabilizou dessa forma o código foi utilizado, e portanto o seu código é pior nessa situação em particular. Por exemplo, o seu código pode não estar a funcionar em ambientes multithreaded, ou os dados com que o código lida podem ter algumas propriedades não óbvias que fazem o código antigo funcionar melhor e mais rapidamente.

Por tudo o que sabemos pode ter esquecido alguma razão tola (um bug no seu código, ou o facto de o seu código correr mais devagar, etc.) que deveria ser óbvia para um programador experiente.

Pode ter esquecido outra coisa. Afinal, eles estão a trabalhar com este código há muito tempo, e provavelmente devem saber muito melhor como ele funciona. O facto de eles terem dito “que [vocês] não consideraram porque o codificaram como era” sugere isto.

Dito isto, concordo com outras pessoas que dizem que abrir um RP não é nada de mal. No entanto, como em qualquer nova base de códigos, muitas vezes é melhor discuti-la com os mantenedores. Dado que nessa altura estava no processo de entrevistas, poderia simplesmente ter levantado essa questão sobre a entrevista.

É difícil perceber como pode ser intrinsecamente inadequado escrever um RP para o projecto de código aberto de qualquer pessoa.

Por isso tem de se resumir aos pormenores, dos quais sabemos muito pouco. Foi ingénuo ou arrogante em código ou atitude? Foi útil e amigável? Sem saber mais é difícil avaliar a adequação.

A curiosidade levou a melhor sobre mim. Encontrei o seu RP. E causou-me uma tal impressão que decidi partilhá-la aqui. Não foi uma decisão leve porque não quero trair a confidencialidade nem de si nem da empresa, mas achei que traria um contexto substancial para a discussão de uma forma aceitável. A falta de detalhes concretos levou certamente a muita especulação não fundamentada

Eu anonimizei e ofusquei completamente as relações públicas, alterando todas as variáveis personalizadas, strings, métodos e comentários. Aqui está, na sua totalidade:

# if this is invoked with an argument then use that for target
- target = 'jadaskjafjldfsfsasf'
  if len(sys.argv) > 1:
      arg = sys.argv[1]
      if arg == '...':
          print '...'
      else:
          target = arg
-
- match = some_lookup(target)
+ match = some_lookup(target)

  if match:
      print "..."

O código inicializará target para uma string aleatória hardcoded. (Nota, eu apenas shuffled os caracteres da string para ofuscar essa parte). Se um argumento não for fornecido então some_lookup(target) falhará em produzir uma correspondência porque presumivelmente não pode procurar a string padrão intencionalmente maluca.

Isto é claramente pelo design. Mas também é objectivamente má codificação.

A sua correcção parece ser uma melhoria. Eu próprio gostaria de comentar isto numa revisão do código, sem hesitação. E pude facilmente ver-me a escrever exactamente a mesma mensagem de compromisso não conflituosa, de 25 palavras, que o senhor escreveu.

Por conseguinte, este RP em particular não me parece inadequado. E desde que seja feito de uma forma profissional, respeitosa e de boa fé, a RP nunca seria inapropriada inclusive quando se trata de entrevistas.