Podajcie jakie umiejętności warto mieć, aby dobrze wypaść na rekrutacji. Mam na myśli takie, których nie znajdę w oklepanym spisie 100 .NET interview questions. Przykłady jakichś zadań, które realizowaliście w pracy na poziome mida lub takie umiejętności lub zadania, które mało kto potrafi, a dobre firmy tego wymagają i zapunktuję jeśli będę wiedział.
0
4
Nie wiem, czy to powinno być w tym dziale, bo to jakby niezależne od technologii (chyba, że chodzi ci o umiejętności typowo pod C#, .NET).
Poza tym pytasz o umiejętności juniora/mida (w pracy) czy tylko na rekrutacji? Bo to dwie różne rzeczy.
W pracy jak chcesz być dobrym juniorem/midem to:
- nadkomunikacja - czyli warto pytać innych, zgłaszać problemy, jakie masz w pracy itp. ogólnie wychodzić z inicjatywą komunikacyjną, a nie czekać, aż ktoś cię o coś spyta (np. czemu ci task nie idzie).
- robienie notatek, organizacja własnej pracy na poziomie indywidualnym (bo na poziomie zespołowej masz sprinty, taski itp. ale na poziomie indywidualnym po prostu jesteś ty i komputer i też potrzebujesz to ogarnąć).
- interesowanie się szerszym kontekstem niż tylko twój aktualny task - to co inni programiści robią, to czego biznes chce itp.
A na rekrutacji to ciężko powiedzieć, ale pewnie mocna gadka i pewność siebie i swoich umiejętności.
2
potrafienie zdeployować swój produkt (np. web app)? :P
1
Nieoczywista umiejętność to umiejętność zaprojektowania w miarę sensownej architektury (np. zależności pomiędzy modułami w ramach aplikacji, nie trzeba od razu wchodzić na poziom enterprise architecture), a nie spaghetti :)
0
Juniora od Seniora odróżnia przede wszystkim doświadczenie i umiejętność odnalezienia się w konkretnych sytuacjach. Przygotuj sobie przed rozmową swoje indywidualne osiągnięcia oraz przykłady na bycie dobrym członkiem zespołu. Skup się na tym jakie cele osiągnął zespół dzięki Twoim akcjom.
0
Chodzi mi bardziej o konkretne przykłady taksów w pracy którymi można się pochwalić. Na kilku rozmowach padało pytanie podaj przykład zadania które zrealizowałeś w projekcie z którego jesteś dumny. Ja powiedziałem, że zrobiłem endpointa do API i napisałem testy jednostkowe, wdrożyłem na proda. Czy takie zadanie jest imponujące? Nie wydaje mi się żeby na kimś zrobiło wrażenie, a w ciągu 2 lat pracy mam podobnego typu taski i jestem ciekaw co inne osoby odpowiadają na to pytanie.
0
Coś przydatnego, co działa i jest używane. Biblioteka do api? Dodatkowy moduł do systemu napisanego w danym języku? Prosta aplikacja?
0
kamyk77 napisał(a):
Chodzi mi bardziej o konkretne przykłady taksów w pracy którymi można się pochwalić. Na kilku rozmowach padało pytanie podaj przykład zadania które zrealizowałeś w projekcie z którego jesteś dumny. Ja powiedziałem, że zrobiłem endpointa do API i napisałem testy jednostkowe, wdrożyłem na proda. Czy takie zadanie jest imponujące? Nie wydaje mi się żeby na kimś zrobiło wrażenie, a w ciągu 2 lat pracy mam podobnego typu taski i jestem ciekaw co inne osoby odpowiadają na to pytanie.
Nigdy nie napotkałeś na jakieś nietrywialne problemy podczas pisania jakiegoś endpointa? Albo nie naprawiałeś jakiegoś nieoczywistego buga?
Bo to o takie rzeczy chodzi - nie typową robotę, gdy wszystko idzie gładko, tylko jakieś wyzwania, z którymi sobie poradziłeś.
1
Możesz pochwalić się optymalizacją
np. tym, że namierzyłeś wiele miejsc gdzie ktoś błędnie wczytuje dane do pamięci ToList() wciągając całą tabelkę i robi na tym zbiorze .FirstOrDefault()
Możesz pochwalić się ułatwieniem,
np. wiele osób wielokrotnie robiło to samo na piechotę a Ty dorzuciłeś jakiś skrypt do pipeline'u i już tego nikt nie musi robić ani sekundy dłużej
Możesz pochwalić się dobrą komunikacją
np. często klient bierze pod uwagę Twoje zdanie gdy mówisz "zróbmy to prościej lub taniej, np. tak i tak" lub zadajesz analityczne pytania dzięki czemu nie implementujecie czegoś co się nie uda zaimplementować bo w którymś momencie natrafisz na nierozstrzygniętego ifa
Możesz pochwalić się jakimś "frameworkiem"
np. w Twojej aplikacji trzeba było zaimplementować moduł audytowy i zrobiłeś do tego bebechy, dzięki czemu każda nowa encja w sposób pół-automatyczny Tworzy sensowną historię edycji użytkownika
Jak wyżej, możesz pochwalić się tym, że znalazłeś nieoczywistego buga, bo zauważyłeś że ktoś zamiast skopiować obiekt to przepisał referencję przez co magicznie rzeczy zmieniały się w dwóch miejscach a powinny w jednym :)