leszek wrote:
> Ktoś swieżo po kursie C++ sobie poradzi, gdyż pewnie na kursach sie rozwiązuje
> takie łamigłówki w dużych ilościach. Ale w praktycznym programowaniu tego typu
> 'tricky' programming trzeba unikac jak ognia, bo jak nawtykasz takich bamboli,
> to sam diabeł potem nie rozwikła co tam się na końcu liczy i dlaczego.

Właśnie... doszedłem do drugiego etapu, ale ostatecznie dostałem
negatywną odpowiedź (spartaczyłem, naprawdę spartaczyłem rozmowę z osobą
z HR). To był właśnie problem, że w tych testach (i na samej rozmowie
też) nie było jak się wykazać praktyczną wiedzą z programowania - być
może to by coś zmieniło.

Mam podobne zdanie, co kolega - te testy sprawdzały/ją tylko i wyłącznie
książkową wiedzę na temat języków. W ogóle zauważyłem, że jest kilka
problemów (z c/c++, java), których na pewno można się spodziewać /wide:
#define kwadrat(x) x*x, brak case w switch/). Analiza programów to
pomyłka[1], co z tego, że wyklepie na pamięć tablice z priorytetami
operatorów, jak nie będę wiedział, jak debugować, odszukiwać błędy w
programie.

A Motorola - niech tworzą nowe testy :) . Testy, które pisałem same w
sobie miały parę nieścisłości, błędów, może zrobią lepsze.

A sama rozmowa - pełen profesjonalizm (może te testy) - tutaj właściwie
nie mam zastrzeżeń.

Miłego.

[1] to jest pewien sposób, ale bez przesady - 80% testu to same programy
do analizy? Na samej rozmowie było to samo, program - co nie działa, co
poprawić (blah, zaciąłem się na jednym).

--
Łukasz Góralczyk
http://liku.sdfpau.org