Пугающая антиутопия интервью для программистов

Автор оригинала: Jared Nelsen
  • Перевод

Эксперименты


У меня зазвонил телефон.

— Алло, это Джаред.

— Здравствуйте. Я звоню вам насчёт телефонного собеседования в Гигантской Поисковой и Рекламной Компании [очевидно, это Google — прим. пер].

— Да! С нетерпением ждал вашего звонка!

— Хорошо. Можете написать алгоритм для поиска K-го самого большого значения в двоичном дереве?

Я замолкаю. Полностью отключаюсь. Никогда не попадал в такую ситуацию. Пустой документ Google смотрит на меня, а курсор мигает как в замедленной съёмке. Я кое-что набрасываю в качестве первого прохода.

— Можете написать тестовый пример для этого алгоритма?

Конечно. Я бы мог, если бы не был полностью одурманен и моё внутреннее эго не таяло под пылающей яростью мечты, умирающей на моих глазах. Неужели к этому сводится вся моя тяжёлая работа за последние несколько месяцев? Примерно в январе 2019 года я решил, что пришло время найти новую работу. Как будто боги программной инженерии благословили эту самую мысль, и рекрутер Гигантской Поисковой и Рекламной Компании связался со мной в LinkedIn по поводу телефонного собеседования. Это было прекрасно!

Такое случилось уже не в первый раз. Будучи блестящим молодым инженером, только что окончившим школу, я не так давно приступил к первой работе и неплохо справлялся с ней. Но потом мой мир перевернулся с ног на голову. Я работал над особенно неприятной ошибкой и сделал то, что сделал бы любой уважающий себя инженер-программист, прежде чем пытаться решить её самостоятельно: погуглил. Как только я нажал Enter с моим соответствующим тупым запросом в окне поиска, экран почернел и меня выбросило в консоль.

Вы говорите на нашем языке… Хотите решить задачу?
1. Да
2. Нет, спасибо

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

Дан массив nums, содержащий n+1 целых чисел, где каждое целое число находится между 1 и n (включительно). Докажите, что хотя бы одно число повторяется. Предположим, что существует только один дубликат. Найдите его.

У вас 24 часа!

У меня случился небольшой сердечный приступ. Когда мне удалось привести себя в чувство с помощью ещё одной порции кофе Costco, я понял, что вполне могу решить задачу. У меня уже был план. Так я и сделал. Как только я нажал кнопку «Отправить», мне дали решить ещё одну. Это повторялось пять раз, и с каждым разом становилось всё труднее. Когда я отправил последний ответ, то увидел ещё одно сообщение:

Поздравляем! Этот код очень хороший! Хотите пройти собеседование в Гигантской Поисковой и Рекламной Компании?

Вот и всё. Весь мой профессиональный мир изменился. Одна из самых могущественных организаций мира проникла в мой 22-летний мозг и переписала регистр. Ни одна из предыдущих целей в карьере больше не имела значения. До этого я был в блаженном неведении, что меня может нанять такая топовая компания. Но очевидно, что я каким-то образом оказался достаточно достойным внимания.

Телефонное собеседование было похоже на кошмарный сон. Меня попросили за 45 минут запрограммировать игру Конвея «Жизнь». Вообще-то я неплохо справился. Написал всю программу и протестировал её. На следующий день я получил отказ. Внутренне я был подавлен и смущён. Что именно я сделал не так? Разве все тесты ничего не значили? Почему я должен был написать такой сложный алгоритм за такое короткое время?

После первого опыта решения задач на этом уровне я решил, что должен усовершенствовать свои навыки. Собеседование состоялось в апреле этого года. Я составил трёхмесячный учебный план и приступил к делу. Каждое утро я решал три практические задачи перед работой. Вечером после пробежки и перекуса работал ещё. За три месяца в общей сложности я решил 114 практических задач. Массивы, поиск с возвратом, двоичный поиск, двоичные деревья, поиск в ширину, поиск в глубину, динамическое программирование, графы, жадные алгоритмы, хэширование, связные списки, вероятности, сортировка, стеки и префиксные деревья — вот некоторые из тем, которые я изучал. Как я мог потерпеть неудачу с такой подготовкой?

Неудачи


Интервью с Гигантской Поисковой и Рекламной Компанией завершилось в огне. Я не мог решить проблему. Но это было только начало безумия. Сначала я весьма стратегически подошёл к тому, в какие компании обращаться. Мне нужна была не просто «хорошая», а «правильная» работа.

Следующей была компания по производству беспилотных автомобилей. Я получил ответ почти сразу после подачи заявки и настроил редактор кода. Интервьюер раздражённо и с очень сильным акцентом попросил меня закодировать очень сложный алгоритм фильтрации изображений. Я написал его. «Выглядит очень хорошо!» — сказал он. На следующий день я получил шаблонное письмо с отказом.

Затем была аналитическая компания, которая попросила выполнить домашнее задание из трёх предложений. Я сделал всё, что мог, и написал очень сложную многопоточную систему обработки изображений. И получил вежливое «Нет» от рекрутера, а когда попросил объяснить, мне сказали, что моя реализация была «слишком неэффективной».

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

Другой пример был с Гигантской Компанией Социальных Медиаплатформ: «Джаред! Благодарим за вашу заявку! Думаем, что вы отлично подойдёте для работы в нашей компании! Я отправил ваше заявление непосредственно менеджеру по найму в вашем региональном офисе!» Через восемь минут я получил шаблонное письмо с отказом, в котором было написано, что мои навыки не подходят для этой должности.

Ко мне обращалось бесчисленное количество сторонних рекрутеров. Все разговоры закончились ничем. Пожалуй, больше всего мне понравилась одна компания по звукообработке. Рекрутер связалась со мной и сказала, что после просмотра моего резюме команда очень взволнована и стремится поговорить со мной, так что она установит контакт с менеджером по персоналу. Прошла неделя, я спросил у неё, как дела. Рекрутер сказала, что она связалась с менеджером по персоналу — и он не думает, что мои навыки соответствуют должности. Я смирился с этим… однако в качестве теста отправил своё резюме на другую вакансию — и со мной немедленно связался другой рекрутер. Я был поражён, что они немедленно позвонили. Должен признаться, в этот раз я не очень хорошо проявил себя. На следующий день я получил по почте шаблонный отказ.

Наконец, я дошёл до этапа собеседования в офисе Гигантской Компании Социальных Сетей. Я ответил на серию вопросов по программированию с несколькими людьми в течение четырёх различных интервью — правильно и удовлетворительно ответил на все из них. По пути мне задали ряд запутанных и жёстких вопросов типа «Расскажите о том времени, когда...». Это было освежающе, так как впервые во время поиска работы меня спросили о моём опыте и проницательности как инженера вообще. Затем последовало заключительное собеседование по проектированию систем. Интервьюер быстро дал мне небольшую систему для разработки. Я начал рассказывать о своём решении, а по ходу мне задавали вопросы. Наконец, мы дошли до того, что он сказал: «Хорошо, допустим, у нас микросервисная архитектура… можете её спроектировать...?» Я сразу же сказал, что у меня нет никакого опыта работы с микросервисами. Он вопросительно посмотрел на меня и спросил: «Нет опыта?» Я подтвердил. Я постарался чётко изложить свой набор навыков и опыт в области ПК, встроенных систем и мобильных разработок. Он замолчал как человек, который понимает, что совершил ошибку. Отлично! Я четыре месяца готовился к этому собеседованию, потратил на подготовку практически всё нерабочее время, решая практические задачи, и репетируя, как представить свой опыт по навыкам коммуникации, а он не потрудился потратить 10 минут на чтение моего резюме.

