W jaki sposób umiejętności wykorzystywane w typowych pytaniach do rozmowy kwalifikacyjnej są stosowane w prawdziwej pracy? [Zamknięte]

W przypadku zadań deweloperskich aplikacji SQL i C #, ankieterzy zwykle zadają pytania na temat przejścia przez drzewo, wykresy i powiązane listy przy użyciu czystego C i wskaźników. Przez 3 lata spędzone w pracy nigdy tak naprawdę nie musiałem

znajdź ścieżkę do pierwszego węzła po prawej stronie danego węzła, który jest wielokrotnością danego węzła

na przykład

Widzę, że te umiejętności można wykorzystać w zadaniach, w których trzeba pisać kompilatory, sterowniki i pracować w jądrze systemu operacyjnego. Poza tymi, gdzie jeszcze są używane te umiejętności?

Przeczytaj niektóre odpowiedzi Joela poniżej.

Szczególnie zwróć uwagę na malarza Schmiela. W pracy być może nigdy nie będziesz musiał przepisywać połączonej listy, ale na pewno powinieneś wiedzieć, jak to działa, aby uniknąć Schmiela.

Zasadniczo, jeśli idziesz do lekarza, chciałbyś, aby ten lekarz studiował anatomię. Nawet jeśli ona właśnie przepisuje ci lek przeciwhistaminowy, lekarz dowie się w szkole medycznej, że niektóre leki są złe dla osób z „przewlekłym złamaniem kości udowej gorszej kości udowej”. Tego rodzaju dogłębna znajomość WSZYSTKIEGO w tej specjalizacji może czasem odróżnić życie od śmierci, a w technologii informacyjnej życie i śmierć produktu lub pracy.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

„... spędzić przynajmniej semestr zbliżając się do maszyny, inaczej nigdy nie będziesz w stanie stworzyć wydajnego kodu w językach wyższego poziomu.”

„... programujesz w oparciu o przesądy, o ile o mnie chodzi: lekarz medycyny, który nie zna podstawowej anatomii, rozdaje recepty na podstawie tego, co powiedziała babka ze sprzedaży farmaceuty”.

http://www.joelonsoftware.com/articles/CollegeAdvice.html

Oni nie są. Wiele wywiadów przeprowadzają ludzie, którzy nie wiedzą, jak szukać zręcznych programistów i nie wiedzą, jakie pytania powinni lub nie powinni zadawać.

Większość ankieterów w ogóle nie zadaje pytań technicznych i jest bardziej skoncentrowana na bezsensownych, ale wymiernych rzeczach, takich jak liczba projektów, w których uczestniczyłeś (więcej jest lepsza dla tych ankieterów) lub stopień naukowy (im wyższy, tym lepszy dla nich ). Z przyjemnością zatrudniają osobę, która zmarnowała pięć lat na studiach, nie ucząc się niczego, a następnie spędzili dziesięć lat, robiąc dziesiątki witryn e-commerce, ale nie zatrudniają osoby, która porzuciła studia po kilku latach i pracowała nad kilkoma duże projekty wymagające pod względem technicznym.

Zadawanie przynajmniej teoretycznych pytań jest lepsze niż zadawanie żadnych. Ma to tę zaletę, że sprawdza, czy osoba ma wystarczającą wiedzę teoretyczną i nie jest programistą, który może mieć kilka lat doświadczenia w programowaniu, ale tak naprawdę nie rozumie, co dzieje się pod maską. Programiści, którzy nie mają tej wiedzy teoretycznej, zwykle nie znają różnicy między listą, połączoną listą wyszukiwania lub zestawem skrótów i używają ich zamiennie.

Dobre (techniczne) pytania, złe pytania

Podczas wywiadów możesz napotkać pytania od bardzo dobrych do bardzo złych:

1. (Szkodliwy) „Jaka jest długość w liniach najdłużej działającego programu, który napisałeś w tym języku?”

   To pytanie jest po prostu błędne. Wyjaśniłem już, dlaczego w innej odpowiedzi . Firma, w której ankieterzy zadają takie pytania, ma duże szanse na ocenę produktywności programistów w LOC / miesiąc. Jeśli muszę dać radę: nie potrzebujesz takiej pracy.

   Ten przykład różni się od bezsensownych, ale wymiernych rzeczy, które zacytowałem na początku mojej odpowiedzi. Tutaj ankieter pokazuje również, że nie ma nawet najbardziej podstawowego zrozumienia wskaźników, wybierając taki, który jest znany z tego, że jest szkodliwy.

2. (Złe) „Kim jest Dennis Ritchie?”

   Posiadanie przynajmniej pewnej kultury jest rzeczywiście bardzo przydatne, ale zadawanie tych pytań nie ma sensu. Jeśli firma szuka utalentowanych programistów, którzy potrafią obsługiwać projekty programistyczne i pisać kod, fakt, że nie znają nazwiska osoby, która stworzyła C i Unix, nie powinien mieć większego znaczenia.

3. (Dobrze) „Jakie są nowe funkcje .NET 4.5?”

   To pytanie jest o wiele bardziej interesujące niż pytanie o Dennisie Ritchie. Jeśli kandydat nie może mówić o nowych funkcjach .NET 4.5, dlaczego nazywa siebie programistą C #? Brak takiej wiedzy:

   • Pokazuje, że dana osoba może nie być zainteresowana ani językiem programowania, ani społecznością .NET,

   • Wskazuje, że dana osoba może nie mieć pewnej istotnej wiedzy na temat funkcji języka C # / .NET inni deweloperzy używają, jeśli nie codziennie, przynajmniej często.

   Zobacz także odpowiedź Jerry'ego Coffina, która zawiera bardziej szczegółową analizę tego rodzaju pytań.

4. (Średnia) „Który z nich jest szybszy, SSD lub RAM?”

   Może to być przydatne i pokazuje, czy dana osoba ma wystarczającą wiedzę na temat sprzętu, ale kandydata, który nie może odpowiedzieć na to pytanie, nie należy odrzucać.

5. (Średnia) „W jaki sposób stos i kolejka są wdrażane?”

   To są pytania, o których mówisz. Są teoretyczne, może nawet zbyt teoretyczne, ale wiedza o tym, co dzieje się pod maską, może pomóc w pisaniu lepszego kodu.

   Nie odrzuciłbym kandydata, który nie może odpowiedzieć na to pytanie, ale sprawdzi, czy naprawdę zna się na rzeczy, na przykład zadając powiązane, ale mniej teoretyczne pytanie:

6. (Dobrze) „Jak przejść przez drzewo bez rekurencji?”

   Jeśli kandydat odpowie na to pytanie, mówiąc o FILO / FIFO oraz o zaletach i wadach używania stosu w porównaniu z rekurencją podczas przechodzenia przez drzewo, to nie ma znaczenia, że ​​nie był w stanie odpowiedzieć na poprzednie pytanie.

   Zadanie tego pytania jest również dobrym sposobem na wykrycie kandydatów, którzy spędzili lata na zdobywaniu tytułu CS, ale nie mają doświadczenia w terenie.

Jak zadawać dobre pytania techniczne?

Komentarz kojiro jest interesujący i zasługuje na dłuższą odpowiedź:

Czasami musisz zatrudnić kogoś właśnie dlatego, że powinien on wiedzieć więcej na dany temat niż ty, więc z definicji nie masz kwalifikacji do przeprowadzenia rozmowy kwalifikacyjnej. Z tego samego powodu nie można niezawodnie uzyskać pomocy, nawet podczas wywiadu. Najlepsze, co możesz zrobić, to zadawać pytania w zależności od miejsca, w którym twoje zrozumienie styka się z dziedziną problemową i mam nadzieję, że będziesz miał szczęście.

