Testy sprawdzające zdolność logicznego myślenia

Question

Witam wszystkich!

Staram się dostać na warsztaty do pewnej firmy. Zostałem zaproszony na testy z C++ oraz Pythona w poniedziałek, które według tego co mi powiedziano mają za zadanie sprawdzić zdolność logicznego myślenia a nie samego programowania. I tu pojawia się pytanie: jak to rozumieć ? Może miał ktoś podobny przypadek i może wyjaśnić na czym to polega ?

Answer 1

Całkiem niedawno pewna dziewczyna też starała się o pracę związaną z C++ i pytała czy ktoś ma dostęp do takich testów ;)
Raczej to nic nowego. http://rymszewicz.eu/post20130426/ - tu masz np mniej więcej pokazane o co chodzi

Comments

Już to sprawdzałem ale jednak w moim przypadku ma to się opierać o kodowanie

---

napisałeś:

mają za zadanie sprawdzić zdolność logicznego myślenia a nie samego programowania

więc teraz to się wyklucza, jak wspominasz o kodowaniu ;)
w każdym razie, ja tylko wiem o takich, jakie podałam wyżej. Może ktoś inny jeszcze się wypowie ;)

---

Szczerze? Jakby mi ktoś dał taki test, to bym tylko się zaśmiał i wyszedł. Co to ma niby wspólnego z programowaniem? I zanim ktoś mi odpowie, że programista musi mieć analityczny umysł: od kiedy "analityczny umysł" = rozpoznawanie, czy linia jest krzywa w lewo, czy w prawo?

---

no ale to co wstawiłam, to nie są zagadki logiczne?
bo czy mają coś wspólnego z programowaniem to w sumie nie wiem ;p
ale coś tam zawsze sprawdzają :D

---

Dokładnie tak jak pisze Comandeer, rozwiązałem ten test i uzyskałem 20 punktów, co według tabelki oznacza dużo powyżej średniej. Mam jednak wątpliwości.

Po pierwsze w wynikach jest napisane, że punktację należy liczyć tak: ilość poprawnych odpowiedzi (+3 jeśli nie ma żadnej złej odpowiedzi), co jest nielogiczne. Dlaczego? Jest 31 pytań. Można więc zyskać 31 punktów. Powyżej 20 punktów klasyfikujemy się jako wyjątkowi. To po cholerę dodawać 3 punkty do 31? Poza tym jak uzyskamy 31 punktów, to mamy maksimum, to jaki jest sens zwiększać maksymalny wynik?

Po drugie, niektóre zadania można rozwiązać inaczej (czyli klucz odpowiedzi może być inny). Na przykład dla zadania 25. poprawną odpowiedzią wg klucza jest E. Ja natomiast wybrałem B, ponieważ podział wielokąta odbywa się za pomocą trójkątów w każdym przypadku z wyjątkiem B. Odpowiedź E jest właściwa chyba dlatego, że figura stoi na płaskim. Czy to nie jest pomylone? Według mnie moja odpowiedź jest bardziej właściwa.

Po trzecie i ostatnie, jest za mało czasu. 600 sekund na 31 zadań oznacza, że na zadanie mamy niecałe 20 sekund. Weźmy zadanie 30., które akurat miałem dobrze. Trzeba zauważyć, że kwadrat to zegarek i ma dwie wskazówki. W każdym kroku obracamy pierwszą wskazówkę o 90 stopni, a drugą o 315 stopni (obie zgodnie z ruchem wskazówek zegara). Żeby na to wpaść i sobie to wyobrazić, i przewidzieć kolejny krok, to trzeba trochę więcej czasu niż 20 sekund.

---

No właśnie to jest dziwne. Powiedziano mi, że testy nie mają za zadanie sprawdzać umiejętności programowania tylko sprawdzić zdolność logicznego myślenia. Myślałem, że nie będą mieć nic wspólnego z kodzeniem ale jednak usłyszałem, że logiczne myślenie będą sprawdzać w oparciu o kodowanie. Dlatego też moje pytanie bo już sam się w tym pogubiłem i nie wiem co myśleć 

---

Według mnie, takie testy w ich istocie nie są złe, tylko ich forma jest zła. Test sam w sobie jest rozwijający i może być pomocny przy rekrutacji, o ile zostanie prawidłowo przeprowadzony.

Co do złej formy - tutaj widzę dwa "zarzuty", które już wcześniej padły. Myślę, że pierwszy z nich wypada nazwać i doprecyzować, czyli: odpowiedzi na pytania nie mogą być kluczowane. Każda odpowiedź powinna zostać uargumentowana przez rozwiązującego. To dałoby pogląd na sposób myślenia i pozwoliłoby na (mniej lub bardziej) sprawiedliwą ocenę.
Drugą sprawą jest czynnik ograniczonego czasu, o którym wspomniał Benek i o którym chyba nie ma sensu więcej pisać. :)

---

Test sam w sobie jest rozwijający i może być pomocny przy rekrutacji, o ile zostanie prawidłowo przeprowadzony.

Co jest rozwijającego w wyborze odpowiedniego kwadratu dla kogoś, kto zajmuje się na co dzień architekturą aplikacji opartych na React choćby? 

---

Nie ma to związku z "architekturą aplikacji opartych na React". Nie na tym to polega. W takim teście masz znaleźć rozwiązanie pewnego problemu. Być może głupiego, tego nie podważam. Ale zostajesz postawiony przed abstrakcją, powinieneś wyłuskać z niej pewien wzorzec i znaleźć rozwiązanie (które nie jest zapisane w kluczu, jak pisałem wyżej). To pomaga rozwinąć sposób myślenia. A wymóg, żeby każda odpowiedź była uargumentowana, pomaga w wyćwiczeniu precyzowania i wyrażania myśli.

