Mock Interview #2: Mati 'Mid' vs Mateusz 'Junior' i straż pożarna

Białko banan śmietana. Tak, banan ŚMIETANA.

Ostatnio jak zamawiałem swoje białko, zobaczyłem, że oprócz truskawki i tego, co biorę zawsze, jest trzeci smak do wyboru.

BANAN ŚMIETANA - przecież to się musi zajebiście komponować. Jak te mniejsze komponenty (których nie było) tworzące ten komponent z code review Matiego.

No ale wracając do konkretów - dla mnie to była ciekawa kompozycja, dopóki nie pochwaliłem się KURWA KAŻDEMU DOOKOŁA i KURWA KAŻDY DOOKOŁA stwierdził:

“weź Ty sie puknij w łeb, gdzie śmietana”.

Było nawet takie przysłowie nie? Żeby nie mówić o swoich planach coś tam, coś tam…

Grunt, że mi to mega smakuje i polecam.

A co to ma wspólnego z Mock Interview Mateusza?

Nic.

To jest opening. Nie musi.

Dobra, Mati

To kolejne Mock Interview, kolejne emocje jak na grzybach i kolejny kandydat - znowu React’owiec. I to taki React’owiec, że jak przedstawiłem mu listę plusów Angulara:

lista plusów Angulara:

Nie no, na poważnie - przedstawiłem mu plusy Angulara, a on mówi:

tak tak, ale ja jednak wolę Reacta

No i ja szanuję takie decyzje.

Natomiast wyłącznie decyzje - Reacta dalej nie.

Na „Poznajmy Się“ opowiedział mi o kuli 3D, która reaguje na muzykę.

Mega ciekawy projekt. Aż mi się łezka w oku zakręciła, bo przypomniał mi o Windows Media Player.

Ale projekt jest naprawdę fajny. Mati potrafił wejść głębiej w amplitudę, częstotliwość i sposób, w jaki dźwięk wpływa na animację. I już tutaj pojawiła się rzecz, która wracała przez całą rozmowę:

Kiedy dostaje konkretny problem, potrafi sensownie myśleć i dobrze tłumaczyć swój tok rozumowania.

Nawet po angielsku. Tylko czasami zatrzymywał się, żeby znaleźć idealne słowo.

Nie ma po co. W komercyjnym IT naprawdę rzadko wygrywa człowiek, który zna słowo „notwithstanding“.

Najważniejsze, żeby druga osoba wiedziała, że:

production dead

Blok sytuacyjny: Kolega ma inne zdanie. Niestety ma też argumenty

Pytam:

Co robisz, kiedy Ty ograłbyś feature inaczej niż kolega z zespołu, ale on upiera się przy swoim rozwiązaniu?

M:

a co cie to obchodzi

Niee no, nie było tak. Było tak, że Mati mówi, że chce poznać rozwiązanie kolegi z zespołu i porównać wtedy oba.

No ale potem to mnie zaskoczył, bo zaczął mówić językiem argumentów mierzalnych, czego bardzo często nie można uświadczyć nawet u seniorów. (bo nie żyją)

W sensie u senior developerów.

  • złożoność,
  • pamięć,
  • koszt utrzymania,
  • wpływ decyzji na przyszłość (to już mniej mierzalne, chyba, że w litrach łez / środowisko)

I to jest dokładnie dobra odpowiedź.

Nie „bo wydaje mi się czyściej“. Nie „bo tak się teraz robi“. Nie „bo widziałem shorta, w którym gość miał mikrofon na widelcu“.

Tylko: mamy dwa rozwiązania, porównajmy ich koszt i wybierzmy świadomie.

Klasa.

TypeScript, bo wszyscy używają

Przechodzimy do bloku technicznego. (nie, nie wrzucę tu żartu, że niby blok techniczny… no dobra - biały, A4, 10 kartek)

Dlaczego używasz TypeScripta? Jaki konkretnie problem Ci rozwiązuje?

Pierwsza odpowiedź Mateusza:

Wszyscy z tego korzystają.

No i świetnie. Wszyscy też akceptują regulaminy bez czytania.

Ale dalej było już fajnie. Wrócił Mati i wskazał typowanie i dobrze rozróżnił compile time od runtime. Wiedział, że typ zadeklarowany w TypeScripcie nie sprawi magicznie, że API przestanie wysyłać śmieci.

Gdyby backendowiec usłyszał, że API wysyła śmieci - to by sie pewnie zapluł i zaczął coś pewnie dukać z piwnicy, że frontaś, że haha javascript 

var null = 0

(nieoczekiwany wjazd na backendowców)

Do feedbacku dorzuciłem runtime validation i Zoda, bo Mati był ciekawy jak mu powiedziałem.

