Chcialem prosic grupowiczow o zasugerowanie dobrych pytan na interview dla
programisty, sprawdzajacych "wiedze ogolna" i ogolne obycie w dziedzinie (nic co
byloby specyficzne dla jezyka czy technologii).

RW

do góry

W dniu 2012-07-17 10:51, Roman W pisze:
> Chcialem prosic grupowiczow o zasugerowanie dobrych pytan na
> interview dla programisty, sprawdzajacych "wiedze ogolna" i ogolne
> obycie w dziedzinie (nic co byloby specyficzne dla jezyka czy
> technologii).

Przy tak nikłej wiedzy i tak ciężko będzie zweryfikować poprawność
odpowiedzi. W takim przypadku, jedyne co mogę polecić, to sprawdzenie
wykształcenia i dokonań. Obycie i wiedzę ogólną może jako tako sprawdzić
jedynie ten kto ją posiada.


--
Kaczus
http://kaczus.republika.pl

do góry

On 2012-07-17, Roman W <b...@g...pl> wrote:
> Chcialem prosic grupowiczow o zasugerowanie dobrych pytan na interview
> dla programisty, sprawdzajacych "wiedze ogolna" i ogolne obycie w
> dziedzinie (nic co byloby specyficzne dla jezyka czy technologii).

Zależy od charakteru stanowiska.
Jeśli do projektowania interfejsów, to pokaż mu kilka i niech wybierze
ten najlepszy. Albo niech chwilę poużywa tego, który będzie miał
rozwijać i powie, co według niego wymaga poprawienia :).

Jeśli do jakiejś algorytmiki/optymalizacji itp, to po prostu daj mu
prosty, przykładowy problem. Nie każ mu rozwiązywać go na kartce, tylko
spytaj jak by to zrobił. Będziesz mógł ocenić nie tylko poprawność
pomysłu, ale też sposób dochodzenia do rozwiązania.

Zawsze niezłym i uniwersalnym pomysłem jest pokazanie fragmentu kodu.
Są dwa sensowne warianty:

1) Możesz pokazać pseudokod z ewidentnymi błędami i spytać co kandydat
o nim myśli. Przykłady:
- pętla, z której program nigdy nie wyjdzie (standard :)),
- warunek który zawsze odcina fragment kodu lub przerywa program
(np. robi coś, gdy x>3, ale x jest zawsze ujemny :)),
- kod pod if'em ustala jakąś zmienną niezbędną w dalszej części
programu, ale dla części warunków początkowych ta instrukcja
w ogóle nie zostanie wykonana

2) Możesz pokazać kod w języku, którego kandydat nie zna i spytać
co ten kod robi :). Oczywiście musi to być prosty program bez jakichś
tricków i specyficznych konstrukcji.

pozdrawiam,
PK

do góry

Dnia Tue, 17 Jul 2012 01:51:00 -0700, Roman W napisal:

> Chcialem prosic grupowiczow o zasugerowanie dobrych pytan na interview
> dla programisty, sprawdzajacych "wiedze ogolna" i ogolne obycie w
> dziedzinie (nic co byloby specyficzne dla jezyka czy technologii).

Zacząłbym od pytań sprawdzających wiedzę ogólną, czyli bardzo różnych
pytań dotyczących wiedzy, szczegółowych i ogólnych. To pozwala
sprawdzić nie tylko "co kandydat wie", ale ponieważ taką serię
można bez problemu ciągnąć przez 30 minut czy godzinę można
nie tylko wiele rzeczy zauważyć, ale to też "ładuje do cache"
całą dziedzinę, o której podczas drogi na spotkanie nikt nie myślał.

Potem ma się wyeliminowane wszystko poza spotkaniem i tematem
i można przystąpić do rzeczy, czyli zrobić jakieś proste
testy, sprawdzić jak kandydat sobie radzi, jak rozwiązuje problemy
itd.

Edek

do góry

co z ciebie za wyborca Donalna Tuska i Hanny Gronkiewicz Waltz... to chyba
oczywiste, ze pytania nie maja miec zwiazku z czymkolwiek, na temat czego
cos w ogóle mozna powiedziec...

proponuje mój watek na sieciach, jak nie wiesz o co pyta Tusk i
Gronkiewicz... dodam eksperci we wszystkim...

do góry

On Tuesday, 17 July 2012 09:51:00 UTC+1, Roman W wrote:
> Chcialem prosic grupowiczow o zasugerowanie dobrych pytan na interview dla
programisty, sprawdzajacych &quot;wiedze ogolna&quot; i ogolne obycie w dziedzinie
(nic co byloby specyficzne dla jezyka czy technologii).
>
> RW

