Pull to refresh

Comments 71

UFO just landed and posted this here
А вы изучайте для себя а не для собеседования. Темы для изучения которые описал автор — это база, которую дают на первом курсе профильных учебных заведений.
UFO just landed and posted this here

Помню, в универе защищал лабораторную. Какую-то мелочь не знал, препод говорит: "Что нужно делать если не знаешь — верно, читать документацию. Где в RStudio документация?", а потом "И что значит что ты прочитал?".
Отличный препод был. Жаль что я на учебу забил(

Неиспользуемые вещи забываются.


Я пару лет назад прочитал книжку Окасаки по алгоритмам в чисто функциональном сеттинге, и даже реализовал и формально доказал свойства красно-черного дерева на идрисе, например. Тем не менее, уже через пару месяцев вспомнить, как именно оно там внутри работает, в условиях интервью было бы нереально.

А мне вот другое интересно — если человек помнит, что красно черное дерево — это двоичное, сбалансированное (даже самобалансирующееся) дерево, применяемое в таки-то случаяз — этого недостаточно? Ведь если мы говорим о понимании — то понимания того, что такое сбалансированное дерево, и почему это хорошо/плохо — должно реально хватать для работы. А уже детали реализации помнить скорее глупо, чем полезно.
UFO just landed and posted this here

В гугле, наример, не спрашивают реализацию красно-черных дервьвев. Достаточно использовать std::set, допустим, и знать, что оно работает за логарифм, потому что там внутре бинарное самобалансирующееся дерево поиска. Если вы слышали о (или тем более знаете как устроено) красно-черное дерево (как один из примеров таких деревьев), то это лишь повод поставить вам дополнительный жирный плюс в графе "алгоритмы и структуры данных". Но даже просто знания, что там за логарифм как-то работает и вставка и проверка и удаление, вполне достаточно, и никаких минусов в отчете не понесет.

Понятно. Ну я бы сказал, что это логичный вариант, т.е. если бы я решил вдруг спросить про красно-черное дерево, меня бы такой ответ удовлетворил тоже.
Вы так говорите, как будто эту университетскую «базу» используют больше 1% современных программистов/кодеров/разработчиков. ПО сути для первой джуниорской вакансии надо прочесть 1 книжку по языку и 1 книжку по алгоритмам (самую тонкую, не надо кнута) + глянуть 10-15 самых распростанненых задач на собес. А дальше ты работаешь и получаешь актуальный для индустрии опыт. А для всякиех там гуглов уже читаешь вот такие статьи и специфические книги. Какое-то кусочки знаний конечно иногда пригождаются на работе, но использовать старое доброе высшее образование как какое-то базовое мерило для специалиста весьма спорно. Вижу кучу примеров как люди без вышки прекрасно себя чувствуют в индустрии разработки ПО.
-А вы знаете как сделать поиск внутри графа?
-Да, конечно, вот — вот так можно, а еще так, но за большее число итера…
-А красно-черное дерево?!
-Да, это мое любимое — вот варианты и я еще мо…

-Хорошо, вы приняты!
Будете делать формочки для логина пользователя…

© FAANG
Будете делать формочки для логина пользователя…

))))) Спасибо, спасибо, что так лаконично выразили цель такого рода собеседований.

FAANG:
-А вы знаете как сделать поиск внутри графа?
-В книжке посмотрю, если на SO сходу не нагуглю.
-А красно-черное дерево?!
-Ну что вы! Название, конечно, слыхал, но в настоящей жизни это даром не нужно!

-И действительно! Мы вам перезвоним!

*Продолжает делать формочки для логина пользователя в чешижопской интернет студии*
Есть разница между «не знаю», и «знаю, но с ходу не напишу, надо заглянуть в справочник». Таким образом вас могу попросить написать, к примеру, 5 интегралов от тригонометрических функций по памяти.
Это тоже верно. Но если вам нужно будет принять на работу одного, а на собеседование придет 500 соискателей, то скорее всего, вы возьмете на работу того, кто эти пять интегралов знает, и не будете проверять навыки просматривания в справочниках у всех остальных. Нет, возможно кто-то из них и лучше решает диффуры, но если вы это будете проверять, то за приемлемое время вы никого не найдете. Лучше найти локальный приемлемый максимум за конечное время, чем абсолютный за бесконечное.
Но если вам нужно будет принять на работу одного, а на собеседование придет 500 соискателей, то скорее всего, вы возьмете на работу того, кто эти пять интегралов знает, и не будете проверять навыки просматривания в справочниках у всех остальных.

