Czy to było naprawdę niestosowne, aby napisać pull request dla firmy, z którą rozmawiałem?

Najwyraźniej nie był to dobry taktyczny wybór dla tej firmy, ale to dość głupie iść na trud założenia publicznego repozytorium, a następnie pogardzać ludźmi za to, że mają chutpa do składania wniosków o pociągnięcie. Powiedzenie “nie” prośbie o wycofanie się nie jest prawie żadnym obciążeniem. Do diabła, mogliby to po prostu zignorować.

Gdybym był ankieterem, dałbym ci dodatkowe punkty za wykazanie rzeczywistego zainteresowania firmą i pokazanie, że wiesz, jak pracować z projektem open source w publicznym repozytorium. Byłoby to prawdą nawet, gdyby nadesłany kod był naiwny na temat rozwiązywanego problemu.

Ponieważ oferta pracy jest na linii, powinieneś być pewien, że nadesłany kod jest wysokiej jakości (poproś kogoś innego, aby go przejrzał), i zachować wszelkie komentarze w kodzie lub w pull requestie skromnie i grzecznie.

Część, która daje mi największą pauzę, to “znacznie prostszy i przyszłościowy sposób na napisanie jednej funkcji”. Nie widziałem twojego kodu i nie rozumiem kontekstu twojej zmiany, ale nie brzmi to tak, jakbyś naprawił błąd, dodał funkcję, poprawił wydajność, lub w inny sposób zrobił coś, co opiekunowie projektu uznali za sensowne. Widzę, że wysłanie prośby o taką zmianę może nie pozostawić najlepszego wrażenia.

Wiele projektów open source (a często także zamkniętych) nie jest prowadzonych jak artykuły w Wikipedii, gdzie wszyscy są zachęcani do wprowadzania małych zmian przez cały czas. Z każdą zmianą wiąże się niezerowy koszt: czas na jej przeglądanie, testowanie i zatwierdzanie, ryzyko zerwania czegoś (nawet z solidnym pakietem testowym), stworzenia czegoś, co jest zrozumiałe dla mniejszej liczby członków zespołu, itp… W rezultacie, wiele projektów nie jest zbyt dużych na zmianę rzeczy tylko dlatego, że; istnieje nieskończona ilość sposobów na napisanie dowolnej funkcji i nic by się nie stało, gdyby każdy regularnie zmieniał istniejący kod roboczy tak, aby spełniał swoją osobistą definicję “najlepszy”. Kiedy nadszedł czas na zmianę kodu, jest bardziej prawdopodobne, że będzie to wymagało zaangażowania opiekuna projektu, a nie pierwszego uczestnika, i zazwyczaj ma to jakieś uzasadnienie. Są to normy, i jak wszystkie normy, różnią się od siebie i zazwyczaj są to rzeczy, których oczekuje się, że zostaną wychwycone przez osmozę, a nie nauczone. Jeśli byłeś świeżo upieczonym absolwentem, prawdopodobnie nic z tego nie było wtedy szczególnie widoczne.

Większość zgłoszeń pull dotyczy bardziej oczywistej potrzeby: naprawienia błędu lub dodania funkcji. I nawet w tych przypadkach, często lepiej jest najpierw omówić zadanie z opiekunem, ponieważ mogą one mieć kontekst i preferencje, których nie jesteś świadomy.

Więc nie sądzę, że to jest z natury niewłaściwe, aby kiedykolwiek złożyć wniosek pull podczas procesu wywiadu (to z pewnością pokazuje zainteresowanie i entuzjazm), ale z ich perspektywy, mogą widzieć cię jako kogoś, kto jest prawdopodobne, aby przepisać działający kod bez większego uzasadnienia, a następnie, niestety, zareagował negatywnie i protekcjonalnie wobec Ciebie. Co, pomocne, mówi Ci wiele o nich i o tym, co by było, gdybyś z nimi pracował.