Ja chyba zapytam czy Zod nie chciałby, żebym Zodstał ich ambasadorem. (przestawiony szyk zdania na półczytelny, ale żart też 2/10. Ciekawe, że to tak działa)

Testy: tutaj trzeba usiąść

Pytam:

Jak i co testujesz testami jednostkowymi? Czego nie testujesz unitami?

I tutaj wyszła największa techniczna luka Mateusza. (“Mati” to jak jest dobrze, jak jest źle to oficjalnie - “Mateusz”)

Kojarzy biblioteki, ale miesza poziomy testów.

Przykłady w stylu

czy coś znajduje się na stronie

nie odpowiedziały na najważniejsze pytanie:

Jaką wartość daje ten test?

Mega plus, że Mati nie udaje, że wie. Jak nie wie - to mówi, że nie wie - i to naprawdę mocno cenimy.

Natomiast sama szczerość testów nie napisze.

Dlatego rekomendacja była konkretna: wziąć własny projekt i go przetestować.

M:

ale jak?

Ja:

no przecież jest Jest

Nie no, nie było tak.


Ale teraz już jest. (sorry, musiałem)


Rekomendacja wskazywała na konkretne rodzaje testów, które należy zawrzeć w ramach testowania własnego projektu. Zostały również zaproponowane konkretne technologie.

Biblioteka czy własne osiem linii kodu?

100 zł grzywny albo 25 lat pozbawienia wolności.

Pytam:

Masz prostą funkcjonalność, dla której istnieje dedykowana biblioteka, ale wykorzystasz z niej jedno API. Co robisz?

Tutaj Mati odpowiedział bardzo sensownie.

  • Z jednej strony nie warto wymyślać koła na nowo.
  • Z drugiej - wszystko zależy od skali problemu i od tego, ile kosztuje wpuszczenie biblioteki do projektu.

Była kontrola nad własnym rozwiązaniem. Było ryzyko zainfekowanych zależności. Duży plus za security.

Do pełnej checklisty dorzuciłem:

  • “ile to będzie ważyć w bundlu”,
  • kwestie licencji,
  • zależności pośrednie,
  • koszt późniejszego usunięcia biblioteki.

Robisz npm install i instalujesz backendowców.

(drugi nieoczekiwany wjazd na backendowców)

AI pisze. Mati nadzoruje

Mati powiedział wcześniej ciekawą rzecz: podczas pracy z AI nie tyle pisze kod, co go nadzoruje.

Więc oczywiście zapytałem:

Widzew czy ŁKS

Nie no dobra…

Zapytałem:

A jak wygląda taki proces nadzoru u Ciebie?

I tutaj odpowiedź rozczarowałaby wegan:

(bo było samo mięso, ha)
  • dokładne rozpisanie funkcjonalności
  • podział na milestone’y
  • polecenie agentowi, żeby dopytywał
  • ręczne sprawdzanie kodu
  • pilnowanie przejść między etapami, bo wtedy wcześniejsze decyzje lubią nagle przestać się ze sobą zgadzać

I to jest bardzo fajny kierunek.

Dopisałem, że jeszcze można:

  • review diffu
  • testy
  • security
  • zgodność z istniejącą architekturą

Ale naprawdę klasa.

Próbowałem przeciągnąć go na Angulara

Dlaczego React? Nie wolałbyś może gotowego zestawu rozwiązań, jaki oferuje Angular?

Mateusz powiedział, że od Reacta zaczął, a Mati uzasadnił, że ceni kontrolę, którą dostaje.

Podpuszczałem go trochę celowo i udało się wydobyć mega wartościową rzecz.

Mati nie zmienił zdania mimo, że zasypałem go plusami Angulara.

To trochę jak z pokazem garnków - oni zawsze mówią, że:

będzie fajnie, że garnki za free, że poczęstunek.

A Ty zawsze, że:

fajnie fajnie, ale dziękuję.

I tak samo było tutaj. I dodatkowo Mati rozumiał doskonale trade-off. Pięknie.

User mówi, że lista jest wolna. I tyle, jak to user

Mateusz od razu zaproponował paginację i indeksy w bazie.

Kiedyś to były czasy. Na studiach też były indeksy i pierwsze pół sesji zajmowały zaliczenia, a drugie pół sesji - latanie za prowadzącymi, żeby wpisali Ci to zaliczenie do indeksu.

Tylko jeszcze nie wiemy, czy problemem jest baza.

  • Może API odpowiada 2 minuty
  • Może frontend próbuje wyrenderować dziesięć tysięcy elementów na raz
  • Może backendowiec właśnie traci czas, uważając, że jest wartościowy i ktoś przejmuje się jego pracą, zamiast zoptymalizować zapytanie do bazy (trzeci nieoczekiwany wjazd na backendowców)

