Was het echt ongepast om een pull verzoek te schrijven voor het bedrijf waarmee ik geïnterviewd heb?

Het was duidelijk geen goede tactische keuze voor dit bedrijf, maar het is vrij dom om de moeite te nemen om een publieke opslagplaats op te zetten en vervolgens de mensen te verachten voor het hebben van de chutzpah om pull-verzoeken in te dienen. Het is nauwelijks een last om “Nee” te zeggen tegen een pull-verzoek. Heck, ze hadden het gewoon kunnen negeren.

Als ik de interviewer was geweest, had ik je bonuspunten gegeven voor het tonen van echte interesse in het bedrijf en het laten zien dat je weet hoe je met een open source project in een public repository moet werken. Dat zou waar zijn, zelfs als de ingediende code naïef was over het probleem dat werd opgelost.

Aangezien er een vacature op het spel staat, moet je er zeker van zijn dat de code die je indient van hoge kwaliteit is (laat iemand anders er naar kijken), en houd eventuele opmerkingen in de code of in het pull-verzoek nederig en beleefd.

Het deel dat me hier de meeste pauze geeft is “een veel eenvoudigere en toekomstvaste manier om één functie te schrijven”. Ik heb je code niet gezien en heb geen begrip voor de context van je verandering, maar het klinkt niet alsof je een bug hebt gerepareerd, een functie hebt toegevoegd, de prestaties hebt verbeterd of iets anders hebt gedaan dat de projectbeheerders als zinvol beschouwden. Ik kan zien hoe het indienen van een pull-verzoek voor een ongevraagde wijziging van deze aard misschien niet de beste indruk heeft achtergelaten.

Veel open source projecten (en vaak ook gesloten source-ontwikkelingsprojecten) worden niet uitgevoerd zoals Wikipedia-artikelen waar iedereen wordt aangemoedigd om de hele tijd kleine wijzigingen aan te brengen. Er is een niet-nul kost die met elke verandering gepaard gaat: de tijd om het te herzien en te testen en goed te keuren, het risico om iets te breken (zelfs met een robuuste testsuite), iets te creëren dat minder teamleden begrijpen, etc… Als gevolg hiervan zijn veel projecten niet bijzonder groot in het veranderen van dingen alleen maar omdat er een oneindig aantal manieren zijn om een functie te schrijven, en er zou niets gedaan worden als iedereen regelmatig bestaande werkcode zou veranderen om te voldoen aan hun persoonlijke definitie van “het beste”. Als het tijd is om te refactoren, dan is de kans groter dat er een projectbeheerder bij betrokken is, in plaats van een beginnende bijdrager, en er is meestal een soort van rechtvaardiging bijgevoegd. Dit zijn normen, en zoals alle normen, variëren ze en zijn het over het algemeen dingen die je geacht wordt op te pikken door middel van osmose in plaats van te worden onderwezen. Als je pas afgestudeerd bent, is het waarschijnlijk dat niets van dit alles destijds bijzonder duidelijk was.

De meeste pull-verzoeken hebben betrekking op een meer voor de hand liggende behoefte: het repareren van een bug of het toevoegen van een functie. En zelfs in die gevallen is het vaak beter om de taak eerst te bespreken met de onderhouder, omdat die misschien context en voorkeuren heeft waar je je niet bewust van bent.

Dus ik denk niet dat het inherent ongepast is om ooit een pull verzoek in te dienen tijdens het interview proces (het toont zeker interesse en enthousiasme), maar vanuit hun perspectief, kunnen ze je gezien hebben als iemand die waarschijnlijk werkende code herschrijft zonder veel rechtvaardiging, en dan hebben ze, helaas, negatief en neerbuigend gereageerd naar je toe. Dat vertelt u, met hulp, veel over hen en hoe het zou zijn geweest om met hen te werken.

Je hebt de feedback die je kreeg verkeerd begrepen en je hebt je gericht op het verkeerde deel

Hij zei dat het overkwam alsof ik meer weet dan zij als een verse college grad, en dat ik niet heb overwogen waarom ze het gecodeerd hebben hoe het was.

Het probleem is niet dat je een pull verzoek hebt gedaan, maar dat je het deed voor iets dat jezelf arrogant leek, onwetend, en onbewust van je eigen beperkingen. Je beschrijft je verandering als het maken van hun code “veel eenvoudiger en toekomstbestendig”; het lijkt duidelijk uit de bovenstaande paragraaf dat ze het er niet mee eens zijn. Sterker nog, omdat ze meer ervaring hebben dan jij en bekend zijn met hun eigen codebase is het zeer waarschijnlijk dat ze correct zijn en jij het mis hebt.