You have misunderstood the feedback you were given and focused on the wrong part

He said that it came out like I know more than them as a fresh college grad, and that I haven’t considered why they coded it how it was.

The problem is not that you issued a pull request, but that you did it for something that made yourself appear arrogant, ignorant, and unaware of your own limitations. Opisujesz swoją zmianę jako uczynienie swojego kodu “znacznie prostszym i przyszłościowym”; wydaje się oczywiste z cytowanej sekcji powyżej, że się nie zgadzają. Co więcej, ponieważ są oni bardziej doświadczeni niż ty i znają swoją własną bazę kodową, jest bardzo prawdopodobne, że mają rację, a ty się mylisz.

Często zdarza się, że absolwenci wychodzą ze swoich stopni naukowych mocno przeceniając swoje własne kompetencje. Nie drażniło ich to, że wystawiłeś wniosek o pociągnięcie, ale dlatego, że wydawałeś się wykazywać brak zrozumienia dla własnych ograniczeń i brak szacunku dla ich umiejętności w składanych przez Ciebie zgłoszeniach. Prawdopodobnie spotęgowałeś to wrażenie podczas rozmowy kwalifikacyjnej.

Wreszcie, nie czytaj zbyt wiele w żadnej konkretnej części każdej konkretnej rozmowy kwalifikacyjnej: może być tak, że nie miało to nic wspólnego z tym, że nie dostałeś pracy, a oni po prostu mieli lepszego kandydata. Nie wiesz. Nie miej obsesji na punkcie tego niepowodzenia i zamiast tego skup się na następnej aplikacji. Powodzenia w szukaniu pracy!

“Niestosowne” może nie być najlepszym słowem, ale “nie strategiczne” prawdopodobnie byłoby trafne.

Ponieważ to, co brzmi jak być może jeszcze stosunkowo nowy pracownik w dziedzinie technicznej, jedną z pierwszych rzeczy, których trzeba się nauczyć, jest to, że podejmowanie decyzji o tym, jak coś zrobić, a kiedy warto to zmienić, nie jest prostą sprawą. Biorąc pod uwagę, że masz impuls do zmiany czegoś, co już działało, nie będąc o to proszonym, możesz być często oskarżany o “czczenie nowego i błyszczącego” bez zrozumienia koszty zmiany, złożonych zasad, dlaczego coś zostało zrobione tak jak było, lub pełnego zakresu nowych zagadnień, które twój pomysł by wprowadził.

Rzecz w tym, że w pewnym stopniu nie ma znaczenia, co jest obiektywnie najlepsze, głównie ma znaczenie, co jest subiektywnie najlepsze dla organizacji w danym momencie. Zmiana ma realny koszt w przełamywaniu istniejącej świadomości, więc nowa metoda musi być substantially lepsza w ways that matter, a nie tylko trochę lepsza w teorii lub trochę bardziej zgodna ze współczesnymi trendami i myśleniem.

Jeśli chcesz “zgłosić się na ochotnika” do czegoś bez bycia poproszonym do, prawdopodobnie otrzymasz lepszy odbiór w zwalczaniu naprawdę wybitnych błędów, które mają wpływ na użytkowników, niż w odważnym przepisywaniu rzeczy, które już działają. Jeśli zrozumiesz nierozwiązany problem, sprawdź, czy możesz dokonać zmiany, która jest tak mała i minimalna, jak to możliwe, z pierwszą klasą commit wiadomość. Spraw, by było jasne, dlaczego ta jedna zmiana jest właściwym sposobem na rozwiązanie problemu, i zrób to tak, by pasowało do obecnego stylu i metodologii kodu. Daj im pull request, który jest easy do zatwierdzenia i nie wywołuje żadnych złożonych uczuć kompromisu.

