Комментарии 235
Что за задача-то была... На каком языке писали...
Да как вы посмели. Любой программист С++ должен в мелочах знать STL, Boost и QT.
А также, уметь писать код из головы(интервьюера/начальника). Причём, обязательно на С++23, иначе код не будет засчитан.
а что, вы хотели бы чтобы человек написавший список вот так как он написан в посте работал над чем-то важным и сложным?
Чем плох его список?
это не список вовсе, а нода списка какая-то.
Никаких операций над ним не определено, хотя нужно якобы аж сортировать, добавлять элементы и проч.
Какой то инт непойми почему там
над этим "списком" невозможно работать
то что человек не определяет нужных ему операций для выполнения задачи уже знак, что он не знает как же нужно писать код.
По такой логике и переменные в языке не нужны. Ассемблер тьюринг полный!
Кому нужна эта понятность кода, глупые понятные интерфейсы!
что-то мне подсказывает, что над листом нужно иметь хотя бы операции вставки в понятном виде, иначе абсолютно ничего непонятно в коде
Ну а программистов на С не знаю набирает ли яндекс, сделать хотя бы С с классами ради решения задачи можно было
Я правильно понимаю, что в данном комментарии вы возмущаетесь тем, насколько прост данный список (и при этом полностью соответствует определению однонаправленного списка), и вы хотели бы увидеть огромный класс с определением всего возможного блекджека и плюшек, просто потому что "так красивее"? И вы же не надеетесь, что такой godlike класс будет написан в ограниченное время?
А с ним не нужно "работать", его нужно просто отсортировать (ну присоединить один к другому, а потом отсортировать), продемонстрировав знание элементарных алгоритмов, сложности, декомпозиции и т.д. и, например, решить задачу за O(n*log(n)), а не за O(n^2), порассуждать. Полноценная абстракция односвязного списка с шаблонами, аллокаторами, операциями, ни как не поможет в решение задачи, если человек не знает как отсортировать список, возможность вызвать метод insert вместо "ручного" присваивания одного указателя, не приблизит его к решению. Ну т.е. в чем смысл писать метод insert для задачи сортировки списка, если ты не знаешь как сортировать список... Напротив, это только покажет, что человек просто не понимает смысла задачи и самое главное зачем он ее решает. Все нужные операции, обобщения, оптимизации, баги ) можно добавить следующими итерациями, отталкиваясь от исходного решения, алгоритма.
Я так давно не делал руками сортировку, тем более односвязных списков, что сходу и не напишу. qsort, std::sort. Не будет хватать: профайлер, измерения, изучение.
Я в общем, но пусть будет и forward_list::sort. Это уже часть - изучение, если не будет хватать.
И если бы я был интервьювером, то с моей точки зрения решение из двух строчек с std::forward_list::splice_after() и std::forward_list::sort() было бы самым правильным
Возможно, у того человека который проводил интервью у автора, это тоже было бы самым правильным. Проблема скорее всего в том, что автор не знаком со стандартной библиотекой в достаточной степени, чтобы ее применить в такой ситуации. Я думаю интервьюер был бы не против если бы автор предложил ему несколько решений с использованием стандартной библиотеки, просто чтобы выразить суть алгоритмов (например forward_list::sort + forward_list::sort + forward_list::merge или forward_list::splice_after + forward_list::sort), объяснил как это работает, что быстрее, какие ограничения накладывает односвязный список и попытался часть из этого реализовать. Начать можно было просто с сортировки пузырьком, а дальше предложить развитие, ни где же не требуется сложность изначально. Но, возможно, я ошибаюсь на счет интервьюера )
Вы — интервьюер моей мечты!
Хотя я только к таким как Вы на собеседования и попадаю, очень везёт, видимо =)
К сожалению, некоторые интервьюеры просят как раз изобрести велосипед, а не использовать стандартную библиотеку.
я потому что сталкивался с людьми которые отлично знают библиотеки, а вот чуть поправить штатный функционал или переделать какуюто ф-цию без подсказок — 'а как? напиши подробное ТЗ на 10 листах'
это не список вовсе, а нода списка какая-то
То что в статье - это и есть классический интрузивный односвязный список. Это потом уже придумали разделять на контейнер и его узлы. И то, это удобней лишь при наличии встроенных в язык средств ООП.
Чем плох его список?
Тем что
1. в bool присваивается 0?
2. ну ладно, допустим это не с++, но тогда в указатель присваивается 0?
3. какие-то сокращения вместо имен. Зачем? Место экономим?
4. в одну строчку запиханы цикл, два тернарника и инкрементация с какой-то нетривиальной логикой. Опять же, зачем? Долго нужно думать над таким кодом
Скорее всего интервьюер просто понял, что не хочет такой код видеть на код ревью и поспешил закончить. В целом если речь про позицию джуна, то ошибки понятны и можно было бы дальше говорить. Но какой там был грейд, автор не сказал
Ну со спеху написать вот это: list* src = fst.next? &fst:&scd; src->next; src = src->next->next || flg? src->next : (flg = 1, &scd) , все равно кажется странным. Да и сокращения тоже очень сомнительные, лучше бы уж l1 l2, а не такие стремные. Не защищаю интервьюера, но код несколько стремно выглядит.
Может у ревьюера там обед уже стыл, а KPI по собеседованиям уже был выполнен...
можно еще раз ревью?
ListNode* mergeTwoLists(ListNode* list1, ListNode* list2) {
bool f;
ListNode* t;
return (ListNode*)
(
(!list1 * (unsigned long long)list2) +
(!list2 * (unsigned long long)list1) +
((!!list1 && !!list2 &&
(
((f = (list1 -> val <= list2 -> val)) && (t = list1, list1->next = mergeTwoLists(list1 -> next, list2)))||
((!f) && (t = list2, list2->next = mergeTwoLists(list1, list2->next)))
)
) * (unsigned long long)t)
);
}
Адовое оперирование условиями через целочисленную арифметику. Если у вас за спиной стоит мужик с пистолетом, который выстрелит если вы используете if, дайте знак.
Зачем кастовать все указатели к ull?
Приведена функция, сливающая 2 уже отсортированных списка. Это не всё решение, а только его часть.
На каком нибудь эльбрусе этот код может работать быстрее за счёт более простой конверизации компилятором и меньшего числа ветвлений (части выражения можно вычислить паралельно)
Кастовать требуется так как указатель нельзя умножать на bool
Из условия не следует что изначальные списки не отсортированы.
Кастовать требуется так как указатель нельзя умножать на bool
Bool по стандарту при касте к целому даёт 0 или 1, так что умножать его на uintptr_t безопасно. И в любом случае длинное целое, отличное от 0 и какого-то из входных указателей, будет невалидным возвращаемым значением, а значит и нет смысла расширять тип.
Из условия не следует что изначальные списки не отсортированы.
В условии ничего не сказано про отсортированность, значит в общем случае входные данные не сортированы.
3. какие-то сокращения вместо имен. Зачем? Место экономим?
Редактор неудобный, как пишет автор, плюс собес с машины, с которой много не печатает (хотя нафиг?)
Спискок тем, что используются сырые указатели. Функция тем, что у него задача без копирования, а первой же строкой в функции он делает копирование, хоть и не всего листа, а только первого элемента. Но все же
Не, в первой строчке там нет копирования элемента, это локальные ноды, в которых только указатели на первые элементы реального списка. (Не уверен, правда, зачем ноды вместо указателей). Если я ничего не пропустил, значения копируются только для выбора ref, но там очевидно можно заменить ref на ссылку если значение не int, а что-то тяжёлое.
Код трудно понимаемый и запутанный. При нормальном программировании наверное стоило бы написать шаблонную функцию сортирующую слиянием что-то, что имеет компаратор, input iterator и back inserter. Причём списывать с leetcode или ещё откуда-то -- нечего и незачем. Алгоритм самоочевидный если его реализовывать на нормальном ЯВУ, а не в C-стиле: делим список пополам, рекурсивно сортируем каждую половину (пока не дойдём до пустого списка), сливаем отсортированные половины (здесь нужен компаратор).
При программировании на C начинается -- никаких абстракций не ввести, вместо этого сразу 20 переменных, какой-то пинг-понг между ними, и куча звёздочек по которым программист должен угадать где упадёт программа. Нет, можно конечно абстракции и на C. Только выглядеть оно там будет ещё более громоздко и страшно. В итоге решение задачи превращается в борьбу с недостаточной выразительностью языка програмирования.
Собственно что примерно должно было получитья:
https://coliru.stacked-crooked.com/a/359a6331cb720b34
(прошу не пинать за отсутствие концептов, передачу по-значению и инвалидирующиеся итераторы -- покажите как сделать нормально).
На листке (в редакторе без компилятора) тяжело написать программу на C++ без ошибок. Мелких ошибок компиляции, не помнишь какого-то нюанса библиотечной фунцкии или шаблона. За что я люблю C++, так это то, что после их исправления -- сразу начинает работать. А программа на C со звёздочками, void'ами и C-кастами -- требует отладки. Но без компилятора эти ошибки не исправить и приходится скатываться на голый C (такая же ситуация в спортивном программировании где #include запрещают, даже utility и type_traits). Где, повторюсь, из-за недостаточной выразительности языка программирования всё скатывается в жонглирование полутора десятками переменных в запутанной функции.
На ICPC, IOI и Всероссе можно использовать всё, что поставляется с компилятором. Кроме stdlib можно ещё gnu pbds использовать.
Алгоритм самоочевидный если его реализовывать на нормальном ЯВУ, а не в C-стиле: делим список пополам, рекурсивно сортируем каждую половину (пока не дойдём до пустого списка), сливаем отсортированные половины (здесь нужен компаратор).
У вас односвязный список, вы не знаете, где у него середина. Даже если бы был двусвязный, середину от этого искать станет не проще. Чтобы работала ваша идея вам нужна возможность доступа к произвольному элементу, а в C++ std::list произвольный доступ не дает, если нужен произвольный доступ то это уже std::vector.
А почему нельзя один раз посчитать число элементов и после этого всегда знать где середина и потом ходить только до нее? Это даже не изменит сложность алгоритма сортировки.
Собственно эти собеседования и отбирают людей для которых такие решения очевидны и не требуют раздумий.
Мы бы хотели понимания работодателем следующей парадигмы: "всё, в чём работник разобрался, перестаёт быть сложным". Желательно вместе со следующей аксиомой: "всего знать невозможно".
Итого, задачу найма работника (при отсутствии 100% подходящего кандидата), сводим к поиску такого кандидата, который потратит на дополнительное обучение меньше времени.
а что, вы хотели бы чтобы человек написавший список вот так как он написан в посте работал над чем-то важным и сложным?
Не хотел бы. Но при условии, что это самая финальная-расфинальная версия, обдуманная как следует в спокойном рабочем режиме и обмазанная юнитами. Я не приведу точную цитату, но Роберт Мартин в своей книге говорит что когда он пишет код, то это самый грязный код на свете, но вот когда он посылает код в репозиторий - этот код уже чистый.
Теперь я понял для чего в некоторых универах учат программировать на листочке и компилировать в голове.
...а мы на втором курсе такие лабораторки на С++ решали, ещё и без этих ваших интернетов.
Причём потом выяснится, что у них в 23 году всё ещё C++03. Но C23 надо знать на зубок.
У меня аналогичная история с java была, но в другой компании. Терзали меня про новые версии на собеседовании, устроился, открыл репозиторий - 1.7. Нет, не 17, а именно 1.7(!). Зато усвоил ответ на классический вопрос с java-собеседований "что нового в java 8?". Потому, что это то, чем я пользоваться не мог. Но платили, тем не менее, хорошо за легаси.
Правильное собеседование должно выглядеть так:
Добрый день, хочу к вам работать.
Здравствуйте , напишите тестовое.
Спасибо, вы мне не подходите, до свидания.
Если без сарказма, то у этой схемы есть один изъян. В природе есть множество программистов, которые ещё не настолько прокачали репутацию и портфолио, чтобы их в принципе взяли на достойную работу без тестового задания :)
А всё равно, они даже твое резюме не читают. И для всех: напишите связный список... да йопт! Я драйвер и uvc устройство реализовал в OS-less окружении в event-loop на microblaze за 2 недели. Драйвер для эксперементалоного IP, с microblaze на тот момент тоже не работал. IP для usb 3.2 gen2, раскачались на 10gbit. Или недавно: рабочий прототип face auth камеры из г-на и палок с созданием эрзац IR сенсора из обычного RGB. И сделано быстро, хотя тема была - terra incognita, больше матчасть изучал, чем код писал...
Или просто пишу: удалёнка. А мне сходу: готовы к релокации... я таких сразу в спам отправляю.
В общем, иногда пригорает от лютого несоответствия вопросов на собесах и повседневных задач.
ЗЫ выговорился.
ИМХО: с вашим опытом не стоит подавать в Яндекс, поскольку он для них по-видимому нерелевантен.
Или просто пишу: удалёнка. А мне сходу: готовы к релокации... я таких сразу в спам отправляю
Ну вообще одно другому не мешает. Например, если удалёнка в пределах определенной страны (или нескольких стран).
С подобным опытом вообще не принято проходить собеседования :)
А всё равно, они даже твое резюме не читают.
Ну как бы написать можно много чего, в этом и есть одна из целей собеседования - понять, насколько человек соответствует своему резюме. Когда "синьор" не может физзбазз на собеседовании накидать за полчаса - это смешно только первые 15 раз.
Когда «синьор» не может физзбазз на собеседовании накидать за полчаса — это смешно только первые 15 раз.
1) только обычно в задачах не физзбазз, а чтото с литкода… причем не easy уровня
2) писать надо на бумажке
3) хорошо… на ДОСКЕ
4) ладно… в блокноте, интернетом пользоваться нельзя!
и в итоге задача превращается в тест навыков компилятора и памяти
Всем плевать, компилируется ли программа. Интересует, понимает ли кандидат что вообще писать надо.
Ну, упоротые есть везде, к сожалению...
Я вам про процесс, вы мне про очевидно неадекватного интервьюера.
Your mileage may vary. У меня за всю жизнь только один был чисто на алгоритмы собес, и то там был Codesignal с медиумам с литкода (3sum + еще какие-то две). В остальных случаях что-то легкое типа смерджить два сортированных массива + просили по шагам пройтись и проверить, как работает.
Ещё зависит от тестового задание. На небольшое вроде того, что у автора еще можно согласиться. Но у меня был опыт, когда собеседование проходило сначала в виде теста, мол делай, а я(интервьюер) потом подойду и гляну. После чего мне было предложено написать полноценный rest api для викторины с oauth2 аутентификацией, полной документацией и чтобы это все в докере работало со сроком в неделю(?!). По неопытности я согласился, но задним умом я понимаю, что вне зависимости от того, джуна собеседуют или сеньора, подобные собеседования - это неуважение ко времени, которое человек для вас выделил. От таких собеседований можно смело отказываться, так как скорее всего подобное неуважение будет и в повседневности
Подобные собеседования, это пусть не осознаная фильтрация, но именно фильтрация. Компания так получает к себе исполнительных, но не уверенных в себе людей, которые будут делать что им скажут.
Пара сотен собеседований и сервис готов) это такой модный-современный метод разработки devless. Декомпозируешь сервис по спринтам, на каждый спринт выделяешь по пять кандидатов, кто-нибудь да напишет часть. Последние два спринта - просишь предыдущие в одно целое собрать)
Раньше примерно так делал. Но в последний раз очень хотелось в некоторые сильно интересные компании, поэтому пришлось писать тестовые задания.
Всё правильно, за исключением того что автору дали не тестовое а провели классический 45-минутный раунд интервью, прям как в этих ваших FAANG-ах. Единственное отличие в том что Яндекс может провести на 1-2 раунда больше, (5-6 против 4), остальное прям 1 в 1.
Кстати, по моему скромному опыту, интервьюеры Яндекса давали более интересные задачи чем оные из FAANG-ов.
Вы даже в статье написали какой-то ужас вместо примерно 5 простых и понятных строк кода. Собеседующий прав.
Сразу скажу, что писать так нельзя
Тогда почему ты так написал?
И вообще, статья-то о чём?
Мне кажется, что статья о том, что когда идёшь на интревью без подготовки, получается не очень.
Под подготовкой в данном случае я понимаю, узнать про тип интервью и почитать советы как такие интервью проходить.
Я в свой время развил навык решения кодовых задачек. В этом нет ничего сложного, но требует много времени. Для большинства программистов шансы пройти такие интервью без подготовки близки к нулю.
узнать про тип интервью
В Яндексе всегда алгоритмические задачи "на доске". Хотя, не знаю как там собесят синьоров, но у прочих - всегда. Даже на неалгоритмических раундах, задачи с каким-никаким алгоритмом, типа "напиши свою реализацию LinkedList".
И ещё, у меня было... с ними пара раундов, так вооооот, говорю шёпотом чтобы не спугнуть.... в одном случае мне разрешили использовать IDE! Того и гляди, технологическая компания №1 освоит парное программирование в IDEA, и тогда заживём! :)
Joint - это косяк, что в принципе правильно описывает содержимое функции
А исходные списки в задании были точно произвольные? Решал похожую задачу, где входные списки были уже отсортированы и нужно было просто грамотно провести их слияние. Решалось за О(N).
Решалось за О(N).
Побуду немного педантом, но раз списка два то O(N+M) будет более правильным. Перед тем как упростить до O(N), нужно получить согласие от интервьюера, что длинны списков изменяются в одних предалах. Или просто сказать, что сложность линейная.
Это в общем не критично, но на собеседовании себя надо красиво продать и показать, что вы знаете больше.
В рамках такой задачи мне бы еще хотелось услышать, что этот алгоритм является частью сортировки слиянием.
О(N+M) и O(N) не одно и то же? Я особо в этом не разбираюсь, но если это не так, то хотелось бы понять, почему.
Представь, что списки связаны между собой логически. Например, в первом у тебя строки, а во втором все суффиксы этих строк.
Тогда у тебя длины списков N и M, но M=N*K (для каждого элемента первого списка K суффиксов во втором), и сложность алгоритма линейна относительно второго списка, но нелинейна относительно первого.
Не уверен, что конкретно этот пример действительно понятный, но суть в том, что длины списков могут быть взаимосвязаны. Второй список - все подсписки первого, и мы получаем квадратичную сложность относительно одного из списков.
В каком-то смысле это буквоедство и формальность, но с другой стороны показывает понимание вопроса.
Задача о рюкзаке NP-полная, но имеет сложность решения O(N * W), и если ты это упомянешь, и даже сможешь объяснить, то это немного выделит тебя среди остальных кандидатов: не просто решаешь задачи, но еще и знаешь матчасть.
Представь, что списки связаны между собой логически. Например, в первом у тебя строки, а во втором все суффиксы этих строк.
Тут как раз связь не нужна, если можно выразить одно через другое, то можно и упростить. Например длинна одного сипска, всегда в два раза больше m = 2n; O(m+n) -> O(2n + n) -> O(3n) -> O(n).
Некоторые алгоритмы, например nested-loop join в базах данных зависят от порядка выполнения. Сложность такого джойна примерно O(n) * O(log(m)), где n это размер меньшей таблицы. Между длиннами таблиц нет логической связи, но зато есть доболнительное требование по соотношению этих размеров.
Разве не O(N) всё-таки? Где N — длина меньшего списка. Если списки отсортированы, то остаток списка с бо́льшей длиной перебирать не нужно.
При слиянии двух отсортированных списков запросто может быть, что придется перебрать наиболее длинный. Например, [1, 5] и [1, 2, 3, 4]. Так что надо брать именно наибольший список, то есть O(N+M)
Действительно, верно, всё так. Зашёл даже на LeetCode за своим решением этой задачи:
ListNode* mergeTwoLists(ListNode* list1, ListNode* list2) {
if (!list1) return list2;
if (!list2) return list1;
ListNode *i = list1, *j = list2;
if (i->val > j->val) swap(i, j);
ListNode *merged = i;
while (i->next && j) {
if (i->next->val > j->val) {
swap(i->next, j->next);
swap(i->next, j);
} else i = i->next;
}
if (j) i->next = j;
return merged;
}Как легко всё-таки простые задачи с собеседований обсуждение провоцируют.
Вам не понравится интервьюер и его методы, вы тоже ему не понравились, как и ваш код. Так как вы сошлись во мнениях, собеседование можно считать успешным.
я боюсь, вас забрили из-за сложности алгоритма. У вас O(N^2), тогда как односвязные списки сортируются merge sort-ом за O(N*log(N))
merge sort на двух списках за O(N*log(N)) по времени звучит как очень непростая задача для 20-30 минут на интервью. надеюсь, автор всё-таки чего-то не понял или не уточнил в условии.
я думаю, что никто бы не стал требовать полностью все реализовывать, достаточно было бы сказать "сортировать будем мерж сортом", накидать топовую рекурсивную функцию, заголовки split и merge, а дальше что успеется
Но тут требуется не merge sort (который,кстати, не настолько уж сложен), тут просили маленький кусок, одну простую операцию из алгоритма: merge.
И сделать его *вот таким* способом, да еще и накосячить в его сложности - это сильно.
Либо он этого не уточнил ¯\_(ツ)_/¯
95% что автор забыл или не придал значения, для варианта с сортированными списками это задача на реализацию мержа которая пишется в 5 строк, а при несортированных списках нужно отдельно написать мерж сорт и смержить результаты, это логическое излишество которых в таких интервью никогда не бывает.
На что получаю ответ, что он, опытный мастер, наблюдая за моими руками, никакой осмысленности в моем черновом коде не видит. [...] Человек из Яндекса не может прочесть код с оператором “запятая”?
Я не опытный мастер из "Яндекса", но, кажется, догадываюсь, в чём дело. Человек не "не может" прочитать код, он не хочет его читать, потому что он выглядит как нагромождение строк и не воспринимается взглядом, его нужно декодировать. Этого достаточно для отказа.
Предположу, что собеседующий хотел увидеть декомпозированное на несколько функций решение, как-то так:
ListNode* mergeAndSortInplace(ListNode* a, ListNode* b) {
a = sortInplace(a);
b = sortInplace(b);
return mergeSortedInplace(a, b);
}
ListNode* mergeSortedInplace(ListNode* a, ListNode* b) {
// Тут делаем в один проход слияние двух отсортированных
// списков и возвращаем голову результата.
}
ListNode* sortInplace(ListNode* list) {
// Тут делаем сортировку (быструю или, если не хватает
// времени, пузырьковую) и возращаем голову результата.
}
У вас задача неправильно решена, нужно сначала смержить 2 списка, а только потом отсортировать, иначе условно для [1,2,3] и [1,2,3] у вас получится [1,2,3,1,2,3] вместо [1,1,2,2,3,3]P.S. Не понял причину минусов, если в вашем понимании слияние не конкатенация, то почему тогда за один проход не решить ¯\_(ツ)_/¯
Так нельзя.
фишка merge sort это именно сортировка 2-х списков. и она дает O(n* log N)
этапы там такие
слияние 2-x списков длины 1 с их одновременной сортировкой
разбиение на списки длины 2
повторение с шага 1 для длины *2 пока разбиваться уже не будет
Человек не "не может" прочитать код, он не хочет его читать, потому что он выглядит как нагромождение строк и не воспринимается взглядом, его нужно декодировать.
Именно. Эти задачи нужны не столько для решения собственно задач, сколько для того, чтобы посмотреть как человек пишет, отлаживает и тестирует код. А также про общение с интервьюером.
Странный выбор темы для рекавери мода, и тем более подача.
Когда мне на собеседовании предлагают текстовый редактор, я спрашиваю, нужно ли, чтобы код обязательно компилировался. На что мне всегда отвечают, что незначительные ошибки не играют роль. Подсказки и подсветка разработчику с определенного уровня опыта обычно не требуются, например, я часто в комментариях к PR предлагаю небольшие блоки кода, которые доносят именно идею, не лезть же в среду разработки.
Я пишу не на C, но, думаю, идея везде общая. На таком собеседовании важен сам процесс, а не только результат. Как разработчик декомпозировал задачу, как разбил на методы, какие имена даёт методам и переменным, как рассуждает вслух. Обычно, если начинаешь впадать в ступор или движешься в неверном направлении, интервьюер помогает наводящими вопросами или советами. Его цель не задавить, его цель узнать как можно больше о претенденте.
Что такое рекавери мода? Ну, и вы наверно правы в целом, за 20 минут, что мной было потрачено где-то на половину этого кода, надо был сделать оценку(estimation) и какой-никакой дизайн в виде комментариев будущих блоков. Но намека на это в задании не было(было - написать функцию)
Кодинг этап интервью стал стандартом уже много лет назад как, ну, как минимум, в США, на счет России не уверен, на этом этапе приходится решать алгоритмические задачки в онлайн редакторах. Если вы планируете успешно проходить эти этапы, вам придётся потренироваться их решать на leetcode.com, или аналогах.
Не вводите общественность насчет штатов+, там никому не будут платить, чтобы тот следил за руками кандидатов - только автоматические веб-сервисы. И без компилятора - ни одного не видел. Часто сначала предлагается тестовый пример, чтобы научиться веб сервисом пользоваться. Обычно дается лимитированный временной слот. Но бывают задачи просто на время, часов на 10, например. Еще в отличии от яндекс-практики, там обычно нет дефектов в требованиях (видимо прошло через значительное число соискателей, которые там еще имеют привычку оставлять фeeдбак на условие задачи)
Если кому интересно, могу что-нибудь опубликовать из нерешенного мной (решенные обычно не записываю, а во нерешенные копирую в спецархив на память :) )
Как-то вы категорично. В ФБ и Гугле собесы ровно такие, вы пишете в блокноте, интервьюер следит за руками. Обе компании американские, и обе довольно технологичны, и при этом имеют большой поток кандидатов.
Про Яндекс: там тоже обсуждаются условия задач, косяки исправляются.
Не знаю про ФБ, а про Гугл - все ходы записаны Смотрим https://www.youtube.com/watch?v=rw4s4M3hFfs
Интервьюер написал в "блокноте" больше и наговорил больше чем интервьюируемый (интервьюируемая). Слежки за руками тут нет, потому что интервьюерная транзакция(скажем так) не два алгоритма в одном, не алгоритм и даже не функция, а строчка кода-, отражающая идею.
ЗЫ: Интересно вот что, интервьюер потратил больше 10 минут на feedback. У нас фидбек выгрызать из нанимателей надо, и то, обычно отпишутся.
К сожалению, у меня нет часа для просмотра вашего видео. Замечу только, что это не настоящее собеседование: Клемент действительно работал 2 года в Гугле, но это видео — фактически реклама его сервиса для подготовки к алгоритмическим собесам. 10 минут на фидбек потрачены не для кандидата, а для зрителей. Любые выводы на основе подобных видео могут отличаться сколь угодно сильно от реальности.
Мой личный опыт собесов в Гугл и ФБ говорит о том, что и там, и там интервьюверы почти не говорят. Совсем. Обратной связи во время интервью не было: человек просто себе что-то помечает, ну и на уточняющие вопросы отвечает. В гугле фидбек был уже после, на созвоне через рекрутёра в форме "как вы сами оцениваете прошедшее собеседование?" При этом, конечно же, для успешного решения задачи недостаточно ключевой строчки, нужна корректная программа без багов. Интервьюер терпеливо ждёт, пока в блокноте не появится законченный работающий код.
А вы поделитесь своим опытом?
могу что-нибудь опубликовать из нерешенного мной
Будьте так любезны.
Очень важный этап такого собеседования - это поговорить. Вы обсуждаете возможные варианты решения, сложность, договораиваетесь о решени которое будете делать и только потом начинаете кодить.
По статье мне показалось, что вы с места в карьер полетели. И вместо того, чтобы обговорить простое решение с двойным цилом, его начили реализовывать.
Возможно вы пропустили или не спросили что-то важное, например не остортированны ли списка которые вы сливаете.
Важный этап такого собеседования, что интервьювер постоянно молотит языком и заставляет тебя что-то отвечать, и в такой ситуации думать над кодом -- невозможно. В спортивном программировании тебя хоть на какое-то время оставляют в тишине, даже если и с голым C. Может я плонетянин, но у меня в мозгах только один "думатель" через который всё прокручивается, и исходник на C++, и внутрений диалог, и прокрутка программ в голове и вся прочая болтовня языком. И если я буду постоянно болтать языком, то я могу только выполнять тупейшую работу. Это конкретно про яндекс.
У других или алгоритм спрашивают (где не надо пытаться в голове удержать десять переменных и одновременно молотить языком), или дают время порешать задачу самостоятельно.
А задачи у Яндекса не являются супер-сложными при том (у других -- сложнее). Там нет нужды знать какие-то особые методы решения отдельных классов задач или воспроизводить сложные алгоритмы, ну только самые базовые. Скорей больше задачи на внимательность и среднюю сообразительность, и на способность писать код и болтать языком одновременно.
Мой опыт собеседований показывает, если ты спросишь: "можно ли мне пару минут подумать", тебе ответят что-то типа "конечно", и замолчат. Ни разу не было иначе, хотя, допускаю, что мне просто везло.
Пару минут дают, но за это время сложно набросать код и мысленно прогнать его на десятке тестов. А потом, действительно, интервьюер Яндекса просит объяснить будущее решение. На олимпиадах и впрямь легче соображается.
Вообще не совсем так. Общая схема секции с кодом примерно такая (на каждую задачу):
Условие задачи - можно и нужно уточнять если что-то не очевидно/не понятно.
Придумывание задачи (можно вслух, можно молча).
Когда человек говорит, что придумал или начинает писать код его просят рассказать общую идею какое решение будет написано. Тут спросят про алгоритмическую сложность, могут подсказать почему идея не сработает(если не сработает). Тут можно и мысленно код придумывать, а можно только общую идею.
Пишется код(опять же можно говорить при этом, можно молча).
Когда кандидат говорит, что всё готово, идёт проверка. Всё ок - отлично.
Если есть ошибки - говорят.
Не нашел - просят придумать тесты и прогнать их (если еще не делалось самим кандидатом).
Не помогло - показывают тест где будет ошибка.
Если совсем не помогло - намекают где именно (но это уже совсем плохой случай).
Для простых задач вроде этой, при попытке использовать стандартную библиотеку скажут, что это всё замечательно и в проде так и надо, но тут, пожалуйста, сделайте руками.
По идее всё это говорится собеседующим в начале (если он адекватен). Как минимум в немного в сокращённом виде пункты 1-5.
Вообще, раз вы написали статью, значит теперь у вас уже было время подумать над решением и в удобном для себя редакторе. Было бы интересно увидеть вариант.
О, дельный коммент. Хочу тоже со стороны посмотреть)
Дописано в конце статьи по техническим причинам. Вообще целиком код я не планировал обсуждать. Только "неправильную" строчку c for. Я вижу, что абсолютно все те, кто её комментировал - не понимают как в ней цикл работает. Теперь, кому интересно, может разобраться, посмотрев, как этот сложный цикл разложен на два простых (строчки подобной сложности возникают когда рекурсию реализуешь в цикле, бывает надо - к тому что тема не такая уж надуманная)
Я вижу, что абсолютно все те, кто её комментировал - не понимают как в ней цикл работает.
Какие вы делаете из этого выводы?
Для меня код, который разные люди могут понять по разному, является плохим кодом. Писать просто и понятно это не то, что получается само, к этому нужно себя приучать. В стрессовой ситуации, например собеседование будут работать привычки больше, чем голова.
Никакой код не существует см по себе. Любой код отвечает какому-либо требованию и существует благодаря существованию этого требования. Совершенно не имеет значения, записаны эти требования или нет - они появились, поскольку заказчик вошел в контакт с исполнителем.
Требование реализовать два алгоритма в одной функции за неестественно короткое время очевидно означает, что приоритет простоты ясности и понятности, а, формализуя, читаемости и структурируемости - у заказчика идет вторым планом.
Я где приводил пример про нагруженный transform из какого-нибудь С++20. Читаемость там очевидно не си-шная( не простая\ясная), а структурируемость еще не устоялась. Но сие не значит, что требование написать что-то подобное нельзя выдвигать. Как-то так.
Требование реализовать два алгоритма в одной функции за неестественно короткое время очевидно означает, что приоритет простоты ясности и понятности, а, формализуя, читаемости и структурируемости - у заказчика идет вторым планом.
Не надо заказчику приписывать логическое мышление, для него это может быть совсем не очевидным. Такие вещи должны проговариваться.
Если мы говорим про собеседования, то у того кто готовится к решению именно таких задач, результат будет намного лучше, и ожидания интервьюера рассчитанны на этот уровень.
Я где приводил пример про нагруженный transform из какого-нибудь С++20.
Читаемость там очевидно не си-шная( не простая\ясная), а
структурируемость еще не устоялась. Но сие не значит, что требование
написать что-то подобное нельзя выдвигать. Как-то так.
Решение задачек имеет много общего с реальным программированием, но всё же это отдельное ремесло со своими особенностями и правилами.
Не надо заказчику приписывать логическое мышление
Определенно не приписывал. Вот бизнес логика интервьюера, возможно отражающая политику компании, меня бы могла заинтересовать. Да, это все писалось из любопытства. Потому, кстати, и здесь, реакция ботов забавляет ;)
Готовится предлагаете? Но я относительно возрастной программист, чтобы рассчитывать попасть в яндекс без условного "блата". Потому, увы, интерес тут только согреться. В честном спаринге. Не? Не сюда?
Готовится предлагаете? Но я относительно возрастной программист, чтобы
рассчитывать попасть в яндекс без условного "блата". Потому, увы,
интерес тут только согреться. В честном спаринге. Не? Не сюда?
Яндекс и многие другие играют в открытую и по своим правилам. Если хотите с ними играть, то надо готовится, если нет, то зачем тратить время.
К данной задаче мне [под]готовка сильно не поможет (из ботов никто не выложил якобы канонической имплементации).
Да, я туда не рвался, но и отказываться глупо. Хеадхантерша упомянула про решение задач, логично предположить, что интервьюер смотрел мое резюме, но выглядело так, что он ничего обо мне не знает. Т.е. уже не в открытую.
Теперь про свои правила. Вопрос опять же не в моей подготовке, вопрос прежде всего в бизнс-стратегии компании. И о том как туда вписаться. Критериях. Пусть даже в рамках игры.
К данной задаче мне [под]готовка сильно не поможет (из ботов никто не выложил якобы канонической имплементации).
Это подход настоящего программиста, сидеть у берега реки и ждать пока мимо проплывёт каноническая имплементация?
Напишите его самостоятельно в спокойной обстановке.
Да, я туда не рвался, но и отказываться глупо. Хеадхантерша упомянула
про решение задач, логично предположить, что интервьюер смотрел мое
резюме, но выглядело так, что он ничего обо мне не знает. Т.е. уже не в
открытую.
В те компании куда я собеседовался про задачки говорили и даже давали ссылку на редактор кода потренироваться. О том что мне предстоит делать рассказывали достаточно подробно.
Человек который должен проверить как вы задачки решаете может действительно о вас ничего не знать и может быть вообще из другого отдела. Это нормально, от него требуется только проверить, что вы умеете решать эти задачки.
Теперь про свои правила. Вопрос опять же не в моей подготовке, вопрос прежде всего в бизнс-стратегии компании. И о том как туда вписаться. Критериях. Пусть даже в рамках игры.
Чтобы туда вписаться нужно играть по их правилам. Если есть вес то навязывать свои правила.
Возмущаться можно до того как вы согласились с ними играть, дальше это уже просто нытьё.
Очень рекомендую почитать введение в Cracking the code interview, там хорошо расписанны причины стоящие за таким типом собесов, их плюсы и минусы.
Напишите его самостоятельно в спокойной обстановке.
У вас там пересменка? Уже написал, в конце статьи. Cвой. Но по идее должен быть и канонический. Или вы слово канонический - не понимаете? Это тот который знает интервьюер. Ведь он же не задает задания, не зная решения? Или таки задает? :) Ox ,боты боты.
Слежу 24/7 чтобы в интернете все было в порядке, даже на работе взял отгул.
Вы про это решение: "Не сильно тестированный вариант:"?
Выбор текущего значение из середины возможных кажется странным. int cur_max_data = 0; Отрицательные числа, это даже не крайние случаи, это половина множетсва возможных значенией.
На собеседовании это детскую ошибку можно списать на волнение. То что вы решили опубликовать улучшенную версию кода и сделали это спустя рукава - это для меня красный флаг. Лучше уж совсем не далать, чем так.
У меня сложилось впечатление, что вы обиженны всей этой ситуацией и ищете вину в других.
У меня тоже были ситуации, когда мои ожидания о своих великих возможностях разбивались о стену реальности. В таких случаях, я задаю себе вопрос, а что я могу сделать, что бы не сесть в лужу в следующий раз. Мне это помогло, интервью стал проходить гораздо успешнее. Хотя когда в прошлый раз когда искал работу на одном собесе облажался по полной, сделав не совсем то, что просил интервьюер.
Выбор текущего значение из середины возможных кажется странным.
int cur_max_data = 0;Отрицательные числа ...
Не читаем комментариев. А ведь разговор про требования уже шел. В частности про то, что без требования не существует ни одной строчки кода. И то, что требования не обязательно где-то записаны, они могут существовать по умолчанию. В частности к демонстрационному прототипу, где достаточно поддержать множество натуральных чисел. Чисел которые формируются естественным(натуральным/природным) образом. Но, согласен, это сложно.
опубликовать улучшенную версию кода ...
Опять же не бывает улучшенной версии кода, бывают уточненные требования. Эти уточненные требования, в соответствии с которыми была выполнена вторая версия кода, прозвучали в некоторых комментариях, которые вы не прочли, так же, как в предыдущий раз головную статью. Может быть, не понимая сути жизненного цикла программного продукта (что продемонстрированно дважды) не стоит выносить оценки по области принятия решения при программировании?
У меня сложилось впечатление, что вы обиженны всей этой ситуацией и ищете вину в других.
Ну что вы, что я ищу - я обозначил в самом начале. А именно - разобраться в ситуации в широком и узком смысле.
И даже "не ботам" могу сказать спасибо - информация получена.
Я как-то проходил собеседование в Яндекс из спортивного интереса (они сами на меня вышли). Со мной все разговаривали очень любезно, к техническому собеседованию дают время подготовиться. Первые пару собеседований стандартные. У Яндекса даже есть специальный сайт для тренировки прохождения собеседований. Во время собеседования мне даже было интересно обсуждать разные варианты решений, т.к. такими алгоритмическими задачами, решения которых заранее известны, я не занимался со школы. В общем - лично у меня самое положительное впечатление от общения и с рекрутёром и с техническими интервьерами Яндекса.
К технической стороне собеседования, конечно, надо готовиться, но в целом дам совет - не относитесь к любому собеседованию серьёзно. Собеседование - это как лотерея. Никогда точно нельзя быть уверенным почему вас взяли или почему вам отказали. Вас в первую очередь выбирают как человека, а во вторых как специалиста. Вы написали, что вам было неудобно программировать в их неудобном редакторе. Но в жизни есть много неудобных вещей с которыми приходится работать. Не обвинять же в этом рекрутёра? Вашим недовольством вы ставите очень жирный минус, потому что это показывает, что и во время работы в нестандартной ситуации вы сдадитесь. Рекрутёры ценят усилия, которые вы можете предпринять и видно, когда человек старается. Может даже случиться, что оказавшись в нестандартной ситуации вы измените течение собеседование в другое русло и из скучного разговора оно может оказаться интересным. Рекрутёр тоже человек. Покажите ему, что вы не из пугливых, что вы можете подчинять эти железяки своей воле!
Не будьте кожаным мешком!
Согласен полностью, не понимаю позицию автора.
К технической стороне собеседования, конечно, надо готовиться
Но зачем?
Если успех в прохождении собеседования целиком и полностью зависит от зубрежки и подготовки, то грош - цена и такому собеседованию, и тому набору специалистов, которые такую же фильтрацию прошли.
Рекрутёры ценят усилия, которые вы можете предпринять и видно, когда человек старается.
Ну если только для того, чтобы потешить ЧСВ рекрутера. Тут какая-то подмена задач рекрутера произошла. С "найти специалиста, удовлетворяющего требованиям" на "найти кого-то, кто будет стараться удовлетворить требования". Задача бизнеса в поиске исполнителя-то - иметь человека, который будет работать работу, а не старающуюся изо всех сил ясли-группу.
Ну, может у них цель - собрать команду людей, увлекающихся алгоритмическими задачами. Тогда всё делают правильно.
Красиво жить не запретишь 😊
Всегда можете набрать людей не любящих алгоритмические задачки. В Rockstar так как-то сделали, перекладка джейсонов не задалась
Но зачем?
К лайвкодингу надо быть хоть немного прогретым, иначе есть все шансы в нервных условиях ограниченного времени затупить на корнер-кейсах и тупо "не решить" простую задачу. Но это, конечно, если всё по-строгому, с дебаггингом под ключ, и недостаточно просто описать словами и накидать черновик решения.
С "найти специалиста, удовлетворяющего требованиям" на "найти кого-то, кто будет стараться удовлетворить требования".
Скажем, что бизнесу не нужен человек, который при любых трудностях ноет и складывает лапки. А требования - они абстрактны.
Скажем, что бизнесу не нужен человек, который при любых трудностях ноет и складывает лапки
ныть надо, а складывать лапки нет.
бизнесу дай волю, они такой говнокод в бой лить начнут капец
Так фильтрация "прошел в команду, потому что готовился (старался, бедный) к конкретному собеседованию", скорее всего, дает на выходе как раз людей, готовых к собеседованию.
И все. Она, скорее, никак не характеризует то, как человек сложит лапки.
И дальше, что мы ожидаем получить от человека, прошедшего этот фильтр, при возникновении трудностей?
Ему нужно будет заранее дать материал для подготовки к неожиданным трудностям?
Как именно он будет "стараться"?
Поэтому в требованиям нужно заложить "не пасует перед трудностями", и всегда держать в голове, что собеседование - стрессовая ситуация, и не обязательно за пару минут получится оптимальное или верное решение, да и получится ли оно вообще. Потому как ответ "с таким не сталкивался, попробовал бы посмотреть туда, но нужно погуглить день" - тоже вполне себе удачное удовлетворение поставленного требования.
Но в жизни есть много неудобных вещей с которыми приходится работать
И что? Какой вывод из этого? А еще в Африке дети голодают.
Если такие мучения с компаний на этапе первого контакта: собесов, то зачем это вот всё?
Интересно то, что некоторые выходцы из Яндекса тянут, порой, эту муть и в другие места: они уже просто не умеют по-другому. Лайвкодинг, два тестовых, интервью - это последнее что мне предложили. Но проект был - топ, этого не отнять.
А есть и тру-лиды, которые по небольшому тестовому и диалогу-собеседованию вполне себе могут сделать выводы.
А можно с этого момента поподробнее...
Хм… А то что случилось с деливери не показатель? Я, например, как человек, который раньше им пользовался очень "рад" его покупкой яндексом.
Получилась неюзабельная помойка: категорий больше нет, сортировки по времени доставки/рейтингу и проч. нету, чата нет, все промокоды из истории исчезли, да и история тоже, дизайн переделали под ужасный формат Я.Еды, позиций (ресторанов/магазинов) стало на порядки меньше, доставка стала в полтора-два раза дольше. И самое замечательное — убрали чат, оставив только почту и телефон. И если заказ задерживается на час (ну т.е. вместо указанных 20 минут проходит полтора часа), то позвонив по телефону можно услышать замечательное "извините, слишком много обращений, не можем обработать", после чего трубка просто кладётся.
Если говорить про отдел разработки, то половину (утрирую, точных цифр не знаю, но есть знакомые с которыми приключилось) очень крутых и даже известных инженеров просто поувольняли или в другой отдел устроили писать на других языках и работать с другими проектами. Так что не удивительно, что крутой сервис скатился.
Если говорить не про разработку, а другой персонал — работники доставки устраивают массовые забастовки за многочисленные нарушения и незаконные действия со стороны Яндекса. С неделю назад даже вроде уголовное дело завели, за мошенничество или что-то такое (нужно смотреть/гуглить) после встреч с госслужащими, которые решили разобраться в ситуации.
Так что расписывать более детально весь треш и хаос в Я.Еде (+Деливери) и Я.Такси (это из того что знаю) даже не хочется. Это на километр текста ещё выйдет.
Понимаю, что это не весь "Яндекс", но подобное не первый раз же. Просто данный случай самый актуальный на данный момент.
Эмм... Чат есть, фильтры есть, категории какие-то тоже есть (никогда не пользовался). Истории нет из-за переезда бека, скорее всего, может и восстановят. С промокодами - ну сервис зарабатывать наконец начнет. Про меньше и дольше я не сравнивал, может зима просто настала?
А все остальное - эмоциональный наброс. Каких-то "известных инженеров" уволили, какие-то "массовые забастовки за многочисленные нарушения" и даже "уголовное дело за мошенничество". Деливери был крутым сервисом, потому что они заливали деньгами рынок и получалось на 20-30% дешевле Я.Еды? Они практически до последнего момента не в состоянии были сделать так, чтобы еда начинала готовиться до прихода курьера в заведение. Даже если время приготовления 40-60 минут
Очень хочется почитать треш и хаос, если там какие-то факты есть. Пока это уровень сплетен и субъективного восприятия
Зарплаты ниже рынка, очень душный коллектив из оленьпиадников с раздутым ЧСВ, охреневший менеджмент и вытекающие из этого хреновые условия труда с людоедскими метриками.
А если олимпиадники такие умные, то что ж они не уходят в другие места? Им ж легко задачки решать на любом собеседовании, наверное. Хотя у меня такое подозрение, что нормальная разработка ПО несколько отличается от олимпиад и требует других навыков. Вроде того, что нужно уметь правильно выстраивать архитектуру, знать нюансы используемых языков программирования, библиотек, операционных систем, уметь работать с системами контроля версий, уметь видеть типичные проблемы на ревью и в архитектуре в целом, уметь отлаживать наконец, понимать как работают компиляторы и линкеры... Чем тут олимпиады помогут?
А код надо уметь писать? Хотя бы самый простой, как в статье?
Действительно, разработка - она разная и состоит не только из написания кода, но и из чтения чужого, иногда (субъективно) чуждого восприятию кода. И вот эту проверку на способность чтения-понимания практически не встречал на собеседованиях. Потому как заморочиться надо и подготовить код. Проще задачки дать или теорию спросить.
Кто сказал, что они умные? Если собака берёт призы на выставках - это ещё не значит, что она сможет загнать лося. Более того, это обычно значит, что как раз не сможет.
Ну, стремное, так стремное, не прошел так не прошел, а в чем смысл статьи-то был?
Автор такой типа: "я всю жизнь прожил в танке, я ничего не слышу, ничего не вижу". Странно, что есть люди, которые реально ничего не слышали про то, как устроены собесы в яшке, хотя на том же хабре это тыщу раз обсуждалось. Не менее странно, что это вылилось в коротенький пост-батхерт на хабр, хотя такая подача больше подходит для твитера или личного блога, например
Да у меня примерно такая же фигня)) прошел две секции, вроде все хорошо, ребята почти хлопают по плечу, говорят скоро увидимся, потом на третьей секции я не решаю полностью задачу (я не обработал крайние участки, хоть и пытался чего-то изобразить), как итог про меня забывают на две недели, потом сбривают. Но ребята, я и не такие алгоритмы могу решить и куда качественнее, но не в 6:30 вечера и не за пол часа)) я всё-таки андроид разработчик. На мой взгляд лучше в шахматы поиграть (показать умение логически мыслить) или по деревьям полазить (показать упорство), чем проходить это)) Яндекс лишь сбривать хороших девелоперов,и оставляет тех кому повезло. В заклад бьюсь, что проверь вы своих андроид разработчиков как меня 30% из них задачку не решит в аналогичных. условиях, а в спокойной обстановке за чашкой чая ее решат все
Не очень понятно из задания:
1) исходные списки уже отсортированы или нет?
2) Значения в исходных списках пересекаются или нет (то есть есть ли одинаковые значения в списках) ?
3) в каком направлении отсортированы списки по возрастанию или убыванию
если списки не отсортированы то ваш алгоритм не рабочий ,
если отсортированы в порядке возрастания и пересекающихся значений нет то ваш алгоритм потерял последнюю ноду в списке (list *a) функции joint,
если отсортированы и есть пересекающиеся значения то алгоритм тоже не рабочий
если сортировка в списках по убыванию алгоритм тоже не рабочий
э... а можно ссылочку на инфу, что в яндексе хорошие зарплаты?
Так не только в Яндексе будет: подобная ситуация возникает практически при любом лайв кодинг интервью в непривычной IDE. Фактически, проблема старая, но в новой обложке: собеседование не проверяет насколько кандидат подходит и скилловый, а лишь с какой-то вероятностью даёт шанс на его прохождение. Почти случайность. При этом предлагаемые для решения задачи могут даже вообще никогда не встретиться в реальной работе в этой компании.
Вебредактор яндекса - это отдельная боль. Как IDE он не работает, скорее как чуть-чуть прокаченный блокнот. Такое ощущение, что это более современная версия подхода "кода на листочке", и почему яндекс такое практикует, я могу понять - потому что "я сделяль". А вот когда другие компании на собесах зовут в него кодить, это уже беда)
Такое ощущение, что это более современная версия подхода "кода на листочке"
Вообще-то так и есть, в редакторе есть только подсветка кода и запись истории редактирования, и это сделано целенаправленно. Цель этих интервью в том чтобы посмотреть на ход ваших мыслей во время того как вы задачу решаете, а не в том чтобы получить синтаксически корректный код. Кодинг на бумажке для этого, как ни странно, отлично подходит.
Hidden text
Если у меня в редакторе будет такого типа шпаргалка - ход моих мыслей будет виден хуже?
Скажу мысль, которая тут уже пару раз звучала, но даже являясь действующим разработчиком, с несколькими годами стажа, я не помню на память все сигнатуры всех методов даже у обычного объекта. И это не мешает разработке, зачастую свериться с докой можно даже не выходя из редактора, а начав набирать имя метода
Если у меня в редакторе будет такого типа шпаргалка - ход моих мыслей будет виден хуже?
Это вообще иррелевантно - может даже отвлечет от сути задания, потому что они обычно на алгоритмы а не на знание стдлибы.
Поверьте, нормальному интервьюеру абсолютно наплевать напишете ли вы .length() или .size() если вы знаете что есть метод делающий то что вам нужно.
Пилить же полноценную онлайн IDE, ещё и с компиляцией на беке - можно, но совсем не обязательно и имхо усилий не стоит в контексте задачи которую решает этот онлайн листочек для написания кода.
В Майкрософт (субконтрактором) проходил собеседование вообще в каком-то интранетовом онлайн-пейнте. Копипастят тебе туда лабиринт (ну мне попалась такая задача - поиск выхода с ограничениями на доступные операции) с рядом добавляешь текстовое поле и описываешь алгоритм поиска выхода - на чем хочешь, да хоть блок-схемы мышкой рисуй.
А потом, ну давай проверим твой алгоритм, и в соответствии с алгоритмом рисуешь ходьбу по лабиринту и проверяешь работоспособность :)
В больших компаниях от маленького сотрудника нужно только одно - чтобы он был простой частью большого механизма и делал только то, что скажут - без права на собственное мнение, без права на альтернативные виды мышления и нестандартный подход. Соотвественно и участники собеседований на стороне работодателя - принимают только тот ответ, который соответствует тому, что написано в "книжечке". Шаг влево, шаг вправо - отказ.
Люди с определённым складом ума с высокой долей вероятности такое собеседование не пройдут, хотя на деле могут быть профессионалами высокого класса, способными изящно и эффективно решать нестандартные и очень сложные бизнес задачи.
Когда прогретые навыки кандидата и представителя работодателя не совпадают, начинается самая мякотка - представитель работодателя на собеседовании пытается показать свою крутость и свои компетенции, теорию по которым он учил и с которыми работает каждый день.
Отвечая на вопрос представителя работодателя, кандидат с ходу задаёт вопрос по тем компетенциям, где он прогрет и силён, а представитель работодателя начинает сыпаться - злиться и вести себя непрофессионально. В итоге он завершает собеседование с гарантированным отказом для кандидата. Проверено на практике :-)
Разумеется, случаи бывают разные, но общая ситуация повторяется почти каждый раз.
Грустно и точка.
Попробуйте тренажёр кода от Яндекса, та еще гадость. Надменные интервьюеры не новость, часто им хочется просто потешить своё эго, а не выполнять свои обязанности. Я не пишу на плюсах, но код очень наколеночный, это видно, можно было попросить оформить или спросить в в чем идея, если сразу обрывают, точно никто не нужен этому человеку, он сам огого.
В общем раз это теперь тред баек про Яндекс, то добавлю свою. У меня ситуация была с другого угла зрения. Осенью один за другим к нам на собес приходили один джун+ и один сеньор оттуда. Мы тоже даем задачку под конец, она она вообще изи левел. В общем эти двое стандартную задачку раскололи за какие-то секунды и потребовали посложнее. Дали посложнее - тоже влёт. Берём?
Нет, не берём. Реальность такова, что мы занимаемся энтерпрайз-разработкой. Задачки на кодинг - это так, на сладкое. А в первую очередь мы хотим видеть, что для человека нет "магии" в том, что он делает каждый день. Поэтому мы задаем вопросы не "что такое Х", а типа "почему в этой ситуации ты используешь именно Х и есть ли альтернативы". Еще мы проверяем умение читать код и видеть антипаттерны в код-ревью. В итоге поплыли оба. Потому что по гамбургскому счету нам параллельно, что человек пишет 4 вида сортировки по памяти, если он не может объяснить, а за счет чего именно ускоряется поиск в БД с использованием индекса и какие индексы когда стоит применять. Или если не видит явные косямбы конкурентного доступа в предложенном коде. Код-то читать каждый день придется, в отличие от "вращения деревьев".
Какой вывод? Да никакого по всего двум-то кандидатам. Но я все больше прихожу к мнению, что ИТ-гиганты это вообще ни разу не кузницы кадров.
Каждому свое. Я, как правило, ориентируюсь не на то, что нужно для "ежедневной" работы, а на то, что понадобится, когда все начнет ломаться.
Рутине мы научимся: все джейсоны лопатой ворочают, на сотый раз даже обезьяна сообразит.
А вот разок у нас поломалось фигня, и тяжелое расследование выявило баг в компиляторе gcc. "Повезло", что у нас был чувак, который хорошо знал ассемблер и как транслируется код: в коде бы мы долго искали.
У нас в серсвисе (с миллионами запросов в час) внезапно все начало тормозить. Анализ показал, что тормозит почему-то в парсинге json в библиотеке. Но поскольку у нас не json общего вида, а вполне конеретный, мы написали свой сверхбыстрый парсинг json-а на двух стеках, и все заработало отлично. "Повезло", что у нас был чел, который умел это писать, причем за 40 минут вместе с тестами, что позволило снизить Time To Recover до смешных двух часов.
У нас сервис сегфолтился раз в сутки на каждой машине. Иногда это создавало проблемы. Поставили чувака разбираться, он в мешанине макросов 10-летнего легаси нашел проблемы в кастомном алгоритме сжатия, и поправил (+0.01% размер файла на диске, минус краши). "Повезло", что был чувак, хорошо разбирающийся в алгоритмах сжатия.
Или не "повезло", а таких и искали.
По итогу ты смотришь, с какими проблемами ты обычно сталкиваешься, и подстраиваешь набор людей под этот комплект проблем.
Если ты Яндекс, с кучей самописных технологий, ты будешь искать того, кто алгоритмы знает, и язык до уровня инструкций.
Если ты интернет-магазин, то того, кто знает, как индексы в БД правильно настраивать. И какие SQL запросы во что разворачиваются, потому что это твои основные проблемы. Ну или какую из открытых технологий мы выбираем, и почему.
И кузница кадров Яндекса отличная, только под специфические задачи, с которыми далеко не все сталкиваются в индустрии.
Если прочесть cracking coding interview и how Google works, то станет понятно чего ждут на собеседовании:
Убедился что точно и верно понял задание и необходимую сложность решения
Сам подумал над разными решениями до кодинга
Сам выяснил недостающие в задании нюансы
Сам написал что то типо тестов, что бы проверить себя потом, что алгоритм все пройдет (если инпут Х то ответ У)
Написал код
Обязательно проверил свой же код до сдачи
Если есть трудности, посоветовался с интревьером, это твой коллега и вы решаете рабочую задачу
Убедившись, что задача прошла тесты, скомпилируется и будет работать правильно сдаешь задачу
Яндекс смотрит как думает человек и нравится ли интервьеру то как думает человек. Решить алгоритм важно, но это 50% того, что хочет интераьер. Этого не достаточно для оффера. Покажите ему, что с более сложной задачей вы тоже справитесь, как минимум правильно поймете задание, напишите тесты и сходите к коллегам за помощью.
Однако все мы люди и интерьер смотрит через свою призму опыта, как бы не хотела компания унифицировать процесс найма. С этим нужно смириться и не грустить.
Все шаги которые я написал как правило проходятся быстро, если ты натренирован. Поэтому они сами советуют решать leetcode до интервью, как и FAANG и около них.
Например facebook дает 40 минут на 2 задачи, уровня easy первая и medium/hard вторая. (Проходил собес, но не получилось)
При этом, я сам не очень люблю алго-интервью, но есть 2 стула, либо фейлить собесы, злиться и грустить или принять правила игры и строить карьеру.
Осенью участвовала в Weekend Offer Яндекса. Отправила резюме. Прислали ссылку на контест. Прошла, получила сообщение, что необходимое количество баллов набрано и "наша команда скоро с вами свяжется". Но никто так и не связался. На мой запрос поддержка ответила: "Рекрутер пригласит тебя на секции, если твой профессиональный опыт соответствует требованиям, которые мы описали на сайте мероприятия". То есть они прочитали мое резюме только после того, как я прошла контест, и что-то там им не понравилось. Неужели нельзя было поменять эти этапы местами...
Полагаю, что зарегистрировавшихся на контест X, а набравших баллы X/20. И заставлять hr-ов смотреть в 20 раз больше резюме... Их время тоже денег стоит, а конест условно бесплатный. Резюме не прошедших можно потом смотреть по остаточному принципу. Что-то, наверное, рассматривают, но врядли есть физическая возможность посмотреть всех до контеста.
Все так, но посмотреть резюме - задача на 1-2 минуты, а решить контест - 5 часов.
в октябре ходил по собесам с вилкой 350-400, и в яндекс и в мейл (где когдато работал) и еще кудато там.
в итоге выбрал компанию чуть поменьше (хотя и не маленькую)
я — выбрал, не мне отказали
==
свой стартап не проще организовать кстати, особенно сейчас
Про забитый штат - не похоже, судя по количеству висящих вакансий Яндекса на hh.
Я человек без опыта 40+ лет - прошел подобное интервью и предложили существенно больше 200к
проще свой стартап сорганизовать
Есть основания полагать, что данный коммент попал к нам их параллельной вселенной. Это объясняет и загадочный момент с 200к. Потому что в моей наблюдаемой вселенной фраза "да просто намути стартап" звучит примерно как
да просто получи гражданство Японии - сможешь по всему миру ездить
проще вертолет свой купить и в пробках не стоять
проще свой гугл написать, чем на булшит из топа выдачи смотреть
Очень трудно находить общий язык с представителями секты Свидетелей Олимпиадного Программирования На Собеседовании. А еще труднее - нанимать адекватных людей по такой схеме. Видел это счастье с обеих сторон - и собеседующего, и собеседуемого - но так и не нашел ничего более оторванного от реальности для отбора SRE, коим и являюсь.
Согласен, что собеседование странное. Расеянские ИТ-компании принадлежат олигархам, работают там лимитированные смузихлëбы, которые чужака не подпустят. Гои же работают в Яндекс.Доставке и Такси. Задачка совершенно не объясняет как работают высоконагруженные сервисы с ИИ в этом Вашем Яндексе. Жду пинков от охранителей.
В чем глубокий смысл требовать написать код в крайне неестественных условиях (без компилятора и в неиспользованном ранее редакторе)?
Какой кошмар. Думаю, рассказывать ли, как ещё несколько лет назад, когда собеседования были только очными, меня просили писать код на листочке? А тут - редактор, понимаешь, без компилятора.
А по задачам - на собеседованиях Яндекса (и не только) задачи с leetcode берутся, это не секрет, даже наоборот, HR говорят: в рамках подготовки к собеседованию порешайте задачи на leetcode, уровня - в зависимости от того, на джуна, миддла или сениора собеседуешься.
В Яндексе задачи не с leetcode, там своя база, накопленная за много лет. Просто часть задач кандидаты успели слить на leetcode.
Сложность задач не зависит от уровня, на который собеседуешься: всегда дают одну задачу easy/middle и одну middle/hard, если успеешь за час обе щёлкнуть, могут третью дать. В моём случае, на одной из секций у интервьюера не оказалось четвёртой, поговорили остаток часа за жизнь 😀 По результатам того, как кандидат подходит к решению задач и решает их, предусмотреть краевые случаи, ищет и исправляет баги, и определяется его уровень. А не уровень определяет задачи, как у нас написано. Ну и, конечно, если кандидат претендует на senior позицию, ему назначат system design, потому что сеньёрность на алгоритмической секции не определить
Ндаа, опять какая то священная война в коментариях. Я вом напишу как это выглядит с другой стороны барикад. Большая контора хочет нанимать инженеров. Почти всегда есть куча вакансий, поэтому найм идет постоянно и потоком.
Теперь требования:
1) Надо не тратить слишком много ресурсов на сам найм. Прособеседовать одного кандидата это 7-8 часов работы инженеров и 1.5-3 часа менеджедов.
2) Процесс должен быть одинаковый для всех. Иначе от исков о дискриминации компания не отобьется. Т.е. список вопросов более-менее стандартен и одинаковой сложности, все интервьюеры проходят тренинг и сертификацию.
3) Статистика говорит, что на 10-20 очных интервью - 1 найм. Сколько отсеивается на предварительном телефонном интервью я не знаю, но там цифры еще больше.
4) Не взять годного кандидата не так страшно, как нанять негодного. Стоимость увольнения человека измеряется сотнями тысяч долларов.
5) Системы у больших компаний большие, сложные и уникальные. Языков много и они меняются. Поэтому важно не владение конкретным стеком, а способность учить новое.
6) Компании ищут не специалиста который будет контрибутить здесь и сейчас, а того кто дорастет по Senior Engineer'а в перспективе 3 лет. Если человек уже Senior, то смотрят чтоб он мог взять на себя проект через годик-другой.
Вот и получается, что нужно максимально быстро отсеять негодных кандидатов. Конечно процесс не идеален. И некоторое количество нормальных кандидатов отсеятся тоже. Спрашивать надо стандартизованным критериям. На каком языке человек писал до этого не важно. Любой мейнстримный сойдет для собеседования (С, С++, C#, Java, JavaScript). Причем интервьюер этого языка может и не знать.
Поэтому собеседование по индивидуальному плану в этот процесс не вписываются. Нужно не искать уникальные самородки, а просеивать тонны руды.
Каждый раунд собеседования 30 минут + 10 мин на представиться и ответить на вопросы.
Оценка кандидата идет по чек-листу.
( ) Уточнил задание перед тем как начать код писать.
( ) Уточнил граничные условия.
( ) Расказал алгоритм.
( ) Посчитал алгоритмическую сложность.
( ) указал на компромис память vs время.
( ) Указал как будет тестировать и привел тест кейсы.
( ) Успел модифицировать задачу под усложненные условия.
( ) Внятно озвучил процесс принятия решений и возможные варианты.
( ) Упомянул другие возможные алгоритмы и подходы. Их плюсы и минусы.
И так далее.
Смотрите на этот процесс с точки зрения инженера. Этот процесс - результат решения задачи оптимизации по многим параметрам.
А почему не использовать для отбора кандидатов обычные онлайн-контесты с теми же задачками?
А как защитится от того что их будут решать другие люди за кандидата? Онлайн хоть какая-то гарантия что человек сам код пишет.
А как на "Лидерах России" этот вопрос решают? Устраивают очную перепроверку для тех, кто пройдет многоступенчатый онлайн-отбор. Там-то кандидатов куда больше, чем на вакансии "Яндекса".
Не надо ставить в пример всякие гос убожества. Там решают просто. Берут только своих на все доходные места. Как отобрать своих это другая задача. Яндекс и другие технологические корпорации пытаются отобрать профессионалов в отличии от этих.
"Лидеры" - это не конкурс на "доходные места". Это просто конкурс. Поэтому никаких "своих" там нет и пробиться туда можно только одним способом - решив все тесты самостоятельно. Отбор там очень грамотно организован и полностью автоматизирован, так что влияние человеческого фактора отсутствует. Упомянутой "большой конторе" следовало бы взять этот опыт на вооружение (имхо).
Это именно способ занять своими все доходные места. Не своих я на таких местах давно не видел. Профессионализм не являтся критерием отбора. Случайности бывают и свои тоже оказываются профессионалами, но это просто так получилось а не целевая задача системы.
Автоматизирован, это списочек победителей в Эксельке заранее подкладыватся в систему?
Большая контора умрет от такого отбора очень быстро. Когда нет безлимитных денег приходится профессионалов нанимать. Чтобы деньги зарабатывать.
Наверное, я, обычный провинциальный доцент, должна причислить себя к мифическим "своим", раз прошла все этапы отбора на "Лидерах". Только "доходных мест" в моем резюме после этого что-то не прибавилось, так что приходится продолжать штурмовать систему отбора кандидатов в "Яндексе", описанную в посте.
Потому что не то важно, решил кандидат задачу или не решил. А важно, как он за нее брался и сам процесс решения. Поэтому онлайн-контесты заменяют только первичное телефонное интервью. И это используется. По крайней мере Майкрософт их использует параллельно с остальными способами.
Мало того, и в Гугле, и в ФБ вы получите доп очки за честность, если скажете, что решали точно такую задачу несколько дней назад и просто помните все рассуждения. В этом случае интервьюер может задачу поменять. Это от того, что процесс достижения результата важнее чем сам результат. Поэтому все споры на тему: "я все правильно решил, а меня не взяли" - это ни о чем.
1) Надо не тратить много ресурсов на сам найм
И поэтому они делают многоступенчатые собесы? По-моему, наоборот, надо как-то отсеять 95% соискателей и они вынуждены тратить время сотрудников на это.
4) .... Стоимость увольнения человека измеряется сотнями тыся долларов.
М.... Обоснуй цифру. Откуда там сотни тысяч?
Так вы предлагайте как отсеять! Только чтоб там не было читерства, дискриминации и удавалось нанимать тысячи инженеров в год. Сейчас многоступенчатый собес. На каждой ступени вас могут отсеять. Первый этап отсева телефонное интервью.
Цифру? Да просто все. Базовая ЗП инженера от 130 до 200 тыс в год. Стоимость его рабочего места и прочие накладные расходы дополнительно от 50% до 100% этой суммы. Процедура увольнения прописана в политиках компании. Если причина в том, что человек "не вывозит", то это процедура долгая и многостадийная. Сначала дать человеку время освоиться (неск месяцев), потом ставить ему задачи с четкими сроками и регистрировать как задачи, так и успехи. Потом первая полугодовая оценка и предупреждение. Через месяца 3 еще одна оценка и наконеч увольнение. Т.е. от 6 до 9 месяцев бесполезного персонажа, а вся команда еще и будет тратить время на его обучение. Если уволить быстро не оформляя бумажек, может кончится судом против компании.
tl;dr Позвали на собес, сказали решить задачку в непонятном редакторе, решение интервьюеру не понравилось
Как по мне - обычное дело. Очевидно, что в Яндексе повышенные требования из-за количества единорогов, поэтому не вижу смысла чего-то обсуждать.
Если говорить о собеседованиях, то Яндекс определенно компания для студентов-олимпиадников. Вообще на тему яндекса написано много статей, и даже есть несколько на хабре. Ключевых моментов я вижу два: Яндекс собеседует всех подряд в потоке, видимо, для составления своей базы. При этом подходящей открытой вакансии может и не быть вовсе. И основная сфера Яндекса всё же давно не IT, а услуги. Более того, на сколько я понял, все интересные для разработчиков-инженеров проекты в яндексе после дробления пошли своим путем, вне яндекса(?). Тем не менее компания остаётся весьма хайповой.
Как бывший клиент яндекса добавлю, что за всё время пользования сервисами сталкивался только с негативом: яндекс убил сервис народ, которым я пользовался, яндекс 2 раза слил мои персональные данные, яндекс слил мой аккаунт яндекс.деньги сбербанку без моего согласия, яндекс заблокировали мой почтовый аккаунт и вымогал паспортные данные с биометрией (фото лица) для разблокировки. И договорится так и не получилось, тех. поддержке было просто пофиг. В яндекс.такси часто сумма списания не соответствовала сумме у водителя. А еще под разными аккаунтам цена поездки отличалась. Почему? Никто не считает нужным объяснить. Я плачу деньги и получаю нулевую прозрачность, и это во вроде бы прогрессивной компании?
У Яндекса всегда стоит задача отсева, а не найма. Это надо понимать, когда они приходят. Есть исключения по знакомству, но они редки и там всё равно будут делать мозг, просто не так сильно и с поправкой на здравый смысл.
Согласен с теми кто считает что проблема именно в том что автор с лёгкостью пишет какойто сжатый обфусцированный код. Ему и дали неряшливый начальный какой-то пример и блокнот чтобы он показал просто спокойные навыки организации кода. А не чудеса c++ выражений в одну строчку. А если бы ещё и сходу алгоритм распевали то совсем хорошо. Мы не Яндекс но когда разрабов смотрим тоже больше смотрим на знание методики а не хардкора. И раз человек метит в такие компании как Яндекс, лучше урок из своего провала извлечь, а не жаловаться на собеседующего.
Этот "обфусцированный код", точнее, одна строчка цикла может быть разложена на два простейших "for()". Какой-нибудь нагруженный transform из новейших плюсов разложится куда как на большее количество компонент.
Яндекс компания без процесса, иначе бы об его методологии там бы известно. Все достижения компании - на основе выдающихся умов. Бизнес модель имеет право на существование, так делался Windows NT в параллель с правильным Windows 95. Но ... долгий разговор.
По кейзу, типа, резюме. Помню в шахматном спортивном лагере раз тренер пришел буквально с авоськой спичечных коробков, расставил их на досках - играйте. И ничего так. Интервьюер мало того, что оказался не коробочником и поставил 5:3 на часах, так еще присудил себе победу в миттельшпиле :)
Предлагаю перенять следующий принцип:
1) нанимают вас а не вы!
2) нанимающий спрашивает что хочет и как хочет, будьте к этому готовы (про собеседования в Яндекс куча инфы)
3) Если вам что-то не нравиться на этапе собеседования вы также можете отказаться!
Когда придерживаешься такой философии то с каждым собеседованием становишься лучше и узнаешь что-то новое, а не негативишь говоря "они все плохие". В гугле, амазоне и тд - везде так, спрашивают потому, что могут позволить себе и потому, что это дает хороший результат в их случае!
Стрёмное собеседование в Яндекс