A czy w swojej pracy zdarza Ci się pisać aplikacje, w których trzeba tego arraya obracać?
Zastanów się może, co takiego robicie, a najlepiej poszperaj w swoich projektach i zastanów się, gdzie i kiedy miałeś jakąś zagadkę, albo miejsce, gdzie trzeba było pokombinować. Bo tak naprawdę to chyba najważniejszą cechą programisty jest myślenie, umiejętność rozwiązywania problemów itp. Podejrzewam, że w necie w 2 minuty znajdziesz gotowe funkcje, które tablicę obrócą lub inaczej przekształcą, więc nie jest to jakaś istotna/kluczowa sprawa.
Możesz też dać jakiś prosty kod, który został celowo popsuty. Niech koleś/kolesiówa postara się go naprawić. Zobaczysz jak myśli, kojarzy, kombinuje i jak sobie radzi w nietypowych sytuacjach.
Z tymi zagadkami, to faktycznie jest jakiś pomysł, ale ciężko będzie coś znaleźć co da się rozwiązać w maks 10-15min. Dodając stres może być kiepsko.
Chyba właśnie ciekawszą opcją by było dać do naprawy jakiś zepsuty kod i zobaczyć na jakie elementy zwróci kandydat uwagę i jak je naprawi.
Tu też możnaby kandydata podpytać dlaczego ten komponent został użyty, itp.
Czy zadania w stylu napisz metodę na odwrócenia array mają sens?
Nie. Napisz jakiś mały projekt, luźno powiązany z waszą pracą i np. zrób tam:
- klasę z pustymi metodami i testy do tego i poproś o dopisanie brakujących elementów, przy czym ty siedzisz tam razem z nim i robicie peer-programming albo jesteś tam jako jakiś analityk/product owner żeby odpowiedzień na "biznesowe" pytania ad brakujacej logiki
- klasę z jakimś kodem i puste testy i poproś o dopisanie testów
- klasę z kodem i testami, ale takimi które failują
Przynajmniej zobaczysz jak ktoś pisze jakiś quasi-prawdziwy kod. Jako zadanie z gwiazdką, możesz dopytać co by można było zrobić zeby któraś z tych funkcji była thread-safe, albo jakby ten serwis można było zeskalować na wiele równoległych nodów (więc np. jakiś cache w Mapie przestaje sie sprawdzać).
Dzięki za pomysł. Na pewno wykorzystam.