Dwa lata temu odbyła się pierwsza edycja konferencji DynamIT. Mieliście okazję przeczytać o niej tutaj. Rok temu “nie było niczego”, ale na szczęście w tym roku wydarzenie wróciło.
Weźmy taką sytuację – wysłaliście swój kod do review a tam koledzy zgłaszają poprawki. Ot codzienność. Wrzucacie zatem poprawki w kolejny commit, powiedzmy pod nazwą “Fixes in relation to the code review” a później jeszcze drugi trzeci, bo poprawek jest więcej. Każdy zbiór poprawek wrzucacie w osobnym commicie aby było czytelniej – nie żadne tam amendy. W końcu historia w Waszym repo wygląda mniej więcej tak:
W końcu gdy Wasze zmiany zostaną zaakceptowane zabieracie się za squash czyli scalenie wszystkich commitów w jeden. Co w tym przypadku będzie przebiegało następująco:
git rebase -i masterWynikiem będzie następująca lista git-rebase-todo:
Chcielibyśmy by z tych czterech commitów został nam tylko pierwszy. W takim wypadku możemy wyedytować tę listę i napisać coś takiego:
W kolejnym kroku możemy dodatkowo pozbyć się śladów tych tymczasowych commitów:
Wówczas na koniec nasz git log będzie wyglądał następująco:
Wyobraźcie sobie, że w takiej sytuacji wcale nie musicie edytować git-rebase-todo, bo jest narzędzie, które wszystko co trzeba zrobić automatycznie.
Wróćmy zatem do momentu, gdy wrzucamy pierwsze poprawki do review i zamiast zrobić zwykły git commit użyjmy bohatera dzisiejszego artykułu czyli:
git commit --fixup 1f6fa91Gdzie hash – 1f6fa91, który widzicie odpowiada hashowi commita do którego dodajecie poprawki. Wówczas nasz git log będzie wyglądał następująco:
Dodajmy pozostałe commity i wówczas będzie to wyglądało tak:
Jak fajnie! Nie trzeba już wymyślać nazw commitów – nazwy tworzą się same.
Ostatecznie możemy teraz te commity scalić w jeden, tak jak robiliśmy to wcześniej, ale nie o to chodzi:) Teraz mamy do dyspozycji komendę:
git rebase --interactive --autosquash masterWówczas pojawi nam się okienko z git-rebase-todo i możemy je edytować albo zostawić tak jak jest i wówczas na koniec nasz git log wygląda następująco:
Inna sytuacja – zabieracie się do pracy nad jakimś zadaniem, ale wcześniej znaleźliście parę miejsc w kodzie, które można by ulepszyć i zdecydowanie powinny się znaleźć w osobnym commicie. Robicie zatem refaktoring, dodajecie commit z nim związany i ruszacie dalej z kopyta do pracy nad daną funkcjonalnością. Kodujecie, kodujecie, kodujecie i nagle pach! Jeszcze jedno miejsce, gdzie przydałby się refaktoring. No ale głupio tak wrzucić to do bieżącego commita, który dotyczy zadania nad którym pracujecie. Można wtedy utworzyć dodatkowy commit a następnie za pomocą git rebase scalić go z tym pierwszym dotyczącym refaktoringu. Strasznie dużo roboty!
Niech nasz git log wygląda następująco:
Ponieważ chcemy nasz kolejny commit tak naprawdę podpiąć pod ten związany z refaktoringiem, możemy zrobić tak:
git commit --fixup 6345e1Znowu wykorzystujemy hash aby powiedzieć gitowi do jakiego commita ma podpiąć ten nowy. Co się teraz stanie z historią commitów:
Może się wydawać, że ten commit wskoczył w to samo miejsce co normalny, zwykły commit. Ale… git sobie z tym bardzo zręcznie poradzi jeśli tylko następnie użyjemy znanej nam już komendy:
git rebase --interactive --autosquash masterI git-rebase-todo będzie miało commity w jak najbardziej prawidłowej kolejności:
W efekcie uzyskamy następującą historię:
Uwaga! Możliwe, że pojawią nam się tutaj konflikty, ale to nic strasznego – rozwiązujemy je tak jak normalne konflikty.
Nie musimy zawsze wpisywać --autosquash, gdy chcemy skorzystać z tej funkcjonalności. Zamiast tego możemy skonfigurować gita aby robił scalał commity oznaczone jako fixup automatycznie. Wystarczy wykorzystać następującą komendę:
git config rebase.autosquash true
Na jednym z portali, które pomagają w przygotowaniu do rozmów kwalifikacyjnych natknęłam się niedawno na artykuł na temat tego, jak radzić sobie z syndromem oszusta podczas technicznej rozmowy kwalifikacyjnej. Postanowiłam zatem podzielić się z Wami przemyśleniami na temat problemu syndromu oszusta nie tylko podczas technicznej części rekrutacji, ale całego procesu rekrutacyjnego.
Jeśli nie jesteście pewni czy syndrom oszusta dotyczy też Was, zapraszam do innego mojego artykułu w tym temacie: https://programistka.com/syndrom-oszusta-czy-dotyczy-tez-ciebie/
Nie trafimy na żadną rozmowę kwalifikacyjną, jeśli wcześniej nie przygotujemy porządnego CV. Jak się do tego zabrać, gdy wydaje nam się, że nic nie umiemy i na niczym się nie znamy? Przede wszystkim musimy przez moment skupić się na wszystkim co nam się udało w trakcie pracy w poszczególnych firmach. Idealnie byłoby, gdybyśmy pracując, notowali swoje mniejsze lub większe sukcesy. Jednak jeśli do tej pory tego nie robiliśmy, teraz poświęćmy chwilę i zastanówmy się, jak wyglądał nasz czas spędzony w jednej czy drugiej firmie. Spróbujmy to zrobić maksymalnie obiektywnie – w szczególności nie skupiać się tylko na tym, co nam się tam nie udało i jakich umiejętności nam brakowało.
Zamiast tego pomyślmy o tym z czym dobrze sobie radziliśmy, czego nowego się nauczyliśmy, jakie lekcje wyciągnęliśmy z różnych trudnych sytuacji, czym się zajmowaliśmy. I te nasze najlepsze strony przenieśmy do CV. Być może parę lat temu w swojej pierwszej pracy kiepsko nam szło, bo byliśmy początkującymi programistami i można by pomyśleć, że nie ma się czym chwalić w związku z tym stanowiskiem, ale może gdy pomyślicie dłużej przypomnicie sobie, że braliście udział w jakimś fajnym projekcie, który nauczył Was tego czy tamtego albo, że nie popełniacie już podobnych błędów jak parę lat temu.
Takie szukanie swoich dobrych stron i osiągnieć może być trudne, ale nie niemożliwe. Można również spróbować zapytać kolegów z którymi pracowaliśmy o ich wrażenia z pracy z nami, o wspomnienia z projektów. Oni na pewno postrzegali nas całkiem inaczej niż my sami siebie i być może przypomną nam o paru umiejętnościach czy osiągnięciach, na które my nawet nie zwróciliśmy uwagi albo zapomnieliśmy o nich, a którymi warto będzie się pochwalić w CV.
A gdy już CV będzie gotowe, czas na dalsze kroki.
Samo stworzenie dobrego CV to jeszcze nie wszystko. Teraz, abyśmy w ogóle trafili na jakaś rozmowę kwalifikacyjną musimy to CV wysłać do firm, których ogłoszenia nas interesują. Jeśli dokucza nam syndrom oszusta, to często już tutaj zaczynają się schody. Większość osób niepewnych swoich umiejętności, zobaczywszy w ofercie pracy chociaż jedną brakującą umiejętność, odrzuci w ogóle myśl o aplikowaniu. Tymczasem często firmy wcale nie oczekują, że spełnimy 100% wymagań – oczywiście im więcej tym lepiej, ale fakt, że nie znamy jakiegoś frameworka czy biblioteki nie musi oznaczać odrzucenia naszego CV na wstępie.
Nie mowię tutaj o aplikowaniu na stanowisko programisty Javy, jeśli tej Javy w ogóle nie umiemy, bo jednak jest to w tym przypadku bazowa umiejętność, którą trzeba posiadać. Ale w ogłoszeniu może być również napisane, że kandydat powinien znać bibliotekę X i narzędzie Y. To nie powinno nam przeszkadzać w aplikacji. Pozwólmy firmie na podstawie naszego CV zdecydować czy nasze umiejętności wystarczą czy nie.Dodatkowo, niektóre firmy umieszczają w ofertach pracy narzędzia lub frameworki, których pracując tam nawet nie zobaczysz (historia prawdziwa), ale są w danym momencie modne, więc by przyciągnąć kandydatów firmy nieco naciągają rzeczywistość;) To z kolei można już zweryfikować podczas rozmowy kwalifikacyjnej.
Udało się! Mimo małych braków w CV związanych z umiejętnościami wyszczególnionymi w ofercie pracy dostaliśmy zaproszenie na rozmowę kwalifikacyjną. W pierwszej chwili myślimy: „O rany, ale super!”, ale już w drugiej: „O rany, nie dam sobie rady! To musi być pomyłka, że chcą ze mną rozmawiać”. Co teraz? Co robić z taką niepewnością? Jak pójść na rozmowę z podniesioną głową?
Rozmowa kwalifikacyjna chyba dla każdego jest dużym stresem, więc obawy przed nią, to nic nadzwyczajnego – nie jesteśmy w tym odosobnieni. Otuchy powinno nam dodać to, że firma oceniła nasze kwalifikacje na podstawie CV i zdecydowała się z nami porozmawiać. To już znaczy bardzo dużo! Informacje, które zawarliśmy w naszej aplikacji, wystarczyły aby zainteresować ich naszą osobą.
Spróbujmy przez chwilę spojrzeć na nas ich oczami – widzą w nas specjalistę w danej dziedzinie odpowiedniego na dane stanowisko. Niech ten fakt doda nam odwagi! Dalej – pomyślmy o tej rozmowie nie jako o polu na którym niewątpliwie polegniemy, ale jako o miejscu, gdzie możemy w końcu się wykazać! Naszym doświadczeniem, wiedzą, umiejętnościami. To pozwoli nam stres obrócić w pozytywne uczucie podekscytowania nowym wyzwaniem.
Często rozmowy składają się nie tylko z części technicznej ale też tzw miękkiej. Warto być przygotowanym na obie te części.
W szczególności nie bójmy się zadawać pytań – o to co nas interesuje na temat firmy, o to jak się w niej pracuje, jaki będzie nasz zespół. Gdy czujemy się jak oszust, możemy się zadawania pytań nieco obawiać, ponieważ już na starcie czujemy się gorsi. Gdy z takim nastawieniem przychodzimy do firmy na rozmowę w naszej głowie jesteśmy jakby „poziom niżej” od naszego rozmówcy czy rozmówców. Tymczasem powinniśmy o sobie myśleć bardziej jako o partnerze dla danej firmy a nie jako o kimś gorszym. Wnosimy naszą wiedzę, doświadczenie i umiejętności. To bardzo duża wartość. Myślenie o sobie w takim kontekście doda nam nieco pewności siebie i sprawi, że na rozmowie wypadniemy zdecydowanie lepiej.
Zadawanie pytań może nam również bardzo pomóc na części technicznej – w szczególności jeśli jest to live coding. Zawsze, gdy czegoś nie rozumiemy, bądź mamy wątpliwości, powinniśmy dopytywać. Nie tylko wyjdzie to nam na dobre, ponieważ dzięki temu szybciej dojdziemy do odpowiedzi czy rozwiązania, jakich się od nas oczekuje, ale również pozwoli to rekruterom zobaczyć jak rozwiązujemy problemy. Często sam przebieg takiej rozmowy jest ważniejszy niż to czy udało nam się rozwiązać poprawnie dane zadanie.
Czując się jak oszust, możemy mieć duże opory przed zadawaniem pytań, żeby nie wyjść na głupich – obawiając się, że nasz wewnętrzny oszust zostanie zdemaskowany. Tymczasem jeśli ważnym kryterium na rozmowie jest również nasza komunikacja z rekruterami a my będziemy milczeć zamiast zapytać, na pewno sobie zaszkodzimy. Z powodu stresu może nam się ciężko myśleć i nie od razu wpadniemy na najlepsze rozwiązanie. Dobrze jest pamiętać o tym, że rekruterzy są świadomi tego, że rozmowa kwalifikacyjna jest czymś bardzo stresującym i jeśli tylko damy im szansę pomogą nam co nieco.
Niestety może się zdarzyć, że mimo iż stworzyliśmy CV z którego jesteśmy naprawdę zadowoleni, rozmowa kwalifikacyjna wydawała się pójść całkiem nieźle, ale mimo to nie zostaliśmy zaproszeni do współpracy. Czy to oznacza, że na niczym nie znamy, do niczego nie nadajemy? Oczywiście, że nie!
To może oznaczać, że firma zdecydowała się na innego kandydata – być może miał więcej pożądanych umiejętności. Zawsze będzie ktoś, kto umie coś czego my nie umiemy. Jak również my umiemy wiele rzeczy, których nie umie ktoś inny – o tym trzeba pamiętać, ale nie dręczyć się tym, że nie wiemy wszystkiego. Inny powód może być taki, że firma zmieniła plany co do rekrutacji, może nawet w międzyczasie zamknięto projekt – wiele rzeczy może się wydarzyć i wcale nie muszą być bezpośrednio związane z naszą osobą. Najważniejsze, byśmy jak najwięcej dla siebie z tego doświadczenia wyciągnęli.
Poprośmy firmę z którą rozmawialiśmy o jak najbardziej szczegółowy feedback z rozmowy. W ten sposób możemy dowiedzieć się, co zdecydowało, że nasza kandydatura została odrzucona. Mógł to być jakiś brak w wiedzy, który teraz możemy uzupełnić albo wspomniana przeze mnie niewystarczająca komunikacja. Będzie to dobry punkt startu do zdobycia nowych umięjętności i być może ponownego aplikowania do danej firmy. Sporo firm taki szczegółowy feedback przekazuje od razu.
Jednak jeśli nie uda nam się takiego uzyskać możemy zapisać sobie pytania i kwestie poruszane na rozmowie i zacząć pogłębiać wiedzę w tych właśnie tematach, co na pewno przyda nam się podczas rekrutacji do kolejnych firm.
Dostaliśmy tę pracę, ale zamiast się cieszyć obawiamy się, że gdy tylko zaczniemy pracę ,obowiązki nas przerosną a nasi współpracownicy odkryją, że się na to stanowisko nie nadajemy. Ale to tylko złudzenie! Spróbujmy pomyśleć o tym w ten sposób – firma do której aplikowaliśmy podjęła decyzję o zatrudnieniu nas bazując na naszym doświadczeniu i umiejętnościach, jakimi wykazaliśmy się podczas rozmowy kwalifikacyjnej. Zatem ta firma uważa, że się nadajemy! Nie ma żadnego powodu, żebyśmy my myśleli inaczej. Jeśli faktycznie czujemy, że pewne tematy potrzebne do nowej pracy powinniśmy zgłębić, to zróbmy to, ale na spokojnie – bez stresu i niepotrzebnych zmartień. W końcu teraz czas na świętowanie sukcesu!
Inne moje artykuły na temat syndromu oszusta znajdziecie tutaj:
https://programistka.com/syndrom-oszusta-czy-dotyczy-tez-ciebie/
https://programistka.com/syndrom-oszusta-typy/
Polecam również obejrzenie zapisu prezentacji z konferencji Segfault:
Artykuł, o którym wspominam na początku, a który mnie zainspirował do tego wpisu znajdziecie na portalu InterviewCake.
Jeśli w codziennej pracy piszecie coś w JavaScripcie zapewne jednym z podstawowych narzędzi jakich używacie do debuggowania jest właśnie console.log. Dlaczego więc chcę Was namówić do zmian? O tym już za chwilę.
Dziś chciałabym Wam polecić niedawno powstałe ścieżki edukacyjne na JetBrains Academy.
Format kursów jest podobny do innych platform. Wybieramy technologię (ścieżkę), której chcemy się nauczyć. Następnie mamy “Study plan” z listą kolejnych lekcji, a każda z lekcji składa się z wprowadzenia do tematu i ćwiczeń.