Проблема только в том, что такой метод сработает, если ваша работа связана с высшей математикой. Но, если работа именно «формочки для логина» делать, то может оказаться, что чемпион-олимпиадник, на память диктующий таблицы интегралов, очень плохо делает формочки.
Т.е. я к тому, что вопросы собеса должны находится в практической плоскости, понятной и собеседующему и соискателю.
Проблема оценки пригодности кандидата стара как мир, никто и не говорит о том, что это оптимальный подход. Просто вероятность того, что человек, знающий алгоритмы, может делать формочки хорошо, выше, чем у человека, который их не знает. К тому же это универсальная проверка на пригодность в области computer science, позволяющая унифицировать процесс для разных вакансий.
Просто вероятность того, что человек, знающий алгоритмы, может делать формочки хорошо, выше, чем у человека, который их не знает.
Совсем не факт. «Делать формочки» — это нудная работа на усидчивость и для человека с высоким интеллектом и глубокими знаниями она скучная и не интересная, поэтому делать он будет ее «через силу» и результат будет соответствующий. Академика тоже можно посадить за кассу в супермаркете, но зачем?
Ну ладно, нудная работа это отстой, согласен. И куда тогда податься людям с высоким интеллектом, да так, чтобы по деньгам как в FAANG? Такие места есть, но их на порядок меньше, чем открытых позиций в фаанге, и попасть туда еще труднее. Тут не такая дихотомия, что ты или страдаешь от ограниченности в Гугле, или купаешься в деньгах, попутно применяя свои глубокие знания в каком нибудь НИИ cutting-edge R&D центре. IRL ты или мучаешься от ограниченности задач в Гугле в Калифорнии, считая дни до вестинга, или мучаешься такими же ограниченными задачами в «Рога и Копыта Индастриз» в Подмосковье, считая дни до зарплаты (это я сильно утрирую, конечно, сути это не меняет).
Я не вижу препятствий для человека с глубокими знаниями и высоким интеллектом «делать формочки в Гугле», и извлекать из этого максимум выгоды в деньгах, в качественном расширении социальных связей и деловых и научных возможностей для собственного дела. Имхо, это вполне стоит месяца-двух усилий над собой.
С позиции соискателя интерес понятен.
Мой комментарий был относительно нелогичности HR-отдела.
Грубо говоря, если нужны грузчики, так и проверяйте силу и выносливость, а не IQ-тест и наличие кандидатской диссертации…
Мой комментарий был относительно нелогичности HR-отдела. Грубо говоря, если нужны грузчики, так и проверяйте силу и выносливость, а не IQ-тест и наличие кандидатской диссертации

Все у HR логично. Представьте, что вы HR в некотором условном Газпроме и руководство для подержания имиджа требует платить грузчикам в 10 раз больше среднего в этом регионе.

В результате у вас десять тысяч человек на место, причем вы прекрасно знаете, что на самом деле грузчики ничего тяжелее стульев у вас не носят, то есть подойдет почти любой.

В результате, вы требуете от соискателей кандидатскую десертацию в философии, умение писать левой ногой и садиться на шпагат, придумывая причины почему это важно для грузчика.

Но вам просто нужно отсееть 99.99% соискателей, оставив только тех кто реально упоролся в желании попасть на эту должность и потратил год жизни только на обучение тому что ему скорее всего никогда больше не пригодится.

Этим вы с одной стороны покажете элитарность работы в вашей компании, с другой будете нанимать только реально мотивированых людей, которые не убегут через неделю.
Ну а тут уже вы утрируете )
Если продолжать аналогия с грузчиками, то проверяется не кандидатская, а нормативы по ТБ, нормы электро и пожаробезопасности, правила товарного размещения и прочее.
Если продолжать аналогия с грузчиками

Скорее грузчиков заставляют участвовать в соревновании армрестлинга.
Это не очень покажет умение акуратно перенести рояль или разгрузить Камаз кирпичей за смену, но в целом какие-то корреляции с физической силой армрестлинг, вероятно, покажет.
Мне кажется, цепочная интерпретация аналогий — неблагодарное занятие. Точки зрения понятны, так что предлагаю остановиться. )
может оказаться, что чемпион-олимпиадник, на память диктующий таблицы интегралов, очень плохо делает формочки.

Кстати, судя по результатам работы FAANG для конечного пользователя — оно в целом так и есть.
Тут главное не спутать маркетинговый и инженерный буллшит. )
Как интересно получается.

