Frage:
War es wirklich unangemessen, eine Pull-Anfrage für das Unternehmen zu schreiben, mit dem ich gesprochen habe?
user90809
2019-03-06 09:51:24 UTC
view on stackexchange narkive permalink

Das ist mir letztes Jahr passiert, als ich mit einem Unternehmen ein Interview für eine Stelle geführt habe, die ich nicht bekommen habe. Ich bin derzeit anderswo beschäftigt, würde es aber gerne für zukünftige Bewerbungen wissen.

Ich hatte laut ihnen ein ausgezeichnetes Telefon-Screening - sie sagten, ich sei ein starker Kandidat und das erste technische Interview mit einem Ingenieur ging sehr gut. Zwischen diesem zweiten Interview und dem letzten Interview stellte ich fest, dass ihre Software eine Open-Source-API auf GitHub hatte, die in Python geschrieben war. Ich habe es mir 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ührte.

Als wir meine dritte starteten Im Interview mit zwei Ingenieuren erwähnte einer von ihnen, dass er meine Pull-Anfrage gesehen habe und es für mich unangemessen war, sie zu öffnen. Er sagte, dass es so rüberkam, als wüsste ich mehr als sie als frischgebackener College-Absolvent, und ich habe nicht darüber nachgedacht, warum sie es so codiert haben, wie es war. Ich habe den Job nicht bekommen.

War es für mich wirklich unangemessen, dies zu tun?

Was genau sagten Ihre Kommentare zusammen mit der Pull-Anfrage?Sie haben möglicherweise nicht die Pull-Anfrage selbst oder den darin enthaltenen Code verletzt, sondern das, was Sie darüber gesagt haben.
Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/90833/discussion-on-question-by-pasclerasc-was-it-really-inappropriate-to-write-a-pull).
Dreizehn antworten:
#1
+435
Charles E. Grant
2019-03-06 10:11:31 UTC
view on stackexchange narkive permalink

Natürlich 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 die Leute dafür zu verachten, dass sie die Chuzpe haben, um Pull-Anfragen einzureichen. Zu einer Pull-Anfrage "Nein" zu sagen, ist kaum eine Belastung. Heck, sie hätten es einfach ignorieren können.

Wenn ich der Interviewer gewesen wäre, hätte ich Ihnen Bonuspunkte gegeben, um echtes Interesse an dem Unternehmen zu zeigen und zu zeigen, dass Sie wissen, wie man mit Open Source arbeitet Projekt in einem öffentlichen Repository. Dies wäre auch dann der Fall, wenn der übermittelte Code in Bezug auf das zu lösende Problem naiv wäre.

Da ein Stellenangebot in der Leitung steht, sollten Sie sicher sein, dass der von Ihnen übermittelte Code von hoher Qualität ist (lassen Sie jemanden dazu schau es dir an) und halte alle Kommentare im Code oder in der Pull-Anfrage bescheiden und höflich.

