@vpiotr o ile nie aplikujesz na pozycje programisty algorytmów sortowania to taka wiedza jest praktycznie bezużyteczna. Ja co prawda znam odpowiedzi na te pytania, ale też gdyby padły na rozmowie rekrutacyjnej to byłyby jasnym sygnałem ze rekruter nie bardzo rozumie co i po co robi.
To jest trochę jak z testami jednostkowymi ->
- jeśli możesz popsuć kod a test przechodzi, to test jest bez sensu
- jeśli zmieniasz strukturę kodu, a zachowanie pozostaje poprawne, a test się wywala, to jest bez sensu
I tutaj analogicznie:
- na te pytania może spokojnie odpowiedzieć ktoś kto nie potrafi programować, bo wykuć i zaklepać kilka linijek da radę każdy
- na te pytania moze nie odpowiedzieć bardzo doświadczony developer, bo zwyczajnie nie będzie pamiętał
Siłą rzeczy użyteczność takich pytań jest zerowa.
Tak jak mówiłem zresztą, nie widzę sensu wymagać znajomości algorytmów joinowania rekordów w bazie (chyba ze piszemy silnik bazodanowy) ale trzeba rozumieć co się tam dzieje i ile trwa. Analogicznie z sortowaniem, nie ma sensu wkuwać na pamięć kilku wariantów quicksorta, ale trzeba rozumieć jaką ma złożoność i jakie ograniczenia, bo bez tego nie będziesz w stanie efektywnie z tego korzystać.
Byłem kiedyś na rozmowie gdzie padło trochę praktycznych pytań o struktury danych, tzn na zasadzie "jak bym rozwiązał problem XYZ" i wymagało to użycia jakiejś dwupoziomowej mapy i seta. Mój rozmówca bardzo był zadowolony z tego że użyłem tam hashseta bo ponoć masa ludzi przychodzi i wybiera struktury danych na pałe i zgaduje że może użyje linkedlist a może arraylist a może treeset a może gołej tablicy.
I znów, nie ma większego sensu sprawdzać czy ktoś umie z pamięci zaklepać drzewo czerwono-czarne, ale programista powinien wiedzieć jakie struktury danych ma dostępne, czym sie charakteryzują i kiedy należy użyć X a kiedy Y, najlepiej na konkretnym praktycznym przykładzie.