Анализ


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

  1. Мы поглощены собственной мифологией. Практически каждая популярная концепция программиста, особенно в современном помешанном на технологиях мире, предполагает идею одинокого программиста-индивидуалиста, который может легко решить любой алгоритм по требованию. Архетипический инженер-программист — это социально незащищённый, антиструктурный и крайне идеалистичный человек. Он отчаянно независим, а чтобы сделать работу, не нуждается в общении с кем-либо. Из этого следует, что поскольку мы бессознательно верим в этот архетип, у меня как инженера должны в первую очередь проверить эти черты. Но насколько нам известно, эти черты характера на самом деле отрицательно коррелируют с высокоэффективным кандидатом. В компаниях по разработке программного обеспечения работает одна или несколько команд разработчиков. Команды — это группы людей.

    • Чтобы добиться успеха в группе с общей целью индивиды должны:
    • Общаться друг с другом — если один из членов команды не понимает цель, он потянет вниз всю команду.
    • Общаться с непрограммистами — хотя некоторым программистам это не нравится, но для управления компанией действительно недостаточно одних только разработчиков.
    • Взять курс — чаще всего направление для продукта приходит извне команды разработчиков. В конце концов, это своего рода смысл работы в организации: вы воплощаете в жизнь видение, которое не является вашим.
    • Учиться друг у друга — всегда есть дисбаланс, кто что знает в команде. Это относится как к знаниям о продукте, так и к техническим навыкам. Существует взвешенный баланс в общем наборе технических навыков для коллектива. Вот почему создаётся иерархия опыта и распределение обязанностей. Это равновесие никогда не бывает и не должно быть статичным. Кто-то всегда должен учиться, и всегда есть кто-то, кого можно научить.

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

    • Насколько вообще ценны алгоритмы? Есть много точек зрения на этот вопрос. Хотя я не согласен, но есть даже мнение, что вы можете быть отличным программистом, вообще ничего не зная об алгоритмах и даже об устройстве компьютера, если на то пошло. Мой контрапункт заключается в том, что авиамеханик отличается от аэрокосмического инженера. Кто из них ценнее, и кем бы вы предпочли быть? Я оставляю этот мыслительный процесс на ваше усмотрение. Лучше спросить, насколько релевантны алгоритмы.
    • Насколько вообще релевантны алгоритмы? Я верю, что для успешного и ценного инженера важно знание алгоритмов и того, как работает компьютер. Но все знают, что эти знания редко используются на работе. В командах повсеместно распространено и навязывается мышление «не изобретать велосипед». Для многих и большинства приложений это хорошая политика. Если есть хорошо проверенная библиотека, то безопаснее и уместнее использовать её, чем заново изобретать колесо. Круглые колёса — это, так сказать, хорошие колёса. Итак, если рассматривать проблемы алгоритмов в связи с этим вопросом, то возникает вопрос, почему, черт возьми, мы вообще задаём эти вопросы. Если так много людей в отрасли думают, что эти вопросы не представляют ценности в ежедневных задачах, то почему мы используем их для оценки программистов?
    • Тёмная сторона задач на алгоритмы. Как и во многих философских вопросах в жизни, есть тёмная сторона. Дело в том, что в технологическую индустрию пытается войти огромное количество людей. В течение дня после публикации вакансии в LinkedIn у неё более ста кандидатов. Практически ни у одной компании нет ресурсов, чтобы опросить всех. Задачи на алгоритмы становятся механизмом просеивания кандидатов, которые не подходят для работы или не имеют базовых навыков программирования. Проблема в том, что у каждого, похоже, есть своё представление о том, что означает «базовых» в этом контексте.
    • Мы не знаем, насколько трудными они должны быть. В течение семи месяцев во время собеседований я столкнулся с большим количеством очень сложных задач. С одной стороны, меня попросили написать функцию для обращения строки. С другой стороны, меня попросили имитировать социальную сеть и написать алгоритм фильтрации изображений. Одна компания попросила провести два отдельных собеседования по программированию. В первом меня попросили написать простой алгоритм сортировки. На втором — написать рекурсивный генератор перестановок (пермутаций) с использованием динамического программирования, что является непростой задачей. В тот момент я был совершенно сбит с толку. В конце я спросил интервьюера: «Эта проблема кажется немного крутой для телефонного интервью. Часто ли вы пишете рекурсивные алгоритмы в Компании по Обработке Платежей? Он ответил: «Нет, мы не используем рекурсию». Я спросил «А как насчёт пермутаций? Когда вы ими пользовались?» Он ответил: «Наши алгоритмы не нуждаются в пермутациях. Большинство наших инженеров работают над пользовательскими интерфейсами и инфраструктурой». Больше у меня вопросов не было. Почему на аналогичные позиции одна компания предпочитает задавать более простые вопросы, а другая — более сложные?
    • Численная оценка не намного лучше, чем русская рулетка. Допустим, вы кандидат. Вы потратили последние пару месяцев на изучение каждой темы, которая может иметь отношение к программированию интервью. Предположим, вы подаёте заявку в компанию A. Она просит вас написать алгоритм поиска в двоичном дереве. Отлично! Вы только что закончили изучать двоичные деревья! Вы проходите с честью. Теперь предположим, что вы подаёте заявление в компанию Б. Та просит написать реализацию префиксного дерева. Нееет! Вы забыли его выучить! Из-за того, что вы не изучали эту тему, вы проваливаете собеседование. Теперь поменяйте местами эти компании: предположим, компания Б задаёт вам алгоритм двоичного дерева, а компания A спрашивает о префиксном дереве: ясно, что получение работы в какой-то компании зависит чисто от темы вопроса.
    • Ограничения по времени вредны и дискриминационны. Обычно во время телефонного собеседования на задачу по программированию вам дают 45 минут. Этого достаточно для решения простой задачи. Но когда вас просят написать сложный алгоритм, это просто смешно. Когда меня попросили написать игру «Жизнь», мне потребовалось 50 минут, чтобы получить работающий фрагмент кода, и у меня почти не было времени его протестировать. Когда меня попросили написать алгоритм фильтрации изображений, я потратил первые 15 минут только на то, чтобы понять этот вопрос. У меня кончилось время. Если бы такой сложный алгоритм был написан в реальном мире, вероятно, неделю заняла бы реализация и месяц тестирование. Как минимум. Так почему мы просим инженеров сделать это за 45 минут?
    • Вокруг прохождения собеседований существует смежная индустрия. Все эти задачки на алгоритмы начались с популярных компаний, таких как Google. Потом несколько инженеров из этих компаний увидели возможность заработать несколько долларов, предложив материал для подготовки к собеседованиям. На эту тему были написаны две популярные книги: «Взлом интервью по кодированию» и «Элементы собеседований по программированию». Обе книги предлагают материал для подготовки к интервью. Проблема в том, что индустрия получила доступ к этим книгам и адаптировала свои интервью к их материалу. Но когда люди начали массово отвечать на основные вопросы, изложенные в этих книгах, компании поняли, что фильтрация сотрудников перестала работать. Поэтому они написали новые, более сложные вопросы на алгоритмы, чтобы выделиться и нанимать «более квалифицированных кандидатов из всех, казалось бы, квалифицированных». Существует множество историй о нынешних и бывших инженерах высшего звена в конкретных компаниях, которые утверждают, что процесс собеседования стал настолько трудным, что они сами никогда не прошли бы его сейчас. Например, в одной «топовой» технологической компании процесс заключается в том, что, когда кандидат проходит интервью, по его результатам составляется определённый «пакет» с оценками. Затем пакет направляется в комитет, чья работа заключается в беспристрастном рассмотрении пакета для принятия решения о найме. В какой-то момент один комитет стал настолько критичным, что они в течение нескольких месяцев отклоняли все пакеты. Когда отдел кадров пронюхал об этом, они решили устроить проверку. Они послали комитету новую порцию пакетов, и комитет снова отклонил их все. Затем отдел кадров созвал всех на совещание и объяснил, что пакеты, которые они только что рассмотрели, на самом деле были собственными пакетами членов комитета по найму на тот момент, когда они проходили собеседование в этой компании. Они неосознанно отвергли самих себя! Как можно пройти такую планку?
  3. Почему мы измеряем людей, а не изучаем их? Несколько недель назад я смотрел выступление одного товарища, который провёл большое количество интервью в топовой компании. По его словам, цель состоит в том, чтобы «отточить стратегию извлечения сигнала во время интервью». Что?! Что стало с людьми, которые хотели узнать друг друга? Это отношение кажется таким совершенно роботизированным и, честно говоря, довольно мрачным. Какова здесь логическая последовательность? Будем ли мы сканировать мозг кандидата, чтобы найти сходство с существующими высокоэффективными кандидатами? Это отношение кажется особенно ужасной смесью эгоизма и организационного мачизма. Мне кажется, что сейчас компании больше боятся нанять плохого кандидата, чем радуются возможности нанять отличного. Пока компании не изменят своё отношение, вряд ли улучшится ситуация для кандидатов. Хуже всего то, что кандидат первым делом слышит от рекрутера, какой он отличный профессионал, а как только попадает на собеседование, встречает только подозрения и сомнения в его профессионализме. Я считаю, что подозрительность нужно заменить осторожным оптимизмом.

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

  • Я знаю, как писать софт — за два года я написал около 85 000 строк Java-кода для продакшна, что оказало очень положительное и ярко выраженное влияние на продукт, над которым я работал. Я написал несколько очень сложных реализаций алгоритмов машинного обучения на Python, а также довольно много скриптов. Я написал код embedded C и C++ для различных низкоуровневых приложений, таких как графика на встроенных системах. Я выучил Flutter и опубликовал несколько приложений. Я выучил Clojure, что стало весьма просветляющим опытом. Я работал над кодом C#. Я знаю, как создать статичный веб-сайт. У меня степень по информатике.
  • Не понимаю, почему мне не позволяют писать программное обеспечение — существует фундаментальное несоответствие между публичными утверждениями, что компании отчаянно ищут инженеров-программистов, и жестокой реальностью отсеивания кандидатов. Эти проблемы кодирования под сильным давлением «сделай или умри» кажутся скорее механизмом дедовщины, чем ценным инструментом оценки. Использовать их — всё равно что стрелять в кандидатов на работу полицейского, прежде чем спросить, что они знают о законе.
  • Не знаю, как это выглядит с другой стороны — дело в том, что критикуемый процесс может быть единственным способом, которым компании могут отсортировать хороших и плохих кандидатов. Я никогда не входил в команду по найму, и уверен, что о многом не знаю.