Znalezienie dobrych pytań może być trudne, szczególnie gdy zatrudniasz pierwszego programistę lub zatrudniasz programistę, który powinien być bardziej wykwalifikowany niż wszyscy programiści, którzy faktycznie pracują w firmie.

Oto trzy wskazówki, które mogą pomóc:

1. Znajdź przyjaciela / kolegę, którego uważasz za wykwalifikowanego i poproś go o wykonanie recenzji. Wymaga to dużego zaufania, ale może przynieść wiele korzyści Twojej firmie.

2. Znajdź konsultanta, który Twoim zdaniem jest wykwalifikowany, i poproś go o pomoc lub wykonanie części technicznej wywiadu.

3. Wpisz „pytania do rozmowy kwalifikacyjnej” w Google. Działa całkiem dobrze i zwykle wyjaśnia możliwe odpowiedzi. Przykład:

   • Python : te dziesięć pytań wydaje się całkiem dobre. Mogą być nieco podstawowe, ale pomogą odfiltrować 95% kandydatów, których i tak nie chcesz zatrudniać.

   • SQL autorstwa Dave'a Pinala, jak zwykle doskonały.

   • C # : nieco zbyt podstawowy, ale znowu będą filtrować 95% kandydatów,

   • JavaScript : pytania są bardziej otwarte, co może nie być dobre w przypadku pytań technicznych, jeśli chcesz, aby wywiad był krótki i miał więcej czasu na otwarte pytania nietechniczne. Lista nadal pomaga w łatwym filtrowaniu kandydatów, którzy nie rozumieją podstawowych pojęć w JavaScript.

   Wadą tego podejścia jest to, że kandydat może zastosować tę samą technikę w celu przygotowania się do rozmowy kwalifikacyjnej. Jeśli przejrzy każde pytanie dotyczące pierwszej witryny, którą znalazł w Google, może uzyskać dobre wyniki, nie posiadając wymaganych umiejętności.

^{¹ Niektórzy programiści nie są w stanie wyjaśnić, czym jest B-drzewo (poza tym, że jest to „jakaś struktura danych”), ale nadal są w stanie poprawnie się rozwijać.}

Z mojego doświadczenia w mojej firmie, w której przeprowadziłem wiele wywiadów, jest duża szansa, że ​​osoba przeprowadzająca wywiad nie ma pojęcia, jak to zrobić poprawnie. Przygotowali więc zestaw pytań technicznych, obliczyli wynik i sprawili, że zostaniesz wznowiony. Ma to jednak wiele wad i nie należy tego robić z następujących powodów:

• Pytasz punktową wiedzę. Jeśli programista nigdy nie zrobił czegoś w tym obszarze, nadal może być doskonałym współpracownikiem, ale po prostu nie zna tej konkretnej odpowiedzi. Przeciwnie: jeśli ktoś przygotował się na rozmowę i znalazł w sieci odpowiedź na to pytanie, masz właściwą odpowiedź, ale ta osoba może wcale nie mieć pojęcia na dany temat.

• Ludzie się denerwują podczas rozmów kwalifikacyjnych. Mózg ma tę wspaniałą funkcję zamykania wielu obszarów wyższego poziomu (takich jak logika) w stanie paniki, co oznacza: jeśli jesteś zdenerwowany, możesz nie zapewnić jakości odpowiedzi, którą byś otrzymał w codziennej sytuacji. Niektóre osoby mogą poradzić sobie ze stresującą sytuacją, taką jak rozmowa kwalifikacyjna, wielu nie.

• Za pomocą jednej poprawnej odpowiedzi testujesz umiejętności tych osób, aby znaleźć tę konkretną odpowiedź. Jest to jedna z wielu umiejętności, których potrzebuje współpracownik, ale nie jest to jedyna wymagana. Dlatego jedno lub dwa z tych pytań powinny wystarczyć do przetestowania tego obszaru wiedzy, a następnie należy zapytać o inne umiejętności. Wywiad, który zawiera tylko pytania dotyczące rozwiązywania problemów, ciągle testuje tę samą umiejętność.

