Était-il vraiment inapproprié de rédiger une demande de retrait pour l'entreprise avec laquelle j'ai passé un entretien ?

Il est clair que ce n'était pas un bon choix tactique pour cette entreprise, mais il est assez idiot de se donner la peine de créer un dépôt public et de mépriser les gens parce qu'ils ont le culot de soumettre des demandes d'extraction. Dire “non” à une demande d'extraction n'est pas un fardeau. Si j'avais été l'interviewer, je vous aurais donné des points bonus pour avoir démontré un réel intérêt pour l'entreprise et montré que vous savez comment travailler avec un projet open source dans un dépôt public. Cela serait vrai même si le code soumis était naïf quant à la résolution du problème.

Puisqu'une offre d'emploi est en ligne, vous devez vous assurer que le code que vous soumettez est de haute qualité (demandez à quelqu'un d'autre de le regarder), et gardez tout commentaire dans le code ou dans la demande de tirage humble et poli.

La partie qui me fait le plus réfléchir ici est “une façon beaucoup plus simple et évolutive d'écrire une fonction”. Je n'ai pas vu votre code et je ne comprends pas le contexte de votre changement, mais il ne semble pas que vous ayez corrigé un bogue, ajouté une fonction, amélioré les performances ou fait quelque chose que les responsables du projet ont considéré comme significatif. Je peux voir comment le fait de soumettre une demande de modification non sollicitée de cette nature n'a pas laissé la meilleure impression.

De nombreux projets open source (et souvent aussi des projets de développement fermés) ne sont pas gérés comme les articles de Wikipedia où chacun est encouragé à faire de petites modifications tout le temps. Tout changement a un coût non nul : le temps de le réviser, de le tester et de l'approuver, le risque de casser quelque chose (même avec une suite de tests robuste), de créer quelque chose que moins de membres de l'équipe comprennent, etc… Par conséquent, de nombreux projets ne sont pas particulièrement motivés pour changer les choses simplement parce qu'il existe une infinité de façons d'écrire une fonction et que rien ne serait fait si chacun modifiait régulièrement le code de travail existant pour répondre à sa définition personnelle de “meilleur”. Lorsqu'il est temps de remanier, il est plus probable que cela implique un responsable de projet, plutôt qu'un nouveau contributeur, et cela est généralement accompagné d'une sorte de justification. Ce sont des normes, et comme toutes les normes, elles varient et sont généralement des choses que l'on est censé apprendre par osmose plutôt que d'être enseigné. Si vous êtes un jeune diplômé, il est probable que rien de tout cela n'était particulièrement apparent à l'époque.

La plupart des demandes d'extraction répondent à un besoin plus évident : corriger un bug ou ajouter une fonctionnalité. Et même dans ces cas, il est souvent préférable de discuter de la tâche avec le responsable en premier, car il peut avoir un contexte et des préférences dont vous n'avez pas connaissance.

Je ne pense donc pas qu'il soit intrinsèquement inapproprié de soumettre une demande pull pendant le processus d'entretien (cela montre certainement de l'intérêt et de l'enthousiasme), mais de leur point de vue, ils peuvent vous avoir vu comme quelqu'un qui est susceptible de réécrire du code de travail sans grande justification, et puis ils ont malheureusement réagi négativement et avec condescendance à votre égard. Ce qui, de manière utile, vous en dit long sur eux et sur ce que cela aurait été de travailler avec eux.

**Le problème n'est pas que vous avez fait une demande de retrait, mais que vous l'avez fait pour quelque chose qui vous a fait paraître arrogant, ignorant et inconscient de vos propres limites. Vous décrivez votre changement comme rendant leur code “beaucoup plus simple et à l'épreuve du temps” ; il semble évident, d'après la section citée ci-dessus, qu'ils ne sont pas d'accord. De plus, comme ils sont plus expérimentés que vous et qu'ils connaissent leur propre base de code, il est très probable qu'ils aient raison et que vous ayez tort.

