War es wirklich unangemessen, eine Pull-Anfrage für das Unternehmen zu schreiben, mit dem ich mich interviewt habe?

Offensichtlich war es keine gute taktische Wahl für dieses Unternehmen, aber es ist ziemlich dumm, sich die Mühe zu machen, ein öffentliches Repository einzurichten und dann Leute zu verachten, die die Chuzpe haben, Pull-Anfragen zu stellen. Nein" zu einem Abrufantrag zu sagen, ist kaum eine Belastung. Verdammt, sie hätten es einfach ignorieren können.

Wäre ich der Interviewer gewesen, hätte ich Ihnen Bonuspunkte dafür gegeben, dass Sie echtes Interesse an der Firma gezeigt und gezeigt haben, dass Sie wissen, wie man mit einem Open-Source-Projekt in einem öffentlichen Repository arbeitet. Das wäre selbst dann der Fall, wenn der eingereichte Code in Bezug auf die Lösung des Problems naiv wäre.

Da ein Stellenangebot auf dem Spiel steht, sollten Sie sicher sein, dass der von Ihnen eingereichte Code von hoher Qualität ist (lassen Sie ihn von jemand anderem überprüfen), und alle Kommentare im Code oder in der Pull-Anfrage bescheiden und höflich halten.

Der Teil, der mir hier am meisten zu schaffen macht, ist “eine viel einfachere und zukunftssichere Art, eine Funktion zu schreiben”. Ich habe Ihren Code nicht gesehen und habe kein Verständnis für den Kontext Ihrer Änderung, aber es klingt nicht so, als hätten Sie einen Fehler behoben, eine Funktion hinzugefügt, die Leistung verbessert oder sonst etwas getan, was die Projektbetreuer für sinnvoll hielten. Ich kann mir vorstellen, dass das Einreichen einer Pull-Anfrage für eine unaufgeforderte Änderung dieser Art nicht den besten Eindruck hinterlassen hat.

Viele Open-Source-Projekte (und häufig auch Closed-Source-Entwicklungsprojekte) werden nicht wie Wikipedia-Artikel betrieben, in denen jeder dazu ermutigt wird, ständig kleine Änderungen vorzunehmen. Es gibt einen Kostenfaktor, der nicht gleich Null ist und mit jeder Änderung einhergeht: die Zeit, sie zu überprüfen und zu testen und zu genehmigen, das Risiko, etwas zu zerstören (selbst mit einer robusten Testsuite), etwas zu schaffen, das weniger Teammitglieder verstehen, usw… Infolgedessen sind viele Projekte nicht besonders darauf aus, Dinge zu ändern, nur weil es unendlich viele Möglichkeiten gibt, jede Funktion zu schreiben, und nichts würde erreicht, wenn jeder regelmäßig den bestehenden Arbeitscode ändern würde, um seiner persönlichen Definition von “am besten” zu entsprechen. Wenn es an der Zeit ist, ein Refactoring durchzuführen, ist es wahrscheinlicher, dass daran ein Projektbetreuer beteiligt ist, als ein erstmaliger Mitwirkender, und es hat normalerweise eine Art von Rechtfertigung. Das sind Normen, und wie alle Normen variieren sie und sind im Allgemeinen Dinge, die man eher durch Osmose lernen sollte, als dass man sie lehrt. Wenn Sie vor kurzem Ihren Abschluss gemacht haben, war wahrscheinlich nichts davon zu diesem Zeitpunkt besonders offensichtlich.

Die meisten Pull-Anfragen beziehen sich auf einen offensichtlicheren Bedarf: die Behebung eines Fehlers oder das Hinzufügen einer Funktion. Und selbst in diesen Fällen ist es oft besser, die Aufgabe zuerst mit dem Maintainer zu besprechen, da sie vielleicht einen Kontext und Vorlieben haben, die Ihnen nicht bekannt sind.

Ich glaube also nicht, dass es von Natur aus unangemessen ist, während des Interviewprozesses jemals eine Pull-Anfrage zu stellen (es zeigt sicherlich Interesse und Enthusiasmus), aber aus ihrer Sicht haben sie Sie vielleicht als jemanden gesehen, der wahrscheinlich ohne viel Rechtfertigung funktionierenden Code umschreibt, und dann haben sie leider negativ und herablassend auf Sie reagiert. Das sagt Ihnen hilfreich viel über sie und darüber, wie es gewesen wäre, mit ihnen zusammenzuarbeiten.

Sie haben das Feedback, das Ihnen gegeben wurde, missverstanden und sich auf den falschen Teil konzentriert