Jakie są pytania dotyczące dobrych zadań programistycznych?

Te słynne pytania „Czy możesz napisać krótki program” mają ogromny problem polegający na tym, że większość programistów nie może napisać ani jednego wiersza kodu bez pomocy IDE. Ale w codziennych sytuacjach roboczych nie ma żadnego problemu, ponieważ programista zawsze pomaga mu w jego IDE. Dlatego zadając pytania takie jak „Znajdź błąd”, „Napisz 50 wierszy kodu, które wykonują ...” lub nawet proste pytania, należy wziąć pod uwagę, że wnioskodawca nie ma dostępnych narzędzi (IDE, Google).

Mogę na przykład odpowiedzieć w zasadzie na każde pytanie w ciągu 1 minuty, jeśli Google mi pomoże, ale bez połączenia z Internetem wydaje mi się bezradny. Nazywam to zewnętrzną pamięcią i zamiast przeszkadzać, bardzo pomaga mi skupić się na tym, co jest naprawdę ważne - na zrozumieniu mechaniki podkładu - ponieważ wszystko inne można sprawdzić. Ale nie pytaj mnie o szczegóły z dowolnych losowych interfejsów API, ponieważ ich nie znam, mam do tego Google.

To powiedziawszy, dobre pytanie programistyczne nie powinno koncentrować się na znajomości interfejsów API lub specjalnych umiejętności kodowania, chyba że jest to bezwzględny wymóg dla zadania. Wiedzę można zdobyć, więc lepiej dowiedzieć się, jak dobra jest ta osoba w zdobywaniu wiedzy, niż zapytać, co już wie.

Dobre pytanie do zadania programistycznego powinno być krótkie, proste, dające się zakodować w każdym języku za pomocą zaledwie kilku linii kodu, a to - szczególnie - powinno ci powiedzieć jak najwięcej o tym, jak dana osoba działa i znajduje odpowiedzi. Przykład:

„Napisz funkcję w wybranym języku, która pobiera tablicę liczb całkowitych i porządkuje je w taki sposób, że pierwsza liczba całkowita jest później ostatnią, a wszystkie inne odpowiednio się zmieniają”.

Najpierw w tym momencie każdy kandydat powinien zapytać: „Przepraszam ... czy możesz wyjaśnić zadanie?”. Ponieważ żaden programista nie otrzymał jasnego opisu tego, co należy robić. Po tym następuje wyjaśnienie, że kod w pytaniach powinien wykonać przesunięcie w lewo zawartości tablicy z przepełnieniem dodanym po prawej stronie.

To zadanie jest tak proste, że każdy, kto ukończył jakikolwiek poziom programowania, powinien umieć poprawnie odpowiedzieć. To bierze pod uwagę, że programista musi pracować bez swoich narzędzi i że nerwowość zmniejsza zdolność logicznego myślenia. Jednak wciąż mówi ci, w jaki sposób ludzie rozwiązują problemy na podstawie sposobu sformułowania pytania i sposobu, w jaki ludzie do niego podchodzą, po prostu dlatego, że przesunięcie w lewo jest sprzeczne z powszechnym instynktem „od lewej do prawej” i zmusza ludzi do myślenia za sekunda.

Istnieje wiele możliwych odpowiedzi na to pytanie, więc ważne jest, aby uważnie przyjrzeć się sposobowi opracowywania kodu, a nie to, czy rozwiązanie rzeczywiście zadziałałoby. Czy wnioskodawca testuje wartość null? Jak przechowywane jest przepełnienie? Czy używana jest pętla lub zestaw memów? W jaki sposób wnioskodawca weryfikuje poprawność kodu? To jedno proste pytanie mówi całą biografię o tym, jak ta osoba działa.

Jakie są pytania dotyczące dobrej wiedzy ogólnej?

