-
Czy przegotowujecie się do rozmów kwalifikacyjnych? Czasami wśród znajomych spotykam się ze "studenckim" podejściem do rozmów. Zakuć jak najwięcej( ewentualnie pouczyć się pytań), dostać się do firmy a później i tak nie stosować tej wiedzy i w efekcie zapomnieć( a więc warunki ZZZ spełnione). Co mogłoby się wydawać dziwne takie osoby są chętnie brane do różnych firm.
Czy dobre firmy są odporne na takich "wykutych wymiataczy" z ograniczonymi umiejętnościami praktycznymi? -
Jaką wartość na rynku ma senior nie znający podstaw? Mam w pracy parę osób, które pomimo długiego stażu pracy sprawiają wrażenie zatrzymania się w czasie. Mógłbym o tym wiele napisać, ale brak znajomości podstaw języka( np łapanie Exception w którym seria ifów sprawdzaja instanceofem typ wyjątku), clean code czy SOLID jest normą.
Czy na rozmowach na stanowiska seniorskie padają pytania o podstawy? Czy zdarza się, że osoba która ma 5+ lat doświadczenia jest pytana o potencjalnie błahe rzeczy czy raczej zakłada się znajomość podstaw w ciemno?
Jezeli wiedzialbym ze w potencjalnie nowej pracy bede uzywal technologii ktorej nigdy nie uzywalem, to mozna cos tam popatrzec. Ale i tak najwiecej czlowiek sie uczy "live", w trakcie pracy, wiec sens zakuwania przed interview jak do egzaminu moze nawet wprowadzic w blad i moze sie okazac ze nawet jezeli sie dostales do pracy to mozesz sie do niej niedawac :)
Chyba ze to twoja pierwsza praca... wtedy wszystkie chwyty dozwolone :) Ale pozniej, chyba nie warto kolorozywac, szczegolnie ze rynek jest przeplniony milionami ofert dla programistow, latwo znaleŹĆ cos dla siebie.
A co do pytan dla seniora... to nie wiem nie jestem seniorem, ale wydaje mi sie ze w pierwszych paru minutach rozmowy mozna zdefinowac czy ktos jest seniorem czy nie. Sposob mowienia zmienia sie wraz ze wzrostem doswiadczenia. Sam tez nie uzywam expection's ale to nie znaczy ze nie moge sie ich nauczyc w relatywnie krotkim czasie jako "Senior", czy nawet jako "Mid"
-
Warto się przygotować z tej podręcznikowej wiedzy. Nigdy nie wiesz na kogo trafisz na rekrutacji. Może to być koks, który przemieli Cię i sprawdzi co umiesz naprawdę a gdzie znasz reguły, ale może też być wstęp z panią z HR i kiepskim programistą którzy by chcieli byś wyrecytował wzorce GoF. To drugie nie znaczy od razu że firma jest kiepska. Może np. standardowy rekruter jest w delegacji do klienta czy coś w ten deseń. Dlatego ja przeglądam książki dzień przed, ale kuć to nie kuję :).
-
Myślę że po krótkiej rozmowie dość łatwo sprawdzić jaki jest faktyczny poziom. Jak jest stanowisko seniorskie, to pyta się raczej o trudniejsze terminy wynikające z doświadczenia, ale jak delikwent zacznie się gubić w zeznaniach, to zawsze można zejść niżej i sprawdzić czy nie stał się seniorem bo pracował 5 lat w janusz sofcie, a tam właśnie to jest wyznacznikiem. No i oczywiście zawsze możesz dostać kawałek kodu do napisania który dość jasno powie jaki jest Twój poziom.
najlepiej postawić się w odwrotnej sytuacji a co ty byś sie zapytał potencjalnego pracownika ?
Wąs Grażyna napisał(a):
- Jaką wartość na rynku ma senior nie znający podstaw?
W Polsce firmy traktują osoby 40+ jak śmieci. Szczególnie wtedy gdy chcą lub muszą zmienić zawód. Firmy nastawione są na rekrutację młodzików, głównie niedoświadczonych studentów. Dla firm ważne jest głównie to aby ktoś był piękny i młody (najwyżej 25 lat). A tak jak napisałem powyższej, osoby 40+ są traktowane jak śmiecie społeczne. Dla firm i młodych osób, seniorzy są starzy, głupi, niby nie potrafią się niczego nauczyć. Zapomina się o tym, że takie osoby są otrzaskane w pracy, mają bagaż doświadczeń życiowo-ludzkich-pracowniczych. Tylko że w Polsce takie wartości wyrzuca się na śmietnik.
Wąs Grażyna napisał(a):
- Czy przegotowujecie się do rozmów kwalifikacyjnych?
biore gume do rzucia zeby nie chuchac smrodem podczas pair programming ;) a tak serio to sie nie przygotowuje.
Wąs Grażyna napisał(a):
Czy dobre firmy są odporne na takich "wykutych wymiataczy" z ograniczonymi umiejętnościami praktycznymi?
zalezy od firmy, rekruterzy maja rozne podejscia. to czy ktos jest wykutym wymiataczem latwo sprawdzic zadajac pytania praktyczne i dajac IDE zeby pokazal co potafi.
Wąs Grażyna napisał(a):
Jaką wartość na rynku ma senior nie znający podstaw?
znow zalezy od firmy, ale niestety nawet malpa majaca 5 lat dosw jako programista jest warta calkiem sporo na rynku pracy
Wąs Grażyna napisał(a):
Czy na rozmowach na stanowiska seniorskie padają pytania o podstawy? Czy zdarza się, że osoba która ma 5+ lat doświadczenia jest pytana o potencjalnie błahe rzeczy czy raczej zakłada się znajomość podstaw w ciemno?
pytania pewnie padna ale czy odpowiedz na nie bedzie miala jakies wielkie znaczenie to juz zalezy od rekrutera
Przygotowania po studencku wynikają z tego, że sporo firm ciągle prowiadzi rekrutacje tak jakby szukała studenta drugiego roku.
Jeżeli firma fię nie przygotuje i tylko ściąga najpopularniejsze pytania, a później pyta o niepraktyczne bzdety typu własne sortowanie, własną implementację drzewa i inne rzeczy których się robić nie powinno bo od tego są biblioteki to nie ma się co dziwić, że człowiek znajduje sobie w necie top 100 pytań i je wkuwa - przynajmniej jak chce wytargować jak najwięcej.
Wąs Grażyna napisał(a):
- Czy przegotowujecie się do rozmów kwalifikacyjnych?
Czasem odświeżam sobie wiedzę z rzadziej używanych przeze mnie rzeczy typu SQL, wątki, czy jakieś wzorce projektowe, których nie miałem okazji stosować. Ale bez przemęczania się.
Czy dobre firmy są odporne na takich "wykutych wymiataczy" z ograniczonymi umiejętnościami praktycznymi?
Tak, dobre firmy dają testy Codility i nie mają problemu z kujonami. :D
A tak na serio, to wątpię, w prawie każdej firmie są ludzie, którzy piszą słaby kod.
- Jaką wartość na rynku ma senior nie znający podstaw? Mam w pracy parę osób, które pomimo długiego stażu pracy sprawiają wrażenie zatrzymania się w czasie. Mógłbym o tym wiele napisać, ale brak znajomości podstaw języka( np łapanie Exception w którym seria ifów sprawdzaja instanceofem typ wyjątku), clean code czy SOLID jest normą.
Bo senior od juniora różni się wyłącznie tym, że pisze gówniany kod samodzielnie.
Nie przypisywałbym dużej wagi do korporacyjnych stanowisk, które dostaje się za dupogodziny wysiedziane w projektach.
Czy na rozmowach na stanowiska seniorskie padają pytania o podstawy?
Zależy, co nazywasz podstawami, ale o takie rzeczy jak: "jakie znasz wzorce projektowe" albo "czym się różni klasa abstrakcyjna od interfejsu" pytają wszystkich.
Stanowcze 'nie' dla zalewu rynku pracy śmieciem ludzkim, który nie chce uczciwie pracować!
Według mnie takie przygotowywanie się nie ma sensu bo tak na prawdę można zadać zbyt dużo innych pytań techniczny i jest bardzo niewielka szansa na to, że padnie któreś z tych twoich top 100. Wiem, że na pewno 2 razy miałem jakaś podpuchę, dostałem ileś tam słów kluczowych i miałem tłumaczyć do czego one służą a niektóre dawno wypadły ze standardu. W top 100 tego nie znajdziesz.
Kiedyś się przygotowywałem, ale teraz, tak jak mówi to Wojciech Waglewski - człowiek w pewnym momencie staje się w pewien sposób profesjonalistą i specjalnie nie musi robic prób, to co robi stale - wystarcza.
Co do 1 pytania to koderzy z przynajmniej rocznym stażem niemal wszystkie słowa kluczowe C# czy Javy wymieniają bez zająknięcia przez sen w fazie REM, więc nic dziwnego, że nie muszą tego powtarzać ;) Osobiście jako leszczyk z doświadczeniem mniejszym niż rok, mam w zakładkach z 10 stron z popularnymi pytaniami i zadaniami w C# i ASP.net. Ostatnio wrzucam sobie to wszystko do Worda i jeśli będę zmieniał pracę to będę to wszystko powtarzał. Inna sprawa, że przygotowując takie rzeczy jest duża szansa, że dowiesz się czegoś nowego albo sobie o czymś przypomnisz.
Nie wiem jak z C#, ale W C znajdziesz, słowa które wypadły ze standardu, więc nie koniecznie musisz je znać, albo nie robią nic bo po prostu pozostały z wcześniejszych wersji
Wiadomo, że można zapytać o dużo rzeczy i zadać dobre/praktyczne/sensowene pytania, ale ciągle są firmy które prowadzą rekrutację w sposób olewczy i to bardzo.
Takie firmy nie wymyślają swoich pytań, tylko ściągają je właśnie z neta, a jak już coś od siebie dadzą to szblon jest zupełnie taki sam.
Bardzo często ktoś się pyta o podział wyjątków w javie(checked i unchecked), ale prawda jest taka, że nawet nie znając tych słów można być dobrym programistą -dokładnie tak jakby powiedzieć Polakowi, że nie umie mówić po <ort>Polsku </ort>jeżeli nie wie co to jest czas zaprzeszły albo przyimek - oczywiście zaraz poleci hejr, że niby powinienem pisać małą literą.
Inne pytania tego typu to np polecenie narysuj schemat fabryki abstrakcyjnej.
Bywa, że <ort>karzą </ort>zaimplementować swoje drzewo, albo quicksorta tak jakby programiście zapamiętywanie algorytmów było potrzebne do klepania webserwisów czy innego korpo.
Do tego dochodzą jeszcze bzdurne programiki webowe typu codility czy hackerrank czyli coś w rodzaju pisania na kartce z kompilatorem, a gdzieś "tam" siedzi sobie rekruter i patrzy na żywo jak piszesz.
To rozwiązanie jest o tyle głupie, że normalnie piszesz w jakimś IDE i możesz sobie podpiąć masę pluginów czy robić szablony więc nie piszesz kodu tylko go generujesz/odtwarzasz i dostosowujesz.
Jak do takiego hackerranka przystąpi dwóch kandydatów z czego jeden nie zna swojego środowiska i wszystko ciśnie z palca a inny ma wszystko zdefiniowane i pokonfigurowane tak, że używa skrótów, ale za to nie pamięta często powtarzających się konstrukcji - bo po co skoro ma je pod kombinacją klawiszy - to na rozmowie lepiej wypadnie ten pierwszy, a w pracy jednak ten drugi.
Dobre firmy zamiast tego pytają o prkatyczne rzeczy typu:
Aplikacja wyłożyła serwer i poleciał OutOfMemoryError, co robisz?
Musisz usunąć z drzewa katalogów wszystkie foldery o nazwie x wraz z ich zawartością, jak to zrobisz?
Aplikacja działa zbyt powoli, co robisz?
Zaprojektuj bazę danych do rpzechowywania informacji medycznych x,y,z, itd. klienta. Pamiętaj, że wymagania mogą się jeszcze zmienić.
Generujesz klasy z wsdl czy wsdl z klas? Dlaczego tak?
To samo co wyżej z bazą i orm.
Zamiast codility dają praktyczne zadanko którego naklepanie powinno zająć jeden wieczór i deadline na nie na 2 tygodnie tak żeby osoba pracująca czy zajęta w jakiś inny sposób mogła znaleźć czas na rozwiązanie.
W zadaniu powinna być pełna dowolność wyboru technologii i ort!, ale też należy dać zastrzezrenie, że wymogi się mogą zmienić.
Wtedy firma się zabezpiecza przed wkuwaniem top100, widzi w praktyce czy kandydat zna frameworki w stopniu umozliwiającym rozwiązywanie codziennych zdań, widzi jakość kodu.
Później jeszcze tylko trzeba kandydata przepytać dlaczego wybrał takie a nie inne rozwiązania i gotowe.
Mnie osobiście takie podejśćie firm irytuje, bo pokazuje, że firma ma olewczy stosunek i nie wie co przyszły pracownik będzie robić.
Jak firmie szkoda poświęcić trochę czasu osoby rekrutującej, to później musi się męczyć z ludźmi niemającymi pojęcia co robią.
Pijany Lew napisał(a)
Bardzo często ktoś się pyta o podział wyjątków w javie(checked i unchecked), ale prawda jest taka, że nawet nie znając tych słów można być dobrym programistą
Nie. To jest fragment kodu napisany przez jednego "seniora".
try{
doSmth();
}catch(Exception e){
if( e instanceof SomeException){
smth();
}
if( e instanceof OtherException){
smthOther();
}
}
I teraz jeżeli poleci cokolwiek innego niż SomeException lub OtherException, to nie wydarzy się nic. Coś w którymś miejscu nie będzie działało i nikt nie będzie wiedział dlaczego. Jak widzę takiego koszmarka, który przypadkiem "wycisza" wszystkie wyjątki poza tymi z if'ów to jest mi słabo. Jeżeli oprócz tego mam świadomość, że osoba która to wyprodukowała nie ma pojęcia co tworzy to dostaję konwulsji.
Nawet gdyby obsłużyć wszystkie wyjątki to też jest ciekawie:
public class TestClass
{
public TestClass(int option) throws IOException, FileNotFoundException
{
switch(option)
{
case 0:
{
throw new IOException("Error on read file");
}
case 1:
{
throw new FileNotFoundException("File not found");
}
}
}
}
try
{
TestClass testClass = new TestClass(0);
}
catch (Exception e)
{
if (e instanceof IOException)
{
System.out.println("Handled IO Exception");
}
if (e instanceof FileNotFoundException)
{
System.out.println("Handled File Not Found Exception");
}
}
Dla 0 wyświetli: Handled IO Exception, dla 1 wyświetli zarówno to Handled IO Exception jak również Handled File Not Found Exception.
natomiast coś takiego:
try
{
TestClass testClass = new TestClass(1);
}
catch (FileNotFoundException e)
{
System.out.println("Handled File Not Found Exception");
}
catch (IOException e)
{
System.out.println("Handled IO Exception");
}
już poprawnie, zamienić miejscami tzn. catch FileNotFoundException zaraz po IOException to się nie skompiluje a przynajmniej NetBeans nie pozwala.
Widocznie te głupie testy kompetencyjne przeprowadzone przez te rzekomo niepoważne (czy tam debilne) firmy coś znaczą...
@Wąs Grażyna
W jaki niby sposób zajomość terminów checked/unchecked zabezpiecza przed czymś takim?
To jest zwyczajnie złe i tu seniora nie trzeba tylko trochę obycia i wyobraźni.
Przed czymś takim i innymi błędami zabezpiecza właśnie ten programik który się karze zrobić, bo w kodzie od razu widać czy człowiek wie co robi czy nie.
@Pijany Lew
Ale żeby ten prosty programik w celu pokazania swoich umiejętności napisać, to chyba jakieś fundamentalne podstawy w Javie (ogólnie w dowolnym języku) należałoby znać. Problem jest jednak w czymś innym i nie wiem czy to widzisz. Otóż znajomość czegoś co jest w praktyce wykorzystywane bardzo rzadko albo nawet wcale nie jest tu żadnym miernikiem. Bo jak by tak się przyjrzeć tym wszystkim kodom to pewne rzeczy (fundamentalne) będą wykorzystywane częściej niż inne.
Jeśli w rekrutacjach padają pytania o fundamentalne podstawy z javy czy tam sql ale pytanka są powymyślane w ten sposób, że są to rzeczy praktycznie nigdy albo bardzo rzadko wykorzystywane to można by się tylko zastanawiać nad tym co takie podejście ma na celu? Czy to nie chodzi przypadkiem o budowanie sobie takiej otoczki profesjonalizmu w celu pokazania klientom jaką to profesjonalną kadrę się zatrudnia? Udowodnić komuś że nic nie umie a skoro kasa jest uzależniona od umiejętności to kandydat nie zasługuje na więcej niż płaca minimalna?
Co zaś do pytań praktycznych, studenciaki chyba nie mają raczej pojęcia o wzorcach projektowych a w aplikacjach webowych o zagadnieniach związanych ze skalowalnością, więc jak by im zadawano pytanka typu jak sensownie poprawić wydajność aplikacji webowej bo liczba użytkowników się zwiększa to co by na to odpowiedzieli? Przepisać w C zamiast PHP bo jest szybszy albo inne tego typu rzeczy?
@drorat1
Dokałdnie tak jest jak piszesz, chyba, że Cię nie zrozumiałem.
Albo firma robi otoczkę profesjonalizmu by wytargować jak najwięcej na pracowniku, albo faktycznie jest profesjonalna i zarabia profesjonalizmem a nie cwaniactwem.
Wielu studentów faktycznie by nie odpowiedziało na konkretne pytania, ale zmiana tych pytań na pytania teoretyczne i oderwane od rzeczywistości to jest właśnie premiowanie studentów zamiast ludzi którzy mają pojęcie czyli zupełnie złe podejście.
Pijany Lew napisał(a):
Wielu studentów faktycznie by nie odpowiedziało na konkretne pytania, ale zmiana tych pytań na pytania teoretyczne i oderwane od rzeczywistości to jest właśnie premiowanie studentów zamiast ludzi którzy mają pojęcie czyli zupełnie złe podejście.
niby co jest zlego w tym podejsciu, jesli firma chce zatrudniac studentow to raczej robi przysluge profesjonalistom prowadzac rekrutacje pod studentow :)
co do rzekomego 'ugrywania' na celowym zadawaniu pytan niepraktycznych to watpie zeby ktokolwiek takie podejscie stosowal, 'nie wiedzial pan ile dokladnie bajtow ma generacja 1 w GC to -500 do pensji' jaaasne ;)
Wąs Grażyna napisał(a):
- Czy przegotowujecie się do rozmów kwalifikacyjnych? Czasami wśród znajomych spotykam się ze "studenckim" podejściem do rozmów. Zakuć jak najwięcej( ewentualnie pouczyć się pytań), dostać się do firmy a później i tak nie stosować tej wiedzy i w efekcie zapomnieć( a więc warunki ZZZ spełnione). Co mogłoby się wydawać dziwne takie osoby są chętnie brane do różnych firm.
Czy dobre firmy są odporne na takich "wykutych wymiataczy" z ograniczonymi umiejętnościami praktycznymi?
Ja osobiście nigdy nie uczę się na pamięć. Ba nawet przed rozmową kwalifikacyjną się nie uczę, idę na żywioł i jakoś pod względem technicznym zawsze dobrze wypadam. Czasem człowiek coś się fajnego dowie od doświadczonych kolegów. Często też na rozmowach kwalifikacyjnych programiści sami zadają pytania takie już wykute - to znaczy mają ułożony plan działania. Ostatnio na dwóch rozmowach wprowadziłem takie coś, że ja po pytaniu zadanym przez programistę sam je przekształcałem w pytanie do niego, na które on nie potrafił odpowiedzieć. Bardzo zabawna sytuacja wówczas powstaje :) Najfajniejsza rozmowa techniczna trwała u mnie 2 godziny gdzie spotkałem programistę z którym właściwie wspólnie toczyliśmy dyskusje jak rozwiązać pytania. Ja odpowiadałem on również wtrącał dwa słowa, a ja potem sam poddawałem tą kwestię w wątpliwość. Super to była dyskusja.
Jeśli w rekrutacjach padają pytania o fundamentalne podstawy z javy czy tam sql ale pytanka są powymyślane w ten sposób, że są to rzeczy praktycznie nigdy albo bardzo rzadko wykorzystywane to można by się tylko zastanawiać nad tym co takie podejście ma na celu?
Nie sądzę. Wydaje mi się raczej, że to jak z maturą, która również miała mierzyć to co człowiek umie, a jest dość słaba w tym temacie. Ktoś kto jest dobry w programowaniu może wyjść słabo w maturze z informatyki, ktoś kto się interesuje historią, może mieć słabą maturę z historii, dodajmy do tego test inteligencji, który też raczej nie zmierzy tego, czy ktoś jest rzeczywiście inteligentny.
Dlatego też ciężko jest wymyślić dobre pytania sprawdzające czy programista się nadaje do pracy. Od czasu do czasu widuję anglojęzyczne artykuły-ranty na ten temat, więc to chyba nie dotyczy tylko polskiego podwórka. To jeden z większych problemów współczesnego IT.
Chociaż dla niektórych ten problem to szansa na zarobek. Tak działają strony typu Codility. Czemu Codility jest tak popularne? Wystarczy spojrzeć na ich slogan - "Hiring programmers made easy" ;) obietnica wartości jest taka, że dzięki Codility łatwiej będzie oszacować czy ktoś się nadaje czy nie (niezależnie od tego czy to prawda - chodzi raczej o to, że Codility, czy podobne rozwiązania obiecują rozwiązania bolączek, srebrną kulę na problemy związane z rekrutacją programistów, dlatego jest to popularne, bo ludzie chcą wierzyć, że ich problemy da się rozwiązać w łatwy sposób)
Czy to nie chodzi przypadkiem o budowanie sobie takiej otoczki profesjonalizmu w celu pokazania klientom jaką to profesjonalną kadrę się zatrudnia?
To już co innego trochę. Ta otoczka profesjonalizmu owszem jest czasem, ale raczej bardziej ulotna. Nie chodzi o to, że ktoś przygotowuje jakieś dziwne pytania (jeśli się pojawiają dziwne pytania z kartki, to często wynika to z tego, że w sumie nie wiadomo do końca jak przetestować danego programistę, obiektywna trudność).
Raczej wydaje mi się, że ta "otoczka profesjonalizmu" czasem wynika sama z siebie, kiedy rekrutujący świeżaków programiści chcą się dowartościować, jacy to oni są lepsi i profesjonalni. Wtedy owszem, mogą o coś spytać tylko po to, żeby pokazać kandydatowi, że nic nie umie i nie ma doświadczenia (kiedyś mnie o znajomość Redmine pytali na rozmowie XD jakby to była jakaś super trudna rzecz do nauczenia się. No ale to była akurat taka rozmowa, że ogólnie miałem wrażenie, że chcą się powywyższać jacy to doświadczeni są (ja wtedy szukałem jeszcze swojej pierwszej pracy jako programista)). Zwykła psychologia i karmienie ego, a nie zaplanowane działanie.
No bo jeśli mamy zwykłą rekrutację, to zwykle jest rozmowa z panią z HR, której się chce rekrutować, bo na tym polega jej praca, i mamy rozmowę z osobami technicznymi, programistami, którym się czasami chce, czasami nie. Programista nie jest osobą, która na codzień się zajmuje rekrutacją i może mu się nie chcieć, albo być mrukiem. Wtedy padają dziwne pytania.
Co zaś do pytań praktycznych, studenciaki chyba nie mają raczej pojęcia o wzorcach projektowych
Studenciaki politologii w sumie nie muszą mieć, ale od studenta informatyki już bym jednak wymagał tej znajomości.
Fajnie ze macie wlasne zdanie tylko pamietajcie, iz sporo bardzo madrych osob zadaje pytania w taki sposob, ze na pewno byscie stwierdzili ze sa beznadziejni albo chca podbudowac wlasne ego... Zadanie dziwnego pytania, sprawdzanie wiedzy na temat czegos co praktycznie nigdy nie jest wykorzystywane czesto ma za zadanie tylko rozpoczecie dyskusji. W dobrych firmach znalezienie nowego pracownika jest bardzo trudne - poniewaz stawiaja wysoko poprzeczke. Co nam da jeden dodatkowy pracownik jesli zle wplynie na caly zespol?
Z drugiej strony zdaje sobie sprawe ze jest sporo miernych rekrutacji - no ale wiekszosc firm od "miernej" rekrutacji to tak naprawde wypozyczalnie programistow, dla ktorych niewazny jest poziom pracownika - liczy sie tylko czy klient za niego zaplaci.
Co do glownego pytania - dobre firmy gdzie rekrutacja jest wazna z latwoscie zauwaza czy ktos ma wiedze praktyczna czy nie.
Na sam koniec - tak nazekacie na implementacje sortowania - a z tego co pamietam Ayende (od RavenDB) jako jedno z zadan dawal implemetnacje wlasnego indeksu dla duzego pliku teksotwego...
tamtamtu napisał(a):
Na sam koniec - tak nazekacie na implementacje sortowania - a z tego co pamietam Ayende (od RavenDB) jako jedno z zadan dawal implemetnacje wlasnego indeksu dla duzego pliku teksotwego...
co prawda Ayende nie jestem ale tez czesto daje na zadanie implementacje indeksowania czegos bo akurat jest to dosc czesto pojawiajacy sie problem w moich projektach, nie chodzi mi o zastosowanie konkretnego algorytmu ale o dyskusje, okreslenie doswiadczenia, sprawdzenie toku myslenia oraz jakosci i wydajnosci kodu. kazac komus zaimplementowac quick czy merge sorta jest o tyle bezsensowne ze sprawdza to wylacznie fakt czy kandydat jest zdrowo pieprzniety na punkcie klasycznych algorytmow i zna je na pamiec, bo praktycznie nikt nigdy nie potrzebuje tego pisac (poza kolokwium)
IMHO najlepsze co firma może zrobić to dać do domu w miarę praktyczne i w miarę ciekawe zadania z dziedziny związanej z pracą. Dzięki temu widzi się:
- jaki styl kodu ktoś pisze
- czy go testuje
- czy go dokumentuje
- jakich struktur danych używa
- czy dba o wydajność
- czy sprząta po sobie
- jak przebiega jego tok myślenia
Do tego zadania stanowią punkt wyjścia do dalszej dyskusji na rozmowie.
IMHO najgłupszym sposobem testowania wiedzy (i niestety obecnie najpopularniejszym) są testy codility: - zadania codility są nudne, schematyczne i oderwane od rzeczywistości
- nie sprawdzają jakości kodu - zadania często zawierają się w kilkunastu do kilkudziesięciu linijek - jedyną trudnością jest wymyślenie formuły matematycznej, która rozwiąże problem. Gdy się to już ma - implementacja najczęściej jest trywialna
- problem jest przedstawiony w mocno sformalizowany sposób - sytuacja odwrotna niż w rzeczywistości
- większość zadań z codility są już umieszczone na necie wraz z rozwiązaniami - idealna sytuacja dla oszustów.
tamtamtu napisał(a):
Fajnie ze macie wlasne zdanie tylko pamietajcie, iz sporo bardzo madrych osob zadaje pytania w taki sposob, ze na pewno byscie stwierdzili ze sa beznadziejni albo chca podbudowac wlasne ego... Zadanie dziwnego pytania, sprawdzanie wiedzy na temat czegos co praktycznie nigdy nie jest wykorzystywane czesto ma za zadanie tylko rozpoczecie dyskusji. W dobrych firmach znalezienie nowego pracownika jest bardzo trudne - poniewaz stawiaja wysoko poprzeczke. Co nam da jeden dodatkowy pracownik jesli zle wplynie na caly zespol?
Dobra ale nie każdy ma takie ambicje (albo chęci) żeby startować do takich firm jak Google, Facebook, Apple czy tam Microsoft, poprzeczka jest ustawiona bardzo wysoko a rekrutacje wieloetapowe i bardzo trudne. Niemniej jednak senior developer (taki z prawdziwego zdarzania), jeśli jest rekrutowany, ze względu na ogromną wiedzę i doświadczenie powinien być chyba dobrym kandydatem (sprawdzony). Odrębna sprawa to to czy faktycznie jest zapotrzebowanie na takich czy też lepiej takiego zastąpić skończoną ilością studentów.