"Bardzo dobra znajomość *" - co to znaczy

Cześć.

Przeglądam sobie oferty na 4p i w każdej ofercie jest coś w stylu ( albo i dosłownie ) Bardzo dobra znajomość technologii X lub Znakomita znajomość technologii Y itp. Co to w ogóle znaczy bardzo dobra znajomość technologii. O ile w przypadku języka angielskiego czy niemieckiego to jest to jeszcze zrozumiałe , to o tyle IMHO w języku programowania nigdy nie będzie się bardzo dobrym( biorąc pod uwagę cały zakres technologii ). Zawszę będzie robiło się błędy i to nawet te najgłupsze. Piszę w Node 2 lata a nawet nie czuję się średnio dobry.

Co wy o tym myślicie?

Post kieruję do rekruterów / rekruterek / head-hunterów( a wiem że tacy tu są ) by nieco się sprecyzowali co ich interesuje, bo w ofercie jest np bardzo dobra znajomość np. Javascript a na rozmowię nie ma żadnego pytania z tegoż języka. A później się okazuję, że jednak szukają Angular2 Dev a nie Javascript Dev :D

PS. Wiem, że ogarnięcie frameworka z danej techologii po paru latach kodowania w tym języku jest błahe i można to zrobić w parę dni, ale nie na poziom bardzo dobry

To znajomosc na tyle zebys przekonal rekrutera ze masz bardzo dobra znajomosc X :P

Jeden rabin powie tak, drugi rabin powie nie. Pewnie że to nic nie znaczy - ma zniechęcić tłumy wannabe i kompletnie zielonych studentów od przesyłania aplikacji i zmniejszenie roboty dla rekrutującego. Twój poziom i tak rzadko jest w stanie ocenić rekruter -> wszystko zależy od pierwszej rozmowy technicznej i tego jak wypadniesz.

PS: Nie jestem rekruterem.

Dla niektórych bardzo dobra znajomość to przeczytanie na wikipedi opisu danej technologii czy frameworka sic!

Nie ma jednak co iść w drugą skrajność jeśli coś pisałeś w danej technologi i czujesz się pewnie to jest już wystarczająca znajomość aby aplikować.

Najwyżej się nie dostaniesz ale informacje jakie zdobędziesz o tym co umiesz a czego jeszcze nie zostaną z Tobą niezależnie od decyzji rekrutera. Dowiesz się nowych rzeczy i uzupełnisz swoją wiedzę. Czy to nie jest fajne? ;)

tak myślę, że z punktu widzenia programisty znakomita znajomość to lata nauki i praktyki która właściwie nigdy się nie kończy

z punktu rekrutacji pewnie oznacza, że wybierają najlepszego jaki się na dany moment nawinie ;)

Z takiego czysto praktycznego punktu widzenia:

1. Znajomość 20% tego co oferuje dany język programowania/framework i technologie z tym związane = 80% tego co można w tym zrealizować, jest to moim zdaniem tylko znajomość pobieżna, tu zakładam znajomość tego co najczęściej występuje w praktyce (sprawdźcie sobie co występuje w 80% przypadkach w Waszych kodach)
2. Pozostałe 80% to jakieś 20% tego co będzie występowało rzadziej i zapewne trudniejsze rzeczy niż tylko proste CRUD-y :-)
3. Jestem ciekaw co by było, gdyby w ogłoszeniach była wymagana tylko pobieżna znajomość?
4. Spróbujcie napisać prawdę w CV, sygnalizując nie wiem gwiazdkami czy w dowolny inny sposób że daną technologię znacie pobieżnie albo bardzo słabo. Kandydaci kłamią, bo inaczej to pewnie by w wielu przypadkach nie przeszli. A z drugiej strony papier przyjmie wszystko a to że komuś się wydaje że zna coś perfekcyjnie można dość szybko zweryfikować :-)

drorat1 napisał(a):

4. Spróbujcie napisać prawdę w CV, sygnalizując nie wiem gwiazdkami czy w dowolny inny sposób że daną technologię znacie pobieżnie albo bardzo słabo.