Есть в компании программисты, которых набирают через полосу препятствий, чтобы они в уме брали тройные интегралы, свободно разговаривали на ассемблере и стреляли лазерами из глаз.

А ещё есть в компании «маркетинговые» сотрудники, которых берут, если они на собеседовании могут дотронуться пальцем до носа и написать своё имя не печатными буквами.

Всё как в этом известном мультфильме:



Если это правда, то к системе собеседований появляется ещё больше вопросов. Если нет — то придётся признать равный вклад в буллшит всех участников :)
Вопросы к сервисам, конечно, есть у всех. Но лично я в целом не возьмусь учить Гугл бизнесу, а его инженеров программированию.
Вы не поверите, неделю назад, интервью с Убер, первое задание — построить ориентированный граф, обойти все вершины и отфильтровать некоторые из них по условию.
Интервьюверу не понравилось что я использовал adjacency list для построения графа. Сказал, что есть более эффективный способ, но какой не сказал. Интервью на фротенд позицию не пройдено.
UFO just landed and posted this here

…которая для sparse-случая выродится в adjacency list, большие не-sparse-графы — сам по себе интересный вопрос, а для маленьких графов это всё неважно.

Может, там условие — найти ту вершину, которая связанна с этими двумя. Тогда матрица смежности быстрее, ибо разряженной структуре вы по любому медленнее будете проверять наличие дуги между двумя конкретными вершинами.


Но это очень частный случай. Может, mobileDeveloper что-то напутал и наоборот предлагал матрицу смежности вместо списка инцидентности?

Граф был разряженный. Матрицу я упомянул, как вариант и объяснил, почему она может быть хуже в данном случае.
Вы не поверите, неделю назад, интервью с Убер, первое задание — построить ориентированный граф, обойти все вершины и отфильтровать некоторые из них по условию.
… Интервью на фротенд позицию не пройдено.

Задача на построение Virtual DOM. Если подходить с позиции не «фронтэнд разработчик — это тот, кто разрабатывает на реакте» а с «фронтэнд разработчик — это тот, кто разрабатывает реакт», то вполне себе нормальная, хорошая задача.

Вспомнилось. Есть такая либа enzyme. Для тестирования React. И в случае больших DOM она начинала просто беспощадно тормозить (а может и по сей день так). Зависимость была явно нелинейная. Пришлось её всю раздебажить (мои глаза!). Оказалось что ребята делали обход дерева в ширину. Ну ок, в чём проблема? А в том что они частично это реализовали (сделав queue через массив), но потом забили и понавтыкали везде квадратов. В уже почти готовом алгоритме. AirBnB неприятно удивил.

Я не имею ничего против алго задачек на собеседованиях. Меня беспокоит то, что все эти FAANG компании требуют идеального решения за 30-45 минут отведённого времени. Например, в данном случае я дал вполне годное работающее решение, также я могу объяснить в каких случаях оно будет не очень подходящим и т.п. Т.е. получить идеальное решение можно, только если задротить Литкод день и ночь, но это не делает меня инженером лучше чем я сейчас.

С другой стороны, я понимаю, что у этих компаний нескончаемый поток кандидатов, и они могут позволить себе выбирать лучших (по их методикам лучших).
Выучить алгоритмы для собеседования — это дело нужное, конечно, но потребуются ли эти знания потом для реальной работы?
В некоторых ситуациях ответ на вопрос «вам шашечки или ехать» выходит за рамки простого.
иногда требуются. Чаще всего требуется просто выбрать правильно коллекцию (даже с этим у многих проблемы). У меня на практике был случай, когда человек использовал для хранения множества массив вместо хэштаблицы или дерева, и код, который действительно работает постоянно и делает всю работу программы (которая продавалась за большие деньги), дико тормозил. На код-ревью иногда сталкиваюсь с тем, что люди выбирают коллекции небрежно, и могут реализовать алгоритм с квадратичной сложностью там, где кол-во элементов требует более эффективного алгоритма, зачастую даже стандартного.
Так что базовая алгоритмическая грамотность на уровне «отличаю массив от списка и хэштаблицы, а еще знаю про деревья» должна быть.
иногда требуются
А оправдывает ли это «иногда» ретивость, с которой интервьюверы трясут знания алгоритмов?

По крайней мере в FAANG, где на каждую позицию десятки, если не сотни претендентов — да. Могут хоть оценки в школе сравнивать, хоть умение плавать.
Единственный гарантированный способ оценить, как будут работать кандидаты — это испытательный срок. Но это запретительно дорого, даже для них.