I to jest jeden z ważniejszych wniosków dla Mateusza: nie zaczynać od rozwiązania bez pełnego zrozumienia problemu.

998 linii kodu - wygląda jak pożar (hehe)

Przechodzimy do code review projektu Matiego.

Ale pytam Mateusza:

Dlaczego ConfiguratorComponent ma aż 998 linii? Wygląda jak pożar (hehe)

Pierwsza reakcja Mateusza:

To jest dobre pytanie.

Wiem. Przygotowałem je wcześniej.


Mati szybko zauważył, że helpery, formatowanie, typy i konfiguracja nie powinny siedzieć w jednym komponencie.

Mati zauważył, ale Mateusza trzeba było naprowadzić na rozdzielenie widoku od logiki i podziału całości na mniejsze komponenty. Potem pojawiła się kompozycja i sensowny kierunek refactoru.

I tutaj wracamy do początku.

Białko Banan ŚMIETANA.

Tak, bo różne rzeczy można komponować i to naprawdę może smakować.

Mateusz nie zauważył pierwszego błędu, ale Mati wiedział, że trzeba go naprawić

W komponencie po ustawieniu błędu nigdzie nie było setError(null).

Zapytałem:

Czy ten błąd zostanie z nami na zawsze?

Mateusz tego nie rozpoznał. Ale Mati wiedział, że trzeba znaleźć miejsce, w którym stan wraca do poprawnej wartości, ale takiego miejsca w kodzie po prostu nie było.

I to jest dobry temat do przećwiczenia: lifecycle stanu loading / success / error, czyszczenie błędu po ponowieniu akcji albo po sukcesie i ogólnie state management.

Oczywiście wskazówki w feedbacku, klasycznie.

Za chwilę pokazałem warunek w cenowanie.ts (celowo anonimizuję projekt):

if (quantity > config.minQuantity)

(Chodziło o naliczenie rabatu jak użytkownik kupi dużo sztuk.)

“potrzebne informacje”

I zapytałem, czy rabat nie nalicza się o jedną sztukę za późno.

Tutaj Mati bardzo szybko złapał błąd graniczny i zaproponował >=. Dobrze też zaznaczył, że ostatecznie decyduje wymaganie biznesowe, bo może firma naprawdę nienawidzi klienta kupującego dokładnie dziesięć sztuk.

Idealne miejsce na prosty unit test.

Gdybyśmy jakieś mieli.

AddToCart pilnuje ładowania. QuickAddToCart ma wyjebane.

Ostatni ciekawy fragment code review:

  • AddToCart sprawdza czyCosSieLaduje,
  • QuickAddToCart już nie.

Mati dobrze zauważył zagrożenie: podczas ładowania cena może być jeszcze nieznana albo niepoprawna, a jeden wariant feature’a pozwala już dodać produkt.

Potem zaproponował wspólną funkcję sprawdzającą warunki i rozpoznał DRY.

Fajnie.

Natomiast jeszcze ważniejszym elementem jest spójność wymagań.

Bo:

  • Użytkownika nie interesuje, że QuickAddToCart jest innym komponentem.
  • Użytkownika nie interesuje, że wyszedł Angular 23
  • Użytkownika nie interesuje nawet programista i jego leasing

Tylko:

  • Użytkownik chce kupić produkt.
  • Najlepiej z rabatem naliczonym od konkretnej sztuki.

Gupi klient.

Mati “Mid” vs Mateusz “Junior”

Mati trochę jak Wojtek Sokół:

“jeszcze nie zgred, już nie małolat”

W sensie Mati:

“jeszcze nie mid, już nie junior”

Bo było bardzo dużo midowych sygnałów.

A już najlepiej Mati wypada, kiedy dostaje:

  • konkretny kod,
  • prawdziwy błąd,
  • sytuację zespołową,
  • decyzję z trade-offami.

Przy pytaniach ogólnych odpowiedzi były mniej uporządkowane. Największe luki Mateusza to:

  • testy,
  • pełny flow auth,
  • performance zaczynający się od pomiaru,
  • state management,

I to jest klasa - jest mega solidnie i jest też co poprawiać.

Masz z czym iść dalej stary.

Podsumowując

Mati dostał potwierdzenie swoich mocnych stron. Mateusz dostał listę rzeczy do domknięcia.

Razem dostali 10 stron konkretnego feedbacku.

Ja natomiast zainspirowany faktem, że Mati nie zmienił zdania na temat Reacta:

Również nie zmieniam zdania - to białko BANAN ŚMIETANA jest cudowne

No matter what you say dookoła.

Chcesz, żebym Ciebie też tak przepytał? Umów Mock Interview.