Wzrost wymagań wobec juniora na przestrzeni lat.

0

Jak w temacie, chodzi o front end. Czy nie uważacie, że wymagania względem juniora podskoczyły na przestrzeni lat? Byłem ostatnio na meetupie, pogadałem z doświadczonymi osobami na temat pierwszej pracy i większość się zgadza. Jeszcze jakieś 6 lat temu popularny był "programista jQuery". Wystarczyło znać jako tako HTML, CSS do tego jQuery na niezbyt wygórowanym poziomie. Dorzucić do tego umiejętność cięcia psdków i bez problemu można było znaleźć swoją pierwszą pracę. A dzisiaj? Bez znajomości chociaż pobieżnej jakiegoś frameworka ciężko o prace. AngularJS/Backbone/Ember/React, znajomość jakiegoś tusk runnera (gulp, grunt, webpack), coraz częściej wymagana umiejętność testowania kodu (mocha, chai, karma). Może ktoś doświadczony w rekrutowaniu podzieli się swoją opinią.

0
  1. Webpack to nie task runner
  2. React to nie framework
0

Jeśli nie zauważyłeś różnicy między stronami 6 lat temu a dziś, rzuć to i wyjedź w Bieszczady. Frontend poszedł baaaaaaaaardzo do przodu na przestrzeni ostatnich lat więc samo jquery nie wystarcza. Teraz coraz częściej spotyka się zwykłą stronę wizytówkową pisaną w angularze czy jakimś innym frameworku. Czy to dobrze czy to źle nie w tym wątku oceniać. Można to porównać do restauracji.
Jesteś kucharzem który umie zrobić dania typowo polskie (jakiś schabowy, mielone itp). I idziesz do pracy w restauracji która serwuje tylko i wyłącznie owoce morza. Czy przyda im się ktoś kto umie zrobić pysznego schabowego? No raczej nie.

1

Nie tylko we front-endzie, w calym IT poszlo mocno do przodu. Jak ja zaczynalem prace w testowaniu to sie cieszyli jak tester odroznial fora od while. Teraz norma jest pair-programming w lepszych firmach, ewentualnie codility, pozniej kilkanascie pytan z programowania, sieci i baz danych, dopiero na koncu kogos interesuje testowanie. Problemy sa co raz bardziej zlozone, zmiany musza byc co raz szybsze, do tego dochodzi 'boom' na bycie programista co skutkuje duza iloscia ludzi chetnych do zdobycia pierwszych doswiadczen zawodowych.

Na moje oko sytuacja bedzie widoczna co raz bardziej.

0

W PHP to samo, kiedyś jak umiałes coś tam programować to starczało, dziś jak nie znasz jednego z popularniejszych frameworków jak symfony, zend, yii tominus dla ciebie.. bo wszędzie praktycznie jest ich znajomosć w adnotacji mile widziane.. a wiadomo, że jak coś jest mile widziane to masz plus.

2

Ale janusze zawsze szukają seniora w cenie juniora więc wiadomo, że skille wypisują solidne :)

4

Wpisywanie dziesiątek buzzwordów w ogłoszeniach jest domeną Janusz-softów. Im więcej różnych frameworków i bibliotek wymienionych w ogłoszeniu, tym bardziej mówi to o firmie "nie będziemy Cie szkolić, szukamy wyrobnika, który od pierwszego dnia będzie skutecznie klepał formatki, a jak się framework zmieni, to Cię zastąpimy innym programistą".

Popatrzcie sobie na ogłoszenia od Google, Apple, IBM, Microsoft, Oracle, DataStax. Najczęściej jest tylko określona ogólnie technologia.

1

No i dobrze, że poziom idzie do góry. Być może nadejdą czasy w których znowu nie będzie to taki mainstream jak obecnie.

4

coraz częściej wymagana umiejętność testowania kodu

Skandal. Wymagają testowania. Pewnie złośliwi klienci chcą działającego kodu.

Poszedł do przodu, a na końcu i tak masz zwykłą stronę internetową, a nie rakietę kosmiczną. Spora część tych rozwiązań, to przerost formy nad treścią.

Myślę, że stronka wizytówka w Angularze, React'u czy czymś podobnym to jest bardzo dobre rozwiązanie. Reacta czy coś podobnego i tak trzeba dzisiaj znać, a stronki szybko się robi w czymś co się już zna. Inny argument jest taki, że w React'u można klepnąć SPA oparte na statycznym kodzie - bez serwera PHP czy jakiegokolwiek innego. Samo podawanie statycznych plików wystarczy do wizytówki zrobionej jako SPA. Można by też wizytówkę zrobić statycznie i bez Reacta, ale co wtedy zostaje, samo jQuery?

