Certifykat i study guide dla seniora C#/.NET

Programuję już kilka lat w C# głównie z ASP.NET i Azure Functions i spróbowałem się ostatnio w kilku rekrutacjach gdzie wymagane doświadczenie to 2-5 lat i okazuje się, że g**no umiem, za przeproszeniem. Z jakimiś algorytmicznymi problemami jak na SPOJ nie mam problemów, ale na wszystkich rozmowach pytają o zarządzanie pamięcią w .NET, wzorce projektowe i meandry językowe, X typów kolekcji - no wykładam się na wszystkich tych pytaniach.
Zasady pisania czystego kodu chyba znam, byłem w kilku zespołach i do moich pull requestów raczej nie było zastrzeżeń architektonicznych, ale jak ktoś mnie pyta o wymienienie wzorców to nie umiem. Czytałem o wszystkich od bandy czworga z 5 razy w życiu, ale nie mogę tego spamiętać. Zawsze wymieniam singleton, budowniczy, adapter i się blokuję. Podobnie z garbage collectorem i samym językiem C#. Poczytam i po tygodniu zapominam. Nie potrafię nigdy spamiętać nawet, która klasa ma Count, a która Length.

W związku z tym czy ktoś może polecić jakiś certyfikat + materiały, które trzeba ogarniać? Może w ten sposób uda mi się rozwinąć w zawodzie.

Może zrobię mały offtop, ale jak dla mnie problem nie leży w Tobie tylko w rekrutacjach. Tego typu rzeczy sprawdza się w momencie, kiedy są potrzebne. Nikt normalny nie spamiętuje tego na pamięć, bo zwyczajnie po co? Rekrutacje niestety polegają na odsiewaniu takimi pytaniami i zwyczajnie jak na takową idziesz to warto się tego nauczyć na pamięć na te 24h :P

Podobnie z garbage collectorem

To jest ogólnie absurd wielu miejsc, gdzie wymagają wiedzy której się na codzień nie używa. To samo dotyczy właśnie algorytmów. A od sytuacji wyjątkowych gdzie coś takiego trzeba sprawdzić jest Google lub wyspecjalizowana osoba. Jak mniemam masz pecha że trafiasz na właśnie takie miejsca- bo oczywiście sytuacja jest inna gdybyś aplikował do miejsca gdzie faktycznie algorytmy czy zarządzanie pamięcią/GC to codzienno

Całkiem niedawno u mnie w pracy definiowaliśmy na nowo pytania i zadania rekrutacyjne, i dobieraliśmy je tak aby odzwierciedlały to co faktycznie robimy jak i dawały szansę kandydatowi się wykazać. Oczywiście nadal są pytania czysto techniczne, tak aby sprawdzić czy kandydat który podaje że ma wiedzę i doświadczenie np. w ASP Core, faktycznie takie posiada i potrafi odpowiedzieć bez problemu na coś co każdy pracujący z ASP Core na codzień będzie wiedział.

Co do wiedzy o wzorcach projektowych czy architekturze- na poziomie seniora to jednak zagadnienia które należy znać, bo od seniora oczekuje się (zazwyczaj) że będzie mógł podejmować decyzje w takich tematach.

Typowy problem rozmów rekrutacyjnych. Jeżeli zadają takie pytania to zakładam, że hajs musi się zgadzać. Pytanie co Ty chcesz robić. Mnie do nauki (rzeczy których nawet na codzień nie używam) motywuje cytat z artykułu Konrada Kokosy

Level 3: Optimize and be really memory-aware like a crazy. Use advanced C# tricks, refs, Span, stackalloc. Get some internals knowledge. Sell your unique knowledge for serious money.

A to, ze pracodawca o taką wiedzę pytał, płaci za to chociaż tak naprawdę nie potrzebuje? Nie moja sprawa

Tempac0904 napisał(a):

...ale na wszystkich rozmowach pytają o zarządzanie pamięcią w .NET, wzorce projektowe i meandry językowe, X typów kolekcji - no wykładam się na wszystkich tych pytaniach... jak ktoś mnie pyta o wymienienie wzorców to nie umiem.

Właściwie to już wiesz na czym się wykładasz. Wykucie kilku podstawowych wzorców na pamięć to chyba nie powinien być problem. Podobnie z kolekcjami i pamięcią. Chyba że to były tylko przykładowe rzeczy i jest tego więcej.

Tempac0904 napisał(a):

Programuję już kilka lat w C#

I co Cię skłoniło do do zakładania wątku z pytaniem o porady dla seniora?

Zasady pisania czystego kodu chyba znam, byłem w kilku zespołach i do moich pull requestów raczej nie było zastrzeżeń architektonicznych

To na pewno o niczym dobrym nie świadczy. A możliwe, że jest wręcz przeciwnie, i świadczy o czymś bardzo nie tak.

ale jak ktoś mnie pyta o wymienienie wzorców to nie umiem. Czytałem o wszystkich od bandy czworga z 5 razy w życiu, ale nie mogę tego spamiętać.

