Najwyraźniej nie był to dobry wybór taktyczny dla tej firmy, ale dość głupie jest zadawanie sobie trudu zakładania publicznego repozytorium, a następnie lekceważenie ludzi za to, że mają bezczelność do przesyłania żądań ściągnięcia. Powiedzenie „Nie” żądaniu ściągnięcia nie jest ciężarem. Do licha, mogli to po prostu zignorować.

Gdybym był ankieterem, dałbym ci dodatkowe punkty za wykazanie prawdziwego zainteresowania firmą i pokazanie, że wiesz, jak pracować z open source projekt w repozytorium publicznym. Byłoby to prawdą, nawet jeśli przesłany kod byłby naiwny co do rozwiązania problemu.

Ponieważ w wierszu znajduje się oferta pracy, należy upewnić się, że przesłany kod jest wysokiej jakości (poproś kogoś innego przejrzyj to) i utrzymuj wszelkie komentarze w kodzie lub w żądaniu ściągnięcia w sposób pokorny i uprzejmy.

Część, która daje mi najwięcej czasu na przerwę, to „znacznie prostszy i przyszłościowy sposób napisania jednej funkcji”. Nie widziałem twojego kodu i nie rozumiem kontekstu twojej zmiany, ale nie wygląda na to, że naprawiłeś błąd, dodałeś funkcję, poprawiłeś wydajność lub w inny sposób zrobiłeś coś, co opiekunowie projektu uznali za znaczące. Widzę, że przesłanie żądania ściągnięcia dla niezamówionej zmiany tego rodzaju mogło nie wywrzeć najlepszego wrażenia.

Wiele projektów open source (i często także projektów programistycznych o zamkniętym kodzie źródłowym) nie działa jak artykuły w Wikipedii gdzie każdy jest zachęcany do ciągłego dokonywania drobnych zmian. Każda zmiana wiąże się z niezerowym kosztem: czas na przejrzenie, przetestowanie i zatwierdzenie, ryzyko zepsucia czegoś (nawet z solidnym zestawem testów), stworzenie czegoś, co zrozumie mniej członków zespołu itp. w rezultacie wiele projektów nie jest specjalnie przeznaczonych do zmiany rzeczy tylko dlatego; istnieje nieskończona liczba sposobów pisania dowolnej funkcji i nic by się nie udało, gdyby każdy regularnie zmieniał istniejący działający kod, aby spełnić swoją osobistą definicję „najlepszego”. Kiedy nadejdzie czas na refaktoryzację, jest to bardziej prawdopodobne, że zaangażuje się opiekun projektu, a nie pierwszy współtwórca, i zwykle ma to jakieś uzasadnienie. Są to normy i podobnie jak wszystkie normy, są one różne i generalnie są to rzeczy, których oczekuje się raczej poprzez osmozę niż nauczanie. Jeśli byłeś niedawnym absolwentem, prawdopodobnie nic z tego nie było wtedy szczególnie widoczne.

Większość żądań ściągnięcia dotyczy bardziej oczywistej potrzeby: naprawy błędu lub dodania funkcji. I nawet w takich przypadkach często lepiej jest najpierw omówić zadanie z opiekunem, ponieważ może on mieć kontekst i preferencje, których nie jesteś świadomy.

Dlatego nie uważam, że wysyłanie żądania ściągnięcia podczas rozmowy kwalifikacyjnej nie jest z natury niewłaściwe (z pewnością świadczy to o zainteresowaniu i entuzjazmie), ale z ich perspektywy mogli postrzegać Cię jako kogoś, kto prawdopodobnie przepisał działający kod bez większego uzasadnienia, a potem niestety zareagowali na ciebie negatywnie i protekcjonalnie. Co, pomocne, wiele mówi o nich i jak by to było pracować z nimi.

Źle zrozumiałeś otrzymaną opinię i skupiłeś się na niewłaściwej części

Powiedział, że wydało mi się, że wiem więcej niż oni, jako świeżo upieczona uczelnia grad i że nie zastanawiałem się, dlaczego zakodowali to tak, jak to było.

Problem nie polega na tym, że wysłałeś żądanie ściągnięcia, ale że zrobiłeś to dla czegoś, co sprawiło, że sam wyglądać na aroganckiego, ignoranta i nieświadomego własnych ograniczeń. Opisujesz swoją zmianę jako uczynienie ich kodu „znacznie prostszym i przyszłościowym”; z cytowanej powyżej sekcji wydaje się oczywiste, że się nie zgadzają. Co więcej, ponieważ są bardziej doświadczeni od Ciebie i znają swój własny kod, jest bardzo prawdopodobne, że mają rację, a Ty się mylisz.