Denken Sie daran, wenn ein potenzieller Arbeitgeber Sie bewertet, sollten Sie auch diesen potenziellen Arbeitgeber bewerten.Sie haben es erfolgreich vermieden, mit einem vermeintlich erfahrenen Entwickler zusammenzuarbeiten, der nicht einmal weiß, wofür ein öffentliches Repository gedacht ist.
Ganz zu schweigen davon, dass ich ein solches Repository genau als "Extrapunkte" behandeln würde, in der Sie zeigen können, a) dass Sie an dem Unternehmen interessiert sind, b) dass Sie den Code lesen können, c) dass Sie ihn bewerten können, d) dass Sie ihn verbessern können.
"Halten Sie alle Kommentare im Code oder in der Pull-Anfrage bescheiden und höflich."Fügen Sie Professional hinzu, und dieser Satz ist eine gute Regel, nach der Sie immer arbeiten müssen.
@A.I.Breveleri - Die Tatsache, dass ein Repository öffentlich ist, bedeutet nicht, dass es dazu bestimmt ist, * unaufgeforderte * Beiträge zu akzeptieren.Viele Github-Repos, insbesondere von Unternehmen, werden effektiv nur veröffentlicht, andere sind praktische Spiegel von Projekten, bei denen der tatsächliche Entwicklungsfluss und die Übermittlung von Änderungen an anderer Stelle stattfinden - und da ** Github keine Funktion zum Deaktivieren von Pull-Anforderungen ** hat, ist dies möglichWenn Sie dort eine einreichen, bedeutet dies nichts über den Zweck des Repositorys oder die Richtlinien des Projekts.
@ChrisStratton, aber die gleiche Logik gilt auch für den Übermittler.Sofern in der README-Datei für das Projekt oder in einer Beitragsrichtlinie keine dringende Warnung fett gedruckt ist, ist das Senden einer Pull-Anfrage möglicherweise sinnlos, aber kaum unangemessen.
@CharlesE.Grant - Ein potenzieller Übermittler kann die Pull-Anforderung eines Projekts leicht überprüfen und den Autorenverlauf festschreiben.Während ein Interview eine gegenseitige Bewertung ist, obliegt es der * neuen * Partei, einige Anstrengungen zu unternehmen, um die * bestehende * Situation zu verstehen.Jemand, der impulsiv Änderungen herausgibt, ohne darüber nachzudenken, sich zuerst mit den offensichtlichen Normen der Dinge vertraut zu machen, die er ändern möchte, kann als potenziell nerviger Mitarbeiter auftreten, der viel Anleitung benötigt, anstatt als eine Person, die sich schnell einfügt und real löstProbleme auf eine Weise, die leicht aufgenommen werden kann.
@ChrisStratton Sicher, es ist sinnvoll, dass ein Unternehmen die Historie eines Bewerbers durchblättert und alle öffentlichen Pull-Anfragen - insbesondere zu einem unternehmenseigenen Projekt - als eine Möglichkeit zur Bewertung der Fähigkeiten des Bewerbers verwendet.Dies unterscheidet sich jedoch von der Aussage, dass beim Öffnen der Anfrage etwas nicht stimmt.
Wenn es nach einem schlechten Urteilsvermögen des Antragstellers aussieht, sieht es nach einem schlechten Urteilsvermögen aus ... * subjektiv * So sehr diese Einschätzung auch sein mag, niemand möchte mit jemandem zusammenarbeiten, der das, was er für ein schlechtes Urteilsvermögen hält, ausübt, indem er etwas unternimmt, ohne zu überlegen, obes ist nützlich, aber nur mit der Begründung, dass es keine technischen Mechanismen gibt, die sie daran hindern, es zu versuchen.
@A.I.Breveleri Zusätzlich zu den Aussagen von @ ChrisStratton kann der Gedanke, dass ein öffentliches Repo bedeutet, dass Sie eine Pull-Anfrage einreichen können, gefährlich sein.Die Lizenz erlaubt möglicherweise keine abgeleiteten Arbeiten (was im Wesentlichen eine Pull-Anfrage ist).Sogar das Klonen des Repos - was Sie für PRs tun müssen - kann als nicht lizenzierte Umverteilung angesehen werden (die Nutzungsbedingungen von Github erlauben dies ausdrücklich, ähnliche Dienste jedoch möglicherweise nicht).
Ich denke, wenn ich ein Interview führen würde, wäre eine PR ein nützliches Gesprächsthema.Als Interviewer können Sie den Befragten bitten, die Gründe für die PR zu erläutern und diese in Frage zu stellen, und dann sehen, wie der Befragte reagiert.Wenn diese Person in der Lage ist, ihre Argumentation zu kommunizieren und zu verstehen, wie sie möglicherweise etwas falsch gemacht hat, und verschiedene Ansätze zu diskutieren, ist dies ein gutes Zeichen.
@kapex Das ist eine Art Schuld des Repository-Besitzers, nicht wahr?Wenn das Klonen des Repos nicht erlaubt ist, sollte das Repo nicht auf öffentlichem Github sein.
@Wowfunhappy ja, für Github ist das wahr.Mein Punkt war mehr, dass andere Git-Hosting-Dienste dies möglicherweise nicht explizit zulassen.
@ChrisStratton Sie können ein Drittanbieter-Tool wie [No Pull Requests] (http://nopullrequests.com/) verwenden, um PRs automatisch abzulehnen und zu schließen.Oder machen Sie es einfach privat.Oder erstellen Sie zunächst private Repos.Wenn Sie die Eingabe eines anderen Entwicklers nicht schätzen, halten Sie sie privat.Könnte das Repo auch "schreibgeschützt" machen, aber das würde auch die eigenen Entwickler daran hindern, sich zu verpflichten.
#2
+276
Zach Lipton
2019-03-06 14:40:43 UTC
view on stackexchange narkive permalink

Der Teil, der mir hier die meiste Pause gibt, ist "eine viel einfachere und zukunftssichere Möglichkeit, eine Funktion zu schreiben". Ich habe Ihren Code nicht gesehen und habe kein Verständnis für den Kontext Ihrer Änderung, aber es hört sich nicht so an, als hätten Sie einen Fehler behoben, eine Funktion hinzugefügt, die Leistung verbessert oder auf andere Weise etwas getan, das die Projektbetreuer als sinnvoll erachteten. Ich kann sehen, dass das Einreichen einer Pull-Anfrage für eine unerwünschte Änderung dieser Art möglicherweise nicht den besten Eindruck hinterlassen hat.

Viele Open-Source-Projekte (und häufig auch Closed-Source-Entwicklungsprojekte) werden nicht wie Wikipedia-Artikel ausgeführt wo jeder ermutigt wird, ständig kleine Änderungen vorzunehmen. Mit jeder Änderung sind Kosten ungleich Null verbunden: die Zeit zum Überprüfen, Testen und Genehmigen, das Risiko, etwas zu beschädigen (selbst bei einer robusten Testsuite), etwas zu schaffen, das weniger Teammitglieder verstehen, usw. Infolgedessen sind viele Projekte nicht besonders groß, wenn es darum geht, Dinge zu ändern, nur weil; Es gibt unendlich viele Möglichkeiten, eine Funktion zu schreiben, und nichts würde getan werden, wenn jeder regelmäßig den vorhandenen Arbeitscode ändern würde, um seine persönliche Definition von "am besten" zu erfüllen. Wenn es an der Zeit ist, eine Umgestaltung vorzunehmen, ist es wahrscheinlicher, dass ein Projektbetreuer als ein erstmaliger Mitarbeiter beteiligt ist, und normalerweise ist eine Begründung beigefügt. Dies sind Normen, und wie alle Normen variieren sie und sind im Allgemeinen Dinge, die Sie durch Osmose lernen sollten, anstatt sie zu lehren. Wenn Sie vor kurzem Ihren Abschluss gemacht haben, ist es wahrscheinlich, dass dies zu diesem Zeitpunkt nicht besonders offensichtlich war.

Die meisten Pull-Anforderungen richten sich an einen offensichtlicheren Bedarf: Beheben eines Fehlers oder Hinzufügen einer Funktion. Und selbst in diesen Fällen ist es oft besser, die Aufgabe zuerst mit dem Betreuer zu besprechen, da dieser möglicherweise Kontext und Vorlieben hat, die Sie nicht kennen.

Ich halte es daher nicht für unangemessen, jemals während des Interviewprozesses eine Pull-Anfrage einzureichen (dies zeigt sicherlich Interesse und Begeisterung), aber aus ihrer Sicht haben sie Sie möglicherweise als jemanden gesehen, der wahrscheinlich den Arbeitscode neu schreibt ohne viel Rechtfertigung, und dann reagierten sie leider negativ und herablassend auf Sie. Was Ihnen hilfreich viel über sie erzählt und wie es gewesen wäre, mit ihnen zu arbeiten.

Kommentare sind nicht für eine ausführliche Diskussion gedacht.Diese Konversation wurde [in den Chat verschoben] (https://chat.stackexchange.com/rooms/90703/discussion-on-answer-by-zach-lipton-was-it-really-inappropriate-to-write-a-ziehen).
Ich stimme zu, aber der Teil "Er sagte, dass es so rüberkam, als wüsste ich mehr als sie als frischgebackener College-Absolvent" lässt mich denken, dass sie keinen so logischen Grund hatten, auf diese Weise zu reagieren.
Der entscheidende Punkt war, dass Sie vor dem Schreiben von Code viel Zeit damit verbringen sollten, herauszufinden, was Sie lösen.Nur eine Pull-Anfrage zu stellen und dann den Code zu ändern, ist bestenfalls eine nicht informierte Aktion.Ich bin nicht überrascht, wenn es als arrogant herauskam.Was ist, wenn die "kosmetischen" Änderungen die automatisierten Tests vollständig brachen?Wie würde das OP überhaupt die Details der Anforderungen kennen **, ohne mit ihnen zu sprechen **?
Stimmen Sie der Schlussfolgerung zu, aber als Betreuer von Open-Source-Projekten bin ich mit dem Rest Ihrer Antwort nicht einverstanden.Ich schätze jeden noch so kleinen Beitrag, solange er eine Verbesserung darstellt, gerechtfertigt ist und Verständnis für das gesamte Projekt zeigt.Selbst wenn dies nicht der Fall ist, kann ich mir keinen einzigen Grund vorstellen, negativ zu reagieren - selbst wenn der Code objektiv schlecht ist, danken Sie einfach dem Mitwirkenden und lassen ihn wissen, dass Sie seinen Code nicht zusammenführen werden.Eine negative Reaktion auf eine Person, die ihre Zeit verbracht und echte Anstrengungen unternommen hat, um Ihren Code zu verbessern, ist ein Zeichen für eine schlechte Unternehmenskultur.
@Egor +1: Es ist eine Pull * Anfrage *, mein Gott.Ein Angebot.(Und außerdem zeigt es Begeisterung und hoffentlich Geschicklichkeit. Ich würde nur dann negativ reagieren, wenn es nicht so wäre.)
@PeterA.Schneider, Pull-Anfrage sind kein Angebot, sie sind zusätzliche Arbeit - zum Überprüfen, Besprechen usw. + zusätzliche langfristige Wartungskosten für die Hauptentwickler.Manchmal lohnt sich diese zusätzliche Arbeit, um notwendige Änderungen vorzunehmen, aber es ist nie ein sofortiger Gewinn, und deshalb kann ihre Reaktion verständlich sein.Wie ein weiser Mann einmal sagte: "Wenn Ihnen jemand Code schenkt, ist dies meistens eine Verkleidungslast" - https://blogs.msdn.microsoft.com/oldnewthing/20080225-00/?p=23343/
@this.lau_ aber bei jedem Schritt können sie es ablehnen.Sie müssen es nicht einmal überprüfen, wenn es so viel Schmerz verursacht.
@user87779 Ich würde sogar sagen, dass sie Open Source nicht von Anfang an hätten beziehen sollen, wenn sie das Gefühl haben, Pull-Anfragen anzunehmen, ist eine Belastung.
"Kosten, die mit jeder Änderung einhergehen: ... das Risiko, etwas zu beschädigen (selbst mit einer robusten Testsuite)" - IMO, das kann der beste Grund sein, warum kleine Commits von irgendjemandem in Betracht gezogen werden sollten: wenn sie etwas kaputt machenDas heißt, die Testsuite ist noch nicht gut genug.
@leftaroundabout die Frage ist, was ist der Preis, den Sie bereit sind zu zahlen, um herauszufinden, ob es etwas kaputt macht oder nicht?Eine unvollständige Testsuite ist nicht gut, aber viele erfolgreiche Projekte sind erfolgreich, weil sie Arbeitscode liefern, nicht weil sie eine 100% vollständige Testsuite haben (ich meine, nur sehr wenige von ihnen haben letztere).
Dies ist eine großartige Antwort.Ich sollte hinzufügen, dass Sie wahrscheinlich in einer Kultur interviewt haben, in der Sie "ohne Dienstalter nichts sind und nichts wissen". Diese schränken den beruflichen Fortschritt in der Regel stark ein, da der einzige Weg zum Fortschritt darin besteht, die vielen Jahre in den unteren Sprossen zu arbeiten.Versuchen Sie, ein Gleichgewicht zwischen Meritokratie und Senioritätskulturen zu finden. Sie sind in der Regel am besten.
@Egor Vielleicht habe ich etwas gemacht, das meinen Bedürfnissen (und / oder denen meines Kunden) entspricht, und es mit dem Rest der Welt geteilt, in der Hoffnung, dass es jemand anderem von Nutzen ist.Jetzt bin ich damit fertig;Ich muss zum nächsten Schritt übergehen.Die Tatsache, dass ich mich entschlossen habe, es zu teilen, berechtigt niemanden zu kostenlosem Support und / oder Updates ad infinitum.Aber hey - es ist Open Source. Sie können es also jederzeit ändern, eine Community bilden und alles tun.Froh, dass ich helfen konnte.
@AC Machen Sie in der README.md Ihres Projekts deutlich, dass Sie keine Pull-Anforderungen akzeptieren und keine Fehlerkorrekturen bereitstellen oder Funktionsanforderungen implementieren.Stellen Sie sicher, dass die von Ihnen ausgewählte Lizenz es den Nutzern erleichtert, Ihr Projekt zu teilen, zu ändern und zu verteilen.Es ist in Ordnung, Quellcode zu öffnen, an dessen Pflege Sie nicht interessiert sind. Sie müssen lediglich die Erwartungen richtig einstellen.
@Egor (über "A C" - letzte Antwort) -> noch besser: Archivieren, "schreibgeschützt" machen, beim Surfen ein gelbes Banner oben im Repository anzeigen.Kann für Leute, die danach suchen, nicht klarer sein.Aber ich bin mehr für Ihren früheren Kommentar: Wenn Sie keine Hilfe für Open-Source-Code schätzen, machen Sie ihn privat.Nicht wie von "A C" vorgeschlagen, um etwas zu teilen, das nicht von der Welt unterstützt wird: Wir haben alle gesehen, was passiert, wenn Sie jedes kleine Ding teilen: Sie erhalten einen JS-Stapel von "Code" -Modulen in Ihren Projekten, die keinen Sinn ergeben.* Husten * Pad-links * Husten *
@rkeet Das Problem mit dem JS-Ökosystem war nicht, dass es viele kleine Pakete gibt.Das Problem mit dem JS-Ökosystem war (oder ist es immer noch nicht, ob sie es behoben haben), dass sie Paketverwaltern erlaubten, Beiträge zu widerrufen.Für einen Pakethostingdienst sollten nur Mitwirkende erforderlich sein, um dem Repository eine unwiderrufliche Lizenz zum Hosten des Pakets zu erteilen.
@this.lau_ Wenn Sie sich nicht mit Pull-Anfragen befassen möchten, sollte Ihr Projekt zunächst nicht auf Git geöffnet sein.Der Umgang mit Pull-Anfragen - entweder gut oder schlecht - ist Teil des Spiels, wenn Sie Ihren Code so einrichten.
Wenn der Produktmanager die Verbesserung der Codequalität nicht für nützlich hält, ist es besser, wenn OP dort nicht funktioniert.Klingt für mich so, als würde OP das Ego der Leute nur verletzen, indem er schöneren Code schreibt.
#3
+104
Jack Aidley
2019-03-06 17:55:28 UTC
view on stackexchange narkive permalink

Sie haben das Feedback, das Sie erhalten haben, falsch verstanden und sich auf den falschen Teil konzentriert.

Er sagte, dass es so aussah, als wüsste ich mehr als sie als neues College grad, und dass ich nicht darüber nachgedacht habe, warum sie es so codiert haben, wie es war.

Das Problem ist nicht, dass Sie eine Pull-Anfrage gestellt haben, sondern dass Sie es für etwas getan haben, das Sie selbst gemacht haben erscheinen arrogant, unwissend und sich Ihrer eigenen Grenzen nicht bewusst. Sie beschreiben Ihre Änderung als "viel einfacher und zukunftssicherer". Aus dem oben zitierten Abschnitt geht hervor, dass sie nicht übereinstimmen. Da sie erfahrener sind als Sie und mit ihrer eigenen Codebasis vertraut sind, ist es sehr wahrscheinlich, dass sie korrekt sind und Sie sich irren.

Es ist üblich, dass Absolventen aus ihren Abschlüssen hervorgehen, die stark überschätzt werden ihre eigene Kompetenz. Sie waren nicht verärgert, weil Sie eine Pull-Anfrage gestellt haben, sondern weil Sie anscheinend ein Unverständnis für Ihre eigenen Grenzen und einen Mangel an Respekt für ihre Fähigkeiten in der von Ihnen eingereichten Einreichung gezeigt haben. Wahrscheinlich haben Sie diesen Eindruck während des Interviews verstärkt.

Lesen Sie schließlich nicht zu viel in einen bestimmten Teil eines bestimmten Interviews: Es kann sein, dass dies nichts damit zu tun hat, dass Sie den Job nicht bekommen und sie hatte gerade einen besseren Kandidaten. Du weißt es nicht. Machen Sie sich keine Gedanken über diesen Rückschlag und konzentrieren Sie sich stattdessen auf die nächste Anwendung. Viel Glück bei Ihrer Jobsuche!

Ich stimme zu, dass das Problem wahrscheinlich weniger die Pull-Anfrage an sich ist als vielmehr die wahrgenommene Qualität.Die Wahrnehmung des Unternehmens ist möglicherweise falsch. In diesem Fall möchte das OP dort sowieso nicht arbeiten.ot es kann richtig sein, in welchem Fall sie nicht wollen würden, dass das OP dort sowieso funktioniert.
Ihr Kommentar wäre sinnvoll, wenn es sich um ein ** privates ** Repo handeln würde
@RobertoTorres Jack diskutiert nicht über die PR selbst, sondern darüber, wie sie präsentiert wurde: indem er Jacks Antwort zitiert "etwas, das Sie arrogant, ignorant und ohne Kenntnis Ihrer eigenen Einschränkungen erscheinen ließ", im Grunde jemand, der möglicherweise giftig ist und den sie im Team nicht wollen.
@Lesto, weil sie einen Junior finden, der keine Ressourcen verbraucht und der keine Erklärungen benötigt.
Obwohl ich dem Gefühl zustimme, nicht zu viel in ein bestimmtes Interview zu lesen, sehe ich immer noch die roten Fahnen bei der Firma.Wie @Steve bereits sarkastisch schrieb: Als frischgebackener Student muss er sowieso die Kultur dieses Unternehmens lernen, er wird zunächst ein Abfluss sein, er wird sich selbst überschätzen.Bei der Einstellung muss etwas schief gelaufen sein, wenn sie neue Absolventen einladen, aber erwarten, dass sie sich wie erfahrene Programmierer verhalten.Mismatch HR: Ingenieure.
Dies setzt viel über Informationen voraus, die wir nicht haben.Das ist alles sehr gut möglich, aber es gibt keinen Grund, dies vorauszusetzen.Es ist genauso wahrscheinlich, IMO, dass jemandes Ego wegen nichts verletzt wurde.Wenn sie sich um die Berücksichtigung anderer Faktoren durch OP kümmerten, konnten sie diese einfach erklären.
@Leonidas persönlich Ich bevorzuge einen Entwickler mittlerer Qualität, der sich gut in das Team einfügt, als einen erstklassigen, aber "schwierigen" Entwickler.Der moralische Schlag im Unternehmen könnte die Produktivität weitaus mehr zerstören als das, was dieser Entwickler einbringt. Natürlich haben wir nicht genug Informationen, um dies zu sagen (oder umgekehrt!), Aber dies ist eine realistische Möglichkeit zur Ablehnung und es lohnt sich, darüber zu diskutieren. Es liegt an OP, zu entscheiden, das Detail mit jemandem zu teilen, der unparteiisch ist, um dies zu klären.
Ja, dies gilt für alle neuen Absolventen. Ich habe einen PHD-Submit-Code gesehen, der versucht, eine Methode zu verwenden, die das Problem nicht gelöst hat, und Syntaxfehler enthält, die bedeuten, dass er nicht einmal kompiliert werden würde.
@Leonidas: Wenn die Darstellung der Geschichte durch das OP absolut korrekt und unparteiisch ist, dann hat es einige rote Fahnen über das Unternehmen.Aber wir hören nur eine Seite der Geschichte.Es könnte durchaus sein, dass sich die Kritik des Unternehmens wirklich auf die Content-Pull-Anfrage konzentrierte und OP sie etwas persönlicher als angegeben nahm und sie so beschrieb, dass sie dies widerspiegelte.Wir wissen nicht genug, um zu sagen, auf welcher Seite sich die roten Fahnen befinden.Der einzige Rat, den wir OP geben können, ist, das Feedback erneut zu lesen, sich ihrer eigenen Vorurteile bewusst zu sein und zu versuchen, herauszufinden, wie viel davon wirklich inhaltsbasiert war.
Wenn ein Unternehmen keinen externen Beitrag wertschätzt, sollte es: a) keine Inhalte veröffentlichen, b) auf privaten Servern hosten.Zum anderen "Sie haben es für etwas getan, das Sie arrogant, ignorant und sich Ihrer eigenen Grenzen nicht bewusst gemacht hat" - macht das Ihrer Meinung nach wirklich einen Beitrag zum Open Source Code?Das wäre eine seltsame Meinung.Ein neuer Absolvent mag Einschränkungen haben, aber die Bereitschaft zur Teilnahme sollte niemals als das angesehen werden, was Sie sagen, es sei denn, Sie kennen die Person tatsächlich.
@rkeet: Sie könnten buchstäblich nur den Rest des Satzes lesen, den Sie zitiert haben, um meine Antwort zu erhaltensich Ihrer eigenen Grenzen nicht bewusst. "
@PascLeRasc: Ja, ich weiß.Ich schlage Ihnen vor, dass dies eine schlechte Idee ist.Sie können keine aussagekräftigen Lehren aus einer einzigen Erfahrung ziehen, bei der Sie nur äußerst eingeschränkten Zugriff auf die Gründe für die getroffene Entscheidung haben.
Ich finde es lustig, dass ich hierher gekommen bin, um zu kommentieren, dass der beste Rat, der hier gegeben wird, der letzte Absatz ist, und PascLeRasc hat einen versteckten Kommentar, der besagt, dass es der schlechteste war.Als jemand in der Branche seit 20 Jahren ist es ein sehr guter Rat.Ich bin jetzt seit 7 Jahren Teil des Interviewprozesses und kann Ihnen sagen, dass "Lernen, loszulassen" ein fantastischer Rat ist.Ratschläge, die für Leistungsträger wie Sie wirklich schwer zu fassen sind.
Was mir am meisten auffällt, ist, dass ein frischer Absolvent, der denkt, er sei zukunftssicher, etwas fast per Definition absurd ist.Erfahrene Menschen, die tatsächlich schon einige Umdrehungen der „Zukunft“ durchgemacht haben, haben wahrscheinlich eine realistischere Sicht auf die Zukunft, zumindest im technischen Bereich.
#4
+59
Chris Stratton
2019-03-06 10:09:52 UTC
view on stackexchange narkive permalink