В заключение у меня несколько мыслей:

  • Выживание наиболее приспособленных реально — как бы мне ни хотелось устроиться в известную технологическую компанию, в реальности на эту позицию множество конкурентов. Как и во всём остальном в жизни, ресурсов мало, а желающих много. Каждый хочет получать много денег за написание кода. Подозреваю, что такие агрессивные барьеры отбора ставятся по той причине, что кандидатов с объективно (что бы это ни значило) низким уровнем квалификации намного больше, чем с высоким. К сожалению, вам придётся конкурировать с этим огромным количеством людей независимо от вашего опыта. Как понимает любой разработчик, кривая обучения для получения даже минимального опыта очень крута. Кроме того, ключевые компетенции для успешной работы требуют огромного объёма знаний. Реально трудно освоить определённый набор релевантных и востребованных навыков, а тем более в совершенстве овладеть ими. Независимо от того, какой карьерный путь изберёт разработчик, ясно, что конкуренция — это факт жизни, и в этой отрасли она довольно жёсткая.
  • Иерархии реальны — меня немного смущают существующие звания инженеров-программистов. Видимо, существует только два: сеньор и не-сеньор. Как правило, объявления о вакансиях сеньора требуют пятилетнего опыта. Кажется, классификация несовершенна. Как назвать человека с двадцатилетним стажем? Так же, как и с пятилетним? В моем случае, как назвать программиста с четырёхлетним опытом? Я не новичок. Я знаю, как самостоятельно писать программное обеспечение. Знаю, как работает контроль версий и Agile. В некоторых ситуациях нужны люди, которые определят направление моей работы. Чтобы ещё больше усложнить этот вопрос, есть проблема количества лет работы с определённой технологией. Если у человека пятилетний опыт Java и он переходит в команду Python, в которой только люди с менее чем двухлетним опытом Python, должен ли этот человек считаться джуниором? Это настолько запутанная тема, что она заслуживает отдельной статьи, и даже тогда не уверен, что смогу прийти к ответу. Моя точка зрения заключается в том, что я где-то между джуниором и сеньором, и это кажется тонким выбором для моего уровня опыта.
  • Жаловаться на это бесполезно — рано или поздно мне придётся искать другую работу. Даже если мне не нравится методология, мне придётся снова пройти этот цикл. Но на сегодня с меня довольно. Кажется маловероятным, что я добьюсь чего-то, повторяя один и тот же процесс снова и снова. В конце концов, я снова сяду на эту карусель, но пока выберу единственный вариант, который сохранит моё душевное здоровье:

    Выйти из цикла.

    См. также:

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 124

    +17
    Два менеджера по персоналу — опытный и стажёр — сидят в офисе и обсуждают дела. Молодой достает огромную пачку резюме, штук 300:
    — Мы должны просмотреть их все, чтобы подобрать кандидатов на эту вакансию.
    Опытный хладнокровно берет у него пачку, делит ее пополам, одну часть — на стол, вторую — в корзину.
    Молодой изумленно:
    — А как же претенденты?!
    Опытный невозмутимо:
    — А зачем нам неудачники?..

    Выбрасывать резюме запретили, но претендентов по прежнему слишком много, вот и отсеивают с помощью сверхсложных задач на первом собеседовании. Компании по прежнему не нужны неудачники.
      +2
      вот вы будете смеяться, но увы.
      я лет десять тому назад занимался собеседованиями (угу, молодой был, горячий).
      Сейчас, оглядываясь назад, могу только сказать «все почти так».
      Задавали алгоритмы, но реально нужно было 1-2 человека из 10, и нанимали не «тех кто решил задачку» — таких было много, а разбивали на группы по 5 человек и нанимали «тех, кто решил задачку лучше всех в его группе» + рассказал «почему оно работает» (ака софтскилл)…
      Почему-то меня посещает уверенность, что на самом деле такое происходит и сейчас.

      PS: зато треть нашего отдела были программистки!
      PPS: собеседованиями я больше не занимаюсь ни как испытующий, ни как испытуемый.
      +6

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


      P.S. На нескольких собеседованиях попробовал задать встречный вопрос из области "tell me about a time when you...". Все как один несли несусветную чушь, которая никоим образом не отвечала на поставленный вопрос. Это всё, что нужно знать про поведенческие (behavioral) собеседования. В следующий раз попробую задач встречный вопрос на алгоритмы.

        +19
        «Шо, опять?!» (с) известный мультфильм.

        (присаживается поудобнее в кресло-качалку, накрывается клетчатым пледом, наливает в кружку что-то горячее с молоком, отхлебывает)

        А ведь я застал-с те времена, когда знание алгоритмов всяческих там сортировок, деревьев и прочих списков было обязательным, да-с…

        Лет двадцать пять назад, когда программы были маленькие, а 640 килобайт еще многим хватало, я непосредственно и всегда использовал эти самые алгоритмы и структуры данных. В этом было целое искусство — как бы так написать, чтобы втиснуться в требования задачи…

        Вся работа начиналась вот примерно с таких креативов
        struct foo_nlist {
            struct foo_nlist* next;
            ...
        };
        
        struct foo_nlist* foo_lookup(struct foo_nlist* root, ...);
        struct foo_nlist* foo_insert(struct foo_nlist* root, ...);
        struct foo_nlist* foo_remove(struct foo_nlist* root, struct foo_nlist* elem);
        

        в тяжелых случаях вытаскивался препроцессор
        #pragma pack(1)
        
        struct nlist_header {
            struct nlist_header* next;
        };
        
        #define DECLARE_LIST_ENTRY(foo_nlist_name, foo_type) \
            struct foo_nlist_name { \
                struct nlist_header header; \
                foo_type value; \
            }
        
        struct foo {
            ...
        };
        
        struct bar {
            ...
        };
        
        #define TO_VALUE(header, foo_type) \
            ((foo_type*)((char*)(header) + sizeof(struct nlist_header)))
        #define TO_LIST(value) \
            ((struct list_header*)((char*)(value) - sizeof(struct nlist_header)))
         
        DECLARE_LIST_ENTRY(foo_nlist, struct foo) foo_root;
        DECLARE_LIST_ENTRY(bar_nlist, struct bar) bar_root;
        
        struct nlist_header* nlist_lookup(struct nlist_header* root, ...);
        struct nlist_header* nlist_insert(struct nlist_header* root, ...);
        struct nlist_header* nlist_remove(struct nlist_header* root, struct nlist_header* elem);
        

        На этом полет креатива не останавливался — появлялись mutex для параллельной работы, списки менялись на деревья и прочая, а для работы со структурами данных изобретался паттерн visitor в стиле «лямбд пока не завезли»:

        #define FOR_EACH_NLIST(foo_type, item, nlist) { \
            for(struct nlist_header* hdr = (nlist); hdr; hdr = hdr->next) { \
                foo_type* item = TO_VALUE(hdr, foo_type);
        #define FOR_EACH_END() \
                }\
            }
        ...
            FOR_EACH_NLIST(struct foo, foo_item, foo_root) 
                if (foo_item-> ..) {
                    FOR_EACH_NLIST(struct bar, bar_item, bar_root) 
                        ...
                    FOR_EACH_END()
                }
            FOR_EACH_END()
        


        Это сейчас за такое я джунов луплю по рукам линейкой не одобряю, а тогда… тогда даже строки были квадратно-колесными, и в приличном проекте их было полдюжины разных. Роднило их только одно — все они умели в char*, а наиболее грамотные — еще и в const char*.

        Это сейчас за попытку изобрести свой аналог std::string ваш лид спросит — в своем ли вы уме, а 25 лет назад он бы поинтересовался, как это удалось сделать copy-on-write и при этом работающую форму
        str[n] = 'a';
        и как при этом избежать O(n^2) в случае классики
        result = a + "\\" + b +"\\" + c + "." + d; 


        Следом обычно шел кастомный аллокатор, современный tcmalloc() тогда тоже еще не завозили, и героическая борьба с memory leaks…

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

        Вот честно сказать, если бы я в то время ушел «на руко-водящую работу», больше бы не программировал (ну кроме макросов в экселе), и мне бы вдруг! надо было бы отсобесседовать молодежь — я бы вспомнил именно про алгоритмы :-)

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

        А вот когда я грозно бы спросил про о-большое в случае реализации ArrayList на вставку в середине — я бы и произвел нужное впечатление на молодняк, и хотя бы смог бы понять их ответ :-)
          +4

          Все осталось… И велосипеды и прочее. Только применяется для всяких avr, stm и тд…

            +2
            да ладно! Буквально сегодня я написал в коде «для AVR» около 32 вложенных IF, так как это для данной задачи оптимально.
              0
              А можно увидеть такой код с минимальным описанием, почему столько вложенных условий?
                0
                Вложенность убрал, а то просто нечитаемо было… Там простой перебор битов в нескольких массивах для включения соответствующего светодиода в матрице.

                Страшно, аж жуть ))
                Пишу на Bascom (синтаксис почти как у Бейсика, структура кода- как в Паскале), выбрал после работы с пром.контроллерами и их языком ST.
                image
                  +3
                  а нельзя Matrica_right_x3 = Led_edin(1).5 написать?

                  немогу
                  matrica…
                  рукалицо
                    0
                    можно, но генерирует бОльший код.
                    upd Спасибо за идею (ну, не саму идею, а то, к чему она привела ))), сэкономил 100 байт ))

                    а надо! ;)
                    «немогу» — НЕ с глаголами пишется раздельно

                    Согласен с вами полностью, надо причесывать код! И причешу, но уже во вторник.
                    А я сегодня спал 4 часа, не больше: надо запустить три полученных платы (разные проекты), оживить дабы показать руководству варианты.
                    0

                    У меня похожее было в часиках на ин-18

                      0
                      да-да, а что делать..?
                      проще усложнить код, чем делать 16 лишних переходов между слоями на плате.
                      Фото дисплея
                      image
                        0
                        Да ладно вам, сложность плат еще никого не пугала!
                        image
                          0
                          Да без проблем.
                          Показать свои не могу: договор прямо запрещает…
              0
              Это сейчас за попытку изобрести свой аналог std::string ваш лид спросит — в своем ли вы уме,


              И вот тут у меня возникает вопрос — а как сейчас в эту строчку std::string помещают значение какой-либо переменной? Аналог sprintf, то есть. А то я по старинке sprintf использую до сих пор в таких случаях.
                +10

                640 КВ? Да вы, батенька, зажрались. Мы писали систему сбора данных с датчиков, обсчета разных параметров и трехмерной эмуляции ядерной реакции в активной зоне (диффуры в частных производных), все в реальном времени, на 128 КВ — и там же работала ОС. В-)

                  +8
                  Об этом нужен пост!
                    0
                    А вот об этом в Шентоне на попойках ты не рассказывал...:))
                      0

                      ))) А ты не спрашиаал.

                    +3
                    std::stringstream ss;
                    ss << anything_you_want;
                    std::string s = ss.str();
                      0
                      Спасибо! Вот этот вариант я видел, но он мне показался очень неудобным.
                        +2

                        Есть мнение, что он заметно тормознее, чем snprintf и что лучше юзать штуки типа fmtlib или std::format.

                        +2
                        Все так же — кто во что горазд. Вплоть до сумрачных фантазий из 90х, типа такого
                        str.reserve(1024);
                        ...
                        sprintf(str.c_str() + ::strlen(str.c_str()), " %d %d:", i, j);
                        за что хочется немедленно убить на месте, съесть и закопать. Но с другой стороны, что предлагает нам комитет?
                        str.reserve(1024);
                        ...
                        str += " " + std::to_string(i) + " " + std::to_string(j) + ":";
                        это как бы не сильно лучше :-)

                        Да, второй вариант категорически неправильный. Но что с правильным?
                        std::stringbuf buffer;
                        std::ostream os (&buffer);
                        os << str << " " << i << " " << j << ":" ;
                        os.flush();
                        str = buffer.str();
                        И так — во всех местах, где надо форматный вывод? Да ну нафиг, что там с неверным вариантом, может уже не так плох? :-)
                          0
                          Спасибо!
                            +1

                            Собственно, не просто так в 20-й стандарт добавили новую библиотеку для форматирования строк https://en.cppreference.com/w/cpp/utility/format

                              0
                              это как бы не сильно лучше :-)

                              Визуально хоть пытается выглядеть не ужас-ужасом, не?

                                +1
                                str.reserve(1024);
                                ...
                                str += " " + std::to_string(i) + " " + std::to_string(j) + ":";
                                Визуально хоть пытается выглядеть не ужас-ужасом, не?

                                Зато сколько тут копирований и вызовов небесплатного и недешевого аллокатора… вроде бы (вроде бы!) мы не должны за это все радостно платить, а по факту — ух!!!

                                Давайте попробуем удешевить.
                                str.reserve(1024);
                                str += " " += std::to_string(i) += " " += std::to_string(j) += ":";
                                Вот так уже несколько лучше. std::to_string() все еще делает много лишнего, но это уже лучше. Теперь — задумаемся, а в правильном ли порядке идут вычисления, и не добавить ли скобок? А то присваивания идут справа налево…
                                str.reserve(1024);
                                (((((str += " ") += std::to_string(i)) += " ") += std::to_string(j)) += ":");
                                Ну и кто в здравом уме будет так писать?

                                Не, в Java/C# это решали умные люди, у них компилятор автоматом преобразует строчные плюсики в
                                str = (new StringBuilder(N)).append(...).append(...).toString();
                                и это все еще хуже, чем ветхозаветный sprintf(), но значительно лучше чем постоянные аллокации / копирования. Почти полный эквивалент той травы что чуть выше в скобках. Ну и плюс свои накладные расходы несет, на аллокацию объекта и массива у него внутри.

                                Пайтонисты и дотнетчики пошли еще дальше — и у них в строчках прямо переменные указывать можно, типа такого
                                str += $" {i} {j}:";
                                и некоторые даже этим злоупотреблять научились, указывая вместо переменных многоэтажные конструкции :-)

                                Вы спросите, так а чем не нравится путь комитета? Тем более stringstream завезли, стало чуть проще…
                                std::stringstream ss;
                                ss << << str << " " << i << " " << j << ":" ;
                                str = ss.str();
                                Вполне же?

                                Давайте вспомним, как часто и зачем нам надо в коде много форматирования? Вот именно, логи! И что, нам теперь по три строчки каждый раз вставлять, и плодить локальных переменных? Не, конечно можно… но лениво.

                                Неужели все так плохо?

                                По счастью, нет. В новейшем стандарте завезли std::format! Господь услышал наши молитвы!

                                Что делать олдфагам тем, у кого легаси? Нууу, в принципе, можно вот как-то так вывернуться —
                                #include <memory>
                                #include <string>
                                #include <stdexcept>
                                
                                template<typename ... Args>
                                std::string string_format( const std::string& format, Args ... args )
                                {
                                    size_t size = snprintf( nullptr, 0, format.c_str(), args ... ) + 1; // Extra space for '\0'
                                    if( size <= 0 ){ throw std::runtime_error( "Error during formatting." ); }
                                    std::unique_ptr<char[]> buf( new char[ size ] ); 
                                    snprintf( buf.get(), size, format.c_str(), args ... );
                                    return std::string( buf.get(), buf.get() + size - 1 ); // We don't want the '\0' inside
                                }
                                но тут наш sprintf все еще с нами и у него все те же проблемы несоответствия фактического списка параметров и декларированных спецификаций форматирования. Да и кроме примитивных типов есть еще и структуры-классы, они снова идут мимо.

                                И зачем я это все вспомнил -\_(o^o)_/-
                              +1

                              std::string foo = "bar";
                              Аналог sprintf — std::format / fmt::format (лучше по всем параметрам).

                                0
                                А в std::format можно сделать простым способом вывод числа с n-дополненными нулями до запятой и m-цифр после запятой?
                                И тут уже писали, что это 20 стандарт.
                            +1
                            Вот честно сказать, если бы я в то время ушел «на руко-водящую работу», больше бы не программировал (ну кроме макросов в экселе), и мне бы вдруг! надо было бы отсобесседовать молодежь — я бы вспомнил именно про алгоритмы :-)

                            А почему, если вы сами же только что сказали, что сейчас это не нужно? Эффект утенка?

                              +2
                              Он же написал — потому что сам бы не осознавал, что это уже ненужно (он много лет занят другим) ну и потому что в этом он (не реальный, тот, из примера) разбирается, а в современных реалиях разработки — нет.
                                +2
                                Вот насчет «не нужно» — споры как раз и идут. Оно наверное все еще полезно, уметь в структуры данных, обычно это хэштаблицы-списки-кольца-деревья, графы уже сильно реже. Но это неточно :-)

                                Шутка в том, что я еще помню, как задача транспонирования матрицы занимала несколько суток, занимая при этом весь объем — нет, не тогдашней оперативы, а тогдашнего жесткого диска! и я тогда самолично изобретал — как это в почти 3 мегабайта кэша воткнуть работу с матрицей, которая сводится к треугольному виду методом Гаусса. Lookahead и вот это вот все, чтобы диск не трещал так жалобно своими головами.

                                Причем даже не «повысить перформанс», а потому что «в лоб» предыдущий диск за выходные сгорел. :-)

                                Уже в двухтысячных — такие матрицы просто помещались в оперативе, их сводили стандартным матпакетом или на пайтоне, и перформанс вообще никого не волновал.

                                Теперь сотни мегабайт воспринимаются как «лабораторная работа», тут вообще нечего делать. Что тут оптимизировать?..

                                Соответственно в мейнстриме и «тюнинг» структур данных и алгоритмов вокруг них — нет, не исчез! но сильно изменился :-)
                                  +1
                                  Вот насчет «не нужно» — споры как раз и идут.

                                  Не понятно, что тут спорить. В каких-то задачах — нужно, в каких-то — нет.


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


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

                                  Ну а сейчас эти 3мб надо упаковать в процессорном кэше ;)

                                +1
                                Лет двадцать пять назад, когда программы были маленькие, а 640 килобайт еще многим хватало, я непосредственно и всегда использовал эти самые алгоритмы и структуры данных. В этом было целое искусство — как бы так написать, чтобы втиснуться в требования задачи…


                                И сейчас оно никуда не делось. Есть почти во всех Сишных библиотеках. Например, в ffmpeg этого добра навалом. Чтобы прикрутить более-менее сложную фичу, 20% времени тратишь на разработку, остальные 80% изучаешь особенности работы кастомных аллокаторов и контейнеров типа FIFO очередей. Потом обновляешь конфигурации в Makefile'ах.

                                Вкратце: получаешь незаменимый и нерелевантный опыт.

                                  0
                                  Вкратце: получаешь незаменимый и нерелевантный опыт.
                                  … и чем древнее изначальная кодовая база — тем больше этого опыта и получаешь :-)
                                  +2
                                  Маааам, дедушка опять забыл принять свои таблетки!
                                    +1
                                    Господи, зачем я все это понимаю… ^_^
                                      0
                                      Самое любопытное, что вот оно подаётся вроде как старое и отжившее, а тут я вспоминаю, как встречал всё это в достаточно свежих проектах на работе С++ программистом всего пару лет назад. А в самых свежих проектах еще и шаблонная магия добавляется в ненормальных дозировках.
                                    –14
                                    Хаха, готовился три месяца и думал, что готов к гуглособесу. Салага…
                                      +5

                                      Странно, почему игра Жизнь оценивается автором так высоко; там же простейший цикл по клеткам минут за 10 пишется, в отличие от других упомянутых им алгоритмов.

                                        0

                                        У наивной реализации Жизни ужасная производительность

                                          0
                                          CUDA поможет с этим справиться. :)
                                            +3
                                            Мне кажется, там линейная зависимость от числа клеток поля, и написать что-то с худшей асиптотикой — еще надо постараться. Или я не прав?
                                              0
                                              Константу можно менять на порядки.
                                              +2

                                              Я сомневаюсь, что на телефонном собеседовании хотели бы увидеть hashLife какой-нибудь.


                                              Тупое наивное решение, которое работает, позволило бы пройти дальше. Там единственный спецэффект вокруг обработки границ может быть. Ну еще можно запутаться в 8 одинаковых кусках кода, если не додуматься до констант сдвигов dx и dy, или хотя бы двух вложенных циклов -1...+1.


                                              Для сильного кандидата предполагается, что останется время пообсуждать, как это можно ускорить: Распараллеливание, векторизация, битовое сжатие всякие. Писать всякие хитрости тут 100% не требуется.


                                              Телефонные собеседования имеют весьма низкую планку.

                                                0
                                                За гугл могу сказать что «планка» на телефонных интервью точно такая же как на onsite. (не путать с предварительным hr-скринингом) и критерии оценки те же самые. В которые, внезапно, софт скиллы входят в полной мере, просто оцениваются они опосредованно по результатам диалога в процессе решение. Ну и да, решение задачи как таковое — не самоцель.
                                                  +1
                                                  За гугл могу сказать что «планка» на телефонных интервью точно такая же как на onsite

                                                  Не совсем.


                                                  Если вы проводите интервью в гугле — поищите "technical phone screen guide". Первая же ссылка будет содержать слова вроде "you would want to cast a wider net than during an onsite". Цель телефонных интервью — отсеять совсем слабых кандидатов. Поэтому планку там рекомендуется понижать.


                                                  Конечно, зависит от конкретного интервьюера, да и инструкции и реальность могут различаться на практике. Но предполагается, что TPS легче on-site.

                                                    0
                                                    У меня итак планка пониженная :-)
                                                    Мне кажется интервьюверы все равно по одному шаблону работают. Те же задачи, те же критерии оценки.
                                            +20

                                            Удивительньнее всего, что по таким собеседованиям кажется что там работают сверх люди. Пока миллиард учётных записей не утечет от какой-то тупой ошибки

                                              +12
                                              Удивительньнее всего, что по таким собеседованиям кажется что там работают сверх люди.

                                              Наоборот же, там работают люди, которые сами не прошли бы в свои критерии ;-)
                                                +2
                                                да нет, там работают сверхлюди которые ТОЛЬКО и умеют что делать такие задачки… а всякие учетки и прочее ИБ и всякие баги — это не про них
                                                  0

                                                  Большинство работающих там людей — таки сами прошли такие же интервью.

                                                    –1
                                                    Большинство работающих там людей — таки сами прошли такие же интервью.
                                                    … а также они набили «боинг» шариками от пинг-понга и обосновали круглость люков :-)
                                                      0

                                                      Гугл уже давно спрашивает алгоритмические задачки. И нанимает активно. Людей, которые круглость люков обосновывали в гугле — меньшинство.

                                                  +16
                                                  Да ровно так же везде. Сначала на собеседовании тебя долго пытают пишите ли вы тесты, как пишите, почему пишите, что делаете чтобы писать лучше, а после найма выясняется что тесты в компании по древней легенде пишут 1.5 человека и никто не знает как их зовут.
                                                    +7
                                                    Я тут недавно недавно запоем наконец-то проглотил «Мистера Робота». Сериал, конечно, потрясающий, но я сейчас не о том.

                                                    АХТУНГ!!! НИЖЕ СПОЙЛЕР!!!

                                                    Мне понравился комментарий одного обзорщика на ютубе, который «оборзел» некоторые самые популярные вопросы, которые возникают после просмотра сериала. Итак, вопрос: как же так, почему не заработало (и, судя по всему, и не должно было) титаническое устройство Белой Розы, на которое он и его соратники положили свои жизни и жизни кучи невинных людей? Ведь это был такой серьёзный суперпроект, которым занимались такие серьёзные люди!
                                                    А ответ прост. Это известное в психологии когнитивное искажение (которым, кстати, успешно пользуются мошенники на доверии): почему-то все уверены, что если солидное лицо, в галстуке, с умным выражением физиономии и не менее умными словами изо рта, да ещё и с правильной «корочкой», что-то делает — то это априори что-то очень важное, нужное, умное и куда уж туда нам, со свиным рылом в калашный ряд. А на самом деле, если отбросить галстуки и вот это всё — ведь это самые обычные люди в большинстве случаев, если не хуже (ну, может, чуть более наглые и самоуверенные). Которые, в полном соответствии со словами киношного Мюнхгаузена, с умным выражением лица постоянно творят несусветную чушь.

                                                    Так что поменьше верьте галстукам и баззвордам, it's a trap :))
                                                      +1

                                                      В статье обсуждается гугл… У них где-то утекал миллиард учетных записей? Ну или что-то типа того?

                                                        +1
                                                        У Микрософта, когда-то были похожие собеседования. Попытался я перейти с Ёкселя 2003 на 2010. В логе с прибора десять столбцов примерно по 20000 точек. Десять графиков.
                                                        2003-й перерисовывает весь экран десяток раз (по числу графиков). 2010 — порядка 100( примерно n^2). Более двух минут. Это пусть и на стареньком, но i7. Куда, мать их, все эти чудо-алгоритмисты подевались?
                                                          0

                                                          Ничего не могу сказать про microsoft. Возможно это издержки их stack ranking, который просто помножил на 0 все старания инжинеров.


                                                          Думаю не зря в FAANG нет буквы M.

                                                      +8
                                                      Еще один все понял (с).

                                                      Автор конечно молодец, однако, как мне кажется, не до конца разобрался с тем как эти интервью все-таки работают. И возможно в этом и заключена его проблема. Задача на
                                                      этих интервью в большинстве своем просто повод поговорить, ее даже не обязательно решать до конца, чтобы пройти (более того, скорее всего она будет усложнена в случае успешного решения, так, чтобы человек не успел ее дорешать до конца) и автор очень зря считает что софт скиллы во время этих интервью не оцениваются. Возможно причиной отказа было не то, что алгоритм плохо получился, а как раз плохая оценка по софт скиллам. Есди автор во время собеседования угрюмо молчал, не шел на контакт с интервьюрующим, рассказывал какие все в текущей компании мудаки и он один в белом пальто стоит красивый, вполне… вполне вероятно что не прошел именно по софт скиллам. Именно потому что все работают в команде и это важно.

                                                      Плюс после изначального «телефонного» интервью в гугле и других подобных компаниях идет уже серия интервью пара из которых как правило чисто разговорные (ну там «дизайн» и «за жизнь» например). Но даже в чисто алгоритмических интервью в критерии оценки входит часть с «софт» скиллами. Даже в изначальном телефонном интервью.
                                                        0
                                                        забавно, но я на таком интервью фактически до конца не решил ни одной задачи (правда, рассказал каким образом я бы их доделал если бы был поумнее время не закончилось) и был совершенно уверен, что интервью я с треском провалил, хотя с интервьюерами общение было довольно теплым и приятным. В любом случае опыт получился весьма интересным, я его положил в собственную копилку и успокоился. Каково же было мое удивление, когда через пару дней мне перезвонили и сообщили, что интервью пройдено успешно, при этом с неплохим(!) результатом. Что это было, черт возьми?! Как?!
                                                        К сожалению, сотрудничество в итоге так и не состоялось в силу иных причин, но о прецеденте до сих вспоминаю с улыбкой.
                                                          +3

                                                          Однажды собеседовал парнишку на его первый настоящий контракт. В тестовых заданиях последним пунктом шла задача на алгоритм, которую мы в принципе не требовали (важен был процесс мышления), тем более от джунов. Но он написал и так ладно объяснил, что хотелось посмотреть, до куда можно докопать. В итоге кучей дополнитедьных вопросов я его вывел на оптимизацию алгоритма. Когда я уходил из той компании он рассказал, что был уверен, что на моих вопросах засыпался и работа у нас ему не светит. А на самом деле ещё до конца интервью мы решили, что сорвали джекпот и дали добро на найм.

                                                        +8
                                                        Мне кажется, что сейчас компании больше боятся нанять плохого кандидата, чем радуются возможности нанять отличного.

                                                        Парниша, об этом крупные компании во всеуслышанье заявляют! False negatives are okay. Вот ты гениален и тебя не наняли — и фиг с ним. Лишь бы не получилось false positive — когда ты бревно, а тебя наняли.
                                                          +16
                                                          False negatives are okay.

                                                          Почему одновременно с этим все те же самые лица ноют (да, именно «ноют» и именно «все те же самые»), что специалистов всё сложнее и сложнее искать? Выглядит как методичный отстрел своей ноги с жалобами, что чё-то больно.
                                                            +4
                                                            ну раньше они (те, которые ноют) были молодыми модными стартапами, а теперь свежие сверхумные ребята идут в свои стартапы (которые «внезапно» — другие компании). Понятно, что «это обидно» (сарказм моде офф)
                                                              +1

                                                              К тому же в стартапы таки проще попасть.

                                                                +1
                                                                вот только платить там хотят «акциями моего будущего предприятия» :)
                                                                Это из личного, когда нанимали разработать ВСЮ автоматику + электрику для пивоварни…
                                                                  0

                                                                  Ну почему же? Многие готовы и зарплаты платить неплохие, просто прямо говорят, что все может прогореть, когда не получится на следующем раунде получить инвестиции.
                                                                  То есть, если иметь в запасе денег на полгода жизни без работы, то можно вполне смело ввязываться в стартапы.

                                                                    0
                                                                    почему полгода?
                                                                      0

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

                                                              +1

                                                              Да пёс с ними, пусть ноют. Что нам, жалеть их, что ли? Кто бы мелкие компании пожалел, а эти как-нибудь уж проживут, можно не беспокоиться.

                                                            0

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

                                                              +5
                                                              А почему вы считаете что гуру в одной технологии не может разобраться в новой теме и начать делать?
                                                                +1
                                                                зачастую человек полностью погруженный в одну технологию — узкий специалист, который даже переходя в другую начинает тащить за собой решения и паттерны из «своей родной-правильной»
                                                                  +4
                                                                  Но зачастую — нет.
                                                              +4
                                                              Интересный факт что большинство HR-щиков очень медленно читает. Часто даже не могут осилить и прочитать в резюме несколько связных предложений. Это странно.
                                                                +2
                                                                Вывод — нужно меньше нервничать и просто делать свое дело (искать работу)?
                                                                  0

                                                                  Для тех кто видит себя на месте автора. Если вы умеете программировать и не комплексует быть нердом ботаном — идите во фриланс. Там это щедро оцениться звонкой монетой. После пары лет во фрилансе работа во всех этих компаниях будет казаться детским мышиной возней (чем она в общем то и является).

                                                                    +4
                                                                    Большие и значимые проекты, как правило, не доверяют фрилансерам. «Создать» типовой сайт — это пожалуйста. Разрабатывать огромный проект с миллионами пользователей — это вряд ли.
                                                                      0
                                                                      Какие именно преимущества фриланса вы имеете ввиду?
                                                                        0
                                                                        Только как часто на фрилансе попадаются такие предложения?
                                                                        +17
                                                                        Просто примите, как работоспособную гипотезу, что у нас:
                                                                        • ПЕРЕИЗБЫТОК подходящих по скиллам программистов в компании с высокими зарплатами
                                                                        • НЕДОСТАТОК подходящих по скиллам программистов в компании с низкими зарплатами.


                                                                        Поэтому крупные лавки с хорошими зарплатами выбирают людей по очень искусственным признакам, могут себе позволить. И могут себе позволить false negative is ok. И могут позволить себе набирать overskilled. Все равно за забором трется еще пара десятков не менее крутых разрабов.

                                                                        Лавки с плохими зарплатами ноют, т.к. к ним просто никто не хочет идти. И из-за денег и из-за коллектива.

                                                                        Вот и вся мистика.
                                                                          +1
                                                                          Ну нет же. Иначе из этих крутых лавок не выходила бы всякая говнотека ± среднего индусского уровня. Они не набирают самых крутых, они набирают квадратно-колёсных, подходящих для локального прокрустова ложа. В том то и дело, что реально уровень инженера оценивать не умеют / не научились / лень / etc.
                                                                            +1
                                                                            из этих крутых лавок не выходила бы всякая говнотека ± среднего индусского уровня
                                                                            Это вещи слабосвязанные.

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

                                                                            И выбора у него нет — говнокод или говнокод :-)

                                                                            А бывает еще круче. Бывает что саентисты по скраму должны выдавать прорывные инвеншены по тикетам (сам такое видел, офигел в край и быстро убег). Результат? Зачем?
                                                                          +1
                                                                          Коллеги, вы упускаете еще одну большую брешь в собеседованиях — личность и амбиции того, кто собеседует. Эти люди тоже неидеальны, имеют свои страхи и гордость. Сколько собеседований было провалено, просто потому, что техлид побоялся взять человека, который, вероятно, лучше чем он сам. Из личных наблюдений — был на собеседовании, где последнее слово было за уже уволившимся сотрудником, который пообещал «помочь пособеседовать людей» после увольнения. Так этот сотрудник просто тешит свое ЧСВ без каких либо последствий для себя.
                                                                            +2
                                                                            Это мало относится к гуглу, у гугла система такая что собесетуют «в общем», в гугл в целом. И вероятность того что собеседующий и собеседуемый хотя бы пересекутся впоследствии крайне, как говорится, мала. После успешно пройденного собеседования уже начинается собственно подбор команды. Ну на линейные позиции по крайней мере.
                                                                              +2

                                                                              Хочу еще добавить, что в гугле решение принимает не один человек-интервьювер, а аж целый комитет, который читает отзывы интервьюверов. Я, как интервьювер, не могу сказать "не нанимать этого". Я должен сказать, "кандидат плохо программирует, потому что вот его код. Вот подсказки, которые я давал, но за 30 минут кандидат ничего нового не сделал". И так по нескольким критериям — все с обоснованиями. Конечно, есть возможность, что интервьювер выдумает весь отчет, чтобы провалить персонально противного ему кандидата, но это должно быть редкостью. И отчетов аж 4-5 штук для одного кандидата! Даже если один из них strong no hire, могут кандидата нанять.

                                                                              +5

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

                                                                                –4
                                                                                Ваш подход — это примерно как при выборе жилья отказываться смотреть квартиру в доме, если вам не понравился цвет дверной ручки в подъезде.
                                                                                  +1
                                                                                  У вас некорректная аналогия. Домашнее задание — это скорее уборка квартиры перед ее просмотром.
                                                                                  P.S. Не отказывался смотреть из вежливости, но заранее отбрасывал вариант если мне по тем или иным причинам не нравился подъезд.
                                                                                    +1
                                                                                    Тут смысл не в аналогии, а в том, что наличие/отсутствие тестового задания при приёме на работу вообще не имеет никакой корреляции с тем, хорошее будет по факту место или плохое. Это надо выяснять на собеседовании с непосредственным начальником и с потенциальными коллегами. А на тестовое задание внимание не обращать, по крайней мере, если оно не такое, что требует от вас реальных усилий и траты рабочего времени.
                                                                                      0

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

                                                                                    +2
                                                                                    Если люди не ценят моё время, то это уже звоночек, что работать с ними может быть тяжело
                                                                                    +1
                                                                                    Хз, если задание интересное — можно и сделать. Чисто по фану.
                                                                                      0

                                                                                      Возможно. Чисто теоретически. Но я таких не встречал)

                                                                                    +5
                                                                                    Ну, тут ведь ещё надо понимать, что дело было наверняка в Америке, автор наверняка просил хорошую зарплату и всем этим компаниям был нужен не ответ на вопрос «умеет ли он найти К-наибольшее значение в бинарном дереве», а ответ на вопрос «нужно ли нам нанять вот этого американца здесь и сейчас вместо трёх индусов или украинцев удалённо, даст ли он больший выхлоп для нашей компании, чем они?». И поэтому если он просто «да, смог» — то ответ на второй вопрос «он ничем не лучше других». Вот если бы он это смог за полторы минуты, или из 5-ти возможных вариантов сразу выдал лучший, или сослался на свою же статью с обзором возможных вариантов решения этой проблемы — вот тогда ответ был бы «да, этот лучше других, надо брать».
                                                                                      +1
                                                                                      Кстати, вы упомянули Америку,
                                                                                      или сослался на свою же статью с обзором возможных вариантов решения этой проблемы

                                                                                      Это действительно правильный вариант действий при собеседовании?

                                                                                      я эмпирически пришел к такому выводу на собеседованиях в РФ, что надо не тупо решать задачу в лоб, а вести диалог по поводу её решения и вообще адекватности
                                                                                      интересно насколько такой подход применим за бугром
                                                                                        0
                                                                                        Это действительно правильный вариант действий при собеседовании?

                                                                                        Это скорее удачное совпадение, которое возможно, если у тебя таких статей за плечами тысяча и, конечно, невозможно, если их тупо ноль. Диалог о решении — однозначно лучше, чем молча тупить в пустой экран. Но хуже случая, когда ты всё-таки сразу пишешь лучшее решение :)
                                                                                          0
                                                                                          Но хуже случая, когда ты всё-таки сразу пишешь лучшее решение :)

                                                                                          Не лучше ли в этом случае совпровождать свое решение рассказом, поясняя почему оно лучшее, какими были другие варианты и т.п.?
                                                                                            0
                                                                                            А это уже не будет диалог :)
                                                                                          0
                                                                                          Такой подход из-за бугра и пришел.
                                                                                          Задачу «в лоб» кстати решать не то чтобы прям не надо. Зачастую наивная реализация очень быстра и дает правильную базу для дальнейшего конструктивного диалога.
                                                                                          +2
                                                                                          дело было наверняка в Америке, автор наверняка просил хорошую зарплату и всем этим компаниям был нужен не ответ на вопрос «умеет ли он найти К-наибольшее значение в бинарном дереве», а ответ на вопрос
                                                                                          … можно ли его отшить так, чтобы он не подал на нас в суд за дискриминацию по Х признаку
                                                                                            +1
                                                                                            Зачем тогда вообще звать на собеседование — чтобы всех отшивать? Я думаю задача была всё-таки взять кого-то умного.
                                                                                          0
                                                                                          Очень занятно, было интересно почитать и подчеркнуть для себя что-то. Спасибо.
                                                                                            +2
                                                                                            Как-то некоторое время назад увидел вот такое мнение о алгоритмических задачках:
                                                                                            Независимо от пользы умения щёлкать литкод, вы по крайней мере знаете чего от вас на собеседовании ждут и как к этом готовиться.

                                                                                            И в принципе я частично с этим согласен. Недавно начал собеседоваться в эти самые софтверные гиганты (и другие компании использующие тот же процесс) и в принципе рад, что готовиться можно универсально.
                                                                                              0
                                                                                              FAANG не могут взять всех, кто к ним подается, поэтому можно решать все на A+, и все равно получать отказы. Хотя задачки, которые они задают на интервью – иногда за гранью разумного, особенно с учетом временных ограничений и того, что интервью идут четыре-пять часов подряд, одно за другим.

                                                                                              С другой стороны, без кодинга на интервью не обойтись, потому что каждый второй кандидат – с роскошным резюме, увешан референсами и soft skills, но не может найти максимум в массиве.
                                                                                                0
                                                                                                И то и другое плюсую. Найди максимум в массиве, обойди js-объект и замапь одну структуру на другую — это реально надо спрашивать, ну должен ты это уметь. Но задачки на динамическое программирование, ну е-мое.
                                                                                                  0
                                                                                                  Вы просто поймите что эти задачи совершенно необязательно дорешивать до конца чтобы «пройти». Более того хороший интервьювер все равно будет модифицировать и усложнять условия таким образом чтобы вы ее не решили. Зато то, докуда вы дорешали, КАК именно вы это делали и вели себя в процессе (обосновывая какие-то логические выводы, проверяя граничные условия, задавая уточняющие вопросы, показав что вот в принципе так решать вот дорешал бы) — вот это важно.
                                                                                                  0
                                                                                                  Немного покритикую статью.
                                                                                                  1) Сейчас на алгоритмических интервью в основном все-таки спрашивают задачи где надо придумать алгоритм (при этом можно не особо знать хоть какие-то алгоритмы вообще), либо «составить» эффективный алгоритм, благодаря знанию «алгоритма». Примерами здесь могут быть как раз та самая задача, упомянутая в статье про K-тый максимум (эта задача уже баян баянистый), который по сути опирается на знание работы быстрой сортировки. Либо, задачки на промоделировать что-то в лоб (только обойтись наименьшим количеством кода). Видел только один раз когда спрашивали написать почти напрямую алгоритм Дейкстры.
                                                                                                  По поводу того, что задачу необязательно дорешивать: частично правда. Но нужно хотя бы словами успеть рассказать эффективный алгоритм.
                                                                                                  2) Можно конечно бесконечно ныть, что алгоритмы не нужны. Можно попробовать их все-таки освоить (готовясь к интервью) и оглянуться на свой код, который когда-либо был реализован. Возможно, станет сюрпризом, что что-то можно было сделать проще, эффективнее, быстрее.
                                                                                                  3) По поводу soft skills и behavior questions. В настоящее время рекрутеры снабжают информацией о базовых принципах компании. На каждый из этих принципов нужно подобрать (придумать в крайнем случае) историю. Встречный вопрос интервьюверу тут неуместен, так как он(а) не придумывал(а) историю, идя интервьювировать. В целом это несложное интервью, если готовы истории заранее. Главное распознать про какой принцип хотят поговорить интервьверы. Очень круто, если истории универсальные.

                                                                                                  Мой опыт: 1 успешное собеседование в Яндекс, 2 успешных собеседования в Microsoft (Прага, Редмонд), 1 успешное собеседование в Google (Мюнхен).
                                                                                                    0
                                                                                                    Позвольте спросить, в каком году было последнее собеседование в гугле например, я слышал тенденция в том, что получить оффер в гугле в 2010 и в 2019 например требовало несоизмеримых трудозатрат. Могу ошибаться.
                                                                                                      0

                                                                                                      Интервью, как описал apodavalov, было у меня в 2016 году.


                                                                                                      Могу еще добавить, что в задаче на k-ый максимум можно было еще делать и piority queue, или даже какой-нибудь std::set, поддерживая в нем k элементов. Не обязательно знать QuickSelect. Бонусный вопрос был на распараллелить это и тут надо было придумать, как слить множество отсортированных списков побыстрее (опять применив priority queue). При этом доаются подсказки, которые не являются жирным минусом при оценке интервью.


                                                                                                      По ощущениям, сейчас интервью проходят так же как в 2016. Только, может быть, добавилось немного болтовни на проверку soft skills.

                                                                                                        0
                                                                                                        Аналогично, сначала сделал через кучу, а на доп. вопрос уже сказал, что можно и через quick select (кстати, не знал, что оно имеет еще и название). Он, кстати, эффективнее кучи, так как там линейная сложность по времени.
                                                                                                        0
                                                                                                        Проходил интервью в марте 2019 в Google и Microsoft. Яндекс, Microsoft: начало 2017 года.
                                                                                                        yadi.sk/i/Qni2rzVc7BG1sA — то, что я знаю для прохождения алгоритмических секций (возможно даже список еще не совсем полный).
                                                                                                        +1
                                                                                                        Примерами здесь могут быть как раз та самая задача, упомянутая в статье про K-тый максимум (эта задача уже баян баянистый), который по сути опирается на знание работы быстрой сортировки.

                                                                                                        Ай-ай-ай, внимательнее надо быть.
                                                                                                        Задача в статье про поиск не в массиве, а в двоичном дереве поиска. Тут банальный inorder обход дерева и эффективнее ничего нет.
                                                                                                          0
                                                                                                          Тогда автор статьи что-то совсем упоролся. Эта задача еще проще, IMHO :-)
                                                                                                          В оригинальном комментарии это было просто «к слову». Как демонстрация задачи из множества «решение опирается на другой алгоритм» остается K-максимум в массиве.
                                                                                                        0
                                                                                                        Как здесь уже упомянули, проблема в том, что на рынке избыток рабочей силы.
                                                                                                        Поэтому вообще неважно, какие вопросы задавать, главное чтобы
                                                                                                        1) Они выглядели как «конкурс» (формальное основание).
                                                                                                        2) Они позволяли отсеять 90% кандидатов.
                                                                                                          +2
                                                                                                          что на рынке избыток рабочей силы.

                                                                                                          не на рынке, а у ворот топ-IT компаний
                                                                                                            +1
                                                                                                            На рынке, на рынке.

                                                                                                            Компания, которая не готова платить человеку достаточно денег для жизнедеятельности и расширенного воспроизводства — это не часть рынка, он её мгновенно решает. Она успевает как раз только немножко поныть о том, что «негде брать людей», подразумевая, что нет специалистов, согласных работать за еду и «большую честь».

                                                                                                            А настоящий рынок — компании, которые платят люди достаточно денег для жизнедеятельности — в работниках буквально купаются, отсюда и такой отбор. И это не обязательно топ-ИТ, а любая такая компания.
                                                                                                              0
                                                                                                              это не часть рынка, он её мгновенно решает

                                                                                                              А вы не забывайте что бОльшая часть рынка — это не чисто ИТ компании, где разработка софта это не основной вид деятельности, и «решать рынку» если она платит не как в FAANG там нечего.

                                                                                                              Я работал в крупной международной корпорации, которая хоть и имела прямое отношение к IT но я не скажу чтобы прям сильно нуждалась в супер-специалистах, зарплаты там были чуть ниже рынка, проблемы с наймом даже миддлов — были, но из-за того что основой вид деятельности зависел от ИТ лишь коственно — это совершенно ни на что не влияло в её жизни

                                                                                                              И именно такие компании задают «рынок», FAANG лишь небольшая его часть в глобальном масштабе, буквально это самая вершина горы, куда далеко не каждый пойдёт (я например, во всяком случае сейчас и линейным программистом)

                                                                                                              люди отбракованные топами — всёравно кудато пойдут, а пойдут они в такие компании и у них свой «рынок», гораздо более крупный.
                                                                                                          0
                                                                                                          решение задачек разное бывает
                                                                                                          тот же поиск дубликата — кто-то эн-квадрат сравнением кинется перебирать, кто-то отсортирует и найдет два подряд идущих одинаковых… а кто-то посчитает сумму по массиву, вычтет из нее n(n+1)/2 и сразу получит профит
                                                                                                          как-то раз на собеседовании попросили сделать обработку пересекающихся курсов
                                                                                                          думаете, скалярные произведения наше всё? да вот чёрта с два, нашим всем оказалось умение нагромоздить и сориентироваться в груде ифов!
                                                                                                          как говорится, можно вывезти девушку из деревни…
                                                                                                            0
                                                                                                            Одна из лучших статей про собеседования (из-за второй части, там, где выводы).
                                                                                                            И вот что подумалось.

                                                                                                            Неужто ещё не придумали компанию, ноу-хау которой — антипаттерн типичног собеса? Которая могла бы проводить для других действительно качественные интервью? Понятно же, что сущестующие практики легко отсеивают действительно стоящих инженеров по рандомным критериям («спросили такой-то алгоритм, а я его как-раз вчера вспоминал»). Предварительный отстрел кандидата происходит после 1-2 случайных вопросов, которые, как верно заметили, редко встречаются в повседневной деятельности.

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

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

                                                                                                            Если уже заявляется, что самое главное в индустрии XXI века — это люди (логично, ведь экономика знаний), то почему до сих пор так топорно, рандомно их отбирают?
                                                                                                              +1
                                                                                                              Прочитайте вот этот мой комментарий если пропустили — habr.com/ru/post/512160/#comment_21881264

                                                                                                              Оценивается и опыт и софт-скиллы и интервьюверы могут менять задачу в процессе, если видят что кандидат не справляется (хотя это и довольно серьезный сигнал) и интервью аж пять штук в том же гугле для того чтобы «случайно» после 1-2 вопросов не отстреливать и оценка результатов собеседования делается отдельными людьми, которые не встречались с кандидатом лично. В целом оно как-то работает. Оно настроено на найм крепких середняков, которые «могут копать», как выше заметили, а не рок-звезд и это в целом нормальная практика, рок-звезды плохо скейлятся.

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

                                                                                                            Самое читаемое