Вот и остается спрашивать что-то вполне релевантное и коррелирующее с когнитивными способностями. Заодно как-то проверяется умение писать код.

ретивость — скорее нет, тут фактор большого конкурса на место. Но спросить человека по нескольким алгоритмическим темам — нужно. Вот они и проверяют, по задаче на тему. Времени только мало дают, поэтому приходится задачи тупо задрачивать.

Если вы не знаете алгоритмы, то вы даже не поймете, что они вам, оказывается, понадобились. Просто будет какой-нибудь полный перебор или решение какой-то упрощенной, приближенной задачи. При том что, нормальное, алгоритмическое решение и работает на порядки быстрее, и кода там в 4 раза меньше (со всеми комментариями, вроде — это динамическое программирование, тут такие-то параметры).


Отвечая на ваш вопрос — в FAANG, по личному опыту, алгоритмы нужны бывают. Сейчас на интервью вообще спрашиваю именно ту задачу, решение которой лично коммитил. Писал и ДП, и всякие линейные регрессии, и хитрые структуры данных, и даже теорию чисел пришлось применить один раз. Это случается далеко не каждый день, но случается.

UFO just landed and posted this here
Статья неполная без нормальноо текста задачи, имхо) Потому что в такой постановке вообще непонятно, что надо сделать.

Ну так там и дейкстра и а* указаны. Можно и каким-нибудь BFS/DFS пытаться достигнуть

А, есть что то, подобное такой программе,

Documentalist
Fast, offline access to developer API documentation on Windows.
Over 190+ API docs.


, но сборником решений разных алгоритмов на разных языках программирования?
(как вариант сборника решений сайта rosettacode.org/wiki/Rosetta_Code )

P.S. И, можно ли, тогда будет при собеседовании пользоваться такой подборкой реализации алгоритмов?
И, что тогда, в такой «гипотетической» ситуации, станут спрашивать собеседующие? :)

Список алгоритмов

И, по вопросу в статье,
Я помню, как один из собеседников спросил, как пройти из точки A в точку И по сетке. Я понятия не имел, как это сделать

Например:

Алгори́тм волново́й трассиро́вки (волновой алгоритм, алгоритм Ли) — алгоритм поиска пути, алгоритм поиска кратчайшего пути на планарном графе. Принадлежит к алгоритмам, основанным на методах поиска в ширину.
Мой экземпляр «Cracking The Coding Interview 6th Edition», подписанный Гейлом Лаакманном Макдауэллом

Лол. Это девочка.

Ну вот, теперь вы знаете, чем отличается перевод в корпоративном блоге от авторской статьи… если это поправят — это хорошо. А бывает что и нет.
Ну это не мне, это чуть выше )
UFO just landed and posted this here
И тут опять «sliding window» смешали зачем-то с TCP/IP :D
UFO just landed and posted this here
Автор оригинала имел в виду технику/прием решения задач «sliding window», который неплохо переведен, например, тут. При этом, если посмотреть оригинал статьи, никакого упоминания TCP/IP там нет. Это вариация на тему «слышу звон, но не знаю где он». И, главное, всего несколько дней назад, вот тут, те же «скользящие окна TCP/IP».
ИМХО это уже перебор — учиться проходить интервью. Даже в Гугл или ФБ. Есть уже и книги о том, как проходить собеседования, и куча сервисов для подготовки к ним. Кроме того, что у человека хорошая память, действительно такие собеседования ничего показать не могут. Более того, не уверен, что работающие уже в FAANG инженеры смогут пройти такие интервью. Если нужно использовать алгоритмы обхода деревьев в проекте, не проблема открыть этот конкретный алгоритм и изучить. Как тут уже указывалось, главное знать где искать и иметь желание это делать.
Для себя, да, учиться нужно в обязательном порядке. Но не по списку из алгоритмов, а по мере необходимости.
так они уж лет 15 есть, книги эти, и сайты лет 10. Я бы сказал, это уже давно мейнстрим. За бугром так вообще сейчас тупо везде задачами собеседуют. На моей текущей работе тоже на собеседовании приходилось реализовать кой-чего.
Мне тоже не нравится необходимость постоянно в решении задач практиковаться, если что. Но вот правила игры такие. Вы сами пишете, что учиться нужно для себя в обязательном порядке, но почему не по списку алгоритмов? это ж тоже в конечном итоге для себя
Более того, не уверен, что работающие уже в FAANG инженеры смогут пройти такие интервью.

Тут есть практика тестировать новые задачи на своих коллегах. Мои коллеги — легко прошли бы мое интервью.