Jeśli naprawdę wierzysz, że sekcję trzeba napisać od nowa, zachowaj tę myśl do czasu, gdy zostaniesz asked do wniesienia wkładu i jesteś świadomy priorytetów, historii i natury bazy kodowej w ogóle. I bądź gotów zrozumieć, dlaczego zmiana, której chcesz dokonać, nie jest zgodna z ich priorytetami i planem. Trochę kontr-intuicyjnie, im bardziej możesz wykazać się zrozumieniem obecnego kodu, wprowadzając poprawki, które pasują do jego tradycji, tym bardziej prawdopodobne jest, że zyskasz zaufanie, które pozwoli ci podążać w nowych kierunkach. Można też swobodnie wprowadzać drastyczne zmiany w bardziej nieformalny sposób - “hej, myślałem, że moglibyśmy uczynić tę część o wiele lepszą, gdybyśmy ją przerobili na składanie wrzeciona” i zmierzyć reakcję _zanim faktycznie to zrobimy.

Mówiąc z drugiej strony biurka - na poziomie osobistym, jestem dość zadowolony, gdy wnioskodawca nawet _ ma Github repozytorium lub innego rodzaju portfolio, i zrobił kilka badań tle na temat tego, co firma robi. To jest jak 3-5% wszystkich aplikantów.

Aplikant, który potencjalnie demonstruje _wszystkie z tych bardzo bezpośrednio, poprzez naprawę / poprawę naszego kodu? Prawdopodobnie przegapili świetny wynajem, a Ty z pewnością uniknąłeś dołączenia do strasznej kultury.

Nie zrobiłeś nic złego. Jeśli Pull Request wymaga, aby reformatorzy korzystali z jednej z funkcji kodu, nie pozostawia to wiele miejsca na bardziej złożone interakcje.

Rolą opiekuna projektu (lub recenzenta) jest oddzielenie jakiejkolwiek polityki (postrzeganej jako arogancja, niekompetencja) od samego kodu i obiektywne przejrzenie kodu. Jeśli recenzent otrzymuje Pull Request i tylko skupia się na polityce (“Jak śmiesz podnosić ten PR?”) i nawet nie recenzuje kodu, są bardzo nieefektywni w swojej roli.

Szczerze mówiąc, nie brzmi to tak, jakby szukał kogoś Twojego kalibru, ciesz się, że wkrótce dołączysz do lepszej firmy.

Jak powiedział @Kyralessa, to mógł być twój komentarz nie twój PR Co wpisałeś jako komentarz do pull requestu? To jest kluczowy brakujący element tutaj. Być może niezamierzenie przekazałeś w swoim komentarzu, że oryginalni programiści byli idiotami i że byłeś o wiele lepszy. Kluczowym słowem jest tutaj “nieumyślnie”. Jako deweloper jest to bardzo łatwe do zrobienia. Nie mówię, że to zrobiłeś, ale jest to konkretna możliwość.

… Albo boją się zajmować się świeżo upieczoną inicjatywą Inną możliwością, o której wspominali inni, jest to, że są nadopiekuńczy w stosunku do swojego kodu i być może nie chcą zajmować się mentoringiem świeżo upieczonej absolwentki z inicjatywą, która będzie potrzebowała (tak jak wszyscy inni na tej samej łodzi) znacznego mentoringu i nadzoru, aby upewnić się, że nie zrobią żadnych wielkich błędów (mówię to z doświadczenia, które było jednym z nich lata temu).

…Albo nie wiedzą jak przeprowadzić wywiad Mogą po prostu nie wiedzieć jak przeprowadzić wywiad dla typu kandydata, którego chcą i spartaczyli swoją stronę procesu wywiadu.

W większości firm, Twoje działania byłyby postrzegane pozytywnie, nawet jeśli istniałby dobry techniczny powód do odrzucenia Twojego wniosku o pociągnięcie w końcu:

