Комментарии 34
- typedef вместо using;
- фиксированный char[] вместо std::string (в данном случае на всяких cnt, tens и т.д. скорее всего SSO сработает);
- malloc вместо new;
- использование C заголовков, а не C++ (например math.h, а не cmath);
- если уж было желание использовать scanf / printf, то нужно применять cstdint (а не typedef'ить до ll, что вообще не читаемо) и PRIxN / SCNxN из cinttypes;
и так далее.
Судя по конструкциям типа sys.stdin.readline() и std::cin.sync_with_stdio(false) — это код от любителей хардкорных контестов с жесткими лимитами)
PS. А на фото Ваня?
А на фото Ваня?
Да, это ivan_puzyrevskiy.
По опыту собеседований в FAANG и сайтов типа hackerrank ваши задачи, особенно первая, слишком перегружены предметной областью. Нужно реально много времени чтобы даже просто прочитать условие. Описание должно быть короткое, некий кейс, откуда человек должен понять класс задачи (BFS, LCS, permutations and etc.) и успешно применить теорию в виде кода. Зачем мне, как соискателю, тонна информации про Васю-Петю-Машу?
UPD для минусующих сотрудников Яндекса: против Яндекса ничего не имею и даже наоборот, однако не смог удержать при себе свое ИМХО
Спасибо! Кстати, я собеседовался в Яндекс (в Новосибирске), примерно во времена написания тех статей, лет 8-10 назад. Не взяли)) Я действительно рад, что в нашей стране есть компания такого уровня, но вот по форме собеседований… Лично мое мнение, способность быстро проводить собеседования — это круто. Да, Яндекс может себе позволить проводить 5-и часовое собеседование (у меня было так) с задачами, специфичные алгоритмы, детали устройства ОС (Рихтер отдыхает) и процессоров. Нереальный объём информации. В мире есть немало компаний, тоже весьма высокотехнологичных и успешных, которые «мучают» на собеседовании гораздо меньше. Т.е. они каким-то образом смогли сделать более эффективный «экспресс-тест».
может для того чтобы проверить насколько вы хороши в бизнес-анализе? мне в иностранную компанию попалось задние рассчитать систему зеркал для аттракционов :D:D:D
Если выкинуть «литературу», то учебники похудеют в половину.
Это может показаться немного странным, но, с другой стороны, все полученные методы и алгоритмы решении сразу оказываются привязаны к тем или иным конкретным жизненным «бизнес-кейсам».
начал читать про ингредиенты и пустил скупую мужскую слезу — всё это делал когда писал систему управления бизнесом для мороженого — автоматический расчёт себестоимости, рецептур… а потом поймал себя на мысли что быстрее других я бы эту задачу всё равно не решил
Пока читал первую задачу, в голове возникла мысль "к черту все, пойду в проститутки".
Имхо, надо или читать в условии математическую абстракцию, или прикладную задачу, потому что це итое рецептов на эн итое друзей это такая себе постановка условия, на мой взгляд.
Имеют мало общего с реальностью к примеру?) Как та картинка — "спрашивают про красно-чёрные деревья, а на деле править конфиги докера") Суть та же)
Ну и конечно, на собеседованиях ещё спрашивают что-то про знание языка. И в конце концов на собеседовании уже в команду (а не в весь Яндекс в принципе) обсуждаются реальные задачи, которыми придётся заниматься.
А что есть чуть более сложные задачки? На ваших собеседованиях на секциях алгоритмов не чуть более сложны практические задачи, а обычные задачки с олимпиадного программирования.
Или вот никогда не понимал такое. В чём сложность в каждой команде или в группе команд иметь человека который супер-пупер в алгоритмах? Т.е. если появляются такие задачи сразу идти к нему и он выдаст наиболее качественно решение за короткое время.
Т.е. искать людей по специализации: хороший бекенд, фронтенд, мобильный разраб, алгоритмист-математик.
В наше время доступной информации очень сложно на практике сделать откровенно хреновый алгоритм если он известен(он либо встроен куда-то, либо гуглится), а если не известен — вот для этого и будет специальный человек.
По той же причине, почему редко один человек делает одновременно бекенд и мобильную разработку, одновременно iOS и Андроид, или занимается одновременно hardware и раскрашиванием кнопочек на UI.
Алгоритмы — та же специализация.
Смысл в нескольких хороших, если один крутой затмит всех остальных и сделает однозначно лучше? Зачем 5 бекенд разработчиков, которые немного умеют в мобилки. Может лучше плюс пару мобильных разработчиков, которые уже 10 лет этим занимаются? Думаю смысл понятен:)
И программирование и разработка уже не идентичные понятия всё таки.
Разработка это уже не только про "алгоритмы и сложность".
Алгоритмы это всё ещё не специализация. У вас же нет специализации по типам данных, например? Вася пишет код, который работает со строками, Коля — с числами
Понимание алгоритмов, способность оценить их сложность одинаково важна и в бекэнде, и в мобильной разработке, и во фронтэнде. Иначе получаются монстры, которые десятками секунд отрисовывают интерфейс в браузере и высаживают аккумулятор на мобильнике
Надо разделять понятия базовых знаний и специализированных.
Олимпиадные задачки с собеседований — это уже специализированный навык.
А можете ткнуть в то, что делает задачи из поста специализированными? Может, какой-то очень хитрый алгоритм надо разрабатывать или знать? Вроде всё на уровне тех самых базовых знаний, ну ещё требуется способность думать, но это ведь тоже не специализация
Ну кроме как для А — да.
Да в задачах надо разработать хитрые алгоритмы, надо каждый день работать с деревьями, графами, иметь механический опыт алгоритмов gcd/lcm, обхода вершин графа.
Прибавьте в к этому стресс + ограниченность времени.
Способность думать вообще — не специализация, а способность думать в конкретной области — специальный навык.
1. Эти задачки не проверяют ничего, кроме того, что кандидат озадачился литкодом. И да, потом он продолжает перекладывать JSON'ы, только в яндексе.
2. Средний человек видит это, и с очень большой вероятностью сразу думает «ну его к черту».
В одном килограмме 1000 грамм и в одном литре 1000 миллилитров.
А разве бывает как-то по другому? 1024 грамма? О_о
И еще вопрос не дает покоя: это задачи для стажеров,- то есть даже не джунов. А какой смысл спрашивать про чанки или ранжирование выдачи, если стажера ни к тому, ни к другому даже близко не подпустят? Не, ну правда: алгоритмы это прям здорово, но 95% задач (вакансий) в Яндексе этого же не требуют… Зачем тогда?
Понятно, что алгоритмы — это полезная здоровая вещь, и я поддерживаю, что их нужно спрашивать на собеседованиях, но Ваш формат конкретно в данном примере — это оверкилл. На мой взгляд, составителям задач стоит подумать о том насколько понятно и лаконично они пишут описания к задачам и в целом продумывают задачи. Хорошие примеры можно посмотреть на leetcode top 100 liked questions
Где порешать реальные задачи для кандидатов в Яндекc: тренировка на Codeforces и разбор