Er sagte, dass es so rüberkam, als ob ich als frischgebackener College-Absolvent mehr wüsste als sie, und dass ich nicht darüber nachgedacht habe, warum sie es so kodiert haben.

Das Problem ist nicht, dass Sie eine Pull-Anfrage gestellt haben, sondern dass Sie es für etwas getan haben, das Sie arrogant, ignorant und sich Ihrer eigenen Grenzen nicht bewusst waren. Sie beschreiben Ihre Änderung so, dass ihr Code “viel einfacher und zukunftssicher” wird; aus dem oben zitierten Abschnitt scheint es offensichtlich, dass sie damit nicht einverstanden sind. Da sie zudem erfahrener sind als Sie und mit ihrer eigenen Codebasis vertraut sind, ist es sehr wahrscheinlich, dass sie Recht haben und Sie Unrecht haben.

Es kommt häufig vor, dass Absolventen nach ihrem Abschluss ihre eigene Kompetenz stark überschätzen. Sie waren nicht verärgert, weil Sie einen Pull-Antrag gestellt hatten, sondern weil Sie in dem Antrag, den Sie gestellt hatten, mangelndes Verständnis für Ihre eigenen Grenzen und mangelnden Respekt vor ihren Fähigkeiten zu zeigen schienen. Wahrscheinlich haben Sie diesen Eindruck während des Vorstellungsgesprächs noch verstärkt.

Schließlich sollten Sie nicht zu viel in einen bestimmten Teil eines bestimmten Gesprächs hineininterpretieren: Es könnte sein, dass dies nichts damit zu tun hatte, dass Sie die Stelle nicht bekommen haben, sondern dass sie einfach einen besseren Bewerber hatten. Sie wissen es nicht. Machen Sie sich nicht über diesen Rückschlag Gedanken und konzentrieren Sie sich stattdessen auf die nächste Bewerbung. Viel Glück bei Ihrer Stellensuche!

“Ungeeignet” ist vielleicht nicht das beste Wort, aber “nicht strategisch” wäre wahrscheinlich zutreffend.

Da das, was sich nach einem vielleicht noch relativ neuen Mitarbeiter in einem technischen Bereich anhört, ist eines der ersten Dinge, die Sie lernen müssen, dass die Entscheidungsfindung darüber, wie etwas zu tun ist und wann es sich lohnt, es zu ändern, keine einfache Angelegenheit ist. Da Sie den Anstoß haben, etwas zu ändern, das bereits ungefragt funktioniert hat, werden Sie sich wahrscheinlich oft beschuldigt sehen, “das Neue und Glänzende zu verehren”, ohne die Kosten der Veränderung, die komplexen Gründe, warum etwas so gemacht wurde, wie es war, oder den vollen Umfang der neuen Themen, die Ihre Idee einführen würde, zu verstehen.

Oder vielleicht sind es nur kleingeistige Leute, die Sie als lästig empfunden haben.

Die Sache ist die, daß es bis zu einem gewissen Grad nicht darauf ankommt, was objektiv am besten ist, sondern vor allem darauf, was für eine Organisation zu einem bestimmten Zeitpunkt subjektiv am besten ist. Veränderungen haben einen realen Preis, wenn sie das bestehende Bewusstsein brechen, deshalb muss eine neue Methode wirklich besser sein in Wegen, auf die es ankommt und nicht nur _ein bisschen besser in der Theorie oder ein bisschen mehr auf zeitgenössische Trends und Denkweisen ausgerichtet sein.

Wenn Sie sich für etwas “freiwillig” engagieren wollen ohne dazu aufgefordert zu werden, werden Sie wahrscheinlich besser angenommen, wenn es darum geht, wirklich herausragende Fehler zu beheben, die sich auf die Benutzer auswirken, als wenn Sie Dinge, die bereits funktioniert haben, mutig neu schreiben. Wenn Sie ein ungelöstes Problem verstehen, versuchen Sie, mit einer erstklassigen Commit-Nachricht eine möglichst kleine und minimale Änderung vorzunehmen. Machen Sie deutlich, warum diese eine Änderung der richtige Weg ist, das Problem zu lösen, und machen Sie daraus eine Änderung, die sich nahtlos in den aktuellen Stil und die Methodik des Codes einfügt. Geben Sie ihnen eine Pull-Anfrage, die leicht zu genehmigen ist und keine komplexen Gefühle von Kompromissen hervorruft.

