Ma to wg was sens ? Biorąc pod uwagę, że - nie oszukujmy się - mamy kilka chwil aby wpaść na poprawne rozwiązanie, a po drugie przy rekruterze wiadomo, nerwy mogą o sobie dać znać.
I drugie pytanie czy takie zadania na rozmowach zdarzają się często (raczej mowa o osobach z <1 rok doświadczenia).
To jest programowanie a nie przedszkole, tu trzeba stalowych nerwów i błyskawicznego myślenia niezależnie od zewnętrznej sytuacji. To nie jest branża dla mięczaków.
Te zadania to bzdura, tyle powiem po odbytych XX interview (i przeprowadzonych XXX). Lepiej porozmawiać z człowiekiem i dać mu ew. zakodzić coś typowego, ale porządnie. Klucz to na interview skupiać się na przyszłych tematach dotyczących rekrutowanego. Jak ktoś chce robić zagadki matematyczne albo jakieś wydumane codility, to zatrudni jakiegoś socjopatę prawdopodobnie i dobrze mu tak :P
Dodam jeszcze, że po trafieniu ileś razy w bagniste projekty, to tak na prawdę wolałbym jako aplikujący przepytać gruntownie obecnych pracowników z merytorycznej wiedzy, a managera poddać stress testom za pomocą pytań np.:
A jak już miałbym rozwiązywać coś nietrywialnego na rozmowie, to niech to chociaż zahacza o wymagane technologie.
PythDev napisał(a):
Ma to wg was sens ? Biorąc pod uwagę, że - nie oszukujmy się - mamy kilka chwil aby wpaść na poprawne rozwiązanie, a po drugie przy rekruterze wiadomo, nerwy mogą o sobie dać znać.
I drugie pytanie czy takie zadania na rozmowach zdarzają się często (raczej mowa o osobach z <1 rok doświadczenia).
takie zadanka powinieneś w pamięci trzaskać
ofkz jęczą wszystkie matołki po butkampach, mistrzuniowie ctrl+c, ctrl+v ze stackoverflow
magistrowie socjologii z dyskalkulią i dysmóżdżem
po cholere się pchają do takich firm i zasrywają HRy swoimi CV, nie mogliby robić stronek z [CIACH!] kotami w wordpresie ?
Może dorzucę coś od siebie w kwestii częstotliwości takich pytań. W ostatnim miesiacu uczestniczylem w 5 rozmowach i nie wiem czy to przypadek czy nie ale na 4 z nich mialem przynajmniej jedno pytanie typowo matematyczne. Nie były to jakieś trudne zadania bardziej chodziło o spostrzegawczość i sposób myślenia.
Co do kwestii czy ma to sens czy nie.. Moim zdaniem owszem. Można tym sposobem odsiać niektóre osoby, bo co po kimś takim kto naklepie coś z pamięci albo zakodzi coś gdzie już spotkał skoro przyjdzie czas kiedy będzie coś do zrobienia czego nie przerabiał? Jak podejdzie do takiego zadania skoro całkiem prostej łamigłówki matematycznej nie potrafi rozwiazać?
Burtoon napisał(a):
Co do kwestii czy ma to sens czy nie.. Moim zdaniem owszem. Można tym sposobem odsiać niektóre osoby, bo co po kimś takim kto naklepie coś z pamięci albo zakodzi coś gdzie już spotkał skoro przyjdzie czas kiedy będzie coś do zrobienia czego nie przerabiał? Jak podejdzie do takiego zadania skoro całkiem prostej łamigłówki matematycznej nie potrafi rozwiazać?
No tak, bo przecież programista to kretyn i jak dostanie zadanie którego jeszcze nie robił to będzie siedział i patrzył się w niebo..
zapewniam Cię, że każdy kto programuje na poziomie juniora znajdzie Ci rozwiąznie większości problemów a przynajmniej będzie wiedział od czego zacząć.
za to zauważyłem, że te mądre firemki dające łamigówki matematyczne szukają potem przez rok juniora bo żaden się nie nadaje, tylko kto tu komu szkodzi...
Wcale nie uważam, że każdy junior to kretyn.. Chodzi mi o to, że zaczynajac karierę programisty wypadałoby mieć już wyćwiczony jakiś tok myślenia. Rozumiem, że każdy ma swoje zdanie na ten temat i nie mam zamiaru tego podważać.
Jako przykład o co mi chodzi:
Na jednej z rekrutacji dostałem zadanie typu ołówek i długopis razem kosztuja 1zł 10gr. Długopis jest o 1zł droższy od ołówka. Ile kosztuje długopis a ile ołówek? I teraz wiele osób sobie pomyśli co na celu ma takie proste zadanie? A tu z rozmowy z rekruterem dowiedziałem się, że wiele kandydatów ma problem żeby to rozwiazac w glowie (ok to zrozumiem) ale sa też osoby które nie daja sobie z tym rady majac kartke i dlugopis... Oczywiście cały czas mowa o kandydatach bez doświadczenia komercyjnego.
Ja nie mam nic przeciwko, wolę krótkie zadania na miejscu w czasie rozmowy niż zadanie na 2 tygodnie do robienia wieczorami w domu.
Burtoon napisał(a):
Wcale nie uważam, że każdy junior to kretyn.. Chodzi mi o to, że zaczynajac karierę programisty wypadałoby mieć już wyćwiczony jakiś tok myślenia. Rozumiem, że każdy ma swoje zdanie na ten temat i nie mam zamiaru tego podważać.
Jako przykład o co mi chodzi:
Na jednej z rekrutacji dostałem zadanie typu ołówek i długopis razem kosztuja 1zł 10gr. Długopis jest o 1zł droższy od ołówka. Ile kosztuje długopis a ile ołówek? I teraz wiele osób sobie pomyśli co na celu ma takie proste zadanie? A tu z rozmowy z rekruterem dowiedziałem się, że wiele kandydatów ma problem żeby to rozwiazac w glowie (ok to zrozumiem) ale sa też osoby które nie daja sobie z tym rady majac kartke i dlugopis... Oczywiście cały czas mowa o kandydatach bez doświadczenia komercyjnego.
I to są kretyńskie pytania właśnie które potem odsiewają osoby którym taka wiedza nie jest potrzebna. Wyobraź sobie sytuację. Ktoś programuje w jakimś języku, ma swoje projekty, ale szuka pierwszej pracy. W pracy okazuje się, że nagle trzeba sofrmatować dane w tablicy. Myślisz, że sobie nie poradzi? poradzi bardzo szybko.
Teraz daj mu matematyczne zadanie na rekrutacji gdzie masz określony czas. Nie rozwiązuje bo stres, bo matematyka to nie jego mocna strona brawo właśnie odrzuciłeś kandydata który ma projekty, zna dobrze język, po krótkim wdrożeniu będzie szybko się uczył, ale nie Ciebie interesowało czy umie rozwiązać zadanie matematyczne.
@Pabloss: nie chcialbym brac do teamu osoby ktora tak trywialnego zadania nie rozwiaze. Byc moze jest swietny (bardzo male szanse) ale nie widze sensu ryzykowac. To jest zbyt proste by zrzucac to na barki wyimaginowanych problemow.
Pabloss napisał(a):
I to są kretyńskie pytania właśnie które potem odsiewają osoby którym taka wiedza nie jest potrzebna. Wyobraź sobie sytuację. Ktoś programuje w jakimś języku, ma swoje projekty, ale szuka pierwszej pracy. W pracy okazuje się, że nagle trzeba sofrmatować dane w tablicy. Myślisz, że sobie nie poradzi? poradzi bardzo szybko.
Teraz daj mu matematyczne zadanie na rekrutacji gdzie masz określony czas. Nie rozwiązuje bo stres, bo matematyka to nie jego mocna strona brawo właśnie odrzuciłeś kandydata który ma projekty, zna dobrze język, po krótkim wdrożeniu będzie szybko się uczył, ale nie Ciebie interesowało czy umie rozwiązać zadanie matematyczne.
Zgadzam się z tym. Ktoś przygotuje się ze swojej dziedziny, ma jakieś osiągnięcia, niezły kod, a może sie wywalić na rekrutacji, bo ni z gruszki ni z pietruszki każą mu rozwiązać zadanie geomtryczne, albo przypomnieć sobie z liceum kilka twierdzeń o ciągach geometrycznych. Może by jeszcze dawać zadania z fizyki, też wymagają logicznego myślenia. Albo z chemii, np na stężenie roztworów, masę molową albo jakąś prostą reakcję chemiczną. Jak inteligentny to przecież rozwiąże. Tak? No na poziomie liceum to powinien mieć w małym palcu i rozwiązywać z pamięci, przecież to dzieci rozwiązują.
P.S. jestem prawie pewien, że większość tutejszych napinaczy, co to podobno biorą po 15k miesięcznie, nie rozwiązałoby zadań z geometrii czy arytmetyki albo fizyki na poziomie liceum i odpadliby z takiej rekrutacji, bo skończyłby im sie czas na wykonanie zadania.
tamtamtu napisał(a):
@Pabloss: nie chcialbym brac do teamu osoby ktora tak trywialnego zadania nie rozwiaze. Byc moze jest swietny (bardzo male szanse) ale nie widze sensu ryzykowac. To jest zbyt proste by zrzucac to na barki wyimaginowanych problemow.
Ale zdajesz sobie sprawę, że to był tylko przykład? dostałem kiedyś na rekrutacji niby zadanie OOP na godzinę. Począwszy od napisania dwóch prostych klas, przekonwertowania tablicy na obiekty minęło 20-25 minut. Tylko to było nie ważne, ważne było to by wymyśleć i napisać algorytm wyliczający średnie czasy dla zawodników.. algorym obłożony 8 warunkami. Firma dalej szuka juniora od maja tamtego roku :D
Są po prostu firmy, które nie chcą nikogo znaleźć. Zajmują sie tylko ciągłą rekrutacją, która jest celem samym w sobie. Prawdopodobnie mają z tego jakąś kasę i tyle. Dlatego ciągle organizują rekrutacje, gdzie przeprowadzają z kandydatami test psychologiczne, testy IQ i ch... wie co jeszcze i tak się biznes kręci, a nie przyjmują nikogo. Może chodzi tylko o pozyskiwanie danych osobowych.
W normalnej firmie idziesz na rozmowę, siadasz face to face z rekruterami, pytają cię o to i owo (ale na temat), a potem albo cie przyjmują albo nie przyjmują. Ale nie każą ci w czasie rozmowy policzyć całki nieoznaczonej ani rozwiązać równania 3 stopnia na kartce, nie każą ci też dzielić wielomianów pisemnie, ani wymyślać od nowa algorytmu sortowania, nie każą ci tez rozwiązywać testu psychologicznego na 200 pytań, ani testu IQ, gdzie masz dopasowywać figury do dziurek
Pabloss napisał(a):
Burtoon napisał(a):
Wcale nie uważam, że każdy junior to kretyn.. Chodzi mi o to, że zaczynajac karierę programisty wypadałoby mieć już wyćwiczony jakiś tok myślenia. Rozumiem, że każdy ma swoje zdanie na ten temat i nie mam zamiaru tego podważać.
Jako przykład o co mi chodzi:
Na jednej z rekrutacji dostałem zadanie typu ołówek i długopis razem kosztuja 1zł 10gr. Długopis jest o 1zł droższy od ołówka. Ile kosztuje długopis a ile ołówek? I teraz wiele osób sobie pomyśli co na celu ma takie proste zadanie? A tu z rozmowy z rekruterem dowiedziałem się, że wiele kandydatów ma problem żeby to rozwiazac w glowie (ok to zrozumiem) ale sa też osoby które nie daja sobie z tym rady majac kartke i dlugopis... Oczywiście cały czas mowa o kandydatach bez doświadczenia komercyjnego.I to są kretyńskie pytania właśnie które potem odsiewają osoby którym taka wiedza nie jest potrzebna. Wyobraź sobie sytuację. Ktoś programuje w jakimś języku, ma swoje projekty, ale szuka pierwszej pracy. W pracy okazuje się, że nagle trzeba sofrmatować dane w tablicy. Myślisz, że sobie nie poradzi? poradzi bardzo szybko.
Teraz daj mu matematyczne zadanie na rekrutacji gdzie masz określony czas. Nie rozwiązuje bo stres, bo matematyka to nie jego mocna strona brawo właśnie odrzuciłeś kandydata który ma projekty, zna dobrze język, po krótkim wdrożeniu będzie szybko się uczył, ale nie Ciebie interesowało czy umie rozwiązać zadanie matematyczne.
To nie jest "wiedza", to jest analityczne myślenie, jak ktoś tego nie potrafi to faktycznie nie jest kolorowo. Ty tu wyjeżdżasz z ciągami geometrycznymi i jakimiś twierdzeniami, ale podane zadanie rozwiązałby rozgarnięty 11-latek, jeśli tylko ma dość inteligencji.
Jak dla mnie takie zadania są ok (też spoje i inne codility), jeśli faktycznie zadania z pracy potem wymagają takich umiejętności, dla samego odsiania nadmiaru kandydatów to słaby pomysł.
Co do zadania z ołówkiem - jeśli ktoś nie umie tego rozwiązać to nie znaczy, że się nie nadaje na programistę, a raczej że ma problemy z logicznym myśleniem na levelu "druga połowa podstawówki"... (chociaż w sumie to pierwsze wynika z drugiego)
A w temacie szybkiego działania, błyskotliwości itp - czy to jest casting na prowadzącego na żywo dziennik w TV, czy na programistę? W Polsce jest takie dziwne podejście, widoczne bardzo mocno w szkołach. Zamiast uczyć myślenia i umiejętności znajdywania informacji, uczy się wszystkiego na pamięć. Zamiast nauczyć się umiejętności obsługi atlasu, obecnie każą uczniom na pamięć nauczyć się lokalizacji rzek i innych "elementów". W efekcie za parę lat zapomni gdzie dana pustynia/góra/rzeka się znajduje, ale ponieważ nikt nie nauczył jak się korzysta z map - sam sobie nie znajdzie.
Podobnie jest z programistą (oraz każdym innym zawodem). Ja zamiast bystrzaka, który szybko strzeli poprawną odpowiedź, wolę kogoś, kto nie odpowie od razu, ale merytorycznie przysiądzie do tematu, wie gdzie i jak poszukać rozwiązania. Taka osoba z dużym prawdopodobieństwem poradzi sobie w innych nowych sytuacjach, których "bystrzak" może nie ogarnąć.
Troszeczkę zeszliście z tematu. Mówimy tutaj o spoju czyli operacjach na tablicach, ciągach, Stringach itd a nie o kartkówce w gimnazjum. Ogarnijcie się.
Nie wykluczałbym ich całkowicie (można np. zobaczyć, jak ktoś myśli, podchodzi do problemu), jednak nie oszukujmy się - robienie takich zadań jest całkowicie inne od pracy programisty.
Bo raz - są bardzo wąskie i badają np. podejście do algorytmów (a w rzeczywistej pracy może się rzadko pisać tego typu algorytmy, a większą umiejętnością byłoby np. umiejętność sprawnego poruszania się w kodzie legacy albo sprawnego pisania nowych ficzerów na podstawie mglistych wytycznych).
Dwa, że mają nierealne ramy czasowe. Takie zadanie może mieć np. limit 30 minut. Kto tak programuje? W firmach liczą się bardziej dni (i tygodnie) pracy a nie minuty.
Nawet jeśli zadanie odzwierciedlało by rzeczywistą pracę 1:1, to w realnej pracy miałbyś na to ileś razy więcej czasu i zamiast się pocić przez 30 minut, mógłbyś sobie usiąść i poświęcić z połowę dnia (albo i więcej) na rozkminianie sposobu, w jaki to zaprogramujesz.
Moim zdaniem tego typu zadania są ok. Pozwalają odsiać pseudo programistów po boodcampach. Nie mam nic do takich kursów jednak mam do ludzi którzy myślą że można się przyuczyć do zawodu programisty w 3 miesiące. Kolejna kwestia to że aby zrobić takie zadanie trzeba myśleć abstrakcyjnie. Moim zdaniem nie tyle chodzi o zrobienie a ruszenie problemu i pokazanie rekruterowi że jesteśmy w stanie chociaż zacząć rozkminiać problem. Mamy dostateczną motywacje a nie że problem nas przytłoczył i przerósł.
I to są kretyńskie pytania właśnie które potem odsiewają osoby którym taka wiedza nie jest potrzebna.
To nie jest "wiedza", to jest analityczne myślenie, jak ktoś tego nie potrafi to faktycznie nie jest kolorowo.
Zadanie z ołówkiem odrzucić ludzi którzy nie potrafią zastanowić się i poszukać rozwiązania.
Taki Szybki Lopez rzuci 1 zeta i 10 groszy. Później w pracy też coś naklepie i będzie się rzucał (jak wcześniej ktoś podobny do Szybkiego Lopeza "on ma dobry kod") i kiedy w końcu wyleci będzie robił smród firmie bo prawie całek i fizyki od niego wymagali.
Ja wolę takie zadanie z ołówkami niż jakby ktoś znowu dał mi na rozmowie quicksorta do napisania na szybko.
Raz, że to jest out of the box, dwa, że nie pamiętam algorytmu, trzy, że nijak się ma do tego co później się robi w firmie.
Chory Polityk napisał(a):
Ja wolę takie zadanie z ołówkami niż jakby ktoś znowu dał mi na rozmowie quicksorta do napisania na szybko.
Raz, że to jest out of the box, dwa, że nie pamiętam algorytmu, trzy, że nijak się ma do tego co później się robi w firmie.
W takim wypadku dziękuję sie za rekrutację z uśmiechem na twarzy i wychodzi, a potem wali opinię na goworku o sposobie rekrutacji.
Na prawdę jeżeli firma jest konkretna i szuka nawet juniora to nie bawi się w jakieś pseudo zadania algorytmiczne bo to nijak ma się do tego co w przyszłości miałby robić pracownik. Raz uczestniczylem w jednej rekrutacji, nie, nie było żadnych testów, głupich pytań o ołówki i inne kretynizmy. Facet zaczął rysować na tablicy scenariusze dotyczące różnych problemów. Indexy na bazach, optymalizacja kodu, tj jaki wzorzec można wykorzystać, pytania jaki wzorzec kryje się pod eventami w symfony, wąskie gardła i ich optymalizację - wszystko rozrysowane na tablicy w scenariuszach.. I to jest normalna rekrutacja po której widac czy ktoś wie po co przyszedł czy udaje pseudointeligenta który naczytał się w necie o ołówkach i innych logicznych łamigówkach... a potem jego kod opiera się o drabinkę 100 ifów...
Chory Polityk napisał(a):
Ja wolę takie zadanie z ołówkami niż jakby ktoś znowu dał mi na rozmowie quicksorta do napisania na szybko.
Raz, że to jest out of the box, dwa, że nie pamiętam algorytmu, trzy, że nijak się ma do tego co później się robi w firmie.
to wy [--ciach--] na pamięc algorytmy, ze musicie je pamiętać ?
o_O
Niektórzy tu mają ciekawe podejście
"hurr durr najtrywialniejsza rzecz może się zapomnieć" no ok, ale przecież jest jakieś minimum z minimum, czyż nie?
przecież rekrutując na stanowisko które wymaga logicznego myślenia, to raczej najprostsze zadania typu 2x-3 = 5 nie powinny cie zaginać, czyż nie? dodatkowo zazwyczaj(chyba) na stanowisko programisty aplikują ludzie ze średnim lub wyższym wykształceniem.
Zresztą, raczej nie jest to jedyne pytanie na rozmowie, więc możesz się wybronić na innych i tłumaczyć, że stres czy coś.
A jeżeli zawalisz większość pytań "bo ci się zapomniało", to zawaliłeś rozmowę, więc co dziwnego w tym, że cię nie przyjęli?
A ja ciągle uwazam że najlepsze zadanie jakie można dać to kazac napisac kawełek softu (i nie mam na myśli jakiegoś ciągu Fibonacciego) na kompie. Oczywiście to nie jest jedyny element, ale to według mnie dobrze sprawdza czy ktoś rzeczywiście cokolwiek ogarnia. Pod warunkiem oczywiście że dzadzą mi IntelliJ :D :D :D
Pod warunkiem oczywiście że dzadzą mi IntelliJ :D :D :D
...albo dowolnie inne wybrane przez kandydata środowisko programowania. Bo z jednej strony dobry programista może coś w notatniku albo na kartce rozpisać program (w sensie, że to nie IDE czyni programistę), a z drugiej strony jeśli ma się mocno limitowany czas, to szkoda czasu na chrzanienie się ze środowiskiem. Pamiętam jak kiedyś robiłem zadanie, w którym było takie pseudo-IDE w przeglądarce (możliwość podglądu i edycji różnych plików w projekcie), tylko, że było to tak nieintuicyjne, że aż zawaliłem to zadanie, bo nie potrafiłem się sprawnie w tym poruszać.
Tak więc myślę, że w takich silnie stresowych testach powinno się dać kandydatowi jego ulubione IDE, czy ulubione narzędzia pracy (choćby i możliwość zajrzenia do Google), a nie zmuszać do stania przed tablicą i rysowania czegoś markerem.
Wszyscy psioczą na tego quicksorta, że przecież go nie pamiętają na rozmowie kwalifikacyjnej, to jak się przygotowują? Przecież to nie jest zaskoczenie, że na rozmowach pytają o banalne algorytmy, o SOLID-a, o ACID-a, o equals i hashcode, a potem i tak jest narzekanie. To nie lepiej spędzić jeden wieczór przed rozmową, przypomnieć sobie podstawy i potem mieć argument za wyższą kasą?
Ze swojej strony rozumiem te pytania. Prowadziłem sporo rozmów i często trafiali się ludzie, którzy nie potrafili odwrócić w miejscu tablicy, wypisać liczb od tyłu lub zanegować liczby, a jak pytałem ich o dekompilowanie kodu C# lub debugowanie zrzutów pamięci, to były wielkie oczy, że takich rzeczy się nie robi w pracy. Niektórym po prostu nie dogodzi.
Osobiście polecam regularne chodzenie na rozmowy rekrutacyjne i prowadzenie ich w firmie. Łatwiej jest spamiętać pytania, można poznać sporo ludzi, przyzwyczaić się, poznać rynek i stawki. Same zalety, a pójście na pogadankę raz w miesiącu znowu nie zjada masy czasu.
Pierwsze
x + 2x = 3
Oblicz wartość x
Drugie
Znany fizz-buzz
Takie zadania rozkładają cię na łopatki bo
LukeJL napisał(a):
Pod warunkiem oczywiście że dzadzą mi IntelliJ :D :D :D
...albo dowolnie inne wybrane przez kandydata środowisko programowania. Bo z jednej strony dobry programista może coś w notatniku albo na kartce rozpisać program (w sensie, że to nie IDE czyni programistę), a z drugiej strony jeśli ma się mocno limitowany czas, to szkoda czasu na chrzanienie się ze środowiskiem. Pamiętam jak kiedyś robiłem zadanie, w którym było takie pseudo-IDE w przeglądarce (możliwość podglądu i edycji różnych plików w projekcie), tylko, że było to tak nieintuicyjne, że aż zawaliłem to zadanie, bo nie potrafiłem się sprawnie w tym poruszać.
Tak więc myślę, że w takich silnie stresowych testach powinno się dać kandydatowi jego ulubione IDE, czy ulubione narzędzia pracy (choćby i możliwość zajrzenia do Google), a nie zmuszać do stania przed tablicą i rysowania czegoś markerem.
Nie to jest wiadome, chociażby dlatego że nie bede pamiętał w jakich pakietach są jakieś adnotacje Springowe, od tego są skróty klawiszowe :) Więc tu nie chodzi o stres tylko że pisanie w takim notatniku może wydłużyć prace 5 razy
Wszyscy psioczą na tego quicksorta, że przecież go nie pamiętają na rozmowie kwalifikacyjnej, to jak się przygotowują?
Może po prostu widzą w pamiętaniu algorytmu quickosort tyle samo sensu co pamiętanie liczby PI do 12. miejsca po przecinku.
Skoro to jest gotowy default np w sortowaniach list to po co to pamiętać?
Ważne żeby wiedzieć kiedy to nie jest dobry pomysł i czym to zamieniać.
I ja np dokładnie tak odpowiadam na zadania w stylu napisz quicksort(no chyba, że mogę sobie sprawdzić jaki był ten algorytm).
Zdarzyło się, że rekruterowi się to bardzo nie spodobało, ale dla mnie to bardzo źle o nim świadczy, bo prawdopodobnie zupełnie nie rozumie co robi, tylko wyznaje kult kargo quicksorta.
To działa w dwie strony. Wyznawcy kultu quicksorta mnie nie zatrudnią, ale firm IT jest sporo więc ja też nie będę z tego powodu jakoś rozpaczał, tylko pujdę do innej.
Prawdopodobnie mają omnie takie samo zdanie jak ja o nich.
Dump pamięci i szukanie wycieków to już jest konkretne pytanie, ale pytanie o quicksorta to jet żenada.
Skoro to jest gotowy default np w sortowaniach list to po co to pamiętać?
W Javie merge sort (a raczej jego odmiana) jest defaultem : https://en.wikipedia.org/wiki/Timsort