spin napisał(a)
I własnie dlatego ich zadawać nie wolno. Oczywiście, ze wolą osobe bez rodziny, która odda się pracy bez reszty, a nawet w świeta przyjdzie popracowac jak trzeba... A to zakrawa o dyskryminacje osób, ktore rodzine maja...
Albo na wykorzystywanie osób które rodziny nie mają :-)
I własnie dlatego ich zadawać nie wolno. Oczywiście, ze wolą osobe bez rodziny, która odda się pracy bez reszty, a nawet w świeta przyjdzie popracowac jak trzeba... A to zakrawa o dyskryminacje osób, ktore rodzine maja...
No tak, ale zdarza się że szukają właśnie osoby mobilnej , oferując jednocześnie dużą płacę, więc jak się mają tego dowiedziec ? ;p
Mnie by takie pytania nie uraziły, i bym odpowiedział na nie jakby było trzeba ; )
No tak, ale zdarza się że szukają właśnie osoby mobilnej , oferując jednocześnie dużą płacę, więc jak się mają tego dowiedziec ? ;p
Zapytać wprost? Mnie się pytali czy pasują mi częste wyjazdy.
Krolik napisał(a)
Chyba nie pomylił, bo w C# są konwersje typów implicit, podobnie jak w C++.
To nie jest konwersja implicit, tylko sztuczka kompilatora :)
(mniej kodu, ale czasem denerwujące jak się trzeba domyślać, czego się domyślił kompilator).
Mi też się to nie podoba, ale nie o to akurat chodzi. Jest szansa zadania głupiego pytania, na którym może odpaść ktoś naprawdę zajebisty, tylko dlatego, że akurat takiej nic nieznaczącej pierdoły nie wiedział.
EgonOlsen napisał(a)
Po co pan chodzi do pracy?
I co tu takiemu odpowiedziec :D
Po to, aby swoją wytężoną pracą sprawiać, że firma się rozwija i jest coraz lepsza. Po to, by się do końca poświęcić i zatracić we wspólnym celu, jakim jest sukces firmy. ;P
Zapytać wprost? Mnie się pytali czy pasują mi częste wyjazdy.
No prawda w sumie ;)
Jednak tak czy siak ja bym odpowiedział na te pytania, problemu nie widzę ;p
A propos dziwnych pytań podczas rozmowy o pracę: Oto... Latający Cyrk Monty Pythona! ;]
Ale to się da załatwić pojedyńczym regex'em czy regexem w pętli?
W sumie nie chciałem, żeby ktoś tu próbował rozwiązywać ten problem tutaj na forum. Problem jest banalny i raczej każdy programista jest w stanie go rozwiązać wcześniej lub później. Przy rozmowie kwalifikacyjnej oprócz poprawności (i elegancji) rozwiązania oceniana jest też szybkość z jaką ktoś to napisał (tzn. czy się zastanawiał 10 minut, czy od razu wyjechał z dobrym kodem). Oczywiście na podstawie SAMEGO tego testu jeszcze nie można stwierdzic, czy ktoś jest dobry, ale można stwierdzić, czy ma obycie z SAMODZIELNYM pisaniem kodu (a nie przeklejaniem gotowców).
BTW. Z 3 odpowiedzi na tym forum, 2 były ok, a ta, którą zacytowałem kończy rozmowę kwalifikacyjną (tzn. gdyby ktoś próbował to robić regexpami).
@entity: Nie, tego problemu NIE DA się rozwiązać regexpem. A przynajmniej regexp nic nie uprości / ułatwi.
IMHO szybkość nie powinna być oceniana. Jeżeli ktoś bez zastanowienia wyjechał z dobrym kodem to znaczy albo, że rozwiązywał ten problem wcześniej, albo że się nie zastanowił i akurat trafił bo w zadaniu nie było jakichś haczyków. Gdyby były pewnie nie napisał by poprawnego kodu.
@rnd - w tym zadaniu NIE MA haczyka, nie jest to jedyne zadanie, a rozwiązanie zajmuje 5 może 6 linijek. Jedna pętla for, licznik i ze 3 warunki. Jeśli ktoś nie umie na poczekaniu wymyślić takiego kodu to jest dupa, nie programista. Oczywiście nikt nie mierzy czasu stoperem ("Zajęło to panu 45,08 s, o 0,08 s za dużo. Dziękujemy."), ale generalnie patrzy sie jak się ktoś do tego zabiera. Szybkość jest oceniana właśnie dlatego, że jeżeli rozwiązywanie takiego banalnego problemu zajmuje komuś dużo czasu, to ile zajmie mu rozwiązanie problemów, z którymi będzie się stykał w czasie normalnej pracy?
Programiści BARDZO różnią się produktywnością. Celem jest wyłapać, tych, którzy piszą kod szybko i dobrze.
Są ludzie, którzy mają obkute na pamięć połowę książek o J2EE, znają 100 wzorców projektowych i nazwy wszystkich kluczowych metod i klas Hibernate'a, mają 10 lat doświadczenia przy projektach, a i tak są mało produktywnymi programistami, bo jak im przychodzi to wszystko zastosować, to... brakuje pewnej części mózgu ;)
Joel Spolsky napisał o tym niezły felieton: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
Naprawdę warto przeczytać.
BTW: W normalnym programowaniu rzadko są "haczyki". W każdym razie nie ma takich haczyków, jak w zagadkach na inteligencję, gdzie albo widziałeś zagadkę wcześniej i znasz rozwiązanie, albo po prostu nie znasz.
somekind napisał(a)
EgonOlsen napisał(a)
Po co pan chodzi do pracy?
I co tu takiemu odpowiedziec :D
Po to, aby swoją wytężoną pracą sprawiać, że firma się rozwija i jest coraz lepsza. Po to, by się do końca poświęcić i zatracić we wspólnym celu, jakim jest sukces firmy. ;P
Wlasnie zlapales -3 punkty. Dla pieniedzy misiu, dla pieniedzy :P
@Królik - wiem, że w tym zadaniu nie ma haczyków. Ale na jednej rozmowie dostałem 2 zadania z haczykami. Jedno z nich to było napisać program, który liczy szereg maclaurina (wzór był podany). Można było od razu zacząć pisać ze wzoru i wyprodukować mniej efektywny kod, który liczy każdą silnie od początku. A można było trochę pomyśleć i od razu zoptymalizować.
Sęk w tym, że nie wiadomo czy zadanie ma haczyk czy nie ma więc trzeba się chwile zastanowić.
@rnd nie wiem czy to aż taki wielki haczyk, bo takie zadanie dostaliśmy na kartkówce chyba gdzieś w okolicach 3 tygodnia studiów na Wstępie do Informatyki (dokładniej było to obliczanie cosinusa z rozwinięcia w szereg maclaurina). Jeśli ktoś nie wpadł na to ze wyliczając kolejny wyraz wystarczy poprzedni pomnożyć i podzielić odpowiednio to dostawał 0 pkt. Czas na to zadanie to było jakieś 10-15min.
Przy okazji tematu:
http://www.codinghorror.com/blog/archives/000781.html
U poprzedniej firmie rok temu byly rozmowy, bralem udzial w jednej z nich. Otoz pacjenci dostawali na twarz pytania z SCJP, ale nie z tych latwych, ale takie trudniejsze. Szczytem bylo danie lasce kartki A4 z kodem zrodlowym, 3 klasy, dosc mala czcionka - klasa glowna, implementacja runnable i jakistam obiekt z ktorego wspolnie korzystaja. Miala powiedziec czy dobrze wszystko zsynchronizowane jest. Myslala 5 minut moze i jej zabrali kartke i podziekowali.
To byla ostatnia rozmowa w ktorej bralem w tamtej firmie udzial po tym jak powiedzialem szefowi rekrutacji ze sa chyba poje^%$#, i ze on tez nie ma pojecia co tam jest zle i czy w ogole.
Niestety zdarzaja sie takie zonki. Dodam tylko ze nie przyjeli nikogo, a teraz sie borykaja z biurem 300m2 i 9 programistami w srodku. A byli na rozmowie dobrzy ludzie.
@Shalom - nie powiedziałem, że jest wielki. Już sam fakt, że można było zarobić 0 pktów za działające rozwiązanie świadczy o haczyku. Zadanie Królika raczej czegoś takie nie miało. Albo potrafisz rozwiązać albo nie.
@fąfel - z ciekawości - zdradzisz więcej szczegółów co było na tej kartce? 5 minut może być trochę mało, ale
umiejętność rozumienia kodu wielowątkowego i znajdywanie potencjalnych fuckupów w synchronizacji też jest istotna.
O ile ten kod miał sensowną strukturę i było dobrze opowiedziane co robi. Ale to już w dalszym etapie rozmowy, jak ktoś przejdzie "łatwe zadania". Inna sprawa, że większość przeciętnych programistów takich trudniejszych zadań z rekurencją, wskaźnikami i programowaniem współbieżnym nie umie (Joel pisał tylko o tych pierwszych dwóch, ale ja dodam programowanie współbieżne, bo to wymaga chyba też tego samego fragmentu mózgu).
Naprawde nie pamietam co to bylo. Cos w stylu zeby 2 watki robily cos na zmiane, jakies liczniki byly, wait() i notify(). Wiem ze niewiele to mowi, ale to bylo dosc dawno i od tego czasu widzialem wiele innego kodu ;d
Mimo wszystko nie uwazam zeby takie pytania na twarz byly dobre, poza tym bledy z synchronizacja robimy wszyscy (np przynajmniej mi sie zdarza) majac IDE przed oczyma, a tam kartka A4 nawet bez pokolorowanej skladni. Najlepsze jest to ze jak wzialem ta kartke to okazalo sie ze wait() nie jest wolany w bloku synchronized, a osoba pytajaca ("specjalista" Javy) nie zauwazyla tego bledu. Najsmieszniej bylo jak jeden koles odpowiedzial ze to jest zle, na wytrzeszcz oczu pytajacego wytlumaczyl dlaczego, po czym wstal, podziekowal i wyszedl.
no bo powiedzmy sobie szczerze - nikt wszystkiego w głowie nie ma - ważne, żeby świtało co może być nie tak - reszte załatwia jakieś źródło informacji.
//do tej pory byłem tylko na 3 rozmowach kwalifikacyjnych. Zadań jako takich nie miałem - bardziej rozmowy teoretyczne - a po co pan używał UML'a - jakie diagramy - w jakim narzędziu. W tej firmie co aktualnie pracuję pokazywałem jeszcze trochę kodu - bez pytań.
fąfel napisał(a)
Najsmieszniej bylo jak jeden koles odpowiedzial ze to jest zle, na wytrzeszcz oczu pytajacego wytlumaczyl dlaczego, po czym wstal, podziekowal i wyszedl.
Tak to najczesciej bywa. Dlatego u nas stosujemy bardzo proste testy praktyczne np.
CMyObject *pObj = new CMyObject();
pObj.MyMetyhod();
pObj = NULL;
delete pObj;
Co tu jest zle?
Taki tescik wystarczy zeby odrzucic tych co sie nie nadaja. Uwierzcie albo nie ale 99% ludzi nie potrafi znalezc bledow.
Z drugiej strony jak moze rozmowe kwalfikacyjna prowadzic ktos kto przez swoja niekompetencje nie dosc ze nie rozumie tematu to jeszcze zadaje do rozwiazania zadanie ktore samo w sobie jest zle? Czy to nie nadaje sie przypadkiem do sadu?
Nie robilem dawno w C++ ale tam sa zdaje sie 2 bledy - jeden to ze musi byc -> a nie . przy wywolaniu metody a drugi ze delete na nullu sie robi, czyli jest leak.
@EgonOlsen:
Takie testy testują jedynie znajomość języka programowania a nie umiejętności programowania.
Tzn. są przydatne, ale nie jako jedyne kryterium. Tego "." zamiast "->" można zwyczajnie nie zauważyć, zwłaszcza jak ktoś programuje dużo w C#, a w C++ miał przerwę np. rok. Co nie musi wcale oznaczać, że będzie cienkim programistą w C++.
Może się też pojawić wtedy problem, że te proste testy praktyczne przejdzie kilku programistów. I co wtedy? Zawsze jedno pytanie bardziej zaawansowane z trochę bardziej złożonym kodem (ale oczywiście też i większą ilością czasu na to i raczej nie na kartce bez kolorowania składni) jest ok, bo może się trafić, ktoś kto to zrobi. Ważne jednak, żeby nie testowało wiedzy encyklopedycznej z jakiejś wąskiej dziedziny - najlepiej, np. żeby gość miał do tego zadania kompa, IDE i Googla, czyli podobne warunki jak normalnie w pracy. Ewentualnie żeby mógł zadawać pytania, na które odpowiedź znajduje się w Googlach / dokumentacji w 5 sekund.
Stosujemy też pytania w stylu "jak byś zabrał się do rozwiązania danego problemu?", gdzie wiadomo, że nie ma pewnego rozwiązania, ale można sprawdzić, czy kandydat ma sensowne pomysły jak rozwiązać problem, i czy nie rozłoży rąk. Np. problemem może być, że "Od kilku dni niektórzy klienci raportują nam, że nie mogą się zalogować do systemu w godzinach wieczornych. Jakie działania podejmiesz?". Przy takim pytaniu można w trakcie udzielać wskazówek, np. jeśli gość odpowiedziałby, że sprawdziłby najpierw logi to dostałby odpowiedź "W logach systemu nie odnalazłeś żadnych komunikatów o błędach. Co robisz dalej?"
BTW: co do powyższego zadania to oprócz tych 2 błędów, ja bym jeszcze dodał, że używanie makra NULL w C++ to jest "bad style", bo jest zwyczajnie niepotrzebne. Używa się 0. Makro NULL w C++ zwyczajnie nie ma sensu, bo jedyna jego możliwa definicja to:
#define NULL 0
Krolik napisał(a)
Tego "." zamiast "->" można zwyczajnie nie zauważyć.
Jesli ktos nie umie wylapac takich rzeczy to nie ma tu czego szukac.
Krolik napisał(a)
Może się też pojawić wtedy problem, że te proste testy praktyczne przejdzie kilku programistów. I co wtedy?
Wtedy reszty go nauczymy.
EgonOlsen napisał(a)
Jesli ktos nie umie wylapac takich rzeczy to nie ma tu czego szukac.
Przeciez to bez sensu, przy kompilatorze w ide w ciagu sekundy sie kapnie o co chodzi. Ty taki cwaniak moze jestes bo moze miales takie pytanie i dales rade, ale na wiele innych o podobnym stopniu trudnosci bys sie wylozyl (albo i nie, ale nie o to chodzi, nie znaczy to ze jestes super i sie wszedzie nadajesz).
Odpowiedz sobie na pytanie - lepiej miec w firmie czlowieka ktory mysli i jest po prostu dobry, mimo ze mial przerwe w C++ 3 lata i zrobil maluczki blad*, i moze sie szybko nauczyc wszystkiego, czy kogos kto zajebiscie zna skladnie C++ ale jest to osoba ktora nic wiecej nie umie, nie jest elastyczna itd. Czy eliminujecie kandydatow ktorzy tej strzalki nie skapneli? To wcale nie oznacza ze ktos nie zna wskaznikow, to oznacza ze tego nie zauwazyl.
Tak na marginesie, artykul Joela Z Polski naprawde ciekawy, jak zreszta caly blog. Dzieki za namiary Krolik.
Prosty, przykladowy kodzik z glowy taki zeby tylko pokazac poziom trudnosci a tyle rzucania sie?
Specjalista od psychotestow pewnie umialby to zdiagnozowac ale jak na moje przymruzone oko wyglada to jak zakuty leb.
No wiadomo, jestes najlepszy i nigdy sie nie mylisz.
Ale w sumie to od dawna jest to offtop.
Stanowisko: kompilator C++
Wymagania:
* wyłapywanie błędów w locie, reszty ciebie nauczymy
Jesli ktos nie umie wylapac takich rzeczy to nie ma tu czego szukac.
Jak jedyne co robicie to bugfix to pewnie faktycznie nie ma czego szukać :-P
Krolik napisał(a)
@EgonOlsen:
Takie testy testują jedynie znajomość języka programowania a nie umiejętności programowania.
Tzn. są przydatne, ale nie jako jedyne kryterium. Tego "." zamiast "->" można zwyczajnie nie zauważyć, zwłaszcza jak ktoś programuje dużo w C#, a w C++ miał przerwę np. rok. Co nie musi wcale oznaczać, że będzie cienkim programistą w C++.
Ja mam przerwę już 2 lata, a zauważyłem te błędy jeszcze zanim przeczytałem co tam autor o tym kodzie pisze :P Jeżeli to była rekrutacja na stanowisko C++ to bez wyłapywania takich rzeczy nie ma co przyjmować do pracy. Dopiero potem można sprawdzać inne umiejętności.
W języku z wskaźnikami wskazówki z IDE wam mało pomogą w kwestii wycieków pamięci.
mizol napisał(a)
- Tak, uwazam to za maluczki blad.
Przez takie małe błędy produkcja w fabrykach staje raz w tygodniu bo soft nią sterujący wywala się z out of mem i cała ekipa w pocie czoła tego szuka bugfix bo jakiś jełop designer wśród niej strzelił sobie happy commit'a. (PS. Wyprzedzając twoją argumentacje: nie, testy z reguły tego nie wykrywają bo mało kto ma zasobów żeby napisać konkretne testy obciążeniowe)
mizol napisał(a)
mimo ze mial przerwe w C++ 3 lata i zrobil maluczki blad*
Z takimi rzeczami w C++ to jak z jazdą na rowerze :P Jeżeli teraz tego nie widzisz to znaczy że dużo w konkretnych projektach na C++ żeś sobie nie popracował.
Uwazam to za maluczki blad bo to sie nie skompiluje. O to mi chodzilo.
pObj = NULL;
delete pObj;
^ to się skompiluje i głównie o to mi chodzi
A tak przy okazji:
endl napisał(a)
Jesli ktos nie umie wylapac takich rzeczy to nie ma tu czego szukac.
Jak jedyne co robicie to bugfix to pewnie faktycznie nie ma czego szukać :-P
^ Jedynie? Pójdziesz do pracy nad większymi projektami do zobaczysz co zajmuje najwięcej czasu w projekcie i co sprawia że menadżerce się włosy jeżą na głowie :P Na pewno nie projektowanie ani implementacja. Projekt może i być genialny ale jak ktoś strzeli ci totalnie nie banalnego bug'a, który propaguje ci przez pół systemu (i nie mówię tutaj o jakimś throw exception z niższych warstw) to dopiero poznasz gdzie masz geniuszy w ekipie.
Krolik napisał(a)
BTW: co do powyższego zadania to oprócz tych 2 błędów, ja bym jeszcze dodał, że używanie makra NULL w C++ to jest "bad style", bo jest zwyczajnie niepotrzebne. Używa się 0. Makro NULL w C++ zwyczajnie nie ma sensu, bo jedyna jego możliwa definicja to:
#define NULL 0
Lol. Idąc dalej za tą filozofią, WSZYSTKO to syntactic sugar i należy pisać tylko z goto.
0 - wartość liczbowa.
NULL - pusty adres.
I tak należy pisać. Informujesz wtedy czytającego, co przypisujesz. C++ nie wspiera 'wartości pustej' bezpośrednio - więc to właśnie kwestia dobrego stylu.
```cpp
Klasa {
X *y;
int z;
...
}
jakasMetoda() {
y = NULL; //automatycznie po przeczytaniu - aha, y to wskaznik - jesli chce wiecej szczegolow, najezdzam na nazwe myszką
z = 0; //aha, z to typ liczbowy
}
Podobna sprawa jest z asciiz - dobrym stylem jest pisanie rzeczy w stylu
x[0] = '\0';
zamiast = 0. Ale jeśli zakres jest bardzo mały i deklaracja jest blisko często to olewam.