Programista pragnie wybrać algorytm, który najszybciej przetwarza dane w jego aplikacji. Na podstawie złożoności obliczeniowej przedstawionej w tabeli, należy wskazać algorytm numer <br><br> <table><tr><td>Algorytm 1</td><td>O(n²)</td></tr><tr><td>Algorytm 2</td><td>O(n!)</td></tr><tr><td>Algorytm 3</td><td>O(n³)</td></tr><tr><td>Algorytm 4</td><td>O(n)</td></tr><tr><td>Algorytm 5</td><td>O(n²)</td></tr></table>

Wybierając algorytm o najniższej złożoności obliczeniowej, zawsze warto patrzeć na oznaczenia w notacji dużego O. O(n) oznacza, że czas wykonywania algorytmu rośnie liniowo wraz z rozmiarem danych wejściowych. To zdecydowanie najlepszy wynik z dostępnych, szczególnie jeśli porównać do O(n²), O(n³) albo już totalnie niepraktycznego przy większych n: O(n!). Dlatego Algorytm 4, który ma złożoność O(n), to najrozsądniejszy wybór, jeśli zależy nam na szybkości działania programu. Z mojego doświadczenia, właśnie takie algorytmy są wykorzystywane np. do przetwarzania dużych zbiorów danych w aplikacjach webowych albo w sytuacjach, gdzie liczy się czas odpowiedzi dla użytkownika końcowego. W branży IT, jeśli tylko można zejść poniżej złożoności kwadratowej – raczej zawsze warto to zrobić. Oczywiście, sama złożoność to nie wszystko – czasem prostszy, liniowy algorytm może mieć duże stałe ukryte w implementacji, ale w praktyce O(n) to standard optymalny. Warto też pamiętać, że w rekrutacjach często padają pytania o takie porównania złożoności, bo to podstawowa wiedza każdego programisty. Takie podejście pozwala budować skalowalne systemy, które nie „duszą się” przy większej ilości danych. Moim zdaniem, to jedna z tych rzeczy, które naprawdę się przydają w codziennej pracy.