Если нужно использовать алгоритмы обхода деревьев в проекте, не проблема открыть этот конкретный алгоритм и изучить

Если вы не знаете про этот алгоритм, то вы в большинстве случаев даже не поймете, что в стоящей перед вами задаче можно построить дерево и обойти его.

В последние годы всегда ходил на собеседования без подготовки, рассуждая, что продаю мой богатый опыт в разработке больших нагруженных систем. Но всегда покупали экспертное знание плюсов и алгоритмы. Поэтому 2 собеседования в Яндексе и одно в Блумберг я не прошёл, но и проходил я их just for fun, без цели всенепременно туда попасть. А работаю много лет над интересными проектами в компаниях, куда попадаю через рекомендации знакомых.

Т.е. моё поведение сейчас: «я типа такой крутой, не хотите, как хотите, нас и тут неплохо кормят». Но, если бы была цель попасть в FAANG и т.п., пришлось бы играть по их правилам. Я бы засел за книги, вспомнил бы алгоритмы, практиковался бы в решении олимпиадных задач и т.п. Пригодится или нет неважно, если цель — попасть в компанию.
подписанный Гейлом Лаакманном Макдауэллом

Это какой-то новый персонаж?
Если берётесь за перевод, то хоть проверьте гендер автора одной из лучших книг для подготовки к собеседованию :)

Знание структур и академических алгоритмов безусловно необходимо, но вторично для инженера. Тем более, что в реальной работе, базовые структуры и алгоритмы не используются в чистом виде, а покрыты толстым слоем оберток и фреймворков фирменного изготовления. А вот знание паттернов программирования и понимание условий их примененимости — это ежедневная рутина, которая нужна как для чтения чужого кода, так и для разработки собственного. Однако на собеседовании разыскивают людей, которые, по всей видимости, каждый рабочий день будут писать по хешсету, а не бизнеслогику приложения. По большому счету ни одно собеседование не проверяет знания, которые нужны именно для работы инженером, но проверяют чисто академические сведения. Углубляться на собеседовании в дебри их устройства — пустая трата времени обеих сторон.

Я всегда на собеседованиях спрашиваю и прошу показать свои работы во время учебы, вне основной работы и тп. Если человек действительно горит программированием, то всегда что-то будет делать для себя. Так легко проверяется мотивация к работе.
Знания и понимание обычно спрашиваю так — спрашиваю про недавно прочитанные книги, статьи, прошу свое мнение — можем поговорить на эту тему и тп. Опять же если человек книг не читает то интереса к работе нет. Если читает но не может рассуждать и сформулировать свое мнение — просто врожденных данных не хватает — грубо говоря программировать может нравится, но таланта не хватает.
Но эти подходы работают только при наборе джунов и простых программеров — с опытными сложнее.

Если человек действительно горит программированием, то всегда что-то будет делать для себя.

Я бы не стал показывать. Да у меня есть свои проекты. Но они сделаны по принципу "времени мало, успеть бы сделать фичу Х". Показывать это как эталон своих возможностей? Ну нафиг. Начнут ещё вопросы задавать — а вот тут почему глобалку объявили? Да потому что времени было в обрез, а мне за это никто не платит. А вот тут почему костылём подпёрли? Да потому что време… Не очень понимаю зачем оценивать по таким критериям. Посмотрит человек как git-история ведётся — скажет а чего всё в master пушили? Да потому что я один над проектом работал. А чего коммиты с тупыми описаниями? Да потому что я один ра… Ну и так далее.

Ну вот заодно и проверил бы собеседника на адекватность. Собеседование это же действие в обе стороны. Зачем тебе работать в конторе где люди не понимают специфики личных проектов и тп. Тем более никто на собесе прямо изучать комменты к коммитам не будет — лично меня интересует:


  1. наличие таких поделок/проектов
  2. насколько человек продвинулся от стандартных примеров — тут вобщем даже код можно не смотреть — можно прям приложение глянуть

Но если джун покажет нормальные проекты/участие в чужих проектах опенсорсные с хорошим кодом, комментами и организацией репы, то это будет практически сразу вин собеса.

Если им этого достаточно, то мне надо еще немного подтянуть английский и из Праги переехать в США. Ну и повспоминать, может код набрать какой. Что то прям не верится, что чуваку этого хватило в фаанг.

UFO just landed and posted this here

Про поведенческое не знаю, а дизайн мне самое простое.

Only those users with full accounts are able to leave comments. Log in, please.