• To pokazuje Twoje prawdziwe zainteresowanie tym stanowiskiem w szczególności
• Jest to dowód na to, że masz praktyczne doświadczenie w kodowaniu
• Była to okazja do rozmowy o prawdziwym kodzie podczas rozmowy kwalifikacyjnej, zamiast gotowych ćwiczeń z kodowania

To znaczy, chyba że kod, który napisałeś był kompletnym nonsensem, który przekonał ich, że nie masz doświadczenia, które zakładali, że masz od pierwszych wywiadów, lub jakoś udało Ci się ich obrazić w komentarzu.

Powiedział, że jakbym wiedział więcej niż oni, że jestem świeżym absolwentem college'u, i że nie zastanawiałem się, dlaczego zakodowali to tak. I didn’t end up getting the job.

Consider yourself lucky for not getting the job , because the treatment you got for this pull request is probably a taste of the treatment you would have gotten if you worked at that company and proposed this (or any other) change.

To be perfectly clear: Tak, uważam za bardzo prawdopodobne, że twój PR nie pasował do nich i że mają naprawdę dobry powód, aby mieć swój kod tak jak oni, zamiast tak jak proponowałeś. Innymi słowy, bardzo mocno wierzę, że *Twój kod był prawdopodobnie prostszy, ale gorszy. *

Jednakże , chyba że w PR-ie zamieściłeś niegrzeczny komentarz, założenie seniora że prosta sugestia jest “niestosowna”, że jest aroganckim sposobem powiedzenia “Wiem więcej niż ty”, i że kandydat z college'u nie może, w rzeczywistości, wiedzieć tyle co oni lub więcej, jest potrójną czerwoną flagą ponieważ:

• To budzi podejrzenia, że gdybyś tam pracował, nawet twoje dobre pomysły zostałyby odrzucone całkowicie z powodu tego, że jesteś juniorem, tylko więc seniorzy mogą usprawiedliwić swoją rolę i wypłatę.
• To pokazuje, że mają oni pewne poważne wątpliwości co do własnej wiedzy fachowej - i byłbym skłonny pomyśleć, że te wątpliwości mogą być usprawiedliwione.
• Jeśli temu seniorowi zdarzy się brak formalnego wykształcenia w zakresie oprogramowania, istnieje dodatkowa zachęta dla nich, aby spróbowali bagatelizować znaczenie stopnia i wiedzy fachowej, która się z niego wydostaje, aby nie zastąpili ich w końcu równie doświadczeni programiści, którzy również mają certyfikaty.

Aby dać wam jakąś perspektywę, kiedyś przeprowadziłem gdzieś rozmowę kwalifikacyjną i w trakcie jej trwania przedstawiłem seniorom nieco radykalną sugestię dotyczącą systemu, który są w trakcie budowy. Nie tylko przyjęli go z zadowoleniem i rozważyli, ale też wkrótce potem złożyli mi ofertę.

Takie środowiska do istnieją - nie wszystkie firmy stosują jednokierunkowy model nauczyciela/uczniaka, w którym wiedza przepływa wyłącznie od seniorów do juniorów. (I pamiętaj, jeśli ukończyłeś studia to nie jesteś “studentem”, a wielu seniorów w tej branży też nie jest właściwie “inżynierami”, niezależnie od tego, jak firma zdecyduje się ich nazwać).

Problem w tym, że twoja “poprawa” była naiwna i sztuczna, i wiem, że z powodu tego, o ile krócej udało ci się to zrobić.

Cały czas mi się to zdarza. Buduję skomplikowany system, aby dane mogły służyć wielu użytkownikom. A potem ktoś przychodzi i mówi: “Nie potrzebujemy tych wszystkich rzeczy! Sprawiasz, że prosty problem jest zbyt skomplikowany.” I hakują i tną, i redukują go do prostego systemu który dobrze im służy, i dają sobie złotą gwiazdę.

Wyjątek nie są jedynymi użytkownikami. A modyfikacje po prostu złamały go dla wszystkich innych użytkowników tych danych. Więc to musi być coś… spotkania, reedukacja, gorycz, rollbacki, wszystko to było niepotrzebne.

