Sytuacja jest jasna: to zależy.
Nie mają racji ci, co twierdzą, że w miarę solidna znajomość algorytmiki to mus i że bez tego nie można znaleźć dobrej (obiektywnie, tudzież uśredniając opinie) pracy. Nie mają racji też ci, co twierdzą, że algorytmika nigdzie nie jest potrzebna.
Podobnie jest z technologiami. Nieraz znajomość konkretnej technologii to sprawa drugorzędna, a nieraz -- praktycznie pierwszorzędna.
W dużych korporacjach, gdzie pisze się oprogramowanie biznesowe, większość teamu nie ma styczności z wymyślaniem algorytmów, więc nie muszą mieć solidnej, podstawowej wiedzy. To się po prostu nie przydaje i tyle. Nieprawdą jest, że w dużych korporacjach nie korzysta się z gotowych rozwiązań -- jak najbardziej się korzysta. U mnie (~80 tys. pracowników) używa się gotowych bibliotek i frameworków całkiem często. Korporacje mają kasę. Mogą sobie pozwolić na drogie, komercyjne systemy zarządzania treścią, czy całe, złożone usługi-akceleratory witryn www. Mogą sobie pozwolić na wykupienie specjalnych pakietów wsparcia technicznego do używanych systemów. Z drugiej strony -- owszem, tworzy się też sporo swoich, "szytych na miarę" narzędzi.
Mamy więc i to i to.
Co do wymagania znajomości technologii, to i tutaj odpowiedź brzmi "to zależy". Niekiedy po prostu nie sposób znaleźć ludzi znających technologię X, bo jest to wewnętrzny system, stworzony i utrzymywany przez zatrudniającą korporację. Jeśli jakaś mała firma szuka np. studentów jako klepaczy PHP, to też wybiorą raczej co bystrzejszych ludzi, a niekoniecznie tych, co pisali już w tym frameworku, którego używa firma.
Z drugiej jednak strony, jeśli zatrudnia się koderów HTML/CSS, to znajomość technologii jest niemal wszystkim. Raczej nie zdarzy się, że ktoś by znał inny, analogiczny do HTML-a język znaczników i inny język arkuszy stylów niż CSS. A nawet jeśli, to "cięcie layoutów" to proces mocno celujący w technologię i umiejętność jej właściwego użycia. Algorytmika tu niewiele pomoże, podobnie jak np. znajomość metodyk programowania/prowadzenia projektów. Te rzeczy schodzą na dalszy plan, a liczy się technologia.
Ja czasami też szukam programistów JavaScriptu. Ale takich prawdziwych, nie script-kiddies. Tutaj trzeba zwykle i posiadać ogólne umiejętności programowania (IO, niekiedy jakieś algorytmy), i bardzo dobrze znać ten język. A jeśli nie ten, to przeważnie kilka innych: coś obiektowego, coś z dziedziczeniem prototypowym, coś z funkcyjnością, z asynchronicznością. Niestety, znajomość Javy czy C++ tutaj nie wystarcza, bo w JS programuje się zupełnie inaczej. Jeśli ktoś chce pisać w JS tak jak w Javie czy C++, to zawsze będzie się na JavaScript wkurzał, bo JavaScript nigdy nie będzie tak dobrą Javą jak Java. Z drugiej strony, trafiają się programiści, którzy język znają w miarę, ale z inżynierii oprogramowania są nogami i ciężko byłoby im stworzyć i utrzymywać większy projekt.
W wypadku algorytmiki również "to zależy". Czasami potrzeba zatrudniać algorytmicznych wymiataczy. A czasami jest to kwestia trzeciorzędna w stosunku do znajomości IO, czy nawet technologii. Zależy to bardziej od konkretnych projektów niż od wybranych języków. Można w JS tworzyć rzeczy algorytmiczne (obróbkę grafiki, czy nawet... implementację kodeku), a można zwykłe RIA -- duże aplikacje o prostych algorytmach, ale wymagające pod względem inżynierii oprogramowania.
I to nieprawda, że to pierwsze czy to drugie jest obiektywnie ciekawsze/fajniejsze. Jeden woli siedzieć w algorytmach, drugi woli tworzyć raczej proste algorytmicznie (ew. z ciężką algorytmiką zaimplementowanąprzez "kogoś innego"), ale skomplikowane aplikacje, użyteczne dla korzystających z nich ludzi.
Ja do teamu raczej nie potrzebuję algorytmików i Codility wydaje mi się nieadekwatnym narzędziem na większość stanowisk. Rekrutując, spory nacisk kładziemy na znajomość technologii, IO, komunikatywność. Część kodu kandydata bywa sprawdzana przez testy automatyczne, ale to tylko coś pomocniczego. Kod przechodzi przez normalne code review, sprawdzany jest przez 2 programistów. Podczas rozmowy kwalifikacyjnej również nie ma oceny zero-jedynkowej. Czasami robi się z tego mini-sesja extreme programming, gdzie poprawia się wraz z kandydatem jakiś bug w jego kodzie.