To nie jest tak, że programista przed zrobieniem każdej kolejnej strony wizytówki uczy się technologii od nowa. On już zna pewne i może je wykorzystać. Nie widzę sensu w wybieraniu najlżejszego narzędzia do danego zadania - lepiej wybrać takie rozwiązania, by długofalowa wydajność pracy wzrosła, a efekty były zadowalające.

0

Moim zdaniem to nic nie poszło do przodu, tylko dawniej się używało innych rzeczy.
A że angular jest nieco bardziej złożony od jquery, to już niektórzy widzą wielki problem.
Natomiast poziom kandydatów do góry raczej nie idzie, bo jak nieraz chodzę na rozmowy rekrutacyjne jako rekruter, to czasem idzie się tylko złapać za głowę.

1

Tak naprawdę to "mainstreamowe" programowanie to tylko znajomość pętli i ifów. Większość ludzi nie umie nic poza tym.

0

Co do taskrunnerów to nauczenie się podstaw Grunta to jeden dzień, więc warto się za to wziąć. Przydaje się w codziennej pracy i oszczędza dużo czasu.
Co do np. Karmy, to jeśli ktoś ma doświadczenie z testami jednostkowymi z backendu, to też dosyć szybko to przyswoi. Faktycznie, dla kogoś kto 1. raz ma kontakt z testami, może być dosyć ciężkie, ale nie są to miesiące nauki.

AngularJS to kobyła i mi trochę zajęło opanowanie go na jakimś zadowolającym poziomie, chociaż ucząc się go dosyć słabo znałem JS.

Podsumowując:
co prawda AngularJS czy inny framework mają najwyższy priorytet u pracodawców, ale być może warto rozpocząć naukę od taskrunnera i testów jednostkowych, co nie powinno zająć więcej niż miesiąca, a potem rzucić całe siły na framework? CV będzie bogatsze, a i znajomość tych dwóch rzeczy dosyć szybko przyda się w codziennej pracy.

Nie jestem frontendowcem, ale ucząc się grunta korzystałem z tej książki:
http://www.allitebooks.com/pro-grunt-js/
O testach jednostkowych tu jest dosyć dużo napisane (autor jest fanem TDD i wszystkie zagadnienia rozpoczyna od rozpoczęcia pisania testów):
http://www.allitebooks.com/reliable-javascript/

0

Myślę, że na dwoje babka wróżyła.

Problem z dzisiejszym rynkiem frontendowym w porównaniu z tym sprzed 6 lat jest taki, że dzisiaj każdy chce być programistą, w rezultacie jest większa konkurencja.

Tyle, że ciężko powiedzieć na ile to groźna konkurencja. Wiele nowych frontendowców dzisiaj kompletnie nie ma o niczym pojęcia, i osoby zajmujące się rekrutacją tylko rozkładają ręce z powodu niskiego poziomu (to z drugiej ręki informacje, bo nie zajmuje się rekrutacjami, ale od czasu do czasu słyszę od ludzi, którzy się zajmują, że poziom często jest bardzo niski).

Z drugiej strony na pewno też jest więcej ludzi dobrych, o ile z 6 lat temu prawie każdy ssał w JSie (coś jak "bo to taki dziwny język, lol, piszę w nim tylko dlatego, że chcę zrobić skrypt na stronę") to teraz jest więcej osób, które mają wysoki poziom i traktują to poważnie (ciężko tylko powiedzieć, czy tacy ludzie startują na stanowiska juniorskie).

Ogólne standardy też wzrosły. I nie mówię o frameworkach bo to nie są żadne standardy (w końcu mody na frameworki się zmieniają średnio co rok), tylko raczej to, że teraz się projekt dzieli na moduły, robi się jakiś build process, jest transpilacja, są różne rozwiązania CSSowe(np. Sass, ale to już trąci trochę myszką), zaczyna się myśleć również o sensownej architekturze...

JavaScript to już nie są proste skrypciki, tylko zaawansowane aplikacje. A to wszystko na pewno jakoś się odbija na wymaganiach w stosunku do juniora. Jako junior bardziej prawdopodobne, że będziesz rzeźbił swój moduł w dużej aplikacji rozwijanej przez twoich kolegów z zespołu, niż że będziesz robił proste stronkI od zera. To nie chodzi o konkretną technologię, bo raz będzie jedno, raz drugie, ale ogólnie sam proces tworzenia aplikacji frontendowych się zmienił i stał się bardziej zaawansowany).

0