Oczywiście to zależy jaki poziom ogólnej wiedzy i obycia jest oczekiwany.

Ogólnie, według mnie bardziej sensowne są otwarte pytania typu "opowiedz,
co wiesz o..." niż konkretne typu "podaj definicję".

Kilka sugestii:
"Jak działa komputer?"
"Jak działa wielozadaniowy system operacyjny?"
"co to jest automat skończony (state machine)?"
"co to jest maszyna Turinga?" (wybadać czy słyszał o obliczalności, problemie
stopu, turing-completeness itd.)
"jak zbudowany jest kompilator?" (można przy okazji zobaczyć co wie o gramatykach,
notacjach)
"jakie znasz paradygmaty programowania?" (na czym polega OOP, co to jest
programowanie imperatywne i deklaratywne, statyczne i dynamiczne, czy
słyszał o programowaniu funkcyjnym itd.)
"co wiesz o złożoności obliczeniowej?"
"jakie znasz kontenery danych? jak się je implementuje?"
"co wiesz o programowaniu współbieżnym?"
"jakie są według ciebie dobre praktyki, których powinien trzymać sie
programista?"
"jak programista może testować swój kod?"
"co zrobić, żeby stworzyć program, który robi to, co powinien robić?"

Oczywiście problem jest taki, że na każde z tych pytań można długo odpowiadać,
a czas jaki można poświęcić na interview jest skończony. Nie mam szczególnie w
takiej sytuacji zdania, czy lepiej zadać mniej pytań, a zostawić więcej czasu
na każdą odpowiedź, czy ucinać rozmowę na dany temat po kilku minutach i
przechodzić do kolejnych pytań. Na pewno warto wziąć przyjnajmniej jedno z
pytań, w którym kandydat się dobrze czuje, i rozwinąć w dyskusję. OTOH, jak
widać, że w danym temacie nie ma nic ciekawego do powiedzenia, to nie ma co
wałkować i można przejść do kolejnego.

do góry

W dniu wtorek, 17 lipca 2012 15:22:08 UTC+2 użytkownik Andrzej Jarzabek napisał:

> Na pewno warto wziąć przyjnajmniej jedno z
> pytań, w którym kandydat się dobrze czuje, i rozwinąć w dyskusję.

Dla mnie to jest wystarczająca strategia. Pytam kandydata o projekt, z którego jest
najbardziej dumny - jawnie przy tym rozszerzam zakres, że chodzi nie tylko o
doświadczenie zawodowe, ale również o uczelniane, open-source, itd.
Ponieważ to ma być projekt, który mu zapewnił największą satysfakcję, to będzie
chętnie o nim mówił - wtedy ciągnę za różne zwisające sznurki i dopytuję o
architekturę, uzasadnienie wyborów rozwiązań z dostępnych alternatyw, "co by było
gdyby", itp.
Przy takiej formie można sprawdzić nie tylko czyjeś kompetencje, ale też czy kandydat
potrafi coś opisać i przekazywać informacje - to jest nie mniej ważne, niż sama
wiedza, bo akurat wiedzę można nabyć (lub uzupełnić) stosunkowo łatwo.
Nie jestem fanem testów ani innych rebusów, uważam je za słabą metodę sprawdzania
czegokolwiek.

> jak
> widać, że w danym temacie nie ma nic ciekawego do powiedzenia, to nie ma co
> wałkować

Właśnie dlatego pytam o projekt, z którego jest najbardziej dumny. Nie ma opcji, żeby
nie miał nic do powiedzenia, chyba że pomylił spotkania, albo faktycznie nigdy
niczego takiego nie zrobił, co w sumie i tak oznacza, że pomylił spotkania.

Uwaga: tak, wiem, że ta metoda nie działa z ludźmi, którzy na każde pytanie o ich
doświadczenia odpowiadają "NDA". Trudno.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Tuesday, 17 July 2012 15:14:13 UTC+1, Maciej Sobczak wrote:
> W dniu wtorek, 17 lipca 2012 15:22:08 UTC+2 użytkownik Andrzej Jarzabek napisał:
>
> > Na pewno warto wziąć przyjnajmniej jedno z
> > pytań, w którym kandydat się dobrze czuje, i rozwinąć w dyskusję.
>
> Dla mnie to jest wystarczająca strategia. Pytam kandydata o projekt,
> z którego jest najbardziej dumny - jawnie przy tym rozszerzam zakres,
[...]
> Właśnie dlatego pytam o projekt, z którego jest najbardziej dumny.
> Nie ma opcji, żeby nie miał nic do powiedzenia, chyba że pomylił spotkania,
> albo faktycznie nigdy niczego takiego nie zrobił, co w sumie i tak oznacza,
> że pomylił spotkania.

