[m.....s]

#praca #humorinformatykow #programowanie #kalkazreddita #pracait #pracbaza #programista15k

To jestem ja gdy widzę wymagania o znajomościach technologii w ogłoszeniach o pracę i gdy czytam przykładowe pytania jakie padają na rozmowach dotyczące tych wymagań. Samemu pracując na prastarych technologiach.

[ajentidzej]

@matwes: może to dobry moment na zmianę pracy ( ͡° ͜ʖ ͡°)

[m.....s]

@ajentidzej: intensywna powtórka in progress, od września zaczynam chodzenie na rozmowy

[DarkGL]

@matwes: https://pl.wikipedia.org/wiki/Efekt_Dunninga-Krugera

[ajentidzej]

@matwes: bardzo dobrze, trzeba iść z technologiami do przodu i przy okazji nie można psuć rynku niskimi stawkami

[m.....s]

@ajentidzej: no, jakieś 3 lata mam do nadrobienia, może same podstawy zdążę przerobić by chociaż wiedzieć "co to jest" jak się mnie spytają ( ͡° ͜ʖ ͡°)

[motokate]

@matwes: Im dłużej pracuję, tym bardziej myślę, że ważniejsze jest wiedzieć, czego nie robić, niż znać to czy tamto. Konkretnych technologii czy rozwiązań zawsze można się szybko douczyć (lub wygooglać), a dowiedzieć się, jak NIE pisać kodu, można tylko poprzez doświadczenie.

[ajentidzej]

@motokate: cenne spostrzeżenie. Just-in-time learning jeżeli chodzi o technologie, ale oczywiście też warto z grubsza zapoznać się co dana biblioteka/framework ma do zaoferowania. Potem zauważa się że to wszystko jest bardzo podobne, są wykorzystywane podobne wzorce, podejścia, konwencje, więc dużo łatwiej się potem skacze z takiego np. Springa na micronauta.
Zamiast więc tracić czas na pisanie kolejnego hello world w super nowym fancy frameworku to lepiej poczytać jak pisać dobry

[p.....k]

intensywna powtórka in progress, od września zaczynam chodzenie na rozmowy

@matwes: z doświadczenia powiem, że lepiej iść na rozmowę i zobaczyć czego się nie umie - uczenie się technologii i frameworków w ciemno nie ma większego sensu - zwłaszcza, że na rozmowie i tak zazwyczaj się okazuje, że wystarczy znać ogólny koncept, a najistotniejsza i tak jest wiedza core'owa (szczególnie na stanowiskach seniorskich)

[m.....s]

a najistotniejsza i tak jest wiedza core'owa

@powaznyczlowiek: właśnie to najbardziej sobie powtarzam jeśli chodzi o język w którym programuję. Sztuczki, kruczki, pułapki, wyjątki od wyjątków, aby nie zrobić wielkich oczu jak dostanie się kawałek kodu do analizy z pytaniem "co byś tu zmienił, co Ci tu nie gra?". Jestem po lekturze "Czystego kodu" i trochę mi ta książka łeb zryła jeśli chodzi o styl pisania.

@motokate: co

[p.....k]

@matwes: no to jeśli jeszcze coś mogę polecić to poświęć trochę czasu na wzorce projektowe, SOLID itp :)

[m.....s]

poświęć trochę czasu na wzorce projektowe, SOLID itp

@powaznyczlowiek: poleciłbyś jakąś literaturę z tego? Mam w swojej wirtualnej biblioteczce "Czystą architekturę".

[p.....k]

@matwes: clean code i clean architecture to już klasyki - miałem kiedyś nawet rozmowę, na której gość wprost mnie zapytał kiedy ostatnio czytałem Czysty Kod ( ͡° ͜ʖ ͡°) także na pewno warto przeczytać - zresztą, to dobre tytuły

Polecam też Domain Driver Design Evansa żeby trochę się otworzyć na inne podejście, Head First Design Patterns (chociaż tu można i Wikipedię przewertować) - dodatkowo jeśli siedzisz

[Khaine]

@matwes: Ja jeszcze 10 lat nie siedzę co prawda w zawodzie, ale już teraz zauważyłem, że praktycznie nie ma żadnego sensu się uczyć niczego jeśli nie masz czegoś konkretnego do zrobienia xD Jeszcze mi się nie zdarzyło, żebym potem przyszedł do jakiejś roboty a tam się nie okazuje, że oni robią inaczej i musisz się oduczać tego jak wcześniej się uczyłeś. Było tak jak dotąd za każdym j-----m razem, w

[Khaine]

Im dłużej pracuję, tym bardziej myślę, że ważniejsze jest wiedzieć, czego nie robić, niż znać to czy tamto. Konkretnych technologii czy rozwiązań zawsze można się szybko douczyć (lub wygooglać), a dowiedzieć się, jak NIE pisać kodu, można tylko poprzez doświadczenie.

@motokate: O to to. Doświadczenie daje przede wszystkim ogląd i myślenie strategiczne. Naoglądałem się c-------h projektów i c-------o kodu, i to są tak naprawdę głównie rzeczy które definiują moje doświadczenie.

[m.....s]

@Khaine: co nie zmienia faktu, że można 10 lat przesiedzieć na dupie i się nie rozwijać w ogóle (a co za tym idzie jeżeli firma w której się pracowało upadnie, a Ty masz z tego powodu marne szanse by gdziekolwiek się załapać, musiałbyś praktycznie od juniora startować bo tak wszystko do przodu poszło), a następnie na pierwszej lepszej rozmowie zostać zagiętym na najprostszym pytaniu.

Żadna zdrowo myśląca firma nie przyjmie

[Khaine]

(a co za tym idzie jeżeli firma w której się pracowało upadnie, a Ty masz z tego powodu marne szanse by gdziekolwiek się załapać, musiałbyś praktycznie od juniora startować bo tak wszystko do przodu poszło)

@matwes: Miałem w pierwszej firmie takich ludzi którzy byli właściwie zakładnikami już tej firmy. W tej firmie byli na poziomie kierowników projektów i lead programmerów, poza nią max szeregowy regular - bo w takich technologiach

[m.....s]

Aczkolwiek takich technicznych testów na z---a od pewnego czasu już nie miałem w sumie - na juniorze to mnie trzepali z uporem maniaka, potem już coraz mniej. Bardziej mnie zawsze wypytywali co robiłem, jakie były problemy, jak je rozwiązywałem.

@Khaine: jak się próbowałem wbić gdzieś nie mając zupełnie doświadczenia to też tak miałem. Maglowanie do upadłego przez leada, który z każdym kolejnym pytaniem nakręcał się jeszcze bardziej. Tak samo jak

[Khaine]

@matwes: Od pewnego poziomu doświadczenia już nie sprawdzają czy jesteś intelektualnie zdolny do poradzenia sobie z zadaniem, bo skoro przez np. 3+ lata siedzisz w zawodzie i nie masz w CV historii zmian firm co 3 miesiące jak ci się kończył okres próbny albo nawet częściej, to znaczy że radę sobie już dajesz - pytanie raczej czy pasujesz do zespołu i jakie masz podejście do radzenia sobie z zadaniami.

[damer135]

@Khaine: aż mam ochotę wkleić ss na grupę z jr, mogę xd?

[Khaine]

@damer135: Nawet jakbyś to zrobił, to bym o tym nie wiedział xD