z drugiej strony też często gęsto janusze przerzucają odpowiedzialność na fronta za grafikę i nawet backend, bo przecież od Angulara nie tak daleko do Node.js i on również coraz częściej jest wymieniany w "mile widziane" a zawsze łatwiej napisać w ogłoszeniu frontend i dać niższe widełki niźli fullstack i je powiększyć
co podsumowując daje naprawdę ogromną ilość materiału do nauczenia, zwykle wygląda to tak, że najpierw szukają człowieka orkiestrę do wszystkiego i nikogo nie znajdują za niską stawkę, potem ilość chętnych sukcesywnie się zmniejsza, bo IT ze sobą rozmawia co powoduje ignorowanie takich ogłoszeń przez myślących ludzi i na końcu biorą kogokolwiek z łapanki narzekając na poziom ;)

2

@Wibowit Nie zgodzę się z Tobą. Strony wizytówkówkowe są z założenia proste, więc według mnie lepiej je naklepać w zwykłym html'u + jquery albo nawet pure. Ponieważ angular potrzebuje dużo zasobów. Jeśli widzę że na tablecie strona jakiejś firmy ładuje się baaaardzo długo to osobiście wolę kliknąć w kolejny link w google. A czas pisania za bardzo się nie zmieni. Według mnie jeśli nie jest to aplikacja która często się zmienia, która cały czas serwuje nową treść to nie ma to sensu.

4

Na https://gist.github.com/Restuta/cda69e50a853aa64912d są wypisane rozmiary frameworków:
React 0.14.5 + React DOM + Redux = 42K po gzipie

Stronka musiałaby być ogołocona z grafiki, by te 42K miało znaczenie. A spowolnienie ładowania stronki jest zwykle przez ładowanie zewnętrznych skryptów, głównie reklamowych.

@LukeJL już podał generator statycznych stron opartych o React.js. Popatrz na https://github.com/gatsbyjs/gatsby#sites-built-with-gatsby i sprawdź czy ci te stronki wolno działają.

Zresztą jeśli komuś wolno ładuje się strona z 42 kilobajtowym frameworkiem to myślę, że wszystkie strony mu się wolno ładują. No chyba, że włączył Internet tylko po to, by oglądać lekkie strony wizytówki...

A i jest jeszcze jedna ważna sprawa: server side rendering. To przyspiesza początkowe wyświetlanie zawartości strony.

0

Nie mówię o ładowaniu strony a o samym jej renderowaniu, użyłem złego słowa. Jednak angular dodaje tą jedną warstwę która renderuje html na co potrzeba czasu. Szczególnie widać to na starszych, słabszych urządzeniach. Mam dość stary tablet i na nim często wchodząc na proste strony które są pisane przy użyciu frameworków czas między wpisaniem adresu a możliwością użycia strony wynosi czasem 10 sec.

0

Nie wiem jak w Angularze, ale w React'u spowolnienie względem "czystego" JSa powinno być cały czas, bo React cały czas robi uzgadnianie wirtualnego DOMa z rzeczywistym.

Sprawdź na swoim starym tablecie jak działają stronki z https://github.com/gatsbyjs/gatsby#sites-built-with-gatsby i podziel się wrażeniami. Porównaj też szybkość do innych stronek.

1

Mam dość stary tablet i na nim często wchodząc na proste strony które są pisane przy użyciu frameworków czas między wpisaniem adresu a możliwością użycia strony wynosi czasem 10 sec.

Skąd wiesz, że to wina frameworków? Często wcale nie framework jest winien a nagromadzenie CSSa i efektów animacji w JS.

Jak to jest, że mogę na komputerze odtwarzać bez problemu filmy w HD, a już jak wchodzę na byle stronkę w jQuery to mi wszystko zamula, bo ktoś wrzucił z pierdylion różnych wtyczek do animacji i oczywiście z megabajt CSSów z różnych bootstrapów, pluginów, slajderów, parallaxów itp. Poza tym często na stronach są tła po 2000 pikseli w jedną stronę. To też potrafi zamulić przy scrollu (no i oczywiście zanim się te style załadują, zanim się odpali ostrzeżenie o ciasteczkach itp. może upłynąć parę sekund).

Wyrzućmy niepotrzebne animacje i grafiki, które się pakuje jak wodę w wędlinę z marketu (bo tak sobie wymyślił a to grafik, a to klient czy inny decydent), a większość stron, które teraz wolno działa, będzie śmigać...

0

Jak to nic nie poszło do przodu? A raczej może należałoby przyjrzeć się pewnym trendom albo podejściom. Jak to:

https://blog.miguelgrinberg.com/post/writing-a-javascript-rest-client