Odpowiedzi na dobre pytania są łatwe do udzielenia, pozwalają na szeroką liczbę odpowiedzi (tzw. „Pytania otwarte”) i pozwalają dowiedzieć się jak najwięcej o wnioskodawcy w możliwie krótkim czasie.

Przykłady:

(Pytanie do programisty C ++): „Jakie znasz inne języki oprócz C ++?”

To są pytania podstawowe, które dają wnioskodawcy szansę na ratowanie w tym momencie, jeśli nie będzie wiedział nic na zadany temat. „Nie” w tym momencie jest lepsze niż dręczenie go kilkoma pytaniami, na które wszyscy muszą odpowiedzieć: „Przepraszam, nic o tym nie wiem”.

Dodam, że przede wszystkim mówi ci, jakie inne języki zna ta osoba, a ponadto dowiadujesz się, jak zainteresowana jest ta osoba, aby uzyskać szerszy obraz świata programowania lub jeśli masz kogoś, kto ma tylko jeden język (a zatem cechy / techniki) ) widok.

(Następnie, powiedzmy, że zna Javę): Jakie są trzy najważniejsze różnice między C ++ i Javą w twoim opinonie?

To pytanie otwarte, które pozwala na wiele odpowiedzi, więc wnioskodawca ma szansę znaleźć co najmniej trzy. Pytanie o (pierwszą osobistą opinię) pierwszą trójkę nie tylko ogranicza możliwe odpowiedzi, ale także zmusza wnioskodawcę do sortowania według priorytetu. Nadal jest (lub powinna być) łatwa odpowiedź.

To proste pytanie, które testuje dużą dogłębną wiedzę na temat różnych języków programowania. Jak głęboka jest naprawdę znajomość tych tematów? Z tych odpowiedzi możesz wiele powiedzieć o wiedzy i faktycznym zrozumieniu mechaniki leżącej u podstaw języków programowania. Ile ta osoba wydała z brudnymi szczegółami lub jeśli jest to tylko osoba, która łączy różne funkcje API bez rzeczywistej wskazówki, co się dzieje pod nimi.

Ta koncepcja pytań podstawowych, po których następują proste pytania z pogłębioną wiedzą, może być również stosowana w przypadku większości innych tematów. Zawsze w tym schemacie: pytanie ratunkowe, pytanie weryfikacyjne, pytanie szczegółowe. Kolejny przykład (z wywiadu Java):

1. „Jak oceniasz swoje wrażenia związane z programowaniem wielowątkowym?”
2. „Wymień trzy najważniejsze rzeczy, które Twoim zdaniem należy wziąć pod uwagę przy opracowywaniu aplikacji wielowątkowej”.
3. „Proszę wymienić trzy klasy interfejsu API języka Java, które mogą pomóc w opracowaniu tych aplikacji, oraz krótki opis ich zastosowania”.

Te trzy pytania powiedzą więcej niż jakiekolwiek pytanie techniczne, co wnioskodawca naprawdę wie na temat tych tematów, jednocześnie udzielając uczciwej odpowiedzi, biorąc pod uwagę poziom wiedzy i poziom stresu.

Tak więc następnym razem, gdy ktoś zada ci 20 pytań kodujących z rzędu, wiesz, że on / ona w zasadzie nie ma pojęcia, jak poprawnie przesłuchać kogoś. ;)

Ostrzeżenie: jest to napisane jako (poniekąd) komentarz do odpowiedzi @ MainMa, ale 1) jest za długie, by zmieścić się w komentarzu, i 2) Myślę, że dodaje nieco innej perspektywy do konstruktywnych pytań, więc sama w sobie jest prawdziwą odpowiedzią .

W swojej odpowiedzi @MainMa klasyfikuje „Jakie są nowe funkcje .NET 4.5?” jako „dobre” pytanie.