Il est fréquent que les diplômés sortent de leurs diplômes en surestimant fortement leurs propres compétences. Ils n'étaient pas ennuyés parce que vous avez émis une demande de retrait, mais parce que vous avez semblé démontrer un manque de compréhension de vos propres limites et un manque de respect pour leurs compétences dans la soumission que vous avez faite. Il est probable que vous avez aggravé cette impression pendant l'entretien.

Enfin, ne vous attardez pas trop sur une partie particulière d'un entretien en particulier : il se peut que cela n'ait rien à voir avec le fait que vous n'ayez pas obtenu le poste et qu'ils aient simplement eu un meilleur candidat. Vous n'en savez rien. Ne soyez pas obsédé par ce revers et concentrez-vous plutôt sur la prochaine candidature. Bonne chance dans votre recherche d'emploi !

“Inapproprié” n'est peut-être pas le meilleur mot, mais “non stratégique” serait probablement exact.

Comme ce qui semble être un travailleur encore relativement nouveau dans un domaine technique, l'une des premières choses que vous devrez apprendre est que la prise de décision sur la façon de faire quelque chose, et quand il vaut la peine de le changer, n'est pas une chose simple. Étant donné que vous avez l'envie de changer quelque chose qui a déjà fonctionné sans qu'on vous le demande, vous risquez de vous retrouver souvent accusé de “vénérer le nouveau et le brillant” sans comprendre le coût du changement, les raisons complexes pour lesquelles quelque chose a été fait de cette façon, ou toute l'étendue des nouvelles questions que votre idée introduirait. Le fait est que, dans une certaine mesure, peu importe ce qui est objectivement le meilleur, c'est surtout ce qui est subjectivement le meilleur pour une organisation à un moment donné qui compte. Le changement a un coût réel en brisant la conscience existante, donc une nouvelle méthode doit être substantiellement meilleure dans les domaines qui comptent et pas seulement un peu mieux en théorie ou un peu plus alignée sur les tendances et la pensée contemporaines.

Si vous voulez vous “porter volontaire” sur quelque chose sans qu'on vous le demande, vous serez probablement mieux reçu pour vous attaquer à de véritables bogues remarquables qui ont un impact sur les utilisateurs, que pour réécrire de façon audacieuse des choses qui ont déjà fonctionné. Si vous parvenez à comprendre un problème non résolu, voyez si vous pouvez apporter une modification aussi minime et difficilement modifiable que possible, avec un message de commit de première classe. Expliquez clairement pourquoi cette modification est la bonne façon de résoudre le problème, et faites en sorte qu'elle s'intègre parfaitement dans le style et la méthodologie actuels du code. Si vous pensez vraiment qu'une section doit être réécrite, n'y pensez plus jusqu'à ce qu'on vous demande de contribuer et que vous soyez conscient des priorités, de l'historique et de la nature de la base de code en général. Et soyez prêt à comprendre pourquoi le changement que vous voulez apporter n'est pas conforme à leurs priorités et à leur plan. De manière quelque peu contre-intuitive, plus vous pouvez démontrer votre compréhension du code actuel en effectuant des corrections qui s'intègrent parfaitement à ses traditions, plus vous avez de chances de gagner la confiance nécessaire pour orienter les choses dans de nouvelles directions. Vous pouvez également faire flotter des changements drastiques de manière plus informelle - “hey je pensais que nous pourrions améliorer cette partie si nous la réécrivions pour utiliser le pliage en fuseau” et évaluer la réaction avant de la faire réellement.

D'un point de vue personnel, je suis très heureux quand un candidat a même a des repos Github ou un autre type de portefeuille, et qu'il a fait des recherches sur ce que fait l'entreprise. C'est le cas de 3 à 5 % de tous les candidats.

Un candidat qui démontre potentiellement les deux très directement, en corrigeant / améliorant notre code ? Ils ont probablement manqué une bonne embauche, et vous avez certainement évité de rejoindre une culture terrible.

Vous n'avez rien fait de mal. Si une demande d'extraction qui refaçonne une fonction du code a fait basculer leur bateau, cela ne laisse pas beaucoup de place pour des interactions plus complexes.

