Co do freeza, czyli zamrozenia w zatrudnianiu - ze strony firmy ucziciwie byloby powiedziec kandydatowi ze jest freeze, technicznie wypadl ok, ale jakikolwiek ruch bedzie mozliwy np. dopiero za pol roku, zamiast przetrzymywac osobe w niepewnosci (mnie tak na poczatku kariery firma przetrzymala przez pol roku, ale to byly czasy ze w Krakowie bylo 5 duzych firm z branzy). I jeszcze uwaga od strony osoby ktora rekrutuje: dobrym podejsciem ze strony kandydata jesli czegos nie jest pewny, jest uczciwe powiedzenie, ze nie mam pewnosci jakby cos dzialalo, ale wydaje mi sie ze powinno byc tak i tak. Wtedy rekruter widzi jak osoba mysli/kombinuje, ale wie tez ze w razie czegos nie bedzie pozniej w pracy sciemniac.
Ja rozumiem, że to tylko prezentacja i przedstawione przykłady są mocno pokolorowane, ale po prostu z lekka ukuło mnie stwierdzenie, że lepsi kandydaci nie mają studiów. Szukając pracowników do Javy, kandydat prawdopodobnie tylko z niej (i innych technologii w projekcie) zostanie zapytany, na taką rozmowę wystarczyłoby przeczytać jak ten "polonista" 2-3 książki do Javy i mamy pracę w kieszeni. Jednak tego czego wtedy ten rekruter nie widzi jest to, że ta osoba ma mocno ograniczone spostrzeżenie na IT, "tak wiem, że jest coś takiego jak C, ale słyszałem, że to stary język i teraz używa się bardziej zmodernizowanych". Natomiast przychodzi student/absolwent wykazujący się częściową wiedzą z Javy, więc w tym momencie spada w rankingu, bo rekrutera nie interesuje, że oprócz klepania gówno-programów gość poznał lub chociaż miał styczność z wieloma różnymi silnikami baz danych, że zmiana języka dla niego to teraz tylko nauczenie się syntaxu i znalezienie odpowiedników funkcji jednego w drugim, że ma jakąś wiedzę algorytmiczną, że w końcu ma jakieś pojęcie o wielu aspektach i gałęziach IT, które w tym bądź innym miejscu zazębiają się z programowaniem. Tomasz podczas prezentacji dużo także mówił o motywacji bądź entuzjazmie kandydatów, że wtedy sobie plusują, że potrafią ciekawie mówić o swoich projektach. Ja po mimo tego że programuje codziennie, dniem wyjątkowym jest jak nie wejdę na stack overflow, to do ludzi niezwiazanych z programowaniem mówię o nim dość sceptycznie, namawiam do nauki, natomiast od razu mówię, że to nie będzie jedna książka, tydzień pracy i już umie się programować. To dotyczy też moich projektów, ponieważ nawet po ich zakończeniu, nadal czuję że można tam było inne rozwiązanie zastosować, można było dopisać brakujące funkcjonalności, że były pewne problemy - stąd nie mówię ich z entuzjazmem, więc na wstępie jestem degradowany przez rekrutera. Szczerze mówiąc, nie do końca rozumiem właśnie pytania w stylu "jakie interfejsy implementują Collection w javie", bo to pytanie dotyczy czysto teoretycznej wiedzy, na które też można słabo odpowiedzieć najzwyczajniej zapominając o jednym z interfejsów, ale już odpowiedź na pytanie "w jakiej sytuacji wykorzystałbyś TreeSet albo HashSet, kiedy jeden z nich będzie bardziej odpowiedni niż drugi" wymaga nie tylko dobrej wiedzy z samej Javy ale także znajomości struktur danych i ich przeznaczenia.
Zgadzam się ale po części ;) nie zgadzam z podejściem że studia są aż tak ważne, zgadzam że sprawdzanie detali javy, bez zapytania o podstawy czyli algorytmy, struktury danych jest sprowadzaniem tego na bardzo niski poziom. Po prostu nie wiązałbym tego aż tak ze studiami, a podejściem do nauki - czy ktoś uczy się żeby działało, czy ktoś uczy się troszkę szerzej. Dla przykładu typy danych i kolekcje można przerobić do stanu używania w dzień, można też zacząć od drugiej strony dowiedzieć się co to złożoność obliczeniowa, w jakich przypadkach jaka jest dla danej struktury, a potem powiązać to z kolekcją. Tylko na rozmowie przy coding teście pierwszy kandydat będzie pamiętał wszystkie metody ArrayList'y (bo tylko tej używał), a drugi przepadnie bo niekoniecznie zapamiętał wszystkie metody kolekcji, którą wybrał dość świadomie. Pytanie, któremu bliżej do dobrego programowania?
Świetny wpis, dziękuję zań. Z racji na charakter komentarza YT, nie odniosę się tak, jak wpis na to zasługuje (choć rozważam po prostu odpisanie na blogu). Natomiast kilka uwag na pewno nawet tu zawrzeć zdołam. 1) przykłady są z moich rekrutacji; 2) lepsi kandydaci [do Akademii]. Nie "lepsi pod każdym względem i do każdego projektu". 3) Studia dają erudycję, jeśli sam ją pogłębisz. Naprawdę studia dają MOŻLIWOŚĆ takiej erudycji zdobycia, ale można ją zdobyć prosto, prześlizgując się nad większością zajęć praktycznych. Wtedy nie jesteś dobrym programistą, ale dużo o programowaniu potrafisz powiedzieć. I taki ktoś "słyszał" o innych silnikach bazek, ale pomocny niekoniecznie będzie. Nie mówię oczywiście, że to standard zawsze i wszędzie, ale z moich doświadczeń wynika moja niezbyt pochlebna opinia o studiach informatycznych. 4) Zajawienie na projekty jest ZNAKIEM pasji. Nie jedynym, oczywiście, zatem nie chciałbym, by odebrano, że ODMAWIAM pasji ludziom, którzy nie mówią o projektach głośno i z entuzjazmem. 5) Absolutnie się zgadzam, że nie ma dyscypliny, której opanujesz w tydzień, po jednej książce. Dotyczy to oczywiście także programowania. Natomiast jak widzę, że człowiek ma potencjał, to go namawiam, zwłaszcza jak wiem, że temu konkretnemu człowiekowi pójdzie łatwo. Raz jeszcze dzięki za wpis!
Także nie mogę się nie zgodzić, bo niestety sam znam wiele przypadków ludzi, który już są na etapie pisania pracy magisterskiej na Informatyce prześlizgując się przez projekty i laboratoria na cudzym kodzie. I tak jak napisałeś, studia tylko informują, że dane zagadnienie istnieje, pokazują książkę, a tylko decyzją studenta jest czy tą książkę chociaż otworzy. No i ostatecznie, po mimo braku entuzjazmu z pewnych projektów warto je mieć online w jakimś repo, nawet odchudzone do jedynie najpotrzebniejszych funkcji, bo spojrzenie na to jak ktoś coś napisał może dużo powiedzieć o jego poziomie umiejętności programowania. Z perspektywy czasu, gdzie przybyło mi prawię rok doświadczenia i miałem okazję prowadzić kilka rozmów rekrutacyjnych, co raz bardziej rozumiem dlaczego w taki, a nie inny sposób opisywałeś te różne sytuacje na swoim przemówieniu. Pozdrawiam serdecznie.
Cześć, Panie Tomaszu, kiedyś (ok 1,5 roku albo 2 lata temu) wyprawiliśmy nie małą dyskusję nt. rekrutacji, podejścia obu stron i ogólnie wielu (jak nie większości) apektów związanych z rekrutacją na software developerów i inżynierów. Nie pamiętam tej wymiany komentarzy w ogóle, nawet nie chce mi się ich szukać. Natomiast chciałbym się dowiedzieć, czy Pańskie podejście do pewnych aspektów rekrutowania się w przeciągu tych ostatnich 2ch lat zmieniła? O ile Pan w tym czasie nadal zajmował się choćby trochę techniczną rekrutacją.Pytam, ponieważ w tym czasie prawie jedynie, a dodatkowo wielokrotnie, byłem postawiony w roli rekrutera technicznego. W Pańskiej prezentacji porusza Pan bardzo dużo różnych zagadnień, podejść i postaw w obec rekrutowanej osoby oraz postaw osób rekrutowanych. Tutaj chciałbym się dowiedzieć jaki jest cel zadawania pytań sugerujących błędną odpowiedź (i trwanie przy tej odpowiedzi). Pracuję aktualnie na stanowisku "Seniora", a wiem, że wiele konkretniejszych pytań, a może nawet nie konkretnych ale dotyczących wewnętrznych właściwości JVM sprawiłoby mi wielką trudność lub po prostu odpowiedziałbym "nie wiem", czyli nie mógłbym ocenić swojej wiedzy nawet na 4/5. Z perspektywy doświadzczenia stricte ta ostatnia odpowiedź "nie wiem", jest najgorsza z możliwych, bo jest wiele lepszych sposobów na przekazanie tej samej informacji (nie wiem) ale wraz z dodatkowymi informacjiami, które zaplusują. Mówię, że z perspektywy doświadczenia, bo przyszło rekrutować spektruk kandydatów od studentów, po osoby mające tyle doświadczenia ile ja lat :). Odpowiedź byłaby bardzo mile widziana, chętnie przeniósłbym ją na email, bo mam jeszcze kilka aspektów do poruszenia, a lepszym byłoby spisać wnioski z dyskusji niż dyskutować komentarz po komentarzu.
Rozumiem, że sama wypowiedź na konferencji miałą na celu przedstawienie juniorom pewnych postaw obu stron, wskazanie czego unikać, czego się trzymać. Ja chciałbym trochę poruszyć temat osób na poziomie mid/senior. Bo mówiąc o "Gienku", który nie miałby znajomości danego języka (np. Java) ale rozumiałby paradygmaty/zagadnienia, na których trochę się wspiera i pewne odpowiedzi dałby radę wypracować logicznym myśleniem, to taka jak najbardziej nadaje się do zatrudnienia.
@@mastahq3a witam ponownie! :-) Króciutko, bo czas mnie mocno goni, ale niedawno miałem prezentację o przygotowaniu się do zmiany pracy z obu stron barykady. Doświadczenia z kilku lat rekrutacji ludzi z wielu miejsc na świecie i o różnym poziomie rekrutowanym do wielu innych miejsc na świecie i też na różny poziom. Oraz oczywiście regularnie nowa porcja juniorów. lafk.pl/Prezki/ZmianaPracy.html - dopisek: robione z perspektywy mojej pracy u mojego głównego klienta. Można powiedzieć że pewne rzeczy mi się skrystalizowały i dążę do automatyzacji procesu. Daję dużo wrażeń, które podpieram obserwacjami i informacjami wziętymi z całego procesu. Wiedza, poruszanie się po IDE, skróty, obsługa laptopa, wyszukiwanie problemów, co człek robi jak nie wie - to i wiele więcej jest omówione razem z odpowiedziami na pytania. Czemu ta odpowiedź jest dziwna, tamta nieciekawa, owamta świetna itp. Często już na tym etapie mówię człowiekowi czy będę go rekomendował czy nie. Nie mówię czy go przyjmą czy nie - to jest poza mną, ale mówię czy rekomenduję i staram się powiedzieć dlaczego. Nie zawsze mi się udaje - czasem np. nie wiem, czasem potrzebuję raz jeszcze przejść przez CV aplikującej osoby, jej kod itp. Takie rekrutacje przechodzę osobno, dla siebie samego, bo to znaczy że nie zdołałem podjąć decyzji w czasie jaki sobie na nią dałem. Ale forma rekrutacji 1,5g z pytaniami i tablicą i bez koderki jest u mnie zdecydowanie skreślona, nieistotne czy mówimy o młodszych czy starszych programistach.
@@lafk_pl zakładam, że aktualny stan nie pozwala Ci (i mi też) mówićw 100% czysto :) Ale jak będziesz miał chwilę to proszę powiedz mi co rozumiesz i widzisz pod " Ale forma rekrutacji 1,5g z pytaniami i tablicą i bez koderki". Czuję, że wg. Ciebie rozmowa kwalifikacyjna powinna zawierać jakieś zadanie, które kandydat powinien napisać. OK, to może dać dużo info o rekrutowanym ale nadal sporo zależy od tego jakie to zadanie bedzie. Umkneło mi to co się kryje pod "1,5g z pytaniami i tablicą". Osobiście, dla mnie CV kandydata jest po to, żeby się odwiedzieć, co wg. i może na jakim poziomie tego "papieru" umie, potrafi. Czy względem jego ostatnich doświadczeń powinienem podejść do jego znajomości pewnych technologii krytycznie, czy też może spróbować dowiedzieć się czy rozumie i zna zastosowania pewnych aspektów technologii, która nie jest jego domenową technologią.
Ja ogólnie, ostanio, jestem zdania, że jeżeli rekrutowana osoba myśli i w obec zadawanych pytań, nie znając konkretnej odpowiedzi, stara się sformułować odpowiedź na podstawie jej aktualnej wiedzy i logicznego myślenia (np. widzi pewne wspólne cechy różnych języków, posługuje się analogią, wnioskowaniem, itp...) to nawet po mimo braku konkretnej wiedzy albo "dziurach" w pewnych podstawowych aspektach rekomenduje taką osobę, bo wiem, że jest ona w stanie uzupełnić te braki bez większego problemu.
Co do freeza, czyli zamrozenia w zatrudnianiu - ze strony firmy ucziciwie byloby powiedziec kandydatowi ze jest freeze, technicznie wypadl ok, ale jakikolwiek ruch bedzie mozliwy np. dopiero za pol roku, zamiast przetrzymywac osobe w niepewnosci (mnie tak na poczatku kariery firma przetrzymala przez pol roku, ale to byly czasy ze w Krakowie bylo 5 duzych firm z branzy). I jeszcze uwaga od strony osoby ktora rekrutuje: dobrym podejsciem ze strony kandydata jesli czegos nie jest pewny, jest uczciwe powiedzenie, ze nie mam pewnosci jakby cos dzialalo, ale wydaje mi sie ze powinno byc tak i tak. Wtedy rekruter widzi jak osoba mysli/kombinuje, ale wie tez ze w razie czegos nie bedzie pozniej w pracy sciemniac.
Ja rozumiem, że to tylko prezentacja i przedstawione przykłady są mocno pokolorowane, ale po prostu z lekka ukuło mnie stwierdzenie, że lepsi kandydaci nie mają studiów. Szukając pracowników do Javy, kandydat prawdopodobnie tylko z niej (i innych technologii w projekcie) zostanie zapytany, na taką rozmowę wystarczyłoby przeczytać jak ten "polonista" 2-3 książki do Javy i mamy pracę w kieszeni. Jednak tego czego wtedy ten rekruter nie widzi jest to, że ta osoba ma mocno ograniczone spostrzeżenie na IT, "tak wiem, że jest coś takiego jak C, ale słyszałem, że to stary język i teraz używa się bardziej zmodernizowanych". Natomiast przychodzi student/absolwent wykazujący się częściową wiedzą z Javy, więc w tym momencie spada w rankingu, bo rekrutera nie interesuje, że oprócz klepania gówno-programów gość poznał lub chociaż miał styczność z wieloma różnymi silnikami baz danych, że zmiana języka dla niego to teraz tylko nauczenie się syntaxu i znalezienie odpowiedników funkcji jednego w drugim, że ma jakąś wiedzę algorytmiczną, że w końcu ma jakieś pojęcie o wielu aspektach i gałęziach IT, które w tym bądź innym miejscu zazębiają się z programowaniem.
Tomasz podczas prezentacji dużo także mówił o motywacji bądź entuzjazmie kandydatów, że wtedy sobie plusują, że potrafią ciekawie mówić o swoich projektach. Ja po mimo tego że programuje codziennie, dniem wyjątkowym jest jak nie wejdę na stack overflow, to do ludzi niezwiazanych z programowaniem mówię o nim dość sceptycznie, namawiam do nauki, natomiast od razu mówię, że to nie będzie jedna książka, tydzień pracy i już umie się programować. To dotyczy też moich projektów, ponieważ nawet po ich zakończeniu, nadal czuję że można tam było inne rozwiązanie zastosować, można było dopisać brakujące funkcjonalności, że były pewne problemy - stąd nie mówię ich z entuzjazmem, więc na wstępie jestem degradowany przez rekrutera.
Szczerze mówiąc, nie do końca rozumiem właśnie pytania w stylu "jakie interfejsy implementują Collection w javie", bo to pytanie dotyczy czysto teoretycznej wiedzy, na które też można słabo odpowiedzieć najzwyczajniej zapominając o jednym z interfejsów, ale już odpowiedź na pytanie "w jakiej sytuacji wykorzystałbyś TreeSet albo HashSet, kiedy jeden z nich będzie bardziej odpowiedni niż drugi" wymaga nie tylko dobrej wiedzy z samej Javy ale także znajomości struktur danych i ich przeznaczenia.
Zgadzam się ale po części ;) nie zgadzam z podejściem że studia są aż tak ważne, zgadzam że sprawdzanie detali javy, bez zapytania o podstawy czyli algorytmy, struktury danych jest sprowadzaniem tego na bardzo niski poziom. Po prostu nie wiązałbym tego aż tak ze studiami, a podejściem do nauki - czy ktoś uczy się żeby działało, czy ktoś uczy się troszkę szerzej. Dla przykładu typy danych i kolekcje można przerobić do stanu używania w dzień, można też zacząć od drugiej strony dowiedzieć się co to złożoność obliczeniowa, w jakich przypadkach jaka jest dla danej struktury, a potem powiązać to z kolekcją. Tylko na rozmowie przy coding teście pierwszy kandydat będzie pamiętał wszystkie metody ArrayList'y (bo tylko tej używał), a drugi przepadnie bo niekoniecznie zapamiętał wszystkie metody kolekcji, którą wybrał dość świadomie. Pytanie, któremu bliżej do dobrego programowania?
Świetny wpis, dziękuję zań. Z racji na charakter komentarza YT, nie odniosę się tak, jak wpis na to zasługuje (choć rozważam po prostu odpisanie na blogu). Natomiast kilka uwag na pewno nawet tu zawrzeć zdołam. 1) przykłady są z moich rekrutacji; 2) lepsi kandydaci [do Akademii]. Nie "lepsi pod każdym względem i do każdego projektu". 3) Studia dają erudycję, jeśli sam ją pogłębisz. Naprawdę studia dają MOŻLIWOŚĆ takiej erudycji zdobycia, ale można ją zdobyć prosto, prześlizgując się nad większością zajęć praktycznych. Wtedy nie jesteś dobrym programistą, ale dużo o programowaniu potrafisz powiedzieć. I taki ktoś "słyszał" o innych silnikach bazek, ale pomocny niekoniecznie będzie. Nie mówię oczywiście, że to standard zawsze i wszędzie, ale z moich doświadczeń wynika moja niezbyt pochlebna opinia o studiach informatycznych. 4) Zajawienie na projekty jest ZNAKIEM pasji. Nie jedynym, oczywiście, zatem nie chciałbym, by odebrano, że ODMAWIAM pasji ludziom, którzy nie mówią o projektach głośno i z entuzjazmem. 5) Absolutnie się zgadzam, że nie ma dyscypliny, której opanujesz w tydzień, po jednej książce. Dotyczy to oczywiście także programowania. Natomiast jak widzę, że człowiek ma potencjał, to go namawiam, zwłaszcza jak wiem, że temu konkretnemu człowiekowi pójdzie łatwo. Raz jeszcze dzięki za wpis!
Także nie mogę się nie zgodzić, bo niestety sam znam wiele przypadków ludzi, który już są na etapie pisania pracy magisterskiej na Informatyce prześlizgując się przez projekty i laboratoria na cudzym kodzie.
I tak jak napisałeś, studia tylko informują, że dane zagadnienie istnieje, pokazują książkę, a tylko decyzją studenta jest czy tą książkę chociaż otworzy. No i ostatecznie, po mimo braku entuzjazmu z pewnych projektów warto je mieć online w jakimś repo, nawet odchudzone do jedynie najpotrzebniejszych funkcji, bo spojrzenie na to jak ktoś coś napisał może dużo powiedzieć o jego poziomie umiejętności programowania.
Z perspektywy czasu, gdzie przybyło mi prawię rok doświadczenia i miałem okazję prowadzić kilka rozmów rekrutacyjnych, co raz bardziej rozumiem dlaczego w taki, a nie inny sposób opisywałeś te różne sytuacje na swoim przemówieniu.
Pozdrawiam serdecznie.
Sam postanowiłem zmienić swoje życie i znaleźć pracę w IT, ten film będzie mi bardzo przydatny, dzięki
Powodzenia! :)
i jak żyjesz kolego?
na produkcji serwer spłonie! rozwaliło mnie to
Cześć, Panie Tomaszu, kiedyś (ok 1,5 roku albo 2 lata temu) wyprawiliśmy nie małą dyskusję nt. rekrutacji, podejścia obu stron i ogólnie wielu (jak nie większości) apektów związanych z rekrutacją na software developerów i inżynierów.
Nie pamiętam tej wymiany komentarzy w ogóle, nawet nie chce mi się ich szukać. Natomiast chciałbym się dowiedzieć, czy Pańskie podejście do pewnych aspektów rekrutowania się w przeciągu tych ostatnich 2ch lat zmieniła?
O ile Pan w tym czasie nadal zajmował się choćby trochę techniczną rekrutacją.Pytam, ponieważ w tym czasie prawie jedynie, a dodatkowo wielokrotnie, byłem postawiony w roli rekrutera technicznego. W Pańskiej prezentacji porusza Pan bardzo dużo różnych zagadnień, podejść i postaw w obec rekrutowanej osoby oraz postaw osób rekrutowanych. Tutaj chciałbym się dowiedzieć jaki jest cel zadawania pytań sugerujących błędną odpowiedź (i trwanie przy tej odpowiedzi).
Pracuję aktualnie na stanowisku "Seniora", a wiem, że wiele konkretniejszych pytań, a może nawet nie konkretnych ale dotyczących wewnętrznych właściwości JVM sprawiłoby mi wielką trudność lub po prostu odpowiedziałbym "nie wiem", czyli nie mógłbym ocenić swojej wiedzy nawet na 4/5.
Z perspektywy doświadzczenia stricte ta ostatnia odpowiedź "nie wiem", jest najgorsza z możliwych, bo jest wiele lepszych sposobów na przekazanie tej samej informacji (nie wiem) ale wraz z dodatkowymi informacjiami, które zaplusują.
Mówię, że z perspektywy doświadczenia, bo przyszło rekrutować spektruk kandydatów od studentów, po osoby mające tyle doświadczenia ile ja lat :). Odpowiedź byłaby bardzo mile widziana, chętnie przeniósłbym ją na email, bo mam jeszcze kilka aspektów do poruszenia,
a lepszym byłoby spisać wnioski z dyskusji niż dyskutować komentarz po komentarzu.
Rozumiem, że sama wypowiedź na konferencji miałą na celu przedstawienie juniorom pewnych postaw obu stron, wskazanie czego unikać, czego się trzymać. Ja chciałbym trochę poruszyć temat osób na poziomie mid/senior.
Bo mówiąc o "Gienku", który nie miałby znajomości danego języka (np. Java) ale rozumiałby paradygmaty/zagadnienia, na których trochę się wspiera i pewne odpowiedzi dałby radę wypracować logicznym myśleniem, to taka jak najbardziej nadaje się do zatrudnienia.
@@mastahq3a witam ponownie! :-) Króciutko, bo czas mnie mocno goni, ale niedawno miałem prezentację o przygotowaniu się do zmiany pracy z obu stron barykady. Doświadczenia z kilku lat rekrutacji ludzi z wielu miejsc na świecie i o różnym poziomie rekrutowanym do wielu innych miejsc na świecie i też na różny poziom. Oraz oczywiście regularnie nowa porcja juniorów. lafk.pl/Prezki/ZmianaPracy.html - dopisek: robione z perspektywy mojej pracy u mojego głównego klienta. Można powiedzieć że pewne rzeczy mi się skrystalizowały i dążę do automatyzacji procesu. Daję dużo wrażeń, które podpieram obserwacjami i informacjami wziętymi z całego procesu. Wiedza, poruszanie się po IDE, skróty, obsługa laptopa, wyszukiwanie problemów, co człek robi jak nie wie - to i wiele więcej jest omówione razem z odpowiedziami na pytania. Czemu ta odpowiedź jest dziwna, tamta nieciekawa, owamta świetna itp. Często już na tym etapie mówię człowiekowi czy będę go rekomendował czy nie. Nie mówię czy go przyjmą czy nie - to jest poza mną, ale mówię czy rekomenduję i staram się powiedzieć dlaczego. Nie zawsze mi się udaje - czasem np. nie wiem, czasem potrzebuję raz jeszcze przejść przez CV aplikującej osoby, jej kod itp. Takie rekrutacje przechodzę osobno, dla siebie samego, bo to znaczy że nie zdołałem podjąć decyzji w czasie jaki sobie na nią dałem. Ale forma rekrutacji 1,5g z pytaniami i tablicą i bez koderki jest u mnie zdecydowanie skreślona, nieistotne czy mówimy o młodszych czy starszych programistach.
@@lafk_pl zakładam, że aktualny stan nie pozwala Ci (i mi też) mówićw 100% czysto :)
Ale jak będziesz miał chwilę to proszę powiedz mi co rozumiesz i widzisz pod " Ale forma rekrutacji 1,5g z pytaniami i tablicą i bez koderki". Czuję, że wg. Ciebie rozmowa kwalifikacyjna powinna zawierać jakieś zadanie, które kandydat powinien napisać. OK, to może dać dużo info o rekrutowanym ale nadal sporo zależy od tego jakie to zadanie bedzie. Umkneło mi to co się kryje pod "1,5g z pytaniami i tablicą".
Osobiście, dla mnie CV kandydata jest po to, żeby się odwiedzieć, co wg. i może na jakim poziomie tego "papieru" umie, potrafi. Czy względem jego ostatnich doświadczeń powinienem podejść do jego znajomości pewnych technologii krytycznie, czy też może spróbować dowiedzieć się czy rozumie i zna zastosowania pewnych aspektów technologii, która nie jest jego domenową technologią.
Ja ogólnie, ostanio, jestem zdania, że jeżeli rekrutowana osoba myśli i w obec zadawanych pytań, nie znając konkretnej odpowiedzi, stara się sformułować odpowiedź na podstawie jej aktualnej wiedzy i logicznego myślenia (np. widzi pewne wspólne cechy różnych języków, posługuje się analogią, wnioskowaniem, itp...) to nawet po mimo braku konkretnej wiedzy albo "dziurach" w pewnych podstawowych aspektach rekomenduje taką osobę, bo wiem, że jest ona w stanie uzupełnić te braki bez większego problemu.
świetna prezentacja
To jak się mścisz to łeb jesteś
Szkoda czasu, nie traćcie go