Często zdarza się, że absolwenci wychodzą z dyplomów mocno zawyżeni własne kompetencje. Nie byli zirytowani tym, że wydałeś polecenie ściągnięcia, ale dlatego, że zdawałeś się wykazać brak zrozumienia własnych ograniczeń i brak szacunku dla ich umiejętności w przedłożeniu, które złożyłeś. Prawdopodobnie potęgowałeś to wrażenie podczas rozmowy kwalifikacyjnej.

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

„Niewłaściwe” może nie być najlepszym słowem, ale „nie strategiczne” prawdopodobnie byłoby trafne.

Ponieważ wydaje się, że jest to prawdopodobnie stosunkowo nowy pracownik w branży technicznej, jedną z pierwszych rzeczy musisz się nauczyć, że podejmowanie decyzji, jak coś zrobić i kiedy warto to zmienić, nie jest prostą sprawą. Biorąc pod uwagę, że masz bodziec, by zmienić coś, co już działało bez pytania, często zostaniesz oskarżony o „oddawanie czci nowemu i błyszczącemu” bez zrozumienia kosztów zmiany , złożone powody, dla których coś zostało zrobione tak, jak było lub pełen zakres nowych problemów, które wprowadziłby Twój pomysł .

A może to tylko małostkowi ludzie, dla których jesteś irytujący.

Rzecz w tym, że do pewnego stopnia nie ma znaczenia, co jest obiektywnie najlepsze, najważniejsze jest to, co jest subiektywnie najlepsze dla organizacji w danym momencie. Zmiana ma rzeczywisty koszt przełamania istniejącej świadomości, więc nowa metoda musi być znacznie lepsza w ważnych kwestiach , a nie tylko trochę lepsza w teorii lub trochę bardziej dopasowana do współczesnych trendów i sposobu myślenia.

Jeśli chcesz „zgłosić się na ochotnika” do czegoś bez pytania , prawdopodobnie uzyskasz lepszy odbiór, jeśli chodzi o rozwiązywanie wyjątkowych błędów, które mają wpływ na użytkowników niż odważne przepisywanie rzeczy, które już działały. Jeśli zrozumiesz nierozwiązany problem, zobacz, czy możesz dokonać zmiany, która jest tak mała i minimalna, jak to tylko możliwe, z komunikatem zatwierdzenia pierwszej klasy. Wyjaśnij, dlaczego ta jedna zmiana jest właściwym sposobem rozwiązania problemu, i spraw, aby była idealnie dopasowana do obecnego stylu i metodologii kodu. Daj im polecenie ściągnięcia, które jest łatwe do zatwierdzenia i nie wywołuje żadnych skomplikowanych kompromisów.

Jeśli naprawdę uważasz, że sekcja wymaga przepisania, zachowaj tę myśl, dopóki nie zostaniesz poproszony o wniesienie wkładu i będziesz świadomy priorytetów, historii i ogólnej natury kodu. Bądź przygotowany, aby zrozumieć, dlaczego zmiana, którą chcesz wprowadzić, nie jest zgodna z ich priorytetami i planem. Nieco sprzecznie z intuicją, im bardziej możesz wykazać zrozumienie obecnego kodu, wprowadzając poprawki, które bezproblemowo pasują do jego tradycji, tym większe jest prawdopodobieństwo, że zdobędziesz zaufanie i pójdziesz w nowym kierunku. Możesz też od niechcenia wprowadzić drastyczne zmiany w bardziej nieformalny sposób - „hej, myślałem, że moglibyśmy ulepszyć tę część, gdybyśmy ponownie napisali ją tak, by używała składania wrzeciona” i zmierzyć reakcję przed właściwie robi to.

Mówiąc z drugiej strony biurka - na poziomie osobistym jestem bardzo zadowolony, gdy kandydat ma nawet repozytoria Github lub innego rodzaju portfolio i przeprowadził pewne badania na temat czym zajmuje się firma. To około 3-5% wszystkich kandydatów.

Kandydat, który potencjalnie demonstruje obie z nich bardzo bezpośrednio, naprawiając / ulepszając nasz kod? Prawdopodobnie przegapili świetne zatrudnienie, a na pewno uniknąłeś przyłączenia się do strasznej kultury.