Przykład: ludzie grają w szachy, żeby poprawić zdolność przewidywania, zapamiętywania i podejmowania szybkich decyzji (przykładowy link do "pierwszej lepszej" publikacji)... chociaż w rzeczywistości przecież nie pracują na szachownicy (wyjmijmy stąd zawodowych graczy). To co, jednak gra w szachy nie ma sensu i nie jest rozwijająca?

---

To czemu rekrutacja nie polega na wygraniu partii szachów?

Odpowiedź jest prosta: bo to nie jest praktyczny problem. Co z tego, że znajdzie się gościa, który rozkmini algorytm do łatwego rozwiązywania zadań logicznych skoro polegnie przy projektowaniu rozwiązania, które musi być wydajne na desktopie i mobilnych? Przecież takie totalnie oderwane od rzeczywistości problemy niczego nie mówią o kandydacie – zwłaszcza jeśli mówimy o tak specyficznym środowisku pracy jak przeglądarka.

Można umieć napisać na kartce własny język z własnymi zasadami gramatycznymi i zachwycić tym rekrutera, a potem polec na prawidłowym zakodowaniu okienka dialogowego tak, żeby było dostępne. I uwierz mi, że te 3h poświęcone na wymyślenie tego języka zarówno rekruter jak i rekrutowany mogli spędzić efektywniej.

---

Napisałem, że taki test może być pomocny w rekrutacji (specjalnie jeszcze podkreśliłem), a nie że rekrutacja ma na nim polegać.

---

No ale trzeba go rozwiązać, więc tak czy siak na tym to polega – tracisz na to czas.

Ba, takie podejście może szkodzić w rekrutacji, bo np. odsieje się kogoś, kto Reacta/Symfony/inny framework wsysa nosem, a kod tworzy tak piękny, że aniołowie płaczą ze szczęścia, ale nie miał szans, bo wybrał czerwony kwadrat zamiast zielonego. I jeszcze stracił na to czas i nerwy.

---

Chyba się nie zrozumieliśmy. Wydaje mi się, że za bardzo sprowadzasz "rekrutację" do "rekrutacji na stanowisko programisty".

Wszystko zależy od specyfiki przypadku. Jeśli potrzebuję kogoś, kto ma mi pisać ładny kod, wtedy patrzę na to, jak i co pisze. Jeśli zaś potrzebuję, dajmy na to, inżyniera systemów oprogramowania, stawiam przed nim abstrakcję i oczekuję rozwiązania. I nie, wynik testu nie miałby tutaj znaczenia priorytetowego. Ale nie powiesz mi chyba, że osoba, która ma budować system informatyczny, nie będzie potrafiła znaleźć argumentacji, dlaczego wybrała tę odpowiedź, a nie inną?

Są potrzebni ludzie do opracowania rozwiązań, jak i do implementacji tych opracowań. Zgodzisz się, że są to dwie różne dziedziny? Może tutaj się mylę, ale dotąd wydawało mi się, że są to problemy innej klasy.

Zostawmy kwestię rekrutacji, bo chciałbym coś wyjaśnić. Odebrałem Twoją wypowiedź mniej więcej tak, że testy są złe, bo rekrutacja ma nie na tym polegać... Można się z tym zgadzać, można się nie zgadzać, można się zgodzić częściowo. Ale ja swoim pierwszym komentarzem chciałem tylko wskazać ich użyteczność, jako środka do rozwoju intelektualnego.

---

Ale ja swoim pierwszym komentarzem chciałem tylko wskazać ich użyteczność, jako środka do rozwoju intelektualnego.

No to się rozwijaj… poza rekrutacją :P Ja, gdy się rekrutuję, to znaczy, że szukam pracy, a nie chcę się rozwijać. Niby subtelne przesunięcie priorytetów, niemniej robi różnicę – i to sporą.

 Ale nie powiesz mi chyba, że osoba, która ma budować system informatyczny, nie będzie potrafiła znaleźć argumentacji, dlaczego wybrała tę odpowiedź, a nie inną?

Akurat to leży obok problemu. Problemem są same pytania, które są niewłaściwe. A na niewłaściwe pytanie często nie da się znaleźć argumentacji.

Wszystko zależy od specyfiki przypadku. Jeśli potrzebuję kogoś, kto ma mi pisać ładny kod, wtedy patrzę na to, jak i co pisze. Jeśli zaś potrzebuję, dajmy na to, inżyniera systemów oprogramowania, stawiam przed nim abstrakcję i oczekuję rozwiązania. I nie, wynik testu nie miałby tutaj znaczenia priorytetowego. 

I serio w temacie programowania systemów oprogramowania nie ma wystarczającej liczby abstrakcji, że trzeba sięgnąć takie testy? Jak chcesz użyteczne abstrakcje, to pogadaj sobie o design patterns. Rozmowa na długie godziny, w której zawsze każda ze stron czegoś ciekawego się dowie… a i pokłócić się idzie – i to sensownie ;)

Można postawić problem typu "rozważ architekturę dla systemu klient-serwer w środowisku mobilnym bla bla" i już jest wystarczający poziom abstrakcji.

Są potrzebni ludzie do opracowania rozwiązań, jak i do implementacji tych opracowań.

Zgadzam się, ale kwadratu na całą architekturę nie pomalujesz. Jakbyś nie próbował.