Wenn Sie wirklich glauben, dass ein Abschnitt neu geschrieben werden muss, heben Sie sich diesen Gedanken auf, bis Sie aufgefordert werden, einen Beitrag zu leisten, und sich der Prioritäten, der Geschichte und der Art der Codebasis insgesamt bewusst sind. Und seien Sie darauf vorbereitet, zu verstehen, warum die Änderung, die Sie vornehmen wollen, nicht mit ihren Prioritäten und ihrem Plan übereinstimmt. Je mehr Sie zeigen können, dass Sie den aktuellen Kodex verstehen, indem Sie Korrekturen vornehmen, die sich nahtlos in seine Traditionen einfügen, desto wahrscheinlicher ist es, dass Sie das Vertrauen gewinnen, die Dinge in eine neue Richtung zu lenken. Man kann auch beiläufig drastische Änderungen in einer informelleren Art und Weise vornehmen - “hey, ich dachte, wir könnten diesen Teil viel besser machen, wenn wir ihn so umschreiben würden, dass er mit Spindelklappung funktioniert” - und die Reaktion vor der eigentlichen Durchführung messen.

Wenn ich von der anderen Seite des Schreibtisches spreche - auf persönlicher Ebene bin ich ziemlich glücklich, wenn ein Bewerber sogar Github Repos oder eine andere Art von Portfolio hat und einige Hintergrundrecherchen über die Tätigkeit des Unternehmens durchgeführt hat. Das sind etwa 3-5% aller Bewerber.

Ein Bewerber, der potentiell beide von diesen sehr direkt demonstriert, indem er unseren Code korrigiert/verbessert? Sie haben wahrscheinlich eine großartige Einstellung verpasst, und Sie haben es sicherlich vermieden, sich einer schrecklichen Kultur anzuschließen.

Sie haben nichts falsch gemacht. Wenn eine Pull-Anforderung, die eine Funktion des Codes refaktorisiert, ihr Boot ins Wanken brachte, lässt das nicht viel Raum für komplexere Interaktionen.

Die Rolle des Projektbetreuers (oder Reviewer) besteht darin, jegliche Politik (wahrgenommene Arroganz, Inkompetenz) vom Code selbst zu entflechten und den Code objektiv zu überprüfen. Wenn ein Reviewer eine Pull-Anfrage erhält und sich nur auf die Politik konzentriert (“Wie können Sie es wagen, diese PR zu erheben?”) und den Code nicht einmal überprüft, ist er in seiner Rolle sehr ineffektiv.

Um ehrlich zu sein, es klingt nicht so, als ob sie jemanden Ihres Kalibers suchen, seien Sie froh, dass Sie bald in einer besseren Firma arbeiten werden.

Wie @Kyralessa sagte, war es vielleicht Ihr Kommentar und nicht Ihr PR Was haben Sie als Kommentar zu Ihrer Pull-Anfrage eingegeben? Das ist das fehlende Kernstück hier. Möglicherweise haben Sie in Ihrem Kommentar unbeabsichtigt mitgeteilt, dass die ursprünglichen Entwickler Idioten waren und dass Sie ihnen weit überlegen waren. Das Schlüsselwort hier ist “unbeabsichtigt”. Als Entwickler ist das sehr einfach zu tun. Ich sage nicht, dass Sie das getan haben, aber es ist durchaus möglich.

… Oder sie haben Angst davor, sich mit einem Neuling mit Initiative auseinanderzusetzen Eine andere Möglichkeit, wie andere erwähnt haben, ist, dass sie ihren Code übermäßig schützen, und vielleicht wollen sie sich nicht mit der Betreuung eines Neulings mit College-Abschluss und Initiative befassen, der (wie alle anderen im selben Boot) signifikante Betreuung und Aufsicht braucht, um sicherzustellen, dass er keine großen Fehler macht (ich spreche aus Erfahrung, da ich vor Jahren einer von ihnen war).

…Oder sie wissen nicht, wie man ein Vorstellungsgespräch führt Sie wissen vielleicht einfach nicht, wie man ein Vorstellungsgespräch für die Art von Kandidaten führt, die sie wollen, und haben ihren Teil des Vorstellungsgesprächs verpfuscht.

In den meisten Unternehmen würde Ihr Handeln auch dann positiv gesehen werden, wenn es am Ende einen guten technischen Grund gäbe, Ihren Pull-Antrag abzulehnen:

• Es zeigt insbesondere Ihr echtes Interesse an dieser Position
• Es ist ein Beweis dafür, dass Sie praktische Erfahrung mit der Codierung haben
• Es war eine Gelegenheit, während des Interviews über echten Code zu sprechen, anstatt erfundene Codierungsübungen zu machen