Het is gebruikelijk voor afgestudeerden om uit hun diploma’s te komen met een sterke overschatting van hun eigen competentie. Ze waren niet geïrriteerd omdat je een pull verzoek deed, maar omdat je een gebrek aan begrip van je eigen grenzen en een gebrek aan respect voor hun vaardigheden bleek aan te tonen in de inzending die je deed. Waarschijnlijk heb je deze indruk nog versterkt tijdens het interview.

Tot slot, lees niet te veel in een bepaald deel van een bepaald interview: het kan zijn dat dit niets te maken had met het feit dat je de baan niet kreeg en dat ze gewoon een betere kandidaat hadden. Je weet het niet. Wees niet geobsedeerd door deze tegenslag en concentreer je in plaats daarvan op de volgende sollicitatie. Veel succes met je zoektocht naar een baan!

“Inappropriato” potrebbe non essere la parola migliore, ma “non strategico” sarebbe probabilmente accurato.

Poiché quello che suona come un lavoratore forse ancora relativamente nuovo in un campo tecnico, una delle prime cose che dovrete imparare è che il processo decisionale su come fare qualcosa, e quando vale la pena cambiarla, non è una cosa semplice. Dato che hai uno stimolo a cambiare qualcosa che già ha funzionato senza che ti sia stato chiesto di farlo, è probabile che ti trovi spesso accusato di “adorare il nuovo e brillante” senza capire il costo del cambiamento, le ragioni complesse _perché qualcosa è stato fatto così com'era, o l'intera portata di nuove questioni che la tua idea introdurrebbe.

O forse sono solo persone dalla mentalità ristretta che ti trovano fastidioso.

Il fatto è che, in un certo senso, non importa cosa sia obiettivo migliore, ma soprattutto cosa sia soggettivamente migliore per un'organizzazione in un determinato momento. Il cambiamento ha un costo reale nel rompere la consapevolezza esistente, quindi un nuovo metodo deve essere sostanzialmente migliore in modalità che contano e non solo un po’ migliore in teoria o un po’ più allineato alle tendenze e al pensiero contemporaneo.

Se vuoi “fare volontariato” su qualcosa senza che ti venga chiesto di farlo, probabilmente otterrai una migliore accoglienza per affrontare i bug veramente eccezionali che hanno un impatto sugli utenti, piuttosto che nel fare riscritture audaci di cose che hanno già funzionato. Se arrivate a capire un problema irrisolto, vedete se potete fare un cambiamento che sia il più piccolo e minimo possibile, con un messaggio di commit di prima classe. Rendete evidente il motivo per cui questo cambiamento è il modo giusto per risolvere il problema, e rendetelo un cambiamento che si inserisce perfettamente nello stile e nella metodologia attuale del codice. Date loro una richiesta di pull che sia facile da approvare e non invochi alcun complesso sentimento di compromesso.

Se credete veramente che una sezione debba essere riscritta, risparmiate questo pensiero fino a quando non vi viene chiesto di contribuire e siete consapevoli delle priorità, della storia e della natura del codice in generale. E siate pronti a capire perché il cambiamento che volete fare non è coerente con le loro priorità e con il loro piano. In qualche modo contro-intuitivamente, più si può dimostrare la comprensione del codice attuale facendo delle correzioni che si adattano perfettamente alle sue tradizioni, più è probabile che si acquisisca fiducia per prendere nuove direzioni. Si possono anche apportare cambiamenti drastici in modo più informale - “Ehi, stavo pensando che potremmo rendere questa parte molto migliore se la riscrivessimo per usare la piegatura del mandrino” e valutare la reazione prima di farlo.

Spreken van de andere kant van het bureau - op een persoonlijk niveau, ik ben heel blij als een aanvrager zelfs has Github repos of een ander soort van portefeuille, en heeft gedaan wat achtergrondonderzoek naar wat het bedrijf doet. Dit is als 3-5% van alle sollicitanten.

Een sollicitant die mogelijk beide van deze zeer direct aantoont, door onze code te fixeren/verbeteren? Ze hebben waarschijnlijk een geweldige aanwerving gemist, en je hebt zeker vermeden om je aan te sluiten bij een vreselijke cultuur.

Je hebt niets verkeerd gedaan. Als een Pull Request dat een functie van de code herstelt hun boot doet schommelen, laat dat niet veel ruimte voor meer complexe interacties.

