Комментарии 106
- предварительная секция с рекрутером;
- техническое скайп-интервью;
- несколько очных секций;
- финальные интервью с нанимающими менеджерами.
…
Попробуйте решить все задачи, ни разу не запустив дебаггер; написать решение в Notepad'е без подсветки синтаксиса
Выесть мозг на собеседовании и продемонстрировать на хабре пустой череп уже стало почти традицией. Как вы оцениваете сроки (минимальное и среднее значения), за который можно получить оффер от яндекса?
От первого телефонного разговора с рекрутёром до получения оффера в моём случае прошло почти 3 месяца. Но там были новогодние праздники, в которые я штудировал алгоритмы :)
Можно было и быстрее всё провернуть, но я не торопился и проходил по одной секции в неделю в комфортном для меня режиме.
На самом деле всё не так страшно, как кажется. Но, да, требования к кандидатам высокие.
Можно было и быстрее всё провернуть, но я не торопился и проходил по одной секции в неделю в комфортном для меня режиме.
На самом деле всё не так страшно, как кажется. Но, да, требования к кандидатам высокие.
у меня «несколько очных секций» (по очереди, в один день) и «финальные интервью с нанимающими менеджерами» выпало в одну рабочую неделю. Полный процесс от «привет я рекрутер» до «вот твое рабочее место» занял меньше 4 месяцев, но его сильно затянула релокация
Полным аналогом подобных собеседований для разработчиков является прохождение IQ тестов для любой другой специальности. Когда-то это даже было популярно. Но со временем таки большая часть адекватных людей осознала, что результат прохождения IQ тестов зависит только от того, сколько человек тренировался в прохождении IQ тестов.
Получается забавно — тесты могут хорошо пойти или люди, которые постоянно реально решают алгоритмические задачи, или те кто специально долго к ним готовился.
Если бы нужны были специалисты именно по алгоритмам, я бы мог это понять. Но у яндекса много подразделений, которые занимаются довольно примитивными рутинными задачами. И зачем там специалисты по алгоритмам — непонятно.
И вдвойне забавно выглядит то, что компания фактически признает то, насколько синтетические у неё собеседования — публикуя советы, рекомендуя leetcode и целый сервис «контекст» исключительно для того, чтобы люди могли проходить эти тренировки.
Не, я не спорю — решать алгоритмические задачи весело и интересно. Как и всякие там IQ тесты, тренажёры для мозгов типа luminocity и так далее. Но у меня есть подозрение, что таким образом компания теряет людей, которые действительно занимаются разработкой, и у которых нет времени или желания тренироваться в прохождении синтетических тестов.
Получается забавно — тесты могут хорошо пойти или люди, которые постоянно реально решают алгоритмические задачи, или те кто специально долго к ним готовился.
Если бы нужны были специалисты именно по алгоритмам, я бы мог это понять. Но у яндекса много подразделений, которые занимаются довольно примитивными рутинными задачами. И зачем там специалисты по алгоритмам — непонятно.
И вдвойне забавно выглядит то, что компания фактически признает то, насколько синтетические у неё собеседования — публикуя советы, рекомендуя leetcode и целый сервис «контекст» исключительно для того, чтобы люди могли проходить эти тренировки.
Не, я не спорю — решать алгоритмические задачи весело и интересно. Как и всякие там IQ тесты, тренажёры для мозгов типа luminocity и так далее. Но у меня есть подозрение, что таким образом компания теряет людей, которые действительно занимаются разработкой, и у которых нет времени или желания тренироваться в прохождении синтетических тестов.
Компания считает, что навык алгоритмического программирования важен для разработчиков и публикует материалы, позволяющие разработчикам развивать навыки алгоритмического программирования. Что не так в этой позиции?
Я совершенно не согласен с тем, что наши задачи — синтетические. Такой же код постоянно приходится писать для продакшена, каждый день. Нужно уметь использовать циклы, if'ы, иногда рекурсию, ассоциативные массивы; нужно использовать их своевременно и не допускать при этом ошибок. Что из этого не относится к работе разработчика? :)
Ваши аргументы скорее подойдут к задачам-головоломкам, но мы не даём таких задач на алгоритмических секциях.
Я совершенно не согласен с тем, что наши задачи — синтетические. Такой же код постоянно приходится писать для продакшена, каждый день. Нужно уметь использовать циклы, if'ы, иногда рекурсию, ассоциативные массивы; нужно использовать их своевременно и не допускать при этом ошибок. Что из этого не относится к работе разработчика? :)
Ваши аргументы скорее подойдут к задачам-головоломкам, но мы не даём таких задач на алгоритмических секциях.
Наверное, "не так" то, что задачки (под спойлером в статье) с районной олимпиады 9 класса. И закидоны в духе "не пользуясь дебаггером", "без подстветки синтаксиса в блокноте" — тоже напоминают эти школьные соревнования. Замечательные были времена, да.
Эта статья — отличное обоснование, почему не стоит идти в яндекс.
Самое плохое, что она написана не вчерашним студентом, не отошедшим от госов и первой полученной работы, а человеков, который «руководитель службы разработки». Это очень, очень, очень плохо.
> предварительная секция с рекрутером;
Зачем, если вы его мнение ни во что не ставите и далее следует не одна, а целых несколько очных секций?
> техническое скайп-интервью
Зачем? Там дальше НЕСКОЛЬКО очных секций.
> несколько очных секций;
Зачем их несколько? Ваши интервьюоры настолько глупые, что с первого часа не могут понять, с кем общаются? Настолько плохи задачи? Настолько неопытны? Что с ними не так?
> финальные интервью с нанимающими менеджерами.
Ничего не понял. А где были менеджеры во время все предыдущих моментов числом не менее 4-х?
И у вас там секция «Зачем писать код на доске или бумаге». Предлагаю ее сократить, честно написав, что кроме желания поставить кандидата в неудобное положение и самоутвердиться за его счет, никаких других причин у вас не было.
Боже, как выродился Яндекс… Я помню, как походил интервью в 2005 и 2010. Это были прекрасные, красивые, умные встречи. Что у вас там произошло?
Самое плохое, что она написана не вчерашним студентом, не отошедшим от госов и первой полученной работы, а человеков, который «руководитель службы разработки». Это очень, очень, очень плохо.
> предварительная секция с рекрутером;
Зачем, если вы его мнение ни во что не ставите и далее следует не одна, а целых несколько очных секций?
> техническое скайп-интервью
Зачем? Там дальше НЕСКОЛЬКО очных секций.
> несколько очных секций;
Зачем их несколько? Ваши интервьюоры настолько глупые, что с первого часа не могут понять, с кем общаются? Настолько плохи задачи? Настолько неопытны? Что с ними не так?
> финальные интервью с нанимающими менеджерами.
Ничего не понял. А где были менеджеры во время все предыдущих моментов числом не менее 4-х?
И у вас там секция «Зачем писать код на доске или бумаге». Предлагаю ее сократить, честно написав, что кроме желания поставить кандидата в неудобное положение и самоутвердиться за его счет, никаких других причин у вас не было.
Боже, как выродился Яндекс… Я помню, как походил интервью в 2005 и 2010. Это были прекрасные, красивые, умные встречи. Что у вас там произошло?
дак дайте тогда эти задачки человеку в качестве домашнего задания и пусть он решит их дома. для чего вы заставляете страдать людей при прохождении собеседования? это вам кайф что ли доставляет? вы сами пишите, что эти задачки каждый день решает программист, вот и пусть решит дома в спокойствии, а не под дулом автомата. а учитывая какие еще у вас зарплаты, то кому вообще захочется страдать? а если человек захочет пострадать, то почему бы ему не проделать тоже самое в какой нибудь гугл за x5 от той зп что предлагаете вы? в чем ваше конкурентное преимущество то?
Как мобильный разработчик пишу простенький алгоритм 1-2 раза в год, но почти любое собеседование содержить задачку на алгоритм. В результате я трачу свое время на подготовку в мертвой для меня области, и все потому что кто-то в компании считает, что ум == уменее решать задачки на бумаге. Это не так)))
И зачем там специалисты по алгоритмам — непонятно
Найм армии велосипедопереизобретателей естественно не является ключевой целью. По сути от среднего разработчика требуется умение выбирать алгоритм с оптимальной ассимптотикой там, где это может влиять (в яндексе на удивление это много где может влиять). Навык писать код
Представьте себе, что при написании каждого цикла, возникающего в программе, разработчику требуется потратить время на то, чтобы проверить его работоспособность трассировкой;
Ну да, так это и делается. Мы пишем тест, потом код который удовлетворяет этому тесту. Затем следующий тест и так далее. Не понимаю почему вообше это считается какой-то неправильной практикой и нужно обязательно проверить можем ли мы без этого. Так выглдяит обычная разработка. Такой подход не мешает проводить дебаггинг методом пристального взгляда. Хотя и он тоже делается через тесты. Иззолируем проблему в тесте и пытаемся её решить.
Или у вы как-то по-другому в Яндексе код пишете?
Тесты нужно заранее придумать, а их качество зависит от того, насколько разработчик может предугадать проблемные для алгоритма ситуации. Этот же навык проверяется и в ходе алгоритмической секции. Так что тут нет противоречия.
Когда я пишу о проверке с трассировкой, я имею в виду, например, такие ситуации, как off-by-one error в количестве итераций цикла. Да, такую ошибку очень легко установить трассировкой, но намного лучше уметь заметить её просто взглянув на код. Ещё лучше вообще не допустить :)
Когда я пишу о проверке с трассировкой, я имею в виду, например, такие ситуации, как off-by-one error в количестве итераций цикла. Да, такую ошибку очень легко установить трассировкой, но намного лучше уметь заметить её просто взглянув на код. Ещё лучше вообще не допустить :)
Алгоритмическая секция является лишь одной из многих, поэтому у каждого кандидата будет достаточно возможностей для того, чтобы показать свои самые сильные стороны!
Можно ли получить hire, если секция алгоритмов не пройдена, но пройдены все остальные?
Иными словами как и было — собесед длинной с гугловый и похожими требованиями, за зарплату яндекса), только зачем имея нужный бэкграунд идти в яндекс — не понятно.
А в Яндекс по-прежнему очередь из соискателей?
Вообще я тут подумал — очень хорошо, что Яндекс так нанимает. Ведь это означает, что больше хороших разработчиков будут работать в других компаниях, что хорошо для рынка и вообще экосистемы в целом. Можно еще усложнить собеседования, например, ввести физкультурную секцию: 20 раз не подтянулся — no hire.
А можете чуть подробнее описать почему именно эти задачи были выбраны. Были ли они специально подобраны или просто так взяли. Предполагается ли какое-то эталонное решение или как решит так и сойдёт? Особенно интересует последняя задача, она значительно легче решается явно не тем способом, который вы предполагали указывая сложность с логарифмом.
И всё же, на что ориентирован данный подбор задач. Мне лично они показались тривиальными. Самое сложное было заметить что в задаче C числа 32-разрядные а не битные :)
И всё же, на что ориентирован данный подбор задач. Мне лично они показались тривиальными. Самое сложное было заметить что в задаче C числа 32-разрядные а не битные :)
Господа, ваши тесты и критерии оценки их решений зажаты строго в ваши рамки. Иначе как объяснить, что условие задачи из статьи про "скобки" абсолютно не говорит что требуется сделать и что имеем на входе. Эту информацию нужно выяснять где-то отдельно или быть автором задачи из Яндекс?
Disclaimer: Никакого хейта по отношению к Яндексу, их подходу к собеседованиям, конкретным собеседующим у меня нет. Все ниженаписанное — опыт одного человека, который не должен быть обобщен. Мнение сугубо субъективно.
Это не совсем так. Расскажу про мой опыт собеседования в яндекс.
Собеседование по скайпу:
* Начали с ревью «плохого» кода на плюсах. Обсудили отсутствие виртуального деструктора, отсутствие проверки на самого себя в операторе присваивания, deep/shallow copy, сырые/умные указатели.
* Теория алгоритмов и структур данных. Как внутри устроен квиксорт, что в нем и как. Красно-черное дерево, его нутрянка, гарантия балансируемости.
* Три не особо сложных алгоритмических задачки. Про hashmap, про рекурсию что-то, ну и про бинарный поиск.
Я без особых тупняков ответил на всё, у интервьювера претензий не было. На всё про всё ушло 40 минут, и оставшиеся 20 минут мы общались уже на просто технические темы, импровизируя. Дошли до того, как складываются float'ы на уровне битиков.
Итог прохождения скайп-интервью: 1 час, 100% ответов, покрытые темы — знание специфики языка, его темные углы, теория алгоритмов и структур данных, практика алгоритмов и структур данных, глубокие технические моменты.
Приглашение на очную встречу. 3 интервью по часу.
1. Один удаленный собеседующий. Две задачи. Первая — на линал (которого в требованиях к вакансии не было, и который не повторялся). Вторая — на знание стандартного алгоритма (который я знал, но из-за предположения о том, что задача на динамическое программирование, отмёл). Интервьювер почти не задавал наводящих вопросов, на вопросы отвечал сжато.
2. Два собеседующих. Три задачи. Первая — простая, на сортировку подсчетом. Вторую не особо помню, что-то про hashmap. Третья — на циклический буфер, но хитро поданная. Наводящие вопросы задавали, живо обсуждали решение, даже коснулись специфики языка.
3. Два собеседующих. Две задачи. К сожалению, их я забыл, но тоже на алгоритмику.
Итого, 7 задач на алгоритмику. Из них я решил 3.5 (в одной я озвучил решение, но не успел записать), в письме с результатом сообщили, что зачтены были 3.
Итог прохождения очного интервью: 3.5 часа, 50% ответов, покрытие тем — знание линала, знание стандартных алгоритмов и умение их вспомнить в нужный момент, практика алгоритмов и структур данных, совсем чуть-чуть языковой специфики.
Оффера не поступило.
С моей точки зрения, не прошел собеседование я абсолютно справедливо.
Однако, мне осталась непонятной некоторая однобокость: если бы те же 3 секции распределили как «знание языка программирования», «проектирование», «алгоритмы и структуры данных», то вполне возможно, что результаты были бы 80%/80%/50%. А может и нет. В любом случае, не было бы ощущения, что для работы важен только один навык, набиваемый, при желании, за 3 месяца на hackerrank (полноценно выучить плюсы сложнее, чем натренироваться решать задачки).
Что мне понравилось: комплексность скайп-интервью, открытость к диалогу некоторых собеседующих.
Что мне не понравилось: отличные результаты скайп-интервью были использованы только для приглашения на встречу, сами собеседования были однообразны.
Ну и, собственно, почему я пишу этот комментарий. Как мне кажется, процитированный в начале фрагмент, не совсем корректен. Алгоритмическая секция, по крайней мере в моем случае, была если не единственной (если учитывать скайп), то явно стояла во главе угла.
Это не хорошо и не плохо, но на этом, как мне кажется, стоит всё-таки акцентировать внимание.
Disclaimer again: Я не зол и не обижен на Яндекс за то, что я не прошел собеседование. Помимо Яндекса я в то время получил 2 весьма приятных оффера и в Яндекс, если честно, собеседовался из интереса. Это просто опыт одного собеседования, о котором мне захотелось рассказать, не более.
В то же время, алгоритмическая секция с написанием кода — лишь одна из секций, проверяющая минимально необходимые для любого разработчика навыки.
Это не совсем так. Расскажу про мой опыт собеседования в яндекс.
Собеседование по скайпу:
* Начали с ревью «плохого» кода на плюсах. Обсудили отсутствие виртуального деструктора, отсутствие проверки на самого себя в операторе присваивания, deep/shallow copy, сырые/умные указатели.
* Теория алгоритмов и структур данных. Как внутри устроен квиксорт, что в нем и как. Красно-черное дерево, его нутрянка, гарантия балансируемости.
* Три не особо сложных алгоритмических задачки. Про hashmap, про рекурсию что-то, ну и про бинарный поиск.
Я без особых тупняков ответил на всё, у интервьювера претензий не было. На всё про всё ушло 40 минут, и оставшиеся 20 минут мы общались уже на просто технические темы, импровизируя. Дошли до того, как складываются float'ы на уровне битиков.
Итог прохождения скайп-интервью: 1 час, 100% ответов, покрытые темы — знание специфики языка, его темные углы, теория алгоритмов и структур данных, практика алгоритмов и структур данных, глубокие технические моменты.
Приглашение на очную встречу. 3 интервью по часу.
1. Один удаленный собеседующий. Две задачи. Первая — на линал (которого в требованиях к вакансии не было, и который не повторялся). Вторая — на знание стандартного алгоритма (который я знал, но из-за предположения о том, что задача на динамическое программирование, отмёл). Интервьювер почти не задавал наводящих вопросов, на вопросы отвечал сжато.
2. Два собеседующих. Три задачи. Первая — простая, на сортировку подсчетом. Вторую не особо помню, что-то про hashmap. Третья — на циклический буфер, но хитро поданная. Наводящие вопросы задавали, живо обсуждали решение, даже коснулись специфики языка.
3. Два собеседующих. Две задачи. К сожалению, их я забыл, но тоже на алгоритмику.
Итого, 7 задач на алгоритмику. Из них я решил 3.5 (в одной я озвучил решение, но не успел записать), в письме с результатом сообщили, что зачтены были 3.
Итог прохождения очного интервью: 3.5 часа, 50% ответов, покрытие тем — знание линала, знание стандартных алгоритмов и умение их вспомнить в нужный момент, практика алгоритмов и структур данных, совсем чуть-чуть языковой специфики.
Оффера не поступило.
С моей точки зрения, не прошел собеседование я абсолютно справедливо.
Однако, мне осталась непонятной некоторая однобокость: если бы те же 3 секции распределили как «знание языка программирования», «проектирование», «алгоритмы и структуры данных», то вполне возможно, что результаты были бы 80%/80%/50%. А может и нет. В любом случае, не было бы ощущения, что для работы важен только один навык, набиваемый, при желании, за 3 месяца на hackerrank (полноценно выучить плюсы сложнее, чем натренироваться решать задачки).
Что мне понравилось: комплексность скайп-интервью, открытость к диалогу некоторых собеседующих.
Что мне не понравилось: отличные результаты скайп-интервью были использованы только для приглашения на встречу, сами собеседования были однообразны.
Ну и, собственно, почему я пишу этот комментарий. Как мне кажется, процитированный в начале фрагмент, не совсем корректен. Алгоритмическая секция, по крайней мере в моем случае, была если не единственной (если учитывать скайп), то явно стояла во главе угла.
Это не хорошо и не плохо, но на этом, как мне кажется, стоит всё-таки акцентировать внимание.
Disclaimer again: Я не зол и не обижен на Яндекс за то, что я не прошел собеседование. Помимо Яндекса я в то время получил 2 весьма приятных оффера и в Яндекс, если честно, собеседовался из интереса. Это просто опыт одного собеседования, о котором мне захотелось рассказать, не более.
На мой взгляд вообще хороший инженер, коим является разработчик, не тот кто все знает, а тот кто знает что нужно использовать, где посмотреть как и правильно применить. Ну не вспомню я сейчас на вскидку точно как работает квиксорт. Не нужно это сейчас. Есть туча готовых библиотек чтобы не изобретать велосипед. Раньше, в молодости, любил сам все реализовать, но сейчас это просто не нужно. Так же как и многое другое что любят спрашивать на собеседованиях тратя кучу времени и думая что получают какие то ответы.
Так же когда-то, на собеседовании, не смог написать простейший запрос. Хотя дома у меня на эту фигню с созданием реальной БД и заполнением данными ушло не более 5 минут. Выгляде, наверное, идиотом. Забавно что следом устроился в материнскую компанию этой конторы и успешно проработал там 4 года.
Самое классное собеседование в моей жизни было сразу с руководителем и следующим диалогом:
- Хорошо знаешь %среда_разработки%?
- Ммм… хорошо
- Вот и чудненько
Претензий потом не было.
Вот таки да. Имея, ну уж очень богатыйвыстраданный опыт разработки на C++ (см. P. S.) для меня гораздо ценнее не написать очередной велосипед, вероятно с ошибками и не оптимально реализованный и потом его пилить напильником, а использовать как можно больше готовых алгоритмов из STL и Boost. А уже велосипедостроительством заниматься только тогда когда готовый алгоритм не оптимален для нашей задачи, используется в узком месте и мы можем написать лучше.
Где то в альтернативной вселенной есть тактика: нанять группу студентов математиков олимпиадников по программированию на позиции «разработчик исследователь» и через полгода получить только с помощью этих людей эффективно работающий production код. Некоторые в нашей вселенной считают что это будет работать и думают что в их компании это работает, а другие мне потом отписываются, что собеседования в Яндекс по алгоритмической сложности гораздо сложнее чем вся работа которую человек потом выполнял год и никакую новую алгоритмику под задачи ему писать не приходилось потому что всё уже либо написано и велосипеды это плохо либо задачи были совсем из другой области либо проще, а через год человек ушёл в Google, интересно теперь что о них напишет :)
Где то в альтернативной вселенной есть тактика: нанять группу студентов математиков олимпиадников по программированию на позиции «разработчик исследователь» и через полгода получить только с помощью этих людей эффективно работающий production код. Некоторые в нашей вселенной считают что это будет работать и думают что в их компании это работает, а другие мне потом отписываются, что собеседования в Яндекс по алгоритмической сложности гораздо сложнее чем вся работа которую человек потом выполнял год и никакую новую алгоритмику под задачи ему писать не приходилось потому что всё уже либо написано и велосипеды это плохо либо задачи были совсем из другой области либо проще, а через год человек ушёл в Google, интересно теперь что о них напишет :)
P.S.
знание алгоритмов это не только умение их реализовывать (что действительно нужно очень редко), а еще и понимание их назначения и умение выбирать оптимальный, в т.ч. из набора «готовых алгоритмов из STL и Boost».
Ну да, только знание параметров сложности O(x) по памяти и времени выполнения, понимание как оно работает и как примерно реализовано для, например, unordered_set и возможность реализовать это же на бумажке далеко не одно и тоже, а на тестах просят реализовать, хоть и не столь сложное, но от просто логического мышления и оценки сложности это уже уходит далеко в глубины и требует либо сырых указателей либо итераторов, а там либо унынь в плане читабельности либо «много букв». Опять же, когда любой разработчик пишет какой угодно код то обязательно использует инструменты: компилятор, статический анализатор, подсказки среды разработки и т. д. а на бумажке этого всего нет и при оценке ошибок, которых на самом деле нет ибо будет варнинг, ошибка или просто не скомпилируется из-за опечатки (опечатка будет подчёркнута ещё на этапе написания кода) для бумажки (доски) многие моменты будут посчитаны как ошибки.
Когда я обычный текст пишу даже не перечитываю ибо если красным не подчеркнуло значит что всё ок. В общем если есть желание тестировать написание кода то лучше тестировать в среде разработки, а если нужен алгоритм так и надо просить алгоритм решения, а не код реализации 1 в 1 ;)
Когда я обычный текст пишу даже не перечитываю ибо если красным не подчеркнуло значит что всё ок. В общем если есть желание тестировать написание кода то лучше тестировать в среде разработки, а если нужен алгоритм так и надо просить алгоритм решения, а не код реализации 1 в 1 ;)
а на бумажке этого всего нет и при оценке ошибок, которых на самом деле нет ибо будет варнинг, ошибка или просто не скомпилируется из-за опечатки
Вы лихо смешиваете логические ошибки и опечатки. Оценивается умение не допускать первые (тут уже IDE не поможет), а на вторые интервьюер даже смотреть не будет, ну, по крайней мере, не должен.
А что считается логической ошибкой? Вечные ошибки на +-1 постоянно вылизают в production коде, делаются ошибки вида когда условие проверяется сперва >=10, а несколько ниже тоже значение проверяют на > 15 и эта ветка никогда не выполнится и что это логическая ошибка или недоглядели? Статический анализатор о таком предупредит, а в случае интервьюирующего сработает человеческий фактор :)
Доп: спросите Andrey2008 если мне не верите ;) Мне, например, гораздо важнее сотрудник который будет пользоваться хорошим инструментарием и предлагать другой хороший инструментарий чем тот кто умеет на бумажке код писать ибо сферически абстрактные лошади в непараметризованном вакууме очень далеки от хорошо и оптимально работающей незабагованной реализации.
Доп2: опять же, повторюсь, незачем на доске и бумажке писать код, не предназначены эти инструменты для этого, достаточно написать алгоритм. Более того умение абстрагироваться от реализации и продумывать вещи до мелочи или же более укрупнённо очень и очень полезно на практике ;)
Доп: спросите Andrey2008 если мне не верите ;) Мне, например, гораздо важнее сотрудник который будет пользоваться хорошим инструментарием и предлагать другой хороший инструментарий чем тот кто умеет на бумажке код писать ибо сферически абстрактные лошади в непараметризованном вакууме очень далеки от хорошо и оптимально работающей незабагованной реализации.
Доп2: опять же, повторюсь, незачем на доске и бумажке писать код, не предназначены эти инструменты для этого, достаточно написать алгоритм. Более того умение абстрагироваться от реализации и продумывать вещи до мелочи или же более укрупнённо очень и очень полезно на практике ;)
То же самое. Собеседывался на мобильного разработчика.
П.С. Человек который спрашивал по Java на тот момент видмо мало в Яндексе работал (Саша Ефременков), думаю теперь и он по алгаритмам гоняет хД
- Java — Спрашивали действительно про Java. Хотя на вопросы типа сколько байтов весит пустой объект String в Java я ответить не смог. Но тут ладно это java
- Алгоритмы — алгоритмы на листочке
- Андроид — алгоритмы алгоритмы на листочке
- Архитектура — 50% архитектурные вопросы 50% задачка на листочке
П.С. Человек который спрашивал по Java на тот момент видмо мало в Яндексе работал (Саша Ефременков), думаю теперь и он по алгаритмам гоняет хД
Спасибо за контест!
Пришлось поломать голову над задачей F.
Так вышло, что моя имплементация не проходила последний тест — time-limit-exceeded.
Оказалось, что дело в количестве flush'ей.
Стало неожиданностью, что тесты остальных задач не проверяют производительность IO.
Пришлось поломать голову над задачей F.
Так вышло, что моя имплементация не проходила последний тест — time-limit-exceeded.
Оказалось, что дело в количестве flush'ей.
Стало неожиданностью, что тесты остальных задач не проверяют производительность IO.
С другой стороны IO вообще дурной тон на мой взгляд. В олимпиадах школьников в последние годы надо реализовать функцию в которую все данные уже прочитаны и переданы. Или наоборот, для чтения использовать функцию жюри. Почему это хорошо. На условном С++ слишком много манёвра для оптимизаций именно ввода/вывода. Банальная замена потоков на старые добрый scanf/printf может дать эффект. Про магию ускорений на уровне codeforces.com/blog/entry/5217?locale=ru и говорить не приходится. А иногда можно и ещё больше ускорить используя чтения по символу и преобразование в число…
Я так иногда пропихивал (именно это слово) неоптимальный алгоритм именно таким методом.
Я так иногда пропихивал (именно это слово) неоптимальный алгоритм именно таким методом.
Кстати, а в варианте, когда данные подаются через stdin или файл, меряется полное время выполнение программы? Ну то есть время разворачивания всяких питоновских интерпретаторов, jvm сюда входит?
С хорошо продуманными тестами фокус не удастся. Должен быть кейс, который даже при оптимальном IO не выполнится за отведенное время/память при неоптимальном алгоритме.
У вас в задаче F постановочная бага (ну или тест на внимательность, не знаю). В общем она легко решается за n*k, причем решение гораздо легче приведенного тут.
Там достаточно сохранять в массив сколько раз встречается число со входа. А потом вывести в stdout в отсортированном порядке.
Там достаточно сохранять в массив сколько раз встречается число со входа. А потом вывести в stdout в отсортированном порядке.
Псевдокодом примерно так
int array[100] = {0};
read k
for i=1..k
read n
for j = 1..n
read number
array[number]++
for i = 1..100
for j = 1..array[i]
print(i)
скорее вынужденная мера. Сделали бы числа до 10^9 — размер файла раза в 3 увеличивать пришлось с данными. И тогда по времени прочитать не успевали бы.
Забавно, что на Python такой вариант с подсчетом не укладывается по времени в последний тест из 20 (1.1 секунды в среднем выходит в тестах Яндекса, на локальной машине тест с 1024 массива по 10240 элементов проходит за 0.8 секунды в среднем). А на C# укладывается.
ru.stackoverflow.com/questions/927630/%D0%9A%D0%B0%D0%BA-%D0%BE%D1%81%D1%83%D1%89%D0%B5%D1%81%D1%82%D0%B2%D0%B8%D1%82%D1%8C-%D1%81%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D0%B5-k-%D1%81%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D1%81%D0%BF%D0%B8%D1%81%D0%BA%D0%BE%D0%B2
Пробую сейчас по тому принципу, что в статье описан, реализовать на Python, но так как я в нем не особо специалист, чувствую, что займет время.
ru.stackoverflow.com/questions/927630/%D0%9A%D0%B0%D0%BA-%D0%BE%D1%81%D1%83%D1%89%D0%B5%D1%81%D1%82%D0%B2%D0%B8%D1%82%D1%8C-%D1%81%D0%BB%D0%B8%D1%8F%D0%BD%D0%B8%D0%B5-k-%D1%81%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D1%81%D0%BF%D0%B8%D1%81%D0%BA%D0%BE%D0%B2
Пробую сейчас по тому принципу, что в статье описан, реализовать на Python, но так как я в нем не особо специалист, чувствую, что займет время.
Обсуждали недавно на канадском форуме figvam.ca современный стиль программирования, учитывая постоянный вал технологий, языков, фреймверков, сред в текущей работе.
Особенно если контрактник.
Пришли к выводу что происходит вымывание специализаций.
И большинство решает свои задачи гуглением по stackoverflow.
Особенно если контрактник.
Пришли к выводу что происходит вымывание специализаций.
И большинство решает свои задачи гуглением по stackoverflow.
«Реши на листике», «без дебаггера», «с закрытыми глазами», «во время прыжка на парашюте», «верхом на коне». При желании, все эти ситуации можно оправдать и придумать аргументы, почему это важно.
На заре информатики такие финты ушами имели смысл: компьютерное время стоило дорого; подумай четырежды прежде чем компилировать и запускать программу. Инструментов для разработки было немного (или вообще не было). Однако мы живем в 2019 году. Умение пользоваться дебаггером должно приветствоваться. Это упрощает разработку и экономит время.
Если в Яндексе пишут программы, которые постоянно падают в продакшне и нужны исключительно гении-олимпиадники, которые способны поднимать сервера и сервисы одним лишь скользящим взором на ssh-соединение, простыню из кода, панель мониторинга, то тут нужно задуматься о качестве того, что попадает в продакшн.
На заре информатики такие финты ушами имели смысл: компьютерное время стоило дорого; подумай четырежды прежде чем компилировать и запускать программу. Инструментов для разработки было немного (или вообще не было). Однако мы живем в 2019 году. Умение пользоваться дебаггером должно приветствоваться. Это упрощает разработку и экономит время.
Если в Яндексе пишут программы, которые постоянно падают в продакшне и нужны исключительно гении-олимпиадники, которые способны поднимать сервера и сервисы одним лишь скользящим взором на ssh-соединение, простыню из кода, панель мониторинга, то тут нужно задуматься о качестве того, что попадает в продакшн.
Внесу свои пять копеек про собеседования в Яндексе на позицию С++ разработчика. Дело было в далеком 2016 году и, после интервью по скайпу, я был приглашен в офис для очного собеседования.
Из того, что помню, спрашивали:
Офера не получил, но было интересно попробовать.
Из неприятного было то, что они не предлагали оплачиваемую гостиницу, и из-за этого пришлось лететь в 6 утра. Почти не спал тогда и это сказалось на собеседование. Ну и деньги за билеты возвращали месяц. Могли бы уж сами купить.
В принципе, на эти алгоритмические задачки можно просто натренироваться по книжке типа Cracking The Coding Interview, но стоит ли оно того? Ну и видно, что задачки у них типовые и они не подстраиваются под бэкграунд кандидата.
Из того, что помню, спрашивали:
- Написать свой unique_ptr на листе бумаги (да, я каждый день пишу кастомный умный указатель с его двумя специализациями, в каждом из которых по 6-7 конструкторов)
- Написать что-то типа своего LRU кэша на доске. Эта задачка понравилась больше всего, так как интервьюер был живенький и охотно отвечал на уточняющие вопросы.
- Нарисовать и разработать архитектуру распределенного хранилища (самое то для embedded developer'а)
- Какая-то геометрическая задачка про нахождение центра множества точек (точное условие не помню)
Офера не получил, но было интересно попробовать.
Из неприятного было то, что они не предлагали оплачиваемую гостиницу, и из-за этого пришлось лететь в 6 утра. Почти не спал тогда и это сказалось на собеседование. Ну и деньги за билеты возвращали месяц. Могли бы уж сами купить.
В принципе, на эти алгоритмические задачки можно просто натренироваться по книжке типа Cracking The Coding Interview, но стоит ли оно того? Ну и видно, что задачки у них типовые и они не подстраиваются под бэкграунд кандидата.
А можно тупой вопрос от человека, который слишком долго стул грел в тихом омуте и от жизни порядком отстал, ко всем присутствующим — я по тексту так и не понял, задания контекста (за исключением первого) предполагают, что кандидат на какую позицию претендует — джуниор, миддл? Или там, что для Яндекса джуниор, для средней компании на миддла тянет…
P.S. Вообще на мой дилетантский взгляд хабру немного не хватает «тэга-уровня» для материалов по программированию. Может и боян конечно, но часто читаешь что-то типа «С++ страдание» и по прочтении теряешь в догадках — то-ли радоваться, что не имея особого опыта в последние 5 лет в плюсах процентов на 90% автора понял, то-ли рвать волосы от стыда, что человек тебе разжевал всё, а ты проглотить не смог…
P.S. Вообще на мой дилетантский взгляд хабру немного не хватает «тэга-уровня» для материалов по программированию. Может и боян конечно, но часто читаешь что-то типа «С++ страдание» и по прочтении теряешь в догадках — то-ли радоваться, что не имея особого опыта в последние 5 лет в плюсах процентов на 90% автора понял, то-ли рвать волосы от стыда, что человек тебе разжевал всё, а ты проглотить не смог…
Если плана нет, это будет приводить к большому количеству исправлений, зачёркиваний (на бумаге) и переписыванию больших кусков кода.
По своему опыту могу сказать, что умение писать "по плану" является признаком плохого программиста. Это называется Остапа понесло.
Закрыть скобочку, вынести код во внешнюю функцию, зафиксировать интерфейс, написать тестик и только потом продолжить работу — в общем делать много исправлений — признак хорошего. Конечный код выйдет лучше и быстрее.
Разница тут как между нарисовать сову методом scan line, и "итеративным" классическим образом. Можно даже сказать — по agile.
Всё-таки, для меня вся эта ситуация выглядит достаточно сюрреалистично. Сначала выдумать(позаимствовать) собеседования, которые никто(ну, точнее какая-то часть) не может и не хочет проходить. Потом писать посты на хабре, записывать видео, выкладывать примеры задач(короче уговаривать программистов научиться их проходить). А так как эти задачки практического применения почти не имеют(если бы имели, то все бы их умели решать и таких постов от яндекса бы не было), то всё это будет работать по студенческой системе — сдал/забыл.
Часто можно наблюдать ситуацию, когда будущие стажёры легко справляются с алгоритмической секцией, решая все задачи за 15-20 минут, тогда как более опытные программисты на те же задачи тратят целый час.
Вот в том-то все и дело, что опытный программист придет в офис после вашего собеседования и сможет решить бизнес задачу за гораздо меньшее время, нежели человек, который за 15 минут сможет реализовать заученный алгоритм. Я не знаю, может в реалиях Яндекса это работает иначе, но в большинстве обычных компаний требуется уметь именно первое.
В реалиях Яндекса всё тоже самое. Куча узких мест, большие нагрузки, огромная кодовая база и там точно также важно не допускать появления велосипедов поскольку потом их придётся поддерживать.
P.S. Так, например, Антон Полухин из Яндекса пишет свои«велосипеды»реализации того чего нет в Boost и правильно делает :)
P.S. Так, например, Антон Полухин из Яндекса пишет свои
По поводу написания кода на бумаге или доске хотелось бы кое-что сказать.
Да ну, бред какой-то
Однако, этот способ позволяет позволяет проверить два очень важных для каждого разработчика свойства.Свойства эти имеют опосредованное отношение к упражнению:
Первое из них — умение быстро разбираться с работоспособностью кода «на глаз».А может лучше проверять умение разбираться с работоспособностью кода на глаз с помощью просмотра кода?
Второе важное свойство — способность заранее продумывать план решения и затем следовать ему.Интервью как раз про диалог, уточняющие вопросы, создание простого решения, его анализ, затем совершенствование. А тут про какой-то план речь…
В реальной жизни всё это сильно замедляет разработку, но отчасти маскируется скоростью работы в редакторе кодаВзять тот же кодинг-стрим geohot'a: он с практически молниеносной скоростью печати в основном гуглит документацию, возникающие ошибки или примеры кода библиотек. И конечно же код по ходу исправляется и рефачится. Интересно, на анонимном интервью отсеяли бы его? Чувствуется, запросто.
А вы бы лично наняли geohot'а «к себе», причём не как единственную и неповторимую звезду, а в команду?
Очень абстрактный вопрос, ответ зависит от команды и рода ее деятельности. Скорее команда не подойдёт ему (или другому абстрактному известному разработчику), чем он команде :) В моей текущей он почти наверняка бы заскучал — народ в финсекторе чаще из-за денег, а не призвания.
Про задачу А — нигде в условии не сказано что нужно построить наиболее быстрый (линейный) алгоритм. Можно сказать что это «подразумевается», но почему-то зачастую бизнес требует «не как правильней», а «запустить скорее». И тот «программист» который быстро (пусть и криво) хотелки бизнеса делает, в зарплате растет быстрее того, который делает правильно. Обычно получается так, что тот который «правильно», переделывает за тем, который «быстрее». Так что первый решает важные задачи для бизнеса, а второй — устраняет «мелкие» недоделки. И вот такой набор с такими задачами усуглубляет такую ситуацию.
Когда я пишу о проверке с трассировкой, я имею в виду, например, такие ситуации, как off-by-one error в количестве итераций цикла. Да, такую ошибку очень легко установить трассировкой, но намного лучше уметь заметить её просто взглянув на код. Ещё лучше вообще не допустить :)
ashagraev, существуют ли методики (литература на тему) предварительной оценки работоспособности кода до этапа компиляции(например, распознать упомянутую Вами off-by-one error)? Полагаю, что в спортивном программировании подобные практики должны существовать.
Поделюсь своим опытом. Тоже заваливал алгоритмическую секцию в Яндексе, но задачки были посложнее. Вторая требовала выдумать алгоритм Алгоритм Рабина — Карпа. Алгоритм хоть и придумался (даже без наводящих вопросов), но реализовать его не успел.
Это просто рынок найма: в Яндекс стремиться много разработчиков и их нужно как-то отсеивать. Думаю, что в других условиях, если бы на секцию на секцию отводился час — успел бы написать и код.
Это просто рынок найма: в Яндекс стремиться много разработчиков и их нужно как-то отсеивать. Думаю, что в других условиях, если бы на секцию на секцию отводился час — успел бы написать и код.
Пффф… Кто же ходит в Яндекс без знания алгоритма Рабина-Карпа? Это все равно как пойти в лес без корзинки для грибов.
Насчет евроинтервью с вайтбордингом — это нормальная практика, как в иностранных компаниях. Должна же быть в РФ хоть одна компания с евроинтервью. Надо же как-то людей выбирать. А это один из адекватных способов. Берем с запасом, в хозяйстве пригодится. А так придется всех подряд брать.
Сам периодически "тещусь" на этом интервью для проверки программистского здоровья. Еще ни разу не прошел, правда… и таймаут там слишком большой — целых полгода...
К задаче F специально такое неэффективное решение за O(k*log(k)) написали? :) Ее же можно легко решить за O(k)
Я работал в Яндексе около года, могу сказать по своему опыту, что всего лишь пару раз пришлось использовать DFS в реальном коде. Но, Яндекс это большая компания, возможно там есть несколько отделов, где необходимость использования алгоритмов несколько выше.
В целом, как мне кажется, большие IT компании стоят перед задачей найма программистов «потоком», для этого нужен какой-то более-менее стандартизированный метод оценки. Причем этот метод должен по-хорошему основываться на каких-то численных показателях для сравнения кандидатов друг с другом. В то же время, метод оценки программистов по количеству решенных алгоритмических задач не является идеальным. У него большой процент false negative ошибок, когда в целом хорошие программисты сталкиваются с проблемами при реализации чисто алгоритмических задач, а люди с олимпиадным прошлым получают бонус.
Но, при всех своих недостатках этот метод работает. Тот кто решил все задачи с большой долей вероятности является неплохим разработчиком, даже с учетом того что в 95% случаев в работе умение решать такие задачи не требуется.
Критикам алгоритмических задач на собеседовании можно предложить придумать свой вариант метода оценки кандидатов. Допустим у вас есть 100 кандидатов, 10 интервьюеров, каким образом вы бы построили метод оценки? Причем ваш метод по-хорошему должен быть максимально справедливым, т.е исключать человеческий фактор со стороны интервьюера, а так же давать на выходе какие-то числа для сравнения кандидатов друг с другом.
В целом, как мне кажется, большие IT компании стоят перед задачей найма программистов «потоком», для этого нужен какой-то более-менее стандартизированный метод оценки. Причем этот метод должен по-хорошему основываться на каких-то численных показателях для сравнения кандидатов друг с другом. В то же время, метод оценки программистов по количеству решенных алгоритмических задач не является идеальным. У него большой процент false negative ошибок, когда в целом хорошие программисты сталкиваются с проблемами при реализации чисто алгоритмических задач, а люди с олимпиадным прошлым получают бонус.
Но, при всех своих недостатках этот метод работает. Тот кто решил все задачи с большой долей вероятности является неплохим разработчиком, даже с учетом того что в 95% случаев в работе умение решать такие задачи не требуется.
Критикам алгоритмических задач на собеседовании можно предложить придумать свой вариант метода оценки кандидатов. Допустим у вас есть 100 кандидатов, 10 интервьюеров, каким образом вы бы построили метод оценки? Причем ваш метод по-хорошему должен быть максимально справедливым, т.е исключать человеческий фактор со стороны интервьюера, а так же давать на выходе какие-то числа для сравнения кандидатов друг с другом.
Метод работает на большом входящем потоке кандидатов. Ну не наняли из-за false negative хорошего инженера — ничего страшного, за дверьми еще 100500 соискателей стоят, на каком-то хорошем инженере метод сработает. Поэтому выше и спросил про очередь соиcкателей в Яндекс.
Ну и чтобы за дверьми стояли 100500 соискателей нужно либо платить существенно выше рынка (вариант: выделяться нестандартными и очень приятными условиями), либо поддерживать образ «возвышенной исключительности» компании. Собственно, все эти жесткие собеседования и направлены во многом на поддержание такого образа.
Прилетело час назад на почту. В который раз.
Я надеюсь, что в ближайшем будущем ваши спортисты-алгоритмисты всё-таки обратят внимание на борьбу со спамом, которого в Яндекс-Почте за последние месяцы стало на порядки больше. Быть может, вам таки стоит пересмотреть критерии отбора ваших инженеров?
Приветствуем Вас, лучший пользователь крупнейшей почты!
Счастливый день для Вас, вы получили это письмо, т.к. были выбраны лучшим активным пользователем! И в этот день мы организовали для Вас невероятное предложение.
Необходимая подробная информация в приложении к письму.
С уважением,
представитель почтовых компаний
Lars-Erik Jansen
Я надеюсь, что в ближайшем будущем ваши спортисты-алгоритмисты всё-таки обратят внимание на борьбу со спамом, которого в Яндекс-Почте за последние месяцы стало на порядки больше. Быть может, вам таки стоит пересмотреть критерии отбора ваших инженеров?
Медаль будет?
А я с multiset не могу в F влезть :(
сортировка подсчетом
До этого я уже дошел :)
Только тут работа с памятью довольно странная.
Нижнее — multiset из int.
Среднее — удалил пару заголовочных файлов из include.
Верхнее — заменил int на short.
Только тут работа с памятью довольно странная.
Нижнее — multiset из int.
Среднее — удалил пару заголовочных файлов из include.
Верхнее — заменил int на short.
Я делал массив из 100 элементов каждый это short. Бежите по входным массивам и каждый раз инкрементите соотв числу индекс в массиве. Даже все данные читать не надо сразу, хотя я вроде все вычитал в память и все влезло. Ну и потом идёте по массиву и выводите индекс столько раз сколько записано. Могу код скинуть
Напоминает что-то типа карго-культа: сделаем собеседования как в Гугле и Амазоне, станем такими же успешными как они.
Яндекс может себе позволить такие собеседования — потому что вцелом к ним идут много кандидатов, а небольшая компания особенно в регионе — нет. И мое мнение — не стоит всем работодателям стремиться к таким собеседованием.
Грустно, когда на java нельзя задать параметры запуска и при этом ограничение памяти 20 Мб. У меня выделения памяти вообще нет, но решение D не укладывается никак.
Лично мне яндексовые интервью кажутся крайне простыми. Алгоритмическая секция дак совсем, хотя ею очень сильно пугают HR'ы. Последний раз неторопясь написал 2 задачи за ~35 минут, третей задачи вообще сказали не будет. Все ждал чего-нибудь действительно крутого алгоритмического, а в итоге задачки просто на адекватность, кругозор и умение писать чистый код.
По моим ощущениям, это очень слабый способ проводить интервью. Как для компании, которой бы хотелось нанимать лучших из лучших, олимпиадников — очень низкий порог входа. Думаю, любой вчерашний студент может попасть в Яндекс после пары недель подготовки. А на технические навыки и знания вообще никто не проверяет. Даже на финальном/систем дизайн собеседовании.
Впрочем, зарплаты соответствующие.
По моим ощущениям, это очень слабый способ проводить интервью. Как для компании, которой бы хотелось нанимать лучших из лучших, олимпиадников — очень низкий порог входа. Думаю, любой вчерашний студент может попасть в Яндекс после пары недель подготовки. А на технические навыки и знания вообще никто не проверяет. Даже на финальном/систем дизайн собеседовании.
Впрочем, зарплаты соответствующие.
Можно поинтересоваться сколько вам лет и каков опыт разработки?
31. Пишу системный софт. А что?
Обычно всякие алгоритмические штуки легко решаются сразу после учебы. Потом мозги начинают деревенеть и затачиваться под практические нужды. Примерно в том же возрасте как то наткнулся на задачку, которые с легкостью щелкал в студенчестве и сразу после, а спустя годы она меня сначала поставила в тупик. Чувствую, что решение знаю, но тем не менее оно от меня ускользало. Потому терпеть не могу всякие тесты на собесах. Как уже писал, например, алгоритм быстрой сортировки помню приблизительно, т.к. мне это не пригодится, потому как реализовывать его ручками нет необходимости.
Решил все задачи, кроме одной «D. Генерация скобочных последовательностей», проверка затыкается на 7-м тесте с ошибкой «WA». Это очень странно, потому что задача имеет всего один параметр с допустимыми значениями от 0 до 11, а алгоритм там один и примитивный. Уж если он правильно сработал на шести числах, странно что заткнулся на седьмом.
В задаче непонятны краевые решения. Что должно возвращаться при параметре 0? У меня программа просто завершает работу, а что нужно?
Я даже сгенерил все возможные строки для каждого варианта параметра 0...11, то есть, самый неэффективный вариант, отфильтровал их согласно заданию и отсортировал их. И сравнил с тем что выдает программа — все один в один.
Видимо, никогда не узнаю в чем была проблема. Времени разбираться нет, надо работать.
В задаче непонятны краевые решения. Что должно возвращаться при параметре 0? У меня программа просто завершает работу, а что нужно?
Я даже сгенерил все возможные строки для каждого варианта параметра 0...11, то есть, самый неэффективный вариант, отфильтровал их согласно заданию и отсортировал их. И сравнил с тем что выдает программа — все один в один.
Видимо, никогда не узнаю в чем была проблема. Времени разбираться нет, надо работать.
Зашел я Яндекс.Контест, задача с камнями и украшениями. Попробовал вставить свое решение с Литкода, оно самое быстрое из возможных. Но очень удивился тому, что у вас Mono версия C#, которая вопервых сильно отстает от .Net Core, во вторых не содержит даже полноценных языковых конструкций, типа Span или MemoryCast. На литкоде например используется .Net Core и вам следует убрать этот моно.
Не очень понятно, зачем люди ломятся в Яндекс. Зарплата плюсового кодера в Новосибирске 170 тыр, то есть меньше чем на удаленке.
Скажите, пожалуйста, задача C. на Golang точно выполнима?
Максимум, что мне удалось, это 1 секунда + 5.48Mb памяти ОЗУ.
Там упирается в I/O, я использовал fmt.Scanln() и fmt.Println() для ввода и вывода соответственно.
Пробовал буферизацию, пробовал значения сразу в строки получать.
Читать из файла не пробовал, т.к. я в первой задаче сразу начал с файлового ввода/вывода и получил "RE".
Вполне. Я сейчас написал вот так и зашло с очень хорошим запасом:
package main
import (
"bufio"
"fmt"
"os"
"strconv"
)
func main() {
scanner := bufio.NewScanner(os.Stdin)
last := 0
scanner.Scan()
count, _ := strconv.Atoi(scanner.Text())
for i := 0; i < count; i++ {
scanner.Scan()
current, _ := strconv.Atoi(scanner.Text())
if i == 0 || last != current {
fmt.Println(current)
}
last = current
}
}
Какая то у всех нездоровая фокусировка на Литкоде или это чтобы кандидату легче было по офферу торговаться? Только я не уверен, что Яндекс способен перебить оффер от Google или Facebook, да и многострадальный Microsoft вряд-ли…
Второе важное свойство — способность заранее продумывать план решения и затем следовать ему. Если плана нет, это будет приводить к большому количеству исправлений, зачёркиваний (на бумаге) и переписыванию больших кусков кода. В реальной жизни всё это сильно замедляет разработку, но отчасти маскируется скоростью работы в редакторе кода. Доска и бумага в этом смысле являются беспощадными поверхностями.
Вы не забывайте, что программист - это не 100% инженер. Это инженер-художник. А художникам (писателям и другим творчетким личностям) свойственно зачеркивать целые главы совей работы, делать из этого комок и отправлять в мусорку.
Одна из "фишек" Яндекса при приёме на работу программистов — "алгоритмические секции" — нужно в сжатые сроки решить нетривиальные алгоритмические задачи на листочке.
Когда-то давно я тоже собеседовался в Яндекс (и даже не один раз) и меня не взяли, как раз таки поскольку не проходил эти "алгоритмические секции".
(Может быть и правильно что не взяли, поскольку стал потом сооснователем одной из известных IT-команий в РФ.)
Встречал также отзывы на хабре, что некоторых людей вообще ни о чём другом не спрашивали (ни об опыте работы, ни о технологиях), только давали несколько сессий этих пресловутых "алгоритмических секций" подряд, потом отказ.
Почему-то Яндекс хранит этот метод собеседования как какую-то святую скрепу, пронеся её через года:
https://edaacademy.ru/web_huawei
При этом, моё мнение:
1. Программистам в реальной жизни довольно редко требуется решать алгоритмические задачи, а если и требуется, то довольно простые. Практически всё основное уже "придумано до нас" и этим нужно только уметь пользоваться.
2. Выставляя этот "алгоритмический" критерий как основной, Яндекс теряет много ценных потенциальных сотрудников.
3. Данный критерий вообще мало релевантен для определения хорошего программиста.
Равно как я очень скептически отношусь ко всякому "спортивному программированию", где на скорость люди решают какие-то полуматематические задачи — поскольку это совсем не те навыки, которые нужны программистам в реальной жизни и в реальной работе. Это какая-то "параллельная вселенная".
Это как "танец с саблями" имеет отдалённое отношение к реальному бою на саблях.
Люди, которые хотят устроится в компании с подобными требованиями, специально прокачивают свои "алгоритмические" скилы на всяких leetcode.com.
А потом, после похождения собеседований, успешно их забывают.
Почему эти "алгоритмические задачки" вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — мне неведомо.
Как будто бы работа программиста только и заключается в том, что надо каждый день перепридумывать алгоритм быстрой сортировки или алгоритм сжатия без потерь.
Считаю, вообще этим должны заниматься математики, а не инженеры....
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как проходят алгоритмические секции на собеседованиях в Яндекс