Pozwolę sobie być innego zdania. Jak to sformułował, powiedziałbym, że to w najlepszym razie dość przeciętne pytanie. Dobre pytanie brzmiałoby bardziej: „W jaki sposób kod, który piszesz dzisiaj, różni się od kodu, który napisałeś N lata temu?” (dla pewnej wartości N mniejszej niż lata doświadczenia wymienione w CV, najlepiej około 3 do 5).

Jak to sformułował, pytanie dotyczy zapamiętywania. Czy ten kandydat całkowicie zapamiętał listę funkcji? Zwycięzcą powinien być ten, kto najdokładniej cytuje listę Microsoftu.

Powinieneś się przejmować jego programowaniem. Jak wpłynęło to na jego kod? Z których funkcji on naprawdę korzysta ? A co ważniejsze, czy dobrze ocenia, kiedy użyć nowych funkcji, a kiedy starsze wystarczą doskonale?

Samo powiedzenie „LINQ” mówi ci praktycznie nic pożytecznego o kandydacie. Będąc w stanie powiedzieć: „LINQ pomógł uczynić mój kod znacznie bardziej zwartym i czytelnym, ponieważ mogę wyrażać koncepcje X, Y i Z w sposób czysty i bezpośredni, gdzie wcześniej musiałem przeskakiwać przez następujące płonące obręcze, aby zrobić te rzeczy”. (lub coś podobnego) wiele mówi o kandydacie, jaki kod pisze, jego osąd, elastyczność i tak dalej. Daje to również znacznie więcej okazji do odpowiedzi na pytania dotyczące tego, jak ta osoba myśli o problemach, pisze kod, myśli o kodzie i tak dalej. Wreszcie, daje ci to znacznie lepsze wyobrażenie, czy jest to kandydat, który naprawdę ma N-letnie doświadczenie, czy ktoś, kto ma roczne doświadczenie, powtarzane N razy.

Podsumowanie: możliwość cytowania listy funkcji sprzed kilku lat jest bezużyteczna i niewiele mówi o kandydacie, który prawdopodobnie będzie rzeczywiście przydatny. Postępy kandydata jako programisty prawdopodobnie będą o wiele bardziej interesujące, więc o wiele lepiej zapytać o to bardziej bezpośrednio.

Rzeczywistość jest taka, że ​​większość codziennych zadań wykonywanych przez większość programistów w życiu zawodowym jest trywialna; Oznacza to, że niektóre pytania, na które napotykasz podczas rozmowy kwalifikacyjnej, mogą nigdy nie spotkać się z tobą w rzeczywistości, ale to nie znaczy, że nie ma sensu zadawać tych pytań.

Powiedzmy, że w Twojej firmie jest otwarta pozycja i obecnie przeprowadzasz wywiady z ludźmi. W kolejce jest już 20-30 programistów. Jak więc wybrać najlepszego kandydata na to stanowisko? Powiedzmy, że najtrudniejszym zadaniem, jakie musieli wykonać w tym zadaniu, jest otwarcie pliku z systemu plików, odczytanie danych linia po linii, nieznaczna modyfikacja i ponowne włożenie z powrotem do oryginalnego pliku.

Czy zapytasz ich, jak otworzyć plik? Założę się, że nie widzisz naprawdę dużej różnicy między odpowiedziami. Musisz więc znaleźć rozwiązanie pozwalające rozróżnić programistów, którzy wiedzą tylko, jak otworzyć plik, i tych, którzy potrafią opracować kiepską aplikację w czasie rzeczywistym. Nawet jeśli nie chcesz, aby zbudowali taką aplikację, ale nadal chcesz zatrudnić najlepszego kandydata.