De rol van de projectbeheerder (of Reviewer) is het ontwarren van elke politiek (vermeende arrogantie, incompetentie) van de code zelf, en het objectief bekijken van de code. Als een recensent een Pull Request ontvangt en zich alleen richt op de politiek (“Hoe durf je deze PR te verhogen?”) en niet eens de code bekijkt, zijn ze erg ineffectief in hun rol.

Om eerlijk te zijn, het klinkt niet alsof ze op zoek zijn naar iemand van jouw kaliber, wees blij dat je binnenkort bij een beter bedrijf gaat werken.

** Zoals @Kyralessa zei, kan het uw commentaar zijn geweest en niet uw PR** Wat heeft u als commentaar op uw pull-verzoek ingevoerd? Dat is het belangrijkste ontbrekende stuk hier. U hebt misschien onbedoeld in uw commentaar gecommuniceerd dat de oorspronkelijke ontwikkelaars idioten waren en dat u veruit superieur was. Het sleutelwoord hier is “onbedoeld”. Als ontwikkelaar is het heel gemakkelijk om dat te doen. Ik zeg niet dat je dit hebt gedaan, maar het is zeker mogelijk.

… Of ze zijn bang om met een nieuw initiatief om te gaan. Een andere mogelijkheid die anderen hebben genoemd is dat ze hun code overmatig beschermen en misschien willen ze niet omgaan met het mentorschap van een nieuw college met initiatief die (net als alle anderen in hetzelfde schuitje) significante mentorschap en toezicht nodig heeft om ervoor te zorgen dat ze geen grote blunders maken (ik spreek uit ervaring hier, omdat ik er jaren geleden een van hen ben geweest).

…Of ze weten niet hoe ze moeten interviewen Ze weten misschien gewoon niet hoe ze moeten interviewen voor het type kandidaat dat ze willen en hebben hun kant van het interviewproces verprutst.

In de meeste bedrijven zouden uw acties positief worden gezien, zelfs als er een goede technische reden was om uw pull verzoek uiteindelijk af te wijzen:

• Het toont je oprechte interesse in die positie in het bijzonder
• Het is een bewijs dat je hands-on ervaring hebt met codering
• Het was een kans om te praten over echte code tijdens het interview, in plaats van verzonnen codeeroefeningen

Dat wil zeggen, tenzij de code die je schreef complete onzin was die hen ervan overtuigde dat je niet de ervaring had die ze veronderstelden dat je had van de eerste interviews, of je slaagde er op de een of andere manier in om ze te beledigen in het commentaar.

Hij zei dat het overkwam alsof ik meer weet dan hen als een verse college grad, en dat ik niet heb overwogen waarom ze het gecodeerd hoe het was. Ik heb de baan uiteindelijk niet gekregen.

Bedenk dat je geluk hebt dat je de baan niet hebt gekregen , want de behandeling die je hebt gekregen voor dit pull verzoek is waarschijnlijk een voorproefje van de behandeling die je zou hebben gekregen als je bij dat bedrijf had gewerkt en deze (of een andere) verandering had voorgesteld.

Om heel duidelijk te zijn: Ja, ik vind het zeer waarschijnlijk dat je PR niet goed bij hen paste en dat ze echt een goede reden hebben om hun code te hebben zoals ze dat doen, in plaats van de manier waarop je het hebt voorgesteld. Met andere woorden, ik geloof heel erg dat *uw code waarschijnlijk eenvoudiger was, maar nog erger. *

Echter, tenzij je een onbeschofte opmerking in de PR hebt opgenomen, de veronderstelling van de senior dat een eenvoudige suggestie “ongepast” is, dat het een arrogante manier is om te zeggen “Ik weet meer dan jij”, en dat een college-geschoolde kandidaat kan niet, in feite, weet zo veel als hen of meer, is een driedubbele rode vlag, omdat:

• Het doet vermoeden dat als je daar zou werken, ** zelfs je goede ideeën zouden worden verworpen, volledig op grond van het feit dat je een junior bent, alleen ** zodat de senioren hun eigen rol en salaris kunnen verantwoorden.
• Het toont aan dat ze hebben een aantal ernstige onzekerheden over hun eigen expertise - en ik zou geneigd zijn te denken dat die onzekerheden gerechtvaardigd zouden kunnen zijn.
• Als die senior toevallig geen formele opleiding in software heeft, is er een extra stimulans voor hen om te proberen het belang van een diploma en de expertise die men eruit haalt te bagatelliseren, zodat hun eigen managers hen uiteindelijk niet vervangen door even ervaren ontwikkelaars die ook certificeringen hebben.