Kodowanie to łatwa część. Częścią trudną jest zrozumienie i wyrażenie problemu. Zwariowałeś część twardą, aby ułatwić część łatwą.

Jeśli nauczono Cię, że kodowanie jest królem, cóż, nie do końca. Druga strona to to, gdzie są pieniądze: możliwość napisania specyfikacji, która jest kodowalna i obsługuje wszystkich użytkowników/potrzeb. (na drugim końcu skali możliwe jest również projektowanie rozwiązań, które są śpiewne/wszystko-taneczne, ale niepisywalne, dlatego do projektowania trzeba znać kodowanie).

To był jej rdzeń. Nie do końca zrozumiałeś problem, który kod próbował rozwiązać.

I pokazałeś im to w spektakularny sposób.

W grach “nowicjusz” to zwykły nowicjusz. Noob" jest nowicjuszem, którego arogancja nie pozwala mu się uczyć, ani szanować doświadczenia innych lub ogólnie starszyzny. Wygląda na to, że ten ostatni jest bardziej odpowiedni dla ciebie, ponieważ tak łatwo mogłeś skrócić ten kod, i nie przyszło ci do głowy, że to było do łatwego , musiał być powód, dla którego napisali to tak skomplikowane.

i że nie zastanawiałem się, dlaczego zakodowali to tak jak było.

Tak prawda. W niektórych przypadkach kod jest pisany w celu wsparcia konkretnej funkcji biznesowej lub zasady, której programiści nie mogą kontrolować.

Przyjrzałem się temu przez chwilę i znalazłem znacznie prostszy i przyszłościowy sposób na napisanie jednej funkcji, i otworzyłem PR ze zmianą, nie wspominając o tym, że obecnie prowadzę wywiad.

Jako młody człowiek lubimy myśleć, że jesteśmy sprytni. Że doszliśmy do tego wszystkiego. Prawda jest taka, że gdybyś o tym pomyślał, to ktoś inny mógłby mieć równie dobrze, bo oczywiście “znalazłbyś” lepszy sposób, googlując to, co robili inni ludzie. Za każdym razem, gdy myślisz o czymś tak rażąco oczywistym, powinieneś zatrzymać się i zapytać o to najpierw, aby upewnić się, co jest osiągane w obecny sposób. Bill Gates nie googlował na swój sposób budowania Windows, ale pomyślał o tym i wdrożył go. Jeśli nie jesteś w stanie zrobić tego samego, nie znalazłeś “lepszego sposobu”. Po prostu google’d better than the last person.

Was it really inappropriate for me to do this?

As a PR to their master, yes it was slightly inappropriate. Może własną gałąź, którą możesz się podzielić podczas wywiadu. _“Widziałem jak zrobiłeś X i po zbadaniu znalazłem Y, który pozwala na przyszłe dowody i łatwiejszą modyfikację. Wiem, że napisaliście to nie bez powodu, ale byłem ciekaw, jak zademonstrować koncepcję opartą na twoim kodzie”. _“Wiem, że w gicie możesz używać symboli @, a nawet otworzyć łańcuch dyskusji. Być może następnym razem najlepiej będzie skomentować sekcję, którą zmodyfikowałeś a,

@user Zauważyłem, że robicie tu X, ale włożyłem Y. Chciałem pokazać moją zdolność do odczytywania kodu i dokonywania modyfikacji, etc.

Robiąc PR swojemu mistrzowi, to w zasadzie to samo, co news story o człowieku, który chciał być hydraulikiem, nie mógł znaleźć pracy, więc postanowił "naprawić” wyciek gazu w jego okolicy. Można sobie wyobrazić końcowy rezultat, który się zdarzył.

Aby dodać do innych odpowiedzi,

Czy jesteś pewien, że Twój kod był rzeczywiście poprawny i przydatny w tej konkretnej bazie kodów?

