Привет, хабр!
В прошлой статье меня знатно разбомбили в комментариях, где-то за дело, где-то я считаю, что нет. Так или иначе, я выжил, и у меня есть чем с вами поделиться >:)
Напомню, что в той статье я рассказывал, каким я вижу идеальное собеседование и что я нашёл компанию, которая так и делает - и я туда прошёл, хотя это был адский отбор. Я, довольный как слон, везде отметил, что я не ищу работу, отовсюду удалился и стал работать работу.
Как вы думаете, что делают рекрутеры, когда видят "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 часа алгоритмов? Что это показывет - что я устойчив к тупости? Честно говоря, я уже не уверен.
Может кому-то пригодится разбор задачек, ну вдруг вы любитель такого, хотя я уже говорил о качестве решений :)
А если вам нужен вывод, то вот несколько, берите любой:
Тестировать кандидатов нужно на реальных задачах, а не синтетических
Нужно уважать время кандидатов
Кто-то в яндексе пересмотрел "день сурка"
Знаете, когда целое не равно сумме частей? Вот тут так же: люди тебя собеседуют хорошие и встречи приятные, а в целом всё гавно.
Открыто новое достижение: ругательство "да пошёл ты в яндекс!"
Большие компании ай-яй-яй
Какой-то чувак написал смешную статью
И да, если вы ищете работу на питоне - залетайте к нам. У нас не Яндекс.
Inlore
Стиль изложения — огонь. Жду продолжения истории
Слышал шутку, что яндекс вообще на любую позицию по алгоритмам гоняет
orthoxerox
Бедные курьеры...
lastrix
Не курьеры, а коммивояжеры.
LoadRunner
И решали задачу о рюкзаке?
plus
Это та же задача, что и о коммивояжерах
WASD1
Коммивояжёр решает рюкзак, наоборот нет.
Авторитетно, как яндекс-курьер получивший оффер, заявляю.
ПС
: sarcasm:
haqreu
Я не настоящий сварщик, я маску нашёл, но насколько я понимаю, под словами "задача коммивояжёра" и "задача о рюкзаке" могут подразумеваться несколько разные вещи, в том числе NP-полные задачи, так что сведение одной к другой неочевидно в таком простом заявлении, как ваше :)
WASD1
вы слишком многого хотите от курьера яндекс-яды.
Но если брать формулировку по «knapsack problem» и «travelling salesman problem» в английской вики — то я не вижу как решение второго свести к решению первого (без многократного повторения или увеличения размерности задачи).
haqreu
Лично я дипломированный трубочист (серьёзно), так что давайте поговорим :)
Руку на отсечение не дам, но вроде бы, в обоих случаях задачи разрешимости NP-полны, и не всегда ясно, когда говорят просто про рюкзак (коммивояжёра), имеются ли в виду оптимизационные задачи или речь про разрешимость.
PsyHaSTe
Насколько я вижу по вики (да и всегда думал) — задачи имеют разное название потому что это разные задачи. Там где задачи явно сводятся к другим обычно это пишут, например тут
Если не пишут значится что не сводится одно к другому
masai
Если вы чистите трубы только тем, кто не может прочистить их сам, у меня к вам есть один вопрос. :)
haqreu
Ну вообще я только свой дымоход чищу, но давайте вопрос!
masai
Вопрос как раз и был о том, чистите ли вы свой дымоход. :)
Раз уж мы тут про профессии и теоретическую информатику говорим, грех было не вспомнить парадокс Рассела.
haqreu
Мне диплом был нужен только для того, чтобы страховка не придиралась к тому, что я не вызываю два раза в год дипломированного специалиста. А так я сам себе Буратино :)
Но действительно, Рассела не узнал, богатым будет.
x67
Ветка огонь. Теперь финальная задача. Обойдите все дерево комментов не заржав ни разу) Стандартной библиотекой пользоваться нельзя)
Anei
Я срезался на вашем комменте.
GrogeM
Сколько теннисных мячей поместится в сумку
titsi
а сколько это будет в виде гитар?
dragonnur
Питерская контора яндекса должна помещать в сумки тело.
vidyakinsergey
… найти минимальное количество распилов, чтобы уместить тело в заданном объеме…
sumanai
С учётом тяжести пиления или без?
ainu
Учитывайте, но сторонние библиотеки нельзя.
starosta6123
Они ее распараллеливают, отправляют сразу 100500 курьеров одновременно, кто-то да дойдет.
Stas911
Доставка еды по UDP? Приезжает отдельно колбаса, потом сыр и только к утру сам блин, а коробка где-то теряется
fominslava
Вы только что Wildberries описали :)
saver
В голос, спасибо! :)
dewil
Они думают, что так и будут по алгоритмам бегать, а после приема на работу приходится бегать по городу.
IIIyT
Это не шутка, ну или почти не шутка. Давно проходил собеседование на позицию Project-manager — первым вопросом было: «Какие алгоритмы сортировки вы знаете?»
Через много лет, когда стал Solution Architect, также было интервью по этой позиции, и угадайте каким был первый вопрос?:)
ehots
Да я и второй угадаю: «А можно быстрее?».
pae174
> Какие алгоритмы сортировки вы знаете?
Не, ну это ещё можно вытерпить. Хуже, когда хрюша идёт по опроснику и спрашивает «Какой алгоритм сортировки лучший?».
mapron
А для вас это очевидный вопрос? я бы если честно замешкался, т.к. нет никакого лучшего алгоритма. А что подразумевается-то?
doctorw
Вот именно!
Viceroyalty
Вопрос-то с подвохом: если назовете хоть один — пиши пропало.
Alexandroppolus
"Каждое ваше слово может быть использовано против вас"
Am0ralist
— что арифмометр?
— используйте против меня арифмометр
ksr123
В оригинале была голая баба :)
AleFFlex
задать вопрос «а вы по какой книжке опрос составляли?» 8)))))
panteleymonov
Так и есть, гоняют будь здоров, всегда. До 12 собеседований по алгоритмам доходит, а то и больше. И статья, про яндекс беспредел, уже далеко не первая и не последняя, но они имеют тенденцию удаляться. Люди на таком собеседовании разные попадаются, одни тебя пропустят, другие завалят на одних и тех же задачах. Ладно бы это было только в онлайне, а то и приехать просят, а это уже 4 часа только на одно такое собеседование.
Filatto
И ради чего?.. свет клином же не сошелся на Яндексе… Уж лучше какой-нить европейский стартап.
Ogoun
Ради того чтобы сказать, решаете вроде правильно, но как то медленно, и вообще мы Яндекс, вот вам на 100 тысяч меньше обещанной ЗП, выходите на работу и гордитесь что мы вас взяли. (из личного опыта)
Furriest
«Работать в нашем банке — большая честь» (С)
xom9lk
При всех минусах такого найма, там работают отличные разработчики. Так что могут себе позволить. Желающих много. Да и найм у них в основном с вузов, где живут олимпиадными задачками.
panteleymonov
Это плохая тенденция — считая себя великим, позволять себе «неадекватность». И потом, отличные разработчики работают практически везде, даже дворниками. Тем более что желающих много, каждого так собеседовать по 6-12 часов — это как то жирно, больше похоже на практику для уже работающих. А уж олимпиадными задачами не кормиться только ленивый, они в открытом доступе и даже нашему коллективу филиала из «откуда-то» удалось попасть в полуфинал мирового чемпионата. И все же, больше вопросов возникает к отдельным личностям, а не к общему маразму.
numb
К сожалению, это не шутка…
Shinbolat
И ЗП меньше среднего, прям как в Яндекс доставке!
jkotkot
Ну кстати неизвестно. до ковидлы ходил к ним на тех.манагера собеседоваться. на входе просил немного больше среднего по рынку (хотя хз может оно срденее или ниже, а я не знал)), но они не отказались общаться
Fandorin
Работал в Яндексе техническим менеджером, в итоге предложили зп сильно ниже того, что озвучивал. Но я уже прошел все собеседования, потратил кучу времени и в итоге решил рискнуть) Через год уволился)
jkotkot
Я не дошел до конца) После третей собеседки отказали (у меня последний опыт хреланса/удаленки, а это для них, как выяснилось, зашквар).
dkameleon
видимо, в этом и цель многодневных собеседований.
это как тест на 500 вопросов, в конце которого надов вести номер карты, чтоб узнать, какой вы олень.
dmbreaker
А они так и делают всегда, но в конце будет меньше всё-равно.
Ohar
Это не шутка
nonname
Собеседовался пару раз на девопса в Яндекс, первый раз года 3-4 назад, поговорили даже нормально половину интервью, потом дрочево алгоритмов, второй раз года полтора назад, всё проходило 1в1 как тут описано, готовился не менее ответственно, чем автор поста.
achekalin
После прочтения предыдущих комментов и поста, а потом вашего коммента, в голове само всплыло название следующего сервиса: Яндекс.Девопс. Ну, знаете, сдача админов, которые почти прошли собеседование, в аренду клиентам Я.Облака.
Ну, чтобы просто результаты собеседований хоть как-то применить, даром, что они по алгоритмам!
s1mpl3x
Примерно то же самое проходил перед нг, но у меня сложилось впечатление, что у яндекса девопс это бекендер на дежурствах. Прошел первый такой этап, но настойчиво порекомендовали порешать больше задач на алгоритмы. Продолжать эти круги собеседований я не захотел и просто слился.
kartaris
Несколько лет назад собеседовался на разработчика в Облако. Ожидал, что будет много вопросов по алгоритмам, но завалили вопросами по «железкам» и всему, что около них, а потом дали пару задач на лайвкод на любом удобном языке.
На многие вопросы из первой части я ответил с большим трудом, а на некоторые ответов вообще не знал, что наверняка и послужило поводом меня слить)
Viceroyalty
Напомнило: когда в 2008 (или 2009) на заре карьеры я устраивался в яндекс тоже просили проверить на корректность какое-то дерево и возмущались, что я знаю Руби: не то что пишу на нем, тестовое задание делал на C++, а именно что вообще знаю — интервьюер говорил с презрением «что это за Руби?», «какой-то учебный язык?», «какой-то школьный что-ли?».
Такое впечатление, что в яндексе хорошо умеют проверять знание алгоритмов — вот и ищут специалистов где светлее, а не за углом где потеряли.
MechaDuragon
Это неправда. В данном случае просто не повезло с подрядчиком, кому заказали рекрутирование. В моем случае все было лучше, глушил уже сотрудник Яндекса на последнем этапе, противореча собственным же инструкциям. Правда даже пройдя все этапы, нет уверенности, что вы будете работать в Яндексе, а не на Яндекс в какой-то левой фрилансовской компании.
Правда это было достаточно давно, что бы Яндекс не мог засудить меня за разглашение, ибо соглашение о неразглашении истекло.
Wan-Derer
Меня не взяли водителем беспелоднега хотя я идеально соответствую требованиям вакансии. Про алгоритмы, с.ка, даже не спросили...
Zegan
Ходил на DevOps'a собесится. Было ТРИ собеса по алгоритмам, одно по админству и ни одного по ci/cd и профильным сервисам. Там оч странно
Sofrony
Подскажи плиз, как и зачем собесить по ci/cd, если это учиться за неделю-две и в Яндексе свои велосипеды?
MasMaX
Хочешь сказать чтобы писать эти велосипеды вообще не надо ничего уметь?
Работаю девопс-инженегром. Ни разу за 6 лет не понадобились знания алгоритмов сортировки или слияния массивов. Скрипты пишу постоянно…
Sofrony
Расскажи, пожалуйста, как ты видишь идеальное собеседование на DevOps'a.
vovchik63
в 2018 собеседовался на продажника в яндекс. Задавали алгоритмический задачки))
И еще кучу беспонтовых вопросов
Nihiroz
А мне понравились алгоритмические задачки в яндексе. Первым делом в голову приходит простой алгоритм с большой сложностью. А потом при помощи подсказок собеседующего и всяких хитростей он доводится до сложного, но с малой сложностью. Но у меня, конечно, таких задачек было штуки 4 на двух собеседованиях. На остальных проверяли уже не алгоритмы.
symbix
Задачки нормальные, но зачем столько? Трёх-четырёх достаточно. Я бы уже на втором таком интервью вежливо распрощался, если я захочу порешать задачки, я пойду на hackerrank или leetcode.
swapper9
В свое время я не успел решить одни задачки на время, честно сказал интервьюеру, что если им так нравится, они могут сами решать олимпиадные. В ответ получил оффер.
jkotkot
Так там разные люди собеседуют. Друг другу не доверяют, вот и перепроверяют каждый раз… как в Яндекс.Толока. А вы как думали?
sudden_death
Так могли бы все в одно время поприсутствовать на решении этих алгоритмических задачек… А то время кандидата получается вообще им не жалко.
zuko3d
Ну как бы меркантильно это ни звучало, но время кандидата дешевле, чем время разработчика. Потому что большинство кандидатов отсеются с нулевым результатом, а разработчик время-то потратит всё равно.
shpaker
Внезапно, кандидат тоже работает, собеседование ему никто не оплачивает (а часто это во время рабочего дня) => вылазка для него может оказаться достаточно проблематичной.
PsyHaSTe
Ну значит поток кандидатов с высокой самооценкой поредеет и это частично тоже решит задачу "снизить поток заявок до приемлемого уровня".
Stas911
А почему им его должно быть жалко? Это ж не их время. Вот времени своих разрабов — наверняка жалко.
EzikBro
Ну так если вам нравятся, то и решайте их на leetcode)
Они созданы, чтобы проверять знание кандидатом базового синтаксиса. Конечно, немного думалка тоже проверяется, но алго-думалка с обычной не совсем коррелирует и даже скорее совсем не коррелирует.
NetBUG
Я бы сказал так – в промышленной разработке очень полезно знать, как устроены алгоритмы, но крайне плохо, если их приходится писать самому.
zuko3d
Это крайне плохо, да. Пока вы не сталкиваетесь с масштабами Яндекса. Когда вам нужен хэш-тейбл на миллиард элементов, то внезапно оказывается что стандартная реализация не такая уж и хорошая.
saboteur_kiev
Сколько конкретно разработчиков в Яндекс будут решать задачи с новой реализацией хеш-тейбла?
Такая крупная компания, могли бы сесть, подумать с менеджерами и выдать идеальный ответ — организовать специальный отдел девелоперов-математиков, найти подходящих людей и ставить им задачи.
А не задавать это ВСЕМ подряд, учитывая что такие вопросы задают даже менеджерам (вот они точно будут писать новые реализации хеш-тейблов?)
wataru
Но там не задают задачу на написание хеш таблицы. Максимум на использование. И полностью рабочее бинарное само-балансирующееся дерево — тоже не задают. Максимум тривиальное дерево. Просто для проверки, что кандидат может представить структуру и хоть чуть-чуть понимает, как работают указатели.
saboteur_kiev
Вот именно. То есть зачем они ищут тех, кто пишет алгоритмы а не программы — непонятно.
BugM
А как проверить? Алгоритмы хороши тем что не умея программировать их не выучишь наизусть за 3 месяца. В отличии от баззвордов и 100 типовых вопросов по любой технологии.
И на софт скилах не выедешь, как можно сделать в разговоре за жизнь.
И можно разных кандидатов сравнивать друг с другом. По формализуемым признакам.
Предложите альтернативный вариант. Чтобы не хуже было хотя бы по этим критериям.
Stas911
Ну народ за несколько месяцев мощно насобачивается на решение задач с leetcode.
BugM
Да. Народ уже умеющий нормально программировать. Не случайные люди с улицы после курсов вайти.
Какой варинат решения прелагаете? Спрашивать еще сложнее? Рюкзак модифированный так чтобы его случайный человек не узнал пойдет? Так отсеются вообще все. Случайный мидл даже после сидения на литкоде не справится же.
symbix
Самое плохое в этом всем — то, что в подобных конторах собеседуемому код надо писать не в IDE, а на доске или в условном notepad-е. Это вообще бессмысленное занятие — примерно как проверять, умеет ли оператор экскаватора копать лопатой. Что вы, блин, так проверяете, знание синтаксиса языка? В вакансии на миддла-сеньора, бгг? Еще проверьте, знает ли он алфавит тогда.
Более-менее нормальный подход — давать относительно несложные (не примитивные, но и не настолько сложные, чтобы отсеять вообще всех, кроме гениев и тех, кто подобное решал) задачи, где надо не алгоритмы помнить (то есть надрочиться на литкоде не поможет), а головой подумать, плюс и прикладной смысл чтобы был, и дать человеку ее решать в привычной среде — просто расшарив экран. Пусть гуглит что хочет (кроме прямого решения задачи, конечно), вообще разрешено все (как и что человек гуглит — это вообще о многом сразу говорит!). И посмотреть, КАК человек это все делает. Такое, типа, парное программирование.
Тут, конечно, формальных баллов не начислишь, все субъективно. Но уровень сразу виден, уже через пять минут на самом деле.
wataru
Ну посмотрите же задачи из статьи. Где там хоть одна, где надо алгоритмы помнить? Максимум, знать, что есть такая структура данных — хеш-таблица.
BugM
А примерчик ещё проще чем в статье можно? Там все еще проще вырождается в однострочник или физзбазз.
IDE или не IDE дискуссионно.
PsyHaSTe
Ну так в отличие от ИДЕ от вас не требуется написать компилируемый код, а иногда не требуется и брать существубщий ЯП — достаточно просто набросать алгоритм, чтобы было понятно что куда и как. Вангую что никто не будет докапываться если в каком-нибудь SelectMany букву забудете или порядок аргументов какой-нибудь функции перепутаете. Главное как вы будете рассуждать и какие уточняющие вопросы задавать.
Ilusha
Код запускается и проверяется. Но это по моему опыту и знакомых.
PsyHaSTe
Если от вас требуют написать без ИДЕ на бумажке идеально компилирующийся код без ошибок — то это вполне хороший фактор чтобы туда не идти. Так что не вижу ничего плохого в том чтобы получить на такое отказ.
zagayevskiy
Это где? Особенно с вайтбордом интересно — по-вашему, интервьюер потом сидит и перепечатывает код?
KirillGerasimov
В яндексе, но не у всех. Зависит от интервьюера.
saboteur_kiev
Умение писать алгоритмы, и умение работать в команде, знать фреймворки и другие вещи — вообще не особо связано.
Но вопрос в основном в театре абсурда, когда тебе на 10 интервью задают то одни то другие алгоритмы И НИЧЕГО по технологиям
А в разговоре за жизнь можно много чего узнать. Что человек сделал, зачем, почему.
wataru
Что? По определению, любая программа — алгоритм. Если вы придираетесь к тому, что там на интервью спрашивают заумные алгоритмы, которые в реальной работе не пригодятся — то вы не правы.
Вам так сложно представить, что в яндексе может возникнуть задача взять общие элементы из двух списков (задача из статьи с интервью)?
Я за свою недолгую пока карьеру в гугле много раз использовал и математику и писал хитрую структуру данных, и динамическое программирование. Не каждый день конечно, но эти вещи реально пригождаются. И самое печальное, что если этого всего не знать, то даже мысль не возникнет о том, что вот тут можно было "алгоритм" впендюрить и получить более быстрый и простой код. До этого немного поработал в яндексе, и там пришлось, например, использовать trie для ускорения процесса в несколько раз. Этой структуры нет в stl. Про нее надо хотябы знать, иначе как вообще ее нагуглить?
zuko3d
Так ведь в каждой конкретной ситуации надо смотреть и думать, что нужно. Не может быть универсального решения, т.к. где-то очень важен lookup-time (не асимптотика, а чистое время), где-то важен объём памяти, занимаемый данной структурой. Вы, кажется, не понимаете, что когда речь идёт о миллиардах, то начинает быть важна каждая мелочь.
Ну всем подряд и не задают. У вас тут типичная ошибка выжившего. Те, у кого интервью прошло нормально — они на хабре статей не пишут. Тут не принято писать о том, что в Яндексе хорошие собеседования, за такое можно и минусов отгрести. Поэтому вы со стороны видите только те собесы, которые прошли отстойно. Или прошли нормально, но человеку не хватило компетенции понять, что его вообще спрашивали и какие скиллы проверяли.
Moskus
Всё это помешательство на алгоритмах может объясняться, гипотетически, двумя возможными причинами:
— это действительно нужно (только тогда нужно давать не только самые элементарные вопросы),
— это результат того, что в компании — корпоративный культ карго, выросший из того, что раньше это было действительно распространено и на этом Яндекс что-то выигрывал у конкурентов.
Бардак с «деревом» собеседующих (изоляция процесса найма от реальных задач, как результат этого), размер компании, а также некоторые решения, которые ранее использовались Яндексом, склоняют меня к тому, что более вероятно второе. Ваш же аргумент косвенно исходит из первого, а возможность второго — игнорирует.
zuko3d
О, ну тут всё просто. Я провёл больше сотни собеседований и почти половина кандидатов не смогли решить даже элементарной задачи типа «эффективно удалить нули из массива». Потому что им на практике нигде не надо было работать работать с большими данными и, соответственно, задумываться про асимптотику и т.п. Поэтому к «реальным» задачам далеко не все могут перейти. Но они есть, вполне себе интересные.
Ну Яндекс большой и наверняка в каких-то его уголках есть культ карго. Но в целом — вряд ли. Тут ведь ещё какое-то дело — если не использовать текущую систему найма, то какую использовать? Система с «давайте пообщаемся о прошлом опыте» — полный отстой, т.к. пролезает очень много буллшиттеров (которых потом ещё хрен уволишь).
Текущая система используется (кстати, в том же FAANG примерно всё то же самое при найме — регулярно прохожу собесы чтобы «знать рынок») не потому что идеальная, а потому что пока лучше ничего не придумали.
Moskus
Раз вы ссылаетесь на свой опыт, скажите, сколько алгоритмических задач начального уровня нужно дать кандидату, чтобы надежно отсеять этих самых неспособных, которых вы упомянули?
zuko3d
Ох, сколько нужно — не знаю. Обычно я даваю две простых задачи. Я считаю, что если человек не может решить одну простую задачу — мб не повезло, нервничает и т.п. А если не может решить две — это уже закономерность.
Но тут ведь система со смещённым фидбэком: если мы наняли слабого человека (т.е. человек оказался слабее, чем показалось при найме), то мы об этом узнаем; а если не взяли сильного (т.е. человек оказался сильнее, чем нам показалось) — то не узнаем. Поэтому очень сложно подобрать оптимальное количество и сложность задач.
Есть ещё интересное соображение: если давать много простых задач, то можно не успеть дать сложные (и недооценить кандидата). И это действительно правда, изредка так и бывает. Но если дать сразу сложную задачу и кандидат её не решит — тут всё намного хуже. Т.к. если кандидат не решил сложную задачу — это не значт, что он не подходит, мб он пойдёт на должность ниже. Надо разибраться с причиной того, почему конкретно человек не смог решить задачу — а это ну очень сложно. Я видел как люди на собесе очень хорошо всё рассказывают по плану задачи, но не хватает времени написать код. Их берут в штат, и оказывается, что люди и код-то толком писать не умеют. Это было бы отлично видно, если бы дали простую задачу, но т.к. дали сложную — то подумали, что «перемудрили с задачей, давайте просто дадим ему не сениора, а мидла».
Moskus
Вы налили тонну воды, но ответ все же дали — две задачи должно быть достаточно для общего случая. А теперь перечитайте статью и посчитайте, сколько дали автору. Я не знаю, о чем тут можно спорить.
Все перечисленные нюансы — реальность, но другого порядка.
zuko3d
Я не дал ответ который вы хотели услышать. Но если вы читали невнимательно, то вот мой ответ:
anonymous
Две задачи достаточно, если один интервьювер на всех и он абсолютно объективен/непоколебим.
На деле же, когда у компании 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й.
kesn Автор
Вы меня поразили прям в мозг. Ну добавьте тогда в ваш зоопарк интервьюеров, которые выдают результат в зависимости от дня недели, и интервьюера, который убивает кандидатов с шансом 50%… В моём понимании интервьюер — это функция, которая принимает на вход знания кандидата и выдаёт 0 или 1. Если этот интервьюер выдаёт много FP или FN, значит это паршивый интервьюер и нафига он нужен. Если есть шанс ошибки, то поставьте 3-4 интервьюера рядом и пусть они исправляют друг друга. Добавьте ещё штуки 4 теста для быстрого вылета кандидатов, типа если напишут O(n^2) или если ник начинается с k, то сразу отлуп. Всё.
Судя по тому, что я видел, Яндекс не парится и берёт пулл кандидатов, пулл сотрудников, и как на той картинке с игрушечными собачками скрещивает их. А ведь эту кучу часов, которые рекрутеры тратят на кандидатов, можно было потратить, чтобы — внезапно — улучшить рекрутеров самих и весь процесс в целом.
Я как кандидат — в печали. Я хочу максимально быстрый ответ и, желательно, фидбек. Тут ни того, ни другого. Ну хоть посмеялись всем хабром.
anonymous
Да, Яндекс рандомно назначает кандидатам собеседующих из пула. Есть внутрянняя система фидбека, куда интервьюеры пишут, что спрашивали, что ответил кандидат и оценку. Другие интервьюеры (если секция не в тот же день), обычно проверяют, чтобы не спрашивать повторно те же задачи.
Не очень понятно, как вместо того, чтобы собеседующие проводили по 6 секций с каждым кандидатом, пустить их время на улучшение процесса. Сажать по 6 человек на кандидата — не уменьшит времязатраты интервьюеров, но уменьшит точность за счёт меньшего числа вопросов.
Есть ли примеры крупных IT-компаний (1000+ разработчиков, не бодишоп), где быстро собеседуют и быстро могут дать положительный фидбек?
В гугле с момента подачи резюме до оффера проходит 3-6 месяцев. В Яндексе 1-2 месяца. Да, не неделя, как в небольших компаниях, но раз недостатка в кандидатах нет и акции растут, значит всё работает норм.
Areso
спорное утверждение.
Ко мне рекрутеры Яндекса обращаются с завидной регулярностью. Причем уже доходило до того, что мои данные «передавали» в КА/РА, которое работает на Яндекс.
Ко многим знакомым — тоже.
Да, не спорю, туда все еще многие мечтают попасть, но есть ли прямо очереди? Чё-т не уверен.
anonymous
Основной признак недостатка кандидатов — снижение планки найма.
Активность HRов, это вполне предсказуемый процесс. Яндекс хочет нанимать самых подходящих специалистов на рынке. При этом сильный кандидат может и не подозревать, что его примут в Яндекс. Поэтому Яндексу в целом выгодно множество HRов, которые ходят по рынку и холодными звонками выцепляют людей на собеседования.
И HRы эти далеко не всегда сотрудники Яндекса. В целом есть распространённая модель партнёрства, когда ты заключаешь с компанией договор о том, что она с каждого трудоустроенного от тебя кандидата платит тебе процент. А дальше ты сам себе хозяин и ищешь кандидатов где только можешь. В результате да, бывают эксцессы, а люди могут сокрушаться в комментариях, мол «мне написывал HR из яндекса, как же они задолбали», но это не признак недостатка желающих пройти собеседование.
Мне, например, когда я работал в Яндексе, в Линкедине писали такие HRы предлагая прийти на собеседование в Яндекс. Бывает, что уж
PsyHaSTe
Если инплейс то можете подсказать как? Потому что так-то ничего сильно лучше
arr.Where(x => x != 0).ToArray()
и не придумывается.Можно тоже пример? По опыту в маленьких компаниях это отлично работает, не очень понятно что именно должно сломаться в случае большой. Или у вас в маленьких тоже не работает? Тогда тем более хотелось бы услышать ответ.
Alexandroppolus
Примерно так:
PsyHaSTe
А ну да, логично, даже странно что я про это не подумал. Мне почму-то показалось что мы можем элементы местами менять и нарушить относительный порядок. Немного не в ту сторону подумал.
В целом это и есть
arr.Where(x => x != 0).ToArray()
только копируем прям на месте вместо свободных нулей. Да, спасибо, тупанул четzuko3d
В отдельных маленьких организациях это работает лишь потому, что у каждой конкретной организации выборка маленькая =) В тех маленьких, которых был я — не сработало ни разу (т.е. все, кого наняли «по прошлому опыту» оказались буллшитерами). Но, правда, я там не принимал участие в собеседованиях, а только наблюдал.
PsyHaSTe
По прошлому опыту это ведь не просто "наврите нам покрасивее" а вопросы по этому опыту. Почему сделали так, а не иначе. А вот зачем этот компонент. И так далее.
Плюс можно гитхаб посмотреть если есть, если нет — то все же какую-нибудь задачку разминочную на 10 минут тоже можно. Это не дрючить 10 алгоритмическими задачками на 5 раундах собеседований, но какое-то видение дает. Вкупе с вопросами по арихектуре можно делать выводы.
wataru
Уже сейчас есть в интернете куча платных и бесплатных курсов, задрачивающих людей решать задачи. Т.е. человек без опыта может научится решать задачки и пройти интервью.
Если FAANG будет спрашивать массово про опыт и профиль на гитхабе, то будут курсы, которые будут учить людей складно рассказывать про "прошлый опыт" и объяснять по этому чужому профилю на гитхабе, почему сделали так, а не иначе.
В текущей ситуации имеем людей, возможно вайтишников, которые научились решать алгоритмические задачи. Значит перекладывать json они точно смогут, ибо это проще. В гипотетической ситуации будем иметь кучу вайтишников, очень слабо программирующих, но складно говорящих.
Вторая проблема: поговорить про опыт и посмотреть гитхаб — слишком субъективные оценки. Такое не годится для крупных компаний, которых пытаются засудить за дискриминацию, потому что интервьювер посмел спросить про размер байта в битах.
А еще это на порядок сложнее для интервьюверов. Сходу вот так глядя на неизвестный вам проект понять, что вот такое решение было лучшим, невероятно сложно. Это потребует невероятно много времени подготовки у интервьювера. Когда как задачки можно спрашивать одни и те же, пока они не утекут в сеть.
Вот и получается, что спрашивать задачки — единственно подходящее решение для интервью в FAANG/Яндексе. Оно скейлится, более менее объективно, просто в оценке, проверяет что-то вполне релевантное работе.
sumanai
Интересно, когда появятся курсы, которые учат работать.
wataru
Они уже есть. Но научится работать же сложнее чем только научится скилам прохождения интервью. Люди ленивые и стремятся облегчить себе жизнь.
Stas911
«There is no compression algorithm for experience» by Andy Jassy
Deepwarrior
Научиться работать и не пройти интервью(или пройти на заниженную зарплату) — тоже такое себе
PsyHaSTe
Складно рассказать про прошлый опыт по-моему невозможно не прожив этот самый опыт. Шаг влево-вправо от "рассказывали на курсах" и провал. По крайней мере мне слабо представляется как можно составить решебник на все возможные вопросы.
Ну это да, но мне показалось выше сказали что и для маленьких такой способ не подходит.
Так что сложного? Все непонятные места адресуются кандидату — по его ответам будет понятно, думал он про это или нет, какие варианты отбросил и т.п. Не надо додумывать — надо спрашивать (если конечно есть у кого), наверное одна из первых вещей которые я понял когда начал работать: быстрый фидбек с короткими циклами — залог успеха.
Ну задачки отбирают либо студентов которые недавно их проходили либо сверхмотивированных людей которые в свободное время прорешивают литкод чисто ради фаанга. Пробовал так сделать в прошлом году — после пары десятков задач задолбался и забил.
Я не предлагаю никаких альтернатив, просто рассматриваю минусы текущего подхода. Вполне вероятно это лучшее из худшего.
wataru
Тоже так считаю. Да, у студентов приемущество возникает и нужно тратить время на подготовку. Ужасный метод. Но лучшего, на мой взгляд, нет.
gohan
Есть. Даёте задачу и для неё штуки 3-4 решения готовых, и пусть интервьюируемый посмотрит их и скажет какое лучше и почему. Меньше затрат времени на собеседование, и плюс не будет каких-то глупых ошибок из-за спешки, стресса, неудобства написания кода в блокноте, на бумажке, или на доске.
wataru
Тут в соседнем треде мне другой товарищ доказывал, что эти алгоритмические интервью — ужасны, потому что их проходят легко "профессора" знающие наизусть О-большое всех-всех алгоритмов и умеющие доказывать заумные абстрактные утверждения, но вообще нисколько не умеющие писать код.
В отличии от текущих интервью, ваш вариант как раз подвержен такой проблеме.
Он никак не проверят, что кадидат может писать код. Он никак не проверят, что кандидат умеет решать задачи, а не выбирать из нескольких предложенных вариантов.
A114n
Подавляющее большинство обычных задач в наше время — это как раз необходимость «выбрать из нескольких предложенных вариантов». Уже много раз упоминалось, что «всё давно уже написано», если не в стандартных библиотеках, так на стековерфлоу, нужно просто посмотреть где лучше и выбрать самый подходящий вариант.
wataru
Нет. Вам не даны несколько вариантов. В реальной жизни у вас есть только задача. Вам надо эти варианты еще найти. Как понять, что вот этот вот ответ на стекоферфлоу — хороший? Надо ли искать дальше? Или подобно задаче о привередливой невесте, ищем 4 ответа и берем лучший, надеясь, что среди этих 4-х есть нужный?
Теперь про стандартные библиотеки: 99% всего что вы делаете — нет в библиотеках! Вы можете прикрутить стандартную структуру данных, или найти какой-то фреймворк, который надо как-то потыкать, и часть вашей задачи будет решена. Но практически все, что вы делаете — это решение одной частной ВАШЕЙ задачи. Магической функции "сделать хорошо" нет ни в одной библиотеке.
Это нормально понимать, что вам тут нужно сбалансированное дерево поиска, и взять готовую реализацию из библиотеки. Но если вы не знаете, что вам тут нужно именно дерево, то что вообще искать?
MacIn
Этим вы проверите лишь умение кандидата анализировать, а проверять надо как анализ, так и синтез. Из первого умения никак не следует второе.
Stas911
Кстати да — это ОЧЕНЬ видно хорошо, когда человек сам делал (и шел доблестно по граблям набивая все свои шишки) и когда рядом стоял или «ключи подавал» в лучшем случае.
Поэтому мой совет соискателям — не делайте так.
motoroller95
«Ну ок, хотят проверить знание каких-то базовых вещей»
donRumatta
По-моему, родился новый мем на хабре(=
Viceroyalty
Такие задачи хороши когда нанимаешь студента без опыта с которым больше поговорить не о чем, ну или алгоритмиста.
wataru
Ну нет смысла нанимать выделенного алгоритмиста. Весь абсолютно программный код по определению — алгоритмы. Большая часть — тривиальные, типа пройтись по списку и выбрать минимум или сложить 2 числа.
Без знания о том, какие бывают алгоритмы, без умения решать задачи и алгоритмического мышления часто сложно даже понять, что вот эта задача — она решается тупо (прошлись по списку и выбрали минимум), а вот та — совсем нет.
Потому что почти всегда есть простой, понятный и очень не эффективный наивный метод.
Потому что эта самая алгоритмическая задача ничем принципиально не отличается от всех других задач, которые программисты постоянно решают.
В итоге получается, что выделенный алгоритмист должен ревьювить вообще весь код в компании. С потоком кандидатов FAANG/Яндекса эффективнее, дешевле и удобнее сразу нанимать только "алгоритмистов".
С "поговорить" большая проблема — это очень субъективно. Мелкой компании, где условный CTO сам проводит интервью и решает: кого брать, кого нет — это работает. В крупной типа яндекса и FAANG — уже нет. Плюс, если язык хорошо подвешен, можно тупо заболтать интервьюера в процессе этого "поговорить".
Viceroyalty
Нет, выделенный алгоритмист должен вместе с архитекторами решать как будет работать самые высоконагруженные компоненты.
Без знаний особо не заболтаешь, если человек подходит ответственно к интервью: можно же спросить технические детали/особенности, да и github человека можно посмотреть.А почти всегда есть не очень простой, понятный и очень эффективный наивный метод — правильно применить готовую библиотеку/фреймворк.
BugM
А потом систему в проде уронит случайный метод. Потому что на него внезапно пришла нагрузка, а он сделан так жутко что роняет всю БД.
Внезапно — маркетинг провел рекламную компанию и пришли люди. Эти люди прочитали какую-то статью и пользуются системой не так как ожидали разработчики.
fzn7
Ну уронит и уронит. Кто-то не сможет дошик себе через лавку заказать в моменте или реклама не прогрузится. Ой кошмар какой
wataru
Или у пользователей по всему миру отвалиться условный ютуб на пару часов, потому что упал какой-то служебный сервис из-за возросшей внезапно нагрузки. Или несколько часов не будет показываться вся реклама от яндекса. Огромная денежная потеря.
lllamnyp
Отвечу словами здесь https://youtu.be/NwEuRO_w8HE?t=2180 (там всего на 40 секунд вопрос и ответ). Если вас парит о-сложность до того, как вы запустили код, прогнали бенчмарки и обозначили SLA пользователям, вы занимаетесь преждевременной оптимизацией. В конце концов, насрать, что в формочке на фронте O(n^2), браузер клиента всё стерпит. Не мучайте фронта булщитом про пузырьковую сортировку, пусть об этом парятся люди, которые контрибьютят в ядро линукса или пишут низкоуровневые системные библиотеки.
wataru
А как проверить, что человек сможет исправить найденную после запуска плохую часть?
А потом такие "вот сайт тормозит, пользоваться невозможно!!!". Или у людей игра грузится по 10 минут на пустом месте. При чем там наверняка такая же мысль была: Ну насрать, что там в чтении одного мелкого конфига O(n^2), клиент все стерпит. А потом n, внезапно, выросло и все стало плохо.
SirEdvin
Нет, "потом" такого не будет. Вы просто взяли и пропустили фразы про бенчмарки, SLA и так далее. Если в SLA не было оговорено условное время загрузки сайта, то что там оговорено было вообще?
Просто обычно программный код имеет столько внутренних нюансов, что замена алгоритма с O(n^2) на более оптимальный может замедлить скорость работы, если это делать в слепую.
Вы игнорируете константу, вы игнорируете наиболее полулярные N и так далее.
Что лучше, что бы у большинства пользователей корзина покупок грузилось секунду, а у кого-то 5 или что бы у всех грузилась по 3 секунды?
PsyHaSTe
Только и константы там одинаковые.
Обычно сделать более быстрый (асимптотически) код ничего не стоит. Классический пример который вижу в дотнете:
foos.OrderBy(x => x.Something).First().Bar
. Если это на старте приложения 1 раз делается или там в какой-нибудь режкой ручке — то как бы и плевать. А когда элементов достаточно много да и код выполняется довольно часто — то как бы не очень.При том что решение — загуглить за 5 секунд любую из библиотек-расширений LINQ (либо написать свой хелпер за 5 секунд), и заменить это на
foos.MinBy(x=>x.Something).Bar
— почти те же буквы и те же константы, только уже за линию.SirEdvin
Зависит от контекста. Всегда люблю приводить в пример перемножение матриц)
Зависит от контекста. В вашем примере — не стоит. В каком-то случае это ухудшение читаемости и поддерживаемости кода. В каком-то случае это написание своего более оптимального велосипеда, который потом надо поддерживать.
Я не спорю, что в каких-то случаях вы просто улучшаете точность и все работает, но это явно не 100% и, скорее всего, даже не 50% случаев.
PsyHaSTe
Я это к тому говорю, что плохое решение от хорошего часто отличается не тем что на хорошее нет времени поэтому давайте быстро закостылим, а тем что человек просто не знал, что можно по-другому, а заимплементить что нормально, что костыльно получается одинаково по ресурсам.
Unrul
Обычно небольшие куски кода с медленными алгоритмами размазываются по всему программному комплексу тонким слоем. Тут линейный поиск, вместо хеш-таблицы, там ненужный вложенный цикл, увеличивающий сложность до О^2. И после некоторого количества итераций, всё просто начинает медленно работать без каких-то явных ботлнеков. И тут, зачастую, остаётся только всё переписать с нуля.
SirEdvin
Сколько не работал с кодом, обычно существует одно место, которое тормозит больше всего, и это место отвечает за какую-то io работу в духе "сходи забери из базы что-то с кривым запросом". Переписываешь запрос и все работает :)
Даже во всяких cpu-bound задачах довольно часто спасает кеширование или исправление конкретного места.
OlegMax
«1. существует одно место, которое тормозит больше всего
2. Переписываешь запрос и все работает
3. goto 1»
Так лучше.
zuek
Буквально на днях столкнулся с "возросшей нагрузкой" — есть корпоративный портальчик, ничего супер-пупер нагруженного, состряпали, запустили, пользуемся… через пару лет начинаются жалобы — тормозит. Автор портальчика к тому моменту уже потерялся, полез смотреть сам (я не программист) — оказывается, при каждом действии, ajax шерстит историю сообщений, чтобы в случае чего новенького отрисовать "колокольчик", а сообщений накопилось уже немало, а в алгоритме почему-то был линейный перебор с "ручным" анализом "новое/прочитанное" (таблица ID прочитанных сообщений была у каждого пользователя своя, а таблицы сообщений шли сплошной простынёй)… казалось бы — сделай запрос к базе по JOIN с "объединением по NULL", чтобы отобрать только непрочитанные, но автор решил несколько иначе — выбирал все сообщения, а потом искал их ID в "личной" таблице, и если не находил — высвечивал оповещение.
Вроде рабочий алгоритм, но вот с масштабированием совсем боль.
SirEdvin
Ну так тут же дело не в каких-то неправильных алгоритмах, а в нарушение принципов работы с БД, что все выборки и расчеты максимально должны выносится в БД.
Rebus
Так, стоп! Это кто там такие принципы напридумывал? Те же самые люди, которые придумали триггеры и хранимые процедуры? Ок, у меня к ним есть только одно пожелание, и оно связано с адом и огнём.
Да, и триггеры, и хранимые процедуры могут быть полезны, Но вот крайне было бы замечательно, если бы каждый занимался своим делом. БД — хранила и выбирала данные, а все остальные — всё остальное.
Кхм, ну и да, я понимаю, что уже может быть преувеличиваю… Так можно и JOIN ересью объявить… Но возможно, об этом стоило бы подумать. :-)
SirEdvin
Ну так это ровно то же, что вы пишите. Выборка данных + расчет производных данных на их основе (преобразование функциями, сумма, вот этот весь треш).
Если вы фильтруете или преобразовываете данные потом на бекенде, то тут что-то немного не так. Иногда это ваша вина, иногда бд.
Rebus
… иногда даже вина человека, который занимался выбором БД. Просто потому что колоночные БД и, например, теперь уже бесплатный кликхауз, это могут делать на порядки быстрее.
Но, в целом, мы приходим к изначальному вопросу статьи.
Для того, чтобы выбрать Clickhouse для решения определённого набора задач, надо знать и про Clickhouse, и про то, на каких наборах задач он будет в сотни раз быстрее других СУБД…
И, да, в общем случае, я фиг знает, как вообще можно такие вопросы гарантированно решать за 2-3-4 часа одного собеседования. Но в Яндекс с 10ю собеседованиями и ставкой ниже рынка не пойду. Ну разве что совсем от голода помирать придётся…
Areso
Потом заходишь такой в интернет-магазин (мобайл-фёрст), открываешь с мобилы список товаров, он тупит, но через минуту всё-таки подгружает всё что нужно, и наконец нажимаешь «отсортировать по ...» и обычный обывательский мобильник на snapdragon 4хх (6хх) вешается. Без шанса на спасение.
lllamnyp
Я на самом деле очень люблю оптимизировать. Я несколько лет работал научным сотрудником в сфере, где широко использовалась wolfram mathematica. Я очень заморачивался над вещами типа сведения интеграла к сумме по элементам массива, над вставками на C, которые работали быстрее, итд. Но я это делал уже сильно после того, как написал первый прототип программы, который работал нормально, а потом захотелось больше отзывчивого UI. Я не считаю, что рядового кодера в стрессовых условиях собеса нужно мучать на оптимальные алгоритмы. Для этого давно есть библиотеки и только в редких случаях возникнет реально проблемный боттлнек, где придётся оптимизировать код. Если такое случится — ну, ок, сядет разраб и в спокойной обстановке поищет, в чём там проблема.
mad_god
Почему сразу не думать в категориях нормального кода? Второй раз может и не захотеться переписывать, жалко времени, кончились деньги и т.д.
Типа, сначала строим дом, потом смотрим, что получилось неплохо, но нужно сделать канализацию, затем снова поднимаем краном и прокладываем водопровод. Разматываем электрические провода вокруг дома, снимаем обои и начинаем штробить стены.
ZuOverture
Говорят, code is clay, имея в виду, что код обычно не надо переделывать заново, как какую-нибудь шестеренку, если в процессе изготовления допущена ошибка. Чаще всего изменение обходится малой кровью.
Unrul
Так и в исправлении неправильного ремонта ничего «слоного» нет. Проштробил стену, потом обратно замазал.
mrsantak
При строитенльстве домов теже проблемы, только в меньшем масштабе. Возьмите типичную квартиру и посмотрите как расположены там розетки, используются ли вские тройники и удлинители. А ведь это все можно было решить на этапе ремонта. Вот только для этого нужно точно знать где какая мебель будет стоять, какие у неё будут размеры, какие электроприборы и где будут стоять и использоваться. Точно это предугадать невозможно, поэтому и возникают все эти удлинители или абсурдно огромные группы розеток "на всякий случай".
Так же и в разработке софта. Мы зачастую не знаем сколько у нас будет пользователей конкретной фичи, не знаем какие фичи будут добавлены завтра, а какие убраны. Мы даже не знаем кто будет завтра с этим кодом работать. То что мы знаем точно — так это то что проект точно будет меняться или умрет. Но что именно будет меняться — можно лишь гадать. И правильно угадывать мы будем далеко не всегда. Поэтому намного выгоднее писать код таким, чтобы его было легко менять в будущем, пытаться предсказать что может поменяться, а что нет. А еще, чтобы его могли понять другие разработчики, желательно без необходимости вникания во всю историю проекта. Хороше же оптимизированный код зачастую сложно читать, сложно расширять. В итоге приходится балансировать между расширяемостью, читаемостью и оптимизацией. Хороший разработчик — не тот кто упарывается в одну из этих крайностей, а тот, кто умеет находить баланс в каждом конкретном случае. Когда надо — писать хорошо оптимизированный write only код, а когда надо — медленный, но легкочитаемый и/или легкомодифицируемый, а в большинсте случаев — что-то среднее.
wataru
Это только если упарываться микрооптимизациями. Если просто использовать нормальный алгоритм или структуру данных — то код часто даже проще и понятнее. Что легче — полный перебор через рекурсивную функцию с откатами и неочевидными отсечениями, или динамическое программирование, которое все — 2 вложенных цикла и тривиальная формула для пересчета одной ячейки массива через соседние?
mrsantak
Осталось только найти границу где "просто использовать нормальный алгоритм или структуру данных" переходит в "упарываться микрооптимизациями".
lllamnyp
Спасибо, вы меня поняли. Заморочиться и написать fast inverse square root всегда можно потом.
FluffyBeaver
Справедливости ради стоит заметить, что если подходить к ремонту серьезно, то уже после второго ремонта (в смысле, при планировании третьего) не будет ни лишних розеток, ни удлинителей. Это если себе делать.
Если же Вы прораб и делаете ремонт «другим», то тут грубо говоря два варианта: 1) прораб
м###кне является профессионалом и без комментариев и продолжений выполняет требования по количеству розеток заказчика; 2) даже небольшого жизненного опыта достаточно, чтобы вовремя спросить «а робот-пылесос где парковаться будет?»/«а в шкафу подсветки не будет что-ли?»/«думаете на вашу столешницу больше двух электроприборов за раз поместиться?»/«ну это новая зубная щетка заряд держит, а потом как вы ещё заряжать будете, когда тут бритва на зарядке и фен нужен?»Все лишние розетки и удлинители после ремонта, которые видел либо от отсутствия опыта, либо от нежелания «использовать мозг по назначению»…
teemour
это вы как выяснили?
Primala
Опыт показывает, что нет ничего более постоянного, чем временное.
Рефакторинг отнимает кучу ресурсов, больше, чем было бы потрачено на изначально грамотное проектирование. В конечном итоге рефакторинг откладывается до лучших времен, баги митигируются костылями, мейнтенанс и дев луп растут.
u007
Впрочем, ходят слухи, что уже ведётся работа над новым движком для комментариев, и к осени он будет готов. К какой осени — источник умалчивает.
Viceroyalty
Что там телефон — у меня ноут еле тянет.
Psychosynthesis
Это вы так лихо Хабр новостным ресурсом обозвали или я чёт не понял?
u007
С возможностью комментирования и элементами социальной сети)
pfsenses
Можно подумать это не так. Нормальных технических статей практически нет.
Maccimo
Браузер стерпит. Пользователь может и не стерпеть.
AxelLx
BugM
Или все такси в России на час перестанет работать. Остальные нагрузку не тянут, и ложатся под ней.
fzn7
И как такси без Яндекса работало сотни лет? Пришел случайный Джун, отсортировал массив пузырьком и нагнул отрасль, ну да
BugM
И как люди без интернета сотни лет жили?
И как люди без электричества сотни лет жили?
Раньше работало, плохо но работало. Сейчас если Яндекс падает такси в России перестает работать. Надо теперь с этим жить.
perfect_genius
А конкуренты куда делись?
BugM
Нагрузку не тянут.
В прошлом году полдня Яндекс такси лежало, все конкуренты легли под нагрузкой сразу же.
https://habr.com/ru/news/t/487130
tcapb1
При этом сервисы Яндекса и так регулярно падают. В Яндекс.коннект или в метрике или в Яндекс Недвижимости регулярно натыкаюсь на «ваш запрос не может быть выполнен», на несохранение каких-либо действий или просто на неверную выдачу.
pesh1983
И как вам тут алгоритмы помогут? Отказоустойчивость проверяется нагрузочным тестированием. Даже идеальный алгоритм захлебнётся, если элементарно не хватит нужных ресурсов.
BugM
Никто не гоняет нагрузочне тестирование по всем апишкам после каждого релиза.
Никто даже не пишет его. Это слишком дорого и долго. И не нужно в общем случае.
Критический путь можно так проверять. И иногда проверяют. Но это даже близко не все методы.
Areso
Не согласен с вами.
Мы поддерживали целый стенд для людей, занимающихся автоматизацией нагрузочного тестирования. Биллинг.
Primala
Нагрузочное тестирование — чрезвычайно нетривиальная вещь, особенно для stateful сервиса. В больших компаниях за этим стоят отдельные сервисы со своими командами. И то даже в Яндексе и FAANG'е это далеко не для любого сервиса отлажено хорошо. Не панацея, в общем.
der_Kater
упадёт потому что NPE, и тут никакой алгоритмист не поможет ))
AnthonyMikh
А вы не пишите на языках с null-ами
Kroid
nikbond
Если он сделан прям «так жутко», то он просто код ревью не пройдет.
BugM
Хочется верить.
Всегда есть вероятность что какой-то код написали в тестах. А кто же внимательно ревьюит тесты?
Потом этот же код скопировали в метод нужный в админке. Кто же внимательно ревьют скопированный код на который не будет нагрузки и пользователи все свои?
А потом его вызвали из любого пользовательского метода на который не должно быть нагрузки. Кто же внимательно ревьют не тот код что написан только что, а какой-то там метод? Тем более нагрузки же нет.
А потом пришла нагрузка. И все легло. И никто не виноват.
BelBES
Под "алгоритмистами" чаще всего понимают рисерч-инженеров… давайте расскажите, как компаниям не нужен R&D и все можно порешать на уровне понимания "сейчас пройдемся по списку и сложим два числа"...
wataru
Судя по контексту ("алгоритмические" задачки на интервью) тут под "алгоритмистами" вполне себе подразумеваются обычные программисты, которые умеют в структуры данных, О-большое и всякие алгоритмы.
BelBES
Будто бы база для алгоритмиста чем-то отличается. Вопрос в глубине экспертизы и решаемых задачах.
WASD1
Выделенный алгоритмист не нужен.
У нас был проект, где были выделенные аналитики для увеличения производительности (прям такие математики-предметники). Которые в код реально не лазили.
В итоге (у них было достаточно «веса» чтобы настоять на включении доп.оптимизаций) схема разработки превращалась в старый анекдот про филина и мышей: «я вам решение сказал, а как вы будете это делать — это уже технические (не волнующие меня) детали».
whitehat
Яндекс, суть копия западных компаний типа Гугла, и в собеседованиях решил не напрягаться и просто копировать литкодовые бесполезные задачки, которые упорно задают в западных компаниях
yudinetz
В смысле копия? Это вы так резко опустили всех разработчиков FAANG?
Если же вы имеете в виду, что копия в плане собеседований, то флаг им в руки. Зачем нужно проходить это все в Яндекс, когда можно то же самое все пройти в любую из FAANG?
300KpS
А зачем, например, уежать работать за границу, когда можно не уежать? А зачем вообще что-то делать, когда можно не делать? Таким вопросом можно много чего обесценить.
Все люди разные. Кто-то захочет в Я. работать, кто-то в FAANG захочет. Статьи «какие в Я. глупые алгоритмические собеседования» пишутся время от времени, но даже сейчас, конкретно в этой статье, в опроснике есть люди, которые всё равно выбрали бы Я.
DarkGenius
А что не так? В Яндексе нет настолько умных людей как в FAANG? Или они не делают нормальные сервисы?
siziyman
Ну, не знаю, огромная доля сервисов Яндекса со стороны кажется банальным симптомом болезни «а во. такая штука появилась на рынке, значит, надо делать свой клон». Редкое исключение — божественный Яндекс.Маркет, но и его загаживают последнее время жутчайше.
Am0ralist
merhalak
А ведь какая стюардесса была...
Am0ralist
сейчас активнее екаталог использую
после того, как отменили возможность негативных отзывов на поведение контор из избранного списка — вообще смысла искать на маркете стало минимум.
а до этого уже даже мейлру выдавал в поиске лучшие варианты для покупки отдельных вещей, чем яндекс.поиск и уж тем более маркет.
Вот здесь столько спецов из яндекса рассказывают про крутые алгоритмы, и ведь никто не ответит, почему на жалобу, что в яндексе галочка «искать как в запросе» банально ничего не делала и выдача оставалась такой же, решение было принято по удалению данной галочки.
Ну, так сказать, вот они — крутые олимпиадники в действии…
Kwisatz
Чего чего сделали?
Ой это действительно боль, все еще пользуюсь яндексом по инерции, но заставить его найти именно то что я хотел а не то что он выдумал, это тот еще квест. Особенно весело, учитывая что я работаю с вещами по которым 1.5 статьи и из них одна на английском. Все чаще открываю гугл или утку.
Am0ralist
Если контора отдельно оставила возможность покупать у неё миную яндекс, то там отзывы есть и много всяких в духе «кинули с заказом, отменив оплаченный», «ради гарантии пришлось переться в жопу мира несколько раз» и т.п.
PS. И да, это я виноват. Наехал на яндекс за то, что их «проверенные поставщики» (то, что было ДО этого изменения) массово кидали перед нг народ, отменяя даже оплаченные заказы. Вот, олимпиадники в яндексе решили проблему — нет отзывов, нет возможности доказать, что их проверенные поставщики так делают
Kwisatz
Вот это жесть и как интересно можно было додуматься до такого.
Но справедливости ради это не вина олимпиадников, это вина их начальников. У меня вообще складывается ощущение, что я последний адекватный руководитель на планете, ну что за треш то кругом а.
Am0ralist
Kwisatz
Вот это жесть, это же постараться надо чтобы ТАК работать. А по задумке яндекса можно просто уйти к ним в партнеры и такого никто никогда не увидет? Прикольно.
Ну ок, значит будем людям объяснять что на я.маркете отзывы смотреть нельзя, пусть фламп развивают.
Am0ralist
Так я и говорю, уже несколько лет яндекс начал бороться с пользователями. В связи с чем ушёл с стринг, поиск разнообразил другими, цену ищу на екталоге, в вебверсию почты не захожу (только сторонние клиенты, в том числе на смартфоне). С ужасом жду, что они сделают с яндекс.метро на смартфонах, нафигатор уже снёс в пользу карт, да и то чаще в 2гис на месте бегаю. Гоу с момента переименовывания ни разу не юзал.
А ведь была такая удобная и хорошая экосистема, блин
Moskus
Курс на это можно было предположить уже тогда, когда вместо покупной картосновы они стали разрабатывать собственную путем покупки конторы, нанимающей пионеров для рисования по спутниковым снимкам, и когда в сервисах погоды и отслеживания общественного транспорта стали алгоритмически дорисовывать несуществующие данные.
Moskus
Не то чтобы я хочу сказать, что это именно вина олимпиадников, но олимпиадники — такой народ, который скорее будет беспокоиться больше об алгоритмах и меньше — о, гхм, поворачивании к клиенту задницей. В этом смысле, они — идеальные исполнители для таких начальников.
DarthVictor
С чего бы это? В сам FAANG конечно больше кандидатов, но вот и мест там значительно больше.
При этом для выпускников местных топовых вузов, как мне объяснял один знакомый из Долины, пойти в Гугл, это не как для москвича после МГУ / МФТИ пойти в Яндекс. Скорее как для москвича пойти в какой-нибудь банк, разгребать несвежее легаси, поскольку местные успешные разработчики стараются идти в стартапы за долей в компании.
siziyman
В стартапы, доля которых уже осязаемо чего-нибудь стоит, а не может быть будет стоить через Х лет при лучшем раскладе, отбор и конкуренция строже, чем и в фаангах, и в яндексе, при прочих равных.
А ещё планета не выглядит как «Россия и Долина», между делом. :)
zynaps76
Среднее по больнице на то и среднее, что на больших числах размеры конторы перестают влиять на средний IQ там работающих. )
ps Советую не обожествлять фаанг. Судя по рассказам, локального бардака и бюрократии там куда как больше.
vlivyur
Божественный? Да он был таким пару лет назад, пока из него магазин не догадались сделать. Теперь в нём нет сортировки по цене и отзывы обо всех модификациях фигачат в одну позицию.
Olegnv47
т.е. вы считаете, что что и крупнейшие западные топовые компании и создатели литкода, да и наверное все вокруг идиоты?) и только вы один светоч знаний
whitehat
Крупнейшие западные компании заигрались в литкод, потому что не в состоянии придумать нормальный процесс, адекватно оценивающий кандидатов. И да, там тоже работают люди, а не боги, и они тоже ошибаются. Так же как они раньше в Гугле спрашивали «сколько теннисных мячиков помещается в боинг 737?» и все, как обезьяны, за ними повторяли. Потом признали, что подобные вопросы — идиотизм. Так и сейчас, Гугл на собеседованиях спрашивает всё меньше литкода, а больше более приземлённых, более адекватных для будущей позиции, задач. Так же как и с мячиками, пройдёт лет 10 и слоупоки-подражатели типа Яндекса тоже сменят пластинку и начнут подражать новым веяниям из Кремниевой Долины
Viceroyalty
Согласен — хорошо вести бизнес, хорошо создавать продукт, хорошо собеседовать кандидатов, хорошо <что-то еще> — это совершенно разные задачи.
С топовыми компаниями тут ошибка выжившего — не они топовые по тому что у них эффективная система найма сотрудников, а неэффективная система найма сотрудников не мешает им процветать потому что они топовые (много денег и многие хотят там работать).
zynaps76
А мне кажется, что они не слоупоки и совсем не подражатели. Просто «отличники» или около того, в большинстве своем. Ну привыкли просто так со школьной скамьи… по другому не умеют. Им бы, наоборот, поучиться у гугла с майкрософтом или у других, более адекватных к собесам российских контор. Вон ниже Emil983 о них [google/ms] рассказывает.
Я уже раза три за последние 15 лет, устраивался в подобных топик-стартеру условиях в топовые компании. Слава богу, попадались адекватные интервьюеры и будущие коллеги. Работа-то далеко не из задачек на классические алгоритмы состоит. )
Moskus
Поправлю: Яндекс в этом смысле повторяет не за условным Гуглом, а за самим собой во времена первичного расцвета. А сейчас это превратилось в культ карго.
EvilMonk
zagayevskiy
Я думаю, правильный ответ — это как-то адекватно порассуждать на тему, прикинуть. Ну ошибешься на пару порядков, думаю, оценивать будут не это.
Stas911
Ни одного — у него люки закрыты! (не знаю)
Olegnv47
Так в Яндексе никто про тенисные мячики не спрашивает. А почему вы решили, что задаваемые задачи не имеют практического применения в Яндексе? Вы там работали или хорошо знаете как работают в компании? Я вообще не понимаю такого негодования. Не нравится процесс собеседования, ну так не ходите на них в подобные компании. Почему вы считаете, что процесс правильного собеседования может быть только 1, а все другое ложно?
Rebus
Спрашивали, спрашивали про мячики. Ещё году в 2007, когда это и в гугле могло сойти за новинку. Ну и, собственно, да — в общем, вряд ли я в Яндекс пойду. В прошлый раз пока их рекрутёр расщедрился договориться о собеседовании, у меня уже другой оффер был. И не один.
Emil983
Бред. Собеседовался в MS на Software Engineer и дважды в гугл на Software Engineer Manager за последние 3 года. В MS никаких тупых задач для студентов не было, были задачи приближенные к реальному миру и после их решения каждый раз говорили (ну вот примерно вот так у нас хранение прав устроено), в гугле аналогично: только одно собеседование по кодингу из 5 такое на «базовые вещи» и то это не просто «покажи дао алгоритмов» а вот тебе интересная задачи и реши её, а потом мы обсудим её сложность и как можно улучшить.
А про Яндекс сколько лет не проходит одно и тоже: тупой онанизм на алгоритмы и не надо рассказывать что то «ну а как же им еще большой поток неадекватов отсеивать». У FAANG их куда больше и они постоянно улучшают процессы. В прошлом году в гугле код надо было писать в гугл доке (о да, круто, правда?), в этом уже они свой редактор сделали и плюс ввели кроме кодинг еще и код ревью собес для менеджеров.
whitehat
В каком году вы проходили собеседования? Я выше написал, что гугл (ну ни наверное остальные ФААНГи) уже осознали идиотизм литкода и задают более адекватные задачи. Но мелкие подражатели продолжают тупо долбить литкодовские задачи. Особенно если бывший инженер гугла уходит в другую контору и там все на него молятся, он будет ещё лет 15 применять (давно устаревшие) гугловские практики на новом месте. Я недаром про мячики вспомнил — буквально на прошлой неделе на собеседовании в Verizon был задан вопрос «как взвесить школьный автобус». Угадайте кто его спросил? Правильно, менеджер, который 12 лет сидит в Verizon, а до этого работал в гугле
Emil983
Проходил/прохожу в 2021, 2020, 2019. в 2019м в MS оставшееся время беседовали об этом с одним из интервьюеров и он посмеялся над этим тоже, сказал что такие задачи они давно дают только людям без опыта, читай студентам, у которых-то и спросить больше нечего. Согласен, есть и люди которые бездумно перенимают то что они считают лучшим. Даже на логику есть куда более адекватные задачи.
ABBAPOH
Ну я вот собеседования в прошлом году в Фейсбук и в этом в Амазон. Задачи, внезапно, с литкода.
Окей, в Гугле на первой итерации попросили сдизайнить шедулер тасков, не совсем типичная с литкода, но такие там тоже есть.
nixxa
Аналогично, в 2020-м Гугл, Фейсбук и Амазон спрашивали алгоритмические задачки. Это при том, что в Гугл, например, требовался формошлеп на ангуляре.
Dechjo
Эта leetcode.com/problems/task-scheduler? Классная задачка, на мой взгляд.
ABBAPOH
Не, не эта — надо сделать возможность выполнить коллбек через Х времени в будущем. И чтобы была возможность отмены.
Типа надо сделать 2 метода
TaskId enque(Task task, Time time);
void cancel(TaskId taskId);
Больше вводных вроде бы не было. В целом достаточно творческая, есть над чем подумать, не супер сложная (это фон скрин был), но и не «разверните строку».
Xitsa
Колёса времени?
wataru
Вообще, стандартное решение этой задачи — с использованием priority_queue.
В очереди хранится пара {время, TaskId}, упорядоченная по минимуму времени. Еще нужен map TaskId->время. При enqueue создается новая задача и помещается в очередь. При cancel соответствующая запись из очереди удаляется.
Не надо даже писать очередь, можно использовать stl-овскую, например. Правда, могут спросить, а представляете ли вы как эта структура данных работает.
Другой поток просыпается при любом enqueue или по таймеру. При просыпании он смотрит, пора ли выполнять следующую задачу и выполняет ее. Если рано — ставит таймер до следующей задачи.
По-моему, при написании от кандидата не требуют знаний системных вызовов для таймеров, событий и потоков. Обертки над всем этим и так есть в любой большой компании. Достаточно сказать: ну пусть у нас есть Event, у которого есть метод Wait(timeout), который усыпляет поток, пока не выйдет таймаут или кто-то не вызовет у этого объекта метод signal. Тут интервьюер может даже подсказать, если только кандидат скажет, что надо усыплять потоки. Если кандидат знает про select — это плюс.
Потом могут быть дополнительные вопросы, а что делать, если какая-то задача выполняется дольше, чем дедлайн до следующей? (запускать следующую сразу и не засыпать). Можно ли выполнять задачи в несколько потоков? (можно. Один поток все так же спит, отсчитывает таймеры и работает с очередью, а другие спят пока не получат задание на выполнение).
Еще надо помнить про всякие крайние случаи — типа enque задачи в прошлом времени.
Колеса времени
PsyHaSTe
Тогда уж нужно TaskId -> Node, чтобы можно было из очереди за О(1) удалить, иначе для удаление задачи с конца нужно долго и упорно пёхать по всей очереди (если она в виде связного списка реализована).
Alexandroppolus
Из priority_queue за время О(1) удалить не получится. По крайней мере, если это priority_queue на основе "пирамиды".
Хотя если брать "в среднем", то да, О(1) и выходит… Но в любом случае для нужно время, а не Node.
Впрочем, если есть Node, то его можно не удалить, а "задизаблить".
wataru
Еще можно std::set использовать в качестве очереди.
anonymous
А откуда у вас данные у Гугле?
Я собеседующий в Гугл. За последние пару лет в процессе собеседования не поменялось принципиально ничего. Те же задачи, похожие на литкод. Да, хорошим тоном считается завернуть их в обёртку реального мира. Например, не строку ААААВВВ преобразовать в А4В3, а что-то, что вы военный радист и получаете донесения с передовой для дальнейшей передачи в штаб. Вам надо раз в день собранный поток сообщений как-то уменьшить в объёме, но сохранить порядок. Ещё известно, что часто подряд приходит много однотипных сообщений. Вопрос — как будете преобразовывать? Тут с помощью интервьюера дойдёте до исходного условия и дальше напишете тот же алгоритм (ну или не напишете).
whitehat
многие знакомые/друзья собеседовались и делились опытом и задачками. Последний вот месяц назад собеседовался, сказал что очень вменяемые практические задачи были, непохожие на литкод. Я именно в гугл даже не пробую, ничего плохого не имею против таких контор, но я по жизни не бегу туда куда все бегут :) Надеюсь мой стартап взлетит и в итоге получится даже больше чем обычно в фаангах зарабатывают :)
Stas911
И придется уже вам задавать соискателям задачки :)
AEP
В 2008 году в Яндексе такого алгоритмического маразма на собеседовании не было. Да, алгоритмы были, но не в таком количестве, и с очень хорошей привязкой к внутренней механике Яндекс-поиска.
P.S. я — бывший сотрудник.
iroln
Нет, они довели до абсурда худшие практики, которые в FAANG постепенно уходят из повестки собеседований.
Несколько лет назад, когда я проходил свои 4 собеседования в Яндекс, они всё же были другими. Там про архитектуру и проектирование систем спрашивали, про устройство Linux, распределённые системы и т.п. интересные вещи. А то, о чём написал автор — это квинтэссенция идиотизма. Бессмысленная трата времени и очень плохой алгоритм фильтрации и проверки кандидатов.
Tuxman
В начале собеседования с Гуглом, вас потребуют подписать NDA, что ни какие подробности интервью вы не можете разглашать. Какие последствия? Наверное через суд, заставят оплатить издержки, например, потратили время на 1000 кандидатов, которые уже знали заранее ответы, или оплатить 100 часов на переделку всех контрольных билетов. :-)
Am0ralist
Ну ок, пусть оплачивают время собеседника через временный контракт с доступом к коммерческой тайне.
sumanai
В России это так не работает, даже для работника оформить коммерческую тайну тот ещё квест. В США не знаю, может, с этим намного хуже.
KirillGerasimov
Собеседовался в Гугл в Цюрихе — ничего подписывать не просили.
Sofrony
Какие были задачи?
KirillGerasimov
Например, найти через сколько рукопожатий знакомы два человека в большой социальной сети типа G+.
Sofrony
двунаправленный поиск в ширину?
KirillGerasimov
Похоже, но я не знаю точного ответа. Я рассуждал про разные датацентры и репликацию данных, не знаю насколько это было нужно.
AEP
У кандидата в Google есть возможность отказаться от подписания NDA, при этом собеседование все равно происходит, просто на беджике появляется красная клякса «NO NDA».
Stas911
Ему дают другие задачи или просто не особо откровенничают?
AEP
Не откровенничают на этапе, когда можно задавать вопросы про Google.
Stas911
Все подробности интервью давно есть в комментах на Glassdoor, «ищущий — да обрящет»
ShashkovS
Простите, не смог пройти мимо. Если a и b — один и тот же набор из 1000 различных чисел, то эта программа пройдет по каждому из списков по 1001 разу. Получится пара миллионов сравнений и прибавлений счётчиков. Короче получилось O(n?).
kesn Автор
Ага, сам знаю. Но именно так я и написал бы в проде. Это легко читается, достаточно быстро на небольшом количестве элементов (а сколько их обычно будет в реале, 10-20?), легко пофиксить, если станет боттленеком. Preliminary optimization — зло, как по мне.
cthtuf
если бы можно было весь collections юзать, то я бы такой варик предложил:
правда не знаю какое тут О
kirillsulim
O(n) для конструкторов Counter, O(n) для операции перечечения, O(n) для получения элементов и O(n) для конструктора списка. Итого O(n).
a1ex322
так что получается, чтобы не позориться с N^2 придется либо дерево писать либо хеш таблицу
wataru
На интервью не требуют писать стандартные структуры данных. Сойдет и использование встроенной хеш таблицы. Запрещают пользоваться стандартной библиотекой там, где есть встроенное решение всей задачи. Иначе проверять нечего.
Ну, на худой конец, можно отсортировать и слить 2 списка. Будет O(n log n) вместо O(n). Если сказать, что можно и хештаблицей, но я боюсь, что не напишу ее за интервью.
mrbald
))\n — скобки закрывать надо!
encyclopedist
Dawson’s first law of computing: O(n^2) is the sweet spot of badly scaling algorithms: fast enough to make it into production, but slow enough to make things fall down once it gets there.
https://randomascii.wordpress.com/2021/02/16/arranging-invisible-icons-in-quadratic-time
sumanai
Я разок такое написал, а потом процесс в проде видел по много часов там, где после оптимизации справлялся за 10 минут.
faiwer
20 уже много. Вот если 3-5. Причём нужно очень хорошо понимать, какие реальные объёмы могут встретиться на проекте. Не только самые типовые. А то потом получится как на gitlab-е, или ikea. На gitlab-е открываешь большой MR и оно едва ворочается. Или вот в ikea видимо тоже примерно так подумали — сколько человек товаров может заказать? 5? 10? Нормааально. Заказываем 14 и страница зависает на любое действие на секунды.
Не шутите с квадратами. Мы, программисты, очень часто далеки в своих оценках от реальности.
P.S. а ещё всякие катастрофические regexp-ы, убивающие поток на минуты попадись им строка чуть длиннее обычного.
JustDont
Ситуации вида "ваш сайт дико тормозит" в коде вполне могут быть выражены ситуацией "наш код прекрасен и работает за O(1). Тормозит что-то? Ну, это проблема не на нашей стороне, а какой-нибудь там
реакт редакс браузервиноват, но не мы (с)". Это, опять же — тоже реальный личный опыт из разгребания не вполне рабочих фронтовых проектов, созданных руками чудо-алгоритмистов.Скажем, уже больше 10 лет назад меня попросили "оживить" проект-презенташку очень важных данных в виде таблички, где у чудо-алгоритмистов, написавших чудо-бэкэнд, вдруг возникли сложности с презентованием результатов. Я пришел, увидел код, который на примерно любое действие пользователя собирал огромнейшую строку (всю страницу вместе с большой-пребольшой таблицей в основе) и фигачил её в корневой элемент презенташки через innerHTML. Когда я немного пришел в себя и поинтересовался, как такое вообще могло появиться — мне было сказано, что тут всё реализовано через минимальную алгоритмическую сложность O(n), и это всё так и надо и правильно. А что тормозит (браузеры немного выпадали в осадок и потребление памяти дико скакало, с ожидаемыми тормозами в моменты, когда она вся выжиралась) — так это просто браузеры плохие. И вообще этот ваш веб новомодный отстой.
faiwer
Я ни разу не спорю с тем, что базовые алгоритмы это только один из многих необходимых навыков :)
wadeg
ABBAPOH
Ну, использовать готовые библиотеки (нумпу какую-нибудь) умеют математики, физики и химики, в чем ваша ценность как программиста-то? Чем вы лучше девочки с химфака которая освоила пару питоновских библиотек и хреначит код для своих исследований? Почему должны нанять вас, а не ее?
mdevaev
Почему нужно брать инженера, а не физика, чтобы разрабатывал трансмиссию для автомобиля?
Инженерное искусство состоит в умении хорошо скомпоновать готовые решения, сделать конечный продукт поддерживаемым и простым в расширении, а так же в умении видеть необходимость оптимизации, когда нужно делать что-то новое. Если готового решения не существует, пойти и разработать свое собственное. Если не хватает экспертизы — посоветоваться с кем-то.
sumanai
Потому что её нет на собеседовании, а остальные кандидаты ещё хуже.
ABBAPOH
Так мой поинт обратный — вот к вам на собеседование пришли химичка, физик, математик и автор поста, которые освоили использование itertools. Как выбрать одного из них на вакансию? Ну например, можно взять того, кто в дополнение к itertools знает про О-нотацию. Можно еще по цвету глаз или галстука выбирать (я про такое в том же Гугле слышал). Вам что лучше, угадать цвет галстука (удачи) или за 15 минут прочитать статью на вики про О-нотацию?
sumanai
Как по мне, лучше завести гитхаб и порешать задачки хоть с того же литкода, нежели чем пытаться проскочить на позицию, для которой у меня не хватает знаний, чтобы потом с треском пролететь на испытательном сроке.
mdevaev
Я комментарием выше достаточно емко показал, что ваш поинт — абсурд, но вы проигнорировали. Ясно-понятно.
ABBAPOH
Вы привели пример, когда от «инженера» требуется, скажем, умение крутить гайки. Я не инженер, но гайки крутить умею. Как понять, что я инженер, а не токарь Вася с завода? Мы оба умеем крутить гайки.
Вы описали какие-то абстрактные требования, вопрос-то в том — КАК понять, что кандидат ими обладает? Я встречал кучу кандидатов (в тч когда побеседовал работников Яндекса в других конторах), которые молоть языком горазды — и расскажут как они сделали «конечный продукт поддерживаемым и простым в расширении» и что у них есть «умение видеть необходимость оптимизации, когда нужно делать что-то новое», но вот беда — hello world написать не могут. Как отсеять болтунов?
mdevaev
> от «инженера» требуется, скажем, умение крутить гайки.
Вы точно понимаете, что именно делает инженер? Подсказка: он не крутит гайки. Ну, может, крутит немного, но разве что на прототипе.
> Как понять, что я инженер, а не токарь Вася с завода?
Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше. Конечно, это будет проблемой, если вы сами плаваете в теме. Тогда да, задачки с литкода — ваш выбор.
> молоть языком горазды
Как отсеять болтуна-физика, прикидывающегося инженером?
ABBAPOH
> Пообщайтесь по предметной области, коснитесь углубленно каких-то тем, попросите показать, над чем он работал раньше
Ну вот я общался с кандидатами — красиво стелят, якобы делали то, сё, пятое, десятое, а hello world написать не могут. Что с такими делать? Поверить на слово что он реально это делал? Тогда почему не может hello world написать? Или включить презумпцию виновности и решить что он балабол и просто сидел на зарплате глядя как другие вот это все описанное делают, а сам JSONы два года перекладывал?
> Как отсеять болтуна-физика, прикидывающегося инженером?
Я не знаю, вы мне скажите=) Для программистов вот есть задачки с литкода — если человек потратил недельку на подготовку к собесу, он их решит. Если не потратил — то точно ли он хочет новую работу или просто так с улицы зашел? Как быть для инженеров — хз, не моя тематика.
mdevaev
> Как быть для инженеров — хз, не моя тематика
Программист — это в первую очередь инженер (как инженер-механик). Есть программисты-ученые (это как физики), которые занимаются computer science. Написание продакшн-кода — это почти несвязанный с этим процесс. Но многие этого не понимают и продолжают нанимать физиков для проектирования трансмиссий.
Если вы не можете отличить балабола от опытного специалиста — вы плохой собеседующий. Если пытаетесь сделать это с помощью литкода — вдвойне. Потому что литкод не показывает умения проектировать архитектуру, не показывает умения грамотно структурировать проект и декомпозировать задачу. Литкод — это алгоритмическое задротство.
Вы — не гугл. Вы не можете пользоваться этой методикой. Гугл ее использует, потому что богат и может себе позволить найти задротов, нанять их, а потом спустя год работы отсеять тех, кто не имеет инженерных навыков. Вы за год работы этих самородков потеряете деньги и получите малоподдерживаемое глючное дерьмо в продакшне.
keydet
Всё же механика часть физики.
mafia8
Как хорошие собеседующие отличают опытного специалиста от специалиста разговорного жанра?
mdevaev
А раньше как отличали? Беседой. И никто не умирал при этом, и кандидаты успешно находились. Как же это как, интересно? Потому что это было собеседование, а не вступительный экзамен, как сейчас. Но да, собеседование в таком режиме требует от интервьювера соответствующих навыков и опыта, а не сравнивания ответов задач.
Areso
Посмотреть гитхаб? У некоторых там вполне красноречивые доказательства, почему их (не) надо брать на работу.
Nalivai
Я тот самый человек, который стелит, делает и пишет, но на собеседовании не может hello world. Вот такое у меня свойство организма, я предполагаю что глубокая травма экзаменами в институтах. За 15 лет опыта я прошел сотни собеседований, могу довольно складно рассказывать о прошлых проектах и достижениях, честно рассказывать, без вранья, но как только начинается разговор о том чтобы под строгим взглядом
экзаменаторасобеседующего деревья разворачивать и списки склеивать, я тут-же выключаюсь, мямлю, в голове включается гифка с обезьянкой с литаврами, и я не могу вспомнить как правильно переменные объявлять. Вот так вот я устроен, если дать мне проблему, комп в темном углу, и отстать, я напишу работающий код. Если встать у меня за плечом и смотреть, я напишу ровным счетом ничего. И я такой не один, нас таких достаточно много.PsyHaSTe
В абсолютных цифрах — возможно. А в потоке людей — очень и очень мало. Ну представьте себе что человек проходит какие-нибудь 3-недельные курсы на ютубе, его научили правильно отвечать на "что такое солид" и какие-нибудь киты ООП, но он реально не программист, а какой-нибудь дворник который попал на таргетированную рекламу "заработай 100500 на ~~джойказино ~~яндексе".
И вот на одного такого вас 19 вот таких фот "типа программистов".
Если в маленькой компании с вами могут нормально поговорить по душам и распознать одно от другого (это не трудно, если уделить достаточно времени) — то в компании "на потоке" кроме как собсвтенно попросить кодить это не проверить.
Nalivai
А у вас есть источник этой статистики? А то у меня вот опыт исключительно личный, и за 15 лет опыта работы в различных больших и маленьких компаниях, проведения и прохождения собеседований, тех кого вы описываете видел только на джун вакансиях (куда им, собственно, и место), а вот таких как я навидался до черта.
А вот ужастиков через третьи руки слышал, да, вот только ни разу не видел подтверждений, сколько не спрашивал
PsyHaSTe
Увы, тоже пример личный. Один человек вообще себя искренне называл "Аватар тестирования" (я иногда принимаю участие в собеседовании QA, рассказываю про архитектуру и прочие вопросы по компании с точки зрения разработки).
Есть и другие истории, но их пожалуй приберегу, не все из них хочется в паблик писать, мало ли увидят и обидятся.
strannik_k
Я заметил, что у меня курса с 3-го — 4-го тоже появилась такая проблема. Хотя в школе без проблем решал на доске различные задачи. К счастью хороших предложений сейчас много. Можно позволить себе отсеять компании с кодингом на интервью.
Psychosynthesis
+1 почти ровно такая же ситуация. Путаю синтаксис for в php и js, просто потому, что IDE сама подставляет нужный уже когда напечатаешь «for», остаётся только нужные имена переменных подставить, в результате код на собесе может не заработать тупо потому что где-то поставил запятую вместо точки-запятой.
sumanai
Так он же абсолютно одинаковый, кроме требования знака $ в PHP. Вы с forEach не путаете?
Psychosynthesis
Да, скорее с forEach, вы правы
zuko3d
Эти собеседования нужны как раз для отсечения людей, которые мало того, что не привыкли работать с оглядкой на миллионы запросов в секунду (потому что «ну сколько реально запросов может быть-то?»), но и не понимают, что иногда размер данных больше, чем цифр в их номере телефона. А, ну и забыл мантру: «стандартная библиотека реализована эффективно, её можно использовать в любых высоконагруженных системах» (нет)
botyaslonim
Это очень-очень плохой подход — сразу видеть квадратичную сложность и, имея ввиду лёгкий фикс, всё равно уповать на «может быть срастётся»
RedQuark
Вот тут человек тоже плюс минус того же разлива и количества задачи решал часами на пролет, на стажера… Мне кажется им все равно какая позиция, главное с хорошим человеком порешать задачки! -)
Jesting
Последняя задача прям детская по градации литкода (который тебе не зря посоветовали)
u007
А у этой задачи есть решение, кроме полного перебора?
wataru
Если числа не очень большие по модулю — то динамическое программирование, как в задаче о рюкзаке. Будет решение за O(n*M), где M — сумма всех чисел по модулю.
Если числа — любые инты, то только перебор.
wataru
А вообще, я невнимательно прочитал задачу. Там надо не подмножество чисел взять, а отрезок из массива. Решается за линию. Идем по массиву считая частичную сумму (до начала). Поддерживаем хешмап уже известных сумм. Смотрим, есть ли там target-<текушая сумма>. Если есть — мы нашли отрезок. Потом кладем текущую сумму в мап.
u007
В смысле, все частичные суммы до начала? Для третьего элемента, например, это 3, 3+2, 3+2+1, затем для четвёртого 4, 4+3, 4+3+2, 4+3+2+1 и так далее? Не врубился) Есть HR-ы в треде?)
wataru
Нет, просто частичные суммы. От начала до текущего элемента.
Основная идея решения: сумма на отрезке — это разность двух частичных сумм. Поэтому если для каждой частичной суммы достаточно проверить, что левее есть нужная частичная сумма.
Вот набросок кода:
Можно избавиться от одного случая, если изначально впихнуть в map {0, -1}, но понятнее без этого, мне кажется.
u007
Да, действительно просто) Спасибо.
Jesting
Конечно через хештаблицы.
Вот в псевдокоде:
Сложность O(n)
int[] nums = {1,-2,4,8,....whatever}
hashtable(int) h;
int target = 9;
for(I: nums)
if(h.contains(9-i))
{
print «решение = », 9-i, I;
}
else
map.insert(i)
итерируемся по массиву заданных чисел.
если в хештабле есть искомое-текущее значение итератора, значит решение найдено, иначе кладем текущее в таблицу и итерируемся дальше
wataru
Ну это у вас только 2 числа же. А в задаче нужно несколько.
Jesting
Все равно есть решение. Советую литкод — там это в разделе задач с мид-сложностью.
wataru
Спасибо за совет, я и без него справился.
sibvic
У меня аналогичный опыт. Было 5 или 6 собеседований, после которых, я окончательно потерял интерес к собеседованиям в Яндексе. Правда, есть и отличия:
— один из рекрутеров пользовался компилятором. Просто я что-то нестандартное написал, и без прогона через тесты сложно было понять, во всех ли случаях будет работать.
— на последнем интервью вообще вышло разногласие. Я опять попытался изобрести свой алговелосипед (но не успел), и мнение по поводу работоспособности такого алгоритма у нас с рекрутером разделились. :)
P.S. leetcode крут. Иногда хожу туда за интересными задачками
divanikus
Та же фигня, собеседований 9 прошел, на последних (кстати уже не алгоритмических) уже просто отвечал на отъебись, потому что надоело.
Kwisatz
Знаете что самое забавное, когда кажды йраз читаю про алгоритмы и сложности, а потом берусь за какой нить direct.api и через неделю кидаю пяток багрепортов, в которых суть примерно такова «выша песочница не работает, совсем, вообще» и жду полгода пока они ее починят, а манипулировать деньгами клиентво мне предлагается прямо наживую, агаа…
ЗЫ ну если им по ставке 200к так не жалко своего и кандидата времени, видимо нужно просить 400 с порога
un1t
У них часто элементарно форма обратной связи не работает.
Видимо чуваки, бодро решающие алгоритмические задачки, не в состоянии написать форму обратной связи.
Kwisatz
Она не часто, она почти всегда не работает. Я перестал им что либо писать по этой причине. Ее найти еще часто — целый квест. А еще у них очень часто на этой форме при выборе пунктов такие жуткие тормоза и ошибки, что до кнопки отправить вообще не добраться. Я даже квест как то проходил, победить форму чтобы зарепортить форму, час угрохал но цели не достиг.
Viceroyalty
Им некогда чинить форму обратной связи им библиотеки алгоритмов переписывать надо.
worldmind
Им не интересно, надо алгоритмы изобретать
Namynnuz
Или КиноПоиск HD, который абсолютно безобразно работает на Playstation и тупо отсутствует на Xbox (собирайте подписи, угу). И ладно было бы какое-то ядро сильных алгоритмистов, которые бы писали им внутренний API для инфраструктуры. Так нет же, ищут таких же оторванных от реальности олимпиадников для решения проблем бизнеса. Особенно это явственно при работе с фронтэндом (с чем пользователь и сталкивается бо?льшую часть времени).
wapmorgan
+, четырехчасовой фильм на Ps4 pro не запустился. К тому же на Android smart TV с 1гб оперативки приложение кинопоиска чаще вылетает, чем что-то показывает. Тот же YouTube работает стабильно на этом же ТВ
botyaslonim
На Я.Почте наблюдаю пару ярких багов уже лет 5. Ничего не происходит, никто не чешется
Am0ralist
А что, у них где-то ТП работает и фиксирует проблемы и ошибки?
Никогда не замечал. Вот когда на хабре на кого наедешь, то да, поправят. Причем таким способом, что фейспалм вызывает…
Ожидаешь: улучшение сервисов.
Реальность: вырезают функционал, чтоб пользователи не могли возмущаться, что он работает хреново.
sumanai
Наедьте кто-нибудь, а то уже год наверное в списке самых просматриваемых статей последним пунктом чушь идёт. Как и в остальных похожих блоках.
Am0ralist
Зная, как решают задачи в яндексе, там либо останутся только эти статьи, либо их назовут как-нибудь иначе.
PS. а что, разве всякую чушь не больше всего просматривают?
sumanai
Я про Хабр вообще-то.
Am0ralist
Ну там человек вроде про яндекс, так что я с ним про это и говорил.
А про хабр — я уже устал, мне и те с полдесятка изменений, что я продавил, попили слишком много крови и нервов, а с учетом, что они уже отказываются отвечать даже на прямые вопросы… я уже реально подумываю уменьшить хабр на 20к комментариев, чтоб под старым статьями остались лишь бессмысленные разговоры с пустотой ещё у 20к комментариев.
sumanai
Вот кстати да, болтовня с НЛО в старых статьях тоже бесит.
tvr
Это не просто чушь, а
того кого надооплаченная чушь, сиречь джинса.Kwisatz
Да, можно достучаться. Причем они довольно вменяемые временами и потом присылают уведомления что мол починили/нет.
Am0ralist
Видимо, это только на продуктовых ТП подход к максимально токсичным псевдоответами «нам жаль, что у вас не получилось воспользоваться нашим сервисом хорошо».
И такое постоянное хамство, когда типа перекладывание проблемы на пользователя, они считают нормальным способом сгладить ситуацию с клиентом.
Kwisatz
Во первых у меня есть disclaimer под письмом. Действует магически, проверено на куче тп 8).
Во вторых писал я с действительно серьезными ошибками по их api/интерфейсам.
По более мелким типо отсутствия заливки фона в firefox, да, бесполезно.
razielvamp
Такие же наблюдения. Не понимаю где они берут специалистов с таким подходом?
Создалось мнение, что хорошие спецы попадают в большие компании будучи купленными в стартапах, а там где стартапов нет, там одни задроты-алгоритмены.
Но может это тоже работает? Нанимаешь абстрактного алгоритмена в вакууме и расширяешь необходимыми методами
Хотя, глядя на современный софт, и, даже фреймворки, разрабатываемые корпорациями, (привет гуглу и фейсбуку), которые, вообще, должны быть эталоном кода, понимаешь, что и там квалификация вайтишников на донышке.
ЗЫ опыт работы с пхп чуть больше года, уже три тикета на гитхабе aws php sdk создавал, и объяснял как им надо их баги исправлять… Мир катится в ад
mdevaev
Потому что вместо наема людей, которые решают практические задачи, компании нанимают гениальных сортирователей списков. В некоторых случаях алгоритм-мен оказывается квалифицированным, но в остальных… Нет ничего хуже кода, написанного абстрактным олимпиадником.
DrPass
Ну тут есть важный нюанс: «алгоритм-мен» всегда может решить практическую задачу. Если захочет, конечно же. Последнее — важный момент, т.к. реально бывают кадры, которым это скучно, и они просто забивают болт на работу, но тем не менее, если человек в состоянии придумать алгоритм, то как реализовать что-то на конкретном фрейморке, он даже и не зная, уж точно способен нагуглить и правильно применить.
А вот обратное — уже проблема. Если человек владеет инструментами, но алгоритмы сочинять не умеет, то он застрянет на вполне себе практических задачах вида «отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты», которые не лежат в готовом виде на SO.
rg_software
Ну возьмите одного такого на 50 человек в качестве консультанта, чего ж в этом плохого? Конечно, иногда и список развернуть надо, но с чего бы такое внимание именно на этом аспекте?
DrPass
Три собеседования на одну тему, это и правда перебор, но можно и на одном погонять по умению собственно программировать, и никто от этого не помрёт, честно говоря. Зачем брать одного и заставлять его бегать за всей командой, если можно набрать почти всю команду людей, которые умеют программировать, благо, вышеуказанные задачки когда-никогда бывают у каждого.
rg_software
Ну тут сразу два перебора получается: 1) спрашиваем три раза про одно и то же; 2) не спрашиваем больше ни о чём.
В некотором смысле каждый кулик своё болото хвалит — неудивительно, что люди, которые сильны в алгоритмах, считают, что это и есть самый важный и незаменимый навык. Но человек хорошо разбирающийся в железе или в особенностях того или иного языка/фреймворка /архитектуры тоже может доказать, что его навык самый главный. Тем более, что требования к алгоритмической задаче хорошо формализуются, и всегда можно найти если не своего, так внешнего консультанта, который это решит за лайки или за пиво.
Kwisatz
И почти по всем этим задачкам есть четкие рекомендации: не делать так, используйте стандартные средства языка.
Нужны совсем-совсем другие наыки, например, научиться использовать свое приложение. Знаете по моему сотни програмеров по миру делали рандомный лут в играх. Помню ровно одну игру с нормализацией на матожидание игрока и еще помню в диабло фикси на эту тему, все, в остальных «корейский рандом». Умные книжки на эту тему кстати есть.
FreeNickname
А не подскажете, где можно почитать про оптимизацию лута? Интересно, не слышал об этом.
ITurchenko
Например gdcuffs.com/unfr-rndm
Но в целом, это проблема постановки ТЗ со стороны геймдизайнера. Т.к. плотно сцеплено с UX, монетизацией и прочими вещами вне основной проблемной области программиста.
Kwisatz
Спасибо за ссылку, а может есть статейка о best practice с подробным техическим описанием?
ITurchenko
Тут ничем помочь не смогу. Скорее всего опять же на геймдизайнерских ресурсах.
Потому что вот это «честное распределение» — оно опирается на субъективность восприятия и геймдизайнерам приходится с коэффициентами играться, чтобы с точки зрения игрока всё было как надо (ну и чтобы киты в итоге побольше донатили, куда без этого)
Kwisatz
Я понимаю. Но кроме того, если бы я лично, в своей игре, увидел провал заточки 10 раз подряд, при шансе 75%. Я бы разработчика конкретно этой части заставил эти шмотки сутками точить, до просветления.
Нуда, кто же сейчас игры то хорошие делать будет, главноеж китовый донат, точно, я забыл)
ITurchenko
А сколько раз максимум можно? 4? А почему не 3 и не 5? :)
Kwisatz
Я бы сказал что в среднем для опыта игрока должно получаться 3. Если один игрок за свой игровой опыт многократно сталкивается с провалом 10 попыток из 10 — о каком 75% шансе вообще может идти речь?
Поймите, я понимаю проблематику, но я встречал разные реализации и оцениваю игру еще по такому показателю как «комфорт».
ardraeiss
Не для "опыта", а для "эмоциональных ожиданий". Игрок, имевший опыт бросания монетки или изучения теорвера, как раз имеет опыт что серии — это ожидаемое поведение. И если их нет — значит рандом "накручен", и ещё вопрос в какую конкретно сторону.
А вот эмоционально можно ожидать и что "5% шанс сломать не выпадет никогда, а 75% сработает точно".
Kwisatz
Все верно, и многократное 0 из 10 в это ожидание не вписывается от слова никак
ardraeiss
Да, это популярное заблуждение. С точки зрения эмоций — не вписывается. С точки зрения теорвера — это поведение рано или поздно обязано случиться. С точки зрения псевдорандомного генератора(а других не завезли) — оно случиться может.
Остаётся только делать не "честный рандом"(как того требуют эмоционирующие игрока) — а накручивать специальные "сбросы серий" и прочий мухлёж(да) чтоб эмоциональное ощущение не страдало.
Kwisatz
Все верно, иначе никак.
При наивных реализациях нюансов слишком много и комфорт игры резко падает, да что там я в некоторых играх умудрялся вычислять временной диапазон, когда ГПСЧ работает на меня (энтропии видимо не хватает).
Кстати мы с вами говорим о достаточно высоких шансах, при низких такой треш начинается…
И на эту тему есть даже примеры:
— У La2 как раз был «не честный рандом» и шанс модифицировался в зависимости от попыток, в итоге даже шансы типо 1/65000 были вполне переживемы
— У LostArk судя по всему наивная реализация, наиболее показательный пример одна из коллекций собираемая шансово с ресурсов, она оказалась далеко за пределами матожидания для 95% игроков.
JustDont
А я бы сказал, что как раз апологеты подкручиваний в итоге привели ситуацию к тому, что публика начинает жаловаться на нейтральный ГПСЧ без подкручиваний.
В играх Blizzard нейтральный ГПСЧ остался только в серии Diablo, а остальные игры крутили его так дико, что особо умные игроки даже эксплуатировали это. Или вон при создании пользовательских карт в Warcraft 3, надо было использовать формулу пересчета вероятностей, чтоб обеспечить реальное статистическое соответствие между заданным значением, например, срабатывания абилки, и шансом появления этого в реальности. Задавать значение в 50% и ожидать срабатывания в половине случаев — было крайне наивно.
А нынче при столкновениях с нейтральным ГПСЧ в играх а-ля XCOM — у солидной части публики вдруг начинает пригорать. Ну как так, промах с 99% шансом попадания? Быть такого не может (с).
Kwisatz
Низкие шансы позволяют тонко контролировать экономиу игры, ну и собственно редкие вещи должны быть редкими, но шмотка с шансом 1/100000 может и не выпасть вообще никогда, нам это не нужно. Кроме того я сам лично ходил в том же еверкест2 120 раз в данж за нужной мне шмоткой, я бы не назвал это приятным опытом. Или вон в том же лостарке сделали перенос доп эффектов на скилы с шансом, 2 уровень 30% (60 с расходкой) 4ый 0.5% — ничего более раздражающего давно не видел, особенно учитывая что это тупое и топорное решение для растягивания игры. Ну а про опыт в танках/кораблях я уже выше писал, опять же нет ничего более раздражающего чем какойто совершенно дикий разлет, не зависящий от твоего скила от слова совсем, который повторяется снова и снова.
Не было его там никогда. У D2 лут строго привязан к локациям/боссам, а у д3 при инициализации игровой сессии усекалась лут таблица, выше описывал.
А вот в том то и нюанс, выше по ссылке объяснение почему именно. Во первых нужно быть очень вниматньным к проверкам, потому что вам нужно линейное распределение. Во вторых: на какой дистанции? Никому даром не нужна игра где шмотка случайным образом падает 1 из 1000000 игроков.
Один — да ради бога, но только если он один из ста выстрелов. Но я думаю там далеко не так, раз игроки возмущаются.
Кстати у некоторых ГПСЧ на серверах я очень часто встречаю явно различимые временные интервалы в которых он ведет себя (не)предсказуемым образом. Тоже стоит учитывать откуда береться энтропия.
JustDont
Тем не менее, сам ГСПЧ нейтральный. В том же варкрафте3 именно ГСПЧ постоянно "подкручивает" свои шансы в зависимости от предыдущих результатов.
Kwisatz
А никто и не говорит что только лишь им единым. Изза того что расчет выпадения лута в д2 ведется по локальным лут-таблицам с разумным шансом, гпсч не мешает. Так же точно в еверквесте мы никогда не парились насчет лута в рейд инстах, какая к черту разница если в списке 10-16 шмоток и каждый раз падает две. Но как только мы переходим к общим лут таблицам и маленьким шансам — вот тут и начинается веселье.
Задача — сделать хорошую игру, в которую играть приятно, комфортно. Какими средствами — вам решать. Но 95% современных разработчиков не понимает что это значит, потому что в свои игры не играет.
Am0ralist
Kwisatz
За промах по цели с угловым размером меньше прицела нужно руководителя разработки пытать, причем страшно и противно.
Nalivai
XCOMовсякая пошаговая война это шорткат. В «реальности»-то персонажи это испытывают как бы в реальном времени, а в реальном времени, вчерашнему рекруту, промахнуться в упор по страшному инопланетянену, который на тебя бежит в темноте из-за угла раз плюнуть.
Или попробуйте в какой-нибудь контре из снайперки в упор стрелять, рейт будет сильно ниже 95%
Kwisatz
Потому я играл не в контру а в кваку, где из рельсы в упор ты не можешь промахнуться — никак. Я вообще таких доводов не понимаю. Я могу промах понять на 100 метрах, на 20 понять могу, но когда мне нужно специально отвернуться чтобы промахнуться — нет не понимаю уже, потому что вчерашний рекрут даже закрыв глаза все равно попадет в район противника при таких угловых размерах.
Хотите делать промаху в упор? Смотрите в сторону d&d и спасбросков, «противник схватил винтовку за ствол и отвернул ее от себя!» с шансом на определенной дистанции, не будет так бесить и заставит держать стрелков на дистанции. (хотя схватить за ствол винтовку когда палец на спусковом крючке — ну такое, но это я на вскидку)
Am0ralist
Вот в JA2 при 95% мазали действительно редко (могли не туда попасть, не в голову там, а в туловище, или чиркнуть слабее). А «вчерашний рекрут» (в икскоме оригинальном так-то ты нанимаешь вообще-то как раз «опытных» по легенде, а не с улицы) — просто будет иметь показатели ниже плинтуса и вероятности не 95 в голову, а 70 в торс и мазать больше.
Nalivai
Ну так там не 45% потому что. Это люди почему-то думают что 95% это 100%, когда это вообще-то 1 промах на 20 выстрелов. Но у нас же confirmation bias, мы неприятные промахи запоминаем, а предшествующие этому 19 попаданий нет, потому что считаем их нормой. Оттуда и идут эти разговоры.
Am0ralist
О господи, ну я вам даже дал в пример другую игру, погуглите что ли, прежде чем рассуждать.
Включите JA2 в какой-нибудь «режим железной руки» и сыграйте там.
После чего включите xcom современный с их постоянными промахами при 95% чуть ли не в упор и расскажите мне, что это игроки играть не умеют и проценты не понимают.
И да, аргумент, что пользователи тупые и не могут ничего запомнить — это круто. Не бьется с реальностью
При этом так же есть ксенонавты, где такого убожества нет.
Так что это не «люди не запоминают», это просто отмазки, что раз типа теория вероятности позволяет делать серии из промахов при 90%, то это нормально такие серии получать постоянно. Неа, тервер говорит, что если у вас 99 постоянных решек, то скорей всего проблема в монете.
А тут проблема в том, что AI туп как пробка и проигрывает AI игр конца 90-х. Поэтому кроме такого убогого «рандома» в игре сложности на самом деле нет.
JustDont
Я играл. И я по прежнему нахожу ваш confirmation bias невероятно забавным. Вполне возможно, что вы просто относитесь к "не могущим в статистику" людям.
В JA2 при использовании того оружия, которое стреляет по разу за действие — всё то же самое. Более того, движок JA2 оперирует (как и XCOM) именно процентами успеха, а не "физической моделью", из-за чего криворукий наёмник вполне мог не попасть большей частью очереди из автомата в упор.
Но именно обилие стрельбы делает JA2 на вид "более честным", чем XCOM: когда ты в ход можешь выстрелить раза 2-3 даже из снайперки, один промах тебя не особо будет беспокоить. И уж тем более тебя не будет волновать промах пары выстрелов из очереди.
В XCOM же выстрелы — это очень ценные действия, и неудивительно, что каждая ситуация с промахом 5% поджигает определенные чувствительные части тебя некоторых людей.
Am0ralist
И там проценты указываются с рассчётом на навыки и прочим, куда стрелять. Ты их видешь. Стреляешь один-два раза за ход, максимум (угу, в икскоме то тоже двух выстрелов не бывает, типа, ага-ага). И промахи на длинных дистанциях нормальны лишь при низкой вероятностью.
Очередью. Ну да. И криворукий.
Только берём спеца, то даже очередями промахи снижаются весьма сильно. И вероятность тебе будет нарисованы не 95%, не надо рассказывать сказки.
Очереди в JA2 вообще нужны редко, отмахиваться от набегающих толп если только.
Там и одиночные промахи бывают, при высокой вероятности попасть. Но это именно что несистемные случаи.
Только в искоме очередь вся улетает в молоко. У крутого спеца на близких дистанциях. И это — норма (с)
Вот тут и выплывает вся разница между нормальной реализацией игры, где сложность за счёт AI. И xcom, где сложность только псевдорандомом и тупыми заскриптованными врагами.
JustDont
Ну вот, а в XCOM меткий оперативник, достигающий шансов попадания в 100% — не мажет. Вообще никогда.
Другое дело, что у продвинутых элиенов есть всякие свойства, минусующие шансы попадания по ним.
Ну так и в XCOM нуб со базовым шансом попасть в 65% и профи — с 110% — это очень разные вещи.
Ну то есть в JA2 "несистемные", а в XCOM "системные". Понятно. Так и запишем.
Потому что очереди не моделируются. "Выстрел" в терминах механики XCOM всегда один, а как он там анимируется — дело десятое.
Но претензии к условностям механики пошагового боя меня очень забавляют. Это пошаговый бой, уже дикая условность, которая абсолютно никак не натягивается на реальность. И при этом вас беспокоит отсутствие честной симуляции очередей? Ну-ну.
Это как придти жаловаться шахматистам, что ладья как-то нереалистично ходит.
Am0ralist
разговор про 95%, хватит пытаться уводить в сторону.
Есть заявленная цифра. Она не выполняется.
В джа скорее выполняется.
Вы в очередной раз подменяете.
Говорится о вероятности попадания. Она заявлена 95% для конкретных выстрелов. Вот стоит группа и стреляет по одному. Все имеют большие шансы попасть, все промахиваются.
Тоже самое в JA2, так же заявляется 95%.
Только это разные вероятности попадания. Во-втором случае ты действительно чаще всего попадёшь.
В шахматах вероятность попадания 100%.
Всегда.
Вся претензия, повторюсь, крутится не вокруг существования промахов.
А вокруг нарисованных процентов попадания. Они — ложные.
Но вы целый коммент настрочили, в котором раз за разом пытаетесь увести в сторону от обсуждения «заявленных процентов попадания» и реальных.
Если б там были 50% написаны, как в JA2 у криворукого наемника очередью из автомата на дальнем расстоянии, вопрос бы так не стоял.
JustDont
Эм. В XCOM:EU и XCOM2 шансы попадания не ограничены сверху. Там нет потолка в 95%.
Пруфы? Давайте начнем хотя бы с 4 5% промахов в ряд — это целых 0.000625% шансов, вполне вероятно, что среди всех сыграных партиий в XCOM за всё время такая ситуация возникала, и кто-то выложил её в интернет, а то и может быть даже и не одну. Если же у вас "всё реализовано неправильно", то таких ситуаций должно быть по-вашему — сколько? Тысячи? Десятки тысяч? Короче, выложить сюда хотя бы пару дюжин не должно составить для вас никакого труда.
Am0ralist
Три подряд в упор по пробегающему
JustDont
О, люблю предметный разговор!
Итак:
Видео №1: нубы или около того (средняя базовая меткость: 65%) стреляют в овервотче (x0.7 от финального шанса попасть) по солдату в half-cover (-20%, многие думают, что в overwatch бонусы от укрытия не применяются, но это не так) в упор из винтовок (+19-20%). Это если конечно там модами что-нибудь из этого не переделано.
Итого у каждого шанс попасть — около 45%. Три раза подряд промахнуться — ~16%.
Видео №2:
Ну да, это full cover. В ванильке нет никаких бонусов за "частичный" фланг. Плюс, судя по времени видео, это совсем ванилька, с её приятной механикой критов (это когда при, допустим 15% шансах попасть и 15% крита любое попадание становилось критом). Потом эту механику переделали в WoTC, кстати.
Видео №3:
В XCOM:EU отображаемые шансы попадания псионикой всегда жили своей жизнью. Это баг, который долго и мучительно устраняли из Long War, я c этой историей лично сталкивался. А в ванильке его никто не чинил, по-моему.
Видео №4:
Ну и что такого? Это вероятности в районе 0.1% (а не 0.000625%, как я вам предложил найти), с учётом объемов сыграных игр таких видосиков легко могут быть сотни.
Видео №5:
Ничего необычного, классическая нубоошибка на гейткрашере — сидеть в half-cover, которое дает всего лишь -20% и надеяться на овервотч, который х0.7 к финальному шансу попадания и в силу этого даже с крыши работает так себе. И да, я нахожу панику в ванилле XCOM2 реализованной невероятно тупо, это про дальнейшее.
Люди в среднем не могут в статистику, ага.
Было бы наоборот удивительно, если б при популярности XCOM таких мемасиков бы не было.
JustDont
И да, я тоже нахожу симуляцию тактического боя в джаге — гораздо более цельной и приятной, чем в XCOM:EU и особенно в XCOM2.
(AI там нисколько не лучше, но именно с точки зрения отсутствия странных правил и формул всё намного лучше)
Просто это всё ортогонально честности ГПСЧ. Рандом абсолютно честный и там и здесь. Вернее, в XCOM он нечестен (на легких сложностях) как максимум в пользу игрока, и никогда наоборот.
PsyHaSTe
Нет, тервер говорит что монета не имеет памяти, а 90% попадание означает что каждый 10й будет промах. Но если люди попадали с 90% вероятность 100 раз подряд а 101-110 промахивались — они побегут доказывать что игра сломана и подставляет их чтобы они не могли выиграть. Хотя зачем разработчикам это делать — непонятно. Видимо чтобы всех побесить побольше
Am0ralist
Тем, что у них AI врагов отсутствует как класс. В JA2 неубитый/невырубленный враг вызывает подкрепление и старается скрыться, на тебя облава начинается, когда на твоих 5 наемников человек 20 бежит, а в случае чего ещё и из соседнего района может подкрепление подойти. И в зависимости от цвета противников тебе могут не зеленые косящие юнцы встретиться, а черные спецы, у которых и меткость, и стволы хорошие, так что отряд твой вырежут на раз.
Тут же пришельцы в прямой видимости только реагируют на нападение на них, пока не вскрыл новых на карте, те ничего не делают и никак не реагируют, хоть полкарты разнеси.
То есть при балансе, как в JA2 с таким AI игра б вообще была убогой.
Но при этом нарисовать процентов меньше и убрать откровенную тупость с промахами вблизи (угу, из очереди с пулемёта) — не, это слишком сложна…
PsyHaSTe
Она не ноль — вот и все.
Для этого можно было бы ограничить абсолютную точность для людей в 70% например а не врать что она 95.
Пока что все "пруфы" что я видел — от непонимания теорвера. У людей если монетка 10 раз орлом падает — это невозможно и монетка кривая. Все же знают забавную задачку на подбросить монетку и потом записать результаты бросков на бумажку — хороший профессор теорвера всегда знает какой студент правда бросал, а какой просто от балды написал "типа случайные броски".
Am0ralist
Можно. Но сделали так.
Там циферка в кружочке никак не связана с тем, что внутри творилось, возможно вообще разные люди делали.
И да, моды делались потом, которые правили сие.
А когда у разных людей подобное встречается периодически?
И да, вы говорите про 1к1, а тут 19к1. Давайте вероятность выпадения 1 на кубике D20 10 раз подряд посчитаем?
Viceroyalty
Не знаю, вот в RF Online зависело от загруженности серверов — рано утром точится, вечером сгорает, в среднем по больнице нужные проценты, но о каком случайном распределении тут можно говорить?
Если хотите генератор псевдослучайных чисел близкий к идеальному нужно использовать криптографические оценки «случайности» последовательностей.
Kwisatz
Это не только в рф это много где так. Вы думаете средний разработчик в курсе как выглядит энтропия у рандомизатора под капотом? Да я думаю слов они не знают таких. И, по сути, они не виноваты, им просто нужен талантливый, умный, увлеченный руководитель.
Viceroyalty
Просто как seed нужно использовать младшие разряды нагрузки, а не старшие.
Да, я думал это все в институте проходят.
Kwisatz
Или генератор белого шума, и не забывать про нормальное распределение.
Ну я в институте не проходил, но это никак не мешает литературу читать. Хотя о чем мы, сейчас расплодилось аналитиков/пм как грязи, вот только от первых я регулярно вижу блоки условий с кучей веток и отсутсвием внятного описания сравнений, а вторые почтив се тупо играют в передастов. Профильную литературу никто даже не пытается изучать.
Viceroyalty
Программный генератор белого шума нужно еще оценить по критериям «случайности», и, кстати, распределение не обязательно должно быть нормальным — тут уж как гейм дизайнер видит.
Новые менеджеры это боль — модно стало считать, что менеджеру/руководителю не нужно понимать предметную область. Рука-лицо.
Kwisatz
Зачем программный? Вроде в современных процессорах есть аппаратный.
С нормальным распределением все проверки должны его учитывать, иначе вы вероятность сосем не ту получите какую планировали.
Вот тото и оно, почему то вдруг все решили что могут руководить чем угодно. Теперь модные термины «цифровизация», «гипотезы», «верхний уровень» и прочий булшит. А на самом деле как пытались перестроить сарай в международный аэропорт, так оно все и осталось.
Viceroyalty
Отстал я от жизни, ИБ давноо не занимался.
Ну почему-же может у вас изначально была идея с распределением Пуассона, мы же не знаем, что у вас за игра, может всего за cегодня должно быть столько-то событий. Хотя от современных гейм-дизайнеров вы такого ТЗ не дождетесь.
ITurchenko
Тут еще проблема в чём — если сделать неаккуратно, открывается широкое поле для багоюза.
Например точим дешевые палки-копалки пока 3 раза подряд не сломается, а потом затачиваем мифрильные трусы +8. Ура, мы порушили экономику.
Значит придется более сложные данные хранить и мы только что на ровном месте усложнили всю систему. А глобальный беспристрастный рандом такой проблемы иметь не будет :)
Kwisatz
Да ладно вам чего мы там усложнили, у многих игр итак есть 100% ная заточка после Н попыток, прям с отображением игроку.
Am0ralist
ITurchenko
При заточке предмет ломается. Так что когда 10 раз подряд фейлится 75% шанс — ломается 10 разных (одного типа) предметов.
Значит для каждого игрока придется заводить записи в БД: «неудачных заточек медных мечей», "«неудачных заточек железных мечей» и т.п.
Ну чтобы когда у него 7й медный меч сломается на 8й раз точно получилось, но при этом он не мог мифрильный меч проточить с 100% гарантией.
Am0ralist
Ну трусы просто будут с 35% шансом и заново отсчёт пойдёт.
Просто когда из нескольки десятков попыток у тебя с 75% шансом в >50% случаев молоко и ты вообще не попал в врага и такое на каждой миссии, то всё таки проблема в генераторе рандомов.
А если при 95% у тебя каждый 4-й — промах (ладно бы хоть слабое попадание), то вопросов вообще не остаётся.
Kwisatz
Это у вас не остается, а гемдизайнеру среднему даже объяснить нереально что тут не так. Знаете как я тролю молодых прогрессивных «геймдизайнеров»? Спрашиваю про равномерность шкалы хп в action играх и наслаждаюсь. Дада, они правда не в курсе этих приемов.
Kwisatz
В моем примере нет, не ломается. Вообще механика слома все реже появляется нынче.
Просто в LostArk есть тн «фетранит» который как раз «точится» красиво так, в рядочек, с уменьшением шанса на каждую попытку и сам я встречал и у знакомых и у стримеров можно найти где заходишь и так ррраз всю полосочку зафейлил.
Kwisatz
Оох, сходу не скажу, я когда эмулятор сервера l2 лет 15 назад писал, много литературы перечитал и оказалось что очень многое уже изучено и описано, с тех пор почитываю но у меня память на названия такая себе.
Попробую найти, если получиться — кину, но не гарантирую. А вообще я пря мотчетливо помню, что была статья по лут в d3. Там был интересный нюанс, что разработчики при инициализации игровой сессии усекали лут-таблицу и соответственно вышло так, что если тебе не повезло и твоя шмотка не в списке этой сесии то ты можешь хоть запроходится рифты, шмотка нужная тебе просто не упадет. Это стало совсем очевидным когда за осколи стало можно конкретную часть доспеха покупать, вот тут то и выпустили фикс, насколько я помню фиксом была периодическая реинициализация лут-таблиц в рамках игровой сессии.
Вообще я бы с удовольствием почитал сам о наилучших практиках работы с ГПСЧ. Мало кто вообще об этом задумывается, но ГПСЧ подбирать нужно под конкретные цели. Самый яркий пример: отреверсил в одной игрульке как раз такую проверку и прогнал 100 симуляций на матожидании игрока (ну пусть будет 100 попыток), выяснилось что фактический шанс в 10 раз ниже заявленного, хотя по коду это совсем не очевидно.
В этом плане меня варгейминг веселят «вот посмотрите, мы сделали 100 выстрелов на нашем тестовом контролируемом сервере, 80% как и заявлено попадает в круг.» Вот только мишень плоская и вертикальная, сервер тестовый, а количество выстрелов сильно завышено. Я что в танках что в кораблях попадал в игры где в течении игры _каждый_ выстрел летит куда попало. Да можно сказать что шансы все такое и «неповезло» но когда вы разрабатываете игры вы должны такие вещи находить и устранять, поскольку нет ничего более раздражающего и демотивирующего.
Kwisatz
Вот по рандом из мира доты
mSnus
Интересно было бы почитать про рандом из мира CS. Такое ощущение, что там коэффициент удачливости устанавливался на запуске игры, потому что было проще перезапустить CS, чем мучиться с не попадающими никуда пулями))
SAWER
Контра же? Пули летят по 2 параметрам, условно, отдаче и разбросу. Отдача — алгоритм смещения без рандома, зависит от непрерывности огня и вида оружия(глушителя). Делится на 2 части, одна — просто кривой подъём вверх, вторая — особенности смещения оружия.
Разброс относительно точки последнего выстрела с поправкой отдачи, рандомный, обычно на много меньше отдачи. Зависит от движения и положения, непрерывности огня, вида оружия, глушителя. Последний обычно на много меньше отдачи, возможно раз в 10, возможные исключения — пулемёт, снайперка без прицела.
Вообще, в CS норма — минимально зависеть от рандома, отдачу контролировать заранее(смещать прицел вниз ~ по траектории отдачи), и даже разброс. Последнее вполне контролируется, т.к. следующий выстрел не заново рассчитывается в большом радиусе, а идёт относительно предыдущего в довольно маленьком радиусе.
PS: всё это отличается от версии, хотя база +- похожа. Потому и не люблю CS — повторение одной и той же механики как путь к победе.
mSnus
Это да, но мне сложно иначе объяснить, что я проигрываю раунд за раундом — перезапускаю CS и начинаю выигрывать так же стабильно. Возможно, какой-то сетевой лаг меняется, но больше похоже, что именно "удачливость" меняется.
Kwisatz
Я кстати бросил играть в CS еще на заре его становления ка краз потому, что мы в клубах научились стрелять в голову из АК зная точку прицела под ногами и размер нужной очереди. Очень утомляет такая механика, потому я квакер)
amateur2018
был в солнечном 19-м году в яндексе на собесе по java, было 4 секции — алгоритмы, структуры данных
технологии -sql, networks etc
java core (multithreading, core libraries)
интервью с менеджером и командой
впечатление субъективно такое — спрашивают по технической части по делу, вопросы интересные и полезные для саморазвития, но достаточно тяжело — где-то 4 часа это длится, и мутные параметры найма, видимо все же они ищут звезд, готовых на переработки и не очень задорого (за бренд Яндекс в трудовой), насколько знаю у них зп остает от рынка
zagayevskiy
В Яндексе кроме зп ещё программа поощрения RSU, и значительная часть дохода идет от их вестинга.
amateur2018
Где-то слышал/читал, что опционы получает небольшая часть сотрудников ~17%, возможно самые выдающиеся, например здесь https://www.vedomosti.ru/technology/articles/2015/04/02/yandeks-predlagaet-sotrudnikam-otvyazat-optsioni-ot-kapitalizatsii-kompanii
Или есть другая инфа?
zagayevskiy
инфа от 2015 года. с тех опционную программу значительно расширили, сейчас опционы может получить сотрудник от 15 грейда. для разработчиков это выше джуна. Джуны имеют 14 грейд.
wataru
И что, этот один будет весь код в компании ревьювить и искать, где разработчик не заметил алгоритмическую задачу?
Если же этих алгоритмистов нанимать несколько, то дешевле всех остальных уволить и пусть алгоритм-мены все сами и пишут.
rg_software
Ну это называется straw man: я вот, положим не олимпиадник, но уж «не заметить алгоритмическую задачу» — это удел тех, кто ни разу книгу Кормена (или аналог) не открывал и вообще «в танке». Таких брать, конечно, незачем, но для навыка «заметить задачу» планка не столь уж и высока, таким людям по-хорошему даже диплом бакалавра соответствующей специальности не должен был быть выдан.
wataru
Ну "алгоритмическая" задача ничем особо не отличается от обычной! Вот надо вам, допустим, найти одинаковые элементы в двух наборах данных. И тут человек не натасканный на эти задачки с интервью вполне может использовать 2 списка и проверять на вхождение через стандартную библиотечную операцию, получая O(n^2). Возникнет ли у него тут позыв послать эту часть алгоритм-мену? Казалось бы все тупо. Надо взять элементы из первого набора, которые есть во втором. Так и сделано.
rg_software
Ну так любой человек, хоть раз открывавший Кормена (или аналог) знает, что O(N^2) в общем случае получаться не должно — и тут либо он напоролся на известный алгоритм вот с такой сложностью, и тогда страдать, или что-то он действительно делает не так. И понимание «не так» уже тогда должно как-то звякнуть в голове, и придётся попросить помощи, если он сам не понимает, как решить задачу.
Наверно, я идеализирую «среднего» человека, и у слишком многих в голове ничего не звякнет, но всё же по моим понятиям такое «звяканье» — это на порядок менее жёсткое требование, чем быть реальным алгоритмистом. Ну опять-таки, разве хоть кто-то в здравом уме будет против того, чтобы люди умели писать алгоритмы и вообще думать головой? Тут же весь дискурс исключительно в контексте того, что этому умению придаётся 100% важность, а остальному 0%, как будто бы его не существует. Если завтра по каким-то причинам во главе яндекса окажутся знатоки математики, то точно так же будут собеседовать, спрашивая умения брать интегралы в уме или решать задачи трёхмерной геометрии. Ведь понятно, что если человек не может взять интеграл, то он в целом безнадёжен, можно дальше не смотреть. А если может, остальному тоже научится.
wataru
Ну хорошо, допустим эти звоночки происходят практически во всех нужных случаях. Тогда неизбежно false positive. Все равно наличие выделенных алгоритм-менов сильно усложняет работу. Они будут завалены заявками. Имея гугловую поток кандидатов гораздо легче тупо нанимать только алгоритм-менов.
rg_software
Ну мы же обсуждаем некую карикатурную картину, когда наш кодер настолько непроходимо тёмен, что неспособен взять книжку с полочки и скопировать классический алгоритм к себе в программу. С тем же успехом тогда надо представлять себе карикатурного «алгоритмена», который ни в зуб ногой в архитектуре, и потом надо ещё иметь специально обученного человека на него для постоянного рефакторинга, ну и поскольку он в фрейморках/проч. тоже ни в зуб ногой, то в основном он сидит и курит мануалы, вот так и день проходит.
Но это, конечно, так, вырожденный пример, в идеале, конечно, на каком-то уровне надо уметь всякое разное, как мне кажется.
wataru
И… такой человек как раз есть практически везде. Называется архитектор, technical lead, или еще как-то.
Разность в том, что задачки, "алгоритмические" или нет, постоянно решает любой, кто пишет код. Любой код — это алгоритм. Любые данные — это структура данных. Очень часто тривиальные, да.
Когда надо составить SQL запрос — тут, очевидно, нужен специалист по SQL, можно спросить его. Когда надо придумать, как организовать новый модуль, то очевидно, что это архитектура проекта — надо спросить архитектора.
А когда надо писать код, очевидно, надо спросить алгоритм-мена в команде. s/
Конечно, в идеале все в команде специалисты во всех областях. Но это слишком дорого держать такую команду, да и тогда надо 100500 собеседований проводить и не наберешь столько работников, даже с гугловым потоком кандидатов.
anton0xf
Вообще-то SQL обычно пишут все. И никаких отдельных специалистов по нему нет. В том же Я у меня была секция с вопросами про SQL, когда я устраивался.
Areso
Включая фронтов?
К тому же, бэкендеры/фуллстеки на SQL чистом тоже уже довольно давно не пишут — сегодня это всё чаще ORM, который и будет генерировать некую лапшу запроса.
baldr
Эмм, вы тут поосторожнее с такими заявлениями. Если человек работает с ORM, то лучше бы ему знать во что запрос превратится.
Ну давайте еще до уборщиков дойдем с примерами. Статья вообще про бэкенд и Django. Да и фронтенд сейчас тоже может запросы делать иногда — graphQL и тп.
Areso
Чтобы это знать, надо знать как работает конкретный ORM.
Итого, получается, надо проверять эти моменты:
1) человек умеет пользоваться ORM
2) знает, как он устроен и как он делает трансляцию из модели в запрос
3) знает, как работают SQL запросы
4) и умеет их писать, на случай, если ORM'a нет.
baldr
Отлично. Я согласен 100% с этим. Но вы мне возразили или согласились?
С тем же Django постоянно приходится залезать внутрь и смотреть как он там это все делает. Каждый запрос надо знать как выполняется, не забывать про транзакции и тп.
Areso
Согласился или возразил зависит от того, кого мы нанимаем, на какой участок работы и за какие деньги.
Если у нас вакансия Django dev'a уровня junior'a — достаточно 1 и, желательно, 4. По мере роста — 2 и, желательно, 3.
Почему так? Потому что за 3 отдельные люди получают кучу денег. Не считаю, что рядовой разработчик должен уметь это, да еще и хорошо уметь. К тому же, учитывая что СУБД у нас больше 1 (MS SQL, Oracle, MySQL, PostgreSQL).
baldr
Опять же — согласен полностью.
Меня смутило то, что вы ворвались в тред где идет битва на тему "знаешь алгоритмы — SQL знать не надо, все поймешь и так".
anton0xf
Прошу прощения. Конечно, я имел в виду "все бэкендеры". А писать SQL, HQL или Criteria собирать — это уже дело десятое. Один фиг, если тормозить будет, то придётся посмотреть, какой SQL генерируется и какой у него план выполнения.
mrbald
А потом frontend девелопер генерит себе backend JHipster-ом и захреначивает динамический lazy scrolling (тот который SELECT по rownum) и один юзер с мышкой вешает и backend и базу простым движением руки.
wadeg
Вот после того, как sql-запросы попишут все, и приходит четкое до звона понимание, что специалиста надо было брать сразу, а не когда уже пришла катастрофа.
anton0xf
Ситуация в Яндексе, кстати местами именно такое впечатление и производит. Все умеют проходить алгоритмические секции, а практически любое решение переделывают каждые несколько лет, т.к. оказалось, что архитектура достаточно жёсткая, чтобы проще было с нуля переписать. Или под конец моей там работы был случай, когда ради оптимизации в одном из компонентов решили кардинально поменять его АПИ, чем вынудили всех клиентов этого компонента переписывать довольно много кода. И ни у кого ничего не "звякнуло" ведь. Хотя теоретически, если есть сомнения по архитектуре, то можно сходить на специальный "Архитектурный комитет" и там её обсудить. Просто сомнений обычно нет, да и "зачем время тратить?" — лучше потом два раза переделать)
kalombo
Вот на чем такие утверждения основаны интересно. Типа я вот щас пошел, посидел три месяца на leetcode и вуаля я готовый сеньор-помидор и знания об архитектуре, базам данных, паттернах программированиях и еще 20+ навыков необходимых для современной разработки у меня автоматически вмонтировались в голову?
Мне это напоминает мем, про то как писатель написал, что занавески синие, а все думают и гадают, что же он имел в виду, может он хотел символизировать тоску и деперессию? Хотя на самом деле ничего кроме того, что занавески были «синие». Так и с яндексом. Ввели они эти собеседования, потому что по ним можно прозрачно оценить прошел ли интервьювер собеседование или нет. Решил задачу лучшим решением, без ошибок написал код — прошел. Нет — не прошел, а то, что к реальному миру эта задача имеет отношение чуть более чем косвенное, ну лучше пока не придумали. А все вокруг бегают и строят теории: да эти задачи показывают как программист мыслит, да яндексу нужны алгоритмисты, да алгоритмисты могут решать любые задачи. Увы нет, всё гораздо проще.
DrPass
Типа вот нет. Этого я не утверждал. Одних алгоритмов, естественно, недостаточно для того, чтобы понять набор скиллов кандидата. Не надо искать скрытый смысл в моих словах, там написано ровно то, что я имел в виду: что человек, умеющий составлять алгоритмы, всегда может работать программистом при желании. Человек, не умеющий их составлять, не всегда, ряд задач будут ему недоступны. Поэтому умение придумывать алгоритмы лучше проверять, чем не проверять.
kalombo
По-моему вы домысливаете. Человек умеющий составлять алгоритмы, может составлять алгоритмы. Человеку не умеющему составлять алгоритмы недоступны задачи на алгоритмы. Умение придумывать алгоритмы лучше проверять, если вам нужно умение составлять алгоритмы, если вам нужно что-то другое, лучше проверять что-то другое.
DrPass
Речь о том, что умение составлять алгоритмы — это единственный навык для программиста, который нельзя вот так взять и получить в любое время по потребности, просто открыв поисковик.
baldr
А что, с ним рождаются? Что за уникальный навык такой, которому нельзя научить?
Zverienish
Не всему можно научить.
AndreiNekrasOn
Конечно, научить можно. Но только очень не быстро, в отличие от конкретных инструментов
siziyman
Умение хорошо понимать, как работает конкретный используемый инструмент — не просто, условно, «ну это база данных, она данные хранит» — тоже нельзя получить, просто открыв поисковик. И уж тем более, просто открыв поисковик, нельзя научиться это знание применять к конкретному вашему проекту.
Kroid
«Алгоритм-мен» никогда не сможет решить практическую задачу. Потому что он наловчился только списки сортировать. А опыту за пределами алгоритмов откуда взяться?
А вот обратное как-раз таки верно. Если инженеру нужно отсортировать список, он откроет справочник
объемов зеленых резиновых мячейалгоритмов сортировок, выберет из них наиболее подходящий под его требования, и вернется обратно к действительно важным вещам — решению практических задач.DrPass
Хм. На SO, например. Какой там опыт нужен? Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить.
Я же прям в моём посте указал пример совершенно обыденной повседневной задачи, решения которой нет в справочнике объемов зелёных резиновых мячей, и на которой запнулся реальный чувак, который не умел писать алгоритмы.
miksir
Для решения вашей повседневной задачи не нужны алгоритмы, нужно как раз умение решать повседневные задачи, те поговорить с менеджером, выяснить, что достаточно взять последний звонок клиенту и посмотреть дату следующего прозвона для этого звонка. Какие тут алгоритмы?
DrPass
В смысле, менеджер должен рассказать программисту, как ему данные выбирать?
У последнего, например, дата прозвона может быть не заполнена. Не суть важно, дело в том, что это тоже алгоритм, пусть и нехитрый. Здесь тоже надо включать мозги и думать, как корректнее реализовать.
Kwisatz
Конечно, откуда может рядовой разработчик знать о текущем бизнес процессе?
miksir
Да, менеджер расскажет что искать, ибо даже в такой постановке задачи есть два варианта что искать — просто максимальную дату прозвона для каждого клиента или все же дату прозвона у последнего звонка. Эти даты могут отличаться. Те это формулирование начальных и граничных (не у всех звонков может быть дата прозвона) условий. Это как раз умение решать практические задачи, а не алгоритмические.
А после формулирования условий остается написать нужный SQL запрос, что во-первых, тоже не алгоритмическая, а практическая задача, а во-вторых при определенном навыке решения практических задач уже ищется в гугле.
Любой код можно назвать алгоритмом, конечно. Только вот под "алгоритм-меном" подразумеваются совсем другие алгоритмы и люди. И вот "алгорим-мен" может не догадаться, что пришедшую задачу нужно обсудить с постановщиком, а так же с тем, кто пользоваться будет. Ему вообще прикольнее задачки на сайтах решать, а не с менеджерами общаться. А практик сделать может не оптимально, зато формочку удобную нарисовать в итоге и больше профита компании доставить.
fallart
не буду лезть в ваш спор про то, что лучше, лишь уточню, что на собеседовании помимо правильного решения смотрят на то, какие вопросы задаёт кандидат. Решение может быть неидеальным и иногда даже не до конца правильным, но если кандидат задаёт толковые вопросы по граничным условиям и т.д. — это идёт ему в плюс и может помочь пройти на след этап
Kroid
Хорошая шутка, но я тоже так умею. Назовите задачку на алгоритмы, которую нельзя взять и нагуглить.
Вы стебетесь надо мной сейчас?
Продублирую тут вашу задачу, чтобы далеко не ходить:
>«отобразить оператору клиентов, которых надо сегодня прозвонить, это клиенты, у которых есть звонки с указанной датой следующего прозвона меньше либо равной текущей дате, и нет звонков с датой следующего прозвона больше текущей даты», которые не лежат в готовом виде на SO.
Какие тут вообще алгоритмы? Мне справочник по SQL за вас нагуглить? Нет проблем: www.postgresql.org/docs/current/sql-select.html
Areso
Напишите алгоритм обхода массива двумерных массивов (трехмерного массива), таким образом, чтобы алгоритм обхода этого массива рисовал круг на проекции 120*120*120.
Alexandroppolus
1) Нагугливаем вычисление, где расположится точка [x, y, z] на проекции 120120120 (это вроде бы изометрическая проекция?)
2) Нагугливаем алгоритм Брезенхэма для окружности.
3) ???
4) PROFIT!
Areso
Нужно нагуглить два алгоритма и успешно их скрестить :)
Zverienish
И?
Areso
Данная задача — пример того, что нужно а) определить какие алгоритмы подойдут для решения ситуации (непросто, особенно если человек геометрию в последний раз в школе видел) б) найти их (изи, если знать, что искать) в) правильно выстроить взаимодействие между ними, что предполагает хотя бы минимальные практические навыки (чуть сложнее).
Т.е. конкретно для этой задачи нельзя просто так взять и копипастнуть готовое решение со StackOverFlow как FizzBuzz. Там нет решения.
mdevaev
> Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить
Пожалуйста, задачка из моей практики. Сжатие одной картинки JPEG на одном ядре арма занимает 0.08 секунд. Требуется получить поток фреймов минимум 30 fps. Есть несколько ядер. Как будете решать?
> на которой запнулся реальный чувак, который не умел писать алгоритмы
Почему вы вообще противопоставляете алгоритмы реальному программированию? Программирование — оно целиком про алгоритмы, сюрприз. Если вы берете инженера, а не кодо-макаку, у него не возникнет проблемы увидеть необходимость разработки алгоритма.
Главный навык — это проектирование, а не задроство литкода. Задротство литкода не даст вашему гению списков знаний об RFC или том как правильно проектировать протоколы или плагиновую архитектуру. Зато результат работы этих гениев видео невооруженным взглядом: уродливые библиотеки и бесконечные велосипеды.
PyerK
Заменить алгоритм jpeg на jpeg-turbo. Обещают быстре 2х-6х в зависимости от платформы и параметров, поддержка arm есть. Есть шанс уложиться даже в один поток.
mdevaev
Хорошая мысль, а если не прокатит?
PyerK
Иногда можно кадры дропать (ведь можно спросить?), если картинка не очень динамичная (ведь с новой библиотекой не хватает чуть чуть). Или переиспользовать пожатые куски для неизмененных пирамид, которые скорее всего будут. (если контроллер дешевый то вероятно и камера дешевая, следовательно iso и выдержка скорее всего никудышние и такие куски скорее всего будут).
mdevaev
Тоже можно. А еще?)
lgorSL
mdevaev
Ну, если бы я проводил собеседование, вы бы прошли :)
Kroid
Это главное условие специальной олимпиады — сравнивать вырожденные случаи. На одной стороне суперопытный инженер, который при этом не написал самостоятельно ни одного алгоритма сортировки, на другой — суперопытный олимпиадник, который годами только сортировку и пишет, ни на что более не отвлекаясь :)
mdevaev
> Начну с изучения бизнес-требований.
Все правильно, но давайте попробуем решить именно техническую задачу. Предположим, что от вас хотят получить пачку жопегов в реальном времени с задержкой не более 200ms и максимальным fps.
> На одной стороне суперопытный инженер, который при этом не написал самостоятельно ни одного алгоритма сортировки, на другой — суперопытный олимпиадник, который годами только сортировку и пишет, ни на что более не отвлекаясь :)
Бинго. При этом поклонники собеседования на senior sortirovatel developer считают, что достаточно искать именно вторых, а остальное как-нибудь приложится.
Namynnuz
Но ведь для этого и были придуманы видеокодеки, чтобы размазывать эволюцией векторного пространства ключевой кадр, пока не придёт новый. При чём часто с хардварным ускорением. А если нужны именно статичные кадры из видеофида, восстановить это состояние можно в любой момент. Визуально для заказчика это можно даже представить как папку с jpeg.
mdevaev
Вам нужно получить вполне конкретный поток jpeg. Вопрос сводится к тому, как вы будете распараллеливать алгоритм, который нельзя распараллелить.
KonstantinSpb
map & reduce
mdevaev
Вы точно внимательно прочитали исходные условия?
wataru
В смысле, нельзя распараллелить? Как раз поток jpeg параллелится элементарно: один кадр — один поток.
Учитывая указанные ранее ограничения, конечно:
Но, если вам, по каким-то пропущенным мною ограничениям, это решение не подходит, то сжатие jpeg все-равно можно параллелить: косинусные преобразования, квантование и RLE происходят в блоках независимо. Потом уж и не помню, хаффман применяется ко всем блокам сразу или независимо. Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
mdevaev
> В смысле, нельзя распараллелить?
Имелся в виду один кадр
> один кадр — один поток
Верно, а потом склеивать их, но с сохранением очередности. Или дропать фрейм, если поток не успел в отведенное время и уже был закодирован следующий. Ответ, которого я ждал.
> Но в любом случае, можно после одной непараллельной части для построения таблицы хаффмана, кодировать все параллельно.
Можно. Или так, как в предыдущем варианте. Но тут бы надо производительность замерить, потому что может быть не слишком большой выигрыш. То есть это не полностью параллельный алгоритм, стадия reduce тоже довольно тяжелая. Плюс мы получаем огромное количество переключений контекста на одну картинку. Так что сжимать фреймы целиком все-таки лучше.
0xd34df00d
Почему? Несколько MCU закодировали, выплюнули битики, записали рестарт маркер, все. Если жпег маленький, то и все равно, а если большой, то кодировать по 65 тыщ юнитов в каждом потоке как раз будет норм по количеству задач.
mdevaev
Вполне вероятно, такой ответ меня тоже устраивает.
0xd34df00d
А обратную задачу вы там случаем не решаете? А то я тут по фану пишу декодер жпегов, и пока забурился в оптимизацию декодирования Хаффмана. Были идеи сделать тупо стейтмашину, на переходах выдающую декодированные байты, но я оценил число состояний, и оно ни в какие ворота не лезет. Я уже догадался редуцировать стейтмашину до лукап-таблицы из следующих N бит в декодированный символ и на самом деле потребленное число бит, но нутром чую, что это можно еще улучшить, а придумать ничего не могу.
mdevaev
Неа, не решаю :) Вы попробуйте кроме алгоритма еще и кадры отдельно разжимать.
0xd34df00d
А у меня нет множественного числа. Я из любви к эклектике пытаюсь на хаскеле сделать быстрый декодер и смотрю, во что упираюсь.
picul
Ну Вы лучше уточните это «несколько», а то ведь 2 ядра — это тоже несколько.
mdevaev
Сколько бы ни было — утилизировать надо все что есть. Допустим 4.
picul
Я к тому, что если у нас 2 ядра (тоже «несколько»), то, кодируя кадры то на одном, то на другом, мы получим обратную пропускную способность 0.04 с, а это всего лишь 25 fps, не 30. Но с четырьмя — да, все в порядке.
Wan-Derer
Выкинуть армы, оставить один для управления.
Сверху напаять плисину (плюс покупная библа) или дсп-шку.
Профитттт! :)
symbix
>> А опыту за пределами алгоритмов откуда взяться?
>Хм. На SO, например. Какой там опыт нужен? Назовите задачку не на алгоритмы, которую нельзя взять и нагуглить.
Вот поэтому я всегда настороженно отношусь к олимпиадникам и любителям всяких хакерренков. Зачастую они вот так и мыслят.
Архитектуру приложения нельзя нагуглить. Написать код, который работает, может любой дурак. Написать код, который эффективно работает, может куда меньше кто. Разработать же архитектуру, которая выдержит годы развития проекта без его превращения в набор костылей и подпорок, могут единицы. А это в сто раз важнее. Алгоритм всегда можно оптимизировать локально, а неудачная архитектура — глобальная проблема.
wataru
И чем эта практическая задача принципиально отличается от алгоритмической? Типа горе от ума? Отсортировать списки он сможет, а сложить 2 числа — уже нет, слишком просто?
kalombo
Вы серьезно? Да в любую сторону ткни, нужны знания. Одно только поле знания баз данных неисчерпаемое. Как человеку помогут знания алгоритмов в написании эффективного запроса, если он даже SELECT не делал?
wataru
А если базы данных c SQL не используется? В гуглах и яндексах всякие свои распределенные системы хранения со своими интерфейсами.
baldr
Правильно, зачем нам знать что там до этого понаписали какие-то дураки. Напишем свое!
Вы утрируете — я тоже.
0xd34df00d
В значимой части случаев, где нужна была производительность, мы писали свою in-memory-ерунду.
DrPass
Отличный вопрос, кстати. Как человек, у которого нет знаний в алгоритмах, может проанализировать план запроса и понять, почему он неэффективно работает? Или как он может понять, почему индекс надо перебалансировать, например? Зная алгоритмы, по крайней мере, отдаешь себе отчёт, чем там занимается СУБД, выполняя твой запрос, а не воспринимаешь её как чёрный ящик.
kalombo
Вы всё с ног на голову перевернули. Человек умеющий оптимизировать запросы, будет разбираться и в алгоритмах, как субд оптимизирует. Человек умеющий реверсить списки на листочке не сможет сразу сказать как оптимизировать запрос без практики оптимизации, тем более если он вообще о субд ничего не знает. Так может и стоит спрашивать оптимизацию запросов на собеседовании если она нужна? Да не бред какой-то, давайте алгоритмы.
DrPass
… является человеком, который в той или иной мере изучал алгоритмы. Ну нельзя хорошо уметь оптимизировать запросы, не имея бэкграунда. СУБД — это как раз та редкая область в ИТ, которая буквально напичкана алгоритмикой.
Ну очевидно же, что если мы берём человека, который ничего о СУБД не знает, то наверное не на должность DBA или DB Performance Engineer? ;)
Kwisatz
Все верно, но обратное — не верно.
Зато если отбирать на указанные должности строго алгоритмистов-олимпиадников есть шанс на довольно знатное веселье.
mrbald
100 раз "да". Ситуация абсолютно уникальная — одна хорошо прорисованная "ментальная модель базы данных" (ну там парсер, кэш запросов, оптимизатор, эвристики, память, буфер сортировки, redo, диск, ...) превращает способного слушать литкодера в достаточно полезного специалиста по отладке запросов СУБД. А гуглить — просто умрешь, сумасшедшее количество деталей и ручек/кнопок (особенно Oracle какой-нибудь).
Kwisatz
О как, а вы только исходя из знания алгоритмов, можете понять почему запрос неэффективно работает? Поделитесь сим сакральным знанием пожалуйста, а то знаете мы то думали что тут 100500 нюансов.
Серьезно? То есть обладая общим знанием алгоритмов вы сходу можете понять почему последняя версия пг строит r-tree индексы на порядок быстрее?
JustDont
Нечеткостью критериев.
Я вам в другой ветке писал про различия между "смогут" и "сделают" — вот лично наблюдаемый случай у меня был как раз такой: х2 времени на разработку и очень сложно поддерживаемый код от двух олимпиадников-снежинок там, где вместо всех примененных наворотов можно было взять чужую либу (работающую медленнее, чего уж там, только это не играло никакой роли).
Могли они сами взять чужую либу? Да конечно же могли. Взяли? Нет, не взяли. Лишние пара недель разработки (и потом еще пара недель на то, чтоб после них подтереть) — это та самая нерешенная практическая задача.
mrbald
"Взять либу" — это вы только до предпоследнего уровня дошли. На последнем смотришь сколько у этой либы активных авторов, какая лицензия, как быстро они баги закрывают и на что живут при этом, зачем им эта либа вообще. Потом читаешь код, чтобы убедиться, что и сам бы также написал. В общем если надо написать 20 строк я бы не стал тащить либу, слишком много надо сделать, чтобы притащить ее правильно.
JustDont
В моей системе координат это первый уровень, когда речь заходить о "взять чужой код", а не последний.
Kroid
Алгоритмическая задача — это отсортировать список как можно быстрее, а дальше хоть трава не расти. Любой говнокод, любые недокументированные хаки приветствуются, лишь бы это добавило скорости.
Практическая задача — это не просто сложить два числа. Это написать код так, чтобы он был понятен и легок в поддержке. Это правильно декомпозировать его, написать читаемые имена переменных (а не «a, b, c»), сделать его расширяемым для будущих изменений бизнес-логики, грамотно написать тесты, и тд.
SpiderEkb
Причем даже скорость не всегда является абсолютным приоритетом.
Мы же не про сферического коня в абсолютном вакууме, а про некий реальный процесс, работающий в окружении десятков, сотен, тысяч других процессов. И нам важна не только скорость, но и ресурсоемкость этого процесса. Что толку в его скорости, если он под себя отбирает столько ресурсов, что все остальное встает колом пока он работает?
В результате задача уже формулируется примерно так: «есть временное окно, в котором загрузка сервера составляет XX%. Необходимо уложиться в это временное окно так, чтобы загрузка сервера не превысила YY%»
А это уже те аспекты, про которые на олимпиадах нет.
Viceroyalty
И еще на вас выделено АА% памяти и СС% пропускной способности шины.
Primala
Ну так в процессе решения алгоритмической задачи смотрят в том числе и на эти качества кода.
anonymous
Такой инженегр может вообще не понять, что здесь надо в справочник заглядывать, ибо привык мыслить по шаблону. Ну и имейте в виду, что если будет какая то нестандартная задача, то такой инженегр бесполезен.
mdevaev
Не путайте инженеров с кодомакаками.
Kroid
Да вы, батенька, расист.
wadeg
Kroid
Вспоминайте, вводный курс теории вероятности. Что более вероятно: (а) Вася хорошо умеет в алгоритмы или (б) Вася хорошо умеет и в алгоритмы, и в архитектуру?
wadeg
Умеющие в алгоритмы и сложность, очевидно, не сферические ботаны в вакууме. Они точно так же работают, приобретая весь тот же самый опыт, помимо алгоритмического, только у него еще мыслительный аппарат при этом более разносторонний и тренированный.
Если Вася успешно потратил при изучении алгоритмов мозговых усилий кратно больше ленивого Пети, то статистически и в любой другой области, в которой он профессионально позиционируется, очевидно, будет разбираться не хуже Пети. Потому что может укладывать в голове сложные объекты и действия над ними, а Петя — ну так, со скрипом. И потому что Вася умеет упорно добираться до недр изучаемого предмета, а Петя — ну как уж получилось.Так что даже нельзя сказать, что статистически Петя подобен Васе, только без необходимых знаний. Без знания алгоритмов — Петя слабый, просто негодный архитектор. Вот потому-то архитектура, построенная вообще без представления алгоритмической сложности работы с ней — явление куда более распространенное, чем хотелось бы.
Nalivai
Ни откуда это не следует, это вы придумали двух каких-то персонажей. Я тоже могу придумать Григория, который как прилежный зубрилка задрочил все алгоритмы с хакерранка, но больше ничего не умеет, и слишком задрот чтобы понять что он должен что-то еще уметь, и Константина, который работал на работе и изучал алгоритмы «в полях», и вообще молодец.
Из этих двух персонажей, Григорий очевидно слаб, глуп и достоин порицания.
wadeg
Можете придумать, ну пусть будет, почему бы нет. И, внезапно, раз Григорий ничего не умеет, то у него и не получится позиционировать себя в какой-то востребованной области. Тем более так, чтобы это было не замечено в начале первой же беседы. Еще раз подчеркну: если ваш Григорий ничего не умеет, то и проблемы его отсечения не существует. А если умеет как надо, то это не ваш Григорий, который
Их желание и способности к погрызу гранита будет с неизбежностью статистически выводить Васю и Константина-молодца к познанию, Петю к накапливающимся фейлам, а Григория к невидимости.
Kroid
Вы сделали бездну допущений, ничем не подкрепленных, кроме своего желания высказаться «в защиту» алгоритмена. Забавно при этом выглядят ваши рассуждения про «мыслительный аппарат при этом более разносторонний и тренированный». Вот алгоритмист так же, считает что у него крутой «мыслительный аппарат», а на деле он дальше алгоритмов ничего не видит.
Но ладно, это уже лирика, так можно бесконечно переписываться о том, что для кого очевидно и что не очевидно.
Факт в том, что в «оперативной памяти» хранятся наиболее часто используемые знания и навыки. Чем реже и меньше человек что-то использует, тем с большей вероятностью он это забудет (или положит в «холодное хранилище в долгим временем доступа», если продолжить говорить метафорами).
Если происходит сортировка людей по одному признаку, то первые места занимают те, у кого этот признак «на кончиках пальцев». Если критерий — алгоритмы, то победят те, кто знают алгоритмы лучше других. А кто может знать алгоритмы лучше других? Правильно, тот, кто совсем недавно закончил их изучать. Если человек хотя бы лет так 5 поработал программистом, то, скорее всего, реально изучал алгоритмы он как раз лет так 5 назад. Сейчас ему интересно другое — архитектура, паттерны проектирования, и прочие высокоуровневые штуки. К примеру, вместо того, чтобы сравнивать скорость разных алгоритмов сортировки списков, он сравнивает разные способы организации и получения данных в какой-нибудь базе, типа постгреса.
Вот и получается, что, задавая вопросы в стиле «реализуйте сортировку пузырьком» или «повращайте мне дерево», больше всего баллов наберут студенты, олимпиадники, разработчики чего-то низкоуровневого, типа компиляторов, и всякие кванты, занятые высокочастотной торговлей, когда каждая миллисекунда промедления означает убытки. А, ну и те, кто страстно желают попасть именно в эту компанию, и последние полгода прорешивали литкод. Обычные инженеры, которые первые минут 10 (особенно, если запретить пользоваться справочниками) будут только вспоминать, как именно работает под капотом алгоритм с тем или иным названием, будут в пролёте. А учитывая, что вряд ли много квантов хотят работать в яндексе, то будут они нанимать в основном новичков.
wadeg
Это не факт, это ваше допущение, особенно в части навыков. На самом деле строго наоборот: чем более мыслительный аппарат разносторонен и тренирован (ага), тем легче и успешней даются прочие действия в смежных областях.
Вот только нет ни одной причины, по которой умеющие в алгоритмическое мышление вдруг в повседневной работе что-то использовали реже остальных. Вы тоже фантазируете про шарообразных алгоритмистов в вакууме, а они точно так же работают над обычными задачами, используя те же технологии, что и неспособные в алгоритмику. Только с лучшим результатом в силу более развитых способностей видеть сложность целого.
Алгоритмы нужно не «знать и помнить наизусть», а помнить в целом, какие они есть, а главное — моментально оценивать сложность разных подходов, когда приходит время выбора. Да, архитектуры это тоже касается, если вообще не в первую очередь.
Ох… Вы знаете, я вообще-то sql'щик, и мне особенно больно видеть, какие способы организации и получения данных в какой-нибудь базе изобретают неумеющие в базовую алгоритмику/сложность. И чаще всего быстро и прозрачно пофиксить это невозможно, это фиксится через кровь и развороченные кишки. Ну просто написано вообще без мысли «а как это потом будет работать». Даже не «и так сойдет (с)», а просто люди не видят последствий, не привыкли автоматом просчитывать пути и алгоритмы наперед. Пока данных немного, оно без проблем работает. А когда/если проект вырастает, начинаются веселые старты с поминанием незлым тихим словом непонимающих, что алгоритмы и сложности — они на самом деле везде, просто они не обучены сразу видеть это на каждом шагу.
ЗЫЖ кому вы написали последний абзац, я не знаю. Про описанный процесс найма я не слова не писал, это выбор яндекса, а их проблемы и профиты от этого процесса мне неинтересны.
Namynnuz
Если вовремя отучить от плохих practices с постоянным желанием реализовывать велосипеды и заставить пользоваться уже готовыми и оттестированными кровью и потом библиотеками и фреймворками. И заставить писать по-человечески, с нормальными названиями переменных и вот этим всем.
worldmind
Решить может и может, но заточеность на решение сложных алгоритмических задач часто мешает ему сделать простое и поддерживаемое решение, в итоге буде плохокод
AlexWoodblock
Ну, слушайте, для такого не надо быть алгоритменом, достаточно просто немного иметь голову на плечах, а в ней — мозгов.
wataru
Ну дак и все задачки с этого собеседования не требуют каких-то глубоких познаний в computer science. Достаточно просто немного иметь голову на плечах.
Nalivai
Да если бы. Уж сколько я в промышленной разработке повидал умудренных опытом профессоров, которые могут потратить год на то чтобы оптимизировать до ниточки алгоритм какого-нибудь специфического обхода фрезой внутреннего радиуса малого диаметра, но не способных, под угрозой штрафа, смерти и увольнения, за месяцы и месяцы, не способных этот алгоритм написать и встроить в общую инфраструктуру так, чтобы оно запускалось хотя бы, не говорю уж об исполнялось.
У некоторых из таких теоретических профессоров задачки с литкода вообще никаких проблем не вызывают, вот прям совсем. У них нерешимая задача это склонить репу с гита, или данные из модуля передать чем-то кроме global static void*.
wataru
Ну вот поэтому на интервью просят решать задачики, а не проводят теоретический экзамен. Чтобы отсеять в том числе таких профессоров.
Nalivai
Как в посте задачки, да? Ну да, если под отсеять вы имеете ввиду «искать исключительно их»
wataru
Что?
Сначала вы пишите, что есть профессора, которые могут натеоретизировать заумного computer science, но не могут писать код. Я вам говорю, ну вот же, на интервью просят писать код. Не заумный — задачки простые! И тут вы каким-то непостижимым мне образом делаете вывод, что если заставлять людей писать код решающий эти простые задачки, то его пройдут исключительно профессора "не могущие написать код"? Раскройте свою логику по шагам — она мне вообще не понятна.
Nalivai
Задачки в посте и прочие простые задачки на интервью — они и есть задачки. Это не работающие программы в реальном мире, это вакуумный код в вакууме.
Человек умеющий решать code puzzles совсем не обязательно умеет производить продукт работая программистом на работе. Потому что в реальности задачи стоят не в виде условий от экзаменатора, а в виде ситуации в реальном мире, превратить которую в задачу решаемую инкапсулированным куском кода — тот еще нетривиальный навык.
И два эти навыка — писать программы и уметь решать code puzzles — друг в друга не транслируются. Сопудствуют, но не транслируются.
Отсюда люди, умеющие решать пазлы, но не умеющие решать практических задач, зачастую даже не могущие понять как подходить к решению практичексих задач.
wataru
Эти задачки (или нечто очень похожее на них) постоянно возникают во время работы. Вам так сложно представить, что в Яндексе где-то программисту придется выбрать общие элементы из двух списков?
Не могу себе это представить. Как раз алгоритмическое мышление и умение решать пазлы тренеруют построение математической модели задачи. Это очень помогает решать практические задачи.
Есть еще отдельная секция про проектирование систем — вот там как раз проверяется умение решать большую, нечеткую задачу. Там не просят писать код (то, что человек код писать умеет видно по алгоритмическим секциям). Но там как раз смотрят, как человек разбивает задачу на подзадачи, как выковыривает из интервьювера недостоющую информацию.
Ее не задают на начальные позиции, потому что люди на этих позициях в основном "копают от сюда и до обеда". Им ставят вполне фиксированные задачи.
mrbald
Я ищу программиста которы умеет на Java и выбивает 7+ из 10 (0-нуб, 10-бог, условно). Задаю вопрос по почте «пожалуйста прочитайте 17.4 спецификации языка, и подумайте, зачем оно». Ни один из кандидатов (многие с 20+ годами опыта) нормально не ответил, либо не могут прочитать, либо не могут нагуглить разжеванный вариант, либо начинают хамить прямо сразу и говорить, что это не надо. Так что да, профессия загибается.
A114n
Так у вас тон вопроса агрессивный, вот люди и закрываются. И даже «пожалуйста» этот тон не смягчает. Вы переформулируйте хотя бы в виде: «что вы думаете по поводу §17.4 в спецификации Java?»
mrbald
Я его по-английски задаю, и всем немного по-разному, чтобы рекрутер не понял паттерн, но все с “can you please, if you have time, ...”, плюс — это тоже тест, насколько легко вас втянуть в конфликт.
AlexJameson
А зачем, собственно, вы втягиваете программистов в конфликт?
mrbald
Я исхожу из предпосылки, что вопрос на собеседовании на знание основы технологии, с которой ты будешь работать каждый день, даже если задан без предварительных ласк, не должен вызывать раздражение и тем более хамские ответы. В нашем случае еще к тому же маленькая страна и все кругом Д’артаньяны.
sumanai
Тогда спросите про пробелы vs табы.
mrbald
Я спрашивал (в смысле что делать если у вас с коллегой разные предпочтения). На собеседовании все либо говорят, что они взрослые люди, что можно договориться, что надо форматирование автоматическое делать в pre-commit делать, либо (когда совсем без опыта и не понимают что будет с историей в гите) — что это пофиг и пусть каждый как хочет так и кодит. А после найма — большинство тихонько делают по-своему и меняют форматирование в каждом коммите, пока "начальник" не скажет как надо.
sumanai
Вот у меня банально нет предпочтений. Есть кодстайл, и нужно ему следовать ))
Viceroyalty
И есть инструменты вроде eslint, и они помогают (заставляют?) ему следовать
0o00oo00o0
Кроме, понятно, случайных замен невидимых символов таб-пробел, которые не нужно коммитить, что будет с историей в гите?
sumanai
Кроме того, что вместо точечных замен по заданию будет заменён по сути весь файл, никаких.
Конечно, если смотреть через какой-нибудь веб-интерфейс гита, это не будет видно, они скрывают такие правки. Но реальных изменений меньше от этого не будет.
mrbald
Сложнее пользоваться blame, когда последние N коммитов просто меняли отступы, пробелы и скобки чем когда в один клик можно добраться до настоящего автора.
Viceroyalty
А я вот думаю, что рекрутеры — зло которого должно быть поменьше. Пусть лучше пара лидов (или как там сейчас модно их называть) которые будут непосредственно ставить задачи тратят 10% времени на поиск сотрудников, чем потом все огребают от некачественного кода, но это, конечно возможно в условиях хорошего финансирования (а то будут толпы джунов и текучка).
AEP
Раньше я занимался поиском сотрудников. Сейчас за такое не возьмусь: проходимцы с идеальным резюме и нулем знаний демотивируют. Пусть лучше психологически устойчивый специалист их отсеет за меня.
Viceroyalty
По опыту: высококлассных специалистов обычно находит сам будущий руководитель, правда это в IT-аудите, может, с разработчиками ситуация другая.
intet
Просто вы хотите от кандидатов, чтобы они потратили свое личное время, когда есть куча компаний в которых можно прийти весело поговорить на технические темы без решения задач и уйти получив оффер.
mrbald
Я понимаю всё это. Я просто не могу придумать как делать лучше. Когда кандидат мне пишет “я 9 из 10 в Linux” честно готовлюсь сам ко встрече с мессией, как дурак трачу время на поиск интересных вопросов и тем, а потом чел не знает что такое системный вызов, и, грубо говоря, на какой порт приходит пинг.
wigneddoom
На какой?
mrbald
Не скажу. Запустите ping под strace и сами посмотрите :-)
eugene08
Ни на какой. Знакомые переживания…
Kwisatz
Я каждый день ковыряюсь в пачке микротиков, хобби такое, но вот сходу не вспомнил. Во первых я не в контексте, во вторых вы всегда можете загуглить любыми словами, даже не зная «icmp».
Поговорить как два профессионала, у вас есть задачи, соискатель их может(возможно) решить. Вы когда мебель заказываете тоже сначала спрашиваете из какого металла и под какую отвертку будут шурупы? Уверен что нет, вы говорите «хочу шкаф».
Извините, но вы все верно сформулировали. Я встречался с такими как вы и мне ваши «интересные» вопросы не кажутся таковыми.
Когда я прихожу на собеседование (а прихожу я только когда настойчиво зовут) то я ожидаю услышать «Мы хотели бы нанять вас под проект Н, суть проекта М. Вы сталкивались с таким, можете чтото рассказать? Наши текущие проблемы О, П, Р, С, Т., вы бы смогли их решить? Давайте обсудим как бы вы приступили к решению проблемы Р»
mrbald
Если бы я нанимал сборщика мебели, я бы еще и спросил с каким моментом надо закручивать в фанеру и с каким в ДСП и у кого их лучше покупать и какой отверткой крутить.
Те кто 9 из 10 в Linux, обычно знают с ходу и про пинг и про то, какую для пинга лучше брать сетевуху и у кого покупать, но редко клюют на вакансию "Software Engineer".
Kwisatz
Удачи вам, особенно с мебелью.
mrbald
Да, вы правы, мой мастер цеха бы их научил с каким моментом крутить и какой отверткой. Нафиг их спрашивать. И проверить просто — дать один шкаф собрать.
В принципе так с контрактниками и происходит, и все довольны обычно. И контрактники сами еще приносят шкаф показать, который они делали, и иногда даже можно владельца шкафа спросить как он там.
Kwisatz
Да нет, не научил бы, потому что в исходном тексте речь шла о заказе а не о сборке мебели, собственно дальше идет череда неверных выводов, интерпретаций и аналогий.
wigneddoom
Ту на которой написано "ping ready edition"?
mrbald
Скорее что-то типа "хорошо идет с вашей красной шапочкой", но не уверен, я не тяну и на 6 из 10.
ALexhha
wigneddoom
Без знания ICMP вам врядли светит профессия сетевого инженера например, т.к. поговорить как два профессионала с нанимателем не получится.
baldr
Судя по всему, в Яндексе у вас есть такой шанс. Заодно алгоритмы подтянете.
Kwisatz
Идем в начало ветки и смотрим кого же человек искал то.
Опа, а ищет то он оказывается разработчика, как интересно. Но я как разработчик (CTO, TeamLead) конечно страшно опечален, да.
ЗЫ кстати даже сетевой инженер не держит все и вся в памяти непрерывно а еще он может волноваться на собеседовании. Простой пример, 5ый знак после запятой числа пи назовете сходу? Как нет? Мы же все это учили, ну в самом деле, основы же.
mrbald
Чел будет просить значительно больше денег, и нам было бы здорово такого заиметь и платить больше, мы сами себя сисадминим. Он же сам пишет что знает.
ЗЫЫ — про пинг сетевой инженер знает и на вопрос про порт проржется мне прямо в глаза. Зачем знать про порт — ну чтобы знать насколько хорошо можно пингом оттестировать производительность TCP.
ALexhha
sumanai
979, следующие 3 цифры. Именно с такой точностью оно выводится в стандартном калькуляторе в Windows XP.
Kwisatz
Потому что вы разбили группами правильно, я бы еще девятку отделил.
Зы я просто показал как абсурды и дебильны такие справочные штуки.
intet
В сжатые сроки рассказ кандидата о самых интересных и технически сложных задачах из тех что он делал, даст лучшее понимание его уровня, чем вопросы по каким-то деталям реализации.
Потом всегда есть испытательный срок. Да это денежные и временные траты, но тут уж вопрос баланса — если поток кандидатов высок, то можно ставить барьер в виде алгоритмических задач, если поток низок то больше надо допускать к реальным задачам.
SpiderEkb
Вот да. В Альфу у меня именно такое и было собеседование.
Никаких тестов, просто поговорили — чем они занимаются, чем я занимался.
Интервьюеров тут тоже нет. Беседуют члены команды (тимлид, техлид, функциональный руководитель...) — те, с кем потом работать.
Испытательный срок есть, но это больше обучение — найти готового спеца на RPG и AS/400 у нас малореально…
Am0ralist
Собственно по невозможности даже поддерживать ИС на ней за вменяемые деньги (разработчики в ЕС уже давно на пенсии) был полный уход на новую ИС
sumanai
Проблема в том, что знания этих старых систем нужны практически никому, и такого программиста нужно золотом осыпать, чтобы по уходу у него было пару лет наверстать упущенное.
SpiderEkb
Ну не все так страшно на самом деле. Система вполне себе живет и развивается как по железу, так и по софту. Относительно недавно появились системы PowerS9. На подходе (если еще на вышли) — 10-е.
Версия самой ОС 7.4 вышла в прошлом году. TR-ы (обновления внутри версии) выходят регулярно (мы сейчас в процессе перехода с 7.3TR9 на проде на 7.4TR3 которые уже раскатаны на тестовых средах)
Да, у нас она не популярна (я знаю три банка, которые на ней работают — Альфа, Райф и Рос, ну может еще где-то есть). Но в мире она достаточно распостранена — банки, страховые компании, госструктуры.
Просто на фоне всеобщего засилия мобильной и вебразработки это выглядит нишево, но ниша эта стабильна.
В целом, это свой рынок, вполне устойчивый. Аналогично можно сказать и про многие другие аспекты разработки — та же промавтоматизация, встроенные системы. Уступает по объему вебразработке, но средняя квалификация работающих там людей достатчоно высока.
mrbald
Видимо да, наименее затратный подход для обоих сторон. Или вообще только через знакомых искать (но это будет не совсем честно).
Akuma
И на какой? Вот как ни странно, но по этому запросу на первой странице гугла ничего путевого. В вики пусто.
А потому что нафиг это никому не нужно в реальных задачах.
mrbald
Вы не поняли о чем вопрос и разозлились. Там не про порт совсем.
Akuma
Ну я точно не злился )
mrbald
Вот сам не понял зачем написал ненужное и обидное первое предложение, извините.
BioHazzardt
ну так протокол ICMP вообще никакой порт не использует, в пакете кроме ICMP есть только IP-заголовок (source и destination ip), если мне, конечно, склероз не изменяет
Nalivai
Вот, вот опять это самое. Вопрос «на какой порт приходит пинг» это же в лучшем случае вопрос с подвохом, экзаменационное «завалить» вот это вот.
Это ровно противоположное разговору двух специалистов, это никак не про то, может ли человек работу работать, это очередная итерация агрессивного экзамена, где цель экзаменатора найти чего экзаменуемый не знает, и радостно поставить ему неуд. А если найти не удается сразу, начать трюки разные, лишь бы где-нибудь ошибся.
domix32
А ссылку даете?
mrbald
Ответил в личку
mrbald
Кстати, один из кандидатов был русский чел из гугла. Элегантно отвертелся от низкоуровневых деталей 17.4, затроллил offline coding task на игре слов, сделав совсем не то, что просили но настолько круто, что всем очень понравилось — совершенно другая лига, футболист с мячом, а не бурлак на Волге, условно говоря. Ощущение, что просто приходил убедиться, что в гуле ОК, несмотря на иногда скучную работу.
Viceroyalty
Прокаченные soft скилы они такие
DFeudor
Прошу прощения… Вы вот об этом ...?
«17.4. Спецификации — ДНК, код — РНК
Даже в давние времена PDP-7 Unix-программисты всегда (больше чем их коллеги, работающие с другими системами) были склонны рассматривать старый код как непригодный к повторному использованию. Это, несомненно, было продуктом Unix-традиции, которая акцентировала внимание на модульности, облегчающей выбраковку и замену небольших блоков систем без потери целого. Unix-программисты уяснили из опыта, что попытки сохранения плохого кода или плохого дизайна часто являются более трудоемкими, чем создание проекта заново. Там, где в других культурах программирования инстинкт подсказывал бы исправлять неповоротливые монолиты, потому что в них вложено много труда, инстинкт Unix-программиста обычно ведет к выбрасыванию старого кода и созданию нового.
Традиция IETF усилила этот инстинкт, научив нас считать код вторичным по отношению к стандартам. Стандарты являются тем, что позволяет программам взаимодействовать; они связывают технологии в единое целое. Опыт IETF показывает, что тщательная разработка стандартов, стремящаяся к сбору лучшего из существующей практики, является той формой сдержанности, которая достигает гораздо большего, чем претенциозные попытки переделать мир по образу нереализуемого идеала. ...»
mrbald
нет
un1t
Второй путь через рекомендации тех кто уже работает в Яндексе, в этом случае вас не будут мучить этой ерундой.
anton0xf
Вы уверены? Я слышал ровно наоборот от коллег, которые пробовали кого-то рекомендовать.
un1t
Я слышал это от людей из Яндекса. Более того, книге «Яндекс.Книга» описано, что они стараются нанимать именно по рекомендациям, а не случайных людей с рынка.
Наоборот это как? Тех кто пришел по рекомендации спрашивают в 2 раза больше дурацких задачек?
Надо понимать что Яндекс большая компания и все процедуры включая собеседования могут сильно отличаться от отдела к отделу.
anton0xf
Наоборот, это что они (порекомендованные) сначала долго ждут, когда с ними свяжутся, и не всегда даже дожидаются, а потом их отправляют на тот же стандартный набор секций.
Собственно, это даже логично, учитывая, что рекомендовавшему за нанятого по рекомендации дают приличный бонус.
А то, что стараются нанимать по рекомендации, вовсе не противоречит необходимости решать при этом задачки.
Viacheslav01
Нигде не берут, воронку проходят единицы, мы в проект спецов хантили по полгода. Единственный нормальный поток кадров, это студенты на стажировках, у нас большая часть оставалась.
Но к сожалению почему то политика не становится более адекватной.
П.С. на входе два прохода по 7 интервью (из них 7-8 задачки), провел в офисе Я 2 дня)))
szt_1980
Сильно. В Амазоне — и то 3 этапа, 7 раундов в общей сложности — а уж дурацких задачек сильно поменьше.
extiander
собеседование в ФБ на сетевика
4 из 6 тех собеседований — программирование, причем варианты — правильно сделать вот так (например не хранить состояния мелких процессов/докеров локально) — отметались как неподходящие, «правильно» писать в темп файл локально.
сетевое номер один — все норм, кроме того что я не отгадал «правильную» причину возможной потери пакетов (я назвал штук 20 по уменьшению вероятности, эта проблема была где то в моем списке месте на 50, я ее в итоге после выпытывания назвал, но «уже было поздно»)
единственное норм впечатление (как относящееся к вакансии) оставило архитектурное интервью
вот так я и не стал частью ФБ
Alex_333
Расскажете поподробней про это собеседование?
extiander
про которое из
там их штук 6 — 8 было
все удаленные
прогерские — часть норм (пытаются понять что ты знаешь, как думаешь)
часть — нам нужен ответ который у меня в голове, угадывай,
то что их больше профельных слегка удивило
профильные — архитектурный — прикольно и интересно
чистая сетевка — угадай ответ (на простых, стандартных вопросах не проблема, в сложной проблематике — как указал выше — я привел с десяток потенциальных проблем (из опыта) вызывающих заданную проблему, попытки переключить интервьюрера из режима «угадай мой ответ» в режим «давай вместе проведем траблшут / сужение и найдем варианты» не удалась — от этого интревью осталось самое плохое впечатление
скорее всего — просто не повезло
общее впечатление от всей серии положительное, но локальные перегибы позабавили
HR один из немногих случаев когда они вполне разбирались в базовой тематике и нормально знали требования / альтернативы (например CCIE им достаточно как подтверждение сетевого опыта)
ilowry
Это у них, видимо, так, потому что наемом занимаются люди, которые никакого отношения к тому проекту не имеют. Поэтому у них подход чисто формальный: озадачить кандидата задачкой и поставить оценку, которая зависит от того, насколько его решение соответсвует тому, что они ожидают. Им так проще.
А вот насколько способность быстро решать логические/алгоритмические задачи на интервью кореллирует с практикой разработки программного обеспечения, это еще вопрос. По мне так не сильно.
WALKER898
а никак. у нас конечно не Гугл, но все таки софтверная компания с персоналом около 7 тыс человек. я был в шоке, когда пришлось одному Senior Developer Engineer во время PR review объяснять что set intersection может сократить его код в 2-3 раза. ЗЫ. сам я не senior.
Nialpe
Очень хотелось бы прочитать историю человека, который прошел все этапы в Яндекс (или другую крупную компанию), о том, чем он занимается ежедневно. Доступным языком.
Расскажу схожую историю про одного моего знакомого))) Он смог попасть в госкомпанию (назовем это так) на три буквы первая Ф. Отбирался год примерно, куча этапов, сложнее только у космонавта отбор… Потом ходил гордый, на вопросы чем занимаешься не отвечал — тайна. В итоге через общих знакомых узнал, что он 10 лет на калитке просидел сутки-трое. Нет, тоже важная часть работы, но зачем тайну делать из этого, видимо разочарован был.
Catslinger
Если ему при этом платили, как крутому программисту — то молчал, чтобы от этих самых знакомых не получить подляну. Зависть у русских бессмысленна и жестока.
Nialpe
Зависть вообще разрушительна, у всех.
shpaker
Казалось бы при чем тут русские...
anton0xf
Тем же, что и везде. Работал в Маркете бэкендером на Java. Когда устраивался, описанное выше ещё задачками на сообразительность разбавляли. Писал всякие API, "перекладывал JSON'ы", добавлял в БД таблички и писал к ним запросы, иногда писал и фронт (с минимальным опытом в этом, но на внутренние проекты фронтов часто не дают), иногда что-то ковырял в местном map-reduce, настраивал местный недо-кубер, настраивал всякие графики (rps, тайминг, ошибки и пр.) и мониторинги по ним (тоже всё в основном самописное: "на наших масштабах готовые решения не тянут" ©), чинил баги и разбирался со всякими неожиданными (и иногда мистическими) проблемами с производительностью или неожиданными багами, когда при отключении одного ДЦ ложится вся, казалось бы устойчивая к этому, конструкция.
anton0xf
По теме могу только сказать, что писать квадратичные алгоритмы вместо линейных — это таки большое зло. И стреляет потом очень больно, и разбираться и чинить придётся в дикой спешке и, возможно, в нерабочее время, ибо прод горит, а деньги улетают в трубу тоннами в секунду.
Что конечно никак не обосновывает необходимость задротства на литкоде
mrbald
Еще большее зло — не писать бенчмарки, или не уметь их писать правильно/реалистично.
anton0xf
Таки вот тут выше был пример с "найти общие элементы в двух списках". Вот вы как предпочитаете: написать "очевидный" для тех, кто не в курсе про асимптотическую сложность, квадратичный алгоритм, а потом ловить проблему бенчмарком, или таки воспользоваться библиотечной функцией для пересечения множеств и больше не вспоминать об этом никогда?
Нагрузочное тестирование конечно никто не отменял, но его делают далеко не так часто, а ещё реже добиваются высокого покрытия по коду, а подобная взрывная штука может спрятаться где угодно.
Ну и писать бенчмарки на любой кусочек кода — тоже странная идея. Они всё-таки обычно применяются, когда уже понятно по другим признакам, что конкретный кусочек кода работает слишком медленно, и не видно очевидных опять же проблем с асимптотикой, поэтому придётся писать что-то сложное, которое надо и протестировать досконально, и производительность с другими вариантами сравнить.
Kwisatz
Ну да, я вот как раз недавно узнал как один банк у себя внедряед очередную систему. Какие то совершенно безумные выкрутасы с разнесенными базами и построчной вставкой «для производительности», метрик нет, бенчмарков нет, мониторинга нет, слов у меня — тоже.
olegbask
Ещё я заметил, что люди пишущие квадратичные алгоритмы абсолютно не парятся по поводу рантайма приложения. Напихать в контейнер 5гб зависимостей — легко! А что, на ноуте же запускается? Потом эти же люди решили в результат map-reduce для простоты добавить все входные данные. А что? Так же проще дебажить? Подумаешь, на мастер приезжает 1тб мусора… проще ж засыпать железом.
Nialpe
Спасибо, коллега. Занимаюсь примерно тем же.
JoyceGraham
Кратко если, то тем же самым, что и в других компаниях. Сейчас яндекс большая компания с кучей проектов разной сложности. Поэтому и разработчики в нем работают самых разных уровней.
wataru
Могу поделится опытом из гугла. Да, 99% времени — рутина. Как шутят в гугле — вместо алгоритмов перекладываешь данные из одного протобуфа в другой.
Но алгоритмические задачи раз в месяц, да и случаются. И тут я благодарен, что я алгоритмы умею.
Сейчас на интервью спрашиваю именно ту задачу, которую сам решал и комитил в прод (слегка упрощенную, конечно, чтобы в интервью влезло).
И считаю что такие алгоритмические интервью — полезны. Даже идиота можно научить перекладывать данные из одного протобуфа в другой. А вот с редкими, но важными алгоритмическими задачами чувак с кучей историй и с которым можно по душам поговорить про очередной фреймворк далеко не всегда справится. Более того, такой условный разработчик может даже и не поймет, что тут алгоритмическая задача. Надо как-то данные перемолотить, ну и молотим. А то, что тут можно динамическим программированием вместо 2^n получить n^3 и при этом решение в 3 раза короче по коду и сильно проще для чтения — даже мысль не придет.
Поэтому, если у вас достаточно кандидатов, то имеет смысл отсеевать по самому сложному, хоть и редко нужному навыку.
Плюс, единственный достоверный способ реально понять, умеет ли кандидат писать код — это заставить его писать код.
leventov
Самый сложный и постоянно нужный навык — задавать себе вопросы типа:
mrbald
И еще «как мне не стоять на проходе когда я ничем не могу помочь», и как понять когда я могу а когда нет. Фрактальный скилл просто.
SergeyMax
Вопросы интересные, но интереснее, как вы на них отвечаете)
leventov
Если бы я умел на них хорошо отвечать, я бы уже давно не сидел на Хабре :)
ardraeiss
Чревато. Можно прийти к выводам "ненужное, неиспользуемое, корявое и неудобное, а ещё хлипкое".
Kwisatz
Как раз гугл писал статью что качество работника с типом и качествои собеседования не коррелирует никак, совсем, вообще.
А потом смазать это построчным вызовом запроса в бд и вообще ляпота. Без шуток, видел много раз такое в «крайне оптимизированном» коде.
sumanai
Делать вставку миллионов строк разом тоже не всегда хорошо.
Kwisatz
Тут спорный момент, сильно зависит от того что и как вставляете. И тем не менее, делать миллион вставок одной строки — совсем плохо. Тут можно впринципе длинную дискуссию организовать, но в процессе обсуждения мы с вами скорее всего и конкретные СУБД обсудим и сеть и транзакции, и (маловероятно но возможно) дисковую подсистему и прочие IOPS, но вот чего мы точно с вами не обсудим это как раз большую О. И, кстати, далеко не факт, что с добавлением слоя абстракции и работы с бд, оптимизация исходного алгоритма будет иметь хоть какое то значение.
gecube
А про потребление памяти не забыли? Запросто может быть, что более «медленный» алгоритм более оптимален по памяти, чем более «быстрый» с каким-нибудь бектрекингом, но как только мы сваливаемся в какой-нибудь своп — усе пропало, шеф
wataru
Если там n такое, что n^3 заметно по потреблению памяти, то первоначальный алгоритм за 2^n — вообще ни в какие ворота не лезет. Кстати в динамическом программировании часто памяти надо на порядок (или даже 2) меньше, чем времени. И в итоге потребление по памяти может быть таким же, как при переборе.
Ndochp
Ну 2^n может по памяти быть массив на n + счетчик, а n^3 может быть "а давайте создадим массив nnn и будем его обновлять в процессе обхода."
wataru
Если n^3 уже хотя бы 100 килобайт, то 2^n — это 70 триллионов. Наивный алгоритм тут работает десятки часов, когда как этот ужасно прожорливый до памяти алгоритм — миллисекунды.
Повторю свой тезис: Если увеличенное потребление памяти нельзя тупо проигнорировать, то изначальный алгоритм работал непозволительно долго.
Это как упрекать пожарника, что вы мне компьютер залили — он сломался. Когда как вокруг дом горел и люди умирали. Несоизмеримо меньшее зло.
WASD1
>> и при этом проще для понимания.
Если последний критерий немного переформулировать — то честно говоря прям с ходу я хороших примеров и не вспомню.
То есть если знать терминологию — то да помогает.
Если обладать «постзнанием решения» — тоже помогает.
А вот прям так с ходу, чтобы более быстрый алгоритм был ещё и более коротким и понятным (без постзнания) — не вспомню.
wataru
Что вы понимаете под "постзнанием" тут? Базовые понятия из курса про алгоритмы (ДП идет оттуда). Тут даже никакой хитрой математики нет.
Если это продолжать, то тогда и всякие хитрые конструкции языка использовать не надо. switch-case, оно короче, проще и понятнее, когда представляешь, как оно работает. А вот if-else-if-else-if… это и без "постзнания" понятно. Так что ли?
Из моей практики. 100+ строк рекурсивной функции полного перебора (+ еще 20 комментариев) заменяется на 20 строк ДП уже с комментариями. Там всего 2 вложенных цикла и тривиальная формула внутри. Комментарии четко говорят, что тут ДП, что вот такие параметры, вот пересчет. Даже не знакомый с ДП человек сможет въехать.
WASD1
>> из моей практики.
Вот прям хотелось бы пример!
>> что вы имеете в виду под постзаннием?
пример задачи:
Найти в массиве подпоследовательность с максимальной суммой.
Базовое решение за O(n2), быстрое решение за О(n).
Быстрое решение ещё и короче (в строках кода).
Но по записи быстрого решения понятно что мы делаем на уровне бизнес логики — только в случае, если человек уже разобрался с этой задачей (встречал её в олимпиадном \ литкодном прошлом или на каком курсе).
В итоге быстрое решение хоть и короче — но скорее хуже с т.з. понимаемости.
wataru
Я эту задачу сейчас сам на интервью использую. Поэтому не буду приводить.
Это лечится одним комментарием вроде "cur_max_sum — максимальная сумма подпоследовательности, заканчивающийся в данном элементе." Если после этого человек не может понять эту логику, то этому человеку, наверно, не место в яндексе.
Alexandroppolus
Интересно бы глянуть условие задачи.
wataru
Поскольку я ее все еще задаю, не хочу ее в интернет сливать.
eucariot
Через несколько дней я расскажу на хабре, чем конкретно я занимаюсь (не разработчик, про алгоритмы не спрашивали)
Juster
прошу отправить ссылку на пост ответом на этот комментарий :)
eucariot
А вот и он.
Sofrony
Ну вот тут люди неплохо описывают: habr.com/ru/company/yandex
anwender95
Извините, не объясните, что за «сидение на калитке»? Это фразеологизм, эфемизм или фреймворк из веба? А то сходу не гуглится.
Nialpe
Охранник на входе. Понятно, что там ответственность, оружие и все прочее, но романтические мечты, насколько я предполагаю, были у него разбиты, отсюда и завеса тайны.
Am0ralist
По опыту знакомых — охранники на входе в силовые ведомства намного лучше, чем всякие линейные части. И безопаснее. Да и времени при сутки через трое намного больше, чем у тех, кто 6/7 по 10 часов в день работают стандартную 40 часовую неделю.
unsignedchar
«Поставьте сюда шлагбаум или толкового майора» (ц) #армейскиеанекдоты
Думаю, что-то в этом роде.
TheKnight
Работу работаем, и прокрастинацию прокрастинируем.
Размен скорости на память и наоборот делаем регулярно, страшных алгоритмов типа trie на практике не реализовывал и не использовал, но знаю где в соседней команде заиспользовали и зачем.
panter_dsd
Сейчас прохожу в яндекс на Go сеньора. Было 2 интервью с задачками, сейчас жду фидбэка по второму — уже 3 дня жду. Надеюсь, следующим этапом будет что-то отличное от алгоритмических задачек с литкода. Кстати, задачку про «функцию RLE» я тоже решал. :)
Bokrenok
«на сеньора» по идее ещё одна «с задачками», а потом должно быть две «архитектуры»,
у меня так было в ноябре-декабре: 3 этапа — алгоритмы, 2 — этапа архитектурных
p.s. +1 за RLE, тоже решал, на первом этапе.
panter_dsd
У меня еще одну с задачками поставили и допустили до архитектуры — в пятницу буду проходить.
KonstansKeen
Отличная статья! Когда я проходил собеседования в яндекс, ощущения иногда были те же, что у автора. Почему нельзя IDE? Зачем вообще эти задачи?
Но иногда попадались иного рода интервьюеры, которые задавали достаточно глубокие вопросы: например, на понимание распараллеливания задач, работы сети и так далее.
Поэтому у меня опыт собеседований в яндексе не такой однородный, как у автора.
Snaffi
Не понимаю этого негатива. Задачки простые, зачем беситься? Ну покодил онлайн, поняли, что умеешь кодировать. Относитесь ко всему проще :-)
kesn Автор
4 часа.
Snaffi
ну покодил 4 часа :-)
user52523
Бесплатно
A114n
Кодить с нами онлайн — большая честь!
igrishaev
Думать четыре часа кряду — огромное усилие.
kesn Автор
Не подряд. Написал ниже апдейт. Сорри за путаницу.
VinBear
Да, 4 часа это много когда вы и не собирались устраиваться на работу, а пришли поразвлекаться.
Реальная работа это, извините, сommitment и от вас и от компании на как минимум много месяцев или даже уже лет, плюс с большим количеством денег на кону.
Жаловаться что вас крутят 4 часа по алгоритмам это показать свое непонимание процессов найма, их практичности, неумение оценки реальности внедрения более «правильных» с вашей точки зрения процессов найма, неуважение к людям выстраивающим этот процесс за счет отметания с ходу вероятности того что возможно это именно вы что-то неправильно понимаете.
Даже если бы вы решили идеально все представленные задачи, изложенное вами отношение и мысли в этом посту с таким подходом вида «Все говно, а я Д`Артаньян» не помогают уже вам заслужить уважения в ответ. Лично я бы вас не принял никуда ни на какую роль после такой демонстрации, рад за вас что вам на текущем месте хорошо.
ardraeiss
Найм на работу — это ещё не работа. Во-первых — время не оплачивается. "Во-вторых" после этого уже не требуется.
VinBear
Вы заранее до интервью знаете что это займет несколько часов, хотя бы 2-3, оплачивать которые вам никто не собирается. Это абсолютная клоунада, когда вы ожидаете что по-хорошему каждому из сотни людей на вакансию надо оплачивать его время. Или из десятков, которые доходят до интервью. Компании и так тратят на каждого кандидата куда больше денег, чем требуется потратить от кандидата, в десятки раз больше даже с таким потоковым подходом к интервью.
Надо хоть немного совести иметь и понимать это, а не жаловаться что все про все заняло на 1-2 часа больше времени и бугуртить до уровня написания поста на хабр.
Еще надо понимать что собеседования по удаленке куда сложнее для интервьюера чем лично, поэтому очевидно что их надо больше чтобы лучше понять что за человек пришел. Очевидно это временно. Очевидно что винить компанию за это крайне несправедливо.
Если кто не в курсе, то до ковида яндекс и так при приглашении на личные интервью покупал вам и билеты на самолет и гостиницу оплачивал. Требовать чтобы еще больше они вам что-то компенсировали это вообще тотальная наглость. Что они вам еще должны, оплатить пару дней на уровне реальной зарплаты? Рожа, извините, не треснет? При ковиде теперь то конечно не лично получается, но и время вы экономите не собеседуясь лично.
На каждого программиста, который считает что ему все обязаны, найдется не менее десятка сравнимого уровня тех, кто понимает что ему эта конкретная вакансия нужна больше, чем он нужен компании. И кто готов «потратить» десятки, а то и сотни часов на весь процесс прохождения на желаемую вакансию в желаемую компанию. И я лично рад что такие как ОП, а также неготовые потратить несколько часов бесплатно, отсеиваются в описанном процессе найма. Классическая фича, а не баг.
300KpS
Вы же сами сказали, что для того, что бы интервьюеру на удалёнке понять що ж це за кандидат перед ним, ему придётся потратить больше времени, что бы прийти к такому же уровню понимания о кандидате, чем он мог бы прийти лично. Он же не в вакууме время тратит, он тратит как своё время, так и кандидата. Соответственно, не понятно в чём тут экономия времени для кандидата, если его будут больше собеседовать.
Ну, в том то и дело, что то было до ковида. Если компания оплатит перелёт и проживание, то можно и 8 часов лично собеседоваться, тут нормально всё. Но, поскольку времена ковидные, если рассматривать удалённое интервью, то они ничего не тратят кроме денег на зарплату интервьюеру. А раз не платят, то и отношение соответствующее
VinBear
Такие то вы дефицитные, что даже у яндеса найдется десяток людей на ту же вакансию с соразмеримым уровнем, но куда меньшим чсв, чем у вас, не говоря уже о гуглах и им подобных. Продолжайте кукарекать о своей незаменимости.
Эх, сейчас бы помечтать о том как мой будущий работодатель будет тратить уйму денег ради оплаты чсв кандидатов, которые приходят на интервью почесать оное чсв, а не на повышение зарплаты работникам, которым я, как настоящий кандидат, вроде как собираюсь стать.
Впрочем, если не собираюсь и не имею достаточно эмпатии чтобы поставить себя на место такого кандидата, то да, я могу вредных советов насоветовать, попризывать не жалеть бедненькие компании.
Уровень понимания и осознания написанного на абсолютном дне. До ковида — телефонное интервью плюс переговоры с рекрутером + Полеты туда-сюда до Москвы/Питера/etс. отнимающие больше суток. После ковида — чуть больше онлайн интервью чем их было бы на месте. Экономия очевидно на сутках потраченных на полеты туда-обратно, плюс-минус пара часов здесь вообще ни что не влияет.
При этом вы все равно потратили больше суток своего времени и не получили на выходе никаких денег в кармане, только оффер или нет.
Без полетов вы потратили условные 4 часа, и на выходе получили оффер или нет.
В первом случае вам типа норм, а во втором вам типа недоплатили. Задумайтесь, не унюхиваете маразм и отсутствие логики?
А это как бы мало? 4 условных интервьера плюс-минус, каждый тратит какое-то время на подготовку интервью с вами, само интервью, потом пишет отзыв, каждый тратит на вас в среднем допустим часа 3. Потом рекрутер сколько своего времени тратит, я не знаю, но пусть допустим еще 3.
А сколько еще затрачено на отвлечение программиста от непосредственной работы в плане уменьшения его производительности за счет отвлечения на интервью с вами? Можно еще по часу накинуть. А время изначальной подготовки каждого программиста к интервьюированию? Пару десятков часов, которое потом будет окупаться и размазываться по всем интервью. Думаю далеко не каждый программист за все время работы в яндексе проведет хотя бы 20 интервью чтобы подготовка размазалась хотя бы до часа. Но пусть будет 20 в среднем, еще час можно накинуть.
Итого получается 4 интервьюера * 5 часов зарплаты на каждого, плюс время рекрутера. На этом фоне оплата билетов и гостиницы даже не удвоит эти траты для компании. А вот вы при полетах в несколько раз увеличите затраты своего времени.
swelf
Надо найти компромисс
Если сделали оффер, то кандидату платят эти дополнительные 4 часа по ставке
Если оффер не сделали, то кандидат оплачивает компании 20+ часов по ставке сорудников.
VinBear
Инновационное решение проблемы, за такой уровень находчивости при решении задач на интервью сразу +1 левел надо давать по-хорошему
Wan-Derer
А ничего что "они первые начали"? Не автор к ним просился, а они его всяко зазывали. Значит — в данном случае им нужнее! Поэтому:
maxp
Чувак, может ты в Питоне и понимаешь немного, но проблемы и задачи при найме людей на работу не понимаешь вообще.
Snaffi
понимаю :-) обычно кодингом смотрят человек программировать вообще умеет или нет. Был неоднократно свидетелем когда собеседование проходили блестяще, а кодить не умели совсем.
Помню каким то образом в компанию прошел человек «сеньор помидор» который спросил «Парни, а что такое классы? не понимаю как они работают»
Я за то, чтобы кодинга онлайн было меньше, но он необходим :-) хотя бы физбаз
tommyangelo27
Физбаз можно без классов написать ;-)
baldr
Без классов все могут, а вот вы напишите с классами, синхронизацией потоков, репликацией Oracle и бэкапом в клауд на блокчейне.
SomebodyElse
Уже писали
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
MaslovRG
Как же мне больно на это смотреть…
0xd34df00d
Блин, первое апреля было же вчера. Теперь придется свой физзбазз выкладывать еще через год.
Ghostwriter
aphyr.com/posts/342-typing-the-technical-interview
anton19286
Только не добавляйте туда сториз и лайки )
ComatoZZZ
На сколько я понимаю на западе даже большие компании начали отказываться от такого подхода. Например в Амазоне уже давно не только алгоритмы и задачки а сильно лучше
anonymous
Не знаю, у меня так же было 3 интервью с алгоритмическими задачами + одно на архитектуру.
Stas911
Это на SDE?
anonymous
Ага.
amarao
merge sort на позицию админа. Факт.
saintbyte
4-5 собесов — это каким бездельником надо быть? Если они по часу это уже пол рабочих дня.
Ivan22
ну поэтому для экономии Яндекс и не посылает нормальных программистов собеседовать. Отправляет тех чье время не жалко… всяких рекрутеров, а качество интервью пытается заменить количеством.
BugM
Да обычные разработчики и тимлиды там собеседуют.
Иногда может даже крупная звезда попасться. Если на вакансию какого-нибудь Кликхауса пойти.
Stas911
Вроде во все крупные конторы финальные собесы собирают в один день, чтобы кандидату не нужно было сто раз мотаться. В Ковидом не очень актуально стало, но процесс менять не торопятся.
Sofrony
Я могу ошибаться, но вроде бы нельзя шарить задачи, которые были на интервью?
В гугле, во всяком случае, было так.
По вопросу почему так в Яндексе, ну да, знание базовых вещей сильно помогает потом разобраться в местных велосипедах. А что еще спрашивать? Про высоконагруженные сервисы тоже будет секция, если код пройдешь.
tmin10
Но почему на кодирование 4 собеседования?! Они были не уверены после первого? Вроде бы и кодит, но что-то тут не то, давайте ещё 3 раза повторим.
Sofrony
Там не только задачи разные, но и собеседующие, очевидно, чтобы исключить знание конкретной задачи и субъективизм конкретного собеседующего.
Дешевле не нанять хорошего разработчика, чем нанять плохого.
yanchick
ЕМНИП, чтобы уменьшить влияние мнения одного человека. Ок, один не получил то что хотел, но трое других были в восторге.
baldr
Обычно в таком случае все четверо приходят вместе. И спрашивают из широкого спектра, а не одни и те же задачки.
Я после 11 класса, помнится, и олимпиадные задачки решал, и сортировки все помнил… Но могли бы меня с теми знаниями взять сейчас на сеньора? Да упаси Нортон!
Сейчас уже все эти сортировки забыл за 20 лет, но знаю где лучше применить RabbitMQ а где Kafka, на каком сервере расположить сервисы и как их связать. А сложность сортировки я нагуглю быстро, если надо.
Kwisatz
С удовольствием бы почитал, а то, как человек, от которого развве что ноги торчат из бд, никак не возьму в толк зачем выводить за пределы транзакции критичные вещи (а все этим радостно занимаются)
Alex_333
Ну если автору плевать — почему нет?
ardraeiss
Под NDA нельзя поставить что-то без полноценного заведения оной NDA, с подписями, контролем доступа и всем таким, причём строго через "И".
Поэтому всякие подписи в письмах от рекрутеров "вот это письмо, которое пришло к вам без всяких подписанных бумаг, шарить нельзя" — фикция. Во всяком случае в России.
Устно договориться "давайте Вы не будете делиться?" — это только на уровне устной договорённости. То есть можно, но не обязательно.
Stas911
В Яндексе не требуют подписать NDA перед собесом?
PyerK
С каких это пор нельзя? часто ребята идут «по трупам друзей». Первый идёт, кому не сильно надо — разведка боем, просто собирает максимум инфы все вопросы что запомнит / запишет. Потом идёт более подготовленный товарищ, с уже заготовленными ответами на вопросы которые спрашивают на эту позицию. Последним идёт тот, кому нужно больше всего, и которому коллеги добыли максимум инфы. Ко мне всегда отделами ходят на собеседования из глобалов/интеллиасов/люксофтов. Правда такая подготовка для меня — очевидна.
sleepyNepeta
А вы сделайте им такое собеседование, к которому нельзя заранее подготовиться :)
Paskin
Это, кстати — фигня вопрос для более-менее опытного интервьюера. При желании, разумеется. Я в прошлой фирме задавал те же две задачи на протяжении трех лет, их опубликовали уже через месяц на местном форуме — и ничего, ни о ком из десятка принятых пожалеть не пришлось. Могу даже поделиться:
1. Дан PNG с изображением мяча. При загрузке страницы мяч должен появиться в центре окна браузера и начать двигаться в случайном направлении с заданной скоростью, отражаясь от границ окна.
2. Разработать архитектуру Веб-чата, для простоты — с одной комнатой для всех. Обосновать принятые решения и предложенные фреймворки/библиотеки.
BugM
1. Если отвлечься от фронта и конкретики, то обычные векторы и угол падения равен углу отражения. С небольшим рандомом если ровненько в угол попали. Чтобы пользователю больше понравится. Не точечная фигура добавит чуть-чуть математики, но опять ничего этакого.Что тут вообще такого?
2. А вот это неплохо. Вполне себе типичный вопрос на архитектуру.
Только зря вы про фреймворки и билиотеки. Какие у вас приняты те и берем. Какая разница в конце концов?
Если ничего подходящего у вас нет, то окей Гугл самое массовое и типовое. Опять же какая разница что брать?
Paskin
1. Не надо отвлекаться от фронта. 95% интервьюируемых понятия не имели как сделать анимацию в браузере (ни одним из способов). Тем, кто слишком углублялся в тригонометрию, не подумав что константы не обязаны быть одномерными — мы давали подсказки.
2. Это не холивара ради — а проверить, насколько человек «в теме» (а WebSockets почти у всех в CV). Если он/а может обьяснить и нарисовать, как это все должно работать (или работало в их предыдущих проектах) — то ничего искать и не нужно. Кстати, по поводу Гугла — мы дали предложение человеку, который честно сказал что с таким раньше не сталкивался, но за то время что мы ему дали — нагуглил что-то похожее, разобрался и вот что получилось.
janvarev
1. Скажем так — это простая, но непопулярная задача показывает, что человек вообще умеет кодить и в этот момент немного думать (про физику) )
2. Про фреймворки и библиотеки — тут как раз нетривиально, как архитектор говорю. Вопрос «как будете строить решения и что из библиотек/фреймворков» используете как раз позволяет оценить, как человек принимает архитектурные решения. «Гугл самое массовое и типовое» — это лишь один из стилей, он, кстати, кое-что говорит о кандидате :)
BugM
Как будете строить это замечательно. Архитектура чистая.
Вопросы вызывает только часть про фреймворки. Я допустим чаты не делал. При этом распределенные системы делаю и знаю. Бекенд, но не суть.
Я назову Спринг как отраслевой стандарт и окей Гугл что угодно для вебсокетов. Вроде же на них модно сейчас такое делать? Если что-то подходящее есть в Спринге это и берем, нет смотрим от Апаче итд. Что там будет мне глубоко все равно. Проблема точно решенная в разных библиотеках и в большей части библиотек она точно решена хорошо.
А дальше уйду в дебри кеширования и распреденных БД. Чтобы работать отказоустойчиво и вызывать максимум авто реконнект пользователей при выпадении чего угодно. И не падать когда набегут тысячи пользователей в комнату и начнут постить гифки с котиками.
Это все от фреймворков и конкретных технологий не зависит примерно никак. Хотите Редис, хотите Тарантул, хотите Постгрес, хотите Mysql. Хотите кубер, хотите пакетами можно катать все на любое число серверов. Все работает примерно одинаково. Можно сделать на любых стандартных технологиях.
janvarev
Чаты — тоже не мой профиль, но можно порассуждать — что вы, в принципе, и делаете. И это ок :)
У меня, например, первые вопросы:
1. Это встраиваемое в портал решение, или автономное? Или встраиваемое, но должно быть отдельным сервисом? От этого сильно зависит, как делать авторизацию — прокидывать ли ключи от главного сервиса, или как-то еще.
2. Ну, предположим, делаем модельное решение — доступ по ключу входа, без всяких проверок. Вопрос — на какой объем пользователей? Если у нас миниатюрный сервис до 50-100 участников и мы тестируем гипотезу, я бы почти вообще без библиотек сделал (ну, кроме сокетов, конечно, и, может, хранения сообщений, если есть что толковое под рукой). Зато выкатил бы через несколько дней. Или же у нас есть платная/бесплатная часть? Тогда как выделяем инстансы?.. В общем, тоже, уходим в дебри кеширования и распределенных сервисов (мне, кстати, ближе простенький монолит, но я и высоконагруженными системами не занимаюсь)
Ну, как-то так.
Про фреймворки — это, условно, вопрос «что вы вообще возьмете и зачем». Будете ли фреймворком закрывать архитектурные решения, или возьмете библиотеки и сами их склеите. Что сделаете сами, что делегируете библиотеке (я вот сокеты точно делегирую).
BugM
Авторизацию все делают одинаково давно уже. Насколько я знаю.
Пользователь приходит с кукой. Мы эту куку передаем внешнему сервису, он возвращает все что нам положено знать про этого пользователя.
Работает само и независимо. Это как то место где изоляции мало не бывает.
Кеширование в этом месте или запрещенно вообще или минимальное.
Распределенный монолит это хорошо и правильно. Его размер не выглядит слишком уж большим. Распределение делать все равно надо. Нагрузку на балансерах надо как-то распределять по бекендам, да и ребутать без даунтайма хочется иметь возможность. Как именно их синхронизировать и кешировать дело вкуса.
Мне нравятся зукипер, редис и любая sql бд. Если нужно сделать на etcd, Тарантуле и Монге могу и на них сделать. Ну потрачу я недели две чтобы разобраться с новыми технологиями. Мелочь по сути.
Делать один инстанс чего угодно без возможности подключить второй — это самая большая ошибка которую только можно совершить при проектировании. Исправлять очень дорого и сложно. Как правило проще выкинуть и написать заново чем исправить такое.
Если планируется настолько маленькая штука что даже два инстанса с синхронизацией делать кажется дорого, то стоит вообще не делать а походить по рынку поискать готовое решение.
symbix
Смотря что понимать под «нельзя».
Неэтично — да, конечно. А в принципе то как запретишь? Даже если в Яндексе установлен режим коммерческой тайны и они как-то умудрились притянуть к нему эти задачки, кандидат — не сотрудник, как ему доступ к коммерческой тайне оформлять?
sumanai
В
гуглеяндексе забанишь.kypluk
Шарить задачки, которых нет в интернете — подло с точки зрения компании, но яндекс в этот круг компаний не входит, тк взял все задачки с литкода и ничего нового не придумал.
Viceroyalty
Не знаю, я в свое время в яндексе ничего такого не подписывал.
valkumei
Очень много эмоций… На мой взгляд, в таких ситуациях по факту, можно спокойно рассказать о том, как и что ты проблематизировал в процессе коммуникации. Этакий дебаг, что произошло. А эмоции даже при изрядной правоте, выдают склонность к тенденциозности и желанию чтобы все представили ситуацию именно по твоему.
kesn Автор
Ну стиль у меня такой ?_(?)_/? Да, всё субъективно — рассказал, как это выглядело с моей стороны и что я чувствовал.
TheRaven
Получилось отлично, читал с удовольствием.
valkumei
По реакции видно, что у многих ощущения в собеседованиях похожи).
Люди забывают про горячее сердце и холодный рассудок…
charypopper
Какой смысл в сухом изложении, если большинство пойдет и получит такой же эмоциональный фон в подобной ситуации — это же не вопиющий случай, а политика компании. Наверно будь это не яндекс, было бы куча оговорок — "я не знаю как у других", "может зависит от того кто собеседует" и тд. и тогда сухое изложение может быть было бы уместно, а бурю эмоций можно было бы скрыть под спойлер
iiwabor
С таким подходом, очень вероятно, в Яндекс набирают одних олимпиадников. Это неплохо, возможно, но на самом деле алгоритмы в реальной работе нужны не очень часто — как правило используемые библиотеки уже оптимизированы.
Меня на моей предыдущей работе тоже на собеседовании жестко гоняли по алгоритмам и большому О. Когда приступил к работе, выяснилось, что из алгоритмов в ПО используются только геттеры и сеттеры)
baldr
Да, и стандартная библиотека олимпиадникам не нравится, они ее сразу переписывают сами :)
tvr
Под каждую задачу.
Stas911
О да, на одной из старых работ в начале 2000х коллеге не понравился стандартный парсер XML и он написал свой. Все даже неплохо работало, пока кто-то не кинул в систему документ с символами какого-то экзотического языка…
wataru
"На самом деле огнетушитель в машине нужен не очень часто". Зачем их вообще требовать и проверять на техосмотрах?
Дело в том, что олимпиадники, в подавляющем большинстве случаев, смогут использовать готовые библиотеки, перекладывать данные отсюда туда и всякую другую рутину. Плохой стиль кода у олимпиадников лечится всего за пару недель, если в компании есть код-ревью. А вот не умеющий в алгоритмы программист даже не заметит, что вот тут эта самая алгоритмическая задача возникла. И впендюрит n^2 вместо n log n. Потом внезапно прод станет тормозить, когда нагрузка возрастет всего-то в 10 раз. И придется экстренно искать это место и переписывать.
baldr
Да-да, олимпиадник. Он как раз вместо того чтобы взять готовое решение будет сам месяц писать велосипед. Потому что его натаскивали именно на задачи "война, stdlib убит, напиши свое".
wataru
У нас в гугле такого не вижу. Да, есть всякие внутренние фреймворки и библиотеки, которые имеют распространенные аналоги, но практически все они в компании сделаны раньше, чем эти распространенные появились. Есть собственная замена почти всему из stdlib в репозитории, поддерживаемая специальными командами (и работает сильно быстрее почти всегда). Никто из моей команды каких-то велосипедов не пишет.
sh0ck
You are not Google
wataru
Мой коммент:
Вы приводите ссылку на статью о том, что технологии применяемые в гугле не стоит бездумно перенимать, ибо они заточены под реально большие объемы, которых в большинстве других компаний почти точно нет. Что вы хотели этим сказать?
Если вы про контекст этого поста — то он о яндексе. Как конкурент гугла, хоть и на локальном рынке, Яндекс как раз одна из тех немногих компаний, где гугловые технологии тоже нужны. Опять же, я не понимаю, при чем тут ваш коммент.
sh0ck
Простите, я не считаю Яндекс компанией уровня FAANG. Это безусловно крупный локальный игрок, но по масштабам всё таки отстаёт. Яндекс не Гугл. Уже не Yahoo конечно но и не Baidu. Не надо им по всему миру размещать кешируещие сервера Youtube. Осмелюсь предположить, что stdlib на проектах тоже стандартный. Не верю что так же как в Google «собственная замена почти всему из stdlib». ИМХО нецелесообразно это для локального игрока на стагнирующем локальном рынке. Хотя, это ж Яндекс, какая может быть целесообразность?
wataru
Ну вообще, интернет большой. Искать по всему интернету — даже с учетом фокуса на рунете у яндекса — охренительный объем данных. Не знаю, сколько у них датацентров, но предполагаю, что далеко не один. Так что яндексу 100% нужны самопальные решения. Потому что если можно соптимизировать std::string на 1% — это огромная в абсолютных цифрах экономия, хоть и ничтожная в относительных.
Primala
Все верно.
Sofrony
> что stdlib на проектах тоже стандартный
ха-ха-ха
Viceroyalty
И уж точно не свой glibc
0xd34df00d
У моих прошлых «нас» тоже была своя stl (allocators gonna allocate ;) ), и работало оно ну так себе, особенно по части поддержки новых стандартов или совместимости с каким-нибудь бустом.
0serg
С вменяемым руководством — не будет. Главное их самих к руководству не допускать пока они не освоят подход «начинаем с проверки готовых решений». Но к счастью почти у всех это получается освоить очень быстро.
При этом я не раз видел как довольно быстро «готовое решение» «олимпиадникам» удавалось ускорить раза так в 3 а там где performance matters это довольно полезный скилл.
PyerK
Я правильно понимаю, что ускорить в 3 раза можно только тот алгоритм который изначально имеет сложность О(1) и О(N)?
wataru
Нет. Не обязательно. Взяли вместо O(N^2) сделали O(N log N). Там уже от навороченности алгоритма (константы) и конкретного значения N может получиться что угодно — хоть в 3, хоть в 100 раз быстрее.
PyerK
Я про общий случай ускорения ровно в три раза.
В моей практике, n-кратное ускорение обычно может быть достигнуто знанием архитектуры, но не алгоритма.
Обычно 2 порядка производительности лежат там где убираются списки, убираются денормализованные числа, заменяются деревья на хэш таблицы или данные перепаковываются что бы уложиться в кэш процессора, или распараллеливается, или чтото типа фильтр блума применяется, или замещаются сики на отображаемые в память файлы. Один порядок производетльности лежит в оптимизациях предсказания ветвлений. Процентов 20 лежат в неоптимальном TLB. Еще префетчер есть. Часто бывает что сложность алгоритма компенсируется латентностью памяти и переключением банков, инвалидации кэша, межпроцессорной инвалидацией данных. Часто где критична производительность и алгоритмов хитрых и не встретишь, просто терабайтные таблицы предвычисленных значений или другие ухищрения.
0xd34df00d
Ох, хоть один фаангист бы спрашивал про tlb хотя бы. Я уж не говорю о вещах вроде пеналти за simd-инструкции с разной шириной регистров на интелах примерно пятилетней давности.
PyerK
Я работаю на острие технологий, коллеги понимают кучу алгоритмов, в теме новейших математических и алгоритмических изобретений и публикаций. Но после них получаю задачи вида: «вот у нас алгоритм, на гигабайте работает неделю… прям сильно сильно надо что бы он 100 гигов отрабатывал хотя бы за выходные… мы его на месяц запускали, но даже не представляем сколько ещё осталось… (спустя некоторое время) как это на с++ за час отработал?.. а на 10 ТБ отработает? „
TheKnight
Вы его с Python без numpy переписываете на C++? Или с C++ на C++?
rg_software
Проблема в том, что про любого хорошего специалиста с глубоким знанием чего бы то ни было (компилятора, среды, архитектуры компьютера) всегда можно сказать, что у него есть «супероружие», позволяющее ему сделать то, чего не может другой. Да, карикатурный «не умеющий в алгоритмы» не заметит, что у него O(2^N), а карикатурный «умеющий» сделает за O(1), но на каждый типаж можно десяток таких карикатур придумать. Навыки должны быть сбалансированными, и хорошо бы проверять на собеседовании какой-то срез, а не что-то одно.
JustDont
И конечно же это чистое совпадение, что именно компании-средоточия-олимпиадников являются же главными центрами по производству софтверных решений, которые устраняют исключительно фатальные недостатки в самых разнообразных существующих технологиях.
Ну и уже на личном опыте: смогут использовать готовые библиотеки? Да, безусловно смогут. Будут ли использовать готовые библиотеки там, где их можно прекрасно было использовать? Скорее нет, если только не придёт признанный авторитет и не скажет таки использовать.
wataru
И еще одно забавное совпадение: большое количество этих "велосипедов" без фатального недостатка появилось раньше этих разнообразных существующих технологий.
0serg
И конечно же это чистое совпадение что именно компании-средоточия-олимпиадников являются лидерами рынка и «разнообразные существующие технологии» создаются зачастую именно ими.
Олимпиадниками нужно руководить, без руководства они естественно могут начать делать совсем не то что надо. Но любыми программистами надо руководить чтобы они не делали совсем не то что надо. И олимпиадниками руководить зачастую проще. Они, в числе прочего, умеют выбирать из готовых решений там где другие не видят особой разницы.
JustDont
Не наблюдал никакой корреляции. Умеют выбирать — те, кто умеют выбирать (как правило это те люди, которые уже обжигались на плохих выборах, или те, кто были свидетелями таких случаев). Олимпиадники к этому относятся ортогонально.
ardraeiss
И стали лидерами они до перехода на "строго олимпиадники" или после?
И пруф на "создано именно олимпиадниками" очень хотелось бы увидеть.
Primala
Ну какие олимпиадники? В описанном собеседовании уровень задачек для начинающих. Олимпиадники — это вообще другая лига. То, что автору давали на собесе — базовый уровень, ну.
santa324
В яндексе всё свое, им нафиг не нужны Ваши знания библиотек, фреймворков и т.п. А еще они большие и хотят сделать наем более объективным. Я видел в других местах ситуации когда лид набирает людией под себя и после его ухода их всех только увольнять, другие с ними работать не хотят.
В общем причины почему так нанимают есть. Но вот платят они мало и потому только студентов олимпиадников и могут нанять..
Kane
Вспмонилось как один кандидат спросил "чтО большое?"
Viceroyalty
Возможно этого достаточно, но вопрос — сколько яндекс таким образом теряет потенциальных специалистов по тем вещам, которые нужны в реальной работе
grub-itler
Жму руку. Как там… быть, а не казаться.
MayRiv
Я тоже не готовлюсь.
Но не исходя из моего высочайшего морального облика, а по эгоистичной причине — меньше тревожусь.
Вроде как если я зазубрил все типичные вопросы интервью, то я выдал себя за кого-то другого, и потом грызет синдром самозванца.
А если я просто прошёл собес «чистым» без подготовки, то что уж тут, глаза видели, кого брали:) И мне становится гораздо спокойнее, когда я с какой-то задачей разбираюсь не так быстро, как хотелось бы
leotsarev
Есть теория, что Яндекс понимает кого ищет.
Ищет людей с хорошим знанием алгоритмов и привычкой всюду смотреть на O(?).
Как найдет, дальше всему научит сам.
Мне такой подход не близок, но я не Яндекс.
Про то, что спрашивать про джанго на собеседованиях не нужно, я как раз с Яндексом согласен. Если ты крутой, дадут методичку, выучишь.
kalombo
Джанго — это практика, и именно по ней понятно какой у человека опыт и что он точно уже умеет делать. А алгоритмы сам Яндекс форсит учить перед собеседованием. Вот как раз по ним и надо давать методичку, чтобы выучить, если они понадобятся. Но в том и дело, что не нужны Яндексу алгоритмы в большинстве случаев, об этом программисты говорили в одном видео. А такой способ проверки программиста связан с размером компании, с тем, что с таким подходом меньше субъективности, говоря простым языком — бюррократия(например, чтобы токарь получал больше денег, надо не работать продуктивнее, а сдавать на категорию)
А вот то, что не надо искать человека именно с опытом Джанго и спрашивать от него каких-то хитрых подробностей фреймворка, если ему придется работать с Джанго на текущем месте работы — с этим согласен.
wataru
Выучить джанго все-таки на порядки проще, чем научится алгоритмическому мышлению и способности решать задачи.
baldr
С этим не поспоришь. Но хватит и пары задач чтобы это выяснить. А вот реальный опыт очень важен.
У меня есть хороший пример — на прошлой работе был коллега, матерый программист, еще TCP-стек для какого-то микроконтроллера реализовывал 30 лет назад, писал на всем что горит… Кинули его и меня на новый проект с Джангой. Дали книжку, которую мы за неделю прочитали и уяснили суть.
Как матерые ООПшники порадовались идее ORM и кинулись в бой. Красиво реализовали все на классах, а потом как пошла нагрузка — поняли что база не совсем любит наш подход и
select_related
не зря придумали.kalombo
Что вы подразумеваете под выучить джанго? Можно написать сайт визитку с 10 посетителей в день без тестов и собрав с помощью батареек необходимой функционал. А можно писать что-то посложнее с гораздо большим количеством посетителей, где надо, например, знать, что такое zero downtime migrations, грамотно организовать архитектуру app внтури django, покрыть всё тестами, организовать сбор метрик для мониторинга, CI, грамотно интегрировать свои компоненты во фреймворк используя паттерны программирования, оптимизировать SQL запросы, чтобы не было N+1 проблемы. Именно умение делать это и нужно в первую очередь работодателям, а не алгоритмы. И более того, умение алгоритмов не гарантирует АБСОЛЮТНО НИЧЕГО из этих навыков и никаких способностей решать задачу, оно гарантирует только умение решать синтетические алгоритмические задачи.
leotsarev
В том-то и дело, что Яндексу не нужен опыт. Нужна голова и способность принять условия игры. Несколько раз сказали — выучи, повтори алгоритмы. Если (а) согласишься (б) успешно и быстро подтянешь — то потом, когда тебе скажут разобраться с «Яндекс.Велосипедофреймворк», ты (а) не будешь спорить (б) быстро разберешься.
kalombo
Яндексу нужен опыт, в подтверждении этому у него есть система грейдов, да и на собеседовании он тоже проверяется и от него зависит зп. Да и вы сами подумайте, что вы утверждаете. Вы сейчас уравняли вчерашнего студента зазубрившего алгоритмы и программиста с 10 летним опытом в разработке высоконагруженного проекта. Хотите сказать, что яндексу без разницы кого брать? Если да, то вы сильно ошибаетесь. Да и опыт меряется не только знаниями фреймворка X, есть более фундаментальные вещи.
leotsarev
Система грейдов — чтобы удерживать людей со знанием «Яндекс.Велосипедофреймворк» в компании.
И да, система найма Яндекса устроена так, что сеньоров с рынка они почти не нанимают.
P.S. На всякий случай — я не из Яндекса, инсайдов нет, это мои наблюдения.
kalombo
Мне понятно откуда берется желание обесценить, но всё-таки давайте будем разумными и смотреть на цифры и факты. Считать что Яндекс, у которго сотни продуктов, петабайты данных, мегахайлоад, компанией, которая держится на студентах без опыта, посидевших 3 месяца на leetcode это в высшей степени неуважение. У них точно также внутри как у всех есть синьоры, мидлы джуниоры, которые получают разную зарплату в зависимости от опыта. Причем опыт меряется не фреймворками, а более фундаментальными вещами: работа с бд, паттерны проектирования, микросервисная архитектура, профилирование и отладка и т.п… Мерять опыт фреймворками — это тоже заблуждение, о чем я уже писал в предыдущем посте. Если вы пользовались какой-нибудь SuperMegaDistributedYandexDb, то и с Postgresql быстро разберетесь. Кроме того у яндекса есть, как вы выразились «Яндекс.Велосипедофрейморк» под названием ClickHouse. А React — это «Facebook.Велосипедофреймворк». Вы думаете фреймворки в лесу собирают, они там сами растут?
leotsarev
Нет, все правильно. Сеньоры в Яндексе естественно есть. Просто они не с рынка их нанимают
Primala
С удовольствием нанимают с рынка, если удается таких найти.
Просто представления о синиоре для Яндекса и для большинства «опытных django-программистов» очень разные.
Viceroyalty
Ага, а еще без опыта проще эксплуатировать и можно меньше платить.
vlad_egrv
ну тут двоякое, большинство все еще любят упарываться в типовые вопросы, знание ответов на которые никак и ни разу тебе не пригодятся в будущей работе и вообще никогда не пригодятся ни на одной из будущих работ
Dlougach
Мне кажется, вы словили джекпот — вам подсунули все самые популярные в Яндексе задачки на собеседованиях (сам, когда работал в Яндексе, очень любил задачку про симметрию задавать).
При этом, вы их все слили в интернет, так что сейчас все будут бегать кругами и придумывать новые.
kesn Автор
Я надеюсь, что что-то поменяется. А вообще leetcode большой. На крайний случай могу накидать 10 аналогичных по классу задач и предоставить Яндексу на безвозмездной основе.
BearStrikesBack
Да ничего не поменяется. Ну, поменяют они в задачке отели и гостей на завод и выпуск чушек — какая разница? Смысл этого процесса, как верно заметил один из авторов выше, в проверке вашей submissiveness. Если вы бесплатно ради гипотетического варианта трудоустройства готовы n-кратно учить литкоды, то на работе, столкнувшись с велосипедами, переработками и прочими приколами жизни в Яндексе — вы также согласитесь это все делать, не задавая вопросы.
vilgeforce
Пусть своим рекрутерам эти задачки задают, а то они не умеют в пересечение «нам нужны ...» и «кандидат умеет ...».
ferocactus
Ящитаю, это очень хорошо. Человечество от этого только выиграет. Если все так и будут
всегда поступать, со временем сформируется "база знаний" автоматизирующая решение подобных задач, высвобождая время для более полезных вещей. Хотя, конечно, есть некоторая вероятность, что потеря такого фильтра навсегда лишит общество некоего жизненно важного градиента, оставив нас в локальном минимуме эффективности. Но это скорее в предельно длительной перспективе, а на наш век всё-таки — одна выгода.
0xd34df00d
А как задачку про симметрию предлагается решать?
Если симметрия вокруг вертикальной прямой, то можно пробежаться по всем точкам и покидать их в мапу из y-координаты в массив x-координат точек на этой горизонтальной прямой. Дальше берем любой такой срез (состоящий, например, из точек с x-координатами x1...xn) и находим потенциальную x-координату вертикальной прямой из очевидного уравнения \sum_i (x — x_i) = 0, то есть, x =\sum x_i / n (физик бы сразу про центр масс подумал бы). Пробегаемся по всем остальным срезам и считаем их центры масс. Все совпадают — мы нашли прямую, не совпадают — ее не существует.
Код автора не читал, там питон, а это сложно.
swelf
тут есть подвох, 3 и больше точек не обязательно будут расположены симметрично. ну например 0,1,4,7, и все, прямой нет. Видимо надо пары отдельно сравнивать, от внешних к внутренним. а центр масс /= симметрия.
0xd34df00d
А, че-т я ппц тупанул, да. У меня там куда-то делся шаг проверки того, что это действительно точка симметрии для каждого среза, но это уже начинает плохо пахнуть с точки зрения вычислительной сложности.
snakers4
Автор молодец, я хорошо посмеялся, а я просто возьму и оставлю это здесь
https://blog.ploeh.dk/2021/03/22/the-dispassionate-developer/
Giperoglif
очень понравился стиль изложения с удовольствием прочитал. Из своего опыта собеседований: у меня было как раз наоборот. Как-то раз, когда-то давно, я зазубрил всякие определения ООП, паттерны и прочее, и с успехом прошел собеседование в очень крутую компанию на сеньора, имея 0 опыта в ООП вообще и совсем не большой в программировании в частности. Ну т.е. как раз таки случай «казаться». Слава богу, здравый смысл у меня победил и я туда не пошел, а пошел туда куда мне и была дорога — в джуны. Что забавно, при этом собеседование проходил мой друг у которого был за плечами очень большой опыт и его не взяли. Зубрить википедию накануне он просто не захотел, исповедуя верную мысль автора.
vilgeforce
Яндекс, IMHO, вообще славен письмами типа «Иди работать к нам! Язык G, задачи из области X», при том что ты не специалист по X, а на G и вовсе ни строчки кода не читал. Ах да, и работу получатель таких писем тоже не ищет!
Mnemonik
По моему многие просто неправильно понимают суть собеседования в яндекс. С чего-то им кажется что их туда набирают чтобы в дружном коллективе решать интересные задачи с помощью нестандартных подходов. Что будут какие-то глобальные задачи, где надо будет используя опыт предыдущих работ выдумывать интересную архитектуру которая способна справиться с этой задачей. Но эти должности в любой крупной компании уже давно заняты уважаемыми хорошо зарекомендовавшими себя людьми. Совсем не новичками со стороны. А новых сотрудников набирают сидеть и копать от забора и до обеда. Ну вернее сидеть и херачить то, что как раз те самые уважаемые люди придумают за вас. Никому не нужно ваше знание async/await или опыт предыдущих проектов, от вас как раз требуется прочитать что требудется выполнить в конкретной небольшой задаче, где уже всё будет написано что использовать и как «корпортаивно» писать за вас, и нахерачить максимально непротиворечивым способом чтобы это было лекго покрыть тестами. Чем меньше будет творчества в этом, тем лучше — тем стабильней будет решение.
И вот тут как раз со стороны яндекса это именно то, что они от вас хотят — чтобы кандидат мог стабильно сидеть и кодить что сказали, без фигни. А то если каждый будет выдумывать как ему и что делать, каждый подтянет свои любимые библиотеки в проект — любой проект на дно пойдёт.
Так что может это вам было не интересно, а яндекс-то как раз проверяет всё как надо яндексу.
Viceroyalty
То-есть они могли бы выбрать не алгоритмы, а любую другую область программирования и так же проверять вашу совместимость?
Например, дать необычную (странную) либу со странной же документацией, дать задание разобраться и сделать, а самим следить за моральным состоянием кандидата и тем как он реагирует на подсказки/напутствия?
ilammy
Добавьте сюда ещё другой аспект: когда к тебе стоит очередь из желающих пособеседоваться, её надо бы как-то проредить с минимальными затратами для компании, чтобы не тратить время на тех, кто и не собирается становиться сотрудником, но хочет большую честь или там строчку в резюме ну хоть кого-нибудь.
Одного мема «в Яндексе/Гугле/Иксе гоняют по алгоритмам» достаточно, чтобы часть из этой очереди поумерила пыл — и вообще не пришла сразу, а ушла готовиться — не тратя время компании на это.
Всё ещё слишком много времени уходит на собеседования? Добавляем в ротацию домашнее задание и отсеивается ещё часть людей, которые не хотят тратить своё время — и таки образом не будут тратить время компании.
Всё ещё не помогает? Полируем раундом-двумя-тремя онсайт-интервью на четыре часа — часть людей отвалится сразу как только их об это предупредят, а с «выжившими» можно и поговорить.
infund
InterceptorTSK
Прям таки действительно «улыбает» со всего этого. Нет, не «позиция» автора. И не «позиция» какого то яндекса. Складывается стойкое впечатление, что ни те ни другие не способны даже файл открыть и распарсить за действительно минимальное время.
Ну потому что автор — это питон и это конечно же смишно))
Ну а яндекс вообще ничего не спрашивает про железо, и это тоже смишно)
Ибо не зная как работает конкретная ОС, как она настроена, какие железки стоят т.е. контроллеры и винты и т.д. — почитать и распарсить файлик за минимальное время совсем не получится. И что бы опиративку оно не выжрало как не в себя. И что бы у бгмерского коллектора голова не закружилась. Слушайте, а тогда зачем вам это всё?)
Кому вообще нужен мееееедлееееееенный код? Идиотам? Хз хз… Даже теряюсь в догадках…
Какие то абстрактные кони в вакууме…
п.с.: Нет, я категорически не против алгоритмов и я категорически не против вхлам тормозного питона, однако же я против того, что существует так называемое абстрактное программирование. Нет, это не ооп. Абстрактное программирование — это программирование насмерть оторванное от железа. Однако же если юзать такое вот абстрактное программирование — ничего хорошего не получится, причём по определению. Сие даже не нуждается в доказательствах.
sh0ck
А чем вам AWS Lambda не угодил?
Stas911
Тем более, что сейчас захочешь — до железа не доберешься, тк оно если и есть где-то там в темной глубине виртуальных машин, то плотно обложено гипервизорами до полной невидимости :)
iClo
Закусывайте.
SoundsResounds
М, я думал, что фон Нейман свою архитектуру вычислительных систем затаскивал именно для того, чтобы абстрагироваться от железа при решении прикладных задач, а тут воно как.
AlexWoodblock
Даешь код, меняющий напряжение на элементах напрямую!
dmitryikh
Сам был участником подобных собеседований в FAANG. Поэтому было интересно узнать, почему собеседования проходят именно таким образом: 3 кодинг сессий, 1 дизайн системы, 1 поведенческая.
Для себя сделал такой вывод:
1. Большой поток кандидатов, сложно объективно и индивидуально подходить к каждому.
2. Решая алгоритмические задачи, кандидат показывает свои когнитивные способности. Способность понимать подсказки интервьюера, способность находить и обрабатывать крайние случаи. Отбираются кандидаты с хорошей соображалкой, а уж по скиллам место внутри многотысячной корпорации найдется.
3. Подготовленный кандидат (over 50-100 решенных задач на leetcode, например) также показывает свою мотивацию получить работу в компании.
Ivan22
Ну даже я после первой 100 проведенных однотипных интервью догадался их автоматизировать и проводить скопом сразу на 20 человек (но офлайн, чтобы без читерства).
Areso
Типа, как экзамен в универе?)
Или как семинар?
Застал, когда на экзаменах на бумаге нужно было писать код, который потом лаборанты/аспиранты набивали и проверяли, работает или нет :)
Viers
Из хорошо проведённого кодинг интервью можно вообще массу полезных сигналов вытащить.
+ Насколько вменяемо кандидат общается с интервьювером в процессе решения задачи,
+ Как кандидат себя ведёт, если встречает алгоритмическую задачу, которую раньше не видел. Пробует примерить на неё все паттерны подряд, делает решение «в лоб» и оптимизирует, залез под стол и кричит?
+ Как он то, что понаписал, собирается тестировать? Код хоть приблизительно читаем?
+ Нашёл ли кандидат крайние случаи, уточнил ли все места где задача была недостаточно определена, смотрит ли на вычислительную сложность…
Автор, кстати, хорошо показывает откуда берутся статьи «Винда полчаса сортирует значки рабочего стола» и «GTA V зачем-то парсит гигантский json на каждый чих». А что, «сложность алгоритма в реальном программировании нужна целых 0 раз», интерсектом бахнем да и норм :)
JustDont
Теперь бы еще понять, откуда берутся статьи «Гуглопочта весит 6.7Мб и её практически невозможно* открыть на плохом канале».
Ах да, это же не про сложность алгоритма, какие могут быть претензии.
* — в прошлом, с некоторых пор гугл изволил починить логику отображения ссылки перехода на «легкую» версию гуглопочты, и теперь по крайней мере её можно без проблем нажать
0serg
Так именно при подходе «просто подключим тут для решения проблемы Х (решается одной страничкой кода) библиотеку N (10 мегабайт кода)» и возникает «гуглопочта по 6.7 Мб».
JustDont
Гуглопочта написана на собственных технологиях гугла.
1) Так что же, их собственные офигенные решения не такие уж офигенные?
2) Куда делись все олимпиадники при написании гуглопочты?
wataru
Это, конечно, звучит как "сперва добейся"… Но попробуйте сделать гуглпочту более лучше. Я не встречал ни одного другого почтового клиента с таким набором фич, с поддержкой того же количества трафика.
JustDont
Гуглопочта, до того момента, как она стала гуглопочтой на 6.7Мб — была такой же гуглопочтой, но весьма более скромного размера.
А еще до этого она была гуглопочтой без SPA (это то, что сейчас существует как "облегченная версия"), и там с размерами и скоростью загрузки тоже было всё просто наишоколаднейше.
Так что вот "другие клиенты с фичами и траффиком" — это всё та же гуглопочта, просто не то, что сейчас предлагается по умолчанию, а исторические её варианты.
wataru
И там не было ни автодополнения, ни отмены отправленных сообщений, ни чата и кучи других функций.
JustDont
Да ну нет конечно. Тот же hangouts в почте с незапамятных времен, и в прошлой он тоже был. И в новой он, подозреваю — один из самых скромных по размеру компонентов. И вообще в момент радикального утолщения почты там не было никаких прорывных фич добавлено, по крайней мере относящихся непосредственно к почте.
Фичи уже потом пошли. И самое забавное, что размер гуглопочты они особо не увеличивали.
Bellerogrim
Да не нужен в ней чат! Это почта! Мне не чат нужен, а мгновенное удаление писем! В 2021 году удаление письма занимает 5 секунд, в течение которых нельзя закрыть вкладку!
wataru
Вам — не нужен. А другим пользователям удобно — одна вкладка всегда открыта для связи и там собрано все.
Edit: сидите тогда на html версии и не знайте горя.
BugM
Так Яндекс же. Чего далеко ходить.
wataru
И там тоже есть автодополнение, чат, оффлайн режим?
BugM
Автодополнение есть.
Чат в одном клике. Правильное продуктовое решение.
Оффлайн режим есть в мобильном приложении. В вебе нет. Тут вы правы.
Если такая тяжесть gmail обусловлена оффлайн режимом, то стоит сделать галочку для его выключения. 10х ускорение работы стоят того.
onlinehead
Из того, что я вижу, автодополнение полностью на сервере сделано, на каждый новый символ отправляется запрос (весьма сложно структурированный и включающий в себя все содержимое письма), в ответ на который приходит или не приходит возможное автодополнение. Причем на каждый ввод символа сообщение пересылается целиком. С точки зрения объема клиентского кода это не выглядит очень уж весомой фичей для мегабайта кода. Не считая того, что на так себе канале оно будет жуть как лагать.
Чат — лучше бы его можно было выключить, если им не пользуешься. Hangouts — боль и страдание, с проблемами входа в комнату и подобным. Ух я им наелся, когда с гуглерами работал, у которых кроме него ничего нет.
А offline mode — а он не работает фактически. Да, он позволяет открывать письма в текущем ящике (правда при этом отваливаются пиктограммы над письмом), но к примеру в черновики не попасть.
Зачем оно нужно вообще в таком виде?
wataru
Да, это нужно. Тут вам повезло, что словарь в питоне работает быстро. Но если не знать что как работает, то можно, например, написать то же самое со списком. Получить квадратичный алгоритм и получить дикие тормоза, когда нагрузка на прод возрастет.
rg_software
Ну тут ещё вопрос культуры языка и среды. В C++ (STL) алгоритмическая сложность каждого метода является частью спецификации и прописана в документации. Соответственно, даже если человек вообще не очень в алгоритмах смыслит, ему эти "линейное время" и "логарифмическое время" постоянно глаза мозолят. И хорошо что мозолят, везде бы так.
wataru
Если человек эту алгоритмическую сложность не понимает, то все эти заклинания из документации просто проходят мимо мозга.
rg_software
Это факт. Однако понимание алгоритмической сложности можно минут за 15 выяснить.
Ilirium
Статистический подход к собеседованию. Проверяют на однотипных задачах всех кандидатов на позицию, каждый интервьюер выставляет оценку, в итоге сравниваем некую среднюю метрику и можем выбрать среди кандидатов лучшего по метрике. В итоге, результат найма не зависит от конкретного интервьюера или того, что некий кандидат чуть больше прочитал в документации на фреймворк X про фичу Y. При этом, т.к. компания большая, то финалист собеседования сможет разобраться во внутренних фреймворков, а не только использовать шаблонные best-practice из SO для условного Spring/Django.
Как еще делать в большой компании, чтобы избежать влияния личности на результат, и чтобы можно было сравнить нескольких кандидатов между собой?
Если что, мне тоже не нравятся алгоритмические собеседования и тем более, подготовка к ним.
PS Дополнил спустя 5 минут. Еще нужно попутно держать в голове, что нужно избежать проблему кумовства, найма по знакомству, «он хороший человек», по принадлежности в группе (к примеру, он из моего универа, города) и т.п. В маленькой компании эти проблемы не важны, в крупной — я думаю будет не в кайф оказаться в коллективе, где все друг друга знают по еще какому-то признаку и прикрывают друг друга, а сторонний человек становится изгоем.
baldr
Автоматизировать? Предложить решить 100 задач на том же литкоде в удобное время?
Нет, лучше назначить в рабочее время звонок на минимум час времени и сопеть в наушники пока кандидат потеет в стрессе. Повторить через день. И потом еще неделю так же.
Где-то видел чей-то комментарий на тему "когда меня спросили есть ли у меня вопросы я сказал что есть — мне хотелось бы тоже знать уровень тех, с кем я буду работать. И тоже предложил им решить при мне задачку". Мне кажется это может немного охладить интервьюеров иногда.
Ilirium
Литкод не решит задачу списывания, к сожалению.
A114n
А как её решит любое удалённое собеседование? Я видел правила для удалённой сертификации, когда принимающему экзамен нужно камерой показать всё пространство вокруг рабочего стола, но вряд ли эти правила соблюдаются на собеседованиях.
wataru
По крайней мере интервьювер видит кандидата. Тупо подсказки соседа и гуглеж уже невозможны. Хитрости со скрытыми наушниками еще работают, но в интервью при живом общении такие странности видны. Если кандидат после каждого вопроса несколько минут тупит, а потом идеально отвечает — это будет отражено в отчете интервьюера.
wataru
Та же проблема что и с предложением принимать профиль на гитхабе на интервью.
Списывание, читерство и обман.
miga
Мне кажется, вы не видите за деревьями леса. Когда вас гоняют по (иногда?) тупым задачкам, хотят вовсе не получить их решение, а достать т.н. «сигналы» — как кандидат себя ведет, как размышляет, как комментирует свои действия, как тестит свой код (каким бы простым он ни был).
При этом само решение тут, гм, решающей роли не играет — по большому счету, вы можете ее даже не решить или решить неправильно, но все равно набрать себе очков, если все делали правильно (и это логично, потому что кому нужны олимпиадники и литкод-ковбои в продакшене :) ).
И да, я (уже) не провожу собеседования в яндекс, это просто мои соображения, основанные на том, как сейчас мы собеседуем к себе. И конечно же есть нерадивые интервьюверы, которые из-за лени или по запарке просто посмотрят на формальное выполнение задачки и потом дадут отписку эйчарам, мол, этот решил — его берите, а этот не решил — его не берите.
JustDont
Эта популярная отмазка Яндекса ("вы, если чё, можете решить всё неправильно, мы принимаем комплексное решение, основываясь на всех аспектах") не бьется с практикой: тем, кто на задачособеседованиях решает неправильно, тут же говорят "извините, дальше мы вас не будем собеседовать".
0serg
Так кандидату на собеседовании будут давать подсказки.
А если он даже с подсказками не может решить, то это явный звоночек о проблемах.
KirillGerasimov
Я проходил несколько технических интервью в яндекс, как успешно, так и не успешно. Если вы решаете с подсказками хотя бы одну секцию — вы получите за нее сниженный балл и с большой вероятностью не пройдете.
0serg
Ну я не знаю как в яндексе. У нас конечно тоже чем меньше подсказок тем лучше (особенно на сеньорские позиции), но несколько подсказок не зарезают возможность пройти (а для джуниора достаточно вообще хотя бы часть задачек решить). Иначе какой смысл вообще давать подсказки?
LevOrdabesov
«Как ведёт себя кандидат, сталкиваясь в бесконечным однотипным потоком задач, кажущихся бессмысленными, от людей, которым он не может отказать».
Ха-ха (сквозь слёзы).
И ведь работает, набирают, кодит у них там кто-то.
miga
Это ли не обычный рабочий процесс, не так ли? :)
LevOrdabesov
Безусловный базовый доход нас спасёт. Наверное.
F0iL
Так что с тех пор с Яндексом никаких дел иметь особо не хочется, о чем я вежливо говорю их HR'ам, которые стучатся чуть ли не каждую неделю и почему-то искреннее уверены, что все просто должны мечтать работать в Я.
Am0ralist
Предложите их интервьюверам пройти ваше собеседование, чтоб вам можно было понять хотите вы работать в яндексе или нет)
siziyman
Как уже сказали, это утверждение неверно.
Яндексу. Почему-то. Хотя зачем люди идут унижаться в Яндекс за всем этим, когда можно пойти хотя бы в Гугл с теми же предусловиями (плюс английский, окей), мне совершенно непонятно.
miga
Почему зря? Вы показываете, как вы решаете проблемы и коммуницируете, на вас смотрят, оценивая, подходите ли вы. А потом бы желательно еще оставить минут 5-10 на вопросы кандидата — про процессы и все такое. Но это, конечно, в идеале.
Другое дело, что, к сожалению, программисты — зачастую, очень неприятные люди :) Поэтому частенько нарываешься на такой отвратительный подход к проведению интервью — формальный, на отъебись, лишь бы эти чертовы эйчары отстали и можно было бы вернуться к любимому перекладыванию жсонов. И эйчарам, в свою очередь, насрать на то, как эти интервьюверы работают — лишь бы вакансию закрыть худо-бедно.
Так и живем.
siziyman
Люди вообще зачастую очень неприятные, чивоуштам. А если чуть серьёзнее — так задача менеджмента и отдела по работе с персоналом выстроить процессы так, чтобы очень неприятные люди как минимум не собеседовали кандидатов за исключением крайней необходимости, а в полном идеале так вообще не попадали в компанию (но это уже сложнее, и ещё и платить надо деньгами, и вообще шевелиться много), или, если попали, исправлялись по мере возможностей.
miga
С задачками кстати реально проблема, потому что какие попало задавать же тоже нельзя, они должны быть калиброваны по сложности.
В конечном итоге мы, кажется, приходим к выводу, что собеседования — это сложно, да
followmyutopia
Вот я думаю, пройдёт аффтар ещё десяток уровней собеседования, решит всё, и возьмут они его на работу. А потом руководство найдёт эту статью, да и обидится на слова «в яндексе всё как-то тупо».
Без обид, разбор задачек крутой)
k102
Ну их можно понять, но это не делает процесс лучше. Типа — ну да, мы в крусе, что ты знаешь %фреймворкнейм%, но вдруг ты ничерта кроме него не знаешь и надо «проверить какие-то базовые вещи». Типа такой тест на самозванца.
Имхо имеет смысл спрашивать что-то в духе «а что тебе больше нравится из этих вот технологий?». Ответ показывает и знание и заинтересованность (которой у самозванцев нифига нету)
wataru
И в итоге такое интервью будут проходить люди с хорошо подвешенным языком. Заболтать интервьювера на такого вида субъективных вопросах — не то чтобы очень сложно.
k102
Да ну нет же. Как заболтать в ответ на вопрос «а почему тебе это нравится? а покажи на примере?».
0xd34df00d
Даже не знаю, как бы я показывал на примерах типобезопасность всяких хаскелей, да так, чтобы не выглядеть религиозным фанатиком.
BugM
Вам для этого целый js придумали.
k102
Да в общем фанатизм это не так и плохо — если человек от чего-то фанатеет, значит он это понимает
ryabsky
После 9 таких собеседований в Яндекс мне сказали, что они не готовы меня взять. Не знал, что чтобы отказать человеку, нужно провести 9 собеседований)
Sofrony
Значит ты был близок, живи с этим. :)
zagayevskiy
Скорее всего это значит, что много интервьюеров сказали что-то в духе «нанимать, но не к нам в команду». Ищите проблему в себе.
zzareyan
Мда, слоны боятся мышей…
Во-первых, удачи, во вторых я бы подождал постить это, так как они могут увидеть и, сам понимаешь, тайна компании, и.т.д.
А так, скоро наверное и GIL с Multithread будут ненужны, за них всю работу будут делать сервисы Амазонки и Ажура. Вот тогда наверное и будут спрашивать о них :)
kesn Автор
Тайна? Приходите на собеседования, и вот тайна перед вами.
Я NDA не подписывал, если что.
Viceroyalty
Забанят автора в яндексе?
roman_lulin
Флешбеки словил. У меня не так все долго было и после 2 или 3 задачки отказали. Мы параллельно весело болтали с интервьюером, и я в их блокнотике в .append скобки квадратные написал. Меня это никак не оправдывает — я сам тупень, но сейчас прям благодарен этим скобкам.
При всем этом, Яндекс остается хорошей компанией для работы.
Самое веселое, что эти собеседования, скорее всего, результат «работы» очередного эффективного менеджера. А репутация не манагера, а компании. Ну и вспоминается анекдот про строителя мостов и овцу.
Sofrony
Могу тебя заверить, отказали не из-за скобок.
yngui
Яндекс возомнил себя Гуглом, хотя даже в Гугле подобной фигнёй не страдают.
Sofrony
Поделись плиз своим опытом. Мой — очень похож с разницей в яп.
yngui
Не верю, что в Гугле дают кучу задач на кодинг, к тому же однотипных. Стандартное интервью — 2-3 medium/hard с leetcode и system design в зависимости от позиции.
wataru
В гугле 3-4 алгоритмических интервью. Но это не 10 задач. Обычно дают 1 задачу с дополнительными вопросами. Вроде: сначала напишите совсем простой случай. Потом а что если у вас данные вот такие придут?
yngui
Согласен, 3-4 задачи на алгоритмы.
anonymous
Интересно, а это может от региона, в котором находится офис, зависеть? Ну, например, в Калифорнийском офисе у гугла побольше дают задачек, а в Дублине или, там, восточной Европе — поменьше. Или у них на всех один стандарт?
wataru
Гайды одни и те же. Конечно, могут попасться интервьюверы, плохо оценивающие опыт кандидата. Он, может, думал 1 задачу + дополнительный вопрос на все интервью, а кандидат все решил за 20 минут. Тогда задачек будет побольше.
jumpercc
Насколько я понимаю, в таких собеседованиях хотят проверить не только алгоритмическую подкованность и желание работать в Я (если хорошо подготовился и порешал задачки — значит, хочет сильно),
но и понять, как кандидат думает и насколько хорошо вливается в коллектив разработчиков.
Возможно, навыки, необходимые для решения таких задач, положительно коррелируют с результатами в Яндексе.
Учитывая количество внутренних велосипедов в Яндексе, часто у кандидата могут актуальные навыки только на таком низком уровне (stdlib, конечно, тоже, но тут не знаю, почему её знание не проверяют).
Сам недавно проходил такие секции — впечатления неоднозначные.
darkAlert
я там понимаю в гугл или фб гоняют по собесам, но там и зп соответствующие. А яндекс то что может предложить? зп которая ниже чем средняя по рынку, ниже чем у многих других отечественных контор, где на собесах по делу спрашивают, а не экзамены устраивают. Есть еще плюсы?
Вот, сходил даже за первым попавшимся примером:
1) вакансия в яндекс на дата аналитика:
2) ниже сразу какая-то небольшая контора из питера, тоже дата аналитик:
alexdevyatov
В Google зп тоже ниже рынка
sumanai
А там разве не акциями отыгрываются?
smartello
Чтобы это было правдой, надо очень избирательно очерчивать рынок. Не забывайте про акции, которые докидывают каждый год если средненько (на общем фоне) работать.
wataru
Ну не правда же. Считать надо с акциями. Гугл действительно платит достойно.
greatvovan
Ну опять вот это всё. Смиритесь уже, что никого не волнует знание Django или SqlAlchrmy. Это всё наживное, если мозги есть, человек разберётся. А вот закодить эффективный алгоритм для хай лоада — это уметь надо.
strannik_k
Так и алгоритмы — это наживное) Если мозги есть, то при необходимости научится писать более сложные и эффективные алгоритмы.
wataru
И как на интервью проверить, что мозги есть? Понятно, что лучший способ — взять человека на испытательный строк в пол года, чтобы уж наверняка. Но это непозволительно дорого.
strannik_k
Если компания может себе позволить тратить время на собеседование сотен и тысяч кандидатов, то видимо так, как и делают FAANG и yandex. Если у компании нет таких ресурсов, то вряд ли есть эффективный способ проверки мозгов и найма специалиста выше джуна. Задачки по алгоритмам не покажут знания и опыт, но могут отсеять много опытных, как и плохие вопросы по теории. Я склоняюсь к тому, что вместо лайфкодинга лучше дать кандидату кусок кода и попросить рассказать, что в нем делает каждая строчка. Дать куски с явно плохим кодом и просить, что в них стоит отрефакторить. Не программисты или совсем новички с этим не справятся, да и опытные не отсеются. Ну а далее особо и нет вариантов, кроме как проверить знание используемого кандидатом и компанией стека, а также понимание некоторых важных в разработке вещей, и нанимать того, кто показал себя лучше остальных. Дальше уже как повезет. Конечно же это не универсальный способ и подойдет не всем компаниям.
PsyHaSTe
Вроде уже несколько раз прозвучало выше что яндекс таким образом нанимает людей, которым можно внушить корпоративные ценности и которые не будут задавть лишних вопросов. Как показывает эта статья — со своей задачей они справляются, автор отсеился, а если бы прошел то сам бы свалил в течение пары месяцев "задачи мусор и инициативы вообще не дают".
Это раз, второе — когда у вас гигантский поток заявок то нужно отсеивать хоть по каким-то признакам. Хоть по цвету кожи, хоть по гороскопу, хоть по байке "зачем нам нужны неудачники". Если вы физически не можете проводить единолично 100 собеседований в день и на первый взгляд все резюме +- одинаковые — все прекрасные крутые спецы с кучей опыта и интересными проектами — то приходится фильтровать хоть как-то. Например разделить 100 кандидатов на 20 подчиненных и попросить их пройти какой-нибудь бессмысленный формальный критерий. Ну и дальше от них уже отсекать какой-то процент.
Kroid
PsyHaSTe
А зачем? если можно улучшить корреляцию и вместо 0.1% шанса найти кого нужно сделать 0.2% шанса назойливыми вопросами — то это в целом удвоение качества поискав 2 раза, хотя 99.9% и 99.8% отказов со стороны кажутся примерно одним и тем же.
Ну то есть не факт, что человек знающий алгоритмы — молодец, а не знающий — лохопед. Но зачастую хороший разработчик шарит и за базовые алгоритмы, а если нет — то придумает на ходу. У меня недавно собес был, спросили про MESI (алгоритм когерентности кеша в цпу), а я ни в зуб ногой. Помню что лет 5 нзад в википедии читал про него, в памяти осталось только что там 4 режима работы. Ну и как бы ничего, с подсказками от интервьювера минут за 20 переизобрел режимы и зачем они используются. Просто исходя из простой логики разработчика с опытом работы с многопотоком.
Точно так же изобретал каналы — для меня это всегда была штука куда ты пихаешь данные и они с другого конца видны — без мьютексов и каких-то других дорогостоящих синхронизаций. И тоже — не интересовался никогда, но после предложения "давайте вы попробуете придумать такую структуру данных, думаю у вас получится" и некоторых подсказок тоже смог придумать и spsc и mpsc каналы. ИСЧХ теперь я думаю я это навсегда запомню — вымученное таким трудом запоминается.
В итоге да, вместо часа интервью заняло почти два, и незнание каких-то вещей в целом не помешало успешно пройти (позвали на второй и третий этап) собеседование. Задачка это бусидо — не цель, но путь. Важно не решить задачу, а продемонстрировать свои навыки в процессе. Например вот так.
Vilaine
PsyHaSTe
Ну я раздумываю насчет переката в HFT, жсоны перекладывать я все же научился, а вот красиво выжимать перфоманс из железа — не очень. Надо развиваться)
railroadman
Я чего-то не пойму первое задание безвоенное задание что-то выдает не то, а во втором варианте есть несколько описок
result.append(el) # то это успех
b_dict[el] -= 1
zazar
Я тоже запустил второй код и получил пустую строку.
P.S. Там в третьей строке надо вместо
писать
ivan2kh
Сделал для себя такие выводы.
1.5. Интервьюеры Яндекса тратят свою жизнь впустую, вместо работы на результат.
Sofrony
Почему впустую? Пару раз в неделю потренироваться искать ошибки в чужом
говнокоде — вполне себе полезно, в остальное время они пишут прод.ivan2kh
Каждый сам выбирает чем заниматься
LuigiVampa
О, по моему скромному опыту, это одна из самых любимых задач у всех собеседующих. Не раз задавали на собеседованиях в самых разных компаниях. Возможно это как то связано с тем что она всегда выпадает в топе выдачи по запросам вроде «какую задачу дать программисту на собеседовании»
Alexandroppolus
В JS она тривиально решается однострочником с регуляркой.
wataru
Плохая идея. Почти наверняка будет на порядки медленнее. Регулярки — сильный инструмент, но им очень легко выстрелить себе в ногу.
baldr
А можете показать этот тривиальный однострочник? не троллинга ради, просто интересно.
Alexandroppolus
Могу, эти сведения не содержат гостайну. Выражение вернёт новую строку, можно проверить в консольке браузера.
Вряд ли это будет на порядки медленнее, как предположил wataru. Регулярка тут простая, линейная, забирает подстроку и тут же заменяет. Вручную ничего не выиграем, по крайней мере в js.
smartello
swtch.com/~rsc/regexp/regexp1.html. Регулярка медленнее и медленнее нелинейно. Это хорошее решение если вы уточните что на входе, как часто вызывается, где рантайм (клиент или сервер) и тд. Нельзя просто сказать «и так сойдет», это будет «no hire».
Alexandroppolus
Нелинейное время работы регекса зависит от бэктрекинга — как далеко и как много придется возвращаться при поиске. В моей реге бэктрекинга вообще нет. По факту здесь даже нет "поиска шаблона", просто тупой однократный обход символов, то же, что пришлось бы кодить руками.
smartello
И то правда, но он же будет строить автомат, разве нет? А потом его закидают строками по 1 символу.
wataru
Я был не прав. Эта регулярка, действительно работает за линейную сложность, как и ручной разбор. Там будет сколько-то оверхеда по сравнению с ручным разбором, да.
WblCHA
Я хотел бы для себя уточнить, решение через
*
имеет преимущество перед+
или это просто на скорую руку так получилось?Alexandroppolus
Да, ваш вариант лаконичнее (и скорее всего более быстрый), я на скорую руку набросал, с излишествами.
Valeratal
по сути Яндекс не могут проверить ТС на реальных задачах (потому что не знают или потому что секурность или потому что хрен знает что надо делать завтра) и гоняют его на простых задачах, как проверяют выпускников вуза/курсов
Чтобы понять, как у него мозг работает, вынослив ли :)
ну как если бы грузчика нанимали, дал ему мешок и пусть туда-сюда 100-метровку бегает
самого выносливого (и терпеливого) берешь :)
wataru
Реальные задачи обычно большие и сложные. Или тривиальные, типа перекладывания данных из одной структуры в другую. Выбрать что-то, что можно задать на интервью — весьма сложно. Плюс секретность, да.
undersunich
Я похожее уже проходил и в данном формате даже в Яндексе и даже Микрософте уже проходить не буду.Ушел бы после второго задания
lllepemetbeb
В начале 2020го довелось пройти собеседование (и в итоге получить оффер и отказаться от него) в Яндекс на позицию automation qa на python. Процесс был почти как у автора поста, только без блока Архитектура, ну и все задачки на всех встречах были уровня leetcode-easy. В процессе всех встреч произошел небольшой сбой и мне удалось не под запись и без протокола открыто пообщаться с одним из интервьюеров без последствий для меня и него. На мой вопрос «а почему собеседование проходит именно в таком формате а не в другом?» он прямо ответил, что они тоже читают все эти посты на хабре и все понимают, но у компании в приоритете брать олимпиадников, своего рода «гиков» и уже внутри делать из них кого нужно компании. Опыт показал, что для них это более выгодный путь. На мое замечание, что так они могут упустить действительно крутого спеца, он сказал что да, возможно, но они могут себе это позволить.
alexshy
Итак, главный вопрос к Яндексу:
— Какова сложность сортировки персонала при подборе?
alecsisk
Разделяю мысли автора. Сам завалил собес в Яндексе на первом этапе на вопросах вроде:
Суть в том что это используется каждый день и гуглится за 5 минут, а сложность интуитивно понятна и без этих о-нотации. Зато не было ни одного вопроса по архитектуре приложений (рука-лицо). С тех пор Яндекс и его дочки обхожу за километр.
kesn Автор
UPD. Ребзя, я тут понял, что фраза "интервью шли один за другим" может быть неправильно понята. Сорри, я имел в виду, что 2 и 3 интервью были одно за другим, а вообще между 1, (2и3) и 4 собеседованиями проходило несколько дней а то и неделя. Так что тут я не в претензии, время я выбирал удобное мне. так что за это яндексу плюс.
Статью отредактировать не могу, у меня зависает UI хабра, даже в разных браузерах.
balberbro
Итого:
Дрочат людей, пока не остаются самые покорные олимпиадники, которые «хотят» попасть в могучий и всесильный яндекс. Это позволяет эксплотировать людей, рассказывая о великий целях, занижать зарплату, тормозить карьерный рост и удерживать кадры.
Ибо очевидно, что обычный человек с нормальной психикой и уже имеет опыт работы в других компаниях уже после 2 собеседования сказал бы, что это какая-то мудохрень, и у него нет больше времени и желания играть в литкод по 5 раз без фидбека в пустоту.
___
Поэтому очевидно, что если вы адекватный спец с опытом работы — то лучше просто игнорировать офферы от яндекса. Ибо вы не тот человек, который им нужен. Просто потратите свое время, пока они поймут, что вас нельзя задрочить.
DigitalBerd
Когда я последний раз собеседования в Яндекс — зарплату они предлагали на 30% ниже рынка.
SpiderEkb
Мда… Хорошо что в свое время не повелся на эту тему…
Уже работая там где работаю :-) получил неожиданно письмо от яндыхового рекрутера. Некоторое время пытался объяснить девочке что работу уже не ищу, что текущая работа устраивает и все такое. Как об стену горох. То ли ей за каждого кандидата, которого она на собес затащит, баллы идут вне зависимости от результата, то ли она действительно уверена, что яндых есть предел мечтаний для каждого разработчика.
Ладно,
договорились что встречусь по скайпу просто поговорить. Чем занимаются они, что умею я, что мне могут предложить…
Началось с того, что в назначенное время в скайп засунулся интервьюер и сказал что интервью переносится на полчаса. Ну ладно… Может форсмажор какой…
Через полчаса наконец состыковались. И началось сходу «я тут вам подготовил ряд тестовх заданий...»
Стоп. Мы так не договаривались. Я уже давно вышел из возраста юноши пылкого со взором горящим, олимпиадные задачки меня не интересуют — это вы для джунов оставьте. Мне интересно чем вы там вообще занимаетесь и есть ли там для меня какой-то интерес.
Хотите проверить — задавайте конкретные вопросы из жизни. Как решить вот такую проблему. Или с какой стороны я бы подошел вот к такой задаче. На понимание сути, так сказать.
В общем, проговорил ему что-то в этом плане и попрощался. Товарищ, похоже, так и не понял. Ну и бог с ним.
chernish2
Засунулся!
Это же Вы у Эдуарда Успенского взяли, правда?
SpiderEkb
Не знаю :-)
Просто в голову как-то пришло само. Всплыло из глубин подсознания, а уж как оно там оказалось… Может и от Успенского (хотя не могу сказать чтобы когда-то серьезно им увлекался, хотя наверняка что-то его читал/слышал).
volchenkodmitriy
Спасибо, смешная статья! Во всем виновата пандемия. Собеседовался в Яндекс-Деньги на позицию Системного администратора в 2019 году. Все было нормально, но потом про меня забыли… ни да ни нет т.е. нет.
baldr
Эм… Вы все еще ждете ответа после фразы "мы вам перезвоним"?
yeswell
После моего супер-провального собеседования в 2019 (были две задачи: про отель и нули с единицами, обе решил частично) мне через две недели прислали письмо, сказали что не подхожу, надо решать задачи на литкоде и попробовать ещё раз через полгода.
volchenkodmitriy
И даже дожидаюсь, так было почти со всеми местами, где я работал.
Stas911
Если после собеседования рекрутеры не связываются, чтобы сообщить результат кандидату — это сразу в черный список.
Interreto
Я бегло посмотрел ваши решения и хочу сказать что вам надо подтянуть базовые знания о LIFO/FIFO и рекурсии. Многие представленные здесь задачки имеют лаконичные решения через стек или рекурсивный обход. Удачи!
kesn Автор
Насчёт рекурсии — они ж обязательно спросят, а что будет если на вход подадут 10k элементов?
Alexandroppolus
Ну вот тут LIFO и понадобится. Любую рекурсию можно переписать в цикл+стек. Зачастую и стек не нужен, как в каноничном примере с факториалом.
Sofrony
Конечно, но понимание рекурсии хорошо тем, что ее всегда можно развернуть.
Keeper7
Всё будет хорошо. Память всё ещё дешёвая.
Areso
флегматично: если покупать её не на свои
WASD1
выбрать язык, с эффективным TRO (tail recursion optimization)
BugM
Язык на проекте обычно уже есть. И менять его сложно, дорого и нужен очень веский повод для этого.
stardust_kid
Мне кажется, цель этих бессмысленных и изнурительных для обеих сторон этапов это не столько проверка ваших скиллов как программиста, сколько проверка вашей способности подчиняться и выполнять команды. Вроде как солдат пехоты заставляют многократно выполнять строевые команды, смирно, вольно и т. п. В бою это не нужно, но тренирует человека бездумно делать то, что ему приказывают.
Mike-M
Спасибо за статью.
Теперь понятно, почему у сервисов яндекса столько простых проблем.
И да, на картинке «Этапы интервью» ни слова про soft skills…
moodpulse
С одной стороны я понял боль автора.
Но с другой – Яндекс ведь ищет тех, кто им нужен? Схема отработана уже абсолютно.
Тут у него не было обязанности сделать процесс собеса максимально простым и комфортным.
Была задача отсеять ненужных и найти нужных.
Viceroyalty
Как бы это помягче? То что схема работает давно и позволяет нанимать удовлетворительных кандидатов не означает, что она отбирает тех кто лучше всего подходит компании.
moodpulse
Однозначно сказать действительно сложно.
Но сейчас так же нельзя сказать, что оно работает плохо.
Думаю, что компании виднее, как и что надо делать, процесс явно налажен.
Похоже чем больше кандидатов, тем сильнее повышают порог входа.
Viceroyalty
Что не мешает нам обсудить правильность решения, да и не всегда компании видней и чем она больше, тем тяжелее что-то менять.
Am0ralist
Хотя за последнее время они сильно выдавили меня из своей инфраструктуры, которую я почти 20 лет активно использовал.
Вот, сейчас периодически думаем, куда почту переносить… в связи с периодическими проблемами и неадекватной ТП. И решение будет уж точно не из разряда «заплатить за это яндексу», перейдя с бесплатного на платные тарифы. Потому что отношение к клиенту такое, что отбивает желание даже пробовать.
MacIn
И вот она — 58я серия фильма «я думал, будут спрашивать про реальные задачи, а они хотят алгоритмику» на Хабре.
Астанавитись!
JustDont
Может, в этом случае человек не только решил неправильно, но и показал себя, как не умеющего думать? Это вовсе не взаимоисключающие, а скорее, наоборот, связанные вещи.
Ghooost
Яндекс (ФБ, Гугл) большой, сложный и разнообразный, потому кажется, что собеседовать на конкретный стек смысла немного. В любом случае вас нужно будет дообучать и вводить в проект. И фреймворки в этом масштабе — копейки. Выучите если не знаете, никуда не денетесь.
В этом принципиальная особенность — большая компания может себе позволить нанять вас и не ждать, что вы начнете бешено закрывать таски как только вас пустят в сеть. Постепенно, нагрузка ваша будет нарастать постепенно. Но постоянно :)
Важно понимать, что пройти собеседование — это не конец. Ну наточились вы конкретно на алгоритмы или вам повезло — вы продали себя дороже, чем вы стоите. Значит дальше вам будет очень сложно и тяжело. Вывезете — отлично, все в выигрыше. Не вывезете — ну вас выгонят после испытательного срока. Риск для вас тут даже выше, чем для компании.
Так что собеседования вроде описанных — просто фильтр, нужный для того, чтобы уменьшить количество соискателей до разумного предела. Все самое сложное и интересное начнется позже :)
baldr
Простите, вы про наем кого сейчас говорите? Студентов на джуниорские позиции? Тогда ок, обучайте сколько угодно.
Смысл брать опытного разработчика в том, чтобы он принес свой, возможно новый, опыт в компанию/проект.
Dolios
Какого именно опытного, из тех 30 опытных, что претендуют на 1 место в команде?
baldr
А вот нет у меня формулы универсальной, простите. Я всегда предпочитал чтобы человек сам рассказал о своем опыте. Заодно видно насколько он общительный или конфликтный.
Если человек собеседуется на вакансию senior Django developer и рассказывает как он, к примеру, писал API (и какие библиотеки использовал), какие были проблемы и как решались (не обязательно им самим, а командой) — то я не буду его заставлять писать сортировку если он адекватный. И уж точно я не буду давать ему 10 разных задачек на алгоритмы.
Dolios
Ну, вот представьте, что у вас 30 таких адекватных, которые писали API, а выбрать надо одного.
А вот в этом и основная проблема. Многие ругают алгоритмические собеседования, но не предлагают альтернативы. Альтернативы для компаний уровня ФААНГА, когда на одно место претендуют десятки человек.
Алгоритмические интервью (если они проводятся правильно) — это не интервью на знание алгоритмов, это проверка того, как кандидат может думать. Потом, кстати, обычно следуют интервью на системный дизайн и поведенческие, не нужно думать, что все ограничивается одними задачками.
baldr
Очень просто — если их 30 человек и все адекватные (и прямо все подходят), то до последнего просто не дойдет очередь. Уже после 5 собеседований я перестану тратить время и выберу из пяти. Субъективно, конечно же.
Dolios
У вас собеседования идут параллельно, вы не можете себе позволить год собеседовать. И, естественно, эти 30 адекватных идут вместе со 170 неадекватными. А еще будет печально, если последний окажется самым талантливым с самым ценным для вас опытом.
Вы мыслите категорями маленькой компании. В гуглах и амазонах мыслят по-другому.
Я вот недавно собеседовал человека, который говорил, что он писал апи, казался адекватным, владел теорией и т.д. А как попросил его написать код, даже не алгоритмичускую задачку решить а написать банальный кусок, похожий на то, что каждый программист пишет каждый день, понял, что код писать человек не умеет. Он ключевые слова языка неправильно писал.
baldr
Ога, зато по 4 часа (как минимум) собеседовать каждого по одной только теме вы можете себе позволить..
А когда вы, наконец, прошли все эти 200 собеседований и выбрали самого-самого, наняли его… И через неделю вам попадается самый-самый-самый! Вы будете увольнять предыдущего?
Давайте не будем углубляться в какие-то непонятные споры. Тут все приводят уже совсем странные примеры.
Суть статьи — на собеседовании на позицию "Senior Django developer" компания провела 4 собеседования для одного кандидата и еще ни разу не зашел вопрос о Django и чем-то хотя бы смежном. Вы считаете это нормальным? Сколько еще будет считаться допустимым?
Dolios
Вы правда думаете, что гугл, амазон, фейсбук и прочие не умеют считать деньги?
Не попадается, вакансия закрыта, набора на нее больше нет.
Я пишу про ФААНГ, там обычно собеседуют на позицию software developer engineer, а не django developer или jquery developer.
Не вижу проблемы взять на позицию синьора человека, который джанги в глаза не видел. Это не принципиально. Если он действительно синьор, разберется. Если это, конечно, не набор на временный проект, который через пол года завершится. Пока вы ищите и умного и красивого, конкуренты возьмут умного, а красоту наводить его потом научат.
baldr
Я с вами не согласен уже в этом вопросе, но спорить больше не буду.
Sofrony
Не надо увольнять предыдущего, в Яндексе примерно 1к открытых вакансий.
Viceroyalty
Зачем отбирать всех, можно отобрать лучшего из тех из кого Вы можете отобрать, Вам же нужно хорошо закрыть позицию, а не найти чемпиона из всех возможных кандидатов — это разные задачи.
Я согласен с оратором выше: возможно, OptimalBest(A[0;5]) > StrangeBest(A).
YgReEk
Вообще-то у этой задачи есть вполне себе математическое решение.
При должной фантазии, она элементарно масштабируется на любое количество кандидатов (например каждый интервьюер собеседует неделю или только 10/20/n кандидатов и передаёт лучшего наверх; можно ещё потом сравнивая лучших обратить внимание на вторых/третьих среди отсечённых, поиграться с весами выборок, закодить на основании этого нейронку и так далее).
Можно даже предложить решать эту самую задачу по найму в Яндекс/Гугл/Али/etc. кандидатам, всё веселее будет (а заодно и давать максимально прозрачную обратную связь о критерии отбора и месте сотрудника в этом общем рейтинге). Можно пойти дальше и автоматизировать данный процесс, давая людям задачки и ведя рейтинг лучших. В этом случае рекрутеры собеседуют постоянно, а найм происходит только когда человек:
Или математическое решение, алгоритмы и автоматизация это не для крупной компании?
Upd: Ниже ссылка на эту задачу уже есть, проглядел (и извиняюсь), но оставлю в рамках шуточного предложения алгоритмической задачи на собственный же найм.
wataru
Ох и представьте себе, сколько же ненависти по поводу собеседований вы будете читать от людей, которые вошли в "калибровачную" стадию, если такой подход использовать.
Но даже без этого, тут есть большая разница. В задаче о невесте нет никакого знания о качестве вариантов. Там могут приходить числа любой размерности. При найме же предел отлично известен (все знающий и умеющий сеньер). Еще, особенно в больших компаниях типа яндекса-FAANG, нужно нанять не одного кандидата, а многих и поток кандидатов можно считать неограниченным. Вот и получается, что идеальное решение — установить нижнюю планку требования кандидата и при прохождении ее сразу нанимать.
YgReEk
Можно попробовать найти win-win решение и на калибровочную стадию звать преимущественно тех, кто не готов к активному найму и ходит мир посмотреть, да себя показать. Как вариант, оплачивать такую калибровку или же договориваться на иных взаимовыгодных условиях (хотя сходу в голову такие не приходят, кроме качественной обратной связи, пусть и машинно-сгенрированной).
Что до сходств и различий…
Есть обобщение задачи, где каждому можно сходу дать абсолютную оценку (пусть будет та самая близость к сеньору в вакууме, работающему за идею). Да и известность предела при найме лично для меня под сомнением: сеньор в вакууме — это как бесконечность при сравнении конечных множеств (а людей всё же меньше 8 миллиардов и далеко не все из них могут подавать заявки на найм). Вроде и очевидно, что больше любого из вариантов, а вроде и информации никакой не даёт. Поэтому с данным аспектом не соглашусь.
Что до найма не одного, а 100/1000/N кандидатов из бесконечного потока — так я потому и писал, что задача масштабируется элементарно: нужно выбрать лучшего из бесконечного потока — решение есть и известно. Нужно выбрать второго лучшего — убираем первого и решение тривиально. Чтобы не гонять цикл — можно запоминать статистику и вести рейтинг. Чтобы держать рейтинг актуальным — добавить всяких весов типа как давно собеседовался, на каком этапе поиска был найден, как сравнивался топ из этой выборки с топами из другой выборки, чтобы оценить в принципе состав исходной выборки и так далее.
Dovgaluk
Неправильно же, 10.8 первых нужно выгнать
PS Хотя нет, тут же к прошлым можно возвращаться
Viceroyalty
Не думаете, что адекватный опытный разработчик просто обидится и уйдет? А вы наймете совсем не того кто лучше всего Вам подходит, а того кто лучше всего прошел Ваше неоптимальное собеседование?
Dolios
Нет, не думаю. Все ваши предположения перечеркиваются одним простым фактом: в фаанге полно адекватных разработчиков и очередь тех, кто туда готовится очень велика. Я раньше тоже думал, как многие тут. А когда стал решать литкод и глубже изучать алгоритмы изменил свое мнение на прямо противоположное. Имхо, это нужно любому синьору, оно, в итоге, помогает в работе и приводит мысли в порядок. Особенно сисдиз.
Viceroyalty
У вас есть данные, что эти разработчики пришли туда именно через такой каскад тестовых задач?
А зачем стали решать литкод и изучать алгоритмы, что за область применения? Просто для себя решил пока не тратить время на Кнута, вроде оно в вебе не ценится.
Dolios
Это как-бы стандарт интервью в фаанг. Если вы не Линус Торвальдс, у вас будет такое же интервью, как и у всех.
Хочу в фаанг. Но потом просто интересно стало. Более глубокое понимание алгоритмов, их сложности, применимости и т.д. помогает в работе. Я это с удивлением заметил. И не только я.
Я фуллстек. Начните не с Кнута, а с лекций Седжвика на курсере. Начните решать литкод, там есть челлендж, когда в день нужно решать 1 задачку. Вот апрельский. Это правда интересно само по себе.
В телеге есть группы единомышленников.
mdevaev
> Это как-бы стандарт интервью в фаанг.
Это называется «карго-культ». Один придумал остальные подхватили, причем без понимания того, надо оно действительно или нет.
Dolios
Бывает и такое, да. Почему вы решили, что в случае с Яндексом это так? У вас есть какой-то инсайд, вы работали в компании на найме не линейным специалистом?
mdevaev
Я бывший яндексоид, работал там 9 лет.
Dolios
Это не отвечает на поставленные вопросы. Линейным специалистам часто некоторые вещи кажутся глупостью, потому что они не видят всей картины.
mdevaev
> Это не отвечает на поставленные вопросы
Отвечает в достаточной степени. Я не буду вам щас расписывать всю подноготную ради вашего праздного любопытства, особенно учитывая вашу предвзятость.
> Линейным специалистам часто некоторые вещи кажутся глупостью, потому что они не видят всей картины
Зато карго-культисты видят всю картину, ага-угу.
Dixi.
Viceroyalty
А знание алгоритмов Вам было нужно в работе?
mdevaev
Конечно. Но далеко не в такой мере, как это пытаются подать фанатики собеседований литкодом. Обзорное знание алгоритмов и понимание алгоритмической сложности было вполне достаточным, потому что в реальности всегда можно было взять справочник по алгоритмам после того, как система изучалась на предмет возможных неоптимальных мест.
Написание абстрактных алгоритмов на коленке переоценено. Умение проектировать архитектуру и видеть пути оптимизации — бесценно. Эти навыки пересекаются мало.
Viceroyalty
Спасибо успокоили, а то уж думал, что развиваюсь в неправильном направлении.
Viceroyalty
Интересно само по себе — не моя тема. Испытываю удовольствие когда код решает свою задачу, а не от его крутости как таковой. Не замечал, что знание алгоритмов помогает в работу, правда я фрилансер, хотя математическое образование имеется.
Am0ralist
Интересно, что ж могло пойти не так?
Ghooost
И вы его [ваш опыт] без всякого сомнения принесёте, тут вы правы. Но переписать поиск с нуля вы не сможете. Вам в 99% случаев придётся вливаться в большой сложный проект, в котором годы ежедневной работы десятков а то и сотен ваших коллег, которые тоже не случайные люди в профессии :) Так что обучаться и во многое въезжать вам все равно придется. И уже потом вы канешна привнесете что-то свое. А то и инициируете переписывание все заново. Но не раньше :)
Alexandroppolus
В задачке 4 subranges не нужен, там достаточно помнить текущий максимум, длину предыдущего ренжа (либо 0, когда справа от него него более чем на один нолик) и накапливать текущий. Вот вам и O(N) памяти на пустом месте…
Ну и в 10 задачке картина похожая. Накапливаем текущий ренж, пока он меньше суммы. Если превысил, сдвигаем начало вправо. Тоже всё линейно и без доп. памяти.
dimaal
В 10й задаче отрицательные числа, а значит нужно тащить суммы всех диапазонов с собой
iAMDiver
Автору спасбо за крутой слог и лёгкий стиль изложения. Браво!
QUARI
Проходил как-то собес в Яндекс на React разработчика. Ни одного вопроса про React! А я хотел рассказать как он работает, про ЖЦ компонентов и как их использовать, про мидлвары, про различные способы хранения состояния приложения и т.д.
ПС я там не работаю
snikulov
Давно так не смеялся. Автор, с меня пиво если пересечёмся!
Doublesharp
kesn спасибо за статью. А зп обсуждалась до тестового?
kesn Автор
Рекрутер говорит, что у них нет вилки и ты сам говоришь, на какую зп рассчитываешь. Я говорил "минимум 150, цель — 200".
Я так понимаю, что от озвученной зп зависят их ожидания на тестовом. Я с такой ценой нацелился на середину. Зп говоришь до заданий.
vvk123
Очень кисло для такого уровня геморроя прохождения интервью. В забугорную компанию можно устроиться на большие деньги и с гораздо меньшими усилиями (stackoverflow jobs и иже с ними).
picul
Если Вы не в состоянии качественно решить простые алгоритмические задачи (а в статье все задачи простые) — то даже будучи гуру фреймворков Вы не сможете создать качественный продукт. Я не предлагаю зубрить весь литкод, но задачи на «пройдись по массиву» / «посортируй и пройдись по массиву» проблем вызывать не должны.
С другой стороны — позиция Яндекса в этой ситуации вызывает мягко говоря недоумение. Предлагать пройти весь этот ад из собеседований с однотипными задачами, что бы потом получить… 200К? Видимо, работать у них — большая честь.
saterenko
Автор красавец, изложение — огонь.
Два раза ходил в Яндекс на собеседования just for fun, а потом в профиле на линкедине написал «Яндекс не предлагать».
Прикольный офис, прикольные ребята. Из приятных воспоминаний симпатичная блондинка, гонявшая меня по плюсам. Программист, с которым мило поболтали про файловую систему линукса (тут моих знаний было мало). И то ли синьёр, то ли лид, который мне доказывал в терминах big-O, что моё решение работать не будет, но я ему прогнал несколько итераций на бумажке и показал, что работает как требовалось, ушёл задумчевый.
Осталось впечатление, что Яндексу не нужен мой опыт, им нужно отличое знание спецификации языка и умение решать олимпиадные задачи.
Stas911
Это все понятно, но что там с блондинкой-то? :)
saterenko
Валила меня немилосердно :) Дальнейшая её судьба меня не интересовала, у меня есть собственная блондинка )))
Kknewkles
kesn а можно ваши задачки попробовать? :D
BioHazzardt
spiceginger
В фейсбуке такие же интервью предлагают. И причем их надо рожать в моем случае на свифте, ны котором в силу специфики работы обычно не держишь в голове всякие там строковые сдвиги и вещи как из Char получить String и обратно плюс всякие там copy-on-write и даже если помнишь какое то решение из универа для свифта его надо модифицировать. И это при точ что я в итоге родил им за 5 часов собеседования все алгоритмы. В итоге они остались чем то недовольны. На что я им сказал что они уже на этих алгоритмах наняли 2х моих бывших коллег которых я нахожу одними из самых паршивых программистов и я переписывал за ними то что они наархитектили, и раз они еще чем то не довольны, значит наверное мне не место в этой компании. А самое забавное что эту же моду взяли самые захудалые мелкие конторы.
megaentwickler
Мне кажется, или суть поста в том, что человека отинтервьюировали не так, как он хотел?
megaentwickler
Дайте пояснения, минусуя
baldr
Я не минусовал.
В целом, да — интервью прошло не так как ожидал человек. Но по вашему комментарию можно понять будто вы думаете что это что-то плохое.
У человека же есть какое-то самоуважение. Вы 10 лет работали над довольно сложными задачами, у вас опыт на реальных проектах, вы идете общаться с людьми, которые вроде бы даже должны быть выше вас по уровню… Но вас спрашивают то же самое что и студента 4 курса, а об опыте, который нужен по описанию вакансии — ни слова.
Это обидно, в первую очередь. Конечно, 1-2 задачи — без проблем, но 4 часа! А остальное будут спрашивать? Еще 8 часов?
Areso
суть поста в том, что сторона нанимателя ушла в
megaentwickler
Ну, значит, сторону нанимателя это устраивает. Если нанимаемого не устраивает, он волен покинуть «театр абсурда», а не писать потом негатив в сторону нанимателя.
Где, укажите мне, прописаны каноны, по которым надо проводить собеседования?
baldr
А почему он не может написать свое мнение? Обязательно только позитив писать?
megaentwickler
Возможно, я не совсем понимаю специфику этого ресурса. Для меня это всё ещё место, где люди обмениваются знаниями, а не место, где люди делятся переживаниями. Может, после этого срача я поменяю мнение о нём :)
Areso
Если выкинуть эмоции из статьи и комментариев, то можно оставить:
1) перед собеседованием вас попросят подготовиться к решению алгоритмических задач (Ок)
2) вас будут гонять от 2 до 10 раз по собеседованиям с разными людьми, на которых вы будете решать одинаково несложные задачи от easy до, если повезёт (или не повезёт, зависит от вашего отношения к таким задачам), middle уровня сложности.
3) вас будут спрашивать «а можно лучше/быстрее? помните про сложность алгоритмов». иногда будут подсказывать.
4) вас не будут спрашивать про интересные вещи, теорию, устройства интерпретатора/компилятора или давать задачи сколько-нибудь похожие на задачи с бизнес-логикой.
Вполне себе знание.
Хочешь в Яндекс? Полируй алгоритмы, и терпение, потому что без терпения 10 раз сходить на одно и то же упражнение не все смогут :)
megaentwickler
Доходчиво, спасибо!
anonymous
2) Почему несложные? Автор самостоятельно вроде бы не решил ни одной (с оценкой сложности, проверкой граничных условий).
Areso
Где, укажите мне, прописаны каноны, по которым кандидат не может сказать своё «фи», в том числе публично?
Kroid
megaentwickler
Вообще-то я задал вопрос о том, правильно ли я понял посыл автора, но завязался спор, который наводит на некоторые мысли, и я не могу его так просто покинуть, так как истина ещё не родилась
CDK
> а не писать потом негатив в сторону нанимателя.
Это называется «фидбэк». Надеюсь нанимающая сторона это понимает.
oYASo
Разработчика на позицию разработчика просят закодить задачи, а человек недоволен. Это же вот прям самое понятное и объективное, что можно на собесе сделать: решил/завалил, быстро/медленно и т.д. Куда уж лучше, чем обсуждать UB в каком-то говнокоде, который вообще в прод не должен был попасть, либо какие-то специфичные особенности языка/либы. Или там «почему люки круглые?».
Думаю, многие из отписавшиеся тут пишет со стороны соискателя, а не нанимателя. Я за свою карьеру уж давно провел больше сотни собесов, и могу с уверенностью сказать, что умение болтать, рассказывать про фреймворки и технологии вообще никак не коррелирует с написанием кода. Бывает, кандидат рассказывает, как он там всю архитектуру проекта заделал, как он там всех техлидил, на всех существующих языках писал, а по факту даешь задачку как из поста выше, и человек ее даже за час нормально без багосов написать не может. Было, что и пропускали таких кандидатов, и потом это реально оборачивалось проблемами для всех.
Самые крутые кандидаты, с которыми я общался, а потом и работал, на собесах быстро и молча щелкали такие задачи. Прочитал, рассказал, что будет делать, пару минут постучал по клаве, сдал. Смотришь — лаконичный код, все граничные условия проверил, сложность оптимальная, багов нет. Классный кандидат за полчаса решит три задачи из поста, и это почти стопроцентная гарантия, что кандидат и в работе будет классным как специалист.
Когда ты раз сходил на такой собес — кажется, ой, ну какие-то дураки там сидят, фигню спрашивают. А по ту стороны сидят ребята, у которых уже глаз наметан на эти задачи, на типичные ошибки, на понимание того, как кандидат мыслит. Иногда даже по уточняющему вопросу на задачу можно понять, какого уровня приблизительно сидит кандидат.
Спрашивать про django, sqlalchemy и т.д. практически бессмысленно, потому что внутри на все есть свои либы. То есть спрашивать такие вопросы норм в компаниях, инфра которой строится на них, но это точно не про Яндекс и FAANG. Если человек не может быстро взять какой-то инструмент и начать им пользоваться (в т.ч. языки программирования), то в таких компаниях на большинстве позиции он вообще будет профнепригоден.
Дальше, чтобы там не говорили про собесы в Яндекс, коллеги там реально крутые, то есть система отбора все-таки работает. Среди твоих коллег всегда будет кто-то круче тебя, всегда у кого-то будет шире компетенция, всегда есть у кого поучиться. Джуны и мидлы уходят на старших/ведущих разрабов в другие компании, а старшие и ведущие вообще валят куда хотят, потому что уровень и кругозор их сильно выше, чем в среднем по рынку (тут, на мой взгляд, Я внутри в этом плане ведет плохую политику, но это уже за рамками поста).
И чисто мое мнение: публиковать задачи один-в-один, какие бы они не были — какой-то адский зашквар для специалиста. Где-то на уровне обиженного админа, который паролит доступы для бывших коллег после своего ухода. Я даже когда кому-то из друзей рекомендации куда-то делаю, не рассказываю про задачи, только в общих чертах (разберись с этим, почитай то, освежи память здесь). Опять же, получается, система подбора Яндекса выиграла, что не наняла вас, раз вылились такие вещи.
// мимо бывший яндексоид
megaentwickler
Прекрасный спич!
baldr
Даже когда были вопросы на собеседованиях про круглые люки (да, я сам их тогда задавал тоже, прошу прощения у всех!), то тоже всегда были люди которые говорили что без них нельзя, почти дословно, простите на сарказм:
Ну да, быстро нагуглил трендовые инструменты и понеслась! Помним mongoDB в каждом сайте 10 лет назад?
oYASo
Я не знаю, про каких людей, компании и задачи вы говорите. Но чисто для статистики могу сказать, что среди моих друзей, кто увлекается какими-то интеллектуальными играми (ЧГК, Квизы и прочее) больше толковых разрабов, чем из нет, кто не увлекается. Вероятно, с люками также.
Ну и надо понимать, что найм людей в условный гугл и в местячковый КБ с IT отделом — совершенно разные случаи.
Да, как-то так. Чтобы поправить строчку в Го сервисе, мне не надо изучать Го. Потом, принципиально новых инструментов не так много появляется, большинство крутятся вокруг какой-то идее со своими нюансами.
SpiderEkb
Чтобы поправить строчку, надо сначала ее найти. Среди тысяч других. А чтобы найти (по описанию дефекта типа «у нас тут должно быть так, а по факту вот этак») нужно этот код прочитать и понять что и как он делает.
oYASo
Ну да, а вопрос в чем?
Сегодня Го сервис поправить, завтра запрос в базу долговато ходит, послезавтра что-то ручка пятисотит. Умение быстро диагностировать проблемы и решать их — ценно, и за это бизнес готов платить деньги.
SpiderEkb
Вопрос исключительно в том, что не зная языка сложновато понять код, на нем написанный. Во всех его тонкостях.
Могу поспорить, что Вы не скажете в чем тут ошибка:
if %check(%trim(chDInp): '0123456789') = 0;
Оно скомпилируется. И будет работать. Но неправильно. И будет дефект.
Или вот такое:
setgt (CRF: DInp: Ist: qdsGZRRL1.GZOSI) RRU01LF;
if %found(RRU01LF);
…
endif;
Тоже скомпилируется. И тоже будет работать. Но неправильно.
Чтобы понять почему надо таки знать язык на котором это написано. И тонкости работы его встроенных функций.
oYASo
У меня есть много решений этой проблемы:
1) найти автора кода и спросить у него
2) найти группу, которая ментейнит код, и спросить у них
3) не пропускать код на ревью, который никто не понимает
4) использовать языки, где не будет проблем с пониманием
Вы же не предлагаете это все спрашивать у кандидата? Или вы ищете жестко под одну задачу заточенного человека?
SpiderEkb
Я, собственно, прицепился к фразе
И привел пример того, что не зная языка, Вы просто не увидите ошибку. Вы не сможете по тексту понять что оно должно делать и что делает на самом деле. И скорее всего не найдете даже то место, где надо править.
Если, конечно, это задача чуть сложнее уровня «Hello World!».
Уволился пять лет назад.
А зачем тогда Вы там нужны?
Те, кто пишут на этом языке, прекрасно его понимают. Тут проще не допускать до ревью того, кто не знает этого языка.
Проще использовать тех специалистов, которые понимают основной язык, используемый в разработке в данной области. И не использовать тех, кто берет на себя смелость править код, не понимая языка на котором он написан.
Вам так не кажется?
Я как раз предлагаю не гонять кандидата по олимпиадным задачам. Но в денном случае речь не о том. А об одной конкретной Вашей фразе.
oYASo
Почему вы так считаете?
Например, в соревнованиях CTF приходится и в brainfuck уязвимости искать, и ничего, люди находят.
Ну и мы все-таки говорим не о каком-то абстрактом коде и абстрактных языках, в которых, в общем случае, вы будете правы. Яндекс пишет сервисы и около того на пачке одобренных языков типа C++/Python/Go/Java/JS и т.д. Не вижу проблемы переключиться с плюсов на го, чтобы разобраться в каком-то участке и что-то пофиксить.
Многим такая модель не подходит. Но компании такие навыки ценят.
Если никто про этот код не знает, то поднимать вопрос, кто его дальше будет ментейнить (и нужен ли он вообще). Если Вы, то разбираться — тут уже ничего не поделать.
В вашей компании, я так понимаю, не 300+ разработчиков, которые ежедневно коммитят в один проект под сотню ПРов? Потому что в таком случае люди пишут код сильно быстрее, чем его можно успеть прочитать. И если вместо того, чтобы быстро спросить у коллег, куда надо копать, вы сами будете копать неделю не туда — ну, это плохо.
Ну, вы же нанимаете людей на языке, на котором пишете, да? Мы же не говорим про случае, когда разработчику на питоне вдруг дают код на VHDL.
Какая задача из этого поста является олимпиадной?
SpiderEkb
Находят ошибки в логике. Но ошибку, связанную с особенностями языка можно увидеть только зная этот язык в тонкостях.
Честно скажу — не знаю сколько у нас разработчиков. Больше сотни только на стороне AS/400 это точно (разбиты на много команд — Ядро, модуль пластиковых карта, лимитный модуль, тарифный модуль, универсальный кассовый модуль, система расчетов — это только те, про кого знаю, есть еще) — георгафически расположены в трех городах — СПб, Мск и Екб.
Есть еще вебразработка, мобильная разработка, разработчики Pega, WBI…
В нашем гите несколько десятков проектов. В каждом проекте не один десяток репозиториев (каждая продуктовая линейка — свой репозиторий). Могу сказать как один из ревьюверов (это помимо основной работы) в проекте ядровых функций — за день может пару десятков ПР прилететь на ревью (естественно, что я не один, ревьюверов много и мы делим репозитории между собой иначе на основную работу просто времени не будет)
В силу ряда особенностей, мы нанимаем разработчиков и готовим их (первые три месяца) на язык и платформу под которую пишем.
oYASo
Вот мы и пришли к тому, о чем говорю я, и что делает Яндекс, и что делаете вы — нанимаете думающих разработчиков, которых готовите под свои инструменты.
Согласитесь, если человек не умеет писать работающий код на питоне (который он как бы знает), тогда на специфичных для вашей отрасли языках шансы разобраться драматически снижаются.
SpiderEkb
У нас на собеседовании нет задач на алгоритмы.
И уж точно код никто писать не заставит. Спрашивают чем занимался раньше, какие задачи решал. Максимум, могут подкинуть что-то из реальной практики и спросить как бы это стал решать. Без кода, просто на словах в общих чертах описать алгоритм.
Наша практика показывает что этого более чем достаточно. Не помню случая, чтобы после трех месяцев «испытательного срока» (а фактически это обучение), кому-то сказали бы «не подходишь».
PsyHaSTe
У меня с опытом все сильнее складывается ощущение, что с ростом экспертизы разработчик перестает быть С++ или там Java девелопером а становится просто Software developer, который баг на любом языке от питона до хаскелля может пофиксить за разумное время, а выбор языка для сервиса будет основывать на "готовые либы чтобы сделать Х и иметь поменьше юзеркода/что знает команда/что со спецами на рынке/...", а не по принципу "ну я С++ дев буду на С++ писать".
oYASo
Золотой комментарий.
SpiderEkb
Вот этим согласен на все 100.
На мой взгляд не совсем так. Я бы сказал что он сможет любой новый язык изучить за разумное время.
Это верно, в общем и целом. Хотя в нашем случае выбор языков ограничен и делается по принципу «какой наилучшим образом подходит для эффективного решения данной задачи».
Но тут своя достаточно узкая специфика.
balberbro
«Джуны и мидлы уходят на старших/ведущих разрабов в другие компании» — дальше можно не читать. Означает, что Яндекс хочет нанять ведущего разработчика по цене Джуна, задрочив его на вот таких вот собеседованиях, снижая самооценку и опуская в говно на каких-то непонятных синтетических задачах.
О чем и идет эта статья.
oYASo
Конечно, лучше сразу комент жахнуть.
Со старших/ведущих позиций с длинным хвостом опционов из Яндекса вообще не очень понятно, куда в России уходить — ну просто физически столько денег на рынке не предлагают (зачастую, в т.ч. и за границей).
С мидлами сложнее, потому что их в Я много, не у всех получается быстро расти, hr за ними охотятся и выгодно их продают в другие компании (потому как спрос есть). Но это уже совершенно другая комплексная проблема.
Ну и задачи из поста — ну это же правда смешно. Там же даже каких-то хитрых алгоритмических задач нет, просто аккуратно реши бытовуху. Что так всех бомбит — не пойму.
siziyman
То, что человека просят делать одни и те же довольно тривиальные вещи по кругу 10 раз на нескольких собесах, притом иногда ставя откровенно абсурдные ограничения (и да, невозможность использовать стандартную библиотеку языка — абсурдное ограничение, куда полезнее, если зачем-то очень хочется, обсудить, как она работает, и в каких случаях используемые алгоритмы неприменимы/неудачны — по скорости, памяти или чему-то ещё).
oYASo
Ну а теперь расскажите мне про российские компании, которые:
1) оплачивают в акциях или опционах
2) в их штате чуть больше людей, чем основатель и его кореш — технический директор
3) своим сайнапом они перекроют зп ведущего разработчика с хвостом опционов в Я
С высокогрейдовых позиции в плане финансов и в FAANG не всегда выгодно ротироваться, не то, что выбирать из 1.5 компаний тут.
leventov
Можете объяснить, что такое "хвост опционов" в Яндексе? У каких-то старых сотрудников эти опционы уже должны были конвертироваться в акции которые можно продать и уйти куда угодно?
oYASo
За хорошую работу сотрудникам на высоких грейдах отсыпаются опционы. Вестинг опционов (то есть, грубо говоря, возможность сконвентировать часть опционов в деньги) идет в течении некоторого количества времени (лет). Если вы работаете в компании давно, у вас накопилась довольно большая часть опционов, которая постоянно вестится. Плюс еще и акции компании подлетели.
Например, сейчас вы вместе с окладом выводите опционы за 2015, 2016 и 2017 года, что дает хороший буст к доходу (на высоких грейдах он вполне может быть выше оклада).
siziyman
1, 2) Ну, я знаю некоторое количество таких, если критерий «российских» — эт «нанимает по ТК в РФ и имеет офис(ы) в РФ». Но, я напомню, платить акциями совершенно необязательно, можно просто платить хорошие бонусы, которые в некоторых компаниях тоже бывают.
3) Тут буквально 3-4 месяца назад слышал, что на 17 грейде в Яндексе оценка С на ревью даёт примерно +250 баксов к месячному окладу в чистом виде, что, в общем-то, совсем негусто. А хвост — ну он на то и хвост, что он когда-то потом будет.
Dan_Te
> примерно +250
это без хвоста
с хвостом примерно +1000
> хвост — ну он на то и хвост, что он когда-то потом будет
это верно
но те, кто пришли чуть раньше и нарастили его к 2020 году, получили при тех же условиях (17С) гораздо больше, +1500 или даже +2000 в месяц. Да, это не навсегда, а только пока вестятся акции, которые выдавали, когда курс был 30 за акцию, а сейчас стал 60. Если курс дальше не вырастет, то такого больше не будет. А если вырастет — то будет.
PsyHaSTe
А оклады по грейдам это какая-то тайна или нет? Можете примерную табличку с грейдами (и всеми "хвостами" переведенными в условные тугрики) привести? Ну типа мидл — 200к на руки, сениор — 300к на руки, лид — 400к на руки, архитектор 500к на руки? Ну, просто чтобы как-то предметно было.
А то слов сказано много, а понимания что к чему — непонятно. По идее грейды на весь яндекс скорее всего одни и те же и условно в общем доступе, поэтому хотя бы примерно обозначить на что могут рассчитывать разработчики определенного уровня было бы неплохо. Тот же фаанг на levels.fyi эти цифры например показывает
BugM
Яндекс тоже показывает levels.fyi
PsyHaSTe
Хм, никогда бы не подумал.
Ну оттуда следует что средненький сениор получает 50к на руки за год
Что кажется вполне неплохо. G18 получает уже 110к на руки, т.е. 8.5 миллионов за год.
Не похоже на "ниже рынка"
TheKnight
Это не сениор, это миддл. По крайней мере приставки "старший" в названии должности у такого нет. Сениор — это 17.
PsyHaSTe
Ну я точно знаю что SWEIII это то что на хх и прочих линкединах котируется как "сениор девелопер" с 5+ годами опыта. Что соответствеует как раз G16 судя по ссылке
oYASo
G16 — это мидл.
G17 — сеньор.
G18 и выше — ведущий.
Вилка там достаточно широкая, но моя статистика и levels.fyi более-менее бьются.
PsyHaSTe
Ну окей, то есть получается 50000 мидл (321000 рублей в месяц), сениор 75000 (474000 рублей в месяц).
Не знаю в каком мире это "ниже рынка". Если посмотреть отчеты "Моего Круга" тут же на хабре то там в средних красуются смешные по сравнению с этим цифры в 100-150к для мидла. Конечно там регионы вносят лепту и тд итп но все же. Можно на хх поискать мидл вакансии на 300к ради интереса — нет ни одной. А в тех что есть скромненько через слеш пишется senior. Да и вакансий 6 из 1735.
Это не к вам лично вопрос, а скорее в воздух про людей у котороых яндекс — это выжималка, в которой ни денег не заработать ни задач нормальных. И если второе возможно верно (как и для любой крупной компании впрочем), то первое видимо далеко от истины
oYASo
Ну это цифры с опционами, а они далеко не у всех. Надо смотреть и чисто base (это для новых сотрудников, или тех, кто не получает высокие оценки на ревью), и вместе со stock.
Ну 32к base для мидла — 200к, что выглядит вполне норм.
В общем-то, я в этом треде и пишу, что с цифрами, особенно для высоких грейдов, там все нормально.
Dan_Te
Вы сами уже все нашли )
Я лишь могу подтвердить, что числа на левелсах — адекватные. Понятно, у кого-то меньше будет, у кого-то больше, но в целом все так.
oYASo
Ну о том и речь, что в РФ таких компаний — даже пальцев одной руки будет много.
Ниже уже скинули зарплаты с levels.fyi.
У меня есть друзья во всех топовых российских и не только компаниях, с которыми мы периодически пьем пиво и обсуждаем, где солнце лучше греет. Разве что сбер тут может похвастаться жирными годовыми бонусами, которые с лихвой перекроют опционный хвост 17 грейда. Но это, сами понимаете, вариант с нюансами.
Ниже уже обсудили, что это далеко не всегда так.
mdevaev
> Дальше, чтобы там не говорили про собесы в Яндекс, коллеги там реально крутые, то есть система отбора все-таки работает.
Надо только понимать, что по большей части эти крутые коллеги пришли еще до того, как начался этот театр абсурда с собеседованиями.
// тоже бывший яндексоид
oYASo
Ну такие собесы в Я появились не вчера. Я какой-то корреляции не заметил.
mdevaev
Такие собеседования появились сравнительно недавно. Я начал работать еще в ту эпоху, когда их не было, и застал их появление. Заметил.
baldr
Вот, кстати, еще один комментарий в похожем треде: " Как проходят алгоритмические секции на собеседованиях в Яндекс" в блоге самого Яндекса.
Прошло два года, ничего не поменялось.
oYASo
Лично я на рынке вообще вижу большую проблему с кадрами. Сюда стянулось сейчас много людей на большие зарплаты, плюс всякие скиллбоксы, которые из вчерашнего дворника обещают сделать разработчика с гарантированным трудоустройством. Поэтому людей, которые прокачали красноречение, но не прокачали разработку, стало очень много, и отбирать их сильно тяжелее.
Я думаю, это все первопричина ухудшения качества новых сотрудников, а не задачки на собесах.
SpiderEkb
А вот скажите, как часто в работе попадаются задачи из тех, что предлагаются на собесе?
Я вот не могу вспомнить сходу что-то такое приходилось делать…
Зато сплошь и рядом попадаются задачи, которые требуют некоторой фантазии для решения. Например как один запрос «в лоб», выполняющийся 3 секунды, разбить на несколько, выделить высокоселективные предвыборки на основе частотного словаря, уйти от использования медленных агрегатных функций, и в результате получить тот же результат, гарантированно укладываясь в 150-200мс. Вот это вполне реальная задача, решающая реальную проблему бизнеса.
Или как оптимизировать параллельную многопоточную обработку большого массива данных, которая занимает 15-17 часов, не трогая собственно обработчик, только за счет оптимизации механизма распараллеливания, уменьшив время обработки до 9-ти часов при том же количестве потоков.
Подобных задач на самом деле у нас встречается очень много. И для каждой требуется индивидуальный подход. И тут важнее умение человека думать нестандартно, чем знание им заученных алгоритмов и типовых задачек.
И лично в моей практике есть примеры людей, которые приходили совсем нулевыми, но буквально за полгода раскрывались в достаточно перспективного разработчика. Алгоритмические задачки таких отсеивают сходу, а вот вопросы на подумать скорее помогут распознать потенциал.
oYASo
Это же совершенно про разное. Задачи на собесе нужны для того, чтобы понять, как человек думает, что говорит, как пишет код, насколько внимательный к деталям и т.д. Есть человек работает по принципу хренак-хренак и продакшен — зачем он кому-то?
Поймите, что в таких компаниях задачами «оптимизировать параллельную многопоточную обработку большого массива данных» занимается какая-то отдельная «группа параллельной обработки большого массива данных», куда вас, очевидно, не собеседуют. Вас вполне могут нанимать на перекладывание джейсонов, а не на оптимизацию работы с БД. А еще надо понимать, что в таких компаниях можно встретить каких-нибудь core разработчиков БД (или даже ЯП), которые уже давно все оптимизировали.
В таких компаниях обычно девиз: «лучше не нанять хорошего разработчика, чем нанять плохого». Вы же понимаете, какой там поток резюме? На одного потенциально хорошего джуна там придет десяток уже крутых мидлов — зачем тогда тратить время?
baldr
Приходит такой Линус Торвальдс на собес в Яндекс.Лавку, говорит — "я Linux напи..."
А ему — "нам наплевать что вы там написали, давайте посчитайте сколько тут символов в строке"
picul
Сейчас бы сравнивать автора статьи с Линусом Торвальдсом.
oYASo
Давайте не гипотетические примеры, а конкретные. Вот Илья Красильщик ушел из Медузы и пришел в Яндекс.Лавку на позицию руководителя сервиса. Я свечку не держал, но вряд ли он функцию RLE писал.
Михаила Парахин ушел из Microsoft на позицию технического директора в Яндекс (потом, правда, вернулся). И, кстати, будучи в ТОП-менеджменте, он даже фигачил код. Помню, была какая-то отличная либа на AVX.
Не надо сравнивать позиции обычного копателя джейсонов и рок-звезд. Очевидно, автора поста собеседовали на мидловские позиции, и он совсем не Линус Торвальдс.
mdevaev
> Парахин
> рок-звезда
Выберите что-то одно.
oYASo
Это уже личное дело каждого, как к кому относится. Я лишь указал на то, что необычных людей не гоняют по обычным собесам. И условного Линуса Торвальдса никто бы списки разворачивать не просил.
Bellerogrim
Так была же история. Автору какой-то популярной библиотеки пеняли на то, что он недостаточно хорошо знаком с этой библиотекой.
wataru
Нет, была история — что его просили разворачивать дерево и он не справился. И истории о том, что в вакансиях требуют 5+ лет опыта какой-то технологии, которых не было у автора технологии, который создал ее 3 года назад.
Areso
Первый был автор хоумбрю, Max Howell.
Второго не помню :(
SpiderEkb
Тогда мне не совсем понятен тот случай, что произошел со мной.
Они что, всерьез думали, что я пойду «перекладывать джсоны» со своей текущей позиции? Вот вот прям серьезно? Все брошу и побегу?
Я понимаю мальчиков, которых на рынке рупь за пучок так гонять…
oYASo
Ну вы же понимаете, что это вопрос не ко мне? Я не знаю, что вам предлагали, какая ваша позиция, что вы делали, о чем договаривались, какой реальный уровень и т.д.
Понятно, что бизнес всегда хочет купить нас подешевле, а мы продаться — подороже.
SpiderEkb
Позиция обозначена в профиле.
Главный разработчик ЦБС (Центральных Банковских Систем) в Альфа-Банке. Чтобы понятнее — это бэкенд глубже некуда — команда ядровых функций АБС (Автоматизированной Банковской Системы). Т.е. все, что происходит «наверху» так или иначе приходит к нам. А также все, что крутится в фоне, обеспечивая работу банка.
Работает все это на платформе IBM i (бывш. AS/400) на серверах IBM PowerS9. Пишем на IBM'овском языке RPG (ну и частично на C/C++ там, где нужно более глубокое взаимодействие с системой). Впрочем, до этого я работал в совсем другой области и на С, а позже на С++ пишу года этак с 89-90-го (т.е. стаж в разработке кой-какой имеется, равно как и понимание как надо и как не надо в достаточно широком круге вопросов от работы с БД, распараллеливания обработки больших массивов данных до межпроцессного взаимодействия в гетерогенных распределенных системах).
И решать олимпиадные задачки яндыха до того, как определены позиции что мне могут предложить, что могу предложить я и насколько все это взаимно интересно — ну как-то совсем не с руки.
Девочка-рекрутер мое резюме читала и была в курсе что к чему. И я сразу поставил условие что для начала будет просто разговор для определения позиций. А дальше уже решим.
Но интервьюер был или не в курсе, или просто не в состоянии отойти от привычного шаблона — сходу завалить олимпиадными задачками.
Ну а мне не настолько нужны деньги чтобы прогибаться.
ToSHiC
Оффтоп: я биллингом раньше занимался, и там почти вся финансовая часть была на коболе. У вас был и вы его выжгли напалмом, или не было? Или вообще до сих пор живёт с вами?
SpiderEkb
У нас его изначально не было. Сразу все на RPG. Который по синтаксису приятнее кобола, по возможностям (в плане работы с БД, нативной поддержки типов с фиксированной точкой и т.п.) как минимум не хуже.
Но кобол поддерживется в концепции ILE (С/С++, CL, RPG, COBOL) и его компилятор встроен в систему. Так что возможность писать на нем формально есть :-)
Viceroyalty
То чувство когда комментарий интересней статьи — думал, что АБС это клиент-СУБД, а не классическая трехзвенка, видимо, я Диасофтом испорчен.
SpiderEkb
Ну… Я затруднюсь перечислить все, что у нас делает АБС. Наверное, проще сказать «все» :-)
АБС бывают разные. Вот пример. Обслуживался когда-то в одном небольшом банке. И, видимо, АБС там была достаточно простой. Ибо ситуация такая: есть счет, к нему привязаны две карты. А надо понимать, что остаток на счете и остаток по карте — это две разные вещи. И было там так. Есть на счет 10тр. В статике обе карты показывают по 10тр доступных средств. Заходим в магазин, покупаем что-то на 10тр, расплачиваемся первой картой. После этого смотрим остатки. Остаток по счету 10тр. Остаток по первой карте (которой платили) — 0р. Остаток по второй карте 10тр. Заходим в другой магазин, покупаем еще на 10тр, расплачиваемся второй картой. Смотрим остатки — по счету 10тр, по обеим картам 0р. На следующий день (иногда через день, все это сводится воедино и на счете получается технический овердрафт в -10тр. Так работает АБС.
У нас такое невозможно — АБС работает в реальном времени и все эти остатки синхронизируются в течении нескольких секунд. Но ценой нагрузки на сервер, конечно — все это должно обрабатываться быстро.
Второй пример. Баланс (который притча во языцах каждого бухгалтера) в банке сводится не раз в месяц, а каждый день. Это называется EOD — End-Of-Day (переход на следующий операционный день) и занимает несколько часов ночью. Некоторые АБС на это время приостанавливают работу банка (т.е. все операции как бы проводятся, но фактически складываются в кеш и проходят уже после EOD следующим днем). Но, опять же, не у нас. У нас перед началом EOD создается т.н. «юнит ночного ввода» как копия основного юнита и все операции переносятся туда и продолжают выполняться. А в основном юните проходит EOD. По завершении которого юнит переходит в следующий день и все изменения, что произошли в течении EOD в ночном юните «накатываются» в дневной. Тоже лишние танцы с бубном, но обеспечивают непрерывную работу системы. Естественно, все это автоматизировано.
Открывает клиент счет — банк должен предоставить данные в налоговую. Система сама отслеживает изменения в таблице счетов и как только бухрежим по счету перешел из состояния «зарезервирован» в состояние «активен», сама формирует сообщение для налоговой и отсылает его через MQ в соотв. внешнюю систему, которая уже отвечает за передачу данных.
Карточки клиентов (клиентские данные) — это тоже часть АБС. А там много чего понавешаено. Те же риски клиентов (страновые, репутационные...) — все это обрабатывается автоматом по изменению клиентских данных.
Комплаенс. Моя тема. Росфинмониторинг регулярно присылает списки всяких злодеев. Разбираются и раскладываются по базе они автоматом (последнее время как раз этим занимаюсь). Пришел новый список, разложился — запускается процедура серки клиентов. Это прогоняются все активные клиенты (несколько десятков миллионов если что) и для каждого производится поиск совпадений со списками злодеев — по именам, ДР, ДУЛ (документ удостоверяющий личность), ИНН, адресам. Формируется отчет по совпадениям (полные, частичные). Это все автоматом тоже. Соответсвенно, есть набор APIшек для проверки совпадений… Тоже наша работа… Они же используются для контроля платежей — от кого, кому (а не пособствуем ли мы финансированию террористов?)…
Все это и еще очень много чего является функциями АБС. И любое изменение требования регулятора приводит к необходимости доработки той или иной функции. Чем мы и занимаемся :-)
В результате на серверах одновременно крутятся тысячи фоновых процессов. Тут, кстати, проявляется одно из преимуществ AS/400 — она изначально сделана для такой работы. В силу ряда особенностей в ней минимизированы до предела накладные расходы на смену контекста при переключении между процессами. Так что она еще очень долго будет жить и развиваться в этой нише — там, где требуется одновременная работа многих процессов.
Что касается скуля… По нашим наблюдениям он далеко не всегда является оптимльным с точки зрения производиетльности и потребления ресурсов. Просто потому что перед выполнением требует времени и ресурсов на построение плана запроса. С этим можно мирится для статических или параметризированных запросов — один раз построил план и пользуйся им. А вот если запрос динамический и формируется на лету… И при этом вызывается десятки тысяч раз в секунду… Получается очень дорого.
Была у меня задача — запрос содержал конструкцию where… in (...) где список in(...) формировался каждый раз заново из входных данных. По нагрузочной статистике на это уходило до 36% времени и до 33% процессорных ресурсов данной процедуры. К счастью, RPG позволяет не только скулем работать, но и прямым обращением к таблицам (функции позиционирования по индексному файлу, чтения из таблиц...). Переписал, избавившись от скуля. Да, больше кода. Но стало быстрее работать и меньше грузить процессор. А функция была критичная — как раз поиск совпадений по наименованию со списком злодеев. Т.е. вызываться она могла в определенных ситуациях десятки миллионов раз подряд.
Фактически скулем пользуемся когда надо делать большие сложные выборки по нескольким таблицам. И можно использовать статический параметризированный запрос.
А вот прочитать одну запись из таблицы по ключу (или выбрать десяток-сотню записей) — это быстрее «нативным» RPG. Или проверить наличие в таблице записи с заданным значением ключа (просто есть или нет — содержимое записи не интересует) — тут даже в саму таблицу лезть не надо, просто посмотреть индексный файл.
В общем, там очень много тонкостей, требующих знания языка, платформы на которой работаешь… И смешно читать как человек «правит код на Go самого Go не зная».
Viceroyalty
А вы крутые ребята, жму руку. Насколько знаю бизнес-логика пишется на Java и прочих Haskell-ах, а тут ассемблер среднего уровня (если C++ есть ассемблер высокого уровня).
Но, справедливости ради: многое из перечисленного, если не все, можно решить и без усложнения АБС (хотя, что дешевле — вопрос тот еще).
Веселуха с картами на бывшей работе (не топовый банк в топ-50)была при переходе на новый процессинг, но потом пофиксили — онлайн синхронизация (с некоторыми дополнениями для предотвращения теховера).
При закрытии дня работа не останавливалась, тут к сожалению деталей реализации не знаю, работал все-таки аудитором, а не разрабом.
При этом была высока доля ручных операций, что впрочем было не из-за архитектура («сложилось исторически»)
По скулю — если отключить оптимизацию запросов нельзя обойтись без построения плана запроса?
P.S. вам-то, наверное, в работе нужно знание алгоритмов.
SpiderEkb
Java мы используем только для вебсервисов и под них выделен отдельные сервер в кластере. Ибо работает медленно, а памяти жрет как не в себя.
С Хаскелем не сталкивался — нет его у нас…
Основной язык — RPG Вполне себе высокого уровня. На нем пишется основная часть кода. Что-то системное пишется на С/С++.
Причем, на AS/400 есть такая концепция — ILE Вкратце — можно написать несколько модулей на разных языках (из состава поддерживаемых в ILE — Cobol, RPG, C/C++, CL) и собрать их в одну программу. Т.е. из процедуры, написанной на RPG можно вызывать функции, написанные на С/С++ и наоборот. Главное — правильно описать прототипы.
Ну или можно напрямую из RPG программ вызывать функции С-шной библиотеки (работа с файлами, qsort, bsearch и т.п.) — компилятор их сам найдет :-)
Компиляторы всех ILE языков есть часть системы. Ну вот простейший пример (кусок инсталлятора на языке CL — это системный язык AS/400):
CRTCPPMOD MODULE(QTEMP/DTAQ) SRCFILE(&ASRC/&SRCF) SRCMBR(DTAQ) OUTPUT(*PRINT)-
DBGVIEW(*SOURCE)
CRTCPPMOD MODULE(QTEMP/BATCHM) SRCFILE(&ASRC/&SRCF) SRCMBR(BATCHM) OUTPUT(*PRINT)-
DBGVIEW(*SOURCE)
CRTCPPMOD MODULE(QTEMP/BATCHMWRP) SRCFILE(&ASRC/&SRCF) SRCMBR(BATCHMWRP)-
OUTPUT(*PRINT) DBGVIEW(*SOURCE)
CRTSQLRPGI OBJ(QTEMP/ELB03S) SRCFILE(&ASRC/&SRCF) SRCMBR(ELB03S) DBGVIEW(*SOURCE)-
COMMIT(*NONE) OBJTYPE(*MODULE) RPGPPOPT(*LVL2) SRTSEQ(*HEX) OUTPUT(*PRINT)-
LANGID(RUS)
CRTRPGMOD MODULE(QTEMP/ELB07PROC) SRCFILE(&ASRC/&SRCF) SRCMBR(ELB07PROC)-
DBGVIEW(*COPY)
CRTPGM PGM(&ALIB/ELB03S) MODULE((QTEMP/BATCHM) (QTEMP/BATCHMWRP) (QTEMP/DTAQ)-
(QTEMP/ELB03S) (QTEMP/ELB07PROC) ) BNDDIR((*LIBL/LESBNDDIR) ) ACTGRP(*CALLER)-
TGTRLS(*CURRENT) STGMDL(*SNGLVL) ALWUPD(*YES) ALWLIBUPD(*NO) ENTMOD(QTEMP/ELB03S)
Сначала компилируем модули:
CRTCPPMOD — модуль написан на С++
CRTSQLRPGI — модуль написан на SQLRPG — RPG с использование SQL команд внутри RPG кода
CRTRPGMOD — модуль на «чистом» RPG без SQL
CRTPGM — собираем все модули в один программный объект
Если на С функция выглядит как
то на RPG ее прототип будет:
// количество слов в строке
dcl-pr WordsCount int(10) extproc(*CWIDEN : 'WordsCount');
pBuffer char(65535) const options(*varsize);
nBuffLen int(10) value;
end-pr;
И оно вызывается и работает.
Посему, что проще на RPG — пишем на RPG. Что проще на С/С++ — пишем на С/С++ :-)
Есть достаточно сложные реализации, например, у меня есть реализация SkipList на С++ (с классами, объектами), к ней Сишный враппер и RPG прототипы, позволяющие создавать из RPG объект SkipList (возвращается хендлер объекта) и потом работать с ним уже из RPG программ.
Есть и более сложные вещи — скажем, батчмашина для распараллеливания обработки. Сама машина написан на С++, но используется из RPG
// Создаем многопочку
Master = Batch_CreateMaster('*LIBL' : 'ELB07S' : '' : 'ETLPROC' :
DtaQLib : 'DQELBMAST' : 'DQELBWORK' :
WorkersCount :
(%size(t_qdsClient) * SendBlockSize) :
(%size(t_qdsClient) * SendBlockSize) :
PingTime : ResendCount : RecieveTimeout :
strError);
Тут через spawn запускается несколько процессов (JOB) — обработчиков (программа ELB07S), количество процессов указано в WorkersCount.
Создаются очереди для обмена данными DQELBMAST — Мастер->обработчики и DQELBWORK — обработчики->мастер
А затем мастер готови пакеты данных для обработки и выдает их в очередь
Batch_MasterSendData(Master : pData : DataLen : ErrStr)
Ну и всякая обвязка — контроль за состоянием очереди, состоянием заданий и т.п. Все это прописано внутри объекта на С++ НО используется из RPG.
Ну формально она не останавливется. Просто операции откладываются до нового дня.
Я не говорю что у нас лучше всех :-) Просто есть так а есть этак. Вот у нас так…
Ну вот мы стремимся эту долю сокращать всемерно.
Нет. План запроса все равно строится. Хотя бы для того, чтобы понять какие индексы подцепить.
В ряде случаев скуль эффективнее. А в ряде нет. Наша задача — понимать где как лучше :-)
Да на самом деле не сильно. Логика у нас в целом туповатая в 99% случаев. Больше общие паттерны — как ту же батчмашину эффективно построить, как правильно распределить роли между мастером и обработчиками…
Очень много требований к обработке ошибок, их логированию и мониторингу.
Ну систему с ее особенностями представлять надо. А система ни на что не похожа. Она «объектная» — «все есть объект». И очень много специфических типов объектов. Надо их понимать как оно работает и что когда и где использовать.
Ну иногда нестандартное что-то бывает, конечно, но там просто фантазию включать надо :-)
Viceroyalty
SpiderEkb
Ну… Если не вдаваться в подробности работы As-ки, то суть примерно такая:
Есть программа, запущенная в отдельном задании (JOB). И она вызывает другую программу (много раз, скажем, несколько миллионов за цикл свой жизни) в котрой требуется получить какие-то данные из БД.
Если данные получаются статическим sql запросом (строка запроса захардкожена на этапе разработки, меняются только параметры — значения host переменных), то все хорошо — план запроса построится один раз при первом вызове а все последующие будут выполняться уже по ранее построенному плану.
Все плохо, когда это невозможно и строку запроса приходится формировать в рантайме. Вот тогда план будет строиться каждый раз что отнимает и время и ресурсы.
К счастью, на DB2 for i есть два способа работы с БД — через sql и прямым доступом (поиск записи по значению ключа).
Прямой доступ никакой подготовки не требует, только открыть файл (опять же, он открывается только при первом вызове, дальше сохраняется открытым до конца жизни задания).
Посему, когда нам надо получить большие объемы данных и можно использовать статический скуль — используем его. Если же речь идет об одной записи по известному значению уникального ключа — проще прямой доступ.
Или, например, проверить наличие записи с заданным значением ключа — прямой доступ позволяет вообще не читать ее из файла а только посмотреть есть ли ссылка на эту запись в индексе.
Или, например, такое — нужно определить есть ли в файле запись с заданным ключом, а если есть, то одна или несколько — тут тоже прямой доступ эффективнее — нам не надо считать все записи. Если нашли, то проверяем — есть ли еще хотя бы одна. Если есть — все, выходим.
Ну и так далее… Т.е. всегда смотрим и думаем — что в данном случае будет эффективнее — скуль или не скуль.
wadeg
Единицы сотен — могу понять. Какая-то жуть в архитектуре.
Везде так. У у всех. Да и по-другому быть не может. В-общем, наверно, не понял примера и к чему он.
О боги… еще тысяча и один пример из серии таких же «возьмите уже грамотного sql-разработчика один раз и не мучайте железо и весь отдел дикой самопальщиной».
wadeg
ЗЫЖ последнее, конечно, не к вам, а к верхнему руководству отдела, т.е. в пустоту. Вы-то при рассмотрении вопроса, возможно, как раз первым и пострадаете.
SpiderEkb
Дело в том, что «грамотный sql разработчик» сделает что?
Вот смотрите. НА вход приходит фраза. Ее надо разбить на список слов. Это список надо дополнить словоформами для каждого слова (из таблицы словоформ)(фактически — для каждое слово из входной фразы в списке должно присутствовать во всех 6-ти падежах + двух вариантах транслитирации на латинице). Это первый запрос.
Второй запрос — поиск совпадений по другой таблице. Там ищутся совпадения слов из списка с тем, что есть в таблице (ну плюс еще несколько дополнительных условий).
Фраза каждый раз разная. Количество вызовов только в одной задаче (а функция вызывается много где еще) — несколько десятков миллионов раз за время работы задачи.
Что тут сделает «грамотный разработчик SQL» так, чтобы запрос можно было сделать статическим с парамтерами, а не формирующимся на лету в процессе выполнения и требующим prapare в каждом вызове?
Разбить все это на несколько запросов? И в чем профит? У нас есть возможность работать с индексом напрямую, без скуля.
Одиночный запуск версии со скулем в лоб на тестовой среде — 21мс. Одиночный запуск нескулевой версии на тестовой среде — 7мс.
На копии промсреды вся задача (использующая эту функцию) целиком. 34648 вызовов. Старая версия 7.98сек, новая 6.71сек при меньшей процентов на 30 загрузке процессора.
Причем, основные претензии именно по загрузке процессора.
Вот эти 33% времени и 36% ресурсов процессора мы исключили отказом от скуля в пользу прямого доступа к таблицам.
int03e
А решения типа эластика не подошли?
wadeg
Эластик был бы идеален как раз. Пришлось бы, разумеется, решать задачу несильно нагружающей онлайн-синхронизации данных с ним, это геморрой известный, но задачу решило бы идеально. Вообще, судя по всему написанному, там с архитектуры этого поиска надо начинать.
Ну и фразы типа "Была у меня задача — запрос содержал конструкцию where… in (...) где список in(...) формировался каждый раз заново из входных данных" кричат о необходимости грамотного разработчика. А кусок про поиск словоформ — и вовсе о необходимости грамотного архитектора.
SpiderEkb
Ну предложите свое решение. Вот вам задачка «олимпиадная».
Есть список наименований (это могут быть имена, названия организаций и т.п.). Кириллица, латиница… Несколько сотен тысяч.
И есть «фраза» (имя, наименование) в произвольном падеже или одном из нескольких вариантов транслитерации. Нужно найти совпадение.
Т.е. если в таблице присутсвует «Иванов Иван Иванович», то фраза «Ivanovu Ivanu Ivanovichu» должна дать положительный результат на совпадение.
Эластиков в наличии нет. Библиотек тоже.
Частота вызовов очень большая. Из самых разных мест. Кешировать бесполезно т.к. придется держать в памяти всю таблицу со всеми вариантами написаний, такой возможности нет.
Входная фраза произвольная.
int03e
Так почему бы тогда не добавить эластик, и не заюзать www.elastic.co/guide/en/elasticsearch/plugins/current/analysis-icu-transform.html? Это ведь подходящий инструмент под вашу задачу, и не нужно было-бы изобретать свои велосипеды.
SpiderEkb
Он работает на платформе IBM i?
Что ему нужно для работы? JVM?
И кто будет его сопровождать? Следить за тем чтобы все работало?
Какую дополнительную нагрузку он дает на сервер?
Как у него с поддержкой — в случае возникновения проблем кто-то готов быстро их решать?
Вы поймите — банк, это не яндекс лавка. Потери от недоступности системы тут серьезнее (в том числе и материально). Поэтому используются очень консервативные, проверенные решения имеющую серьезную поддержку производителя.
И тащить кучу всякого зоопарка под каждую локальную задачу сюда никто не даст. А это локальная задача. Одна из очень многих.
Повторюсь — она решена. НА том уровне, который удовлетворяет требованиям бизнеса и сопровождения.
Решение занимает 500 строк кода (17кб исходник) со всеми обвязками.
Реально:
Итого смысловая часть 166 строк кода.
Вы предлагаете ставить непонятную хрень, которая будет жрать ресурсы там, где можно обойтись одной функцией из 500-т строк кода? Серьезно?
Может быть яндекс не так и неправ, когда отсеивает кандидатов, неспособных решить тривиальные алгоритмические задачки без использования сторонних библиотек и фреймворков?
BugM
Прикрутите себе кеш уже. И будет у вас один фулл скан таблицы на каждое обновление кеша раз в N минут. Не очень дорого.
Не надо из sql kv хранилище делать. Оно работает конечно, но плохо.
SpiderEkb
Это очень дорого в наших масштабах. За такое разработчика сразу за причинное место на всеобщее обозрение повесят. В назидание другим.
BugM
Я не знаю баз для которых раз в несколько минут один раз прочитать одну табличку полностью дорого. Естественно у таблички должен буть приемлимые размер, в вашем описании он как раз такой.
Если у вас можно производительность закручивать хинтами или ещё как вниз то надо закручивать. В этом месте можно работать дольше.
SpiderEkb
И для всех табличек хранить кеши? Это только один из примеров, на самом деле такого у нас достаточно много. В том числе и для очень объемных таблиц.
Конкретно эта таблица может использоваться из многих заданий. Т.е. придется городить еще одно задание, которое будет хранить кеш, потом для этого задания делать механизм запрос-ответ, который позволить получать данные кеша из других заданий…
Все это даст неслабую дополнительную нагрузку на систему в целом.
BugM
Для всех у которых большая нагрузка по kv паттерну. А что тут такого? Так примерно все и делают. Чтобы нагрузку держать и sql базу не грузить.
Просто читать не из sql, а из общего кеша. Порефактрить код придётся, но опять же ничего страшного. Вы и так рефакторили чтобы читать как-то по другому.
SpiderEkb
Ок. Давайте еще раз.
Есть порядка 40млн возможных фраз. Каждую из них надо проверить по вышеуказанному алгоритму — разобрать на слова, составить список слов со всеми возможными словоформами… (фраз среди которых ищутся совпадения несколько сотен тысяч). Что тут кешировать?
И это всего одна таблица. А их… да фиг знает сколько у нас таблиц в БД. Это наверное только сопровождение может сказать. Все будем кешировать?
Не, в понимаю, когда в БД десяток таблиц и примерно столько же процессов, их использующих. А если тысячи? Таблиц и процессов…
То, что я описываю, это всего лишь одна маленькая частная задачка.
BugM
У вас есть табличка в которую летит большой rps по kv паттерну. Проверить наличие по ключу или по строке это именно он и есть.
40 миллионов с формами это ну пусть миллионов 400 без оптимизации даже.
Инмемори влазит без проблем.
Берёте и кладёте эту табличку в любой инмемори кеш. Любой стандартный подойдёт. Настраиваете периодическое обновление. Прочитать раз в 5 минут табличку на 40 миллионов записей вообще не проблема для БД.
Дальше переводите всех клиентов на обращения к этому кешу вместо sql таблички.
Для каждой следующей таблички с аналогичным паттерном нагрузки повторяете.
Получаете маштабируемое решение. Вам становится просто все равно на нагрузку в этом месте. Типовые вещи на небольшом железе вытягивают вообще любой rps. Sql база перестаёт испытывать нагрузку.
PsyHaSTe
Вы так уверены? Пробовали читать 40 миллионов записей в каждой из которых лежит мегабайтный
jsonb
?BugM
Там в условиях фамилии.
Делать kv поиск по полю с мегабайтом данных как-то неразумно. Класть такое поле в табличку вместе с обычными данными тем более неразумно, если у вас не колоночная БД.
PsyHaSTe
Ну вполне: имя, фамилия и файл с кастомизациями клиента (у нас такие есть). Ну там не мегабайт, но десятки (у некоторых сотни) кб набираются. Выносить отдельно — ну в целом можно, но и 60 джойнов базе не очень приятно обрабатывать, а денормализовывать не хочется.
BugM
Файл надо хранить как файл. В s3 допустим.
Все что больше 64 килобайт это файл.
Если хранить все в табличке, то потом точно будут проблемы. Проверено уже не раз. Если такое есть тут не кеш надо делать, а БД рефакторить.
SpiderEkb
Вот чтобы понимать масштаб:
Это наша система. Данные достаточно старые, сейчас еще больше.
Насколько помню цифру — сейчас порядка 3млрд изменений БД в сутки.
Вы предлагаете закешировать в памяти все 15 тысяч таблиц? И все их перечитывать фулсканом каждые 5 минут? Гениальное решение, что сказать…
Тот пример, что я привел, это всего лишь маленький кусочек. И далеко не самый критичный.
И там решение есть. Оно лежит вне рамок SQL (который не всегда и не везде оптимален, хотя имеет свои преимущества в ряде случаев). И вот эту его неоптимальность и пытаются компенсировать костылями типа кешей. У нас в том нет необходимости (т.е. кеши локальные используем там где это реально необходимо — справочники всякие и т.п. но глобально держать всю БД в памяти нет возможности, да и необходимости тоже) т.к. есть альтернативный, noSQL, способ доступа к данным.
BugM
При чем тут вообще масштаб всей системы? Явно же не во все таблички идёт большой rps по kv схеме. Ну и значит и не надо все так делать.
Делается мониторинг, собирается статистика. Находятся больные места. И именно они обвешиваются кешами.
Альтернативный — это читать с других железок. Читать все всегда с одной железки рано или поздно упирается в эту самую железку.
SpiderEkb
При том, что я привел лишь один небольшой эпизод. Это далеко не самое критичное место в системе. Таких мест очень много. Есть и более нагруженные. И разгружать их кешем не хватит никаких ресурсов (сейчас три, по-моему, сервера в кластере на одной шине, каждый сервер это 16 12-ядерных SMT8 PowerS928 процессоров и 2.5Тб памяти). Ну еще резервные сервера и тестовые.
Основная проблема у нас — ресурсы процессора. Даже не скорость — ее хватает в целом. А вот за эффективность использования процессоров боремся всесильно. Так что регулярный фулскан тут — очень плохое решение.
BugM
Вот именно в этом и проблема. Вы растете вверх, а надо в ширину. Не нужны все эти монстры в современном мире.
Нужно с таких монстров переводить нагрузку на обычные контейнеры, крутящиеся на обычных серверах. Ресурсы обычных серверов стоят минимум на порядок меньше чем на ваших мега железках.
Ресурсы х86 процессоров не стоят почти ничего. Они ну очень дешевые. Чаще упираешься в шину памяти.
Кеш который я предлагаю это ну пусть три ноды по 2 ядра. 6 ядер и сколько там памяти. Хватит на десятки тысяч рпс точно. Это такие копейки по железу что даже говорить не серьезно.
SpiderEkb
И кто будет следить за работой всех этих серверов и нод? Стоимость сопровождения всего этого зоопарка оценивали?
Требования к надежности и устойчивости банка достаточно высоки. Отдельные части системы имеют очень жесткие ограничения на периоды недоступности (дальше начинаются штрафы от регулятора «за неисполнение обязательств перед клиентами», в особо тяжких случаях до отзыва лицензии).
По поводу стоимости и производительности серверов
Если в курсе — расскажите про организацию АБС в банках из топ-10. Просто для сравнения. И назовите банк, где все это «на обычных серверах» построено.
Viceroyalty
BugM
Я описал стандартную архитектуру всех яндексогуглов. Это работает. Стандартным образом. Стабильнее Сбера уж точно.
Все типовое, взаимозаменяемое и быстронакатываемое. Ну вылетела железка и ладно. Просто берётся запасная. Автоматика сама на неё накатит софт и подключит слейвом к двум оставшимся.
SpiderEkb
Даже комментировать это не буду.
По нашим оценкам:
Цена выхода из строй одной «железки». Яндекс может такое себе позволить. Мы — нет.
Viceroyalty
Друзья мой, мне кажется вы спорите о разном: мистер BugM рассуждает о распределенной отказоустойчивой архитектуре, а комрад SpiderEkb говорит об отказе системы как таковой.
SpiderEkb
Да, все верно.
Строго говоря, у нас архитектура распределенная. Все, что можно вынести за пределы АБС, вынесено.
Все эти 60 систем для АБС есть «внешние системы» общающиеся с ней через WS или MQ.
Внутри АБС сконцентрировано то, что не имеет смысла дробить дальше без ущерба надежности, функциональности и сопровождаемости — слишком высоки и дороги риски.
Viceroyalty
Хотел написать, что это странно и можно сделать АБС параллельной, но это теоретические рассуждения, а практического опыта в таком у меня нет.
SpiderEkb
Что имеется ввиду?
АБС фактически является комплексом из множества одновременно работающих процессов, обрабатывающих информацию и запросы от внешних систем.
Например, есть очередь MQ. Есть «монитор» очереди, который извлекает оттуда сообщения и по заголовкам сообщений определяет в настроечных таблицах обработчик для данного типа сообщения и запускает его в отдельном процессе, передавая ему содержимое сообщения.
Есть процессы, которые запускаются фоном по определенным событиям или в определенных фазах работы.
Фактически, там многое что работает параллельно.
Но все это крутится на одном сервере. Есть еще резервный сервер, на который в любой момент возможно полное переключение всей системы (регламентное время недоступности системы в случае отказа основного сервера порядка 5 минут).
Можно раскидать все это на много железок, но начнутся потери производительности на коммуникационной шине плюс для сопровождения следить за одним сервером проще чем за несколькими железками. И каждую железку придется дублировать отдельно.
Viceroyalty
Интуиция подсказывает, что на каких-то объемах уже придется это делать, но как уже сказал
SpiderEkb
Тут дело в том, что трудно выделить какой-то процесс, который может работать изолированно от других.
Все, что возможно, уже вынесено на уровень «внешних систем».
Понимаете, все что я говорю, я говорю лишь относительно ядра АБС. Но ядро это далеко не весь банк. Это… Ну в общем, ядро оно ядро и есть :-)
И писал уже — внешних систем у нас порядка 60-ти штук. Самых разных. Они обмениваются данными с ядром через ESB шину, через WBI-MQ… Но работают вне его и вне ядрового сервера. Если ляжет внешняя система, на работоспособности ядра это никак не скажется. Если ляжет ядро — ляжет весь банк.
Дробить ядро уже невозможно — там все между собой достаточно тесно интегрировано.
AterCattus
Речь про то, что потеря одной (и более) железок вообще не должна сказываться на работе сервиса. Либо время частичного простоя измеряется долями-единицами секунд. Речь про такую систему.
SpiderEkb
Резонно. Но это достигается за счет резервирования тех самых железок, насколько я понимаю? Или постоянной динамической балансировки нагрузки между несколькими равноправными железками. Но в этом случае вылет железки в периоды пиковых нагрузок чревато лавиной отказов всего остального.
В целом же сравнивать нужно сравнимое. Например, архитектуру серверных решений банков из ТОП-10 (тех, у кого сравнимая нагрузка). Тогда можно будет говорить о преимуществах и недостатках того или иного подхода.
AterCattus
Для быстрой реакции (переключения) нужен, конечно, резерв, причём горячий. И мощности закладываются так, чтобы фактор репликации учитывался в запасе мощности. Иначе, как вы и привели пример, при отказе и временном росте нагрузки, все может стать ещё хуже.
В случае использования стандартного железа (без подходов вертикального масштабирования), это стоит адекватных денег и окупается примерно после первого сбоя, если сервис критично важен. Но тут, конечно, не могу сказать за всех, проекты бывают разные.
BugM
Примерно так это и рбаотает. Одновременно ломается единицы процентов серверов. Сервера они надежные.
10-20% запаса от серверов в проде достаточно для любой горячей замены.
Это не касается уже работающих в проде серверов естевенно. Тут как минимум от одного любого сломавшегося сервера до отключенного ДЦ надо учитывать. Так чтобы это не влияло на пользователей.
Сломалось что угодно и ладно. Все работает как раньше. Сервер из горячего запаса наливается автоматикой. Через час-два готов ко включению слейвом в любую БД или принимать нагрузку если там данных локальных не нужно.
SpiderEkb
Я писал выше — час недоступности у нас стоит порядка 24млн.
Переключение на горячий резерв в нашей системе — не более 5мин недоступности.
И еще приводил статейку выше — трехнодовый сервер на Power L922 (12 ядер) с производительностью 3064QpH обойдется в $817k.
Такой же сервер на Xeon SP (48 ядер) с производительностью 2891QpH обойдется в $1899k.
Или вы предлагаете банковские сервера строить на компах из М-Видео или DNS?
BugM
Вы специально пропустили все кроме этой фразы про час?
Зачем М-Видео? Сервера много кто делает. 2к это нормальная цена. Даже недорого ещё. Я думал там под 5к уже.
А вот 817к это неразумно.
За такие деньги можно огромное резервирование обеспечить и еще на огромный запас производительности останется.
SpiderEkb
Не 2к Смотрите вниматлеьно — 1899 тысяч долларов США
против 817 тысяч долларов США.
Но это за все «решение целиком» — 3 ноды с софтом (железо, виртуализация, ос, бд). Железо конечно скромнее — $37k за сервер на L922 против $52k за сервер на Xeon SP.
Ну и о каких серверах мы говорим? ДЛя контор типа «ООО Сукин и Сын» может и подойдет сервер за 2к, а для банка из топ-100 с несколькикми десятками миллионов клиентов и сотнями миллионов счетов — сильно сомневаюсь.
Мне почему-то не кажется что у того же яндкса или не дай бог гугля, сервера за 2к стоят…
BugM
Как раз столько и стоят. Ну может 5к.
Смысла нет платить больше. Проще взять побольше и организовать резервирование. И в прод лишний сервер добавить и в запас поставить. Так и дешевле и надежнее.
Вы все время пытаетесь принизить все остальные проекты, не надо так делать. Мы тут тоже большие вещи делаем. И даунтайм тоже много денег стоит.
SpiderEkb
Да бог с вами. Я просто хочу сравнивать сравнимое.
Вы просто скажите — сколько таблиц у вас в БД, сколько процессов вокруг этого крутится, какой примерно объем таблиц. И, главное, сколько стоит час недоступности вашей системы в деньгах и прочих рисках.
Ну или приведите конкретный примерт типа «вот ВТБ работает на серверах по 5к и у них все замечетельно».
Я просто пытаюсь сказать, что банк — это очень много данных. Это не только счета-проводки, но и огромное количество других операций с данными, которые проходят постоянно. И огромное количество отчетности. И очень жесткий контроль со стороны регулятора (ЦБ, Росфин, ФНС...). И очень жесткие требования к устойчивости и надежности. Тем более жесткие, если банк считается «системообразующим».
Если вы скажете, что ваша система управляет, скажем, АЭС (или хотя бы энергораспределительной системой крупного региона) — я готов поверить, что решение на серверах за 5к может быть надежным (просто немного представляю те требования, которые там предъявляются к устойчивости системы).
И да, я ничего не имею против серверов за 5к. Там, где этого достаточно.
Или вы думаете, что в банке не умеют считать деньги? И там сидят дурачки, которым эти деньги девать некуда, что они просто ради понтов покупают системы за сотни килобаксов? Так у нас не государственный банк. Мы живем ровно на то, что зарабатываем сами. И если было бы дешевое решение, удовлетворяющее требованием надежности, масштабируемости и сопровождаемости, то он давно бы уже работало.
BugM
Петабайты данных (именно живых данных в БД к которым идут запросы) и узнаю о более чем 15 минутном падении сервиса из новостей по телевизору это достаточно крупно для вас?
На обычных серверах за 5к работает примерно весь интернет. Да-да Гуглы, Яндексы и иже с ними.
Я вообще ничего не придумываю, я просто описываю типичную схему работы любого крупного сервиса.
Rebus
Смею заметить, что Гугл уже давно достаточно велик, чтобы создавать свои серверы самостоятельно.
Но, начинали они именно с идеологии «максимально дёшево, но заменяемо». По слухам, так живут и сейчас.
Максимально дешёвые серверы, состоящие из материнки и минимального набора компонентов, чтобы оно не вывалилось из стойки, и не сгорело.
Общий принцип — многократное резервирование и контроль за тем, что именно сгорело. Вроде бы работает: на серваках Гугла (включая youtube, и других), чуть ли ни четверть мирового интернет-трафика.
Основной идеей выбора именно такой основной идеи было то, что поставщики серверов дерут втридорога, и всё-равно не способны обеспечить даже 3 девятки.
BugM
Так это и есть ровно то что я описываю.
Горячий резерв с автоналивкой новых серверов.
Отказоустойчивость всех систем к вылету любой одной единицы. Подозреваю что у Гугла это ДЦ целиком.
И типовое недорогое железо. Зато много железа.
Гугл типовое железо может удешевить сделав свою карманную контору по сборке серверов, ну и хорошо. Те кто не могут такую сделать просто на рынке покупают.
SpiderEkb
Там немного другое.
Ну какова цена того, что кто-то вдруг не сможет посмотреть ролик на трубе прямо сейчас? Да никакая. Ну посмотрит через полчаса. Ну пошумят из телевизора «ах, на гугле что-то сбойнуло». Все.
А теперь представьте что вы пытаетесь расплатиться картой в магазине, а вам говорят «извините, ваша карта не работает потому что ваш банк не отвечает». А потом выясняется, что он начал отвечать, но пропали последние несколько операций по вашей карте, которые не успели отзеркалиться на резерв перед тем как упала железка на которой они хранились.
Т.е. тут надо не просто иметь резервную железку, тут надо еще чтобы эта железка в реальном времени зеркалилась с рабочей. И так для всех железок в системе…
Да, можно одну большоую дорогую железяку заменить на много маленьких и дешевых. И для каждой создать горячее зеркало. Но будет ли это дешевле в итоге? В том числе и в сопровождении? Вот не факт.
И такой момент — у того же гугля — труба отдельно, почта отдельно, диск отдельно. Это разные системы, достаточно независимые. Их можно разнести.
В банке тоже много разных независимых систем: инетбанк, мобильное приложение, процессинг, рассылка уведомлений — все это внешние системы, их можно отделить физически. Но ядро АБС неделимо. Там все данные очень тесно связаны между собой (практически все таблицы имеют перекрестные связи так или иначе) и падение любой из них в той или иной степени затронет всю систему целиком.
Разнеси все это на 10 дешевых железок — надежность только уменьшится т.к. падение любой железки будет означать падение всей системы целиком.
ALexhha
Правда видел во многих супермаркетах ставят по два терминала. Один из которых не приватовский. Видать страхуются от таких вот сюрпризов
Viceroyalty
.
SpiderEkb
Секунд — да. Минут… Уже может влиять. А вот если часы? Те же карты — два часа не работают — это ЧП для банка.
А если еще у приоритетного клиента в это время не прошел платеж на несколько миллионов — тут уже не отмоешься.
ALexhha
BugM
Если для банка важен один клиент, то такой банк не нужен.
Вот буквально неделю назад https://www.interfax.ru/russia/758335
Крупнейший банк. Упал серьезно. И всем пофиг.
Не переоценивайте надежность или ценность аптайма банков. Падают за милую душу. Чаще Гугла. В разы чаще.
BugM
Ну да. Ютуб упал мелочь какая. Гугл будет терять миллионы долларов в минуту, если не больше. По сравнению с ним потери любого российского банка это тьфу. Копейки.
Для обычных серверов лучше иметь минимум три такие железки. Резервирование это абсолютно нормально.
Напомню что началось все с того что я предложил вместо магии использовать типовой кеш. Для kv нагрузки на одну из таблиц. И сразу нагрузка упадет.
Кажется там много таких мест. Которые можно безболезненно вынести.
sumanai
ИЧСХ, он падал, и не раз, и иногда на часы. Впрочем не из-за выхода железок из строя, да.
SpiderEkb
Достаточно крупно. Согласен.
Но вы не сказали сколько, например, обновлений БД в сутки проходит у вас. Сколько процессов крутится вокруг БД. Ну чтобы проще понять — вот пришел запрос — что происходит? Поиск в БД и возврат ответа? Или если это (к примеру) запрос на изменение данных, он вызывает длинную цепочку множества вторичных изменений, различных проверок, формирование отсылок данных в различные внешние системы…
Что произойдет если пропадет, скажем, одна запись в БД?
Сколько денег вы потеряете за эти 15 минут простоя?
Ну вот для примера — есть Госуслуги. Которые регулярно встаю колом в момент записи детей в школы. Шуму по этому поводу из каждого утюга. И что? Да ничего…
А если в банке произойдет сбой в системе контроля платежей и пройдет платеж в сторону получателя из списка росфина, кричать по телевизору о том не станут. Но регулятор выкатит штраф с очень многими нулями.
Если произойдет сбой в других системах, то сотни тысяч клиентов по всей стране могут оказаться в магазине перед кассой с невозможностью расплатиться картой «нет ответа от банка».
Повторюсь — я не думаю, что в банке не умеют считать деньги. И была бы возможность обойтись сервером за 5к — обошлись бы.
ALexhha
SpiderEkb
Да. Классический пример — один австралийский банк (по-моему, Банк Содружества Австралии или что-то в этом роде) повелся на модный ныне тезис «долой легаси, писать нужно на современных языках» и решил переписать весь банковский софт (работающий) с кобола на что-то современное.
В итоге обошлось им это в $750млн, пять лет работы (не знаю уж сколько там народа работало, но по объемам нашей системы могу предположить что не одна сотня человек) и потом еще глюки вылавливали долго. В том числе и такие как обнуление кредитных задолженностей всех клиентов :-)
Так что что-то менять — это очень дорого, да.
Но ведь был момент когда все это строилось с нуля. И в этот момент изучался опыт, выбиралась платформа… Одни банки выбирают оракл, другие еще что-то. У нас вот выбрали as/400 (ibm i) и db2. Что лучше что хуже — тут нет однозначного ответа.
Тут еще есть момент поддержки производителя. Которая тоже входит в стоимость оборудования. Знаю что у нас есть свой представитель в IBM. Знаю что мы можем с любой проблемой туда обратится и ее будут решать незамедлтельно. Знаю что мы можем заказать аудит производительности — приедут спецы, проедут аудит, покажут тонкие места, дадут рекомендации по оптимизации… Все это входит в цену платформы на котрой мы работаем
ALexhha
Когда у тебя час простоя 1кк$, то логично что у тебя скорее всего куплена gold/premium подписка от вендора. И в здравом уме условный CentOS никто в таким системах ставить не будет. А будет RHEL с максимальной подпиской. Где время реакции отличается.
Знакомый рассказывал, что у них на сервер IBM был установлен RHEL7 и была подписка, какой уровень точно не помню. И возникли проблемы с драйверами raid контроллера, который естественно был сертифицирован IBM и RedHat
В итоге, сам RedHat исправили багу в драйвере и отдали им исправленную версию драйвера
SpiderEkb
У нас платформа IBM i (i5/OS которая, наследница AS/400). Но в целом так, да. На любой вопрос сразу дают разъяснения. Обновления системы получаем быстро (тут уже наши решают когда накатывать — это тоже процесс небыстрый и ответственный).
Уровень подписки не знаю какой, знаю что есть представитель (его почему-то называют «адвокат») — что-то типа персонального менеджера непосредственно в IBM.
Viceroyalty
Я тут много комментов написал — но может дело еще в том, что для организации есть профильный бизнес?
Если ваш основной бизнес это интернет-поиск (условно, вы — Гугл), то вам для снижения расходов и повышения эффективности логично переписать половину ОС или применить необычные паттерны, создав новый язык программирования, но при этом вы будете держать основные деньги на обычных счетах юрлица в нескольких нацбанках и получать банковские переводы «на следующий день».
А если ваш основной бизнес это финансовые услуги — (условно вы — Industrial and Commercial Bank of China) вам для снижения издержек и повышения эффективности логично захеджировать рискованные активы, не позволять деньгам сверх необходимого лежать на коррсчетах, участвовать в маржинальных сделках по всему миру и т.п., но вы купите проверенные серверы у надежных производителей и используете зарекомендовавшие себя в банковской сере подходы к разработке софта.
SpiderEkb
Да, Вы правы. Для банка это всего лишь инструмент. Посему, ищется готовое решение, удовлетворяющее ряду требований по надежности, производительности, расширяемости и сопровождаемости, имеющее хороший уровень поддержки производителем.
АБС у нас тоже не на 100% своя. Купили основу (позже выкупили исходники), которая обладает базовым функционалом плюс позволяет писать свои расширения к ней. И с тех пор расширяем ее функционал для обеспечения автоматизации наших бизнес-процессов и соответствия текущему законодательству и требованиям регулятора.
Т.е. у нас ест стандарты, обусловленные структурой базовой части АБС плюс набор уже наших нефункциональных требований, обусловленных эффективностью и производительностью программных модулей.
Viceroyalty
.
BugM
Базы как базы. Пишутся, читаются. Все что транзакционно надо менять по сложной логике вынесено в отдельные кластера. Биг дата без транзакций, естесвенно.
Из плюсов: пропадение строчки в некоторых местах допустимо. Но чтобы БД теряла за последний год я не припомню. Это скорее бонус обработке. Можно немного менее параноидально писать код. Терять даже 1% недопустимо. Тут речь именно про потерю любой одной записи.
Деньги меряются в милионах за минуты простоя. Точнее не скажу. Много в общем.
Гугл как-то обходится. Только не надо говорить что у вас надежность больше чем у кор сервисов Гугла. Или что вы потеряете больше денег чем они.
SpiderEkb
Согласен. Но это означает горячий резерв любой железки. А это тоже стоит денег.
oYASo
Вы занимаетесь крутыми штуками :)
Думаю, Ваш случай — это косяк HR (а с ними постоянно косяки). То, что ваши пожелания сразу не были учтены — это вот самый первый признак того, что где-то в цепочке между HR, который с вами общался, и интервьювером, что-то сломалось (а там может быть много человек).
siziyman
Вы-таки не поверите, но можно хорошо задрочить литкод и в целом алгоритмическую базу и всё равно быть плохим, даже отвратительным разработчиком, просто не в тех же аспектах, что и Senior Spring/Django/Symfony Developer, который не умеет сортировать массив быстрее, чем за O(n^2 log n) (да, я утрирую, я знаю, что это медленнее пузырьков и прочих сортировок вставками)
oYASo
Я не утверждаю, что найм в Я идеальный (и даже хороший). Просто он такой. Такой же он и в FAANG.
В таких компаниях не смотрят навыки работы с технологиями, а смотрят алгоритмы, структуры данных, умение быстро решать задачи и т.д. Кому-то это подходит, кому-то нет. Это как спорить с тем, что вода с более высокой позиции течет в более низкую.
Вот знаете, среди тех, кто круто задрочил литкод, я не видел плохих разработчиков. Есть обратные примеры?
Да, много кто теоретизирует, что «задрочить литкод — фигня», «олимпиадники не умеют писать код» и т.д., но на практике это все самые топовые разрабы, которые могут вообще в любой проблеме разобраться, а не только список развернуть. Я лично с такими долго работал, и говорю это со всей серьезностью — это лучшие разрабы, у которых я очень многому научился.
Эти все нужно вне больших компаний.
Viceroyalty
Может, просто большие компании настолько богатые и желанные для новичков, что им не приходится тратить силы на разработку эффективной системы найма.
Ведь чем больше система тем сильнее «и так работает»/«ни чего же не произошло»/«так сложилось исторически», а уж если нужда не заставляет меняться то ни какие инициативы снизу (по крайней мере по непрофильным вопросам) не пройдут через руководитво.
masai
Порой действительно не умеют, но быстро учатся.
Thahr
Интересно мнение бывшего яндексоида. Почему Я проводит так много алго-раундов? 10 задач выглядит как перебор, почему не разбавить system design раундом?
Большие компании спрашивают меньше: не считая первого скрининга, на Senior Амазон тратит 3 алго раунда, из них половина времени на leadership principles, в итоге 3 задачи всего. Гугл 3 раунда, 3-6 задач, Фейсбук 2 раунда, 2-4 задачи. При этом всегда есть system design раунд.
Dan_Te
Если вы про конкретно данную статью, то выглядит так, что
1) у автора хорошее резюме, им заинтересовались разные команды
2) он не особо хорошо решал задачи, одна команда теряла интерес и отваливалась, другая подключалась и начинала снова «с нуля», затем история повторялась
3) в системе найма никто не сказал «эй, не надо спрашивать пять раз одно и то же, доверяйте результатам других команд», в результате получилась какая-то ерунда.
Thahr
По пункту 2 и 3 — почему не почитать фидбек с предыдущих раундов, которые твои коллеги проводили, код посмотреть? Нужно чтобы кто-то обязательно подсказал со стороны? Выглядит странно.
Вопрос не только по конкретной ситуации, знаю людей которые тоже по 10 задач решали с 8+ лет опыта и без раундов по систем-дизайну (или их нет в Яндексе?).
Dan_Te
> Выглядит странно.
да, я согласен
Раунды по систем-дизайну делают для старших грейдов.
Thahr
Для "старших грейдов" — это надо подаваться на вакансии с уровня Старший специалист чтобы у тебя провели System Design?
BugM
Обычно интервьюеры сами решают надо или нет. По итогам как раз этих самых задачек.
Dan_Te
Почти во всех разработческих вакансиях ищут «от младшего до старшего», так что можно подаваться практически на любую.
oYASo
В разные части Яндекса (бизнес-юниты) собеседования проходят немного по-разному: где-то больше хардкора, где-то меньше. Автор, кстати, собеседовался туда, где хардкора меньше :) Пошел бы в поисковый портал, его бы остановили еще на первом собесе и поставили no hire (например, задачу RLE автор сделал с ошибкой, она не работает).
Dan_Te написал верно, его, скорее всего, рассматривали разные команды, а т.к. уровень и код был так себе, то разные руководители искали, подходит ли им этот кандидат.
Насчет system design — он есть на старшие грейды. Если бы из собеса было понятно, что кандидат претендует на старший грейд, ему бы провели архитектурную секцию. Даже по его решениям я могу сказать, что явно не претендовал.
ALexhha
убогиене крутые?briarheart
Технические подробности, приправленные здоровым юмором — это отличный стиль изложения. Прочитал с удовольствием.
N лет назад тоже проходил несколько кругов
адасобеседования в Яндекс. На мой взгляд всё было плюс-минус похоже. Разница лишь в том, что это были очные собесы и с некоторыми интервьюерами можно было перекинуться парой-тройкой фраз «за жизнь».Всех мини-боссов мне в итоге одолеть не удалось, однако боюсь, что такой упор, который делает Яндекс на алгоритмические задачи, очень слабо коррелирует с тем, чем придётся заниматься на ежедневной основе. Исключением пожалуй может стать должность заведующего алгоритмами поиска или управления беспилотными автомобилями, но тогда вероятно «Искусство программирования» Дональда Кнута придётся зачитать до дыр.
tyderh
Нет. Суть в том, что это работает как proof-of-work. Теория такая: если ты способен выучить алгоритмы, то ты, вероятно, толковый специалист. У этого есть две стороны:
"А можно быстрее?" — это всегда хороший вопрос. Потому что даже если решение "правильное", сделать его быстрее почти всегда можно. И даже если нельзя быстрее, можно показать, что ты в целом знаешь, как подходить к этому вопросу. Или показать, что не знаешь.
starosta6123
Решение задачи №4:
starosta6123
Может минус я получил от Яндекса, что означает «не стоит к нам совать нос»?
X-Oleg
Хе не так давно тоже пробовал на позицию «Разработчик беспилотных автомобилей» и завалился на алгоритмах, ну там на первом этапе были простые задачи типо обход дерева и вопросы из серии «Что такое стек» и т.д.
По специальности минимум вопросов было…
На втором этапе нужно было сделать реализацию LRU кеша, в итоге я не решил за отведенное время и всё, отказ прям в этот-же день...:(
По началу расстроился, т.к. на эту позицию сделал им ещё тестовое задание, преобразователь Erhernet ->CAN, зачем нужно тестовое задание, если оно ничего не решает непонятно…
Рассчитывал на беседу по специальности, а получилась беседа в области к сожалению где я мало чего знаю, хотя сейчас решил подтянуть алгоритмы.)))
Понятное дело, компании виднее, но утомительные беседы отталкивают всякое желание пробовать ещё раз.
Хотя согласен, что всё-же алгоритмы не плохо-бы подучить, хотя на практике редко приходится их вот так самому с нуля писать.)
Даже в моей области, когда используешь вообще голый Си, где ничего нет, быстрее будет взять уже готовый алгоритм, например алгоритм быстрый сортировки, чем сидеть и тратить время на его реализацию.)
Зачем всё-же знать алгоритмы?
Бывают ситуации, что-бы понять какой выбрать, ну и если есть какие-то ошибки в реализации, для отладки нужно понимать суть.
А-так, да все эти вопросы — это теория, по факту мало чего показывают, но повторюсь компаниям виднее, примерно так спрашивают не только Яндекс, а и тот-же Касперский например, правда там меньше секций, но суть примерно такая-же.)
starosta6123
Еще вариант решения задачи №4
starosta6123
Хочу увидеть правильное решение от минусующих! Или хотя бы почему?
wataru
Не минусовал. Ваше решение похоже работает. Но минусуют, наверно, потому что у кого-то возникла мысль "хвастается, зачем-то. Никто же не спрашивал, как решать задачу, зачем это писать?"
Или кому-то не понравилось, что вы обрабатываете отдельно случай всех единиц в массиве. Плюс код работает очень неявно. Непонятно, чем именно является last_length, почему они суммируются именно при 0. Еще, возможно из-за двух подряд идущих комментариев от вас с решением.
Есть, например, вот такое решение. Оно мне кажется проще и понятнее:
Это, фактически, динамическое программирование. Но можно о нем рассуждать и не зная ДП. F(i,k) — максимальная длина из '1' в конце списка из первых i элементов, если оттуда удалить k элементов. Для k=0, оно считается в current_ones. При k=1, оно считается в current_result и там выбираются 2 варианта — или элемент удален раньше или удаляется последний элемент.
swelf
— Уважаемый , к сожалению по результатам собеседований вы совсем немного не дотягиваете до senior engineer, но мы в лавке готовы предложить вам другую позицию
— Middle?
— Курьер.
Где-то в 2012 проходил собеседования на сисадмина, было 1 телефонное, 1 скайп и 1 очное техническое, после чего сделали оффер. Толи время идет и все меняется, толи просто из-за различий в позициях и админам и щас после 3х собесов дают оффер.
DrBulkin
вот уперся вам этот яндекс
snakers4
Писал статью про найм людей на питоне прошлым летом (в ML-стартап) но подход диаметрально противоположный, зацените, тогда вроде всем зашло.
Причем что важно — выбрали в итоге людей, которые бы наверное не прошли бы 4 раунда таких "испытаний", но у них все в порядке с головой и они всегда решают именно "реальную" задачу и стремятся найти креативные и творческие решения нетривиальных задач.
Не стал ее постить напрямую на Хабр, т.к. побоялся, что за такую нативную "рекламу" словлю пермабан на Хабре. Но автор молодец, вроде не боится =)
kesn Автор
Ну забанят — буду ещё где-нибудь писать. Тем более это так себе реклама, никто не пишет почти.
Dan_Te
> подход диаметрально противоположный, зацените, тогда вроде всем зашло
я прочитал, заценил, интересная статья, но:
1) подход через соревнования или ДЗ, действительно, позволяет гораздо больше понять про кандидата. Надо заставить человека реально поработать, и все становится ясно. Но с таким подходом можно нанимать либо студентов, либо очень мотивированных работать именно у вас людей, другие не станут тратить время. Да даже неприлично как-то работающего человека заставлять. Я тоже применяю иногда ДЗ, но только в самых крайних случаях (и когда уверен, что кандидат сам это позитивно воспримет, ведь ДЗ позволит и ему тоже понять, интересны ли ему наши задачи), так вообще это запрещенный инструмент.
2) сама за себя говорит цитата: «Это стоило больших усилия для меня лично и для нашей команды.»
Так что подход у вас, конечно, прикольный, но на вооружение его вряд ли стоит брать. Более того, вряд ли вы сами захотите подобным образом развлекаться в следующий раз. Процесс найма в компанию должен быть масштабируемым и повторяемым, описанный процесс этому не соответствует.
Еще меня местами зацепили подколки, троллинг, и в целом не видно по тексту, чтобы вы с уважением относились к кандидатам, но возможно, что это такая манера изложения, а в жизни было все плюшево.
rakot
Без шуток, это хорошее собеседование для студента без опыта работы, т.е. если работодатель уверен в том что соискатель ничего не умеет и "пороха не нюхал", то вариант отличный, но у готового специалиста спрашивать такое — бесполезная трата времени, причем для абсолютно всех.
leyte
Собеседовался 3 раза в общей сложности. Все три завалил, лучший результат — 4ый собес, 5/6 решённых задач. Последний раз собеседовался в сервис, который использую как минимум раз в неделю. И который был практически неюзабельным несколько недель из-за глупой ошибки бизнес-логики: цена фиксировалась на интервал меньший, чем нужно человеку на подтверждение действия. Очень хотелось уже устроиться и делать человеческий сервис, с человеческим качеством пользовательского опыта. (Да, я наивен до степени уверенности, что могу что-то изменить в корпорации). Но не получится.
Basilisco
Копирайтеров они тоже по алгоритмам ищут, так что до боли знакомо
Layorn
Есть точка зрения, что собеседование в Яндексе построено абсолютно правильно.
У меня были коллеги, которые уходили в эту компанию. Несмотря на разносторонние знания, в Яндексе их сажали на простую работу, вроде однообразных скриптов на Perl.
Четыре часа таких собеседований проверят, устойчивы ли вы к подобной работе (причём каждое следующее проводит рекрутер более высокого уровня, а вы к нему приходите всё более и более вымотанным).
В конечном итоге, такая цепочка даст ответ на главный вопрос: действительно ли у вас математический склад ума? Потому что только человек с таким складом способен находить удовольствие в подобных задачах. А это — внезапно — психологическая основа системного программирования.
Вывод: Яндекс успешно применяет «сито» задач, через которое могут просочиться только люди с математическим складом ума, способные стать хорошими системными программистами. При этом какие именно у вас знания, им неважно. Думаете, там своих креативных технических начальников не хватает?
balberbro
«измытывающе сито»
«скрипты на perl»
«зп ниже рынка»
Зачем?
KvanTTT
Ну может кто-то считает, что Яндекс — полезная строчка в резюме.
PsyHaSTe
Возможно про ниже рынка это миф. По крайней мере у меня противоречивая информация насчет доходов. Если считать не оклад, а вообще все доходные статьи
balberbro
1) Зарплаты идут достаточно низкие для того уровня, который ты представляешь и для того объема работы, что надо делать. Все же надо понимать, что работать 8 часов в день и потом идти заниматься другими делами, и доступность 24/7 с дежурствами — это немного разная работа, которая требует разную оплату труда.
2) В компании система грейдов, что заставляет тебя сидеть на одном уровне и просаживаться с течением времени по зп посравнению с ранком (если ты не какой-то супер-звезда).
3) Выдача RSU идет весьма по сложной схеме, где от тебя мало что зависит. Как итог, тебе их могут дать — а могут и не дать. И потом еще сиди работай 4 года, чтобы их забрать в полной мере.
4) RSU штука нестабильная — если акции идут вверх, ты хорошо получаешь. Если акции идут вниз, то ты меньше получаешь. Тут в общем лоттеря.
Как итог: зачем дрочиться, учить велосипеды, надеяться на RSU и левую пятку какого-то менеджера, если можно тупо с рынка получить эту же зп в кеше, что перекрывает любые риски RSU.
PsyHaSTe
НУ я слышал от людей что они по 500к имеют. При том что в условных банках потолок который я видел в районе 350, реже 400.
kha0s
Думаю, у Яндекса и подобных компаний сильная специфика, которая приводит к такому процессу.
AxisPod
Highload на питоне, смишно, очень.
alexshy
Одним словом чувствуется, народ заделся за живое.
В сухом остатке: особого пиетета к компании нет, но желание на нее поработать есть. Прагматично, чо.
Krypt
Мне кажется, у них систему заклинило, и они давали вам всегда начальные задачи. (И в связи с тем, что каждый раз собеседователи разные — они не могли этого заметить, если вы им не говорили)
К слову, я с вами не соглашусь по поводу оценки сложности: это единственный навык полученный в универе, которым я пользуюсь регулярно при написании кода.
kozzztik
Не, у меня было так же, вежливо уточнил у HRа не возникло ли тут какой ошибки. Нет, так и задумано.
sergpank
Лет 8 назад собеседовался на Java мидла.
Задачки были годные (всего 3 штуки).
В процессе решения узнал новые для себя структуры данных — суффиксное дерево и суффиксный массив.
Когда дошло до собеседования с будущими коллегами начали спрашивать про размер инта, сортировки. Очень удивился таким вопросам после решения достаточно сложных тестовых задач.
В итоге предложили вместо джависта должность автоматчика XD
Впечатления остались смешанные, но в общем получил позитивный опыт.
thenikita
Неужели в Яндекс так много желающих? Обычно сложность итервью прямо пропорциональна количеству кандидатов.
sumanai
Ну в общем то да, имя компании делает своё дело.
askarbin
К этому собеседованию надо быть реально готовым. Иначе можно получить психологическую травму.
fsocial
Пару недель назад собеседовался в Деньги, или как они себя сейчас называют Юmoney на мидл NetOps.
2 часа веселья с iptables, contrack и, барабанная дробь, алгоритмами на python.
Из 2 часов про сеть было задано ровно 2 вопроса. Остальное прям глубокое-глубокое погружение в недры iptables.
После интервью чувствовал себя как лимон после соковыжималки.
Оффер получил очень странный вида «ЗП столько то, НО ЗАТО МЫ КОМПИНСИРУЕМ ПИТАНИЕ»
sumanai
Это же 5000 рублей в месяц! Как вы могли отказаться от такого!
Alexandroppolus
Тонко намекнули: "да, чувак, ты всё правильно понял, это работа за еду"
i360u
Лично знаю людей, не прошедших отбор в Яндекс, которые на порядок круче тех, кто прошел.
masai
Это к любой компании относится. В любом интервью есть элемент случайности и субъективности.
frobeniusfg
Вот список задач на leetcode или полностью совпадающих с приведенными в статье или близких к ним (некоторые залочены):
1) Intersection of two arrays
2) String compression
3) Summary ranges
4) Longest subarray of 1s after deleting one element
5) Number of students doing homework at a given time
6) Group anagrams
7) Merge intervals
8) Line reflection
9) One edit distance
10) Subarray sum equals k
kesn Автор
Святой человек! Спасибо
frobeniusfg
del
yurysannikov
Похоже, во второй задаче, после
count += 1
нужно добавитьlast_sym = sym
. Иначе основное условие никогда не выполнится.jobgemws
Теперь понятно почему такого качества их решения)
Зачем тратить время на компанию, которая не может в течении 45 минут решить стоит брать спеца на испытательный срок или нет?
Более 1-го собеседования прводят на руководящие должности, а 3+ собеседования-на техдира или около того.
Зачем тратить свое время? Они тратят по часу каждый, а Вы — сумму от каждого такого собеседования. И если бы оно что-то давало, так кроме основ ничего ценного.
Плюс процессы далеко не самые нормальные и оптимальные, о чем и говорит сам процесс найма, да и условия работы в лучшем случае средние или чуть выше средних по рынку.
Ищите нормальные, а лучше хорошие компании с человеческим лицом.
Тем более если Вам хорошо на текущем месте, то зачем тратить энергию в пустоту? Сделайте что-нибудь полезное для своей работы сверхположенного и получите за это премию и/или повышение. Не ведитесь на распиаренные компании. Отличным компаниям пиар не нужен. А лучший вариант, когда к Вам сами придут, поговорят по-человечески и предложат. Остальных отсеивайте. Первые лет 5-6 стоит искать, а потом наоборот-делайте по душе и отлично, и за Вами потянутся. К тому же у Вас замечательная компания)
Статья класс! Спасибо)
glestwid
Зачем тратить время на компанию, которая не может в течении 45 минут решить стоит брать спеца на испытательный срок или нет?
Ну, мало ли. Может, кто-то себя на помойке нашел чтобы так задрачиваться...
BugM
Вы ищете себе компанию в которой собираете проработать несколько лет минимум (если меньше, то вы этой компании сразу не нужны).
Не малая часть работы заключается в перекладывании джейсонов. То есть те самые однообразные действия при нечеткой постановке задачи. Менеджры в тикетах редко все полностью расписывают.
И квадратичную сложность нельзя случайно нигде сделать. А если кто-то другой сделал, то ее надо на код ревью увидеть и попросить поправить.
Замечу что специально квадратичную сложность делать можно. Задачи разные бывают. Надо это понимать, обкладываться кешами в три слоя, рейт лимитерами и готовить план контролируемой деградации если всего этого не хватит.
Вроде всего этого от вас и хотят на собеседовании. Много однообразных задач. Умение не сделать квадратичную сложность. Потратить даже пару дней, если едете из другого города, чтобы найти себе место работы на несколько лет не выглядит страшным. 0.2% рабочего времени из рассчета трех лет работы.
jobgemws
Суть в том, что вакансий и компаний много и на всех тратить много времени-слишком затратно, равно как и компании тратить много времени на каждого кандидата.
Нужно уметь ценить свое и чужое время и оптимально выстраивать процессы.
45 минут вполне достаточно при диалоге, чтобы решить допускать кандидата на испытательный срок или нет. Далее все определяется в течении 2-6 недель на испытательном сроке. Не стоит пытаться определить все сразу-это просто невозможно, для этого и есть исп срок.
BugM
У больших компаний кандидатов много. Брать всех брать на испытательный срок дорого. Это же им маки выдать надо, стол и место в офисе организовать итд.
Уже работающие люди будут тратить много больше своего времени чтобы помочь новичку разобраться в том как все устроено. Дешевле потратить 4-5 часов на то чтобы сразу отсеять большую часть. И повысить вероятность прохождения испытательного срока.
jobgemws
Уже давно пушечным мясом не являюсь.
Если ищут кого-то-то пусть они и проходят все этапы.
Если кого-то конкретного, и я им подхожу, то пообщаемся, а там обоюдно определим стоит начать сотрудничество или нет.
И никаких трат времени ни моего, ни компании на многоэтапные и длинные собесы. Просто предложение и диалог. Все.
На все остальное немало желающих, лично в этом я не участвую.
Мое время дорого.
BugM
Ну и отлично. Условия никто не скрывает, наоборот о них говорят по несколько раз перед началом. Вам они не нравятся, вы и не идете.
Схема отлично работает именно для вас. Фильтр срабатывает даже до начала процесса собеседований, никто не тратит свое время просто так.
Время HR на масс рассылку предложений поработать не стоит почти ничего. Ваш игнор таких писем тоже. Их игнорируем.
jobgemws
Проблема в том, что часто не понимают кого и как искать.
Но да это проблема таких компаний со всеми вытекающими последствиями в будущем.
omikad
Спасибо за задачки, довольно простые и на известные темы. Вот мои решения:
s0llar
481 комментарий выше моего, на момент написания сего комментария.
Я Солидарен с автором, ибо в у меня был подобный опыт. Рекрутер Яндекса 2 недели ежедневно зомбировала меня пройти их Интервью (с большой буквы), и я сдался, решил попробовать, хотя все друзья убеждали не делать этого. Ска, ШЕСТЬ, ДА ШЕСТЬ разных интервьюеров, почти 10 часов потраченного времени…
И сам подход один а один как у автороа. А его интервью 4… Мне кажется у нас был один и тот же интервьювер.
Как итог, 4 из шести пройдены (исходя из фидбека рекрутера). Но мне всё же рекомендовано пройти половину задачь из letcode ))) И попробовать к ним снова — ХАХАХАХА (Яндекс, напишите алгоритм, какая буква тут лишня)
Да закикайте меня шпалами! Но я солидарен с автором.
Представители Яндекса, скажите, что реально вы получаете от такого процесса? Это просто попытка повторить Гугл? Фейсбук? Так там ещё и про отношение к меньшинствам спрашивают ), а вы нет!
Woodroof
Ни Гугл, ни FB не задал мне на собеседовании ни одного вопроса про меньшинства, так что если такое и есть, то это выброс.
Stas911
Ни в одной крупной конторе меня ни разу не спрашивали про возраст, религию, семейное положение или отношение к каким-то группам. Это строго запрещено и дураков такое спрашивать нет.
wataru
Мы в гугле в отчетах комитету, который принимает решение о найме, даже "he/she" не пишем — только "they" или "the candidate". Если в отчете написать что-то про возраст или внешний вид кандидата, его тупо выкинут и попросят больше так никогда не делать.
Hunya
А вы пробовали… Сказать, что уже решали эти задачу? Я тоже сталкивалась с тем, что первый собеседователь спросил то, что должен был второй. Я сказала второму, что это уже спрашивали, и меня просто начали спрашивать обо мне (оффер мне в итоге сделали, но там была другая странная/туппя история, но это же яндекс)
valeris2
У меня был прямо противоположный опыт с Amazon, но с такими же ощущениями после собеседования.
Позиция Senior Consultant — техническая, помогать клиентам с дизайном \ улучшением их AWS Environments.
Телефонный скрининг — нормально, не сложные технические вопросы.
Потом онлайн анкета на 2.5 часа — снова легкие технические вопросы и очень много опросников, связанных скорее с психологией.
Потом домашнее задание на 2 часа — дана архитектураная диаграмма в вакууме — что можно улучшить. Ну хоть что-то интересное, да и одно из «on-site» интервью будет по ней.
Ну и пришло время 5x45 минут собеседований за день:
1) behavioural and leadership — вопросы только такого плана
2) ^^^
3) ^^^
4) 15 минут по архитектуре, потом ^^^
5) смотри #1
Итого из 5ти собеседований на техническую позицию, только 15 минут технического интервью.
Единственный способ пройти такое — это на каждый из 15ти leadership principles написать по ~5 примеров из своего опыта (а учитывая общее кол-во — скорее придумать большую часть).
Ну и как тренд — никакого фидбека, а то вдруг удумаешь их засудить
MadPar
Хочу заметить по поводу "каждый следующий интервью не знал моего контекста". Немного не так. По результатам каждого этапа интервью пишет отчёт, в котором указывает, что спрашивал, что по его мнению сильно, что слабо. Следующий интервьюер это видит. Ну или должен видеть, по крайней мере. Возможно ваши решения не удовлетворил первого, второй решил перепроверить. Ответ на вопрос, на который на предыдущем этапе ответа не было, это однозначно плюс, значит человек заморочился и узнал для себя что-то новое.
P.S. Был в, привлекался, не разраб, уже нет :)
Amega
Стиль изложения, конечно, неплох, хотя слишком прослеживается туннелинг, а именно — продавливание своего мнения насчет этих собеседований.
Тем не менее, хочу сказать несколько слов в защиту Яндекса, уточнив при этом, что не являюсь их сотрудником, и не горю желанием им быть, хотя тоже уже много раз звали на аналогичные должности и зарплаты.
Первое, что хочу сказать, что то, каким будет интервью, решает целиком и полностью работодатель. И если ему важно найти специалиста с конкретными навыками (в данном случае — умением решать сложные алгоритмические задачи), их право устраивать такие испытания, какие они посчитают нужными. Если, конечно, они осознанно это делают, а не потому, что так выдал поисковик по запросу «что спросить на собеседовании».
Многочисленные «одинаковые» собеседования могут действительно показаться избыточными, но если исходить из того, что они действительно хотят подобрать хорошего специалиста, это можно рассматривать как некоторую «диверсификацию» и распределение во времени. Не каждый смог бы выдержать 4х-часовое интервью с такими задачами. В плане разных людей — как раз может быть элементом диверсификации, чтобы получить оценку тебя как кандидата от разных людей в компании.
Ну а насколько им действительно нужны сильные алгоритмисты, им, конечно, виднее. Но предлагаю также взглянуть на ситуацию вообще со стороны как пользователю подобных сервисов. Вот, в Деливери, возможно, гораздо более «правильные» собеседования, но и не стоит удивляться при этом таким случаям, когда ты заказываешь еду за 40 минут до закрытия ресторана, а только через 20 минут уже после закрытия получаешь уведомление «М, извините, мы не успели :( Ресторан уже закрылся.» Все же логистика — не самая простая область.
Dr_Zoidberg
уважаемый автор, давай так. 200 к рублей это что-то около 2600$. Я тебе даю 3500$ в месяц и ты принят без собеседований.
tm1218
Я бы лучше предложил интервьюеру партейку в шахматы. На порядок объективнее будет впечатление о кандидате, а не демонстрация зазубренных подходов в решение NP-сложных задач.
Насчёт «изобретения велосипедов» тут правда, частично, на стороне Яндекса: насколько я знаю у них свой самописный STL, а также много собственных проектов для внутренней инфраструктуры(к примеру: система контроля версий). Так что им, действительно, нужно много вещей городить для себя
BugM
Вы действительно считаете ценным умение выучить наизусть 10500 типовых комбинаций?
Все шаматы чуть выше любителя и ниже мс (может и они тоже не буду настаивать) сводятся именно к этому.
tm1218
Правильность выбора из набора зазубренных комбинаций зависит от развитого интуитивного мышления, которое не чуждо и в алгоритмистике. Ведь ни для кого не секрет, что огромное количество открытий в науке и технике случались «тычком пальца» в небо. Я имел ввиду объективность испытаний. По моему мнению шахматы более наглядны в этом плане, там с большей вероятностью будет победитель и проигравший, да и по манере игры можно многое выяснить о человеке. В статье автор настаивает на адекватности своих решений в столь сжатые сроки, в чём я с ним не могу не согласиться, но проверяющие, по-видимому, были иного мнения, раз направляли его на дополнительные испытания.
BugM
Чтобы в шахматах что-то выбирать надо для начала заучить все эти комбинациию. Очень много комбинаций. На этом большая часть разрядников и ломается. Вся манера игры зависит от количества выученных позиций.
Все что вы узнаете после партии это уровень вашего противника. Сколько он выучил и какой разрад у него. Ну примерно.
И что вы собираетесь делать с этими знаниями? Как их использовать для найма?
tm1218
Погодите с наймом пока. Тут надо выяснить более фундаментальные вопросы. Вы когда-нибудь видели шахматы в глаза, коль так рассуждаете?
BugM
Конечно. Я знаю как устроены современные шахматы. И как выглядит обучение.
На уровне разрядов, но этого достаточно. Не чемпионат мира рассматриваем.
arrakisfremen
Разругался вхлам с этой копрокорпорацией, когда это ещё небыло мейнстримом. На форум приходил ругаться интервьювер, менеджер интервьювера, и менеджер менеджера. А сколько прелести осталось скрытым от глаз общественности… Моё мнение, как было почти десять лет назад, так осталось таковым — идти туда собеседоваться, нужно быть либо отбитым, либо очень сильно себя не уважать.
arrakisfremen
С одной стороны, я за сетевой нейтралитет, но с другой стороны, как-то приятно почему-то на душе, когда подобные фсбшные помойки в стране блокируют.
daniilk
Еще до изобретения литкода, я в яндекс принципиально не ходил на собеседования из-за тупых вопросов по С++, складывалось такое впечатление, что это было вопросник на позицию юриста по стандарту С++. С алгоритмами — видимо не зря же школу алогритмов создали. Отбивают.
Tarvitz
Похоже на какое-то завуалированное испытание стрессоустойчивости + лояльности. Я бы точно не прошёл :)
Dan_Te
Че-то выглядит так, что до более сложных задач ни разу не добрались.
Здесь, безусловно, есть вина собеседующих. Но вряд ли исключительно лишь их вина.
tuxi
Выничегонепонимаете! Они искали еще одного человека на должность интервьюера!
IgorPie
Половину условий задач не понял, пока не посмотрел на исходники. Мде.
Alxdhere
А вы видели, какие математические задачки для учеников средней школы?
Возьмем учебник по математике советского периода. Давайте даже откатимся подальше назад, к 1930-м или к 1950-м годам. Открываем учебники и видим задачки вида: сколько нужно гвоздей, чтобы построить дом, или, сколько нужно комбайнов, чтобы убрать урожай и т.д. В общем, задачки вполне себе предметные и любой ребенок научившись их решать уже сможет применить знания в работе.
Открываем современные учебники по математике и видим задачки вида: посчитайте количество нулей в сумме натуральных чисел от 1 до 10000, или, посчитайте, сколько круглых числе на диапазоне от 1 до 1000 и т.п.
Я не сомневаюсь, что современные задачи развивают мышление ребёнка, особенно абстрактное, вот только где он применит такие знания? На собеседованиях в Яндексе разве что?!
xpomosoma
Автор, не нужен вам этот Яндекс. Полу-государственная контора с посредственными продуктами, от которой исходит характерный запах. Вы достойны лучшего и удачи вам на вашем пути короля алгоритмов
fzn7
Вы абсолютно правы. Я бы даже сказал что это с трудом нарабатываемый навык чуйки засады, когда тебе срут в уши этими речами про "особый секретный способ собеседований" позволяет добиться гораздо большего чем любое умение виртуозно вращать красно-черное деревья
Sofrony
С учетом комментариев, я бы назвал этот тред «Разработчики против алгоритмов: театр абсурда».
Я, как бывший Embedded-разработчик подтверждаю — алгоритмы нужны далеко не всем.
Но ругать Яндекс за то, что им — нужны, это правда очень странно.
ТС интересно описал свой путь, респект ему, но, его решения далеки от идеала, ему есть над чем поработать.
Как верно и то, что Яндексу очень сложно набирать сформировавшихся разработчиков, большинство из них знают фреймворки, но не то, как они работают, поэтому основной канал — стажеры.
kesn Автор
Я как бы и не писал, что умею в алгоритмы. Субъективно оцениваю себя как алгоритмэна на 3 из 5, вон все решения привёл как есть, с ошибками, чтобы не думали, будто я гений какой. Но мне кажется, 1-2 интервью достаточно, чтобы это понять, да и вообще я немного другие скиллы планировал демонстрировать.
Это как устраиваться шеф-поваром: если попросят нарезать хлеб пару раз, я в принципе не против (хотя хлеб всегда уже нарезанный приезжает), но когда меня просят это сделать раз 10, я открываю хабр.
wataru
Много интервью делаются для объективности. У нас в гугле проходят 3-4 алгоритмических интервью, отчеты интервьюверы посылают комитету, который все взвешивает и принимает, по задумке, наиболее объективное решение. Комитет не видел кандидата и не знает ни имени, ни пола, ни возраста. Если какой-то отчет содержит намеки на пристрастность интервьювера, то он выбрасывается из рассмотрения.
Вот и получается, что проводят так много интервью.
kozzztik
Проходил через эту историю, как раз как питонист, и могу сказать что им таки нужно не лучшее решение, а именно эталонное.
Задача — почитать количество единиц в битовом представлении числа. Ну, какбы, пишу я, bin и count. Никакой стандартной библиотеки, никаких импортов, в питоне это считай О(1). Но интервьвера это понятное дело не устроило. Я уточнил, что я конечно могу написать обычный вариант с битовым смещением, но он будет заведомо хуже ибо будет линейным, интервьювер сказал — пишите, именно он мне и нужен. Написал.
На других задачах я так не блистал, потому на тимлида меня не взяли. Но сказали готовы рассмтореть на сеньора. Я ради интереса согласился, и что вы думаете? Снова пачка таких же задач. Не взяли. Предложили мидла или другую команду. Что было бы дальше я проверять, конечно, не стал :)
khorenyan
Спасибо за статью! Сам недавно столкнулся с интервью в Яндекс будучи скептично настроенным. Ваш пост отлично выражает моё недоумение. Только я не прошёл даже первое интервью, на второе уже не позвали.
У меня немного бомбило с задач, с того, что нельзя использовать встроенные классы и методы, вот первая задача с пересечением множеств, мой код с интервью без изменений (и сразу же «определите сложность алгоритма»):
Дальше наши интервью уже отличаются. Мне было задано построить бинарное дерево поиска. Но перед этим назвать сложность поиска, если дерево уже отсортировано. Я выдал что-то типа «ну в лучшем случае это O(1) потому что элемент попадётся первым, в худшем мы пройдёмся по всем элементам, поэтому это O(n), а в среднем там какой-то логарифм, сам не помню, как правильно считается». На что последовал ответ «ну вообще-то нет». Я немного опешил и начал визуализировать (тоже код с интервью):
На что уже не получил какого-то фидбека, мне сказали строить дерево. Пока я пытался без интернета построить бинарное дерево (в начале интервью было сказано, что гуглить не надо, выполнять код нигде не надо, пишем сразу в этом редакторе), вышло время интервью. Интервьюер быстро попрощался и закончил собеседование.
Так я остался с послевкусием недосказанности, у меня были вопросы, которые я просто задал в пустоту, примерно продублирую их тут:
O(log n)
P.S. В тексте статьи возникал вопрос, а на того ли направлены задачи, ведь и методичка про C++ говорит (мне такую тоже высылали) и гоняют только по алгоритмам. Если судить по этому посту, всё так и задумано, и это требуется именно от бекенда (ну, либо в Лавке и Маркете совсем разный отбор).
Woodroof
А какой смысл был бы в специальной структуре для поиска, если бы поиск в ней занимал столько же времени, что и поиск в массиве. Ну и построить дерево поиска, даже сбалансированное, довольно просто без всякого интернета. Вот оставлять его сбалансированным при вставке/удалении — это да, уже надо знать.
khorenyan
Процитирую автора:
И ещё раз себя:
Я не успел построить, так как у нас оставалось 5-10 минут. Я начал описывать класс Node, но не успел сделать методы добавления (вставка не нужна была, только построить дерево на основе отсортированного массива).
Я задаюсь вопросом, какая сложность поиска по отсортированному бинарному дереву, если не
O(log(n))
— тот ответ, который я в итоге дал интервьюеру, и который он не принял.Woodroof
Вы выше в комментарии написали, что интервьюеру сказали, что O(n) в худшем случае, т.к. придётся пройтись по всем элементам, а для сбалансированного дерева это неправильно. Про O(log n) вы написали, что посмотрели в Википедии, и это уже правильно.
TheKnight
В худшем случае при поиске в бинарном дереве поиска надо проверить всего O(log n) элементов. Логарифм двоичный.
Собственно, в этом и смысл двоичного дерева поиска — худший случай поиска O(log n). А основная проблема — поддержание инварианта при вставках и удалениях.
khorenyan
Хорошо, учту, если вдруг снова пойду на интервью..
masai
Если логарифм внутри O(...), то неважно, двоичный или нет.
Не каждое двоичное дерево поиска сбалансировано. А вот если мы говорим про самобалансирующиеся двоичные деревья поиска (например, красно-чёрные), то да, там быстрее уже.
DesertEagle
vanya6194
Самое забавное что сам месяц назад проходил в Яндекс собеседование на позицию middle c++. Ни одного вопроса по c++, все алгоритмы и задачи с которыми я справился. На самом последнем собеседовании джавист из Яндекса вообще учил меня shared_ptr писать) в общем я прошел все кейсы, а после общения с тим лидом получил через пару минут отказ. Оказалось что со мной общается внешний рекрутер, которая по цепочке из n людей общается с Яндекс рекрутером и перепутала результаты. В итоге Яндекс звонил мне и извинялся, однако потом сказали что кейсы я все равно провалил из за пары мелких багов в задачах, а мой вопрос "как я дошел до беседы с лидом" так и остался без ответа)
TimurBaldin
Это какие-то алгодрочеры ))
У меня знакомый работал в яндексе на позиции js разработчика… на собеседование он решал кучу алгоритмических задач… а на работе… рисовал кнопочки…
Спрашивается… яндекс, ну нафига ?)
В моём случае… эта длинная цепочка HR… калапснула… и в результате почти месяц не могли назначить собеседование… Когда наконец-то назначили… собеседующмй меня человек опоздал на 20 минут !
zheka126
Автор — красава. Между прочим суть идеи, которую вы изложили, можно спроецировать не только на работу. Увы, в технических университетах сейчас ровно такая же ситуация.
middle
Потому что знать http, rest, докер, джанго и далее по списку — так себе достижение.
picul
kozzztik
Первая ссылка в гугле утверждает, что bin — это конвертация числа в строку с его двоичным представлением. Итого Ваше решение переводит число в строку (под которую надо еще память выделить), и в ней считает количество символов '0'. Надеюсь, не нужно объяснять почему это решение не является ни лучшим, ни эталонным, ни вообще адекватным.С другой стороны, давать такой вопрос на собеседовании тоже странно, так как это не обычная задачка, к которой можно придумать хорошее решение за пару минут, тут его нужно знать (обычно подразумевается то которое (n & (n-1)), гуглится по «count bits in a number»). Хотя если кандидат напишет перебор бит, то можно проверить понимание битовой арифметики.
P. S. должно было быть ответом на коммент, промахнулся.
AterCattus
В конце 2019 тоже общался с Лавкой. Суммарно 5 часов общения за ~пару недель. 3-4 задачи из этого поста были и у меня Но ещё были встречи про архитектуру и Одна «Сложная» Задача С Тестами, но я бы ту встречу отнес скорее к категории поговорить за жизнь.
AlexTheLost
Это все что бы ты ценил что тебе дали работу в яндэксе и потом не ныл что тебе мало платят и много переработок, а думал что попал в святое место где решаешь уникальные задачи и вообще теперь ты особенный и это самое главное. :)
p.s.
"после того как компания решила нанять сеньор питон разраба за 200к" — это что сейчас такие рейты в РФ, расскажите кто в курсе?
kesn Автор
Я спрашиваю у рекрутера: какая вилка? Мне говорят: вы сами говорите, на что рассчитываете, а в Яндексе это учтут, ну что-то вроде того. Я сказал 200, чтобы на жесть не попасть и побыстрее проскочить. Ну да, ну да, пошёл я…
Какие там реально зп я не в курсе.
ooprizrakoo
Можно для понимания зарплатных вилок поглядеть на Глассдор. Там вполне себе понятные зарплатные вилки.
cosmolev
Ну ок, хотят проверить знание каких-то базовых вещей.
andrey-kuznetsov
Был на подобном интервью, только на первом. Пообщались замечательно, но почему-то завернули меня. Решил обходить Яндекс стороной: не радует подход с проверкой наличия не нужных в реальной жизни навыков.
daria19
отправляла отклик на почти джуновскую вакансию ИТ рекрутера в Я, приходит отклик — мы очень рады вашему резюме, бла-бла, вы должны сделать тестовое, по ссылке тестовое на 4,5 часа. При этом не понятно: з/п, вообще условия, команда, задачи очень общо, в общем ничего еще не понятно, но надо сделать тестовое и кто-то соглашается!
RGr
Процесс ради процесса, наверное, тоже интересно…
Но почему после статьи захотелось уменьшить свой портфель с акциями Yndx
oinovikov
Я в прошлом месяце на js в маркет до финала дошел, но в конце туннеля вдруг выяснилось, что я реактом не владею в бою. Все, две недели "коту под хвост". Но кодинга/алгоритмов было всего 2 "собеседования", плюс одно на софт-скиллы (как я понял), плюс одно с командами (было похоже на ярмарку вакансий, где я больше слушал).
KirillGerasimov
Разве ярмарка вакансий это не конец туннеля? А что тогда?
oinovikov
Именно… но вот после написала рекрутер, что "бизнес развивается настолько быстро, что меня без практического реакта никто не готов взять". Я, в принципе, не против, что не подошёл или не понравился, но за две недели мог бы уже лобать что-то, при том, что одна команда вообще внутреннюю срм пишет, в которой "ближайшая важная задача" сделать удобный календарик для выбора дат)
KirillGerasimov
Интересная ситуация. Тоже была подобная, поэтому и спросил. В связи с началом карантина что-то затянулся этап оффера в яндексе, а потом как-то испарился.
oinovikov
Я очень хотел попасть, чтобы бустануть карьеру. Это при том, что я не js-ник, но много читаю, практического опыта не так много. Я был немного удивлён, что вообще дошёл до финала, но конец все же расстроил.
"Испарился" типа совсем не ответили или что сказали?
Я, кстати, аж прошлым летом (или даже весной в кинопоиск сначала) прошёл самый первый этап, но тогда отказался продолжать, потому что удаленки ещё не было.
KirillGerasimov
Нет, мне переодически писали, что прошел я очень хорошо, но из-за вируса непонятная ситуация с наймом. Через 6 месяцев ситуация наконец-то прояснилась (не знаю вакансию они закрыли или проект).
Valle
Что-то Яндекс отстаёт. Сейчас модно как Амазон — 70 процентов про leadership вопросов задавать. Бомбить от этого можно сколько угодно, но если хочешь работать то приходится учить как проходить собесы
v_eroshenko
Мне казалось, что зашквар с тестами, задачами, кодингом уже динозавры юзают. Ан, нет. Был повергнут в шок про 5 часов собеседований. Конечно, понимаю, что лучше потратить 5 часов рекрутёра, чем 3 месяца испытательного срока и искать заново. Но камон-хамон! 5 часов Карл! Час, ну край два! Испыталка покажет! Гоу ко мне, ребята! Пишите в личку. Ищу.
Woodroof
Согласен с тем, что много собеседований на алгоритмы — это неправильно.
Не согласен с тем, что сложность в реальной жизни не пригождается. Мне не раз приходилось переделывать места, где кто-то написал квадратичный алгоритм, а потом в специфических условиях всё тормозило и пользователи жаловались. Если бы человек сразу думал, какие максимальные реальные входные данные бывают и какая сложность у того, что он написал, пользователь бы не страдал. Встречается и такое, что n log(n) — медленно, и надо n, но редко.
И отсутствие знания сложности сортировки для меня означает, что подпускать человека к написанию кода, который будет работать на больших данных, рановато.
Я удивлён тому, что для приведённых решений вас не спросили, можно ли быстрее, т.к. есть куда улучшать.
kesn Автор
Ну наверно таки да, знать полезно, особенно если в планах большими данными ворочать (хотя для этого я использовал бы какой-нибудь numpy или что-нибудь ещё, написанное на сях, раз уж на то пошло, а меня тут просят оптимизировать на голом питоне). Но в реале я никогда не ловил себя за подсчитываением O(n) после написания функции :) Там скорее чуйка какая-то: я примерно представляю, какие вызовы функций дорогие, я напрягаюсь, если вижу вложенные циклы, ну и прикидываю, как сильно будет грустить БД после моих запросов.
wataru
Много интервью — это не потому что FAANG так важны алгоритмы, а для объективности.
Несколько разных интервьюверов пишут отчеты, потом (по крайней мере в гугле точно так) целый отдельный комитет по найму рассматривает отчеты и решает. Если кандидат затупил на одном интервью, волновался, а все остальные прошел на отлично — с большой вероятностью его наймут. Если один интервьювер явно офигел от внешнего вида кандидата и предвзято писал отчет, это еще не приговор.
dimskiy
В яндексе явно читали кривой перевод про собесы какогонить фейсбука. Половину не поняли, половину выкинули от лени, а образовавшиеся пустоты заполнили чем умеет их персонал — абстрактными задачами из местного репозитория. И правда, абсурд. В общем, и правда не зря игнорирую рекрутеров якитории ))
3263927
вы забыли галочку снять "установить дополнительные вопросы"
Andrey_Solomatin
Полный провал разведки. Каждый раз сюрприз от несовпадение ожидания с реальностью. Зачем же так? Это же не рога и копыта, о том что ожидать можно узнать заранее из многих источников.
Про то зачем нужны алгоритмические задачки и почему у некоторых компания это работает Гэйл Лакманн Макдауэлл написала целую главу в книге. Посмотрите на досуге.
В это плане Яндекс играет в открытую, по своим правилам. Тут либо соглашаться, либо жаловаться.
ComodoHacker
Позволю себе добавить и свой вывод из вашей истории.
Fandorin
Слабую базу можно определить за полчаса.
kesn Автор
В нашей компании неподходящий кандидат не сможет даже заявку подать. А если сможет, то отсеется на 5-минутном автоматическом тесте. Невероятные чудеса!
Matisumi
Если честно я вообще не понимаю кто и зачем сегодня может добровольно захотеть пойти работать в Яндекс. Там что, зарплаты сильно выше рынка? Нет, чаще даже ниже. Интересные задачи? Да тоже не особо. Продукты, реально меняющие мир? Да блин, тоже нет. Так зачем?
TheKnight
А что вы считаете интересными задачами?
geek10010
Интересно, приняли ли бы такое решение Задачи №1?
kesn Автор
Вот вам тест:
a = [1, 1]
b = [1]
assert result == [1]
wataru
Нет, потребовали бы более быстрое решение.
PsyHaSTe
Ну проверьте:
a: [1, 2, 3, 2, 0] и b [5, 1, 2, 7, 3, 2, 3, 3, 3, 3]
Надо вернуть [1, 2, 2, 3] (порядок неважен)
wraki
20 лет код пишу и последние 10 из них читаю как очередной прогер повелся на несуществующие плюшки Яндекс.
У меня лично Яндекс в черном списке компаний в которые я не пойду работать сколько бы не предложили. Когда знакомые там работавшие говорят обходи стороной.
Хуже на данный момент только Озон особенно для Golang разработчиков.
Вообще удивляюсь что еще кто идет в Яндекс, когда столько статей написано и столько отзывов оставлено.
Зарплата ниже рынка, токсичная обстановка, специфический инструментарий который на хрен вам в карьере не пригодится… можно еще долго продолжать.
Я самое бесячее читать смотрите они алгоритмы спрашивают да сколько можно уже =_=
Их подавляющее большинство крупных компаний спрашивает.
Проблема в том что после того как вам вы**бут вам мозг задачками вы еще и ничего не получите.
Дерьмовую ЗП и прекрасное чувство бесполезной шестеренки.
Удачи с Яндекс ))
TheKnight
Alexsey
Для меня было, в общем то, достаточно, что тим лиды нескольких систем на которых строится вся логистика ozon'а с глазами по 5 рублей на меня смотрели когда я им сказал что на один tcp/udp порт сервера могут обращаться сразу несколько клиентов. У ребят там микросервисы, grpc и прочий фарш, а они не знают таких базовых вещей. Они реально при мне полезли гуглить это.
SpiderEkb
Мда… Про TCP не в курсе подробностей, насколько помню, там обращение к порту идет исключительно на стадии установления соединения, а дальше сокет с установленным соединением уже «отъезжает» в сторону и работает самостоятельно (там уже порт не важен). Т.е. порт — это место где сидит listen сокет.
А UDP это просто «дыра» в которую может орать любой желающий без предварительного установления соединения.
revealyan
Я недавно тоже пытался на позицию .NET Backend девелопера в Яндекс.
На задачке про строки немного обосрался(граничные условия, долго их ловил)
Что удивительно — мне дали даже задачку на join табличек, но пока я сидел и размышлял секунд 30 над тем какой join впилить(сначала написал запрос с обычным join, а потом смотрел, что они там хотят вообще), интервьюер сказал что я плохо знаком со скулем:(
Thahr
Вопрос к Яндексоидам: на вскидку, как много людей устраивается в Яндекс как трамплин на запад?
По LinkedIn тысячи бывших сотрудников Яндекса переехало заграницу. С учетом что большинство людей не может переехать — не могут бросить родителей/друзья тут/патриоты в хорошем смысле слова/не знают английский (самый популярный вариант) — для относительно небольшой компании цифры огромные.
Возможно, компания что-то делает для удержания, есть ли какая-то статегия?
Как потенциальному кандидату такая огромная текучка сотрудников (в том числе ключевых — серьезный red flag.
BugM
В Яндексе примерно 10.000 разработчиков. Ладно, пусть я завысил и будет всего 5.000 разработчиков.
Возьмем медианный срок работы 5 лет. Скорее всего даже меньше на самом деле, но ладно.
Это нам даст 1.000 уволившихся каждый год.
Определенный процент будет уезжать всегда. Для не самых глупых разработчиков процент уезжающих будет выше чем в среднем по рынку. От тысячи человек в год абсолютные цифры тоже будут заметными.
Рекрутеры FAAGN не зря свой хлеб едят. И людей активно рекрутят.
Thahr
У Mail.ru Group разработчиков поменьше, но зарубеж укатило в разы меньше % (по linkedin). Про "не самых глупых" — пройти собес на западе это 90% про подготовку: английский, софт-скилы, дизайн, алгоритмы. Если рекрутер фаанга напишет условному senior staff software engineer в Я, то 99% последний откажется по причинам выше (не может бросить родителей/друзья тут/патриот в хорошем смысле слова/не знает английский/...). А скорей всего и не напишет, потому что наш разработчик еще аккаунт не завел на LinkedIn. А зачем? Дачу в подмосковье построил, ипотеку выплатил, дети в школе устроены.
Вопрос именно что Яндекс многие специально используют как трамплин. Кроме опытных ребят, на LinkedIn сотни людей с 1-2 года работы в Яндексе и потом, внезапно, Facebook/Google/etc
PsyHaSTe
Как нас учили на курсе АОД в универе — корреляция не всегда означает казуацию. Например, может быть объясненеи что разрабочтики мейлру на западе просто неинтересны, а вот яндексоидов хантят с удовольствием. Или что мейлрушники все в москве живут (оттуда уезжать меньше причин), а яндекс больше рассеян по стране, и из условной воркуты они с куда большим удовольствием уезжают… Или ещё десятки возможных объяснений, это первые что в голову пришли
Thahr
Согласен, но я немного про другое. Вы видимо не в курсе как это работает сейчас.
"На западе просто неинтересны" — заведите аккаунт в linkedin, заполните профиль и если у вас есть несколько лет опыта и ключевые слова — вам напишут из всех крупных компаний. При этом вы можете работать в неизвестном стратапе из 10 человек. Яндекс, как и Меил, отстуствуют на западе, о них никто не знает (почти).
Устроиться в крупную компанию — это не про опыт (опыт нужен только чтобы попасть на собеседование), это про подготовку к интервью. Яндекс выглядит как идеальное место для подготовки. Прошаренные рекрутеры по идее знают про это и работа в Я теоретически может упростить попадание на собеседование.
Areso
Завёл, заполнил, опыт (как «стаж») накапал сам собою, написали из:
Ну, то есть не то, чтобы дофига…
PsyHaSTe
Ну я вот заполнил на линкедине резюме, опыт 8 лет, только автоматический спам на 99% из российских компаний. И нвидия которые кажде 3 дня предлагает мне пойти к ним го или питон разработчиком, при том что у меня раст/C# описаны.
Ну такое.
Для этого необязательно устраиваться в яндекс — можно порешать задачки на литкоде и пойти внезапно не в яндекс, а в какой-нибудь амазон
zagayevskiy
Не знаю за весь Яндекс, но в моей команде много людей, работающих годами. Есть те, кто работают 7-10 лет. Удержание — RSU, ипотека под 3% на 10 лет, беспроцентный займ на жилье на 3 года. Интересные задачи(это не шутка, я регулярно задумываюсь, почему я тут так долго, и интересно ли мне. Да, интересно, да, всё ещё развиваюсь).
balberbro
Ипотека под 3% — это уже мимо, ибо реально получить такое в банке уже.
balberbro
Вот кто минусует — откройте самолект, фск — там ипотека под 2,99 от альфы. У пика есть ипотека под 3,99%
A114n
Оказывается стоимость недвижимости при одобрении субсидированной ипотеки увеличивается на 10%
ICELedyanoj
Ох Святой Эйнштейн… Я-то считал себя извергом, давая кандидатам относительно хитрый алгоритм на подсчёт суммарного размера файлов внутри заданной папки с периодическим возвратом прогресса в коллбек (дабы тормознуть умников, пишущих однострочную лямбду типа Directory.GetFiles(path, recursive).Summ(item=>new FileInfo(item).Lenght).
На задание даю 10-15 минут (т.к. это — только часть интервью), и из многих десятков кандидатов только пара человек уложились в таймаут и смогли выдать условно рабочее решение. Несправившиеся условно делятся на две группы — первые тонут в трясине хаотичных правок уже написанного кода, вторые начинают писать монстра на десяток (я не шучу) дополнительных вложенных методов и просто не успевают написать ничего вразумительного.
Через 10 минут напоминаю о том, что на задание выделено ограниченное время, иначе не успеем закончить собеседование, ещё через 5 минут останавливаю и прошу устно рассказать чего здесь ещё не хватает для того, чтобы решение заработало. Потом код-ревью с обсуждением плюсов/минусов выбранного подхода.
Этого времени уже достаточно для того, чтобы понять способность человека писать код.
А тут такие простыни кода, что меня прямо в дрожь бросает. Прекрасный способ дать кандидату почувствовать себя ничтожеством.
PsyHaSTe
А как это тормознет умников? В лямбде пишется просто после прочтения FileInfo
Progress.Report(p => p+1)
и всеУже хочу у вас работать
ICELedyanoj
Ну если умника не тормознёт настолько тонкий намёк, то баллов за тестовое задание он не получит.
Перед заданием я предупреждаю, что нежелателен уход метода в нирвану на неопределённое время без репорта. А рекурсивное получение всего списка файлов одной командой — верный способ надолго заблокировать поток выполнения. Конечно, после выполнения Directory.GetFiles() вы начнёте репортить о прогрессе, но на реальных системах с миллионами файлов пока вы дойдёте от получения суммарного списка файлов до построчного выяснения их размеров — могут пройти минуты, если не больше.
Кроме того, если я чему и научился на текущем проекте (мы бэкапами занимаемся), так это правилу «ищешь перерасход памяти — ищи подвисший список путей». 9 из 10 OutOfMemoryException — это неудачно сохранённая в памяти коллекция абсолютных путей.
А вы её хотите одним куском получить.
В общем, как я сказал — с виду это простая задачка, но в неё только копни…
А это мы ещё не трогали потенциально возможное зацикливание папок через хардлинки (реальный кейс из продакшена) и другие прелести.
Если говорить о реальных собеседованиях — лишь один кандидат после моего вступления с пожеланиями тут же их проигнорировал и начал писать в одну строку.
Обычно люди намёк понимают.
PsyHaSTe
Ну окей, если файлов много можно заменить на
Directory.EnumerateFiles
— оно работает лениво, на 100к файлах отработало без каких-либо проблем, первый файл был зарепорчен через 8мс после выполнения кода.Ну это уже будет сложнее, да, но там в принципе сложности с тем "что есть файл". Ну и тут наверное стандартный обходник не подойдет. Но на изначальных условиях да даже с миллионами файлов — проблем нет.
Какая-то ваша специфика. У меня например оомов не так много, но почти все из них были вызваны "накапливали логи быстрее чем успевали их записывать". В другой раз в экспрешн случайно попала ссылка на репозиторий хранящий DataContext — в итоге кэши ормки пухли и никогда не очищались. Ну и всякие такие приколы.
Если много файлов то просто не надо получать их все — рецепт в общем-то простой. Если же там хардлинки и все остальное — то тут просто видимо пишется своя библиотечная функция для того же самого, которая работает так как нам нужно, ну и код остается тем же, просто вместо
Directory
вызываемMySuperDuperHelper
.ICELedyanoj
По моему опыту очень мало кандидатов вообще в принципе помнят методы доступа к файловой системе. Даже те самые банальные Directory.GetFiles в последнее время начал сразу выносить в шпаргалку, дабы не тратить время. Куда уж тут ленивым методам.
Я в конце-концов не требую знания библиотечных функций, а просто проверяю способность справляться с хитрыми ситуациями.
Что касается рекурсии — последние лет 20 избегаю рекурсивного алгоритма при обходе дерева файловой системы. Предпочитаю нерекурсивный вариант со стеком.
Так и максимальную глубину вложенности можно ограничить, и сигнатура метода становится гораздо проще — не требуется постоянно передавать накапливаемые параметры на каждом уровне вложенности. И легко превратить такой метод в IEnumerable, навернув внутрь фильтрацию, пакетирование и прочее.
Но такого варианта, увы, пока ни один кандидат не предложил.
Что касается ООМ — несколько кейсов за последние 7 лет было. Почти все связаны именно со списками путей, но тут вы правы — это именно наша специфика.
Sobolev5
Все написанное подтверждаю.
Человеческих собеседований тут нет.
У меня были задачи на палиндром, что то там про матрицы и т.п.
Я дошел в Яндексе до третьего этапа и решил что это скучный и унылый квест, который никакого отношения к реальности не имеет.
Все же хороший разработчик, это не тот кто умеет складывать в уме матрицы,
а обладает более глубокими прикладными знаниями (к примеру как работает сеть, как устроен unix и т.п.) и имеет большой практический опыт в «нестандартных» задачах в том числе и по масштабированию.
greenkey
Огромная лента комментариев ;-) но добавлю свои пять копеек.
Фреймворки приходят и уходят (даже языки), а алгоритмы- это навсегда. Почти. В общем, нацеленность на алгоритмы вполне понятна, хотя конечно, наверное глупо и невежливо со стороны Яндекса вот так все растягивать. Очевидно, они делают это поскольку у них нет недостатка в желающих там поработать.
Еще добавлю, что в промышленной разработке, в подавляющем случае, кодинг математически и алгоритмически достаточно прост. Это вызывает эффект «забывания», просто хорошие навыки и приемы уходят из фокуса. Это очень плохо, на самом деле, для разработчика, и хорошо если он где-то тренируется/занимается/учится в таком случае, чтобы не терять навыков использования сложных приемов.
Вероятно Яндекс, тем самым, проверяет именно этот параметр, потому что он универсален и нарабатывается длительнее чем освоение языка/фреймворка.
anzay911
Немного не совпадает «2 задачи на код» в Скайпе из методички и вышеописанное.
W_Lander
Возможно яндексу и им подобным нужны оценки в первую очередь способностей, а не навыков. Если навыки можно наработать упорным или упоротым или не очень опытом, то способности больше «природная» штука ). Например им нужны кандидаты с хорошей концентрацией внимания, памятью, внимательностью, скоростью принятия решений, производительностью и т.д. Все таки, коммерческая гонка в нише сервисов впаривания рекламы, товаров и услуг высока и изменчива, вот пилить все это в вечном аврале нужны соответствующие кандидаты ). Проще говоря отсев инертных и наоборот косячных торопыг ). Я вот по себе скажу, что у меня нет способностей, нужных таким конторам, поэтому я и остался в эмбеденщине, где обычно можно покурить гайды неспешно прежде чем решения принимать и авралы не столь часты. Дай мне подобную задачу, я может что-то сходу и слеплю, но потом инертно буду копать еще неделю как это все оптимизировать, выкинуть тяжеловесные либы, какое железо лучше взять ). Но попробовать конечно было бы любопытно в такой среде поработать, почувствовать мейнстрим ), хотя, возможно, я уже «старый» ).
IonDen
Более того. Если зайти на Leetcode и покопаться в обсуждениях к вопросам — там много накидано готовых решений вроде «вот мое решение быстрее чем 99,9% и вообще в одну строку».
И ты пробегаешься по этим решениям и думаешь, что ты бы точно не хотел работать с людьми которые пишут такой код.
Какой-бы быстрый/оптимизированный он не был — его невозможно читать. Я уверен покажи этот код автору через день он сам уже не разберется.
prohodil_mimo
Отличная статья!))
Когда-то давным-давно, в далёкой-далёкой галактике я и сам проходил такие же собеседования. Один раз даже по каким-то недокументированным возможностям языка меня спрашивали! Но сейчас если первая же задача оторвана от жизни, плюю им в зум и отключаюсь. Жизнь коротка, работы много, пусть сами свои постапокалиптические безбиблиотечные алгоритмы решают.
И ещё просьба к автору — сделайте, пожалуйста, апдейты в статье по итогам комментов от яндекса (а я уверен, что они были!). Потому что комментов уже стотысичмилионав, невозможно объять, а интересно.
xaoc80
Плевать в зум не обязательно. Но если все, кто считает себя профи и умеет ценить свое (и чужое!) время перестанут хотя бы повторно ходить в распиаренные компании и отвечать рекрутерам, то может сильно много чего поменяться в отношении крупных ИТ компаний к кандидатам. Ведь их цель — прогнать как можно больше людей через фильтр, чтобы поддерживать высокий средний уровень. Как итог — потерянное время большого числа людей. начиная от рекрутера и заканчивая кандидатом. При этом приходится конкурировать с полсотней таких же кандидатов, но с поправкой на то, что они могли, к примеру пару недель тренироваться в решении таких задач. В итоге ты стоишь в одной ряду со всеми, но потенциально мог бы быть более полезен за счет своего опыта решения практических, задач. К слову, часто в стартапе или небольшой компании тебя с радостью ждут и обеспечат большим числом интересных задач, и подход к набору более адеватен, так как часто там знают точно кто им нужен.
kesn Автор
Ящитаю, что статья закончилась именно там, где должна была закончиться. Она ведь не про то, как какой-то чувак прошёл/не прошёл в Яндекс и что с ним стало потом, а про доширак (и прочее). Но если вам так интересно, то вот апдейт:
1) Меня завернули после 4 собеседования. Никаких особых комментов, почему, не было — ну типа решал алгоритмы не очень. Даже если фидбек был, он же проходит через тор, и я не знаю, сколько инфы там теряется. Я не верю в теорию заговора и считаю, что действительно решал алгоритмы так себе (да вы и сами всё видели) — особенно после того, как посмотрел ради любопытства видео Яндекса про собеседования и какие критерии там смотрят. Я со своей логикой там вообще не в кассу.
2) После выхода статьи со мной связался Яндекс
и предложил стать СЕОи сообщил вот что:Да ладно, вы правда поверили, что Яндексу не плевать? Никто мне не писал, рекрутер вообще не в теме.
Hrodvitnir
Ой, тоже собеседовался в яндекс
Когда длинна собеседований в сумме перевалила мой рабочий день и мне сказали, что готовы меня рассмотреть в другую комманду, но после еще двух интервью, я отказался
DeadMazai
А чё так у всех припекает от такого подхода и задачек? Или горит только потому что это Яндекс? :)
В крупных ИТ компаниях (особенно на западном побережье США) именно так и проходит интервью — много задачек (стоит отметить, что задачи сильно интереснее и сложнее) + дизайн и бехев, 4-5 часов подряд в общей сложности, бывает и дольше. Даже тут я статьи такие встречал не раз про подобный опыт и не видел там столько гнева :) Хочешь работать в крупной компании и получать хорошо — будь добр пройди через эти муки.
SpiderEkb
Все это годится для набора «пехоты». Т.е. уровень тестирования должен определяться уровнем кандитата. В Я этого нет. Там тупо всех гонят через фильтр «пехоты».
Естественно, что даже крепкий мидл туда не пойдет. Не говоря уж про сеньоров.
zagayevskiy
То есть вы считаете, что самую большую айти-компанию России пилят 10000 джунов?.. Окааай:)
SpiderEkb
Я понятия не имею кто и что там пилит. Но отбор идет именно для джунов. Возможно, мидлов и сеньоров они выращивают сами, не берут со стороны (что имеет свою логику).
Ну так и приглашайте джунов тогда. Не надо пытаться завлечь человека с позиции сеньора и пытаться прогнать его через «джуновый» алгоритм отбора.
PsyHaSTe
Возможно сениоры сами виноваты что идут зачем-то на собес, хотя на каждом заборе написано "здесь вам не рады, мы нанимаем джунов-мидлов" :shrug:
zagayevskiy
Ну раз понятия не имеете, может тогда не стоит делать громкие заявления типа «Естественно, что даже крепкий мидл туда не пойдет. Не говоря уж про сеньоров.»?
Потому что нет, не естественно. И идут и миддлы и сеньоры.
SpiderEkb
Ну не знаю… Знакомые мне сеньоры на такое не пойдут :-)
На нормальный собес — да. На это — нет.
Потому что на нормальном собесе стороны равноправны. А здесь тебе милость оказывают. Может быть, если прогнешься. А это значит что и работа вся будет построена по этому же принципу. Тебе будут рассказывать как тут круто зарабатывают, но при этом говорить что до этого круто тебе еще расти и расти. А пока изволь рвать попу за то что дают в надежде что когда-нибудь…
Thahr
В больших ИТ-компаниях нет столько задач: у Амазона всего 3-4 за весь день, у других больше, но не 10+ точно. Так же если есть хотя бы пара лет опыта всегда будет раунд на дизайн систем.
ddubrava
Яндекс не имеет ничего общего с FAANG
sumanai
Можно придумать FAANGЯ.
masai
Я встречал МЯСО: Mail.ru, Яндекс, Сбер, Озон.
pfsenses
Получать хорошо, насколько мне известно, это не про Яндекс. Они ниже рынка ЗП предлагают.
Aminelle
А как бывает с разработчиками, которые уже работали в Яндексе, потом ушли, а через пару лет захотели туда вернуться? Их заново по всем этапам прогоняют?
Sofrony
Как минимум скрининг отсутствует.
А вообще, код-секции обязательны даже, если сотрудник Яндекса ротируется из одного подразделения компании в другое.
То есть ротация внутри компании будет заблокирована, даже если нанимающая сторона тебя хочет, но ты вдруг «забыл» как решать задачки типа тех, что были у ТС.
botyaslonim
Вот она, сила монопольного положения на рынке! Вы можете быть сколь угодно монструозны, набирать бесконечно тупых HR, которые организуют процесс так, что на Хабре уже за положняк писать минимум одну развёрнутую статью про их найм.
Но — им пофиг, это ни на что не влияет, т.к. монопольное положение. Я думаю, завтра половина программистов вообще на работу не выйдет — Яндекс особо не заметит. «Куда ж ты денешься, чык-чырык»
ipo
Полагаю, что тестируют не знание питона, а наличие живого мозга. Это далеко не всегда одно и тоже. У вас мозг судя по всему есть :)
SpiderEkb
Ну если откинуть то, что тестирование превращается в 7 кругов ада, то, судя по комментариям здесь (да и вообще по обсуждениям тут и в сети) они стараются отсеять тех, кто будет предлагать ставит что-нибудь типа Эластика для решения задачи, которую можно решить написав 500 строк кода (со всей обвязкой и комментариями) без использования каких-либо фреймворков вообще, только системные API и встроенные функции языка (и уйдет на это час-полтора времени от первого взгляда на «плохой» код до получения первого тестового сравнения старого и нового вариантов).
Ну то есть людей, которые при разработке всегда думают об эффективности того, что они разрабатывают, а не о том, чтобы скорее сляпать что-то как-то работающее и спихнуть на прод.
BugM
Эластик и любые другие похожие системы нужны для больших данных. Добавьте в любую задачку условие что данных пара терабайт и они не влазят в память. И сразу мапредьюсы с разнообразными базами полезут везде.
SpiderEkb
Я не сомневаюсь что оно реально нужно в определенных ситуациях. Но разработчик всегда должен оцениват сложность решения и его ресурсоемкость.
И там, где 500 строк кода удовлетворяют всех (и бизнес и сопровождение), никакой эластик нафиг не уперся.
Речь, собственно, об этом — прежде чем искать решение на стороне, стоит оценить его сложность своими силами. И соотнести с затратами все варианты.
А в современных условиях в значительной степени «разработка» сводится к поиску подходящего фреймворка где все уже кто-то сделал. Но это приводит к деградации разработчика и превращение его в «интегратора».
Sofrony
Тут много комментариев, но напишу еще один.
Ребят, если решить несложную задачку на 10 строчек кода для вас — ад, вам просто не надо в Яндекс. Не надо себя мучить.
Я ходил на собесы в эту компанию несколько раз, не потому что прямо очень хотел оффер, а просто было прикольно порешать задачки и понять, где я еще могу подрасти.
Какое же было мое удивление, когда в очередной раз мне его предложили.
stasych
wataru
O(n^2). Слишком медленно.
stasych
У автора там тоже два прохода по a и b. Просто хотел более выразительный однострочник, а то уже больно много было кода с той же сложностью.
wataru
И автор не прошел интервью
Более выразительный? Это больше похоже на попытку в code golf — где надо решить задачу наименьшим количеством символов. Как этот однострочник более выразителен, чем 2 вложенных цикла — я не понимаю.
Этот код менее читаем, да еще и работает медленнее даже тупого решения с 2 циклами. Потому что выделяет память под копии и не останавливается при нахождении вхождения.
Danirl
За алгоритмами будущее. Тот кто быстрее будет предоставлять информацию пользователю, тот будет выигрывать всегда
X-Oleg
Ещё раз отвечу по этой теме.)
Конечно алгоритмы нужно знать, хотя-бы базовые вещи, как минимум потому-что любой код — Это есть алгоритм.)
Другое дело на сколько что-то показывают институтские задачки, которые используются по факту мало где и без подготовки те специалисты, которые не работают с такими задачами регулярно, просто не справятся.
Такие задачи будут щелкать, студенты которые хорошо учились в вузе и помнят это всё, либо олимпиадники.
Ну можно конечно подготовится на таких задачках, но смысл какой в этом?
Только для того что-бы попасть в Яндекс?
Да, можно, но для этого нужна как минимум очень хорошая мотивация.)
Возможно я хреновый спец., вот за десять лет кодинга, не разу не приходилось считать нотификацию О.
Также напрочь забыл, как например обойти граф и т.д.
Ну хрен его знает, вроде работу выполняю по своей специальности, что-то даже и работает.
Если интересно, работа связанна в отрасле ответственного применения.
Ещё немного добавлю:
Почему-то я всегда теряюсь на интервью, и мне реально сложнее вдвойне что-то писать при интервьювере.
Поэтому идеальное для меня интервью, это тестовое задание перед беседой, можно даже какой-то боевой проект, ну и беседа по тестовому заданию, опыту работы и т.д., думаю этого вполне достаточно, что-бы я показал свой уровень.
Другое дело такое поведения на беседах, как у меня говорит о каких-то качествах, которые скорей-всего не подходят компаниям типо FAANG…
Это просто привел себя как соискателя как пример, в общем решил сейчас искать компании, которые дают тестовые задания + нормальное общение на интервью (Опыт работы, какие проекты и т.д.), остальные даже рассматривать не буду, сразу буду говорить это перед интервью, что-бы не тратить время...)
pdragon
Хм… а конструкции try catch разве хорошо использовать для построения алгоритмических задач? Я думал в рамках хорошего тона их можно использовать только для выявления ошибок действия над ними (например запись в журнал событий) и/или выкидывания исключений. Хотя может я и ошибаюсь и сейчас именно так принято.
kesn Автор
Ask forgiveness not permission
В рамках кода, что в статье, на больших входных данных эксепшнов ожидается гораздо меньше, чем было бы проверок на наличие предыдущих элеменов. Так что выгоднее с ними, но, вообще говоря, решение само по себе не очень :)
pdragon
Я к тому что на собеседованиях такие условности допускают? Ибо там же я как понял смотрят именно КАК задача будет решена в рамках понимания того как собеседуемый будет и в дальнейшем делать.
aarefiev
Крутая статья, увидел себя со стороны. У меня последняя, 5-я встреча, тоже состояла из решения алогритмических задач. Дело было до пандемии, этапы с 2 по 5 шли оффлайн. Но все время было ощущение, что собеседование != реальные задачи на работе и такой упор на алогритмы сделан, чтобы как-то можно было отсеять нескольких из большого количества соискателей.
Если честно, после этого думал натренировать алогритмы и ехать, но после прочтения статьи как у них происходит повышение (не помню ссылку) подумал, что мы с Яндексом можем хорошо сосуществовать раздельно.
Dabbuger
на сколько же сложное это программирование, я читаю ваши задачки как на марсианском. Даже и близко не представляя с чего нужно начать, что бы понять хотя бы условие задачи.