i byś się zdziwił, sam do niedawna wpisywałem uczciwie podstawową znajomość+portfolio (teraz już wiem więcej) i miałem naprawdę sporo telefonów z top miast bez problemu i nie były to firmy "no name" czy startupy, ani rekruterzy (zapychanie dziury rekrutacyjnej)

Westen napisał(a):

Cześć.

Przeglądam sobie oferty na 4p i w każdej ofercie jest coś w stylu ( albo i dosłownie ) Bardzo dobra znajomość technologii X lub Znakomita znajomość technologii Y itp. Co to w ogóle znaczy bardzo dobra znajomość technologii. O ile w przypadku języka angielskiego czy niemieckiego to jest to jeszcze zrozumiałe , to o tyle IMHO w języku programowania nigdy nie będzie się bardzo dobrym( biorąc pod uwagę cały zakres technologii ). Zawszę będzie robiło się błędy i to nawet te najgłupsze. Piszę w Node 2 lata a nawet nie czuję się średnio dobry.

Co wy o tym myślicie?

Nigdy nie wiadomo co to znaczy. Nigdy. po prostu trzeba się dowiedzieć na rozmowie technicznej. Na jed nej rozmowie możesz powalić rozmówców wiedzą, na innej nie zrobić w ogóle wrażenia.

Myślę, że takie problemy i rozmyślania mają tylko osoby początkujące w szukaniu pracy jako programista. Raczej zdecydowana większość osób, która ma za sobą już jakieś doświadczenia z firmami zdaje sobie sprawę, że te ogłoszenia są po to aby odstraszyć tych pierwszych.

Nie masz za bardzo innego wyboru jak wysłać swoje CV na interesujące Cię ogłoszenia i zobaczyć jaki będzie poziom rozmowy, jeżeli okaże się, że często przewijają się pytania na które nie znasz odpowiedzi to najzwyczajniej będziesz wiedział gdzie masz braki i mógł to nadgonić przed kolejną rozmową.

Zresztą IMO jak nie składasz CV na jakieś wysokie stanowiska to równie ważne jest Twoje podejście do samego problemu i faktu, że czegoś nie wiesz. Lepiej powiedzieć, że nie miałeś jeszcze z czymś doczynienia, ale robiłeś coś podobnego (tutaj możesz nawet na spontanie coś wymyślić) z zastosowaniem takich i takich rozwiązań. W tym miejscu dobrze, żebyś chociaż kojarzył podstawowe zastosowania i pojęcia związane z Twoją technologią i wiedział o co ktoś pyta. Bo jak rozłożysz ręce, powiesz, że nie wiesz, zamilkniesz i zaczniesz patrzeć się w podłogę to może nie być najlepiej.

Chodzi o to, żebyś kogoś przekonał o tym, że nawet czegoś nie wiesz jeszcze to będziesz w stanie to szybko nadgonić :)

Zwykle to znaczy, że pracodawca (pani z HR) nie miał pojęcia co wpisać w ogłoszenie.
Z mich obserwacji wynika że 80% ogłoszeń ma taki mankament.

'bardzo dobra znajomosc x' na ofercie pracy znaczy mniej wiecej to samo co gdy kandydat wpisze na swoim cv 'bardzo dobra znajomosc x' czyli pogadamy zobaczymy

Prawda jest taka, że nikt nie myśli co wkłada do ofert. Potrzeba programisty, więc się pisze ofertę i wrzuca do niej różne hasła (Angular, AJAX, JavaScript) i okrasza je różnymi dodatkami (taki dodatek to np. "bardzo dobra znajomość" - to w ofertach zwykle nic nie znaczy - trochę jak "starannie dobrane ziarna" w reklamach kawy czy "proszek z granulkami sięga w głąb tkaniny", albo "wynagrodzenie adekwatne do umiejętności". Slogan, a nie nic czym by można się przejmować).

Tak naprawdę to co jest napisane w ofertach to wierzchołek góry lodowej. Można powiedzieć, że oferta = 5% prawdy. Rozmowa o pracę = może 20% prawdy. Natomiast jak już się zatrudniasz to dowiadujesz się pozostałych 80% i uwierz, że nie zawsze jest to przyjemna wiedza. To jak wygląda twoja praca w praktyce i jak są napisane projekty najczęściej nie ma wiele wspólnego z tym co na ogłoszeniu. Chociaż z drugiej strony to, co w ogłoszeniu może mieć wpływ na rekrutację:

To znajomosc na tyle zebys przekonal rekrutera ze masz bardzo dobra znajomosc X :P

Czyli musisz jakoś tak zakręcić, żeby uwierzyli, że jesteś odpowiednim kandydatem na stanowisko. To czy masz dobrą znajomość czy złą czegoś tam, nie ma znaczenia na tym etapie. Ważne jest jakie wrażenie wywrzesz na osobach, które będą cię rekrutowały. Że jak "masz znać X" to, żeby uwierzyły, że znasz albo ew. że się szybko nauczysz, nawet jak nie znasz.

Świat jest teatrem, aktorami ludzie i tak dalej.

@Westen Tak z ciekawości, co chciałbyś zobaczyć w ogłoszeniu?

Jestem odpowiedzialny za to ogłoszenie: Senior Web Developer i wraz z grupą innych dewów biorę udział w procesje weryfikacji kandydatów.

Grupa odpowiedzialna za to ogłoszenie składa się z seniorów. Pisząc np "Dobra znajomość języka JavaScript i frameworku AngularJS." pod Seniorem, szukamy dewelopera który mógłby każdego z nas zastąpić na projekcie który używa tych technologii - jeszcze lepiej gdy nas coś nauczy/ułatwi nasze podejście do pracy. Przyznam się że jest to całkiem subiektywne.

Bardziej obiektywną ocenę wymuszamy code review. Każdy kandydat jest proszony oto by w ~tydzień rozwiązał zadanie w oparciu o JS/Angular lub w podobnym (np JS/React/Redux). Rezultat oceniamy w oparciu o checklistę "Best Practices" których sami stosujemy lub podłapaliśmy od innych (np https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md).

Z tą znajomością bardziej chodzi nam o "Czy kandydat potrafi się efektywnie poruszać w technologi X?"

A na wymagane lata doświadczenia w danej technologii lub ogólnie też należy waszym zdaniem patrzeć z przymrużeniem oka czy jednak nie? Jasne, że tam gdzie wymagają 2 lat w Angularze bez zastanowienia powinna aplikować osoba w A. posiadająca np półtora roku, ale sytuacje gdzie wymagają 5 lat, a ma się dwa, gdzie wymagają 2, a ma się 6 msc itd?

Pisząc np "Dobra znajomość języka JavaScript i frameworku AngularJS." pod Seniorem, szukamy dewelopera który mógłby każdego z nas zastąpić na projekcie który używa tych technologii-

Przekonanie, że każdy kto jest dobry w AngularJS (albo zna dobrze inny framework) może bez problemu wejść w projekt napisany w tymże frameworku i "każdego z nas zastąpić na projekcie " jest dość... optymistyczne. Znajomość konkretnego projektu ma znaczenie często większe niż znajomość technologii. Słaby programista który siedzi od roku w projekcie może być bardziej efektywny niż osoba dobra, która wchodzi w nowy projekt (i która się w nim nie będzie umiała poruszać sprawnie).

Na dodatek wiele rzeczy nie ma związku z kandydatem w ogóle. Np. jakość kodu w projekcie. Jeśli projekt jest spaghetti to ciężko coś wykombinować z tego. Można przepisać co najwyżej. No i jeśli w zespole jest kilka osób oraz kilka osób z zewnątrz (menedżer, klient, grafik, admin itp.) to fakt, że ktoś zna dobrze Angulara czy inny framework naprawdę małe ma znaczenie, bo każda osoba w zespole jakoś na siebie oddziałuje.

Dlatego uważam, że wymogi rekrutacyjne w stylu "znajomość Angulara" (nawet już niekoniecznie dobra, ale ogólnie) za śmieszne. Tak jakby od technologii tak dużo zależało...
Jeśli już oceniać umiejętności techniczne, należałoby prędzej badać czy kandydat umie myśleć całościowo, czy umie tworzyć fajne rozwiązania od strony architektury, czy jego kod trzyma się kupy etc.

Czy nawet, czy potrafi coś wnieść do zespołu od siebie. Tak jak przedmówca napisał jeszcze lepiej gdy nas coś nauczy/ułatwi nasze podejście do pracy.