Le rôle du responsable du projet (ou du réviseur) est de démêler toute politique (arrogance perçue, incompétence) du code lui-même, et de réviser le code objectivement. Si un réviseur reçoit une demande d'extraction et se concentre uniquement sur la politique (“Comment osez-vous soulever cette question ?”) et ne révise même pas le code, il est très inefficace dans son rôle.

Pour être honnête, il ne semble pas qu'il cherche quelqu'un de votre calibre, soyez heureux de rejoindre bientôt une meilleure société.

Comme l'a dit @Kyralessa, il se peut que ce soit votre commentaire et non votre PR Qu'avez-vous saisi comme commentaire à votre demande de retrait ? C'est la pièce maîtresse qui manque ici. Vous avez peut-être involontairement indiqué dans votre commentaire que les développeurs d'origine étaient des idiots et que vous étiez bien supérieur. Le mot clé ici est “involontairement”. En tant que développeur, c'est très facile à faire. Je ne dis pas que vous avez fait cela, mais c'est une possibilité certaine.

**… Une autre possibilité, comme d'autres l'ont mentionné, est qu'ils sont surprotecteurs de leur code, et peut-être qu'ils ne veulent pas s'occuper de l'encadrement d'un jeune diplômé ayant de l'initiative et qui va avoir besoin (comme tous les autres dans le même bateau) d'un encadrement et d'une surveillance importants pour s'assurer qu'il ne fera pas d'énormes gaffes (je parle par expérience, ayant été l'un d'entre eux il y a des années). Ils ne savent peut-être tout simplement pas comment faire passer un entretien au type de candidat qu'ils veulent et ont bâclé leur partie du processus d'entretien.

Dans la plupart des entreprises, vos actions seraient perçues positivement même s'il y avait une bonne raison technique de rejeter votre demande de retrait au final : C'est-à-dire, à moins que le code que vous avez écrit n'ait été complètement absurde et les ait convaincus que vous n'aviez pas l'expérience qu'ils supposaient avoir depuis les premiers entretiens, ou que vous ayez réussi à les insulter dans le commentaire.

Il a dit que j'en savais plus qu'eux en tant que nouveau diplômé et que je n'avais pas réfléchi à la raison pour laquelle ils l'avaient codé comme ça. Je n'ai pas fini par obtenir le poste.

Considérez-vous chanceux de ne pas avoir obtenu le poste, parce que le traitement que vous avez obtenu pour cette demande de retrait est probablement un avant-goût du traitement que vous auriez obtenu si vous aviez travaillé dans cette entreprise et proposé ce changement (ou tout autre).

Pour être parfaitement clair : Oui, je trouve qu'il est très probable que votre RP ne leur convenait pas et qu'ils ont vraiment de bonnes raisons d'avoir leur code comme ils le font, plutôt que comme vous l'avez proposé. En d'autres termes, je crois vraiment que votre code était probablement plus simple, mais pire. ** Cependant, à moins que vous n'ayez inclus un commentaire grossier dans le RP, l'hypothèse du senior qu'une simple suggestion est “inappropriée”, que c'est une façon arrogante de dire “j'en sais plus que vous”, et qu'un candidat ayant fait des études universitaires ne peut pas, en fait, en savoir autant qu'eux ou plus, est un triple drapeau rouge parce que :

• Il fait soupçonner que si vous y travailliez, même vos bonnes idées seraient rejetées entièrement au motif que vous êtes un junior, juste pour que les seniors puissent justifier leur propre rôle et leur salaire.
• Cela démontre que les seniors ont de sérieuses insécurités quant à leur propre expertise - et je serais enclin à penser que ces insécurités pourraient être justifiées.
• Si ce senior se trouve à manquer d'éducation formelle en matière de logiciels, il y a une incitation supplémentaire pour eux à essayer de minimiser l'importance d'un diplôme et de l'expertise qu'on en tire, de peur que leurs propres managers ne les remplacent éventuellement par des développeurs tout aussi expérimentés qui ont également des certifications.

Juste pour vous donner un peu de perspective, j'ai une fois interviewé quelque part et dans le processus, j'ai fait une suggestion quelque peu radicale aux seniors sur un système qu'ils étaient en train de construire. Non seulement ils l'ont accueillie favorablement et l'ont prise en considération, mais ils m'ont également fait une offre peu de temps après.