Aplikacja Todo List, REST-owy klient zrealizowany w oparciu o Knockout.js, backend w pythonie, wypluwający JSON-owe dane, tutaj w tym przykładzie wyżej jest HTTP Basic Authentication, bo najpierw aplikacja prosi o login i hasło. Ale z tego co się orientuję to w praktyce rzecz rozbija się o Token Based Bearer Authorization, przy użyciu pewnie tego:

https://github.com/firebase/php-jwt

Piszecie tu o jakimś wolnym ładowaniu? No przecież ta aplikacja z tego przykładu to działa w taki sposób, że bardzo dużo dzieje się po stronie przeglądarki i tylko pobierane są dane w formacie JSON, jak również wysyła się jakieś dane przez POST, PUT i DELETE do usuwania i to bez przeładowania strony.

O co tu się wszystko rozbija jak nie o to? Zresztą widziałem oferty pracy dla Fullstacków, gdzie wymogiem jest właśnie ten Angular, nie wiem jak jest z Knockout. I możliwe że Google albo Facebook czy inni giganci wyznaczają pewne trendy a i pewnie już coraz więcej serwisów jest tworzonych w ten sposób.

Nie znam Angulara a Knockout tylko pobieżnie, obecnie w swojej pracy opieram się o JQuery a też dużo się dzieje w przeglądarce bez przeładowania strony, po prostu to jQuery mi wystarcza i co jeszcze istotne znakomicie się sprawdza.

0

Zawsze tak było, że Janusz szukał ludzi znających X frameworków i bibliotek, a na odpowiedź o wymagania finansowe robił oczy jak 5 zł. 10 lat temu też tak było...

0

Na wstępie zaznaczam iż nie jest bezpośrednio moją działką webdev, ale i o niego lekko się ocieram.

Na pewno w takim np. Krakowie jes już naprodukowane o wiele więcej "absolwentów informatyki" niż było 6 lat temu, bo gdzieś tak około 2009 kilka uczelni zyskało dofinansowanie w ramach kierunów zamawianych co np. na mojej uczelni skótkowało tym, że wzrosła niemal dwukrotnie liczba mejsc na kierunku.

Zauważyć, się da, że w ogłoszeniach przynajmniej na część działek "informatycznych" na stanowiska juniorskie potrafią widnieć wymagania typu "conajmniej dwa lata doświadczenia na podobnym stanowisku".

Oczywiście janusze co by chcieli mieć speców od 100 technologii w cenie juniora od jednej to swoją drogą. Zað jednak faktem jest, że na rynku o pracę ubiega się też spora rzesza ludzi "niezbyt ogarniętych", którzy przez okres studiów nie rozwijali prawie w ogóle swej wiedzy poza nabijaniem expa w League Of Legends czy World Of Warcraft, ewentualnie na zajęcia chodzili żeby grać z kumplami na laptopie w "Hirołsów" na ostatnich ławkach.

Przez co trudniej jest się przebić tym którzy coś sobą reprezentują, ale jak już się jakoś przebiją to o ile nie trafia na jakiegoś "wystraszonego zbyt wysokimi kwalifikacjami" szefa to sobie poradzą. Co nie zmienia faktu, że ogólnie mówiąc etap szukania pracy może obecnie wynosić kilka miesięcy, jeśli ktoś nie chce zasuwać w typowym januszsofcie. Co jest frustrujące. Co może w naszych realiach oznaczać, życie w tym czasie na koszt rodziców niestety. Ale co moim zdaniem w końcowym efekcie jest warte świeczki, jeśli coś sobą faktycznie pezentujesz.

2

Wg mnie to nie wzrost wymagań a zmiana w podejściu do tworzenia frontendu.
Kiedyś gdy nie wiadomo było co najlepsze, a frameworki dopiero raczkowały, firmy wolały bazować na swoich rozwiązaniach.
Teraz już rozumieją że łatwiej i taniej jest zatrudnić kogoś kto zna coś popularnego na rynku niż przekonać jakiegoś wymiatacza żeby się babrał w rozwiązaniu stworzonym wewnątrz firmy.
Krótszy czas nauki to mniej kosztowna inwestycja dla firmy przy wdrażaniu nowego członka zespołu.

1
vpiotr napisał(a):

Krótszy czas nauki to mniej kosztowna inwestycja dla firmy przy wdrażaniu nowego członka zespołu.

To jest właśnie polityka Januszy. Najważniejsza inwestycja firmy czyli inwestycja w ludzi jest u nich na ostatnim miejscu. Lepiej zainwestować w nowe Lambo czy inne Maserati.

