Comments 29
Я закончил бакалавриат по математической специальности связанной с программированием в 2018 году. В университете были пары по алгоритмам, а так же я принимал участие в дополнительных занятия по олимпиадному программированию в одном семестре на первом курсе.
Думаю, это тоже стоит добавить в конце статьи к тем 35 долларам и рутинной работе в течение полутора месяцев.
За саму статью спасибо. Всегда интереснее читать про реальный опыт.
Интересно как прошло собеседование по системному дизайну, с учетом 4 лет опыта.
есть замечательная книга Alex Xu System Design Interview. Там разобраны несколько более-менее реальных кейсов без огромного количества воды.
Я, честно говоря, не знаю как оценить себя. Мне показалось, что задачу я в целом решил, после интервью, конечно, пришло еще много мыслей, как можно было бы сделать лучше.
В целом имелся опыт принятия архитектурных решений, пара прочитанных книг и множество статей. Безусловно это не сравнится с 10+ реального опыта :)
А где еще самый главный пункт в списке "За это лишь надо "? - английский N лет.
Желающим повторить стоит посмотреть ещё тг-чатик «Время Валеры», в котором Бабушкин рассказывает помимо прочего про грейды, систем дизайн и все то, что может на интервью пригодиться
я занимался enterprise разработкой в различных российских компаниях, где не притрагивался к алгоритмам
Надо полагать, и на новой работе Вы так же не будете притрагиваться к алгоритмам.
Я вот когда не знал алгоритмы, то тоже думал, что они нигде не встречаются. А потом после того как в течение нескольких лет серьезно в них погрузился и прокачался с удивлением обнаружил, что они встречаются везде и повсюду. 🤣 по мне так изучение алгоритмов и структур данных - чуть ли не лучшая инвестиция своего времени для разработчика
О, да )
А как сложно работать с ребятами, для которых все эти алгоритмы - пустой звук и любое простейшее действие превращается в увлекательное приключение.
В общем, добрый совет работать над алгоритмами 👍
Вы абсолютно правы, просто я довольно неудачно выразил свою мысль.
Я хотел сказать, что такие интервью (реализация известных алгоритмов) проверяют исключительно то, что кандидат достаточно сильно хочет получить работу в FAANG, чтобы потратить полтора месяца своего время на подготовку к этому интервью. Прохождение таких интервью ничего не говорит о том, способен ли кандидат выполнять реальные задачи в данной компании, равно как и провал на таких интервью не говорит о неспособности кандидата выполнять реальные задачи и даже не говорит о том, что он плохо знает алгоритмы и структуры данных!
Безусловно, знание алгоритмов и структур данных - необходимо любому квалифицированному разработчику, но это не делает разработчика квалифицированным само по себе. И знать их необходимо вовсе не на уровне "разбудите меня ночью и я легко напишу реализацию quick sort, назову её асимптотическую сложность, отличия от merge sort, и дам рекомендацию который из алгоритмов лучше подходит в конкретном частном случае".
Да, на этот счет есть много мнений. Многие считают также как и вы.
Но лично я не согласен. Причем мне кажется вы себе противоречите немного.
>> проверяют исключительно то, что кандидат достаточно сильно хочет получить работу в FAANG
не соглашусь, что исключительно это, но само по себе то, что соискатель готов потратить 1,5 мес на подготовку говорит о его мотивации - а это уже немало
также это говорит об умении учится и о том насколько его мозги заточены на решение подобных задач
уверяю вас, что человек, который не имеет особого аналитического/математического склада ума никогда не осилит подготовку к таким интервью. Заучивание будет легко расколото интервьювером.
>> Прохождение таких интервью ничего не говорит о том, способен ли кандидат выполнять реальные задачи в данной компании
как так? если вы согласны со мной что подобные задачи встречаются часто в работе, то значит прохождение таких интервью прямо вот тестирует это.
>> и даже не говорит о том, что он плохо знает алгоритмы и структуры данных!
тут я вообще не понимаю вас! тестирование на DSA ничего не говорит насколько кандидат владеет DSA???
>> И знать их необходимо вовсе не на уровне "разбудите меня ночью и я легко напишу реализацию quick sort, назову её асимптотическую сложность, отличия от merge sort, и дам рекомендацию который из алгоритмов лучше подходит в конкретном частном случае".
вы так говорите, как будто это что-то сложное
это опять из той же серии - если вы не знаете DSA, то вам кажется что их нигде нет и пользы от них никакой. Но вы себе не представляете сколько я видел проблем из-за того, что разработчики не владеют базовыми DSA. Реальный пример: реализация загрузки ФИАС 20 минут против 50 часов. И это не мелочь и не прихоть разработчика олимпиадника, тк просто на два порядка снижает затраты на оборудование и на эксплуатацию.
Никаких противоречий тут нет. Да, алгоритмы везде, но в ежедневной работе множество других вещей оказываются намного важнее. Ситуации, когда перед линейным разработчиком стоит задача, которую можно сделать либо эффективно и корректно если знать нужный алгоритм либо кое-как пытаясь самостоятельно изобрести неполноценную версию такого алгоритма - крайне редки. А, главное, чтобы правильно сделать такую задачу необходимо и достаточно знать о существовании данного алгоритма в принципе - это позволит его нагуглить или спросить у коллег вместо того, чтобы изобретать свою корявую версию.
Изучение алгоритмов и структур данных необходимо как раз для того, чтобы во-первых знать о существовании разных алгоритмов, и во-вторых уметь определять уместность использования конкретного алгоритма в текущей задаче. Необходимости уметь самостоятельно, корректно и эффективно реализовывать все алгоритмы - в абсолютном большинстве случаев нет, потому что есть готовые реализации.
также это говорит об умении учится и о том насколько его мозги заточены на решение подобных задач
Мы ведь не говорим тут о стажёрах, верно? А для состоявшихся разработчиков "об умении учиться" говорит уже то, что они пару лет уже где-то проработали разработчиком.
А вот что касается "мозги заточены на решение подобных задач" - проблема как раз в том, что именно "подобных" задач в ежедневной работе эти разработчики делать не будут.
Заучивание будет легко расколото интервьювером.
Я в этом сильно сомневаюсь, но это не важно.
если вы согласны со мной что подобные задачи встречаются часто в работе
Нет. Я согласен в том, что алгоритмы нас окружают везде, и на большинство задач можно посмотреть под таким углом, чтобы увидеть в ней несколько распространённых алгоритмов. И изредка такой взгляд даже позволит решить задачу лучше. Но для качественного выполнения абсолютного большинства задач это не требуется, поэтому с формулировкой "подобные задачи встречаются часто" я не согласен.
> провал на таких интервью ... даже не говорит о том, что он плохо знает алгоритмы и структуры данных!
тут я вообще не понимаю вас! тестирование на DSA ничего не говорит насколько кандидат владеет DSA???
Я такого не говорил. Если перефразировать, то я сказал, что если на интервью кандидат не напишет реализацию quick sort, то это не значит, что он недостаточно хорошо (для выполнения реальных задач) знает алгоритмы сортировки. Потому что для реальных задач достаточно в принципе знать о том, что алгоритмы сортировки бывают разные, зачем они такие разные нужны, и как называются самые популярные - всё остальное гуглится.
вы так говорите, как будто это что-то сложное
Нет, не сложное. Просто ненужное. Голова не резиновая, и если она забита этими мелкими подробностями, то скорее всего что-то более важное будет упущено.
А, главное, чтобы правильно сделать такую задачу необходимо и достаточно знать о существовании данного алгоритма в принципе — это позволит его нагуглить или спросить у коллег вместо того, чтобы изобретать свою корявую версию.
Ну вот знаете вы, что есть "динамическое программирование". Как его применить-то к задаче? Там каждая задача — свой собственный мир. Даже зная принцип ДП без опыта именно решения задач будет очень сложно придумать, что взять за параметры и составить рекуррентное соотношение.
Да, алгоритмы везде, но в ежедневной работе множество других вещей оказываются намного важнее
Я считаю, что если человек может пройти алгоритмическое интервью, то практически все задачи в ежедневной работе ему по плечу. Код писать он точно умеет. Мысли в код переводить тоже. Джсоны перекладывать точно сможет. Для дизайна архитектуры (это уже более высокий уровень) есть отдельное интервью. Что там еще остается? Знание каких-то конкретных фреймворков — вообще не нужны, потому что в ФААНГах все свое доморощенное (часто потому, что оно появилось лет на 2-5 раньше этих модных фремворков). Взаимодействие в команде? Для этого сейчас есть отдельное поведенческое интервью (я, правда, считаю что они не работают), но и без этого менеджеры могут все разрулить обычно. Да и процесс разработки классно составлен, что хочешь-не-хочешь, а будешь нормально в команде взаимодействовать. Да и за ФААНГавскую зарплату даже полный социопат может и попридержать язык за зубами. Поведение можно всегда скорректировать, а вот научить человека алгоритмическому мышлению — не всегда.
проблема как раз в том, что именно "подобных" задач в ежедневной работе эти разработчики делать не будут.
Нет. Я на интервью в гугл даю именно ту задачу, которую сам лично писал и коммитил в прод. Чуть-чуть упрощенную и отчищенную от деталей, чтобы упрастить, конечно. И всякие moving-window-max, линейную регрессию, динамическое программирование, хитро сплетенные списки и похожего уровня вещи приходилось писать. Не каждый день, разумеется. Но раз в пару месяцев задача встает. Все-таки гугл занимается чем-то большим, чем сайт-визитка. Там много всякого интересного и фундаментального и кроме рисования формочек и перекладывание протобуфов (местные джсоны) есть более интеллектуальные задачи. И это право гугла выбирать себе тех, кто с этими задачами справится.
если на интервью кандидат не напишет реализацию quick sort, то это не значит, что он недостаточно хорошо (для выполнения реальных задач) знает алгоритмы сортировки.
Обычно на интервью не ждут от кандидата реализации quick sort. Достаточно знать, что оно такое вот есть и работает быстрее пузырька. А вот умение в нужном месте использовать hash map и вот там вот отсортировать данные перед применением жадного алгоритма — это да. Это как раз то, что вполне может встать перед разработчиком.
Не каждый день, разумеется. Но раз в пару месяцев задача встает.
Подозреваю, что даже в гугле, если взять не лично Ваш опыт, а в среднем по всем разработчикам - это будет да-алеко не "раз в пару месяцев". Я не прав?
В мелких-средних компаниях картина кардинально другая: такого рода задачи есть, только попадаются раз в год, делает их обычно ведущий разработчик/самый крутой из сениоров конкретной команды, а все остальные разработчики этой команды такие задачи видят только при подготовке к интервью.
Подозреваю, что даже в гугле, если взять не лично Ваш опыт, а в среднем по всем разработчикам — это будет да-алеко не "раз в пару месяцев". Я не прав?
Сложно взвесить. Вот те, кто хром, как я, пилят — там это наверно так и встречается. Те, кто в deep mind работают — там вообще запредельная математика везде абсолютно. Кто-то пилит распределенную big table — там алгоритмов сильно больше. А кто-то пишет интерфейс для какой-нибудь веб морды поиска — там поменьше алгоритмов встречается. Хотя структуры данных тоже есть.
Но вообще не так важно, как часто эти задачи возникают. Они возникают, компания хочет, чтобы работники с ними справлялись. Имеет право.
В целом согласен с вами, но на мой взгляд тут есть несколько важных моментов:
Хороший интервьюер во время кодинг интервью смотрит не только на решение, но и на ход мыслей кандидата, это помогает оценить человека более объективно. Конечно, в этом случае есть другие факторы вроде волнения и знания языка, но, наверное, идеального способа оценить человека за короткий промежуток времени не существует.
Прохождение таких интервью ничего не говорит о том, способен ли кандидат выполнять реальные задачи в данной компании
Для этого есть дизайн и behaiour интервью, на которых уже можно оценить насколько кандидат способен решать реальные проблемы компании.
кандидат достаточно сильно хочет получить работу в FAANG, чтобы потратить полтора месяца своего время на подготовку к этому интервью
Я думаю все кандидаты на интервью достаточно сильно хотят получить работу в FAANG.
Такие интервью, во-первых, проверяют, что кандидат вообще способен писать код осознанно, а не случайными изменениями, пока оно не заработает.
Во-вторых, алгоритмическое мышление, как и математика даны не всем. Поэтому помимо проверки, что кандидат соизволил подготовиться к интервью, тут еще проверка, что кандидат вообще способен "алгоритмы" осилить.
Прохождение таких интервью ничего не говорит о том, способен ли кандидат выполнять реальные задачи в данной компании
Если кандидат способен выстроить модель задачи, разбить ее на части и понять, какой алгоритм тут применяется, то уж условные "джейсоны перекладывать" он точно сможет. И если ему вдруг придется и что-то поинтереснее делать, то он справится или хотя бы поймет, что вот тут надо бы подумать.
интервью не говорит о неспособности кандидата выполнять реальные задачи и даже не говорит о том, что он плохо знает алгоритмы и структуры данных!
Ну вот так вот рынок найма в ФААНГи устроен, что компании готовы мириться с false negative, а вот false positive им гораздо больнее. Ибо кандидатов и так сильно больше чем мест. А вот бестолковый разработчик сможет какое-то время симулировать деятельность и получать зарплату, пока его не уволят.
Звучит разумно. Правда интервью в стиле FAANG последнее время хакают иначе - интервью проходит кто-то один, а на работу выходит кто-то другой. :)
Но то FAANG, а в стартапах проводить бессмысленные раунды интервью возможности нет. Поэтому я все эти вопросы обычно решаю намного проще: кандидат приходит с примером кода (либо своего с гитхаба, либо с нашим тестовым, если примера своего кода у него нет), и мы этот код обсуждаем в режиме "а для тут вот сделано именно так? а нет ли вот здесь бага? …" и это быстро показывает насколько самостоятельно и осознанно этот код писался, равно как и реальную квалификацию кандидата (которую по заученным реализациям алгоритмов не определишь).
Поддержу ораторов выше. Проблема алгоритмов в том, что, если их не знаешь, даже не возникнет мысль, что тут какой-то алгоритм вообще есть, оказывается.
Даже большинтсво задачек на литкоде написаны "дано A и B — сделайте вот это". При чем можно просто слово-в-слово закодировать "вот это" и будет медленное, наивное, но рабочее решение.
Спасибо за статью! Подскажи, пожалуйста, что дает премиум подписка?
Один мой родственник, весьма успешно работает за границей в геймдеве много лет, при этом часто бывал в Москве и для интереса ходил на собеседования - основные различия "там" и "тут" он описывал просто - если в зарубежной ААА-компании с меня спрашивают за DX12/Shaders и кучу API, то в РФ за сортировку пузырьком (последний пример - утрирование, но ёмко показывающее принципы проведения интервью). Как результат - он не проходит собеседования, просто потому что в его профиле работы другие алгоритмы и другие способы решения проблем.
Впрочем это касается любого трудоустройства, например с меня постоянно спрашивают про стек TCP/IP, хотя в моей работе я касаюсь исключительно вбивания IP адреса в настройках сетевой карты, я не админ, да и уверен админу эта информация тоже не нужна, но уже 30 лет вопросы не меняются. Кстати заметно больше стало вопросов про корпоративный дух и работу в команде, особенно забавно когда ты единственный "айтишник".
Так что всё это нужно исключительно для развлечения, ибо я не представляю как прохождение такого интервью влияет на скилл в конкретных задачах (мы же все понимаем что ЕГЭ это остой, как и любые способы оценки знаний через "вопрос-ответ" с выбором). Ну а написание кода по памяти - это для меня вообще недостижимое, никто не пользуется современными IDE? Там методов и классов с трёхэтажными названиями больше чем слов в английском.
Почему до сих пор FAANG, а не MAANGo - Meta, Apply, Amazon, Netflix, Google?)
Моя история подготовки к интервью в FAANG