Das heißt, es sei denn, der Code, den Sie geschrieben haben, war völliger Unsinn, der sie davon überzeugt hat, dass Sie nicht die Erfahrung haben, die sie bei den ersten Interviews angenommen haben, oder Sie haben es irgendwie geschafft, sie in dem Kommentar zu beleidigen.

Er sagte, dass es so rüberkam, als ob ich als frischgebackener Hochschulabsolvent mehr wüsste als sie, und dass ich nicht darüber nachgedacht habe, warum sie es so kodiert haben, wie es war. Am Ende habe ich die Stelle nicht bekommen.

Schätzen Sie sich glücklich, dass Sie die Stelle nicht bekommen haben , denn die Behandlung, die Sie für diese Pull-Anfrage bekommen haben, ist wahrscheinlich ein Vorgeschmack auf die Behandlung, die Sie bekommen hätten, wenn Sie in dieser Firma gearbeitet und diese (oder jede andere) Änderung vorgeschlagen hätten.

Um es ganz klar zu sagen: Ja, ich halte es für sehr wahrscheinlich, dass Ihre PR nicht gut zu ihnen gepasst hat und dass sie wirklich gute Gründe haben, ihren Code so zu haben, wie sie ihn haben, anstatt so, wie Sie ihn vorgeschlagen haben. Mit anderen Worten, ich glaube sehr wohl, dass *Ihr Code wahrscheinlich einfacher, aber schlechter war. *

Allerdings , es sei denn, Sie haben einen unhöflichen Kommentar in die PR aufgenommen, die Annahme des Seniors, dass ein einfacher Vorschlag “unangebracht” sei, dass es eine arrogante Art und Weise sei zu sagen “Ich weiß mehr als Sie”, und dass ein Kandidat mit College-Ausbildung nicht tatsächlich so viel wie sie oder mehr wissen kann, eine dreifache rote Flagge ist, weil:

• Es erweckt den Verdacht, dass, wenn Sie dort arbeiten würden, selbst Ihre guten Ideen *ganz mit der Begründung, dass Sie ein Junior sind, *abgelehnt würden, nur **so dass die Senioren ihre eigene Rolle und ihren Gehaltsscheck rechtfertigen können.
• Es zeigt, dass sie einige ernsthafte Unsicherheiten in Bezug auf ihre eigene Fachkenntnis haben - und ich wäre geneigt zu denken, dass diese Unsicherheiten gerechtfertigt sein könnten.
• Wenn diesem Senior zufällig eine formale Ausbildung in Software fehlt, gibt es einen zusätzlichen Anreiz für sie, zu versuchen, die Bedeutung eines Abschlusses und die Fachkenntnis, die man daraus gewinnt, herunterzuspielen, damit ihre eigenen Manager sie nicht schließlich durch ebenso erfahrene Entwickler ersetzen, die auch Zertifizierungen haben.

Nur um Ihnen eine Perspektive zu geben, habe ich einmal irgendwo ein Interview geführt und dabei den Senioren einen etwas radikalen Vorschlag über ein System gemacht, das sie im Begriff waren zu bauen. Sie haben es nicht nur begrüßt und in Betracht gezogen, sondern mir kurz darauf auch ein Angebot gemacht.

Solche Umgebungen bestehen - nicht alle Unternehmen setzen ein Einweg-Lehr-/Schülermodell ein, bei dem das Wissen strikt von den Senioren zu den Junioren fließt. (Und denken Sie daran, wenn Sie Ihren Abschluss gemacht haben, dann sind Sie kein “Student”, und viele Senioren in dieser Branche sind auch nicht wirklich “Ingenieure”, unabhängig davon, wie ein Unternehmen sich entscheidet, sie zu nennen).

Das Problem ist, dass Ihre “Verbesserung” naiv und künstlich war, und ich weiß das, weil Sie sie so viel kürzer machen konnten.

Das passiert mir immer wieder. Ich baue ein komplexes System auf, damit die Daten vielen Benutzern dienen können. Und dann kommt jemand vorbei und sagt: “Wir brauchen dieses ganze Zeug nicht! Sie machen ein einfaches Problem viel zu komplex.” Und sie hacken und schrägstrich und reduzieren es auf ein einfaches System, das ihnen gut dient, und sie geben sich selbst einen goldenen Stern.