Z drugiej strony. Nadal jestem pod wrażeniem co sprzedawcy w różnych firmach konsultingowych potrafią nałgać o znajomości technologii przez swoich ludzi. Kiedyś opracowaliśmy nawet podręczny słownik (mniej więcej - trochę pamięć się zacina):

• ekspert w technologii X - potrafi napisać w X "Hello World",
• doświadczony programista technologii X - potrafi napisać w X "Hello World", ale niestety nie działające,
• bardzo dobra znajomość X - ma bardzo dobrego znajomego, który jest ekspertem w X,
• dobra znajomość X - siedział co najmniej tydzień w pokoju z gościem, który jest doświadczony w X,
• podstawowa znajomość X - nigdy nie słyszał o X, ale fajny z niego gość ogólnie,

A tak btw. - to te kolekcjonowanie pokemonówtechnologii to chyba najgorsza rzecz jaka jest IT. W praktyce dobry programista (liczy się (w tej kolejności): przyjazność, pracowitość i niezgorszy łeb) szybko się ogarnie w czymkolwiek. Dlatego
na rozmowie o pracy warto testować ludzi z tego co umieją - niech się pokażą i z tego wyciągać wnioski.

Bardzo dobra znajomość oznacza umiejętność odpowiedzenia na pytania rekrutującego dotyczące: kruczków językowych świadczących zazwyczaj o spapranym kodzie (np. czy właściwości w C# mogą być new albo sealed), ukrytych keywordów, albo podania sygnatury funkcji, których używa się przeciętnie raz na 10 lat.
Ponadto, gdyby jakimś cudem doszło do poważnej dyskusji, to w razie jakichkolwiek różnic w podejściu np. ORM A vs B, silnik widoków X vs Y, czy w MVC logika ma siedzieć w kontrolerach czy w widokach - trzeba zawsze przyznawać rację rekrutującemu.
No i najważniejsze - odróżnianie interfejsu od klasy abstrakcyjnej.

Przyznawanie zawsze racji rekrutującemu nie jest wcale taką dobrą strategią, bo można wyjść na osobę nie mającą własnego zdania, a to np. u nas byłoby potraktowane jako wada. Cenimy osoby samodzielne i niezależne i nie chcemy w zespole osób, które później trzeba będzie niańczyć i które boją się podejmowania decyzji i krytyki.

Jeśli ktoś ma własne zdanie inne niż rekruter, ale umie sensownie je uargumentować, czyli nie jest to jedynie "bo tak!" albo "bo tak było w książce / na studiach", to ja np. uwielbiam takich kandydatów. Różnica zdań to jest świetna okazja aby pokazać głęboką wiedzę. Oczywiście jest to też pewne ryzyko i na pewno trzeba wiedzieć o czym się mówi, nie można blefować, bo to wyjdzie. No i trzeba dyskutować kulturalnie i nie przesadzać. Prezentowanie skrajnego stanowiska w jakiejś sprawie jest wielce ryzykowne, bo można dostać łatkę fanatyka.

Znajomość programowania w języku X to jest nic.... Człowiek, który skończył dobre studia bez problemu opanuje nowy język programowania w tydzień.

@Krolik czesciowo sie zgodze, sama oczekuje od kandydatow wlasnie takiego podejscia i faworyzuje takie osoby (jesli nie gadaja glupot). problem jednak jest taki ze rozne osoby rekrutuja, zwykle jest tez pare etapow i duzo moze sie zdarzyc, jesli kandydat rzuci pare kontrowersyjnych opinii (zdrowy rozsadek jest wazniejszy od wzorcow, tdd wcale sie nie sprawdza, scrum to idiotyzm etc) to nawet jesli bedzie umial to sensownie uzasadnic to male szanse zeby wszyscy go klepneli jesli nie ma naprawde mocnego cv

Krwawy Orzeł napisał(a):

Znajomość programowania w języku X to jest nic.... Człowiek, który skończył dobre studia bez problemu opanuje nowy język programowania w tydzień.

tak, 5 lat studiow na pewno jest wiecej warte niż 10 lat doświadczenia...