Om u wat perspectief te geven, heb ik ooit ergens een interview gehouden en tijdens het proces heb ik een wat radicale suggestie gedaan aan de senioren over een systeem dat ze aan het bouwen waren. Niet alleen hebben ze het verwelkomd en overwogen, maar ze hebben me ook kort daarna een aanbod gedaan.

Zulke omgevingen do bestaan - niet alle bedrijven gebruiken een eenrichtingsleermeester/student model waar kennis strikt van de senioren naar de junioren stroomt. (En vergeet niet, als je bent afgestudeerd dan ben je niet een “student”, en veel senioren in deze industrie zijn eigenlijk ook geen “ingenieurs”, ongeacht hoe een bedrijf besluit ze te noemen).

Het probleem is, je “verbetering” was naïef en kunstmatig, en ik weet dat door hoeveel korter je het hebt kunnen maken.

Dit gebeurt me steeds weer. Ik bouw een complex systeem om data ten dienste te stellen van vele gebruikers. En dan komt er iemand langs die zegt: “We hebben dit allemaal niet nodig! Je maakt een simpel probleem veel te complex.” En ze hacken en slashen, en reduceren het tot een simpel systeem dat hen goed van dienst is, en ze geven zichzelf een gouden ster.

Zonder dat ze niet de enige gebruiker zijn. En de aanpassingen hebben het net gebroken voor alle andere gebruikers van die data. Dus dan moet er iets zijn… vergaderingen, heropvoeding, bitterheid, rollbacks, dat was allemaal onnodig.

Codering is het makkelijke gedeelte. Het moeilijke deel is het begrijpen en uitdrukken van het probleem. Je hebt het moeilijke deel kortgesloten, om het makkelijke deel makkelijker te maken.

Als je geleerd hebt dat coderen koning is, nou ja, niet echt. De andere kant is waar het geld is: het kunnen schrijven van een spec die codeerbaar is en die alle gebruikers/behoeften afhandelt. (aan de andere kant van de schaal is het ook mogelijk om oplossingen te ontwerpen die all-singing/all-dancing zijn, maar on-schrijfbaar, daarom moet je de codering kennen om te kunnen ontwerpen).

Dat was de kern ervan. Je begreep het probleem dat de code probeerde op te lossen niet helemaal.

En dat liet je op spectaculaire wijze aan hen zien.

In gaming is een “newbie” slechts een beginner. Een “noob” is een beginner wiens arrogantie hen ervan weerhoudt om te leren, of om de ervaring van anderen of hun ouderen in het algemeen te respecteren. Het lijkt erop dat het laatste meer op jou van toepassing is, omdat je die code zo makkelijk kon verkorten, en het kwam niet bij je op dat dit te makkelijk was, er moest een reden zijn waarom ze het zo complex hadden geschreven.

en dat ik niet heb overwogen waarom ze het zo gecodeerd hebben.

Ja waar. In sommige gevallen wordt code geschreven om een bepaalde bedrijfsfunctie te ondersteunen of om te bepalen dat de programmeurs geen controle hebben.

Ik heb er een tijdje naar gekeken en vond een veel eenvoudigere en toekomstvaste manier om één functie te schrijven, en ik opende een PR met de verandering zonder te vermelden dat ik op dat moment aan het interviewen was.

Als jongere vinden we het leuk om te denken dat we slimmer zijn. Dat we het allemaal hebben uitgedokterd. De waarheid is dat als je erover nadenkt, iemand anders dat misschien ook wel heeft gedaan, omdat je duidelijk een betere manier hebt “gevonden” door te googlen wat andere mensen deden. Als je denkt aan iets dat zo overduidelijk voor de hand ligt, moet je stoppen en er eerst naar vragen om er zeker van te zijn wat er op de huidige manier wordt bereikt. Bill Gates googelde niet op zijn manier om Windows te bouwen, hij bedacht het en implementeerde het. Tenzij je in staat bent om hetzelfde te doen, heb je geen “betere manier” gevonden. Je googelt gewoon beter dan de laatste persoon.

Was het echt ongepast voor mij om dit te doen?

Als een PR voor hun meester, ja het was een beetje ongepast. Misschien een eigen tak die je kunt delen tijdens het interview. _“Ik zag hoe je X deed en bij het onderzoek vond ik Y die het mogelijk maakt om het in de toekomst te bewijzen en makkelijker aan te passen. Ik weet dat jullie het voor een reden hebben geschreven, maar ik was nieuwsgierig om een concept te demonstreren dat gebaseerd is op jullie code” _ Ik weet dat jullie in git @ symbolen kunnen gebruiken en zelfs een discussieketen kunnen openen. Misschien is het de volgende keer het beste om commentaar te geven op de sectie die je hebt aangepast met een,