Ausser sie sind nicht der einzige Benutzer. Und die Modifikationen haben es für alle anderen Benutzer dieser Daten einfach kaputt gemacht. Dann muss es also eine Sache geben… Treffen, Umerziehung, Bitterkeit, Rollbacks, all das war unnötig.

Die Kodierung ist der einfache Teil. Der schwierige Teil ist das Verstehen und Ausdrücken des Problems. Sie haben den schwierigen Teil kurzgeschlossen, um den einfachen Teil zu erleichtern.

Wenn man Ihnen beigebracht hat, dass Kodieren König ist, nun, nicht wirklich. Auf der anderen Seite geht es darum, wo das Geld ist: in der Lage zu sein, eine Spezifikation zu schreiben, die kodierbar ist und alle Benutzer/Bedürfnisse behandelt. (am anderen Ende der Skala ist es auch möglich, Lösungen zu entwerfen, die alle singen/tanzen, aber nicht beschreibbar sind, deshalb muss man die Kodierung kennen, um zu entwerfen).

Das war der Kern davon. Sie haben das Problem, das der Code zu lösen versuchte, nicht ganz verstanden.

Und das haben Sie ihnen auf spektakuläre Weise vorgeführt.

Beim Spielen ist ein “Neuling” ein bloßer Anfänger. Ein “Neuling” ist ein Neuling, dessen Arroganz ihn daran hindert, zu lernen oder die Erfahrung anderer oder der Älteren im Allgemeinen zu respektieren. Es scheint, dass Letzteres eher auf Sie zutrifft, weil Sie so leicht in der Lage waren, diesen Code so viel kürzer zu machen, und es kam Ihnen nicht in den Sinn, dass dies zu einfach war, es musste einen Grund dafür geben, dass sie ihn so komplex geschrieben hatten.

und dass ich nicht darüber nachgedacht habe, warum sie es so kodiert haben, wie es war.

Ja, das stimmt. In einigen Fällen wird Code geschrieben, um eine bestimmte Geschäftsfunktion oder -regel zu unterstützen, die die Programmierer nicht kontrollieren können.

Ich habe mir das eine Weile angesehen und einen viel einfacheren und zukunftssicheren Weg gefunden, eine Funktion zu schreiben, und ich habe eine PR mit der Änderung eröffnet, ohne zu erwähnen, dass ich gerade ein Interview führe.

Als junger Mensch halten wir uns gerne für clever. Dass wir alles durchschaut haben. Die Wahrheit ist, dass, wenn Sie daran gedacht haben, es auch jemand anderes getan haben könnte, da Sie offensichtlich einen besseren Weg “gefunden” haben, indem Sie gegoogelt haben, was andere Leute getan haben. Wann immer Sie an etwas so offensichtlich Offensichtliches denken, sollten Sie innehalten und zuerst danach fragen, um sich zu vergewissern, was auf die aktuelle Art und Weise erreicht wird. Bill Gates hat seine Art und Weise, Windows zu bauen, nicht gegoogelt, sondern er hat daran gedacht und es implementiert. Wenn Sie nicht in der Lage sind, das Gleiche zu tun, haben Sie keinen “besseren Weg” gefunden. Man googelt einfach besser als die letzte Person.

War es wirklich unangebracht für mich, das zu tun?

Als PR für ihren Meister, ja, es war etwas unangebracht. Vielleicht ein eigener Zweig, den Sie beim Vorstellungsgespräch teilen können. “Ich habe gesehen, wie Sie X gemacht haben, und bei der Recherche habe ich Y gefunden, das für die Zukunft beweisbar ist und leichter modifiziert werden kann. Ich weiß, dass Sie es aus einem bestimmten Grund geschrieben haben, aber ich war neugierig darauf, ein Konzept zu demonstrieren, das auf Ihrem Code basiert.” Ich weiß, dass Sie in Git @-Symbole verwenden und sogar eine Diskussionskette eröffnen können. Vielleicht wäre es das nächste Mal am besten, den Abschnitt, den Sie modifiziert haben, mit a zu kommentieren,

@user Mir ist aufgefallen, dass Sie hier ein X machen, aber ich habe ein Y eingefügt. Ich wollte meine Fähigkeit zeigen, Ihren Code zu lesen und Modifikationen vorzunehmen,etc

Indem ich ihrem Meister einen PR mache, ist es im Wesentlichen dasselbe wie die Geschichte des Mannes, der Klempner werden wollte, keinen Job finden konnte und deshalb beschloss, ein Gasleck in seiner Nachbarschaft zu “reparieren”. Sie können sich das Endergebnis vorstellen, das dabei herauskam.