"Unangemessen" ist möglicherweise nicht das beste Wort, aber "nicht strategisch" ist wahrscheinlich zutreffend.

Als etwas, das sich wie ein vielleicht noch relativ neuer Arbeiter in einem technischen Bereich anhört, ist eines der ersten Dinge Sie müssen lernen, dass die Entscheidung darüber, wie etwas zu tun ist, und wenn es sich lohnt, es zu ändern, keine einfache Angelegenheit ist. Angesichts der Tatsache, dass Sie den Anstoß haben, etwas zu ändern, das bereits funktioniert hat, ohne dass Sie dazu aufgefordert werden, werden Sie wahrscheinlich häufig beschuldigt, "das Neue und Glänzende anzubeten", ohne die Kosten der Änderung , komplexe Gründe, warum etwas so gemacht wurde, wie es war , oder der volle Umfang neuer Probleme, die Ihre Idee einführen würde .

Oder vielleicht Es sind nur kleine Leute, die dich nervig fanden.

Die Sache ist bis zu einem gewissen Grad egal, was objektiv am besten ist, es ist meistens wichtig, was ist subjektiv am besten für eine Organisation zu einem bestimmten Zeitpunkt. Veränderungen verursachen echte Kosten, wenn das bestehende Bewusstsein gebrochen wird. Daher muss eine neue Methode in wesentlich wichtiger Weise wesentlich und nicht nur theoretisch ein wenig besser oder ein wenig besser ausgerichtet sein zu aktuellen Trends und zum Denken.