Też bym nie umiał. Umiem tylko te, których używam.
O reszcie co najwyżej wiem, że istnieją, ale pewnie też nie umiałbym wymienić nawet nazw wszystkich z pamięci.

W związku z tym czy ktoś może polecić jakiś certyfikat + materiały, które trzeba ogarniać? Może w ten sposób uda mi się rozwinąć w zawodzie.

W zawodzie programisty trzeba umieć programować, to nie jest kwestia certyfikatów ani materiałów.

Skoro wylatuje Ci po tygodniu to radzę zrobić sobię A4 ściągawkę którą przeczytasz tuż przed interview.

Co do wzorców polecam wkuć na pamięć następujące (a najlepiej to napisz o nich artykuł i wystaw jako Github Gist - w ten sposób lepiej zapamiętasz):

• Strategia
• Dekorator (wraz z Adapterem i czym się różnią)
• Builder/Budowniczy jest OK
• Fabryka (tak najprostszy chyba wzorzec)

Generalnie te pojawiają się bardzo często w praktyce, jak ktoś pyta o jakiś tam Bridge to znaczy że albo ktoś odjechał albo coś tu jest nie tak (np. próba zbicia stawki).

Co do GC, jak już mówiłem każdy powinien wiedzieć jak działa - tj. podstawy typu śledzenie referencji i to że program się wtedy zatrzymuje. Trzeba wiedzieć że to co wpiszę sie do zmiennych statycznych nie zostanie automatycznie usunięte, warto też wiedzieć o destruktorach w C# (teraz finalizery) i że ich wywołanie nie jest deterministyczne. Warto też mieć obraz o tym jak działa generacyjny mark & sweep ale to już dla seniora. W javie taka wiedza jest bardziej powszechna bo tam trzeba często kręcić wajchami od GC.

Kolekcje, to co każdy musi wiedzieć poza poziomem Juniorskim (abstrahując od języka):

• Tablica vs Lista vs Mapa vs Zbiór vs Sterta (Heap)
• Hash-based vs Tree-based
• Szybkość działania powyższych np. Lista bazująca na rosnącej tablicy, zamortyzowany czas dodawania elementu to O(1)
• Kontrakt dla HashCode i Equals dla powyższych vs kontrakt dla Tree-based structures (IComparable)

Count vs Lenght - ktoś o to pyta? Co za cep!

Powyższe Design Patterns + GC + Struktury Danych zmiejści się na A4, przeczytaj sobie w drodze na interview i nie powinieneś mieć kłopotów z odpowiedzią. Na moje oko za dużo spędzasz czasu na więdzę ogólną (np. GoF) a za mało na konkrętną technologię (C#).

jak ja to dobrze rozumiem
super, hiper, mega korpy gdzie najtrudniejszym etapem jest rozmowa kwalifikacyjna, potem w pracy niby - badzcie innowacyjni - a kończy się i tak robota w legacy

kiedyś przeszedłem rozmowę z c#, byla dość ciężka, dotykała np niuansow programownaia współbieżnego.
potem w pracy miałem okazję raz napisać parallel foreach i raz when all
i tak to rzeczywistość miała się do rozmowy
przygotowałem się do niej, ale nic dziwnego, że wiedza nieuzywana to paruje jak kamfora

wielu rozmów nie przechodziłem, bo byłem zbyt szczery - i potem odmowa, bo nie mam doświadczenia komercyjnego w tym czy w tamtym
np doker - potem w pracy gdy przyszła dokeryzacja to parę dni, parę rozwiązanych problemów i już jakoś sobie radziłem (nie uważam siebie na mistrza dokera). Chodzi o to, ze jak ktoś robi w branży parę lat to narzędzie ogarnie.

ale to nie tylko w programowaniu tak jest
kolega co ma znajomych w świecie medycznym to mówi, że nie ma nic gorszego niż 40-letni dobrze zapowiadający się chirurg. On ma znajomych co np wyjechali z Krakowa do Zakopanego, bo w Krakowie by się nigdy nie przebili, bo profesor jest jeden i nie każdego weźmie na asystenta przy operacjach.

Sam mam z tym problem i to spory. Uwazam to za bolączkę tej branży, ciężko się rozwijać technicznie, wymagania bywają kosmiczne, a praca potem co najwyżej ociera się o te wymagania i wiele ważniejsze jest rozumienie biznesu niż niuanse technologiczne
Ale najgorsze jest to, że potem, nawet w korpie, przychodzi ciekawsza robota to jest - kto to będzie robił, on nie bo on w legacy siedzi to nie będzie się znał na nowościach, zbyt male visibility (mnie to osobiście spotkało po 1,5 roku siedzenia w maintenece, gdy miałem nadzieję że wreszcie się wygrzebię i było impulsem do zmiany pracy)

W życiu trzeba mieć trochę szczęścia i pewną dozę bezczelności, bo bez tego to będzie się człowiek bujał, spychany w dziurę