W sumie może tak być, że ten, z którego jest najbardziej dumny był też już dawno temu
i szczegółów (np. architektury) nie pamięta.

> Uwaga: tak, wiem, że ta metoda nie działa z ludźmi, którzy na każde pytanie
> o ich doświadczenia odpowiadają "NDA". Trudno.

Druga sprawa przy takim pytaniu jest taka, że nawet jeśli nie odpowiadają NDA, to
mogą być aspekty, o których wolą nie mówić na rozmowie, czy to właśnie z powodu NDA,
czy też choćby po prostu dlatego, że nie chcą zdradzać różnych szczegółów dotyczących
swojego poprzedniego/dotychczasowego pracodawcy, np. planów strategicznych, czy też
mówić rzeczy stawiające kolegów, szefów czy całą firmę w złym świetle i tak dalej.
Nie mówię, że nie da się w takiej sytuacji mówić o tych projektach, ale jeśli ktoś
nie mówi swobodnie, pilnuje się, to może wypadać mało, że tak powiem, entuzjastycznie
i np. gorzej od kogoś, kto albo nie ma takich oporów, albo nie ma takich okoliczności
w związku z danym projektem.

Nie mówię, że to złe pytanie, ale wydaje mi się, że czasem nie będzie to właśnie tym
pytaniem, które będzie najlepszym punktem wyjścia do swobodnej dyskusji.

do góry

Dnia Tue, 17 Jul 2012 07:14:13 -0700, Maciej Sobczak napisal:

>> jak widać, że w danym temacie nie ma nic ciekawego do powiedzenia, to
>> nie ma co wałkować
>
> Właśnie dlatego pytam o projekt, z którego jest najbardziej dumny. Nie ma
> opcji, żeby nie miał nic do powiedzenia, chyba że pomylił spotkania, albo
> faktycznie nigdy niczego takiego nie zrobił, co w sumie i tak oznacza, że
> pomylił spotkania.

Istnieje też inna opcja, że nie ma pojedynczego projektu, z którego ktoś
jest dumny. Być może dlatego, że nie przywiązuje wagi do PR i chęci
posiadania czegoś, pod czym widniałoby jego nazwisko. Jak ktoś chce to
uznać za "inne" to droga wolna, natomiast nie widziałbym w tym
problemu z jakimikolwiek umiejętnościami.

> Uwaga: tak, wiem, że ta metoda nie działa z ludźmi, którzy na każde
> pytanie o ich doświadczenia odpowiadają "NDA". Trudno.

Umiejętność dyplomatycznej odpowiedzi zamiast wprost "nie powiem bo nie
mogę" ja akurat cenię.

Edek

do góry

On 2012-07-17, Edek Pienkowski <e...@g...com> wrote:
> Dnia Tue, 17 Jul 2012 07:14:13 -0700, Maciej Sobczak napisal:
>
>>> jak widać, że w danym temacie nie ma nic ciekawego do powiedzenia, to
>>> nie ma co wałkować
>>
>> Właśnie dlatego pytam o projekt, z którego jest najbardziej dumny. Nie ma
>> opcji, żeby nie miał nic do powiedzenia, chyba że pomylił spotkania, albo
>> faktycznie nigdy niczego takiego nie zrobił, co w sumie i tak oznacza, że
>> pomylił spotkania.
>
> Istnieje też inna opcja, że nie ma pojedynczego projektu, z którego ktoś
> jest dumny. Być może dlatego, że nie przywiązuje wagi do PR i chęci
> posiadania czegoś, pod czym widniałoby jego nazwisko.

Wątpliwe. Można być dumnym przez to, że projekt odniósł sukces i jest
rozpoznawany jako robota kandydata, ale można być dumnym z projektu,
który może i zdechł, ale miał szalenie ciekawe rozwiązania albo się
w niego włożyło kawał dobrego kodu. Maciek oczekuje przede wszystkim
drugiej sytuacji (choć nie znaczy to, że ma coś przeciwko pierwszej).

Przepraszam, Maćku, że piszę w twoim imieniu, ale chyba dobrze cię
przewiduję?

>> Uwaga: tak, wiem, że ta metoda nie działa z ludźmi, którzy na każde
>> pytanie o ich doświadczenia odpowiadają "NDA". Trudno.
>
> Umiejętność dyplomatycznej odpowiedzi zamiast wprost "nie powiem bo nie
> mogę" ja akurat cenię.

Nie chodzi o dyplomację, tylko o ludzia, który w ogóle nie opowiada
o swoim doświadczeniu zasłaniając się wyłącznie NDA.

--
Secunia non olet.
Stanislaw Klekot

do góry