Naprawianie może wydawać się dużo prostsze i bardziej solidne, ale może być łatwo, że stary kod został napisany w sposób, w jaki został napisany celowo.

Prawdopodobnie twój pull request zmienił niektóre aspekty zachowania (możesz nawet myśleć, że naprawiłeś błąd), ale jest jakiś odległy kod, który opierał się na tym błędzie.

Prawdopodobnie nie odpowiedziałeś za to, jak kod został użyty, i dlatego twój kod jest gorszy w tej konkretnej sytuacji. Na przykład, Twój kod może nie działać w środowisku wielowątkowym, lub dane, których kod dotyczy mogą mieć pewne nieoczywiste właściwości, które sprawiają, że stary kod działa lepiej i szybciej.

Z tego co wiemy, być może przeoczyłeś jakiś głupi powód (błąd w Twoim kodzie, lub fakt, że Twój kod działa wolniej, itp.), który powinien być oczywisty dla doświadczonego programisty.

Być może przeoczyłeś coś innego. Przecież oni pracują z tym kodem od dawna i prawdopodobnie powinni wiedzieć o wiele lepiej, jak on działa. Fakt, że powiedzieli “że [ty] nie zastanawialiście się, dlaczego zakodowali to tak jak było” sugeruje to.

• *

To powiedziało, zgadzam się z innymi ludźmi, którzy mówią, że otwarcie PR-u nie jest niczym złym. Jednakże, jak w przypadku każdej nowej bazy kodowej, często lepiej jest omówić to z opiekunami. Biorąc pod uwagę, że byłeś w tym czasie w trakcie przeprowadzania wywiadów, mogłeś po prostu zadać to pytanie w trakcie wywiadu.

Ciężko sobie wyobrazić, jak to może być intrinsically niewłaściwe, aby napisać PR dla czyjegokolwiek projektu open-source'owego.

Dlatego też musi on sprowadzać się do szczegółów, o których wiemy bardzo mało. Czy było to naiwne czy aroganckie w kodzie lub postawie? Czy była pomocna i przyjazna? Nie wiedząc więcej, trudno jest ocenić stosowność.

Ciekawość miała o mnie lepsze zdanie. Znalazłem twój PR. I zrobił na mnie takie wrażenie, że postanowiłem podzielić się nim tutaj. Nie była to lekka decyzja, ponieważ nie chcę zdradzić poufności ani ciebie, ani firmy, ale czułem, że wniesie ona istotny kontekst do dyskusji w akceptowalny sposób. Brak konkretnych szczegółów z pewnością doprowadził do wielu nieuzasadnionych spekulacji

Całkowicie zanonimizowałem i zatuszowałem PR poprzez zmianę wszystkich niestandardowych zmiennych, ciągów, metod i komentarzy. Oto ona, w całości:

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

Kod inicjalizuje target do losowego, zakodowanego na twardo łańcucha. (Uwaga, ja tylko shuffled znaków łańcucha, aby zatuszować tę część). Jeśli argument nie zostanie podany, to some_lookup(target) nie wyprodukuje dopasowania, ponieważ prawdopodobnie nie będzie w stanie wyszukać domyślnego, celowo uszkodzonego łańcucha.

Jest to oczywiste z założenia. Ale jest to również objectively bad coding.

Twoja poprawka wydaje się być ulepszeniem. Sam chciałbym zauważyć to w recenzji kodu, bez wahania. I z łatwością mogłem zobaczyć siebie piszącego dokładnie taką samą 25-cio słowną, przyjazną, bezkonfliktową wiadomość commit, którą napisałeś.

Dlatego ten konkretny PR nie wydaje mi się niestosowny. I pod warunkiem, że będzie on zrobiony w sposób profesjonalny, z szacunkiem i w dobrej wierze, a PR nigdy nie będzie niestosowny, również podczas rozmowy kwalifikacyjnej.