Wenn Sie sich freiwillig für etwas melden möchten, ohne dazu aufgefordert zu werden , erhalten Sie wahrscheinlich einen besseren Empfang für die Behebung wirklich herausragender Fehler, die sich auf Benutzer auswirken. als in kühnen Umschreibungen von Dingen, die bereits funktionierten. Wenn Sie ein ungelöstes Problem verstehen, prüfen Sie, ob Sie mit einer erstklassigen Festschreibungsnachricht eine möglichst kleine und minimale Änderung vornehmen können. Machen Sie deutlich, warum diese eine Änderung der richtige Weg ist, um das Problem zu lösen, und machen Sie sie so, dass sie sich nahtlos in den aktuellen Stil und die Methodik des Codes einfügt. Geben Sie ihnen eine Pull-Anfrage, die einfach zu genehmigen ist und keine komplexen Gefühle von Kompromissen hervorruft.

Wenn Sie wirklich der Meinung sind, dass ein Abschnitt neu geschrieben werden muss, speichern Sie diesen Gedanken, bis Sie aufgefordert werden, einen Beitrag zu leisten, und sich der Prioritäten, des Verlaufs und der Art der Codebasis insgesamt bewusst sind. Und seien Sie bereit zu verstehen, warum die Änderung, die Sie vornehmen möchten, nicht mit ihren Prioritäten und ihrem Plan übereinstimmt. Etwas kontraintuitiver: Je mehr Sie das Verständnis des aktuellen Codes demonstrieren können, indem Sie Korrekturen vornehmen, die nahtlos zu seinen Traditionen passen, desto wahrscheinlicher wird es, dass Sie Vertrauen gewinnen, um Dinge in neue Richtungen zu lenken. Sie können drastische Änderungen auch auf informellere Weise beiläufig schweben lassen - "Hey, ich dachte, wir könnten diesen Teil viel besser machen, wenn wir ihn neu schreiben, um die Spindelfaltung zu verwenden" und die Reaktion vor tatsächlich messen es tun.