De tels environnements existent - toutes les entreprises n'emploient pas un modèle professeur/élève à sens unique où le savoir circule strictement des seniors aux juniors. (Et n'oubliez pas que si vous avez obtenu votre diplôme, vous n'êtes _pas un “étudiant”, et beaucoup de seniors dans cette industrie ne sont pas non plus des “ingénieurs”, quel que soit le nom qu'une entreprise décide de leur donner).

Le problème, c'est que votre “amélioration” était naïve et artificielle, et je le sais parce que vous avez pu la faire en beaucoup moins de temps.

Cela m'arrive tout le temps. Je construis un système complexe pour permettre aux données de servir de nombreux utilisateurs. Et puis quelqu'un arrive et dit : “Nous n'avons pas besoin de tout ce bazar ! Vous rendez un problème simple beaucoup trop complexe”. Et ils piratent et sabrent, et le réduisent à un système simple qui les sert bien, et ils se donnent une étoile d'or.

Sauf qu'ils ne sont pas les seuls utilisateurs. Et les modifications viennent de le briser pour tous les autres utilisateurs de ces données. Alors il doit y avoir quelque chose… des réunions, de la rééducation, de l'amertume, des reculs, tout cela était inutile.

Le codage est la partie facile. La partie difficile est de comprendre et d'exprimer le problème. Vous avez court-circuité la partie difficile, pour rendre la partie facile plus facile.

Si on vous apprenait que le codage est roi, eh bien, pas vraiment. L'autre aspect est celui de l'argent : être capable d'écrire une spécification qui est codable et qui gère tous les utilisateurs/besoins. (à l'autre bout de l'échelle, il est également possible de concevoir des solutions qui sont tout en chant et tout en danse, mais qui ne peuvent être écrites, c'est pourquoi vous devez connaître le codage pour les concevoir).

C'était le cœur du problème. Vous n'avez pas entièrement compris le problème que le code essayait de résoudre.

Et vous leur avez montré cela de façon spectaculaire.

Dans les jeux, un “débutant” est un simple novice. Un “noob” est un novice dont l'arrogance l'empêche d'apprendre, ou de respecter l'expérience des autres ou de ses aînés en général. Il semble que ce dernier point s'applique davantage à vous, parce que vous avez pu si facilement raccourcir ce code, et il ne vous est pas venu à l'esprit que c'était trop facile , il devait y avoir une raison pour laquelle ils l'avaient écrit si complexe.

et que je n'ai pas réfléchi à la raison pour laquelle ils l'ont codée comme elle l'était.

Oui, c'est vrai. Dans certains cas, le code est écrit pour soutenir une fonction commerciale particulière ou une règle que les programmeurs ne peuvent pas contrôler.

Je l'ai examiné pendant un certain temps et j'ai trouvé une façon beaucoup plus simple et évolutive d'écrire une fonction, et j'ai ouvert un RP avec le changement sans mentionner que j'étais en train de passer un entretien.

En tant que jeune, nous aimons penser que nous sommes intelligents. Que nous avons tout compris. La vérité est que si vous y avez pensé, quelqu'un d'autre aurait pu le faire aussi bien puisque vous avez évidemment “trouvé” une meilleure façon en cherchant sur Google ce que les autres faisaient. Chaque fois que vous pensez à quelque chose d'aussi évident, vous devriez vous arrêter et vous renseigner d'abord sur ce qui est accompli de la manière actuelle. Bill Gates n'a pas cherché sur Google sa façon de construire Windows, il y a pensé et l'a mise en œuvre. A moins que vous ne puissiez faire de même, vous n'avez pas trouvé de “meilleure façon”. Il suffit de googler mieux que la dernière personne.

Etait-ce vraiment inapproprié pour moi de faire cela ?

En tant que RP de leur maître, oui c'était légèrement inapproprié. Peut-être une branche de votre propre entreprise que vous pouvez partager lors de l'entretien. J'ai vu comment vous avez fait X et en faisant des recherches, j'ai trouvé Y qui permet une preuve future et une modification plus facile. Je sais que vous l'avez écrit pour une raison, mais j'étais curieux de démontrer un concept basé sur votre code" _ Je sais que dans git vous pouvez utiliser les symboles @ et même ouvrir une chaîne de discussion. Peut-être serait-il préférable la prochaine fois de commenter la section que vous avez modifiée avec un,