Um zu anderen Antworten hinzuzufügen:

sind Sie sicher, dass Ihr Code in dieser speziellen Codebasis tatsächlich korrekt und nützlich war?

You fix mag viel einfacher und robuster erscheinen; es kann jedoch leicht sein, dass der alte Code absichtlich so geschrieben wurde, wie er geschrieben wurde.

Wahrscheinlich hat Ihre Pull-Anforderung einige Aspekte des Verhaltens geändert (vielleicht denken Sie sogar, dass Sie einen Fehler behoben haben), aber es gibt entfernten Code, der sich auf diesen Fehler verließ.

Wahrscheinlich haben Sie nicht berücksichtigt, dass der Code auf diese Weise verwendet wurde, und deshalb ist Ihr Code in dieser speziellen Situation schlechter. Zum Beispiel könnte Ihr Code nicht in einer Multithreading-Umgebung funktionieren, oder die Daten, mit denen der Code zu tun hat, könnten einige nicht offensichtliche Eigenschaften haben, die den alten Code besser und schneller funktionieren lassen.

Soweit wir wissen, haben Sie vielleicht einen dummen Grund übersehen (einen Fehler in Ihrem Code oder die Tatsache, dass Ihr Code langsamer läuft, usw.), der für einen erfahrenen Entwickler offensichtlich sein sollte.

Sie haben vielleicht noch etwas anderes übersehen. Immerhin arbeiten sie schon seit langer Zeit mit diesem Code und sollten wahrscheinlich viel besser wissen, wie er funktioniert. Die Tatsache, dass sie sagten, “dass [Sie] nicht darüber nachgedacht haben, warum sie ihn so kodiert haben, wie er war”, legt dies nahe.

Abgesehen davon stimme ich mit anderen Leuten überein, die sagen, dass das Öffnen eines PR nichts Schlechtes ist. Wie bei jeder neuen Codebasis ist es jedoch oft besser, sie mit den Maintainern zu diskutieren. Wenn man bedenkt, dass Sie sich zu diesem Zeitpunkt im Prozess der Interviews befanden, hätten Sie diese Frage einfach im Interview stellen können.

Es ist schwer zu erkennen, wie es immanent unangebracht sein kann, eine PR für ein Open-Source-Projekt zu schreiben.

Daher muss es auf die Einzelheiten ankommen, von denen wir nur sehr wenig wissen. War es naiv oder arrogant im Code oder in der Einstellung? War es hilfreich und freundlich? Ohne mehr zu wissen, ist es schwer, die Angemessenheit zu beurteilen.

Die Neugier hat mich überwältigt. Ich habe Ihre PR gefunden. Und sie hat mich so beeindruckt, dass ich beschloss, sie hier zu teilen. Es war keine leichte Entscheidung, weil ich die Vertraulichkeit weder von Ihnen noch von der Firma preisgeben möchte, aber ich hatte das Gefühl, dass sie auf akzeptable Weise substanzielle Zusammenhänge in die Diskussion einbringen würde. Das Fehlen konkreter Details hat sicherlich zu vielen unbegründeten Spekulationen geführt

Ich habe die PR vollständig anonymisiert und verschleiert, indem ich alle benutzerdefinierten Variablen, Zeichenfolgen, Methoden und Kommentare geändert habe. Hier ist er in seiner Gesamtheit:

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

Der Code initialisiert target zu einer hartkodierten zufälligen Zeichenfolge. (Beachten Sie, dass ich nur die Zeichen der Zeichenkette gemischt habe, um diesen Teil zu verschleiern). Wenn kein Argument angegeben wird, wird some_lookup(target) keine Übereinstimmung produzieren, weil es vermutlich nicht in der Lage ist, die absichtlich verrückte Standardzeichenfolge nachzuschlagen.

Dies ist eindeutig beabsichtigt. Aber es ist auch objektiv schlechte Kodierung.

Ihre Korrektur scheint eine Verbesserung zu sein. Ich selbst würde dies ohne zu zögern in einem Code-Review erwähnen. Und ich könnte mir leicht vorstellen, dass ich genau dieselbe 25 Wörter lange, freundliche, nicht konfrontative Commit-Nachricht schreibe, die Sie geschrieben haben.

Daher erscheint mir diese spezielle PR nicht unangemessen. Und vorausgesetzt, es wird auf professionelle, respektvolle Weise und in gutem Glauben gemacht, ** wäre eine PR niemals unangemessen**, auch nicht bei einem Interview.