bis zu einem gewissen Grad -> bis zu einem gewissen Grad?
Dies ist eine sehr gute Antwort, insbesondere der vierte Absatz.Es gibt nur wenige Dinge, die so frustrierend sind wie Menschen, die alles ändern wollen, ohne die Gründe für die aktuellen Prozesse / Systeme / Regeln zu verstehen.(Und ich schreibe das als eine Person, die Veränderungen liebt und kritisches Denken als eine der größten Stärken ansieht, die jeder haben kann).
#5
+34
Mark K Cowan
2019-03-07 02:35:00 UTC
view on stackexchange narkive permalink

Ich spreche von der anderen Seite des Schreibtisches - auf persönlicher Ebene bin ich ziemlich glücklich, wenn ein Bewerber sogar Github-Repos oder eine andere Art von Portfolio hat und Hintergrundrecherchen durchgeführt hat was das Unternehmen tut. Dies entspricht 3-5% aller Bewerber.

Ein Bewerber, der möglicherweise beide 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.

Ich bin neugierig, was ist deine Rolle?Ich kann das aus zwei Perspektiven sehen - Der Kandidat ist ein Macher.Von HR, das ist golden, oder?Auf der anderen Seite ist es genau so, wie der (technische) Personalvermittler sagte: OP erweckte den Eindruck, DIESER Schmerz im Hintern zu sein, der Grenzen nicht versteht und versuchen will, die Dinge so zu ändern, wie es ihr Professor gesagt hatsein (oder schlimmer noch, wie es für sie Sinn macht).Ah, das Paradox, proaktive Leute einstellen zu wollen, die ihre Nase nicht dort stecken, wo sie nicht hingehört ...
Ein bisschen erinnert mich an das, was mein alter Chef gesagt hat: "Wir sind keine Auftragnehmer, aber wir müssen tun, was uns gesagt wurde."
@Mars IMO "Schmerz im Hintern", der früh Probleme findet, aber die Leute dabei nervt, ist besser als "Profi", der sich nur an seine eigenen Grenzen hält.Aber mein Team besteht aus <20 Personen.Ich würde mir vorstellen, dass dieser Ansatz in größeren Teams Probleme mit der Skalierbarkeit hat.Mein Team korrigiert mich oft in Bezug auf Dinge, da jeder von ihnen seinen eigenen Bereich besser kennt als ich und mit den Tools und Prozessen in seinem Bereich auf dem neuesten Stand ist.
@MarkKCowan Sicher, ein Schmerz im Hintern, der früh Probleme findet, ist groß und Gold wert.Nach der Reaktion des technischen Interviewers zu urteilen, fand OP kein Problem, sie verschwendeten ihre Zeit (und die Zeit des Rezensenten) mit einer PR, die nichts Sinnvolles beisteuerte.Ich möchte keinen Mitarbeiter bezahlen, der die Unternehmenszeit auf diese Weise nutzt!(Klingt hart und ich bin sicher, dass keiner von uns in seiner Karriere 100% produktiv war, aber wenn das Ihr erster Eindruck ist, werden sie wahrscheinlich nicht sehr hoch von Ihnen denken.)
@Mars Aber das OP (frisch graduiert) war nicht im Unternehmen beschäftigt.Jede Zeit, die für eine (möglicherweise) frivole PR verschwendet wird, wird von einem Mitarbeiter durchgeführt, der bereits im Unternehmen beschäftigt ist.Daher wurde jede verschwendete Zeit von einem Mitarbeiter erledigt (möglicherweise 2, wenn er einen HR-Mitarbeiter in den Kandidaten einbezog und ein Meeting / eine Diskussion darüber hatte).Dies würde mir sagen, dass die Mitarbeiter des Unternehmens die Gewohnheit haben, durch die Verwendung von [nicht wartbarem Code] (https://github.com/Droogans/unmaintainable-code) sicherzustellen, dass sie weiterhin beschäftigt bleiben.Der Kandidat vermied es, in einen Vulkan zu gehen.
@rkeet Woher wissen Sie, wann eine PR leichtfertig ist, ohne sie anzusehen?Der überprüfende Mitarbeiter verschwendete keine Zeit, sondern tat, was im Rahmen seiner Arbeit wahrscheinlich ist.Es ist nicht ihre Schuld, dass die PR, die sie überprüfen mussten, leichtfertig war.Der ursprüngliche Beitrag enthielt auch keine Hinweise darauf, dass die Mitarbeiter nicht wartbaren Code verwendeten, daher die ausgewählte Antwort, dass die PR möglicherweise nur leichtfertig war.Achten Sie darauf, nicht zu viel zu * projizieren *!
#6
+23
Edd
2019-03-06 21:40:03 UTC
view on stackexchange narkive permalink

Sie haben nichts falsch gemacht. Wenn eine Pull-Anfrage, die eine Codefunktion umgestaltet, ihr Boot erschüttert, lässt dies nicht viel Raum für komplexere Interaktionen.

Die Rolle des Projektbetreuers (oder Überprüfers) besteht darin, jegliche Politik zu entwirren (wahrgenommene Arroganz, Inkompetenz) aus dem Code selbst und überprüfen Sie den Code objektiv. Wenn ein Prüfer eine Pull-Anfrage erhält und sich nur auf die Politik konzentriert ("Wie können Sie es wagen, diese PR zu erhöhen?") Und den Code nicht einmal prüft, sind sie in ihrer Rolle sehr ineffektiv.

Um ehrlich zu sein, hört es sich nicht so an, als würden sie jemanden Ihres Kalibers suchen. Seien Sie froh, dass Sie bald einer besseren Firma beitreten.

#7
+14
bob
2019-03-06 20:27:39 UTC
view on stackexchange narkive permalink

Wie @Kyralessa sagte, war es möglicherweise Ihr Kommentar , nicht Ihre PR
Was haben Sie als Kommentar zu Ihrer Pull-Anfrage eingegeben? Das ist der Schlüssel, der hier fehlt. Möglicherweise haben Sie in Ihrem Kommentar unbeabsichtigt mitgeteilt, dass die ursprünglichen Entwickler Idioten waren und dass Sie weit überlegen waren. Das Schlüsselwort hier ist "ungewollt". Als Entwickler ist das sehr einfach. Ich sage nicht, dass Sie dies getan haben, aber es ist eine eindeutige Möglichkeit.

... Oder sie haben Angst davor, sich mit einer Initiative zu befassen.
Eine andere Möglichkeit Wie andere bereits erwähnt haben, schützen sie ihren Code übermäßig, und vielleicht möchten sie sich nicht mit der Betreuung eines neuen Hochschulabsolventen mit Initiative befassen, der (wie alle anderen im selben Boot) eine erhebliche Betreuung und Aufsicht benötigt um sicherzustellen, dass sie keine großen Fehler machen (ich spreche aus Erfahrung, die hier vor Jahren einer von ihnen war).

... oder sie wissen nicht, wie sie interviewen sollen stark>
Sie wissen möglicherweise nicht, wie sie für den gewünschten Kandidatentyp interviewen sollen, und haben ihre Seite des Interviewprozesses verpfuscht.

Hey, ich rate demütig davon ab, h1-Header in deiner Antwort so zu verwenden.Es verschmutzt Ihre Antwort und die gesamte Seite.
Danke für die Rückmeldung.Persönlich helfen sie mir beim Überfliegen, und sie scheinen anderen zu helfen, da ich bemerkt habe, dass sie die Wahrscheinlichkeit erhöhen, Stimmen zu erhalten (wahrscheinlich, weil die Leute es eher lesen).Aber ich kann sehen, warum manche Leute sie visuell als störend empfinden.
Sichere Sache.Beachten Sie, dass eine Webseite nur einen Header der Ebene 1 haben soll (im Fall dieser Seite ist dies der Fragentitel, der im Quellcode überprüft werden kann).Trotzdem sehe ich keinen Schaden darin, entweder "h2" -Header oder fetten Text zu verwenden, wenn dies mit Bedacht getan wird.
Tut mir leid, dass meine Antwort wie in Ihrem Kommentar beschrieben bearbeitet wurde - ich verstehe jetzt etwas besser.Klar, ich kann mich an fetten Text halten - ich denke, er sieht gut aus.
Meine eigene Firma hat auf dieser Grundlage gerade einen oberflächlich qualifizierten Kandidaten abgelehnt.Wir wissen, dass er schlau ist, aber der * Ton *, den er nahm, um die Notwendigkeit einer besseren Leistung eines von ihm verwendeten Spiels zu melden, hat uns wirklich ausgeschaltet.Wir wollen nicht, dass er so mit jemandem in der Firma spricht, und das Leben ist zu kurz, als dass wir das Risiko eingehen könnten, ihn richtig erziehen zu müssen.
#8
+9
Dmitry Grigoryev
2019-03-07 18:29:52 UTC
view on stackexchange narkive permalink

In den meisten Unternehmen würden Ihre Maßnahmen positiv bewertet, selbst wenn es am Ende einen guten technischen Grund gäbe, Ihre Pull-Anfrage abzulehnen:

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

Das heißt, es sei denn, der von Ihnen geschriebene Code war ein völliger Unsinn, der sie davon überzeugt hat, dass Sie nicht die Erfahrung hatten, die sie von den ersten Interviews an angenommen hatten, oder dass Sie es irgendwie geschafft haben, sie im Kommentar zu beleidigen.

Die andere Möglichkeit besteht darin, dass das Repository ein offensichtliches und gepflegtes Problem- / Funktionsprotokoll hatte und OP all dies ignorierte, um ein wenig umzuschreiben, von dem er glaubte, dass er damit angeben könnte, dass es keine Probleme und keine Funktionsanforderungen gab.Was tatsächlich ein mangelndes Interesse daran zeigen könnte, nützlich zu sein.
@J.Doe Für mich würde dies eher einen Mangel an Erfahrung mit GitHub bedeuten, was (es sei denn, der Lebenslauf bewirbt das OP als GitHub-Experte) ein kleiner Ärger ist, kein Grund, den Bewerber fallen zu lassen.
#9
+6
Sigma Ori
2019-03-09 22:14:00 UTC
view on stackexchange narkive permalink

Er sagte, dass es so aussah, als wüsste ich mehr als sie als frischgebackener College-Absolvent, und ich habe nicht darüber nachgedacht, warum sie es so codiert haben, wie es war. Ich habe den Job nicht bekommen.

Betrachten Sie sich als glücklich, dass Sie den Job nicht bekommen haben , denn die Behandlung, die Sie für diese Pull-Anfrage erhalten haben, ist wahrscheinlich ein Geschmack von der Behandlung, die Sie erhalten hätten, wenn Sie in diesem Unternehmen gearbeitet und diese (oder eine andere) Änderung vorgeschlagen hätten.

Um ganz klar zu sein: Ja, ich finde es sehr wahrscheinlich, dass Ihre PR nicht war. ' Es passt nicht zu ihnen und sie haben wirklich gute Gründe, ihren Code so zu haben, wie sie es tun, anstatt wie Sie es vorgeschlagen haben. Mit anderen Worten, ich glaube sehr, 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 Senioren , dass ein einfacher Vorschlag "unangemessen" ist, dass es eine arrogante Art ist, "Ich weiß mehr als Sie" zu sagen, und dass ein Kandidat mit Hochschulabschluss nicht em kann > in der Tat wissen Sie so viel wie sie oder mehr, ist eine dreifache rote Fahne , weil:

  • Es lässt den Verdacht aufkommen, dass sogar, wenn Sie dort gearbeitet haben Ihre guten Ideen würden vollständig mit der Begründung abgelehnt, dass Sie ein Junior sind, nur damit die Senioren ihre eigene Rolle und ihren Gehaltsscheck rechtfertigen können .
  • Dies zeigt, dass sie haben einige ernsthafte Unsicherheiten über ihr eigenes Fachwissen - und ich würde gerne glauben, dass diese Unsicherheiten gerechtfertigt sein könnten .
  • Wenn dieser Senior zufällig fehlt formale Ausbildung in Software gibt es Anzeige Ein Anreiz für sie, die Bedeutung eines Abschlusses und das daraus resultierende Fachwissen herunterzuspielen, damit ihre eigenen Manager sie nicht durch ebenso erfahrene Entwickler ersetzen, die auch über Zertifizierungen verfügen.

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

Solche Umgebungen existieren - nicht alle Unternehmen verwenden ein Einweg-Lehrer / Schüler-Modell wo das Wissen ausschließlich von den Senioren zu den Junioren fließt. (Und denken Sie daran, wenn Sie Ihren Abschluss gemacht haben, sind Sie kein Student, und viele Senioren in dieser Branche sind auch keine "Ingenieure", unabhängig davon, wie ein Unternehmen sie nennt.)

Ich würde mich gleichermaßen von Orten fernhalten, die alles umsetzen, was Sie vorschlagen.Ich habe Fälle gesehen, in denen die Idee eines jeden umgesetzt wurde und eine schreckliche Codebasis entsteht, die nicht geändert werden kann.Ich würde gerne an einen Ort gehen, an dem Sie Beweisgründe haben, und sobald Sie diesen Punkt erreicht haben, sind Ihre Vorschläge und Meinungen für alle gleichermaßen wertvoll.Zumindest würde ich den Personalchef respektieren, wenn er gesagt hätte, die Idee sei gut, aber sie können es aus geschäftlichen Gründen nicht tun, und dann eingehend erläutern, warum sich das OP dafür entschieden hat, und seinen Denkprozess sehen.Das Interview nicht sofort beenden.
@Dan Ich spreche nicht darüber, ob sie einen Ihrer Vorschläge annehmen oder ablehnen.Ich spreche speziell darüber, ob ein Junior nicht einmal * im Prinzip * irgendetwas vorschlagen darf.Für mich schreit dies, dass die dort beschäftigten Senioren wahrscheinlich Betrüger sind - und selbst wenn dies nicht der Fall ist, ist es für einen Junior am besten, zu einer anderen Firma zu gehen, in der ihre Begeisterung nicht zerstört wird.
#10
+4
Harper - Reinstate Monica
2019-03-07 23:07:46 UTC
view on stackexchange narkive permalink

Das Problem ist, dass Ihre "Verbesserung" naiv und künstlich war, und ich weiß, dass Sie es aufgrund der kürzeren Zeit geschafft haben.

Das passiert mir die ganze Zeit. Ich baue ein komplexes System auf, damit Daten vielen Benutzern dienen können. Und dann kommt jemand und sagt: "Wir brauchen nicht all diesen Schtuff! Sie machen ein einfaches Problem viel zu komplex." Und sie hacken und zerschneiden und reduzieren es auf ein einfaches System, das ihnen gute Dienste leistet, und sie geben sich selbst einen goldenen Stern.

Außer, dass sie nicht der einzige Benutzer sind. Und die Änderungen haben es nur für alle anderen Benutzer dieser Daten gebrochen. Dann muss es also etwas geben ... Treffen, Umerziehung, Bitterkeit, Rollbacks, die allesamt unnötig waren.

Codierung ist der einfache Teil. Der schwierige Teil besteht darin, das Problem zu verstehen und auszudrücken. Sie haben den schwierigen Teil kurzgeschlossen, um den einfachen Teil zu vereinfachen.

Wenn Ihnen beigebracht wurde, dass Codierung König ist, nicht wirklich. Die andere Seite ist, wo das Geld ist: in der Lage zu sein, eine Spezifikation zu schreiben, die codierbar ist und alle Benutzer / Bedürfnisse behandelt. (Am anderen Ende der Skala ist es auch möglich, Lösungen zu entwerfen, die nur singen / tanzen, aber nicht beschreibbar sind. Deshalb müssen Sie die Codierung für das Design kennen.)

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

Und Sie haben es ihnen auf spektakuläre Weise gezeigt.

Beim Spielen ist ein "Neuling" nur ein Anfänger. Ein "Noob" ist ein Neuling, dessen Arroganz sie daran hindert, zu lernen oder die Erfahrungen anderer oder ihrer Ältesten im Allgemeinen zu respektieren. Letzteres scheint für Sie zutreffender zu sein, da Sie diesen Code so leicht so viel kürzer machen konnten, und es Ihnen nicht in den Sinn kam, dass dies dort zu einfach war musste ein Grund sein, warum sie es so komplex geschrieben hatten.

+1, du hast es geschafft.Ich denke, viele Leute auf diesem Board haben den Eindruck, dass Codierungsfähigkeiten der Schlüssel zum Erfolg in der Softwareentwicklung sind und nicht.Es ist nicht einmal die wichtigste Fähigkeit.Es ist viel wichtiger, das Problem zu verstehen und zu verstehen, welche Probleme tatsächlich gelöst werden müssen.OP konnte dies mit seiner PR nicht demonstrieren.
Beim Spielen ist ein Noob dasselbe wie ein Neuling.Noob braucht nur weniger Zeit zum Schreiben.Auch wenn er das Problem nicht verstanden hat, ist er zu diesem Zeitpunkt noch nicht einmal ein neuer Mitarbeiter.Nehmen Sie einfach das Interesse als Plus und lehnen Sie die Anfrage ab.
@Harper - Sie machen in Ihrer Antwort viele Annahmen.Wenn Ihr Code so komplex ist, sollte er wahrscheinlich etwas mehr entkoppelt / überarbeitet / überarbeitet werden als er ist.Komplex bedeutet nicht unbedingt kompliziert.Und ich habe eine ganze Menge Code durchgearbeitet, der von Leuten geschrieben wurde, die alles an einem Ort verstopft haben. Dieser war viel einfacher zu skalieren, zu warten und zu verstehen, nachdem er entkernt, vereinfacht und wieder zusammengesetzt wurde.
@Harper - so viel Spekulation hier.Ich habe die PR gefunden und sie (verschleiert) in eine Antwort aufgenommen, und es ist ziemlich klar, dass sie überhaupt nicht mit den vielen Annahmen übereinstimmt, die Sie gemacht haben.
#11
+2
Dan
2019-03-07 23:41:29 UTC
view on stackexchange narkive permalink

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

Ja, wahr. In einigen Fällen wird Code geschrieben, um eine bestimmte Geschäftsfunktion oder Regel zu unterstützen, die die Programmierer nicht steuern können.

Ich habe es mir eine Weile angesehen und eine viel einfachere und zukunftssichere Möglichkeit gefunden, eine Funktion zu schreiben, und mit der Änderung eine PR eröffnet, ohne zu erwähnen, dass ich gerade ein Interview führte.

Als junger Mensch denken wir gerne, wir sind schlau. Dass wir alles herausgefunden haben. Die Wahrheit ist, wenn Sie daran gedacht haben, könnte es auch jemand anderes haben, da Sie offensichtlich einen besseren Weg "gefunden" haben, indem Sie gegoogelt haben, was andere Leute getan haben. Wann immer Sie an etwas so offensichtliches denken, sollten Sie innehalten und zuerst danach fragen, um sicherzustellen, was auf die derzeitige Weise erreicht wird. Bill Gates googelte nicht, um Windows zu erstellen, er dachte darüber nach und implementierte es. Wenn Sie nicht in der Lage sind, dasselbe zu tun, haben Sie keinen "besseren Weg" gefunden. Sie googeln einfach besser als die letzte Person.

War es für mich wirklich unangemessen, dies zu tun?

Als PR für ihren Meister, ja es war etwas unangemessen. Vielleicht ein eigener Zweig, den Sie beim Interview teilen können. "Ich habe gesehen, wie Sie X gemacht haben, und als ich nachgeforscht habe, habe ich Y gefunden, das zukünftige Beweise und einfachere Änderungen ermöglicht. Ich weiß, dass Sie es aus einem bestimmten Grund geschrieben haben, aber ich war neugierig, 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 ist es beim nächsten Mal am besten, den Abschnitt zu kommentieren, den Sie mit einem

@ user geändert haben. Ich stelle fest, dass ihr hier X macht, aber ich habe ein Y eingefügt Wollte meine Fähigkeit zeigen, Ihren Code zu lesen und Änderungen vorzunehmen, usw.

Wenn Sie ihrem Meister eine PR machen, ist dies im Wesentlichen die gleiche wie die Nachricht von dem Mann, der Klempner werden wollte, keinen Job fand und sich entschied, ein Gasleck in seiner Nachbarschaft zu "reparieren". Sie können sich das Endergebnis vorstellen, das passiert ist.

-1 für den letzten Absatz.Ein Amateur, der eine Gasleitung „repariert“, kann unermesslichen Schaden anrichten, aber eine Pull-Anfrage ändert den Code, auf dem er basiert, erst, wenn er akzeptiert wird.Es ist eher so, als würde man die Gasgesellschaft anrufen und sagen: "Sie haben ein Leck, weil die Wurzeln eines Baumes das Rohr zerquetscht haben. Sie können Ihr Rohr durch meinen Garten führen, um dem Baum auszuweichen, wenn Sie möchten."
@RichardWard Die PR hatte Auswirkungen auf das wirkliche Leben ... er hat sein Interview nicht bestanden, weil er den Entwickler beleidigt hat.Es war nicht seine Absicht, da er seine Fähigkeiten unter Beweis stellen wollte, aber es hatte eine Nebenwirkung, die er nicht beabsichtigte.Darüber hinaus wurde seine PR vermutlich abgelehnt.
Ist das nicht eher so, als würde die Gasgesellschaft sagen: "Wir wollen Ihren Garten nicht, und weil Sie ihn angeboten haben, werden wir das Gas zu Ihrem Haus abschneiden"?
#12
+1
Petr
2019-03-07 14:22:43 UTC
view on stackexchange narkive permalink

Um andere Antworten zu ergänzen,

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

Sie scheinen viel zu korrigieren einfacher und robuster; Es kann jedoch leicht sein, dass der alte Code so geschrieben wurde, wie er absichtlich geschrieben wurde.

Wahrscheinlich hat Ihre Pull-Anfrage einige Aspekte des Verhaltens geändert (Sie könnten sogar denken, dass Sie einen Fehler behoben haben), aber es gibt einen entfernten Code, der sich auf diesen Fehler stützt.

Wahrscheinlich Sie hat nicht berücksichtigt, wie der Code verwendet wurde, und daher ist Ihr Code in dieser speziellen Situation schlechter. Beispielsweise funktioniert Ihr Code möglicherweise nicht in einer Multithread-Umgebung, oder die Daten, mit denen sich der Code befasst, weisen möglicherweise einige nicht offensichtliche Eigenschaften auf, mit denen der alte Code besser und schneller funktioniert.

Nach allem, was wir wissen, haben Sie möglicherweise hat 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.

Möglicherweise haben Sie etwas anderes übersehen. Immerhin arbeiten sie schon lange 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 es so codiert haben, wie es war", legt dies nahe.


Dies sagte, ich stimme anderen Leuten zu, die sagen, dass das Öffnen einer PR ist nichts Schlechtes. Wie bei jeder neuen Codebasis ist es jedoch oft besser, dies mit den Betreuern zu besprechen. Angesichts der Tatsache, dass Sie zu diesem Zeitpunkt gerade Interviews geführt haben, hätten Sie diese Frage einfach im Interview stellen können.

Wenn ein Fehler absichtlich nicht behoben wurde, wäre es dann nicht angebracht, wenn ein Kommentar so etwas wie "Wir wissen, dass 1 + 1 nicht gleich 3 ist, aber wir brechen x und y, wenn dies nicht der Fall ist" sagt?Nur um genau diese Situation zu vermeiden, in der jemand, der mit der Codebasis nicht vertraut ist, sie "repariert"?
@Atheist, in einer idealen Welt - ja.In Wirklichkeit - bei weitem nicht immer
#13
  0
Richard Flamsholt
2019-03-14 06:49:14 UTC
view on stackexchange narkive permalink

Es ist schwer zu erkennen, wie es an sich unangemessen sein kann, eine PR für ein Open-Source-Projekt eines anderen zu schreiben.

Daher muss es auf die Einzelheiten ankommen, von denen wir weiß sehr wenig. War es naiv oder arrogant in Code oder Haltung? War es hilfsbereit und freundlich? Ohne mehr zu wissen, ist es schwierig, die Angemessenheit zu beurteilen.

Die Neugier hat mich überwältigt. Ich habe deine PR gefunden. Und es hat mich so beeindruckt, dass ich beschlossen habe, es hier zu teilen. Es war keine leichte Entscheidung, weil ich weder Sie noch das Unternehmen an der Vertraulichkeit verraten möchte, aber ich hatte das Gefühl, dass dies in akzeptabler Weise einen wesentlichen Kontext 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 es in seiner Gesamtheit:

  # Wenn dies mit einem Argument aufgerufen wird, verwenden Sie dieses für target-target = 'jadaskjafjldfsfsasf', wenn len (sys.argv) > 1: arg = sys .argv [1] if arg == '...': print '...' else: target = arg-- match = some_lookup (Ziel) + match = some_lookup (Ziel) if match: print "..."  

Der Code initialisiert das -Ziel mit einer fest codierten Zufallszeichenfolge. (Beachten Sie, dass ich nur die Zeichen der Zeichenfolge gemischt habe, um diesen Teil zu verschleiern.) Wenn kein Argument angegeben wird, kann some_lookup (target) keine Übereinstimmung erzeugen, da die absichtlich verrückte Standardzeichenfolge vermutlich nicht gesucht werden kann.

Dies ist eindeutig beabsichtigt. Es ist aber auch objektiv eine schlechte Codierung.

Ihr Fix scheint eine Verbesserung zu sein. Ich selbst würde dies in einer Codeüberprüfung ohne zu zögern bemerken. Und ich konnte mir leicht vorstellen, genau dieselbe 25 Wörter lange freundliche, nicht konfrontative Commit-Nachricht zu schreiben, die Sie geschrieben haben.

Daher erscheint mir diese spezielle PR nicht unangemessen. Und vorausgesetzt, es wird professionell, respektvoll und in gutem Glauben durchgeführt, eine PR wäre niemals unangemessen , auch nicht bei Interviews.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...