Nie zrobiłeś nic złego. Jeśli pull request, który refaktoryzuje jedną funkcję kodu, wstrząsnął ich łodzią, nie pozostawia to dużo miejsca na bardziej złożone interakcje.

Rolą opiekuna projektu (lub recenzenta) jest rozwikłanie polityki (postrzegana arogancja, niekompetencja) z samego kodu i obiektywnie przejrzyj kod. Jeśli recenzent otrzyma pull request i tylko skupi się na polityce („Jak śmiesz podnosić ten PR?”) I nawet nie przejrzy kodu, jest bardzo nieefektywny w swojej roli.

Szczerze mówiąc, nie wygląda na to, że szukają kogoś twojego kalibru, ciesz się, że wkrótce dołączysz do lepszej firmy.

Jak powiedział @Kyralessa, mógł to być Twój komentarz , a nie Twój PR
Co wpisałeś jako komentarz do żądania ściągnięcia? To jest kluczowy brakujący element. Być może nieumyślnie zakomunikowałeś w swoim komentarzu, że pierwotni programiści byli idiotami i że byłeś znacznie lepszy. Kluczowym słowem jest tutaj „nieumyślnie”. Jako programista jest to bardzo łatwe do zrobienia. Nie mówię, że to zrobiłeś, ale jest to pewna możliwość.

... Albo boją się poradzić sobie z nową inicjatywą
Inna możliwość jak wspominali inni, jest to, że są nadopiekuńczy w stosunku do swojego kodu i być może nie chcą zajmować się mentoringiem świeżego absolwenta college'u z inicjatywą, który będzie potrzebował (jak w przypadku wszystkich innych na tej samej łodzi) znacznego mentoringu i nadzoru aby upewnić się, że nie popełniają wielkich błędów (mówię z doświadczenia, że ​​byłem jednym z nich lata temu).

... Albo nie wiedzą, jak przeprowadzić wywiad silny>
Mogą po prostu nie wiedzieć, jak przeprowadzić rozmowę kwalifikacyjną z kandydatem, którego chcą, i spartaczyli swoją stronę procesu rozmowy kwalifikacyjnej.

W większości firm Twoje działania byłyby postrzegane pozytywnie, nawet jeśli istniałby dobry techniczny powód, aby w końcu odrzucić żądanie ściągnięcia:

• W szczególności świadczy to o Twoim prawdziwym zainteresowaniu tym stanowiskiem
• To dowód na to, że masz praktyczne doświadczenie w kodowaniu
• Była to okazja, aby porozmawiać o prawdziwym kodzie podczas rozmowy kwalifikacyjnej, zamiast wymyślonych ćwiczeń z kodowania.

To znaczy, chyba że napisany przez Ciebie kod był kompletnym nonsensem, który przekonał ich, że nie masz takiego doświadczenia, jak zakładali, że miałeś z pierwszych wywiadów, lub w jakiś sposób udało ci się ich obrazić w komentarzu.

Powiedział, że jako świeżo upieczony absolwent college'u wiem więcej od nich i nie zastanawiałem się, dlaczego tak to zakodowali. Nie dostałem tej pracy.

Uważaj się za szczęściarza, że ​​nie dostałeś pracy , ponieważ sposób traktowania tego żądania ściągnięcia jest prawdopodobnie gustem o traktowaniu, które dostałbyś, gdybyś pracował w tej firmie i zaproponował tę (lub jakąkolwiek inną) zmianę.

Aby było jasne: Tak, wydaje mi się bardzo prawdopodobne, że Twój PR nie był t jest dla nich odpowiednie i że naprawdę mają dobry powód, by mieć swój kod tak, jak robią, a nie tak, jak proponujesz. Innymi słowy, bardzo wierzę, że twój kod był prawdopodobnie prostszy, ale gorszy.

Jednak , chyba że zamieściłeś niegrzeczny komentarz w PR , założenie seniora , że prosta sugestia jest „niewłaściwa”, że jest to arogancki sposób powiedzenia „Wiem więcej niż ty”, a kandydat z wykształceniem wyższym nie może w rzeczywistości wiem tyle co oni lub więcej, to potrójna czerwona flaga , ponieważ:

• Budzi podejrzenia, że ​​jeśli tam pracowałeś, nawet Twoje dobre pomysły zostałyby odrzucone całkowicie na tej podstawie, że jesteś młodszy, tylko po to, aby seniorzy mogli uzasadnić swoją rolę i wypłatę .
• To pokazuje, że mają poważne wątpliwości co do własnej wiedzy - i byłbym skłonny sądzić, że te niepewności mogą być uzasadnione .
• Jeśli takiemu seniorowi brakuje formalna edukacja w zakresie oprogramowania, jest ad bodziec dla nich, by starali się bagatelizować znaczenie dyplomu i wiedzy, jaką z niego czerpie, aby ich menedżerowie w końcu nie zastąpili ich równie doświadczonymi programistami, którzy również mają certyfikaty.

  Żeby dać wam jakąś perspektywę, przeprowadziłam kiedyś gdzieś wywiady iw trakcie tego procesu przekazałam seniorom nieco radykalną sugestię dotyczącą systemu, który budowali. Nie tylko przyjęli to z zadowoleniem i rozważali, ale również wkrótce potem złożyli mi ofertę.

  Takie środowiska istnieją - nie wszystkie firmy zatrudniają jednokierunkowy model nauczyciela / ucznia gdzie wiedza płynie wyłącznie od seniorów do juniorów. (I pamiętaj, że jeśli ukończyłeś studia, to nie jesteś „studentem”, a wielu seniorów w tej branży nie jest w rzeczywistości „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 to ze względu na to, o ile krótszy byłeś w stanie to zrobić.

To zdarza mi się cały czas. Buduję złożony system, aby dane mogły służyć wielu użytkownikom. A potem ktoś podchodzi i mówi: „Nie potrzebujemy całej tej głupoty! Sprawiasz, że prosty problem jest zbyt skomplikowany”. Hakują i tną i redukują to do prostego systemu , który dobrze im służy i dają sobie złotą gwiazdę.

Tyle że nie są jedynymi użytkownikami. A modyfikacje po prostu zepsuły to dla wszystkich innych użytkowników tych danych. Więc musi być coś ... spotkania, reedukacja, zgorzknienie, wycofywanie się, wszystko to było niepotrzebne.

Kodowanie to łatwa część. Najtrudniejsze jest zrozumienie i wyrażenie problemu. Skręciłeś trudną część, aby ułatwić łatwiejszą część.

Gdyby uczono cię, że kodowanie jest królem, cóż, nie do końca. Po drugiej stronie są pieniądze: możliwość napisania specyfikacji, która jest kodowalna i obsługuje wszystkich użytkowników / potrzeby. (na drugim końcu skali można również zaprojektować rozwiązania, które są śpiewające / tańczące, ale niepisane, dlatego aby projektować, trzeba znać kodowanie).

To był sedno tego. 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” to nowicjusz, którego arogancja uniemożliwia mu naukę lub ogólnie szanowanie doświadczeń innych lub starszych. Wygląda na to, że ta druga opcja jest bardziej odpowiednia dla Ciebie, ponieważ tak łatwo byłeś w stanie skrócić ten kod o wiele krócej, i nie przyszło ci do głowy, że to było zbyt łatwe . musiał być powód, dla którego napisali to tak skomplikowane .

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

Tak, prawda. W niektórych przypadkach kod jest napisany w celu obsługi określonej funkcji biznesowej lub reguły, której programiści nie mogą kontrolować.

Patrzyłem na to 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, że obecnie prowadzę rozmowę kwalifikacyjną.

Jako młodzi ludzie lubimy myśleć, że jesteśmy sprytni. Że wszystko wymyśliliśmy. Prawda jest taka, że ​​gdybyś o tym pomyślał, mógł to zrobić ktoś inny, ponieważ najwyraźniej „znalazłeś” lepszy sposób, szukając w Google tego, co zrobili inni ludzie. Ilekroć myślisz o czymś tak rażąco oczywistym, powinieneś najpierw zatrzymać się i zapytać o to, aby upewnić się, co jest obecnie osiągane. Bill Gates nie wygooglował swojego sposobu budowania systemu Windows, pomyślał o tym i zaimplementował go. Jeśli nie jesteś w stanie zrobić tego samego, nie znalazłeś „lepszego sposobu”. Po prostu wygooglowałeś lepiej niż ostatnia osoba.

Czy było to dla mnie niewłaściwe?

Jako PR dla ich pana, tak to było trochę niewłaściwe. Być może własny oddział, którym możesz się podzielić podczas rozmowy kwalifikacyjnej. „Widziałem, jak zrobiłeś X, a po zbadaniu znalazłem Y, które pozwala na przyszłe zmiany i łatwiejsze modyfikacje. Wiem, że napisaliście to z jakiegoś powodu, ale byłem ciekawy, aby zademonstrować koncepcję opartą na Twoim kodzie.” Wiem, że w git możesz używać symboli @, a nawet otwierać łańcuch dyskusji. Być może następnym razem będzie najlepiej skomentować sekcję, którą zmodyfikowałeś za pomocą,

@ użytkownik Zauważyłem, że robicie tutaj X, ale wstawiłem Y . Chciałem pokazać, że potrafię czytać Twój kod i wprowadzać modyfikacje itp.

Robiąc PR swojemu mistrzowi, to w zasadzie to samo, co w wiadomościach o człowieku, który chciał zostać hydraulikiem, ale nie mógł znaleźć pracy, więc postanowił „naprawić” wyciek gazu w swojej okolicy. Możesz sobie wyobrazić efekt końcowy, który się wydarzył.

Aby dodać do innych odpowiedzi,

czy jesteś pewien, że Twój kod jest rzeczywiście poprawny i przydatny w tej konkretnej bazie kodu?

Może się wydawać, że poprawione poprawki są dużo prostsze i solidniejsze; jednak łatwo może się zdarzyć, że stary kod został napisany w taki sposób, w jaki został napisany celowo.

Prawdopodobnie twoje żądanie ściągnięcia zmieniło niektóre aspekty zachowania (możesz nawet pomyśleć, że naprawiłeś błąd), ale istnieje jakiś odległy kod, który opierał się na tym błędzie.

Prawdopodobnie Ty nie uwzględnił tego, w jaki sposób kod został użyty, dlatego 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órymi zajmuje się kod, mogą mieć pewne nieoczywiste właściwości, które sprawiają, że stary kod działa lepiej i szybciej.

Z tego, co wiemy, możesz mieć 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. W końcu pracują z tym kodem od dawna i prawdopodobnie powinni wiedzieć znacznie lepiej, jak to działa. Fakt, że powiedzieli „że [ty] nie zastanawiałeś się, dlaczego zakodowali to tak, jak to było” sugeruje to.

To powiedziawszy, zgadzam się z innymi ludźmi, którzy twierdzą, że otwarcie PR to nic złego. Jednak, jak w przypadku każdego nowego kodu, często lepiej jest omówić go z opiekunami. Biorąc pod uwagę, że byłeś w trakcie rozmów kwalifikacyjnych, mógłbyś po prostu zadać to pytanie podczas rozmowy kwalifikacyjnej.

Trudno jest zrozumieć, dlaczego pisanie PR dla czyjegoś projektu open source mogłoby być wewnętrznie niewłaściwe.

Dlatego musi sprowadzać się do szczegółów, z których wiem bardzo mało. Czy był naiwny czy arogancki w kodzie lub postawie? Czy było to pomocne i przyjazne? Nie wiedząc więcej, trudno jest ocenić stosowność.

Ciekawość wzięła górę. Znalazłem twój PR. I zrobiło to na mnie takie wrażenie, że postanowiłem się nim tutaj podzielić. Nie była to łatwa 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 bezpodstawnych spekulacji

Całkowicie zanonimizowałem i zaciemniłem PR, zmieniając wszystkie niestandardowe zmienne, ciągi znaków, metody i komentarze. Tutaj jest w całości:

  # jeśli to jest wywołane z argumentem, użyj tego dla 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 zainicjuje target do zakodowanego na stałe losowego ciągu. (Uwaga, tylko przetasowałem znaki łańcucha, aby zaciemnić tę część). Jeśli argument nie zostanie podany, some_lookup (target) nie zwróci dopasowania, ponieważ prawdopodobnie nie będzie mógł wyszukać celowo domyślnego ciągu wacko.

Jest to wyraźnie zgodne z projektem. Ale jest to również obiektywnie złe kodowanie.

Twoja poprawka wydaje się być ulepszona. Sam bez wahania odniosę się do tego w przeglądzie kodu. I z łatwością mogłem zobaczyć siebie, jak piszę dokładnie tę samą przyjazną, niekonfrontacyjną wiadomość o zatwierdzeniu składającą się z 25 słów, którą napisałeś.

Dlatego ten konkretny PR nie wydaje mi się niewłaściwy. Pod warunkiem, że jest to zrobione w profesjonalny, pełen szacunku sposób i w dobrej wierze, PR nigdy nie byłby niewłaściwy , w tym podczas rozmowy kwalifikacyjnej.