@user Ik zie dat jullie hier X doen, maar ik heb er een Y in gezet. Ik wilde mijn vermogen laten zien om je code te lezen en wijzigingen aan te brengen,etc

Door een PR te maken voor hun meester, is het in wezen hetzelfde als het nieuwsverhaal van de man die een loodgieter wilde zijn, kon geen baan vinden, dus besloot ik een gaslek in zijn buurt te “repareren”. Je kunt je het eindresultaat wel voorstellen.

Om aan andere antwoorden toe te voegen,

*Weet u zeker dat uw code inderdaad correct en nuttig was in die specifieke codebase? *

You fix lijkt misschien veel eenvoudiger en robuuster; maar het kan gemakkelijk zijn dat de oude code is geschreven zoals hij met opzet is geschreven.

Waarschijnlijk heeft je pull verzoek enkele aspecten van het gedrag veranderd (je zou zelfs kunnen denken dat je een bug hebt gerepareerd), maar er is wat verre code die op die bug vertrouwde.

Waarschijnlijk heb je geen rekening gehouden met die manier waarop de code werd gebruikt, en daarom is je code erger in die specifieke situatie. Het kan bijvoorbeeld zijn dat je code niet werkt in een multithreaded omgeving, of dat de gegevens waar de code mee te maken heeft een aantal onduidelijke eigenschappen hebben waardoor de oude code beter en sneller werkt.

Voor zover we weten heb je misschien een domme reden over het hoofd gezien (een bug in je code, of het feit dat je code langzamer loopt, etc.) die voor een ervaren ontwikkelaar voor de hand zou moeten liggen.

Je hebt misschien iets anders over het hoofd gezien. Ze werken immers al heel lang met deze code en zouden waarschijnlijk veel beter moeten weten hoe het werkt. Het feit dat ze zeiden “dat [jij] er niet bij stilgestaan heeft waarom ze het zo gecodeerd hebben” suggereert dit.

• *

Dit gezegd zijnde, ben ik het eens met andere mensen die zeggen dat het openen van een PR niets slechts is. Echter, zoals bij elke nieuwe codebase is het vaak beter om het te bespreken met de beheerders. Gezien het feit dat je op dat moment bezig was met interviews, had je die vraag gewoon aan de orde kunnen stellen tijdens het interview.

Het is moeilijk te zien hoe het intrinsiek ongepast zou kunnen zijn om een PR te schrijven voor iemands open-source project.

Daarom moet het aankomen op de bijzonderheden, waarvan we weinig weten. Was het naïef of arrogant in code of houding? Was het nuttig en vriendelijk? Zonder meer te weten is het moeilijk om de gepastheid in te schatten.

Nieuwsgierigheid heeft mij de wind in de zeilen genomen. Ik heb je PR gevonden. En het maakte zo'n indruk op me dat ik besloot om het hier te delen. Het was geen lichte beslissing omdat ik de vertrouwelijkheid van noch jou, noch het bedrijf wil verraden, maar ik dacht dat het de discussie op een aanvaardbare manier in een substantiële context zou brengen. Het gebrek aan concrete details heeft zeker geleid tot veel ongefundeerde speculaties

Ik heb de PR volledig geanonimiseerd en verdoezeld door alle aangepaste variabelen, strings, methodes en commentaren te veranderen. Hier is het, in zijn geheel:

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

De code zal target initialiseren tot een hardcoded random string. (Let op, ik heb alleen shuffled de tekens van de string om dat deel te verdoezelen). Als er geen argument wordt gegeven dan zal some_lookup(target) geen match produceren omdat het waarschijnlijk niet de opzettelijk wacko standaard string kan opzoeken.

Dit is duidelijk ontworpen. Maar het is ook objectief slechte codering.

Uw fix lijkt een verbetering. Zelf zou ik dit in een code review opmerken, zonder aarzeling. En ik kon mezelf gemakkelijk dezelfde 25-word-lange vriendelijke, niet-confronterende commit boodschap zien schrijven als jij.

Daarom lijkt deze specifieke PR mij niet ongepast. En op voorwaarde dat het op een professionele, respectvolle manier en te goeder trouw wordt gedaan, zou een PR nooit ongepast zijn, ook niet bij het interviewen.