@user Je remarque que vous faites un X ici, mais j'ai mis un Y. Je voulais montrer ma capacité à lire votre code et à faire des modifications, etc

En faisant un PR à leur maître, c'est essentiellement la même chose que l'histoire de l'homme qui voulait être plombier, ne pouvait pas trouver de travail, donc a décidé de “réparer” une fuite de gaz dans son quartier. Vous pouvez imaginer le résultat final qui s'est produit.

Pour compléter les autres réponses,

**êtes-vous sûr que votre code était effectivement correct et utile dans cette base de code particulière ?

Votre correction peut sembler beaucoup plus simple et plus robuste ; cependant, il se peut facilement que l'ancien code ait été écrit de la manière dont il a été écrit à dessein. Votre demande d'extraction a probablement modifié certains aspects du comportement (vous pourriez même penser que vous avez corrigé un bogue), mais il y a un code distant qui s'appuyait sur ce bogue. Vous n'avez probablement pas tenu compte de la façon dont le code a été utilisé, et votre code est donc pire dans cette situation particulière. Par exemple, votre code peut ne pas fonctionner dans un environnement multithread, ou les données que le code traite peuvent avoir des propriétés non évidentes qui font que l'ancien code fonctionne mieux et plus rapidement.

Pour ce que nous en savons, vous avez peut-être négligé une raison stupide (un bug dans votre code, ou le fait que votre code fonctionne plus lentement, etc. Après tout, ils travaillent avec ce code depuis longtemps, et devraient probablement savoir beaucoup mieux comment il fonctionne. Le fait qu'ils aient dit “que [vous] n'avez pas considéré pourquoi ils l'ont codé comme il était” suggère ceci.

Ceci dit, je suis d'accord avec d'autres personnes qui disent qu'ouvrir un PR n'est rien de mal. Cependant, comme pour toute nouvelle base de code, il est souvent préférable d'en discuter avec les responsables. Étant donné que vous étiez en cours d'interview à ce moment-là, vous auriez pu simplement soulever cette question lors de l'interview.

Il est difficile de voir comment il pourrait être intrinsèquement inapproprié d'écrire un article de relations publiques pour un projet open-source.

Il faut donc en venir aux détails, dont nous savons très peu. Était-ce naïf ou arrogant dans le code ou l'attitude ? Etait-ce utile et amical ? Sans en savoir plus, il est difficile d'en évaluer la pertinence.

La curiosité a eu raison de moi. J'ai trouvé vos relations publiques. Et cela m'a tellement impressionné que j'ai décidé de le partager ici. Ce n'était pas une décision légère car je ne veux pas trahir la confidentialité ni de vous ni de la société, mais j'ai estimé que cela apporterait un contexte substantiel à la discussion d'une manière acceptable. L'absence de détails concrets a certainement conduit à beaucoup de spéculations non fondées

J'ai complètement anonymisé et obscurci le PR en changeant toutes les variables, chaînes, méthodes et commentaires personnalisés. Le voici, dans son intégralité :

# 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 "..."

Le code initialisera target en une chaîne aléatoire codée en dur. (Notez que j'ai seulement transformé les caractères de la chaîne pour masquer cette partie). Si un argument n'est pas fourni, alors some_lookup(target) ne produira pas de correspondance parce qu'il ne pourra probablement pas rechercher la chaîne par défaut intentionnellement farfelue.

C'est clairement prévu. Mais c'est aussi un mauvais codage.

Votre correction semble être une amélioration. J'en ferais moi-même la remarque dans une revue de code, sans hésitation. Et je pourrais facilement me voir écrire exactement le même message de 25 mots de commit amical et non conflictuel que vous avez écrit.

Par conséquent, ce PR particulier ne me semble pas inapproprié. Et à condition que cela soit fait de manière professionnelle, respectueuse et de bonne foi, une RP ne serait jamais inappropriée, y compris lors d'un entretien.