Jak każda inna rzecz w naszym życiu, zdajesz sobie sprawę, że musisz iść i dowiedzieć się więcej. Jeśli nie wiesz, co to jest lista powiązana, dla mnie jako programisty, oznacza to dosłownie, że tak naprawdę nie osiągnąłeś tego punktu w swoim życiu zawodowym, aby poczuć, że musisz iść i nauczyć się tej konkretnej rzeczy. Dlaczego? Po prostu dlatego, że nigdy nie zaangażowałeś się w projekt wystarczająco duży, aby wymagać od ciebie doskonalenia umiejętności do tego poziomu. Jeśli jesteś na poziomie podstawowym, możesz powiedzieć, że tak naprawdę nie mam żadnego doświadczenia zawodowego w tej konkretnej pracy, ale mimo to wiesz, że oznacza to, że jesteś wystarczająco zmotywowany, aby postawić się na cięciu powyżej średniej przynajmniej.

Umiejętności wymagane do wykonywania tych zadań są rzadko ważne. Najważniejsze są umiejętności wykazane w podejściu do odpowiedzi na pytanie i w późniejszym dialogu.

Kiedy przeprowadzam wywiad z programistami, szukam (a) inteligentnego (b) zrobienia rzeczy, które pasują (c) pasuje. Podstawowy poziom wiedzy technicznej wymagany do obsadzenia dowolnej roli, musi iść w parze z chęcią uczenia się i zdobywania nowych umiejętności. Wywiad dotyczy zaznaczenia tych pól.

Wolę czytać kod napisany przez wnioskodawcę. Nie lubię pytań z wywiadu w puszkach, ale zapewniają one coś do rozmowy przy braku kodu. Wolę pytać o RAII lub MKOl lub implementację IDisposable niż o listę i kolekcje, ale wszystko zrobi tak długo, jak tylko będziemy w stanie uzyskać wystarczającą wiedzę techniczną .

Najgorsze obawy ankietera to zatrudnienie kogoś, kto tak naprawdę niewiele wie o kodowaniu. Musisz porozmawiać o czymś innym niż doświadczenie zawodowe, aby pozbyć się podróbek.

Te pytania mają na celu wyodrębnienie osób, które nie mogą programować. Czasami ludzie, którzy nie potrafią programować, ale znają wiele ciekawostek, starają się o pracę programistyczną, a napisanie czegoś, co jest użyteczne i nietrywialne, jest zbyt czasochłonne na rozmowę kwalifikacyjną.

Widzę, że te umiejętności można wykorzystać w zadaniach, w których trzeba pisać kompilatory, sterowniki i pracować w jądrze systemu operacyjnego. Poza tymi, gdzie jeszcze są używane te umiejętności?

Co powiesz na pisanie wyszukiwarek, serwerów internetowych, przeglądarek internetowych, edytorów tekstu, arkuszy kalkulacyjnych, edytorów obrazów, programów do rysowania, serwerów baz danych, bioinformatyki, programów handlowych, gier, symulatorów fizyki i tak dalej?

Przyznaję, że większość zadań związanych z oprogramowaniem polega na pobieraniu danych z bazy danych, umieszczaniu ich na ekranie, edytowaniu, usuwaniu ich z ekranu i ponownym umieszczaniu w bazie danych. Jednak nawet wtedy możesz ostatecznie natknąć się na aplikację, w której ograniczenia nie mogą być spełnione przez wbudowane funkcje platformy. W tym momencie możesz zrezygnować lub sięgnąć do zestawu narzędzi algorytmów i struktur danych i spróbować rozwiązać problem.

Obiekty teoretyczne są używane dla wygody, ponieważ powinieneś wiedzieć, o czym jest przeciętne wdrożenie drzewa / wykresu / listy, a tym samym wiedzieć, jak rozwiązać problem losowego przejścia, ale te pytania w ogóle nie dotyczą przedmiotów teoretycznych.

Chcą pracować z abstrakcyjnym modelem, rozumieć abstrakcyjny problem i rozwiązywać go za pomocą dowolnego algorytmu. Jest to umiejętność czysto rozwojowa, więc na pewno się liczy. Właśnie dlatego te pytania mają sens, a nie dlatego, że mają być dokładnymi rzeczywistymi sytuacjami.