Byłem nie raz w takich firmach na rozmowie. Któregoś razu rekruter, nie przygotowany do rozmowy (bo szef gdzieś pojechał i nie zoztawił CV) w momencie gdy opowiadałem o swoim doświadczeniu odparł: "mnie to nie interesuje, chcę wiedzieć co robiłeś w technologii x". Firma mieściła się w biurowcu na warszawskim mordorze i obecnie chętnie patronuje wydarzeniom dla pythonowego community. Szczerze współczuje ludziom, którzy tam pracują.

0

Firma w 99% funkcjonuje dla zysku, a nie dla misji. Jeżeli rynek stwarza takie warunki, że zastępowalność pracownika w technologii x na stanowisku junior-x jest duża to naturalne, że wtedy mniejsza firma nie będzie wiązać kilkuletnich planów z małodoświadczonym pracownikiem i bardziej zależy jej na pracowniku "szybko się wdroży w projekt x, zna już język / technologie, efekty widzialne nadejdą szybko" jak "to prawdziwy pasjonat, ma nieszablonowe myślenie i zainteresowania związane z używaną technologią, jak się go oszlifuje to po roku może być prawdziwym wymiataczem" (i odejdzie zanim zacznie przynosić zysk). Ciężko mieć do firmy działającej na wolnym rynku, że gra wg rynkowych zasad, co innego patologie jak znaczna różnica warunków deklarowanych a realnych, antydatowanie umów, szukanie kruczków i haków itd.

1
Haskell napisał(a):
vpiotr napisał(a):

Krótszy czas nauki to mniej kosztowna inwestycja dla firmy przy wdrażaniu nowego członka zespołu.

To jest właśnie polityka Januszy. Najważniejsza inwestycja firmy czyli inwestycja w ludzi jest u nich na ostatnim miejscu. Lepiej zainwestować w nowe Lambo czy inne Maserati.

"Profesjonalni programiści ćwiczenia wykonują w swoim czasie wolnym. Utrwalanie i rozwijanie Twoich umiejętności nie jest zadaniem Twojego pracodawcy. Nie on ma się zajmować uatrakcyjnianiem Twojego CV. Pacjenci nie płacą lekarzom za ćwiczenie zakładania szwów. (...) A pracodawcy programistów nie powinni płacić za czas poświęcony przez nich na ćwiczenia."
-- Robert C. Martin, The Clean Coder

Warto sobie przyswoić tę zasadę przed zmianą pracy.

0

Same technologie owszem, można poznać w czasie wolnym, ale już np. firmowego frameworka nie poznasz w ten sposób.

Jak dla mnie nauczenie specyficznych rzeczy używanych przez daną firmę jest trudniejsze niż nauka podstaw jakiegoś powszechnie znanego frameworka JSowego, którego się nie zna (choćby ze względu na dostępność dokumentacji, tutoriali do takiego Angulara - do wewnętrznych rzeczy zwykle nie ma tutoriali, a dokumentacja jest uboga).

Więc tak czy siak firma musi się nastawiać na inwestycję w pracownika, nawet jak zna on Angulary.

No i są rzeczy, które może, ale nie musi znać programista, bo nie są to rzeczy, które wypada znać. Frontend ma tyle bibliotek, tooli, frameworków, że nikt nie zna wszystkiego, nawet senior musiałby się douczać jakiejś biblioteki czy frameworka.

Co jeśli jakaś firma miałaby projekt, który jest postawiony na Brunchu (alternatywa do Webpacka), jest postawiony na Cycle.js (taki framework JSowy, ale wciąż niszowy z tego co wiem), korzysta z Ramdy (zamiast z bardziej popularnego Lodasha), z CardinalCSS (zamiast z Bootstrapa) i miała jeszcze parę innych trochę mniej modnych technologii niż te mainstreamowe? Myślę, że nawet seniorzy by nie wiedzieli wszystkiego. Nie ma sensu odrzucać dobrego kandydata tylko dlatego, że nie znał jakiejś biblioteki.

0

to wszystko rozbija się o proporcje wynagrodzenia do umiejętności i tyle

2

Po pierwsze programista to inne cechy i umiejętności niż znajomość języka lub frameworka. Po drugie pracownik to inwestycja, a nie koszt. Po trzecie są pracodwcy, którzy szkolą swoich pracowników - "płacą za ich ćwiczenia" lub doceniają gdy podnoszą kwalifikacje. Po czwarte nie oczekuję, że pracodawca mnie nauczy. Uważam tylko, że błędem jest szukanie pracowników wg słowa kluczowego framework X.

1 użytkowników online, w tym zalogowanych: 0, gości: 1