Собеседование в Яндекс: театр абсурда :/

    Привет, хабр!

    В прошлой статье меня знатно разбомбили в комментариях, где-то за дело, где-то я считаю, что нет. Так или иначе, я выжил, и у меня есть чем с вами поделиться >:)

    Напомню, что в той статье я рассказывал, каким я вижу идеальное собеседование и что я нашёл компанию, которая так и делает - и я туда прошёл, хотя это был адский отбор. Я, довольный как слон, везде отметил, что я не ищу работу, отовсюду удалился и стал работать работу.

    Как вы думаете, что делают рекрутеры, когда видят "Alexandr, NOT OPEN FOR WORK"? Правильно, пишут "Алексей, рассматриваете вариант работать в X?" Я обычно игнорирую это, но тут мне предложили попытать счастья с Яндекс.Лавкой, и я не смог пройти мимо - интересно было, смогу ли я устроиться куда-нибудь, когда введут великий российский файерволл. К тому же за последние 3 года я проходил только два интервью, и мне показалось, что я не в теме, что нынче требуется индустрии. Блин, я оказался и вправду не в теме. И вы, скорей всего, тоже - об этом и статья.


    Короче, я согласился - буду продавать дошики и похмелье!

    Мне назначили дату интервью, и также прислали методичку, чтобы я понимал, что меня ждёт и как готовиться. Чтобы ничего не заспойлерить, я замазал квадратиками важную информацию.

    Вы тоже заметили "вопросы на C++" в методичке для питониста? Не то чтобы я знал C++, но в институте проходили, авось что-нибудь да вспомню на интервью.

    Тут что-то написано про leetcode, но я человек ответственный, поэтому к интервью не готовлюсь. Это кстати я не шуткую, реально: если вы ответственный человек, то вы, когда предстаёте перед компанией, отвечаете за то, что вы заявляете как ваши умения. Можно выучить типовые вопросы и даже казаться умнее и опытнее, чем есть, но по факту это переобучение на тестовых заданиях/вопросах. Ребята из ml поймут. Поэтому я гол как сокол и чист как стёклышко или что там ещё блин, если что-то знаю - скажу, что-то не знаю - скажу что не знаю. Таким образом работодатель знает, что он покупает и сколько ещё нужно вложить в меня средств на обучение. Все счастливы.

    Интервью 1

    Так вот, назначили мне собеседование, и в назначенный час я был в зуме. Сразу скажу, что все - и рекрутер, и интервьюеры - вежливые и приятные в общении люди, тут я подкопаться не могу, ну разве что иногда они слишком корректные: спрашивают, ничего, если будет стажёр-наблюдатель и если они будут делать заметки в ходе интервью. На какой-то из итераций мне даже стало интересно, что будет, если я скажу "нет, нельзя", но именно тогда меня не спросили, так что предлагаю вам проверить самим.

    Мне кинули ссылку на Яндекс.Блокнот (это я его так называю, вообще он Яндекс.Код и живёт тут) - там можно вместе писать текст и включать подсветку синтаксиса. Запускать там, естественно, ничего нельзя, потому что это уже реализовано в coderpad, а он недостоин Яндекса. Ну ок, мне на самом деле проще, потому что написать код и написать хотя бы запускаемый код - это очень разные вещи. Минус - нельзя прогнать тесты и вообще тут как битва самураев: ваша правда против правды рекрутера, один доказывает, почему работает, другой - почему нет.

    Итак, о чём вас спросит Яндекс на интервью? Выберите один правильный вариант:

    1) прежний опыт

    2) текущие проекты

    3) как вы будете решать вот эту бизнес-задачу

    4) как решить вот эту алгоритмическую задачу без стандартной библиотеки

    Именно так! Так давайте решим эту алгоритмическую задачу. Помните, у нас нет collections.Counter, itertools.groupby, set.intersection, вообще случилась война и стандартная библиотека питона погибла, оставив после себя int, bool, for, if и while. Ну ок, хотят проверить знание каких-то базовых вещей.

    Задача 1

    Даны два массива: [1, 2, 3, 2, 0] и [5, 1, 2, 7, 3, 2]
    Надо вернуть [1, 2, 2, 3] (порядок неважен)

    Фактически нам нужно вернуть пересечение множеств, но с повторением элементов. Не включая мозг, я начал сразу кидать что-то вроде

    common = set(a).intersection(set(b))  # найдём общие элементы
    for el in common:
        occurs = min(a.count(el), b.count(el))  # и посчитаем, сколько они встречаются

    Но меня осадили - у нас война, поэтому никаких intersection, только хардкор. После нескольких итераций и намёков интервьюера я родил вот это:

    def common_elements(a, b):
      b_dict = defaultdict(int)  # defaultdict выжил :)
      for el in b:
          b_dict[el] += 1  # я считаю все элементы из b, т.е. типа collections.Counter
    
      result = []
    
      for el in a:
          count = b_dict[el]
          if count > 0:  # если какой-то элемент из a встречается в b
              result.append(a)  # то это успех
              b_dict[a] -= 1  # и я "вынимаю" его из b, т.е. уменьшаю его количество на 1
    
      return result
    

    Внимательные читатели намекнули, что на строчках 11 и 12 нужно использовать el, а не a, но на интервью и так прокатило :)

    Тут же меня спросили, какова сложность алгоритма - ок, норм, это нужно знать, потому что в реальном программировании мне это потребовалось целых 0 раз. Ответил.

    После этого задания (и впоследствии) я увидел, что хоть они и принимают рабочие решения, у них есть эталонные, к которым они вас подталкивают, особенно если сложность вашего решения больше сложности эталона. Не то чтобы прям только эталон принимают, но знайте, что он есть.

    Кстати, как вы наверно догадываетесь, есть большая разница между решением, написанным в обычной рабочей атмосфере, и решением, написанным на собеседовании в яндекс.блокнотике с интервьюером на связи и ограничением по времени. Здесь и далее я привожу те решения, которые сообразил на интервью, какими бы ужасными они не были. Можно ли написать лучше? Да, в каждой из задач можно лучше.

    Задача 2

    Ладно, лоу-левел алгоритмическая муть позади, давайте теперь нормальную задачу, распарсить там что-нибудь или накидать архитектуру высоконагруженного прило...

    Дана строка (возможно, пустая), состоящая из букв A-Z: AAAABBBCCXYZDDDDEEEFFFAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBB
    Нужно написать функцию RLE, которая на выходе даст строку вида: A4B3C2XYZD4E3F3A6B28
    И сгенерирует ошибку, если на вход пришла невалидная строка.
    Пояснения: Если символ встречается 1 раз, он остается без изменений; Если символ повторяется более 1 раза, к нему добавляется количество повторений.

    Ну ок, хотят проверить знание каких-то базовых вещей.

    Вроде просто: for grouper, items in groupby(string)... А, да, у нас была война. Ничего нет.

    def convert(s: str) -> str:
      result: List[str] = []
      last_sym = None  # последний символ, что мы видели
      count = 0  # и сколько мы его видели
    
      # мы будем идти по строке и записывать в result при смене символа
      for sym in (list(s) + [None]):  # последний None искусственно триггерит посленюю смену символа
    
          if last_sym and sym != last_sym:  # если случилась смена символа
    
              if count == 1:
                  result.append(last_sym)
              else:
                  result.append(last_sym + str(count))
    
          	  # начнаем запоминать новый символ
              count = 1
              last_sym = sym
    
          else:  # символ просто повторился
              count += 1  # ну ок, запомнили что символ видели на 1 раз больше
    
      return ''.join(result)
    

    Не помню точно, но с вероятностью 3 сигма я продолбал граничные условия - это я делать люблю. Помните, тут нельзя ничего запускать, вместо этого тут принято запускать интервьюера, который интерпретирует ваш код прям в голове и говорит какие случаи не работают, чтобы вы могли пропатчить код.

    Так, давайте может что-то другое?

    Задача 3

    Дан список интов, повторяющихся элементов в списке нет. Нужно преобразовать это множество в строку, сворачивая соседние по числовому ряду числа в диапазоны. Примеры:
    [1,4,5,2,3,9,8,11,0] => "0-5,8-9,11"
    [1,4,3,2] => "1-4"
    [1,4] => "1,4"

    Так блин, серьёзно? Я наверно очень мутный тип, если две предыдущие задачи не показали мой скилл на этом классе задач.

    Ну ок, хотят проверить знание каких-то базовых вещей.

    
    def repr(group_start, group_end) -> str:
        # это просто правильно печатает группу
        
        if last_group_start == last_group_end:
            return str(last_group_end)
    
        return f'{last_group_start}-{last_group_end}'
    
    
    def squeeze(numbers) -> str:
        if not numbers:  # граничный случай
            return ''
    
        numbers_ = sorted(numbers)  # сначала располагаем по порядку
        groups = []  # тут будем хранить группы
    
        last_group_start = None
        last_group_end = None
    
        for n in numbers_:
            # это первая итерация, просто говорим, что группа началась и закончилась
            if last_group_end is None:
                last_group_start = n
                last_group_end = n
    
            # если предыдущая группа отличается от текущего числа на 1, 
            # то это число входит в группу, то есть становится концом группы
            elif last_group_end == n-1:
                last_group_end = n
    
            # иначе мы понимаем, что группа закончилась,
            # мы её запоминаем и начинаем новую
            else:
                groups.append(repr(last_group_start, last_group_end))
                last_group_start = n
                last_group_end = n
    
        else:
            # посленюю группу придётся обработать вручную
            groups.append(repr(last_group_start, last_group_end))
    
        return ','.join(groups)
    

    На этом интервью закончилось, и я стал ждать вестей от рекрутера.

    Через пару часов мне сказали, что всё отлично и меня ждут на следующих интервью - 2 штуки подряд - задачи на написание кода. Так, минуточку, а что было до этого - написание говнокода? Ладно, там видно будет. Уж точно что-то новенькое, следующий этап всё-таки.

    Интервью 2

    В назначенный час я бахнул кофейку и встретился в зуме с новым рекрутером. Интервью #2 началось.

    Задача 4

    Я, признаюсь, был готов ко всему, но не к этому:

    Дан массив из нулей и единиц. Нужно определить, какой максимальный по длине подинтервал единиц можно получить, удалив ровно один элемент массива.

    [1, 1, 0]

    Ну ок, хотят проверить знание каких-то базовых вещей. Вот такой ужас у меня вышел:

    # пример: [0, 0, 1, 1, 0, 1, 1, 0]
    
    def max_ones_length(lst: List[int]) -> int:
    
        max_ones_length = 0
    
        # тут мы хотим получить сгруппированные 0 или 1 и их количество:
        subranges = []  # [(0, 2), (1, 2), (0, 1), (1, 2), (0, 1)]
        last_el = None  # последний элемент, который мы просмотрели
    
        # идём по элементам списка
        for el in lst + [0]:  # [0] - это ручной триггер для обработки последнего элемента
    
            if last_el != el:  # если произошла смена 0 на 1 или наоборот
                if el == 0:  # если это была смена 1 на 0
                  
                  	# пример: subranges == [(0, 2), (1, 2), (0, 1), (1, 2)]
                    # у нас произошла смена 1 на 0, до смены единица шла 2 раза
                    # (см последний элемент subranges) - проверяем, вдруг это
                    # максимальная длина
                    try:
                        last_ones_length = subranges[-1][1]
                        max_ones_length = max(last_ones_length, max_ones_length)
                    except IndexError:
                        pass
    
                    # а может если мы удалим один ноль между элементами 1 и 3,
                    # то получится более длинная последовательность единиц?
                    try:
                        gap_length = subranges[-2][1]
                        if gap_length == 1:
                            combined_ones_length = subranges[-1][1] + subranges[-3][1]
                            max_ones_length = max(combined_ones_length, max_ones_length)
                    except IndexError:
                        pass
    
                # добавляем новый счётчик последовательности в subranges
                subranges.append((el, 1))
    
            else:
              	# увеличиваем счётчик последней последовательности на 1
                subranges[-1] = (el, subranges[-1][1]+1])
    
            last_el = el
    
        # костыль, граничное условие
        if len(subranges) == 2 and subranges[1][1] == 1:
            return subranges[0][1] - 1
    
        return max_ones_length
    

    Ну что, Яндекс, ты доволен? Ты доволен?! Кто король алгоритмов?! Я король алгоритмов! Давай, удиви меня...

    Задача 5

    Даны даты заезда и отъезда каждого гостя. Для каждого гостя дата заезда строго раньше даты отъезда (то есть каждый гость останавливается хотя бы на одну ночь). В пределах одного дня считается, что сначала старые гости выезжают, а затем въезжают новые. Найти максимальное число постояльцев, которые одновременно проживали в гостинице (считаем, что измерение количества постояльцев происходит в конце дня).

    sample = [ (1, 2), (1, 3), (2, 4), (2, 3), ]

    Отлично, тут уже начинает появляться мир - ну там люди, отели, вдруг даже этот код реально где-то когда-то может пригодиться. Я прям вижу, как с каждой задачей будут появляться дороги, поезда, реки, горы и моря, металл, электричество, сервера и датацентры и блин задачи, которые будут работать в дата-центрах и серверах, ну хоть где-нибудь!

    Ну ок, хотят проверить знание каких-то базовых вещей.

    from collections import defaultdict
    
    def max_num_guests(guests: List[tuple]) -> int:
    
        res = 0
    
        # для каждого дня посчитаем, сколько приехало и сколько отъехало
        arriving = defaultdict(int)
        leaving = defaultdict(int)
    
        for guest in guests:  # O(n)
            arriving[guest[0]] += 1
            leaving[guest[1]] += 1
    
        current = 0
        # едем по дням в порядке увеличения, добавлем приехавших и убавляем уехавших,
        # считаем сколько стало
        for day in sorted(set(arriving.keys()).union(set(leaving.keys()))):  # O(n*log(n)) + O(n)
            current -= leaving[day]
            current += arriving[day]
    
            if current > res:
                res = current
    
        return res
    

    Не без подсказки интервьюера, но я написал это, и теперь менеджер, наверно, может эффективно узнать важную инфу. Круто. Пора прыгать на следующее собеседование (да, они шли одно за другим).

    Интервью 3

    Новый интервьюер; можно наблюдателя; можно писать заметки; да, я знаю, как работает ваш яндекс.блокнот лучше вас уже, давайте наконец

    Задача 6

    Sample Input ["eat", "tea", "tan", "ate", "nat", "bat"]
    Sample Output [ ["ate", "eat", "tea"], ["nat", "tan"], ["bat"] ]

    Т.е. сгруппировать слова по "общим буквам".

    Смутное чувство дежавю посетило меня... Нет, показалось наверно. Ну ок, хотят проверить знание каких-то базовых вещей.

    Эта задача простая, наверно хотят удостовериться, что пока я разруливал дела в отеле, я не забыл, как пользоваться словарём. Не лишено смысла! Давайте накидаем что-нибудь простое.

    def group_words(words: List[str]) -> List[List[str]]:
    
        groups = defaultdict(list)
    
        for word in words:  # O(n)
            key = sorted(word)
            groups[key].append(word)
    
        return [sorted(words) for words in groups.values()]  # O(n*log(n))
    

    Тут меня спросили "а какая сложность у сортировки", и я воспользовался лайфхаком. Дело в том, что все собеседования проводятся разными людьми, и они вообще не знают ваш контекст - например, о чём я говорил в предыдущих сериях и, например, кхм, сколько алгоритмических задач я прорешал до этого. На прошлом собеседовании меня спросили, какая сложность у сортировки, я не знал и мне сказали - и на этом собеседовании я уже ответил.

    Задача 7

    Слияние отрезков:

    Вход: [1, 3] [100, 200] [2, 4]
    Выход: [1, 4] [100, 200]

    Честно говоря, где-то тут мне уже стало плевать на собеседование, Яндекс и все эти алгоритмы, и в реале я бы уже просто послал всех в /dev/null, но мне хотелось знать, что в конце всего этого, ведь конец должен быть? Будет задача, где я завалюсь, и это кончится. Что-то вроде эвтаназии, но в интервью.

    Ну ок, хотят проверить знание каких-то базовых вещей.

    def merge(ranges: List[Tuple[int, int]]) -> List[Tuple[int, int]]:
    
        if not ranges:
            return []
    
        result_ranges = []
        last_range = None  # последний отрезок, что мы видели
    
        for rng in sorted(ranges):  # обязательно сортируем
    
            if not last_range:
                last_range = rng
                continue
    
            # если начало текущего отрезка меньше конца предыдущего
            if rng[0] <= last_range[1]:
                # расширяем предыдущий отрезок на текущий
                last_range = (last_range[0], max(rng[1], last_range[1])
    
            # старый отрезок всё, начинаем новый
            else:
                result_ranges.append(last_range)
                last_range = rng
    
        else:
            # граничный случай для последнего элемента
            result_ranges.append(last_range)
    
        return result_ranges

    Задача 8

    Время собеседования подходит к концу, но всё-таки можно ещё поболтать про кодинг и поспрашивать практические вопросы, например по Django или SqlAlchemy:

    Дан массив точек с целочисленными координатами (x, y). Определить, существует ли вертикальная прямая, делящая точки на 2 симметричных относительно этой прямой множества. Note: Для удобства точку можно представлять не как массив [x, y], а как объект {x, y}

    Ну ок, хотят проверить знание каких-то базовых вещей.

    Тут я как всегда пошёл куда-то не туда и написал вот что:

    from statistics import mean
    
    def is_vertical_symmetry(points: List[Point]) -> bool:
    
      	# сначала найдём вертикальную прямую в середине всех точек
        x_center = mean(p.x for p in points)
    
        # тут будем хранить точки, для которых пока не нашли пары:
        unmatched_points = defaultdict(int)
        
        for point in points:
    
            if point.x == x_center:  # если точка на прямой, то она сама себе пара
                continue
    
            # создадим "брата" - точку, которая симметрична текущей относительно вертикальной прямой
            brother = Point(
                x = x_center * 2 - point.x,
                y = point.y,
            )
            
            # если этот брат есть в unmatched_points, то достаём его оттуда и говорим, что текущая точка сматчилась
            if unmatched_points[brother]:
                unmatched_points[brother] -= 1
                
            # иначе добавляем эту точку в не-сматченные
            else:
                unmatched_points[point] += 1
    
        return not any(unmatched_points.values())

    Здесь я прям видел, как интервьюер ожидал что-то другое, а получил меня. Ну бывает. Я тоже, знаете, ожидал собеседование.

    Так, третье собеседование пройдено, и эти садисты сказали, что я прошёл дальше. Ну вот за что?

    Интервью 4

    Честно говоря, вот тут я потерялся, потому что я всё жду, когда начнётся собеседование, ну, человеческое собеседование имеется в виду, а пока вместо этого я превращаюсь в алгоритмэна.

    По собственным ощущениям я добрался до какого-то мини-босса и на предстоящем интервью у меня должна была пройти какая-то битва на более общие вопросы. А рекрутер мне пишет: знаете, Яндекс настоятельно советует потренироваться на задачках с leetcode. А там опять алгоритмы. Ох, не к добру это...

    Ну тут уж я сломился и решил таки глянуть, что там за задачки, раз мне так настойчиво намекают. Вообще там есть сложные, и над ними было прикольно подумать и порешать в уме, но я так и не понял, как это поможет в интервью. Задачек слишком много и, что более важно, они, блин, разные, и решив одну, я не решаю класс задач - я решаю одну задачу. Соответственно либо я решаю их все и зачем мне тогда ваш Яндекс после такого, либо... короче, я опять не готовился. Ответственный человек, помните?

    Кстати, где-то в этот момент я узнал, что я юзаю что-то вроде тора, но для собеседований: я общаюсь с рекрутером, мой рекрутер общается с рекрутером Яндекса, а рекрутер Яндекса общается с собеседователями, а может цепочка ещё больше. Меня это поразило прям: вы меня тут дерёте за O(n^2) в решениях, так может я у вас посчитаю длину цепочки от кандидата до собственно интервьюера и спрошу "а можно оптимальнее?!"

    Итак, началась четвёртое (да, ей-Богу) интервью. Интервьюер спрашивает, на каком языке я буду решать задачки. На йоптаскрипте, разумеется. Кстати, по косвенным признакам я понял, что интервьюер больше в C, чем в питон, и это тоже здорово. Итак: после того как компания решила нанять сеньор питон разраба за 200к и сношала его 3 часа на долбанных задачках, она отправляет на собеседование сишника и спрашивает, на каком языке кандидат будет сношаться с долбанными задачками. Л - логика!

    Итак, вот задачка от мини-босса:

    Задание 9

    Даны две строки.

    Написать функцию, которая вернёт True, если из первой строки можно получить вторую, совершив не более 1 изменения (== удаление / замена символа).

    Погодите, да это же... Ну ок, хотят проверить знание каких-то базовых вещей. Сссссуууу...пер.

    Если вы хотите решить задачу не так, как хотел интервьюер, то смотрите:

    def no_more_than_one_change(string1: str, string2: str) -> bool:
      
      	# string1: a b c d
        # string2: a b c
    
        max_length = max(len(string1), len(string2))  # наибольшая длина строк
        diff = abs(len(string1) - len(string2))  # разница в длине строк
    
        # дополняем строки до максимальной длины при помощи zip_longest,
        # то есть на место "недостающих" элементов ставим None, и строки
        # теперь одинаковой длины;
        #          ---->
        # string1: a b c d
        # string2: a b c None
        
        # идём слева направо по обеим строкам и сравниваем символы,
        # находим индекс, при котором строки начинают отличаться:
        change_left = None
        for i, (char1, char2) in enumerate(zip_longest(string1, string2)):  # O(n)
            if char1 != char2:
                change_left = i  # в нашем примере будет 3
                break
        else:
            # если мы такой индекс не нашли, то строки просто совпадают
            return True
    
        # теперь делаем то же, но идём справа налево:
        # string1:    a b c d
        # string2: None a b c
        #               <----
        change_right = None
        for j, (char1, char2) in enumerate(zip_longest(reversed(string1), reversed(string2))):  # O(n)
            if char1 != char2:
                # тут строки прям сразу отличаются, т.е. в индексе j=0;
                # но это у нас индекс в системе "справа налево",
                # а мы его переводим в индекс в системе "слева направо":
                i = max_length - j - 1 + diff
                break
        else:
            assert False, 'Я дебил и что-то не учёл'
    
        # ну а теперь смотрим, если строки отличаются в одном и том же месте 
        # при сканировании слева направо и справа налево, то это нам подходит
        return change_left == change_right
    

    Внимательный читатель может заметить, что, по-моему, это даже на приведённом примере не работает :) , хотя пофиксить несложно. Так или иначе, вот такие вещи как я написал лично мне тяжело гонять в голове, и интервьюеру тоже; интервьюер принял это как решение, прогнав несколько тестов в уме. Если хотите возвести это в абсолют, то пишите сразу на brainfucke и с умным видом объясняйте, почему оно будет работать. А вообще я просто тонко намекаю, что всё-таки компилятор/интерпретатор под рукой нужен.

    Задание 10

    Осталось совсем немного времени, и вот в довершение пара реально сложных заданий на понимание многопоточности и gil в python:

    Дан список интов и число-цель. Нужно найти такой range, чтобы сумма его элементов давала число-цель.

    elements = [1, -3, 4, 5]

    target = 9

    result = range(2, 4) # because elements[2] + elements[3] == target

    А теперь все вместе хором: НУ ОК, ХОТЯТ ПРОВЕРИТЬ ЗНАНИЕ КАКИХ-ТО БАЗОВЫХ ВЕЩЕЙ. Вы восхитительны. Спасибо.

    Здесь я уже не успевал по времени и озвучил идею: мы бежим по списку и сохраняем в память значения сумм для всех range до этого элемета. Иными словами, для каждого элемента мы пробуем делать ranges, которые кончаются на этом элементе, и смотрим на их сумму элементов.

    [1, -3, 5, 6, 2, 3, 5]
     ^____[range(0,1)=1]
     
    [1, -3, 5, 6, 2, 3, 5]
         ^___[range(0,2)=range(0,1)-3=-2, range(1,2)=-3]
         
    [1, -3, 5, 6, 2, 3, 5]
            ^___[range(0,3)=range(0,2)+5=3, range(1,3)=range(1,2)+5=2, range(2,3)=5]

    Не угадал, конечно - "а можно чтобы быстрее?". Но тут, к счастью, время вышло, и мой мозг не успел придумать ничего лучше.

    >> Сейчас я нахожусь здесь <<

    Прелесть ситуации в том, что я ещё не получил фидбек, то есть я кандидат Шрёдингера - я и прошёл (формально я все задачи решил), и не прошёл (== не всё угадал, где-то баги), и суперпозиция сколлапсирует, когда ответ пройдёт через всю цепочку рекрутеров ко мне. А пока я полностью беспристрастен, ведь 1) меня не отшили, то есть это не пост обиженного на компанию человека, и 2) мне плевать на результат, потому что мне и на текущей работе офигенно.

    К чему всё это

    Вообще это просто так тупо, что забавно, и я не мог с вами не поделиться. Никак не связанные люди тестируют меня на одном и том же типе задач, который максимально оторван от реальности, всё это длится много часов, сложность задач неупорядочена, проверяется всё в голове и никакого фидбека.

    Сколько вопросов, блин, можно спросить про http, rest, django orm, sql, python, stdlib, docker, multithreading/multiprocessing/async, да про что угодно - что вы там в лавке делаете? - спросите про похмелье, но зачем 4 часа алгоритмов? Что это показывет - что я устойчив к тупости? Честно говоря, я уже не уверен.

    Может кому-то пригодится разбор задачек, ну вдруг вы любитель такого, хотя я уже говорил о качестве решений :)

    А если вам нужен вывод, то вот несколько, берите любой:

    • Тестировать кандидатов нужно на реальных задачах, а не синтетических

    • Нужно уважать время кандидатов

    • Кто-то в яндексе пересмотрел "день сурка"

    • Знаете, когда целое не равно сумме частей? Вот тут так же: люди тебя собеседуют хорошие и встречи приятные, а в целом всё гавно.

    • Открыто новое достижение: ругательство "да пошёл ты в яндекс!"

    • Большие компании ай-яй-яй

    • Какой-то чувак написал смешную статью

    И да, если вы ищете работу на питоне - залетайте к нам. У нас не Яндекс.

    Only registered users can participate in poll. Log in, please.

    Яндекс или не Яндекс?

    • 6.4%Яндекс319
    • 48.6%Не Яндекс2430
    • 51.6%[object Object]2580
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 1253

      +175
      Стиль изложения — огонь. Жду продолжения истории
      Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
        +235
        Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет

        Бедные курьеры...

          +217

          Не курьеры, а коммивояжеры.

            +52
            И решали задачу о рюкзаке?
              +7
              Это та же задача, что и о коммивояжерах
                +5
                Коммивояжёр решает рюкзак, наоборот нет.
                Авторитетно, как яндекс-курьер получивший оффер, заявляю.

                ПС
                : sarcasm:
                  +1

                  Я не настоящий сварщик, я маску нашёл, но насколько я понимаю, под словами "задача коммивояжёра" и "задача о рюкзаке" могут подразумеваться несколько разные вещи, в том числе NP-полные задачи, так что сведение одной к другой неочевидно в таком простом заявлении, как ваше :)

                    +1
                    вы слишком многого хотите от курьера яндекс-яды.

                    Но если брать формулировку по «knapsack problem» и «travelling salesman problem» в английской вики — то я не вижу как решение второго свести к решению первого (без многократного повторения или увеличения размерности задачи).
                      +1

                      Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)


                      Руку на отсечение не дам, но вроде бы, в обоих случаях задачи разрешимости NP-полны, и не всегда ясно, когда говорят просто про рюкзак (коммивояжёра), имеются ли в виду оптимизационные задачи или речь про разрешимость.

                        0

                        Насколько я вижу по вики (да и всегда думал) — задачи имеют разное название потому что это разные задачи. Там где задачи явно сводятся к другим обычно это пишут, например тут


                        The knapsack problem is a generalization of subset-sum.

                        Если не пишут значится что не сводится одно к другому

                          +1
                          Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)

                          Если вы чистите трубы только тем, кто не может прочистить их сам, у меня к вам есть один вопрос. :)

                            +1

                            Ну вообще я только свой дымоход чищу, но давайте вопрос!

                              0

                              Вопрос как раз и был о том, чистите ли вы свой дымоход. :)


                              Раз уж мы тут про профессии и теоретическую информатику говорим, грех было не вспомнить парадокс Рассела.

                                +1

                                Мне диплом был нужен только для того, чтобы страховка не придиралась к тому, что я не вызываю два раза в год дипломированного специалиста. А так я сам себе Буратино :)


                                Но действительно, Рассела не узнал, богатым будет.

                      0
                      Ветка огонь. Теперь финальная задача. Обойдите все дерево комментов не заржав ни разу) Стандартной библиотекой пользоваться нельзя)
                        0
                        Я срезался на вашем комменте.
                    +2

                    Сколько теннисных мячей поместится в сумку

                      0
                      а сколько это будет в виде гитар?
                        +19
                        Питерская контора яндекса должна помещать в сумки тело.
                          +1
                          … найти минимальное количество распилов, чтобы уместить тело в заданном объеме…
                            0
                            С учётом тяжести пиления или без?
                              0
                              Учитывайте, но сторонние библиотеки нельзя.
                        0
                        Они ее распараллеливают, отправляют сразу 100500 курьеров одновременно, кто-то да дойдет.
                          +1
                          Доставка еды по UDP? Приезжает отдельно колбаса, потом сыр и только к утру сам блин, а коробка где-то теряется
                            +1

                            Вы только что Wildberries описали :)

                      0

                      В голос, спасибо! :)

                        +1
                        Они думают, что так и будут по алгоритмам бегать, а после приема на работу приходится бегать по городу.
                        +40
                        Это не шутка, ну или почти не шутка. Давно проходил собеседование на позицию Project-manager — первым вопросом было: «Какие алгоритмы сортировки вы знаете?»
                        Через много лет, когда стал Solution Architect, также было интервью по этой позиции, и угадайте каким был первый вопрос?:)
                          +144
                          Да я и второй угадаю: «А можно быстрее?».
                            +6
                            > Какие алгоритмы сортировки вы знаете?

                            Не, ну это ещё можно вытерпить. Хуже, когда хрюша идёт по опроснику и спрашивает «Какой алгоритм сортировки лучший?».
                              +5
                              А для вас это очевидный вопрос? я бы если честно замешкался, т.к. нет никакого лучшего алгоритма. А что подразумевается-то?
                                +2
                                Вот именно!
                                +5
                                Вопрос-то с подвохом: если назовете хоть один — пиши пропало.
                                  +5

                                  "Каждое ваше слово может быть использовано против вас"

                                    +6
                                    Старый анекдот в тему
                                    — арифмометр
                                    — что арифмометр?
                                    — используйте против меня арифмометр
                                      +3

                                      В оригинале была голая баба :)

                                  0
                                  задать вопрос «а вы по какой книжке опрос составляли?» 8)))))
                                +10
                                Так и есть, гоняют будь здоров, всегда. До 12 собеседований по алгоритмам доходит, а то и больше. И статья, про яндекс беспредел, уже далеко не первая и не последняя, но они имеют тенденцию удаляться. Люди на таком собеседовании разные попадаются, одни тебя пропустят, другие завалят на одних и тех же задачах. Ладно бы это было только в онлайне, а то и приехать просят, а это уже 4 часа только на одно такое собеседование. А если с возрастом давление шалит, то и не на каждом собеседовании блеснуть получается.
                                  +48
                                  И ради чего?.. свет клином же не сошелся на Яндексе… Уж лучше какой-нить европейский стартап.
                                    +37
                                    Ради того чтобы сказать, решаете вроде правильно, но как то медленно, и вообще мы Яндекс, вот вам на 100 тысяч меньше обещанной ЗП, выходите на работу и гордитесь что мы вас взяли. (из личного опыта)
                                      +9
                                      «Работать в нашем банке — большая честь» (С)
                                    +1
                                    При всех минусах такого найма, там работают отличные разработчики. Так что могут себе позволить. Желающих много. Да и найм у них в основном с вузов, где живут олимпиадными задачками.
                                      +2
                                      Это плохая тенденция — считая себя великим, позволять себе «неадекватность». И потом, отличные разработчики работают практически везде, даже дворниками. Тем более что желающих много, каждого так собеседовать по 6-12 часов — это как то жирно, больше похоже на практику для уже работающих. А уж олимпиадными задачами не кормиться только ленивый, они в открытом доступе и даже нашему коллективу филиала из «откуда-то» удалось попасть в полуфинал мирового чемпионата. И все же, больше вопросов возникает к отдельным личностям, а не к общему маразму.
                                    +4
                                    К сожалению, это не шутка…
                                      +26

                                      И ЗП меньше среднего, прям как в Яндекс доставке!

                                        0
                                        Ну кстати неизвестно. до ковидлы ходил к ним на тех.манагера собеседоваться. на входе просил немного больше среднего по рынку (хотя хз может оно срденее или ниже, а я не знал)), но они не отказались общаться
                                          +13
                                          Работал в Яндексе техническим менеджером, в итоге предложили зп сильно ниже того, что озвучивал. Но я уже прошел все собеседования, потратил кучу времени и в итоге решил рискнуть) Через год уволился)
                                            +2
                                            Я не дошел до конца) После третей собеседки отказали (у меня последний опыт хреланса/удаленки, а это для них, как выяснилось, зашквар).
                                              +10

                                              видимо, в этом и цель многодневных собеседований.


                                              это как тест на 500 вопросов, в конце которого надов вести номер карты, чтоб узнать, какой вы олень.

                                              +1

                                              А они так и делают всегда, но в конце будет меньше всё-равно.

                                            +1
                                            Это не шутка
                                              +25
                                              Собеседовался пару раз на девопса в Яндекс, первый раз года 3-4 назад, поговорили даже нормально половину интервью, потом дрочево алгоритмов, второй раз года полтора назад, всё проходило 1в1 как тут описано, готовился не менее ответственно, чем автор поста.
                                                +5

                                                После прочтения предыдущих комментов и поста, а потом вашего коммента, в голове само всплыло название следующего сервиса: Яндекс.Девопс. Ну, знаете, сдача админов, которые почти прошли собеседование, в аренду клиентам Я.Облака.


                                                Ну, чтобы просто результаты собеседований хоть как-то применить, даром, что они по алгоритмам!

                                                  0
                                                  Примерно то же самое проходил перед нг, но у меня сложилось впечатление, что у яндекса девопс это бекендер на дежурствах. Прошел первый такой этап, но настойчиво порекомендовали порешать больше задач на алгоритмы. Продолжать эти круги собеседований я не захотел и просто слился.
                                                    +1
                                                    Несколько лет назад собеседовался на разработчика в Облако. Ожидал, что будет много вопросов по алгоритмам, но завалили вопросами по «железкам» и всему, что около них, а потом дали пару задач на лайвкод на любом удобном языке.
                                                    На многие вопросы из первой части я ответил с большим трудом, а на некоторые ответов вообще не знал, что наверняка и послужило поводом меня слить)
                                                    +15
                                                    Напомнило: когда в 2008 (или 2009) на заре карьеры я устраивался в яндекс тоже просили проверить на корректность какое-то дерево и возмущались, что я знаю Руби: не то что пишу на нем, тестовое задание делал на C++, а именно что вообще знаю — интервьюер говорил с презрением «что это за Руби?», «какой-то учебный язык?», «какой-то школьный что-ли?».
                                                    Такое впечатление, что в яндексе хорошо умеют проверять знание алгоритмов — вот и ищут специалистов где светлее, а не за углом где потеряли.
                                                      0
                                                      Это неправда. В данном случае просто не повезло с подрядчиком, кому заказали рекрутирование. В моем случае все было лучше, глушил уже сотрудник Яндекса на последнем этапе, противореча собственным же инструкциям. Правда даже пройдя все этапы, нет уверенности, что вы будете работать в Яндексе, а не на Яндекс в какой-то левой фрилансовской компании.
                                                      Правда это было достаточно давно, что бы Яндекс не мог засудить меня за разглашение, ибо соглашение о неразглашении истекло.
                                                        –5

                                                        Меня не взяли водителем беспелоднега хотя я идеально соответствую требованиям вакансии. Про алгоритмы, с.ка, даже не спросили...

                                                          +2
                                                          Ходил на DevOps'a собесится. Было ТРИ собеса по алгоритмам, одно по админству и ни одного по ci/cd и профильным сервисам. Там оч странно
                                                            0
                                                            Подскажи плиз, как и зачем собесить по ci/cd, если это учиться за неделю-две и в Яндексе свои велосипеды?
                                                              +1
                                                              Хочешь сказать чтобы писать эти велосипеды вообще не надо ничего уметь?

                                                              Работаю девопс-инженегром. Ни разу за 6 лет не понадобились знания алгоритмов сортировки или слияния массивов. Скрипты пишу постоянно…
                                                              0
                                                              Расскажи, пожалуйста, как ты видишь идеальное собеседование на DevOps'a.
                                                              0
                                                              в 2018 собеседовался на продажника в яндекс. Задавали алгоритмический задачки))
                                                              И еще кучу беспонтовых вопросов
                                                              +3
                                                              А мне понравились алгоритмические задачки в яндексе. Первым делом в голову приходит простой алгоритм с большой сложностью. А потом при помощи подсказок собеседующего и всяких хитростей он доводится до сложного, но с малой сложностью. Но у меня, конечно, таких задачек было штуки 4 на двух собеседованиях. На остальных проверяли уже не алгоритмы.
                                                                +44

                                                                Задачки нормальные, но зачем столько? Трёх-четырёх достаточно. Я бы уже на втором таком интервью вежливо распрощался, если я захочу порешать задачки, я пойду на hackerrank или leetcode.

                                                                  +6

                                                                  В свое время я не успел решить одни задачки на время, честно сказал интервьюеру, что если им так нравится, они могут сами решать олимпиадные. В ответ получил оффер.

                                                                    0
                                                                    Так там разные люди собеседуют. Друг другу не доверяют, вот и перепроверяют каждый раз… как в Яндекс.Толока. А вы как думали?
                                                                      0
                                                                      Так могли бы все в одно время поприсутствовать на решении этих алгоритмических задачек… А то время кандидата получается вообще им не жалко.
                                                                        0
                                                                        Ну как бы меркантильно это ни звучало, но время кандидата дешевле, чем время разработчика. Потому что большинство кандидатов отсеются с нулевым результатом, а разработчик время-то потратит всё равно.
                                                                          0

                                                                          Внезапно, кандидат тоже работает, собеседование ему никто не оплачивает (а часто это во время рабочего дня) => вылазка для него может оказаться достаточно проблематичной.

                                                                            0

                                                                            Ну значит поток кандидатов с высокой самооценкой поредеет и это частично тоже решит задачу "снизить поток заявок до приемлемого уровня".

                                                                          0
                                                                          А почему им его должно быть жалко? Это ж не их время. Вот времени своих разрабов — наверняка жалко.
                                                                      +11
                                                                      Ну так если вам нравятся, то и решайте их на leetcode)
                                                                      Они созданы, чтобы проверять знание кандидатом базового синтаксиса. Конечно, немного думалка тоже проверяется, но алго-думалка с обычной не совсем коррелирует и даже скорее совсем не коррелирует.
                                                                        +36
                                                                        Я бы сказал так – в промышленной разработке очень полезно знать, как устроены алгоритмы, но крайне плохо, если их приходится писать самому.
                                                                          –9
                                                                          Это крайне плохо, да. Пока вы не сталкиваетесь с масштабами Яндекса. Когда вам нужен хэш-тейбл на миллиард элементов, то внезапно оказывается что стандартная реализация не такая уж и хорошая.
                                                                            +16
                                                                            Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
                                                                            Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
                                                                            А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)
                                                                              0

                                                                              Но там не задают задачу на написание хеш таблицы. Максимум на использование. И полностью рабочее бинарное само-балансирующееся дерево — тоже не задают. Максимум тривиальное дерево. Просто для проверки, что кандидат может представить структуру и хоть чуть-чуть понимает, как работают указатели.

                                                                                +1
                                                                                Вот именно. То есть зачем они ищут тех, кто пишет алгоритмы а не программы — непонятно.
                                                                                  +3
                                                                                  А как проверить? Алгоритмы хороши тем что не умея программировать их не выучишь наизусть за 3 месяца. В отличии от баззвордов и 100 типовых вопросов по любой технологии.
                                                                                  И на софт скилах не выедешь, как можно сделать в разговоре за жизнь.
                                                                                  И можно разных кандидатов сравнивать друг с другом. По формализуемым признакам.

                                                                                  Предложите альтернативный вариант. Чтобы не хуже было хотя бы по этим критериям.
                                                                                    +1
                                                                                    Ну народ за несколько месяцев мощно насобачивается на решение задач с leetcode.
                                                                                      0
                                                                                      Да. Народ уже умеющий нормально программировать. Не случайные люди с улицы после курсов вайти.

                                                                                      Какой варинат решения прелагаете? Спрашивать еще сложнее? Рюкзак модифированный так чтобы его случайный человек не узнал пойдет? Так отсеются вообще все. Случайный мидл даже после сидения на литкоде не справится же.
                                                                                      +5
                                                                                      Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.

                                                                                      Более-менее нормальный подход — давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить (то есть надрочиться на литкоде не поможет), а головой подумать, плюс и прикладной смысл чтобы был, и дать человеку ее решать в привычной среде — просто расшарив экран. Пусть гуглит что хочет (кроме прямого решения задачи, конечно), вообще разрешено все (как и что человек гуглит — это вообще о многом сразу говорит!). И посмотреть, КАК человек это все делает. Такое, типа, парное программирование.

                                                                                      Тут, конечно, формальных баллов не начислишь, все субъективно. Но уровень сразу виден, уже через пять минут на самом деле.
                                                                                        +3
                                                                                        давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить

                                                                                        Ну посмотрите же задачи из статьи. Где там хоть одна, где надо алгоритмы помнить? Максимум, знать, что есть такая структура данных — хеш-таблица.

                                                                                          +2

                                                                                          А примерчик ещё проще чем в статье можно? Там все еще проще вырождается в однострочник или физзбазз.


                                                                                          IDE или не IDE дискуссионно.

                                                                                            0
                                                                                            Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.

                                                                                            Ну так в отличие от ИДЕ от вас не требуется написать компилируемый код, а иногда не требуется и брать существубщий ЯП — достаточно просто набросать алгоритм, чтобы было понятно что куда и как. Вангую что никто не будет докапываться если в каком-нибудь SelectMany букву забудете или порядок аргументов какой-нибудь функции перепутаете. Главное как вы будете рассуждать и какие уточняющие вопросы задавать.

                                                                                              0
                                                                                              Код запускается и проверяется. Но это по моему опыту и знакомых.
                                                                                                +3

                                                                                                Если от вас требуют написать без ИДЕ на бумажке идеально компилирующийся код без ошибок — то это вполне хороший фактор чтобы туда не идти. Так что не вижу ничего плохого в том чтобы получить на такое отказ.

                                                                                                  0
                                                                                                  Это где? Особенно с вайтбордом интересно — по-вашему, интервьюер потом сидит и перепечатывает код?
                                                                                                    0
                                                                                                    В яндексе, но не у всех. Зависит от интервьюера.
                                                                                              0
                                                                                              Умение писать алгоритмы, и умение работать в команде, знать фреймворки и другие вещи — вообще не особо связано.

                                                                                              Но вопрос в основном в театре абсурда, когда тебе на 10 интервью задают то одни то другие алгоритмы И НИЧЕГО по технологиям

                                                                                              А в разговоре за жизнь можно много чего узнать. Что человек сделал, зачем, почему.
                                                                                              +7
                                                                                              пишет алгоритмы а не программы

                                                                                              Что? По определению, любая программа — алгоритм. Если вы придираетесь к тому, что там на интервью спрашивают заумные алгоритмы, которые в реальной работе не пригодятся — то вы не правы.


                                                                                              Вам так сложно представить, что в яндексе может возникнуть задача взять общие элементы из двух списков (задача из статьи с интервью)?


                                                                                              Я за свою недолгую пока карьеру в гугле много раз использовал и математику и писал хитрую структуру данных, и динамическое программирование. Не каждый день конечно, но эти вещи реально пригождаются. И самое печальное, что если этого всего не знать, то даже мысль не возникнет о том, что вот тут можно было "алгоритм" впендюрить и получить более быстрый и простой код. До этого немного поработал в яндексе, и там пришлось, например, использовать trie для ускорения процесса в несколько раз. Этой структуры нет в stl. Про нее надо хотябы знать, иначе как вообще ее нагуглить?

                                                                                            +5
                                                                                            Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
                                                                                            Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.

                                                                                            Так ведь в каждой конкретной ситуации надо смотреть и думать, что нужно. Не может быть универсального решения, т.к. где-то очень важен lookup-time (не асимптотика, а чистое время), где-то важен объём памяти, занимаемый данной структурой. Вы, кажется, не понимаете, что когда речь идёт о миллиардах, то начинает быть важна каждая мелочь.

                                                                                            А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)

                                                                                            Ну всем подряд и не задают. У вас тут типичная ошибка выжившего. Те, у кого интервью прошло нормально — они на хабре статей не пишут. Тут не принято писать о том, что в Яндексе хорошие собеседования, за такое можно и минусов отгрести. Поэтому вы со стороны видите только те собесы, которые прошли отстойно. Или прошли нормально, но человеку не хватило компетенции понять, что его вообще спрашивали и какие скиллы проверяли.
                                                                                            0
                                                                                            Всё это помешательство на алгоритмах может объясняться, гипотетически, двумя возможными причинами:
                                                                                            — это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),
                                                                                            — это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.
                                                                                            Бардак с «деревом» собеседующих (изоляция процесса найма от реальных задач, как результат этого), размер компании, а также некоторые решения, которые ранее использовались Яндексом, склоняют меня к тому, что более вероятно второе. Ваш же аргумент косвенно исходит из первого, а возможность второго — игнорирует.
                                                                                              +5
                                                                                              — это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),

                                                                                              О, ну тут всё просто. Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива». Потому что им на практике нигде не надо было работать работать с большими данными и, соответственно, задумываться про асимптотику и т.п. Поэтому к «реальным» задачам далеко не все могут перейти. Но они есть, вполне себе интересные.

                                                                                              это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.

                                                                                              Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).
                                                                                              Текущая система используется (кстати, в том же FAANG примерно всё то же самое при найме — регулярно прохожу собесы чтобы «знать рынок») не потому что идеальная, а потому что пока лучше ничего не придумали.
                                                                                                +2
                                                                                                Раз вы ссылаетесь на свой опыт, скажите, сколько алгоритмических задач начального уровня нужно дать кандидату, чтобы надежно отсеять этих самых неспособных, которых вы упомянули?
                                                                                                  +1
                                                                                                  Ох, сколько нужно — не знаю. Обычно я даваю две простых задачи. Я считаю, что если человек не может решить одну простую задачу — мб не повезло, нервничает и т.п. А если не может решить две — это уже закономерность.
                                                                                                  Но тут ведь система со смещённым фидбэком: если мы наняли слабого человека (т.е. человек оказался слабее, чем показалось при найме), то мы об этом узнаем; а если не взяли сильного (т.е. человек оказался сильнее, чем нам показалось) — то не узнаем. Поэтому очень сложно подобрать оптимальное количество и сложность задач.

                                                                                                  Есть ещё интересное соображение: если давать много простых задач, то можно не успеть дать сложные (и недооценить кандидата). И это действительно правда, изредка так и бывает. Но если дать сразу сложную задачу и кандидат её не решит — тут всё намного хуже. Т.к. если кандидат не решил сложную задачу — это не значт, что он не подходит, мб он пойдёт на должность ниже. Надо разибраться с причиной того, почему конкретно человек не смог решить задачу — а это ну очень сложно. Я видел как люди на собесе очень хорошо всё рассказывают по плану задачи, но не хватает времени написать код. Их берут в штат, и оказывается, что люди и код-то толком писать не умеют. Это было бы отлично видно, если бы дали простую задачу, но т.к. дали сложную — то подумали, что «перемудрили с задачей, давайте просто дадим ему не сениора, а мидла».
                                                                                                    0
                                                                                                    Вы налили тонну воды, но ответ все же дали — две задачи должно быть достаточно для общего случая. А теперь перечитайте статью и посчитайте, сколько дали автору. Я не знаю, о чем тут можно спорить.
                                                                                                    Все перечисленные нюансы — реальность, но другого порядка.
                                                                                                      0
                                                                                                      Вы налили тонну воды, но ответ все же дали — две задачи должно быть достаточно для общего случая.

                                                                                                      Я не дал ответ который вы хотели услышать. Но если вы читали невнимательно, то вот мой ответ:
                                                                                                      сколько нужно — не знаю.
                                                                                                        +3
                                                                                                        Две задачи достаточно, если один интервьювер на всех и он абсолютно объективен/непоколебим.
                                                                                                        На деле же, когда у компании 1000 кандидатов, а нанять надо 50-100, то интервьеров будет человек 100. Из них части попадутся знакомые знакомых, часть окажется олимпиадниками, которым ничьих знаний не будет достаточно, части будет не жалко нанимать всех, кто решит простую задачу, которую решают на первом курсе любого вуза. А ещё кандидат может одному интервьюеру понравиться, а другому нет визуально, может разволноваться с одним интервьюером, а с другим — нет и т.п. Получится рандом, усугубленный тем, что сильных кандидатов меньшинство.

                                                                                                        Для примера пусть из 100 собеседующих 25 не наймут никого, 25 наймут любого, а 50 наймут сильного кандидата и не наймут слабого.
                                                                                                        Пусть из 1000 кандидатов 100 сильных (кого в идеале хотел бы нанять Яндекс; каждый 10й).

                                                                                                        Тогда при одном собеседовании на каждого кандидата будет нанято 25% (шанс попасть на лёгкого собеседующего) * 900 = 225 слабых кандидатов и 75%*100 = 75 сильных. А надо бы, чтобы соотношение было 0 на 100.
                                                                                                        Вот и делают дублирующие собеседования.
                                                                                                        Если на каждого кандидата по две секции и нанимают только тех, кто прошел обе, будет нанято 56 (900*0,25*0,25) слабых кандидатов и 56 сильных. Уже лучше, но соотношение всё равно плохое. Даже один слабый прогер уровня миддла может уронить продуктивность команды из 3-5 сильных мидлов.
                                                                                                        Делаем третье собеседование. Наняли 14 слабых и 42 сильных. Ещё лучше, но большая часть сильных будет отсеяна.
                                                                                                        Делаем четвертое и разрешаем одно собеседование провалить. Получаем 900 * (0,25 ** 4 + 0,25 ** 3 * 0,75 * 4) = 45 слабых и 73 сильных.
                                                                                                        Много слабых. Добавляем пятое собеседование на ту же тему (одно можно завалить)
                                                                                                        Получаем 14 слабых и 63 сильных.

                                                                                                        Если сделать 6е, получим 4 слабых кандидата и 54 сильных.
                                                                                                        Примерно поэтому в Яндексе обычно 6 секций +- одного и того же. В Гугле аналогично.
                                                                                                        Нормально, что среди 942 отсеянных находятся те, кто пишет статьи на хабр о том, какие неадекваты в Яндексе. Согласно модели шанс, что это подходящий Яндексу прогер, процентов 5.
                                                                                                        Но по подходу автора (писать квадратичную асимптотику вместо линейной, потому что так привычнее) видно, что тут к Яндексу только один вопрос — зачем было тратить время кандидата и интервьюеров на секции после 2й-3й.
                                                                                                          0

                                                                                                          Вы меня поразили прям в мозг. Ну добавьте тогда в ваш зоопарк интервьюеров, которые выдают результат в зависимости от дня недели, и интервьюера, который убивает кандидатов с шансом 50%… В моём понимании интервьюер — это функция, которая принимает на вход знания кандидата и выдаёт 0 или 1. Если этот интервьюер выдаёт много FP или FN, значит это паршивый интервьюер и нафига он нужен. Если есть шанс ошибки, то поставьте 3-4 интервьюера рядом и пусть они исправляют друг друга. Добавьте ещё штуки 4 теста для быстрого вылета кандидатов, типа если напишут O(n^2) или если ник начинается с k, то сразу отлуп. Всё.


                                                                                                          Судя по тому, что я видел, Яндекс не парится и берёт пулл кандидатов, пулл сотрудников, и как на той картинке с игрушечными собачками скрещивает их. А ведь эту кучу часов, которые рекрутеры тратят на кандидатов, можно было потратить, чтобы — внезапно — улучшить рекрутеров самих и весь процесс в целом.


                                                                                                          Я как кандидат — в печали. Я хочу максимально быстрый ответ и, желательно, фидбек. Тут ни того, ни другого. Ну хоть посмеялись всем хабром.

                                                                                                            +3
                                                                                                            Да, Яндекс рандомно назначает кандидатам собеседующих из пула. Есть внутрянняя система фидбека, куда интервьюеры пишут, что спрашивали, что ответил кандидат и оценку. Другие интервьюеры (если секция не в тот же день), обычно проверяют, чтобы не спрашивать повторно те же задачи.
                                                                                                            Не очень понятно, как вместо того, чтобы собеседующие проводили по 6 секций с каждым кандидатом, пустить их время на улучшение процесса. Сажать по 6 человек на кандидата — не уменьшит времязатраты интервьюеров, но уменьшит точность за счёт меньшего числа вопросов.
                                                                                                            Есть ли примеры крупных IT-компаний (1000+ разработчиков, не бодишоп), где быстро собеседуют и быстро могут дать положительный фидбек?
                                                                                                            В гугле с момента подачи резюме до оффера проходит 3-6 месяцев. В Яндексе 1-2 месяца. Да, не неделя, как в небольших компаниях, но раз недостатка в кандидатах нет и акции растут, значит всё работает норм.
                                                                                                              +1
                                                                                                              раз недостатка в кандидатах нет

                                                                                                              спорное утверждение.
                                                                                                              Ко мне рекрутеры Яндекса обращаются с завидной регулярностью. Причем уже доходило до того, что мои данные «передавали» в КА/РА, которое работает на Яндекс.
                                                                                                              Ко многим знакомым — тоже.
                                                                                                              Да, не спорю, туда все еще многие мечтают попасть, но есть ли прямо очереди? Чё-т не уверен.
                                                                                                                +1
                                                                                                                Основной признак недостатка кандидатов — снижение планки найма.
                                                                                                                Активность HRов, это вполне предсказуемый процесс. Яндекс хочет нанимать самых подходящих специалистов на рынке. При этом сильный кандидат может и не подозревать, что его примут в Яндекс. Поэтому Яндексу в целом выгодно множество HRов, которые ходят по рынку и холодными звонками выцепляют людей на собеседования.
                                                                                                                И HRы эти далеко не всегда сотрудники Яндекса. В целом есть распространённая модель партнёрства, когда ты заключаешь с компанией договор о том, что она с каждого трудоустроенного от тебя кандидата платит тебе процент. А дальше ты сам себе хозяин и ищешь кандидатов где только можешь. В результате да, бывают эксцессы, а люди могут сокрушаться в комментариях, мол «мне написывал HR из яндекса, как же они задолбали», но это не признак недостатка желающих пройти собеседование.
                                                                                                                Мне, например, когда я работал в Яндексе, в Линкедине писали такие HRы предлагая прийти на собеседование в Яндекс. Бывает, что уж
                                                                                                    0
                                                                                                    Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива».

                                                                                                    Если инплейс то можете подсказать как? Потому что так-то ничего сильно лучше arr.Where(x => x != 0).ToArray() и не придумывается.


                                                                                                    Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).

                                                                                                    Можно тоже пример? По опыту в маленьких компаниях это отлично работает, не очень понятно что именно должно сломаться в случае большой. Или у вас в маленьких тоже не работает? Тогда тем более хотелось бы услышать ответ.

                                                                                                      +1
                                                                                                      Если инплейс то можете подсказать как?

                                                                                                      Примерно так:


                                                                                                      function remZero(arr) {
                                                                                                          var p = 0;
                                                                                                          for (var i = 0; i < arr.length; ++i) {
                                                                                                              if (arr[i] !== 0) {
                                                                                                                  arr[p++] = arr[i];
                                                                                                              }
                                                                                                          }
                                                                                                          arr.length = p;
                                                                                                      }
                                                                                                        0

                                                                                                        А ну да, логично, даже странно что я про это не подумал. Мне почму-то показалось что мы можем элементы местами менять и нарушить относительный порядок. Немного не в ту сторону подумал.


                                                                                                        В целом это и есть arr.Where(x => x != 0).ToArray() только копируем прям на месте вместо свободных нулей. Да, спасибо, тупанул чет

                                                                                                        0
                                                                                                        В отдельных маленьких организациях это работает лишь потому, что у каждой конкретной организации выборка маленькая =) В тех маленьких, которых был я — не сработало ни разу (т.е. все, кого наняли «по прошлому опыту» оказались буллшитерами). Но, правда, я там не принимал участие в собеседованиях, а только наблюдал.
                                                                                                          0

                                                                                                          По прошлому опыту это ведь не просто "наврите нам покрасивее" а вопросы по этому опыту. Почему сделали так, а не иначе. А вот зачем этот компонент. И так далее.


                                                                                                          Плюс можно гитхаб посмотреть если есть, если нет — то все же какую-нибудь задачку разминочную на 10 минут тоже можно. Это не дрючить 10 алгоритмическими задачками на 5 раундах собеседований, но какое-то видение дает. Вкупе с вопросами по арихектуре можно делать выводы.

                                                                                                            +5

                                                                                                            Уже сейчас есть в интернете куча платных и бесплатных курсов, задрачивающих людей решать задачи. Т.е. человек без опыта может научится решать задачки и пройти интервью.


                                                                                                            Если FAANG будет спрашивать массово про опыт и профиль на гитхабе, то будут курсы, которые будут учить людей складно рассказывать про "прошлый опыт" и объяснять по этому чужому профилю на гитхабе, почему сделали так, а не иначе.


                                                                                                            В текущей ситуации имеем людей, возможно вайтишников, которые научились решать алгоритмические задачи. Значит перекладывать json они точно смогут, ибо это проще. В гипотетической ситуации будем иметь кучу вайтишников, очень слабо программирующих, но складно говорящих.


                                                                                                            Вторая проблема: поговорить про опыт и посмотреть гитхаб — слишком субъективные оценки. Такое не годится для крупных компаний, которых пытаются засудить за дискриминацию, потому что интервьювер посмел спросить про размер байта в битах.


                                                                                                            А еще это на порядок сложнее для интервьюверов. Сходу вот так глядя на неизвестный вам проект понять, что вот такое решение было лучшим, невероятно сложно. Это потребует невероятно много времени подготовки у интервьювера. Когда как задачки можно спрашивать одни и те же, пока они не утекут в сеть.


                                                                                                            Вот и получается, что спрашивать задачки — единственно подходящее решение для интервью в FAANG/Яндексе. Оно скейлится, более менее объективно, просто в оценке, проверяет что-то вполне релевантное работе.

                                                                                                              +1
                                                                                                              Интересно, когда появятся курсы, которые учат работать.
                                                                                                                +1

                                                                                                                Они уже есть. Но научится работать же сложнее чем только научится скилам прохождения интервью. Люди ленивые и стремятся облегчить себе жизнь.

                                                                                                                  +1
                                                                                                                  «There is no compression algorithm for experience» by Andy Jassy
                                                                                                                    0
                                                                                                                    Научиться работать и не пройти интервью(или пройти на заниженную зарплату) — тоже такое себе
                                                                                                                    0
                                                                                                                    Если FAANG будет спрашивать массово про опыт и профиль на гитхабе, то будут курсы, которые будут учить людей складно рассказывать про "прошлый опыт" и объяснять по этому чужому профилю на гитхабе, почему сделали так, а не иначе.

                                                                                                                    Складно рассказать про прошлый опыт по-моему невозможно не прожив этот самый опыт. Шаг влево-вправо от "рассказывали на курсах" и провал. По крайней мере мне слабо представляется как можно составить решебник на все возможные вопросы.


                                                                                                                    Вторая проблема: поговорить про опыт и посмотреть гитхаб — слишком субъективные оценки. Такое не годится для крупных компаний, которых пытаются засудить за дискриминацию, потому что интервьювер посмел спросить про размер байта в битах.

                                                                                                                    Ну это да, но мне показалось выше сказали что и для маленьких такой способ не подходит.


                                                                                                                    А еще это на порядок сложнее для интервьюверов. Сходу вот так глядя на неизвестный вам проект понять, что вот такое решение было лучшим, невероятно сложно. Это потребует невероятно много времени подготовки у интервьювера. Когда как задачки можно спрашивать одни и те же, пока они не утекут в сеть.

                                                                                                                    Так что сложного? Все непонятные места адресуются кандидату — по его ответам будет понятно, думал он про это или нет, какие варианты отбросил и т.п. Не надо додумывать — надо спрашивать (если конечно есть у кого), наверное одна из первых вещей которые я понял когда начал работать: быстрый фидбек с короткими циклами — залог успеха.


                                                                                                                    Вот и получается, что спрашивать задачки — единственно подходящее решение для интервью в FAANG/Яндексе. Оно скейлится, более менее объективно, просто в оценке, проверяет что-то вполне релевантное работе.

                                                                                                                    Ну задачки отбирают либо студентов которые недавно их проходили либо сверхмотивированных людей которые в свободное время прорешивают литкод чисто ради фаанга. Пробовал так сделать в прошлом году — после пары десятков задач задолбался и забил.


                                                                                                                    Я не предлагаю никаких альтернатив, просто рассматриваю минусы текущего подхода. Вполне вероятно это лучшее из худшего.

                                                                                                                      0
                                                                                                                      лучшее из худшего.

                                                                                                                      Тоже так считаю. Да, у студентов приемущество возникает и нужно тратить время на подготовку. Ужасный метод. Но лучшего, на мой взгляд, нет.

                                                                                                                        0
                                                                                                                        Ужасный метод. Но лучшего, на мой взгляд, нет.

                                                                                                                        Есть. Даёте задачу и для неё штуки 3-4 решения готовых, и пусть интервьюируемый посмотрит их и скажет какое лучше и почему. Меньше затрат времени на собеседование, и плюс не будет каких-то глупых ошибок из-за спешки, стресса, неудобства написания кода в блокноте, на бумажке, или на доске.
                                                                                                                          +1

                                                                                                                          Тут в соседнем треде мне другой товарищ доказывал, что эти алгоритмические интервью — ужасны, потому что их проходят легко "профессора" знающие наизусть О-большое всех-всех алгоритмов и умеющие доказывать заумные абстрактные утверждения, но вообще нисколько не умеющие писать код.


                                                                                                                          В отличии от текущих интервью, ваш вариант как раз подвержен такой проблеме.


                                                                                                                          Он никак не проверят, что кадидат может писать код. Он никак не проверят, что кандидат умеет решать задачи, а не выбирать из нескольких предложенных вариантов.

                                                                                                                            0
                                                                                                                            Подавляющее большинство обычных задач в наше время — это как раз необходимость «выбрать из нескольких предложенных вариантов». Уже много раз упоминалось, что «всё давно уже написано», если не в стандартных библиотеках, так на стековерфлоу, нужно просто посмотреть где лучше и выбрать самый подходящий вариант.
                                                                                                                              0

                                                                                                                              Нет. Вам не даны несколько вариантов. В реальной жизни у вас есть только задача. Вам надо эти варианты еще найти. Как понять, что вот этот вот ответ на стекоферфлоу — хороший? Надо ли искать дальше? Или подобно задаче о привередливой невесте, ищем 4 ответа и берем лучший, надеясь, что среди этих 4-х есть нужный?


                                                                                                                              Теперь про стандартные библиотеки: 99% всего что вы делаете — нет в библиотеках! Вы можете прикрутить стандартную структуру данных, или найти какой-то фреймворк, который надо как-то потыкать, и часть вашей задачи будет решена. Но практически все, что вы делаете — это решение одной частной ВАШЕЙ задачи. Магической функции "сделать хорошо" нет ни в одной библиотеке.


                                                                                                                              Это нормально понимать, что вам тут нужно сбалансированное дерево поиска, и взять готовую реализацию из библиотеки. Но если вы не знаете, что вам тут нужно именно дерево, то что вообще искать?

                                                                                                                            0
                                                                                                                            пусть интервьюируемый посмотрит их и скажет какое лучше и почему

                                                                                                                            Этим вы проверите лишь умение кандидата анализировать, а проверять надо как анализ, так и синтез. Из первого умения никак не следует второе.
                                                                                                                          +1
                                                                                                                          Кстати да — это ОЧЕНЬ видно хорошо, когда человек сам делал (и шел доблестно по граблям набивая все свои шишки) и когда рядом стоял или «ключи подавал» в лучшем случае.

                                                                                                                          Поэтому мой совет соискателям — не делайте так.
                                                                                                          +17
                                                                                                          «Ну ок, хотят проверить знание каких-то базовых вещей»
                                                                                                            +1
                                                                                                            По-моему, родился новый мем на хабре(=
                                                                                                          +9
                                                                                                          Такие задачи хороши когда нанимаешь студента без опыта с которым больше поговорить не о чем, ну или алгоритмиста.
                                                                                                            +12
                                                                                                            ну или алгоритмиста.

                                                                                                            Ну нет смысла нанимать выделенного алгоритмиста. Весь абсолютно программный код по определению — алгоритмы. Большая часть — тривиальные, типа пройтись по списку и выбрать минимум или сложить 2 числа.


                                                                                                            Без знания о том, какие бывают алгоритмы, без умения решать задачи и алгоритмического мышления часто сложно даже понять, что вот эта задача — она решается тупо (прошлись по списку и выбрали минимум), а вот та — совсем нет.


                                                                                                            Потому что почти всегда есть простой, понятный и очень не эффективный наивный метод.
                                                                                                            Потому что эта самая алгоритмическая задача ничем принципиально не отличается от всех других задач, которые программисты постоянно решают.


                                                                                                            В итоге получается, что выделенный алгоритмист должен ревьювить вообще весь код в компании. С потоком кандидатов FAANG/Яндекса эффективнее, дешевле и удобнее сразу нанимать только "алгоритмистов".


                                                                                                            с которым больше поговорить

                                                                                                            С "поговорить" большая проблема — это очень субъективно. Мелкой компании, где условный CTO сам проводит интервью и решает: кого брать, кого нет — это работает. В крупной типа яндекса и FAANG — уже нет. Плюс, если язык хорошо подвешен, можно тупо заболтать интервьюера в процессе этого "поговорить".

                                                                                                              0
                                                                                                              Нет, выделенный алгоритмист должен вместе с архитекторами решать как будет работать самые высоконагруженные компоненты.
                                                                                                              А почти всегда есть не очень простой, понятный и очень эффективный наивный метод — правильно применить готовую библиотеку/фреймворк.
                                                                                                              Плюс, если язык хорошо подвешен, можно тупо заболтать интервьюера в процессе этого «поговорить».
                                                                                                              Без знаний особо не заболтаешь, если человек подходит ответственно к интервью: можно же спросить технические детали/особенности, да и github человека можно посмотреть.
                                                                                                                +1
                                                                                                                Нет, выделенный алгоритмист должен вместе с архитекторами решать как будет работать самые высоконагруженные компоненты.

                                                                                                                А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.

                                                                                                                Внезапно — маркетинг провел рекламную компанию и пришли люди. Эти люди прочитали какую-то статью и пользуются системой не так как ожидали разработчики.
                                                                                                                  –1

                                                                                                                  Ну уронит и уронит. Кто-то не сможет дошик себе через лавку заказать в моменте или реклама не прогрузится. Ой кошмар какой

                                                                                                                    +4

                                                                                                                    Или у пользователей по всему миру отвалиться условный ютуб на пару часов, потому что упал какой-то служебный сервис из-за возросшей внезапно нагрузки. Или несколько часов не будет показываться вся реклама от яндекса. Огромная денежная потеря.

                                                                                                                      –4

                                                                                                                      Отвечу словами здесь https://youtu.be/NwEuRO_w8HE?t=2180 (там всего на 40 секунд вопрос и ответ). Если вас парит о-сложность до того, как вы запустили код, прогнали бенчмарки и обозначили SLA пользователям, вы занимаетесь преждевременной оптимизацией. В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит. Не мучайте фронта булщитом про пузырьковую сортировку, пусть об этом парятся люди, которые контрибьютят в ядро линукса или пишут низкоуровневые системные библиотеки.

                                                                                                                        +6

                                                                                                                        А как проверить, что человек сможет исправить найденную после запуска плохую часть?


                                                                                                                        В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит.

                                                                                                                        А потом такие "вот сайт тормозит, пользоваться невозможно!!!". Или у людей игра грузится по 10 минут на пустом месте. При чем там наверняка такая же мысль была: Ну насрать, что там в чтении одного мелкого конфига O(n^2), клиент все стерпит. А потом n, внезапно, выросло и все стало плохо.

                                                                                                                          0
                                                                                                                          А потом такие "вот сайт тормозит, пользоваться невозможно!!!". Или у людей игра грузится по 10 минут на пустом месте. При чем там наверняка такая же мысль была: Ну насрать, что там в чтении одного мелкого конфига O(n^2), клиент все стерпит. А потом n, внезапно, выросло и все стало плохо.

                                                                                                                          Нет, "потом" такого не будет. Вы просто взяли и пропустили фразы про бенчмарки, SLA и так далее. Если в SLA не было оговорено условное время загрузки сайта, то что там оговорено было вообще?


                                                                                                                          Просто обычно программный код имеет столько внутренних нюансов, что замена алгоритма с O(n^2) на более оптимальный может замедлить скорость работы, если это делать в слепую.


                                                                                                                          Вы игнорируете константу, вы игнорируете наиболее полулярные N и так далее.


                                                                                                                          Что лучше, что бы у большинства пользователей корзина покупок грузилось секунду, а у кого-то 5 или что бы у всех грузилась по 3 секунды?

                                                                                                                            +4

                                                                                                                            Только и константы там одинаковые.


                                                                                                                            Обычно сделать более быстрый (асимптотически) код ничего не стоит. Классический пример который вижу в дотнете: foos.OrderBy(x => x.Something).First().Bar. Если это на старте приложения 1 раз делается или там в какой-нибудь режкой ручке — то как бы и плевать. А когда элементов достаточно много да и код выполняется довольно часто — то как бы не очень.


                                                                                                                            При том что решение — загуглить за 5 секунд любую из библиотек-расширений LINQ (либо написать свой хелпер за 5 секунд), и заменить это на foos.MinBy(x=>x.Something).Bar — почти те же буквы и те же константы, только уже за линию.

                                                                                                                              0
                                                                                                                              Только и константы там одинаковые.

                                                                                                                              Зависит от контекста. Всегда люблю приводить в пример перемножение матриц)


                                                                                                                              Обычно сделать более быстрый (асимптотически) код ничего не стоит.

                                                                                                                              Зависит от контекста. В вашем примере — не стоит. В каком-то случае это ухудшение читаемости и поддерживаемости кода. В каком-то случае это написание своего более оптимального велосипеда, который потом надо поддерживать.


                                                                                                                              Я не спорю, что в каких-то случаях вы просто улучшаете точность и все работает, но это явно не 100% и, скорее всего, даже не 50% случаев.

                                                                                                                                +4

                                                                                                                                Я это к тому говорю, что плохое решение от хорошего часто отличается не тем что на хорошее нет времени поэтому давайте быстро закостылим, а тем что человек просто не знал, что можно по-другому, а заимплементить что нормально, что костыльно получается одинаково по ресурсам.

                                                                                                                              +1
                                                                                                                              Обычно небольшие куски кода с медленными алгоритмами размазываются по всему программному комплексу тонким слоем. Тут линейный поиск, вместо хеш-таблицы, там ненужный вложенный цикл, увеличивающий сложность до О^2. И после некоторого количества итераций, всё просто начинает медленно работать без каких-то явных ботлнеков. И тут, зачастую, остаётся только всё переписать с нуля.
                                                                                                                                0

                                                                                                                                Сколько не работал с кодом, обычно существует одно место, которое тормозит больше всего, и это место отвечает за какую-то io работу в духе "сходи забери из базы что-то с кривым запросом". Переписываешь запрос и все работает :)


                                                                                                                                Даже во всяких cpu-bound задачах довольно часто спасает кеширование или исправление конкретного места.

                                                                                                                                  +4
                                                                                                                                  «1. существует одно место, которое тормозит больше всего
                                                                                                                                  2. Переписываешь запрос и все работает
                                                                                                                                  3. goto 1»
                                                                                                                                  Так лучше.
                                                                                                                                0

                                                                                                                                Буквально на днях столкнулся с "возросшей нагрузкой" — есть корпоративный портальчик, ничего супер-пупер нагруженного, состряпали, запустили, пользуемся… через пару лет начинаются жалобы — тормозит. Автор портальчика к тому моменту уже потерялся, полез смотреть сам (я не программист) — оказывается, при каждом действии, ajax шерстит историю сообщений, чтобы в случае чего новенького отрисовать "колокольчик", а сообщений накопилось уже немало, а в алгоритме почему-то был линейный перебор с "ручным" анализом "новое/прочитанное" (таблица ID прочитанных сообщений была у каждого пользователя своя, а таблицы сообщений шли сплошной простынёй)… казалось бы — сделай запрос к базе по JOIN с "объединением по NULL", чтобы отобрать только непрочитанные, но автор решил несколько иначе — выбирал все сообщения, а потом искал их ID в "личной" таблице, и если не находил — высвечивал оповещение.
                                                                                                                                Вроде рабочий алгоритм, но вот с масштабированием совсем боль.

                                                                                                                                  0

                                                                                                                                  Ну так тут же дело не в каких-то неправильных алгоритмах, а в нарушение принципов работы с БД, что все выборки и расчеты максимально должны выносится в БД.

                                                                                                                                    0
                                                                                                                                    Так, стоп! Это кто там такие принципы напридумывал? Те же самые люди, которые придумали триггеры и хранимые процедуры? Ок, у меня к ним есть только одно пожелание, и оно связано с адом и огнём.
                                                                                                                                    Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
                                                                                                                                    Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)
                                                                                                                                      0

                                                                                                                                      Ну так это ровно то же, что вы пишите. Выборка данных + расчет производных данных на их основе (преобразование функциями, сумма, вот этот весь треш).


                                                                                                                                      Если вы фильтруете или преобразовываете данные потом на бекенде, то тут что-то немного не так. Иногда это ваша вина, иногда бд.

                                                                                                                                        0
                                                                                                                                        … иногда даже вина человека, который занимался выбором БД. Просто потому что колоночные БД и, например, теперь уже бесплатный кликхауз, это могут делать на порядки быстрее.
                                                                                                                                        Но, в целом, мы приходим к изначальному вопросу статьи.
                                                                                                                                        Для того, чтобы выбрать Clickhouse для решения определённого набора задач, надо знать и про Clickhouse, и про то, на каких наборах задач он будет в сотни раз быстрее других СУБД…
                                                                                                                                        И, да, в общем случае, я фиг знает, как вообще можно такие вопросы гарантированно решать за 2-3-4 часа одного собеседования. Но в Яндекс с 10ю собеседованиями и ставкой ниже рынка не пойду. Ну разве что совсем от голода помирать придётся…
                                                                                                                              +5
                                                                                                                              Потом заходишь такой в интернет-магазин (мобайл-фёрст), открываешь с мобилы список товаров, он тупит, но через минуту всё-таки подгружает всё что нужно, и наконец нажимаешь «отсортировать по ...» и обычный обывательский мобильник на snapdragon 4хх (6хх) вешается. Без шанса на спасение.
                                                                                                                                0

                                                                                                                                Я на самом деле очень люблю оптимизировать. Я несколько лет работал научным сотрудником в сфере, где широко использовалась wolfram mathematica. Я очень заморачивался над вещами типа сведения интеграла к сумме по элементам массива, над вставками на C, которые работали быстрее, итд. Но я это делал уже сильно после того, как написал первый прототип программы, который работал нормально, а потом захотелось больше отзывчивого UI. Я не считаю, что рядового кодера в стрессовых условиях собеса нужно мучать на оптимальные алгоритмы. Для этого давно есть библиотеки и только в редких случаях возникнет реально проблемный боттлнек, где придётся оптимизировать код. Если такое случится — ну, ок, сядет разраб и в спокойной обстановке поищет, в чём там проблема.

                                                                                                                                  +2
                                                                                                                                  Почему сразу не думать в категориях нормального кода? Второй раз может и не захотеться переписывать, жалко времени, кончились деньги и т.д.
                                                                                                                                  Типа, сначала строим дом, потом смотрим, что получилось неплохо, но нужно сделать канализацию, затем снова поднимаем краном и прокладываем водопровод. Разматываем электрические провода вокруг дома, снимаем обои и начинаем штробить стены.
                                                                                                                                    +1
                                                                                                                                    Говорят, code is clay, имея в виду, что код обычно не надо переделывать заново, как какую-нибудь шестеренку, если в процессе изготовления допущена ошибка. Чаще всего изменение обходится малой кровью.
                                                                                                                                      0
                                                                                                                                      Так и в исправлении неправильного ремонта ничего «слоного» нет. Проштробил стену, потом обратно замазал.
                                                                                                                                      +3

                                                                                                                                      При строитенльстве домов теже проблемы, только в меньшем масштабе. Возьмите типичную квартиру и посмотрите как расположены там розетки, используются ли вские тройники и удлинители. А ведь это все можно было решить на этапе ремонта. Вот только для этого нужно точно знать где какая мебель будет стоять, какие у неё будут размеры, какие электроприборы и где будут стоять и использоваться. Точно это предугадать невозможно, поэтому и возникают все эти удлинители или абсурдно огромные группы розеток "на всякий случай".


                                                                                                                                      Так же и в разработке софта. Мы зачастую не знаем сколько у нас будет пользователей конкретной фичи, не знаем какие фичи будут добавлены завтра, а какие убраны. Мы даже не знаем кто будет завтра с этим кодом работать. То что мы знаем точно — так это то что проект точно будет меняться или умрет. Но что именно будет меняться — можно лишь гадать. И правильно угадывать мы будем далеко не всегда. Поэтому намного выгоднее писать код таким, чтобы его было легко менять в будущем, пытаться предсказать что может поменяться, а что нет. А еще, чтобы его могли понять другие разработчики, желательно без необходимости вникания во всю историю проекта. Хороше же оптимизированный код зачастую сложно читать, сложно расширять. В итоге приходится балансировать между расширяемостью, читаемостью и оптимизацией. Хороший разработчик — не тот кто упарывается в одну из этих крайностей, а тот, кто умеет находить баланс в каждом конкретном случае. Когда надо — писать хорошо оптимизированный write only код, а когда надо — медленный, но легкочитаемый и/или легкомодифицируемый, а в большинсте случаев — что-то среднее.

                                                                                                                                        0
                                                                                                                                        Хороше же оптимизированный код зачастую сложно читать, сложно расширять.

                                                                                                                                        Это только если упарываться микрооптимизациями. Если просто использовать нормальный алгоритм или структуру данных — то код часто даже проще и понятнее. Что легче — полный перебор через рекурсивную функцию с откатами и неочевидными отсечениями, или динамическое программирование, которое все — 2 вложенных цикла и тривиальная формула для пересчета одной ячейки массива через соседние?

                                                                                                                                          +1

                                                                                                                                          Осталось только найти границу где "просто использовать нормальный алгоритм или структуру данных" переходит в "упарываться микрооптимизациями".

                                                                                                                                          0
                                                                                                                                          Поэтому намного выгоднее писать код таким, чтобы его было легко менять в будущем,

                                                                                                                                          Спасибо, вы меня поняли. Заморочиться и написать fast inverse square root всегда можно потом.

                                                                                                                                            0
                                                                                                                                            Справедливости ради стоит заметить, что если подходить к ремонту серьезно, то уже после второго ремонта (в смысле, при планировании третьего) не будет ни лишних розеток, ни удлинителей. Это если себе делать.
                                                                                                                                            Если же Вы прораб и делаете ремонт «другим», то тут грубо говоря два варианта: 1) прораб м###к не является профессионалом и без комментариев и продолжений выполняет требования по количеству розеток заказчика; 2) даже небольшого жизненного опыта достаточно, чтобы вовремя спросить «а робот-пылесос где парковаться будет?»/«а в шкафу подсветки не будет что-ли?»/«думаете на вашу столешницу больше двух электроприборов за раз поместиться?»/«ну это новая зубная щетка заряд держит, а потом как вы ещё заряжать будете, когда тут бритва на зарядке и фен нужен?»

                                                                                                                                            Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…
                                                                                                                                              0
                                                                                                                                              Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…

                                                                                                                                              это вы как выяснили?
                                                                                                                                          0
                                                                                                                                          Опыт показывает, что нет ничего более постоянного, чем временное.
                                                                                                                                          Рефакторинг отнимает кучу ресурсов, больше, чем было бы потрачено на изначально грамотное проектирование. В конечном итоге рефакторинг откладывается до лучших времен, баги митигируются костылями, мейнтенанс и дев луп растут.
                                                                                                                                          +10
                                                                                                                                          заходишь такой в интернет-магазин… и обычный обывательский мобильник вешается.
                                                                                                                                          Зашёл я как-то на один технический новостной сайт с обычного пользовательского мобильника…
                                                                                                                                          Впрочем, ходят слухи, что уже ведётся работа над новым движком для комментариев, и к осени он будет готов. К какой осени — источник умалчивает.
                                                                                                                                            0
                                                                                                                                            Что там телефон — у меня ноут еле тянет.
                                                                                                                                              0
                                                                                                                                              Это вы так лихо Хабр новостным ресурсом обозвали или я чёт не понял?
                                                                                                                                                +1

                                                                                                                                                С возможностью комментирования и элементами социальной сети)

                                                                                                                                                  +3
                                                                                                                                                  Можно подумать это не так. Нормальных технических статей практически нет.
                                                                                                                                              +3
                                                                                                                                              В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит. Не мучайте фронта булщитом про пузырьковую сортировку

                                                                                                                                              Браузер стерпит. Пользователь может и не стерпеть.

                                                                                                                                            +12
                                                                                                                                            Не смог удержаться...
                                                                                                                                            image
                                                                                                                                              0
                                                                                                                                              Или все такси в России на час перестанет работать. Остальные нагрузку не тянут, и ложатся под ней.
                                                                                                                                                +2

                                                                                                                                                И как такси без Яндекса работало сотни лет? Пришел случайный Джун, отсортировал массив пузырьком и нагнул отрасль, ну да

                                                                                                                                                  +2
                                                                                                                                                  И как люди без интернета сотни лет жили?
                                                                                                                                                  И как люди без электричества сотни лет жили?

                                                                                                                                                  Раньше работало, плохо но работало. Сейчас если Яндекс падает такси в России перестает работать. Надо теперь с этим жить.
                                                                                                                                                    0

                                                                                                                                                    А конкуренты куда делись?

                                                                                                                                                      0
                                                                                                                                                      Нагрузку не тянут.
                                                                                                                                                      В прошлом году полдня Яндекс такси лежало, все конкуренты легли под нагрузкой сразу же.

                                                                                                                                                      https://habr.com/ru/news/t/487130
                                                                                                                                                +2
                                                                                                                                                При этом сервисы Яндекса и так регулярно падают. В Яндекс.коннект или в метрике или в Яндекс Недвижимости регулярно натыкаюсь на «ваш запрос не может быть выполнен», на несохранение каких-либо действий или просто на неверную выдачу.
                                                                                                                                                0

                                                                                                                                                И как вам тут алгоритмы помогут? Отказоустойчивость проверяется нагрузочным тестированием. Даже идеальный алгоритм захлебнётся, если элементарно не хватит нужных ресурсов.

                                                                                                                                                  0
                                                                                                                                                  Никто не гоняет нагрузочне тестирование по всем апишкам после каждого релиза.
                                                                                                                                                  Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.

                                                                                                                                                  Критический путь можно так проверять. И иногда проверяют. Но это даже близко не все методы.
                                                                                                                                                    0
                                                                                                                                                    Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.

                                                                                                                                                    Не согласен с вами.
                                                                                                                                                    Мы поддерживали целый стенд для людей, занимающихся автоматизацией нагрузочного тестирования. Биллинг.
                                                                                                                                                    0
                                                                                                                                                    Нагрузочное тестирование — чрезвычайно нетривиальная вещь, особенно для stateful сервиса. В больших компаниях за этим стоят отдельные сервисы со своими командами. И то даже в Яндексе и FAANG'е это далеко не для любого сервиса отлажено хорошо. Не панацея, в общем.
                                                                                                                                                    0
                                                                                                                                                    упадёт потому что NPE, и тут никакой алгоритмист не поможет ))
                                                                                                                                                      –1

                                                                                                                                                      А вы не пишите на языках с null-ами

                                                                                                                                                      +7
                                                                                                                                                      А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.
                                                                                                                                                      Я ведь верно понимаю, что любой алгоритмист, при устройстве на работу, гарантирует своему работодателю некий аналог sla с несколькими девятками, и полной компенсацией в случае падения прода? Или алгоритмисты только говорить могут, а на деле роняют прод примерно так же часто, как и обычные инженеры?
                                                                                                                                                        0
                                                                                                                                                        А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.

                                                                                                                                                        Если он сделан прям «так жутко», то он просто код ревью не пройдет.
                                                                                                                                                          0
                                                                                                                                                          Хочется верить.
                                                                                                                                                          Всегда есть вероятность что какой-то код написали в тестах. А кто же внимательно ревьюит тесты?
                                                                                                                                                          Потом этот же код скопировали в метод нужный в админке. Кто же внимательно ревьют скопированный код на который не будет нагрузки и пользователи все свои?
                                                                                                                                                          А потом его вызвали из любого пользовательского метода на который не должно быть нагрузки. Кто же внимательно ревьют не тот код что написан только что, а какой-то там метод? Тем более нагрузки же нет.

                                                                                                                                                          А потом пришла нагрузка. И все легло. И никто не виноват.
                                                                                                                                                      –1
                                                                                                                                                      Ну нет смысла нанимать выделенного алгоритмиста. Весь абсолютно программный код по определению — алгоритмы. Большая часть — тривиальные, типа пройтись по списку и выбрать минимум или сложить 2 числа.

                                                                                                                                                      Под "алгоритмистами" чаще всего понимают рисерч-инженеров… давайте расскажите, как компаниям не нужен R&D и все можно порешать на уровне понимания "сейчас пройдемся по списку и сложим два числа"...

                                                                                                                                                        +1

                                                                                                                                                        Судя по контексту ("алгоритмические" задачки на интервью) тут под "алгоритмистами" вполне себе подразумеваются обычные программисты, которые умеют в структуры данных, О-большое и всякие алгоритмы.

                                                                                                                                                          –1

                                                                                                                                                          Будто бы база для алгоритмиста чем-то отличается. Вопрос в глубине экспертизы и решаемых задачах.

                                                                                                                                                      0
                                                                                                                                                      ну или алгоритмиста

                                                                                                                                                      Выделенный алгоритмист не нужен.
                                                                                                                                                      У нас был проект, где были выделенные аналитики для увеличения производительности (прям такие математики-предметники). Которые в код реально не лазили.

                                                                                                                                                      В итоге (у них было достаточно «веса» чтобы настоять на включении доп.оптимизаций) схема разработки превращалась в старый анекдот про филина и мышей: «я вам решение сказал, а как вы будете это делать — это уже технические (не волнующие меня) детали».
                                                                                                                                                    +35

                                                                                                                                                    Яндекс, суть копия западных компаний типа Гугла, и в собеседованиях решил не напрягаться и просто копировать литкодовые бесполезные задачки, которые упорно задают в западных компаниях

                                                                                                                                                      +8
                                                                                                                                                      В смысле копия? Это вы так резко опустили всех разработчиков FAANG?
                                                                                                                                                      Если же вы имеете в виду, что копия в плане собеседований, то флаг им в руки. Зачем нужно проходить это все в Яндекс, когда можно то же самое все пройти в любую из FAANG?
                                                                                                                                                        +4
                                                                                                                                                        А зачем, например, уежать работать за границу, когда можно не уежать? А зачем вообще что-то делать, когда можно не делать? Таким вопросом можно много чего обесценить.
                                                                                                                                                        Все люди разные. Кто-то захочет в Я. работать, кто-то в FAANG захочет. Статьи «какие в Я. глупые алгоритмические собеседования» пишутся время от времени, но даже сейчас, конкретно в этой статье, в опроснике есть люди, которые всё равно выбрали бы Я.
                                                                                                                                                          0

                                                                                                                                                          А что не так? В Яндексе нет настолько умных людей как в FAANG? Или они не делают нормальные сервисы?

                                                                                                                                                            +14
                                                                                                                                                            В Яндексе нет настолько умных людей как в FAANG?
                                                                                                                                                            Вполне вероятно, что в FAANG средний уровень выше банально за счёт того, что и конкуренция, и ареал поиска кандидатов куда больше.

                                                                                                                                                            Или они не делают нормальные сервисы?
                                                                                                                                                            Ну, не знаю, огромная доля сервисов Яндекса со стороны кажется банальным симптомом болезни «а во. такая штука появилась на рынке, значит, надо делать свой клон». Редкое исключение — божественный Яндекс.Маркет, но и его загаживают последнее время жутчайше.
                                                                                                                                                              +6
                                                                                                                                                              Редкое исключение — божественный Яндекс.Маркет, но и его загаживают последнее время жутчайше.
                                                                                                                                                              Его уже несколько лет убивают, по другому описать не могу.
                                                                                                                                                                +1

                                                                                                                                                                А ведь какая стюардесса была...

                                                                                                                                                                  +1
                                                                                                                                                                  сейчас активнее екаталог использую
                                                                                                                                                                  после того, как отменили возможность негативных отзывов на поведение контор из избранного списка — вообще смысла искать на маркете стало минимум.
                                                                                                                                                                  а до этого уже даже мейлру выдавал в поиске лучшие варианты для покупки отдельных вещей, чем яндекс.поиск и уж тем более маркет.

                                                                                                                                                                  Вот здесь столько спецов из яндекса рассказывают про крутые алгоритмы, и ведь никто не ответит, почему на жалобу, что в яндексе галочка «искать как в запросе» банально ничего не делала и выдача оставалась такой же, решение было принято по удалению данной галочки.
                                                                                                                                                                  Ну, так сказать, вот они — крутые олимпиадники в действии
                                                                                                                                                                    0
                                                                                                                                                                    негативных отзывов на поведение контор из избранного списка

                                                                                                                                                                    Чего чего сделали?

                                                                                                                                                                    Вот здесь столько спецов из яндекса рассказывают про крутые алгоритмы, и ведь никто не ответит, почему на жалобу, что в яндексе галочка «искать как в запросе» банально ничего не делала и выдача оставалась такой же, решение было принято по удалению данной галочки.
                                                                                                                                                                    Ну, так сказать, вот они — крутые олимпиадники в действии…

                                                                                                                                                                    Ой это действительно боль, все еще пользуюсь яндексом по инерции, но заставить его найти именно то что я хотел а не то что он выдумал, это тот еще квест. Особенно весело, учитывая что я работаю с вещами по которым 1.5 статьи и из них одна на английском. Все чаще открываю гугл или утку.
                                                                                                                                                                      +2
                                                                                                                                                                      Чего чего сделали?
                                                                                                                                                                      Для тех, кто доставляет через яндекс (покупка на маркете) — отзыв сделать нельзя, только метрики яндекса как шустро те доставляют и сколько возвратов. Что гарантия будет хз где, а магазин будет всячески пытаться тебя обмануть — ты уже отписать не сможешь…
                                                                                                                                                                      Если контора отдельно оставила возможность покупать у неё миную яндекс, то там отзывы есть и много всяких в духе «кинули с заказом, отменив оплаченный», «ради гарантии пришлось переться в жопу мира несколько раз» и т.п.
                                                                                                                                                                      PS. И да, это я виноват. Наехал на яндекс за то, что их «проверенные поставщики» (то, что было ДО этого изменения) массово кидали перед нг народ, отменяя даже оплаченные заказы. Вот, олимпиадники в яндексе решили проблему — нет отзывов, нет возможности доказать, что их проверенные поставщики так делают
                                                                                                                                                                        0
                                                                                                                                                                        Вот это жесть и как интересно можно было додуматься до такого.

                                                                                                                                                                        Но справедливости ради это не вина олимпиадников, это вина их начальников. У меня вообще складывается ощущение, что я последний адекватный руководитель на планете, ну что за треш то кругом а.
                                                                                                                                                                          +1
                                                                                                                                                                          Вот как это выглядит