Собеседования по алгоритмам: теория vs. практика

Автор оригинала: https://danluu.com/algorithms-interviews/
  • Перевод
tl;dr За последние десятилетия мода на собеседования программистов менялась несколько раз, и каждая из них выглядит нелепо в ретроспективе. Либо мы наконец-то нашли настоящий секрет эффективных собеседований, либо увлеклись очередным модным течением, которое через десять-двадцать лет покажется столь же нелепым.

Когда я спрашиваю людей в модных больших технологических компаниях, почему на собеседовании так обязательно спрашивать об алгоритмах, самый распространённый ответ — что-то вроде: «У нас такой масштаб, мы не можем позволить, чтобы кто-то случайно написал функцию O(n^2) и повалил всю систему»1. Что особенно забавно, в последнее время я немало применял на практике эти алгоритмы и решал реальные проблемы, но не могу пройти собеседования, где о них спрашивают! Думаете, я проваливаю половину собеседований или что-то в этом роде? Нет, больше половины. Я участвовал примерно в 40 «настоящих» собеседованиях и прошёл, может, одно или два. Или ни одного2.

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

Рассмотрим несколько примеров.

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

У больших IT-компаний типичные собеседования по телефону делятся на три категории:

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

Эта проблема реализации массива считается настолько простой, что попадает в категорию «очень легко» и является либо разминкой для «реального» вопроса или идёт в комплекте с кучей таких же простых вопросов. И всё же в нашей компании такой динамический массив отвечал примерно за 1% всей нагрузки на сборщик мусора в коде JVM (это был второй по величине источник выделений памяти во всём коде), а также за значительную долю нагрузки на CPU.

К счастью, эта реализация не использовалась в качестве универсального динамического массива, а создавалась только с помощью полуспециализированной оболочки, поэтому отвечала «всего» за 1% давления на GC. Если бы вопрос задали на собеседовании, большинство членов той команды правильно ответили бы на него. Мой патч принёс работодателю за год больше денег, чем я заработал в своей жизни.

Это был второй по величине источник выделений памяти, главный же — преобразование пары значений long в массивы байт из той же базовой библиотеки. Видимо, кто-то написал или скопипастил хэш-функцию, которая брала массив в качестве входных данных, а затем изменил код, чтобы брать два массива и работать с ними в последовательности из старого интерфейса хэш-функции типа byte[], byte[]. Чтобы вызвать эту функцию на двух лонгах, они использовали удобную функцию преобразования long в byte[] в широко используемой служебной библиотеке. Кроме выделения byte[] и вставке туда long, эта функция также изменяет порядок следования байтов long (видимо, функция была предназначена для преобразования значений long в сетевой порядок байтов).

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

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

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

Ещё один пример простого вопроса по алгоритмам — реальная конфигурация для BitFunnel, поискового индекса, который используется в Bing3.

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

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

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

  1. Пример можно сформулировать как вопрос для собеседования.
  2. Если вопрос сформулирован, вы ожидаете, что большинство (или все) сотрудники соответствующей команды знают правильный ответ.
  3. Экономия средств от этого исправления принесёт работодателю за год больше денег, чем я заработал в своей жизни.
  4. Проблема из примера сохранялась достаточно долго, иначе её бы не заметили.

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

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

Из трёх решений для приведённых выше примеров два ушли в прод. Для меня это нормальный процент, если меня просто пригласили в случайный проект, за которым я не слежу постоянно. Циники могут сказать, что процент даже высок. В случайной команде результаты могли быть и хуже, потому что им невыгодно внедрение никакого решения, даже эффективного. Ведь оно требует от них тестирования, интеграции и развёртывания изменений. Создаются новые риски. То есть я прошу команду сделать какую-то работу и взять на себя некие риски, чтобы сделать что-то полезное для компании, но бесполезное для них самих. Несмотря на всё это, люди обычно принимают код, хотя не очень склонны тратить время на оптимизацию (их рабочее время будет потрачено на вещи, которые согласуются с целями команды)4.

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

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

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

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

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

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

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

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

Приложение: как мы до такого дошли?


В старые добрые времена на собеседованиях задавали «пустяковые» вопросы. Современные версии могли бы выглядеть следующим образом:

  • Что такое MSI? MESI? MOESI? MESIF? В чем преимущество MESIF над MOESI?
  • Что делает деструктор? А если это C++11? А если из деструктора верхнего уровня вызвать деструктор подобъекта, то деструкторы каких ещё подобъектов будут выполняться? А во время раскрутки стека? При каких обстоятельствах можно избежать вызова std::terminate?

Я слышал об этих простых собеседованиях ещё в школе и даже видел в некоторых компаниях «старой школы». Это было во времена лидерства Microsoft, когда все остальные равнялись на успешную компанию и копировали Microsoft. Самый читаемый блоггер в области программирования (Джоэл Сполски) говорил, что всем нужно принять некую практику разработки X, потому что так делает Microsoft. Например, в одной из самых влиятельных статей по программированию той эпохи Джоэл Сполски представил так называемый «тест Джоэла», который определяет, насколько вы идёте в ногу с такими компаниями, как Microsoft:

12 баллов — это отлично, 11 — терпимо, но с оценкой 10 или ниже у вас серьёзные проблемы. Правда в том, что большинство софтверных работают на уровне 2-3 балла, и им нужна серьёзная помощь, потому что компании вроде Microsoft работают на уровне 12 полный рабочий день.

Согласно распространённым легендам того времени, Microsoft на собеседованиях задавала примерно такие вопросы (и мне действительно на собеседовании в Microsoft в районе 2001 года задали одну из таких задачек, при полном отсутствии вопросов по алгоритмам или программированию):

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

Поскольку я проходил собеседование в эпоху перемен, мне задавали множество простых вопросов и кучу задачек (включая все вышеперечисленные). На собеседованиях того времени ещё были популярны вопросы Ферми, которые технически не являются головоломками. Другая тенденция того времени — поведенческие интервью без единого технического вопроса.

Как бы то ни было, тогда люди пытались копировать интервью в стиле Microsoft. Когда я спрашивал, чем хороши головоломки или вопросы Ферми, мне отвечали, что таким образом можно проверить, способен ли кандидат к размышлениям, в отличие от вопросов на знание, которые говорят только о том, что человек запомнил какую-то информацию. А нам нужны кандидаты, которые действительно могут думать!

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

Для кандидатов процедура собеседования была в основном такой же, как сейчас с алгоритмами. Просто для подготовки к собеседованию вместо «Взлома собеседования по программированию» нужно было читать «Как переместить гору Фудзи». То есть требовалось усвоить кучу знаний о заданиях, которые вы никогда не будете использовать на работе, вместо знания алгоритмов, которые вы точно так же никогда не будете использовать.

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

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

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

Вдохновлённый комментарием Уэсли Аптекар-Касселса, в последнее время я специально спрашивал у представителей работодателей, как они проверяют эффективность своих собеседований и как борются с предвзятостью. Вот что они отвечали (в порядке убывания частоты):

  • Что? Ничего такого, зачем это?
  • Мы действительно не знаем, эффективен ли наш процесс.
  • Мы просто знаем, что всё работает.
  • У нас нет предвзятости.
  • Мы бы заметили предвзятость, если бы существовал процесс оценки.
  • Кто-то изучал и/или проводил исследование, но не может сказать ничего конкретного о том, как это изучалось и по какой методологии проводилось исследование.

Приложение: обучение


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

Я уже упоминал, что почти во всех компаниях система не стимулирует людей тратить время на повышение эффективности, даже если простой расчёт показывает, что исправление багов легко сэкономит десятки или сотни миллионов долларов. И в отсутствие стимулов у разработчиков неоткуда появиться опыту выполнения такой работы. Незнакомая работа всегда кажется сложнее, чем есть на самом деле. Таким образом, даже если день работы может принести $1 млн в год в виде экономии или прибыли (такое довольно часто встречается в крупных компаниях, по моему опыту), люди не понимают, что это всего лишь один день работы и её можно сделать практически не отвлекаясь от остальных дел. Один из способов решить эту последнюю проблему — обучение. Впрочем, для менеджера его ещё труднее обосновать, чем повышение эффективности, которое не входит в основные задачи!

Например, однажды я написал небольшое руководство (4500 слов, меньше этой статьи, если не считать изображения) по поиску различных неэффективностей в системе: как использовать профайлер для выделений памяти и времени CPU, как настроить наши GC для специализированных задач, как использовать некоторые мои инструменты для автоматического поиска узких мест в конфигурациях JVM, контейнеров и т. д. В основном, это простые и очень эффективные приёмы, которые легко выполнить. Пара человек смогли отладить и исправить проблему самостоятельно, и из вторых рук я слышал, что ещё кто-то повысил эффективность своего сервиса. Хорошо, если 10% инженеров извлекли пользу из этого мануала, надеюсь, он помог десяткам инженеров, а может и больше.

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

Полагаю, несложно заметить слабое качество публичных учебных материалов из-за относительной трудности монетизации образования и обучения. Если вы хотите монетизировать учебные программы, есть несколько хороших методов. Судя по всему, неплохо работает монетизация ценных видеокурсов (сотни или тысячи долларов за короткий курс). Корпоративные тренинги, когда компании приглашают вас поговорить с 30 людьми, а вы берёте $3000 с каждого, также работают довольно хорошо.

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

Например, Джулии Эванс хватает на жизнь доходов от продажи компьютерных комиксов, которые в последнее время приносят около $100 тыс. в год. Специалист по корпоративным тренингам может заработать это за один-два дня.

Приложение: глубокоэшелонированная оборона с рассогласованием стимулов, часть 3


Из трёх приведённых выше примеров в двух случаях я получил какое-то поощрение за то, что сэкономил деньги компании. По моему опыту, в больших компаниях такое случается редко, но даже в этом случае распределение стимулов оказалось довольно плохим. В какой-то момент, после повышения в должности и увеличения зарплаты, я вычислил соотношение моей прибавки и экономии, которую я принёс фирме. Соотношение составило примерно 0,03% напрямую в деньгах, без учёта разработанных мной инструментов, для которых трудно вычислить конкретную ценность. Вероятно, эта ценность на самом деле больше, чем значение, поддающееся количественной оценке. Поэтому можно сделать вывод, что я получил значительно меньше 0,01% от суммы, которую принёс фирме. И это ещё завышенная оценка: в реальности я сильно подозреваю, что на самом деле сделанная работа ничего мне не принесла, а повышение никак не связано с этим проектом, который сэкономил компании десятки миллионов долларов. После первых $10 млн в год или, возможно, $20 млн в год, уже нет никаких стимулов делать работу с точки зрения оценки эффективности, продвижения, повышения и т. д. Потому что в этом нет никаких плюсов, зато есть некоторые минусы (вы можете ввязаться в подковёрные интриги, случайно обрушить сайт и т. д.), так что отдача от выполнения необязательной работы, вероятно, становится отрицательной.

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

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

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

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

Ссылки по теме





1. Во-первых, собеседования Google зачастую копируют маленькие компании, для которых этот аргумент неуместен. Но даже никто из крупных компаниях не разрабатывает и не внедряет крупномасштабные алгоритмы (возможно, последней это делала Google примерно в 2003 году, но в современных крупных IT-компаниях никто особенно не сосредоточен на разработке алгоритмов). [вернуться]

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

Я также предполагаю возможность нулевого результата, потому что единственное «настоящее» собеседование по программированию было в Google, но меня пришли собеседовать неправильные ребята. Я шёл на работу с железом, а меня интервьюировали программисты, поэтому я получил по сути стандартное программистское интервью, за исключением того, что один интервьюер задал несколько вопросов о машине состояний и когерентности кэша (или что-то в этом роде). Затем мне организовали телефонное собеседование с инженером-аппаратчиком, чтобы убедиться, что я не врал о работе в аппаратном стартапе с 2005 по 2013 годы. Вполне возможно, что я провалил программистскую часть интервью и был нанят только благодаря последующему телефонному разговору.

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

3. Это немного более сложный вопрос, чем вы могли ожидать по телефону и такой вопрос вполне можно ожидать на очном собеседовании. Хотя моему другу на телефонном собеседовании с Google однажды задали вопрос с мирового финала Google Code Jam, так что для максимальной сложности действительно нет предела, смотря кто вас спрашивает.

Кстати, если вам интересно, мой друг на самом деле знал ответ, потому что решал эту задачу на Google Code Jam. На самом конкурсе он не нашёл правильный ответ, но позже посмотрел его для забавы. Однако он не счёл разумным сразу выдавать ответ по телефону, а попросил интервьюера задать другой вопрос. Тот отказался, так что мой друг провалил телефонное собеседование. Хотя я сомневаюсь, что в мире найдётся больше пары сотен человек, способных правильно ответить на такой вопрос по телефону, и почти все они, вероятно, поняли бы абсурдность ситуации. Провалив собеседование, мой друг почти полгода искал работу, прежде чем пройти собеседование для стартапа, для которого он в конечном итоге разработал несколько ключевых систем (с точки зрения как влияния на бизнес, так и технических трудностей). Он и сейчас продолжает там работать после того, как компания провела IPO более чем на миллиард долларов. Компания понимает, как трудно заменить этого человека, и очень хорошо к нему относится. [вернуться]

4. Помимо вопиющих архитектурных проблем, которые просто приведут к падению сервиса, есть ещё один момент. Команды зачастую решают проблемы эффективности просто запрашивая дополнительные вычислительные ресурсы. Некоторые компании пытаются каким-то образом бороться с этим. Я слышал, что в Facebook многие команды, работающие над повышением эффективности, рапортуют в специальный отдел, который позволяет им блокировать запросы на расширение ёмкости, если они замечают у какой-то команды крайнюю неэффективность, которую те отказываются исправить. Но лично мне не попадались такие компании. В Google эту проблему пытались решать системой, которая, среди прочего, соотносила численность персонала с вычислительными ресурсами, но я слышал, что от неё в итоге отказались в пользу более традиционной системы по некоторым причинам. [вернуться]
Поддержать автора
Поделиться публикацией

Похожие публикации

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

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

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

    0
    >> Поэтому можно сделать вывод, что я получил значительно меньше 0,01% от суммы, которую принёс фирме.

    Чисто для понимания — вас наняли не для получения вами каких-то процентов. Вас наняли для выполнения указаний конкретного начальника. Выполнили указания — получили з/п. Не выполнили — не получили. Всё остальное — задача других людей.

    Если опытный разработчик этого не понимает, то… ему никто не объясняет, а просто платят обычную з/п, а он обижается. А зря, ведь такова суть мира. Никакие умные мысли никому нафиг не нужны, если эти мысли не пришли в голову тому, у кого есть деньги. И если к мыслям добавлены деньги, то персонаж начинает думать, кого нанять для выполнения работы. Повторю — не для дележа прибыли, а для выполнения работы. Если бы кого-то интересовал делёж прибыли, то речь шла бы об акциях, бонусах и тому подобном, с привязкой к конкретным показателям. Если речь об этом не идёт — ваша задача крутить гайки как прикажут. Ну а место для творчества нужно суметь найти где-то в процессе кручения. Можно даже творить миллионы для дяди, но это как минимум нерационально.
      +3
      речь о другом — автор утверждает, что если промотивировать сотрудника не «крутить гайки», а «приносить прибыль компании», то и прибыль этой самой компании с работы этих самых сотрудников будет выше
        +7
        Как говорил мой шеф на самой первой работе: «Зачем я буду тебе платить, если могу не платить?» — хоть я и упрыгивался там все инициативно улучшая и он это прекрасно понимал. Пришлось уехать из Сибири в Питер — зарплата стала в 5 раз выше за ту же работу (давно это было).
          +1
          да, это как раз пример как начальник не мотивировал сотрудника. Вот вашей личной мотивации и не хватило, и вы поменяли работу на более благодарную. А если бы он вас премировал/повышал за успешные инициативы, ушли бы вы?
            0
            Сомневаюсь — семью содержал на мою зарплату. Так что к лучшему.
          0
          Если человек знает как приносить прибыль — он не работает на зарплате.
          Ну и опять же — человека наняли делать работу, а не искать более выгодные задачи внутри компании.
            +3
            Если человек знает как приносить прибыль — он не работает на зарплате.

            Это дискуссионное утверждение. Даже если человек знает как приносить прибыль может быть несколько причин, почему он на зарплате:
            1)Не готов брать на себя риски;
            2)У нет доступа к ресурсам, необходимых для ведение деятельности, которая эту прибыль приносит.
              –3
              1) Согласен
              2) Если человек знает как приносить прибыль — он найдет доступ к ресурсам, вся история человечества об этом говорит, когда успешные бизнесмены разом теряли всё и с нуля опять добивались.
                +1
                Если человек знает как приносить прибыль — он найдет доступ к ресурсам, вся история человечества об этом говорит

                Потому что те, кого дельфины толкали в море, уже не могли рассказать об этом, ЕВПОЧЯ.
                  0
                    0
                    Согласен с AllexIn, тот же Трамп прогорал.
                    А вы скорее о тех, кто лотерейный билет вытащил.
                    0
                    2) Частично согласен, но это могут быть непересекающиеся множества умений в одном человеке. Возможно я бы навык поиска ресурсов выделил в ключевой для успешных бизнесменов, причем люди умеющие приносить прибыль — тоже ресурс.
                      0

                      Израиль, Startup Nation, все дела. Такой разговор слышал.


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

                        0

                        Так в чем суть? Он инвестирует ради связей, чтобы ими воспользоваться? Или связи предполагают, что семья ИХ бизнес не бросит, и проинвестирует если будет надо. Или что семья научила чадо быть true предпринимателем, и только приносить доход? Или это очередной "инвестор" которому просто наплевать на твои идеи, и конкретно сейчас он ищет связи.

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

                            Но ведь он совсем другой вопрос задал) он не спрашивал: "есть ли опыт в других бизнесах?" а спросил конкретно про связи. Может у чувака уже 10й бизнес и он умеет их готовить.

                              +1
                              А зачем кто-то в доле тогда, если из 10 успешных бизнесов хотя бы пара генерирует прибыль? Человек решил, что спать по 4 в сутки часа — это непозволительная роскошь, пора запускать ещё один стартап?
                              Или закрыл / продал все 10 успешных бизнесов, деньги пропил и пора снова работать? /irony
                +1

                Вы озвучили точку зрения, характерную для начала 20-го века. Да, где-то до сих пор нет дорог, а где-то — менеджмента.

                +3
                Алгоритмы и сортировки имеет смысл спрашивать только у мидлов и джунов. Пока они их не забыли.
                Синьеры и лиды могут и не помнить всё это, но должны суметь изобрести или вспомнить их в нужный момент. Типичное задание для синьеров и лидов должно быть что-то типа «Расскажите за час как бы вы рефакторили БД на 2005000 запросов в секунду, которая начала тормозить. У вас есть команда из 3х мидлов. Что кому делать?». Тут уже можно и графы изобрести и сортировки, если нужно.
                  0
                  Думаю вспоминать реализацию известных алгоритмов на интервью имеет мало смысла ( можно найти их готовые — например в edu.prinston.cs репозитории), а вот понимание из различий (и ограничений), и то как их реально применить — это неплохо бы знать. Чтобы например вместо брутфорс сканирования в О(n^2) какое нибудь AVL дерево построить или граф. Но этого и многие синиоры не знают или просто не заморачиваются.
                  +8

                  Все так умно рассуждают, а как начинаешь код у самих смоотреть, то цикл в цикле, а в нем еще цикл с запросом к бд.

                    0
                    Так и есть, в моем коде такое сплошь и рядом годами, про это и в статье упомянуто — сделал я для миллион-записей-пула оптимизацию поиска в дереве, а нужно это только мне самому, ведь мог бы парой других решённых задач по-проще высокую производительность своего труда демонстрировать. Менеджеры смотрят (и отчитываются) за количество закрытых задач, а не на время, потраченное пользователем у медленно ползущего прогресс-бара.
                    Об этом вроде Боб Мартин говорил, что ответственность за качество таки на программистах лежит.
                    +1

                    Как-то шаблон поскрипывает, когда читаешь


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

                    При чем утверждается, что друг — ого-го какой специалист.

                      +2
                      Ого-го каким специалистам и тяжело работу искать.
                      Требования со стороны специалиста достаточно высокие и эникеем он не пойдет
                      А с другой стороны — запрос на крутого спеца штука редкая, потому что теже лиды и сеньоры нужны не каждый день, а при старте проектов.
                      Вот и получается, сидишь без работы.
                      Знаю хорошо ситуацию, с сам с обширным успешным серьерским опытом работаю мидлом сейчас, да еще не по прямой специальности.
                      Плюс когда нанимают высокоуровневых спецов — кто их должен оценивать? К примеру была ситуация. когда меня должен быть оценивать лид, от которого я сбежал в другой компании(понял что его требования к коду противоречат правилам и по сути он требует писать говнокод, что мне не надо).
                      shit happens
                        +1
                        И? При таких подходах к найму обычное дело.
                          +1
                          | мой друг почти полгода искал работу, прежде чем пройти собеседование для стартапа
                          При чем утверждается, что друг — ого-го какой специалист.

                          Ну, есть такая байка, что сеньёр находит новую работу пока идёт в соседний страбакс пить кофе. Возможно, в мейнстримовом энтерпрайзе так и есть. Если знаешь именно тот набор технологий, что требуется. На деле всё намного сложнее. Если джуна можно нанимать просто адекватного — его дешевле научить новому, чем искать другого, в случае с мидлом достаточно чтобы скилы хотя бы наполовину пересекались, то сеньёра фирмы подбирают как замуж. Требуют очень часто знания ВСЕХ используемых у них технологий. Видимо, считают, что сеньёра учить слишком дорого. Да, вон, чуть выше пример — человек утверждает, что сеньёра нужно обязательно спрашивать как прооптимизировать БД, полагая, априорно, что сеньёр умеет в БД. Сеньёр, безусловно, умеет в БД, но… Возможно, он последние 10 лет вообще не имел дела с БД. Возможно, он работал в хорошей конторе, где вопросы БД решались целым отделом ДБА. Ещё разные причины. В результате в 95.65% контор стандарта спринг+оракел/постгре его не возьмут, несмотря на то, что он реально сеньёр. Просто занимался не мейнстримом. А на должность ниже с последующим апгрейдом или он сам не хочет уже или его и не берут из за overqualified :)

                          0

                          Тяжеловато читается (как ни странно, оригинал читается проще, хотя и тоже стена текста). Но спасибо за интересный перевод.

                            –1
                            А как вы оценивали эти 0,03% и 0,01%? И ваши коллеги согласились с этой оценкой? Зачастую доведение разумности своих действий до тех, от кого зависят решения, это большая работа.

                            Еще стоит отметить, что подобные показатели достижимы работником только если он работает в фирме, а не в одиночку. А работая на кого-то, работник связан обязательствами договора-контракта, в рамках которого не десятки млн. Другими словами, если человек работает на таможне и он конфисковал контрафакт на 10 млн $, то премию в таком размере ему не дадут, а 10 млн получены прежде всего потому, что ему были предоставлены соответствующие полномочия. Это я к тому, что к таким вещам можно относиться проще (до техпор, пока вы не открыли свою компанию с оптимальной работой ПО или например не начали заниматься оптимизацией софта больших компаний на договорной основе и по результату ;).

                            В общем же случае в озвученной вами проблемой (отсутствию достаточных стимулов к оптимизации и вознаграждений от полученных результатов) я полностью согласен. Вы далеко не одиноки в своих рассуждениях. +1
                              0
                              Обратите внимание, что это перевод)
                              По сути же — у таможенника работа — конфисковывать контрафакт. Если он пропустил партию — это невыполнение служебных обязанностей, если задержал партию на десятки миллионов — это просто его работа. Для программиста же, непосредственная работа — это выполнение задач, поставленных сверху. И если задача оптимизировать узкое место, и тем самым сэкономить миллионы пришла сверху — всё ок, делаем работу. Если же программист сам нашёл такое место — он молодец, можно сравнить с таможенником который обнаружил что огромные партии конфиската везут мимо таможни по соседнему лесу, через дыру в ограждении. Это не относится к его рабочим обязанностям, значит можно считать, что это прибыль которую он принёс своей инициативой. Поощрять ли такую инициативность у работников, или платить им только за выполнение рабочих задач — это отдельный вопрос, который и поднимает автор. Вопрос, причём, достаточно тонкий — в случае хороших поощрений работники могут начать искать места для оптимизации, забивая на свои основные задачи, что тоже не очень хорошо.
                                0
                                Да, я обратил внимание. Но править комментарии или отзывать то что на модерации система мне не дает.

                                В своем сообщении я говорил несколько о другом. О том, что кол-во $ зависит во многом от занимаемой должности и выполняемых обязанностей. Таможенники как и программисты допускают ошибки, и в вашем примере программисты не спешат за свои проколы, которые тоже могут исчисляться миллионами, отдавать свои кровные. Поэтому нельзя говорить о том, что если, то мне должны миллионы.

                                Поощрять, и если да, то как, это вопрос сложный и интересный. В случае организации процессов обычно отрабатывает обратная связь — то есть, должен быть кто-то, кто скажет, что нужна оптимизация (конечный пользователь, поводимая проверка, ..), и далее бизнес принимает решение нужно ему оптимизировать или нет. Потому как зачастую оптимизация не требуется, так как выручка и выживаемость бизнеса с большой долей вероятности определяется другими факторами (привлечением пользователей, инновационными услугами, взаимодействием с другими структурами и организациями и др.). Другими словами, инициатор снизу может соптимизировать например загрузку CPU с 60% до 30%, но от этого аппаратное обеспечение никуда не пропадет, экономия электричества в сравнении с рисками внедрения неоптимальна, а еще окажется, что сам проект может быть закрыт еще до внедрения оптимизации переходом на новые технологии или продажей конкуренту. Но всего этого инициатор не знает и риски на себя берет не он. В таких условиях позиция «мне должны миллионы» слишком поверхностна и наивна. Поэтому я бы к этому относился попроще.
                              0
                              В принципе, это нормально что крупные компании пытаются формализовать процесс найма, введя какие-то критерии для первичного отсева. Просто потому что там поток кандидатов огромен, и у людей напрямую, связанных с проектом, не хватит времени собеседовать всех желающих. Потерять хорошего специалиста для них не так страшно, потому что он среди желающих не один обычно.
                              А вот тенденция, что небольшие фирмы копируют этот подход, конечно, вредит. Но это тоже нормальный процесс во всех сферах: при отсутствии понимания просто скопировать, так не только в ИТ. При этом адекватные руководители никогда не упирают на идеальные знания, скорее проверяются базовые знания и каким образом идут рассуждения.
                              В итоге, все равно, люди адаптируются и большинство понимает, что нужно освежить в памяти алгоритмы перед собеседованием.
                                +5
                                В итоге, все равно, люди адаптируются и большинство понимает, что нужно освежить в памяти алгоритмы перед собеседованием.

                                Или говорить «я вам перезвоню» как только тебя начинают спрашивать о деревьях или еще каких сферических в вакууме вещах. Работы всё так же гораздо больше, чем работников, а конкретно в РФ это еще и усиливающийся тренд.
                                  0
                                  Смотря какой работы, если человек хочет работать и развиваться в определенной сфере, то может быть и не так много компаний могут предложить подобную работу. А Вы скорее говорите о случаях компаний, которые просто скорее всего не способны четко определить свои критерии для найма.
                                  0
                                  Потерять хорошего специалиста для них не так страшно, потому что он среди желающих не один обычно.

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

                                    0
                                    Речь шла про крупные компании с проектами мирового уровня. Все равно у каждого человека есть компании, куда бы он хотел попасть в первую очередь по разным причинам. Если, например, человек хочет заниматься беспилотными автомобилями, вряд ли он упустит возможность устроиться в Tesla и т.п.
                                    Думаю, что тот же Google отверг немало хороших специалистов.
                                  +2
                                  в последнее время я специально спрашивал у представителей работодателей, как они проверяют эффективность своих собеседований и как борются с предвзятостью. Вот что они отвечали (в порядке убывания частоты):

                                  — Что? Ничего такого, зачем это?


                                  Собственно, это вся суть современной работы с персоналом.
                                    +1
                                    А ещё придирчиво выбирать лучших спринтеров мира на 8уровневых соревнованиях (мы не может позволить нанимать себе слишком медленных!) и вручать победителю верёвку бурлака №7728 от баржи с помоями.
                                      0
                                      Именно так.
                                      «У нас тут оклад 60 тыщ и премия в конце года в размере оклада, но мы вам зададим все вопросы, которые в гугле задают, это ведь специальные вопросы для программистов».
                                    0
                                    Получается, что вопросы по алгоритмам на собеседовании не помогают решать реальные алгоритмические задачи на работе.

                                    Это анекдотическое свидетельство. Ничего так не получается на самом деле. Кто знает, насколько больше таких критических глупостей было бы в коде, не проверяла бы фирма при найме знание алгоритмов и умение думать решать задачки.

                                      +1
                                      Основной посыл статьи — зачем нанимать хороших (эффективных, занющих алгоритмы и т.п.) программистов, если у них все равно не будет стимулов хорошо (эффективно) работать?

                                      Просто, гениально и почему-то многим совершенно не понятно.
                                        0
                                        Очевидное продолжение "… поэтому если вы наняли джедаев и рок-звёзд — потрудитесь их правильно мотивировать, не только морковкой сзади".
                                        Ну и неочевидное «Даже если эти не работают за свои деньги — как работают остальные?» /irony
                                          0
                                          >> Просто, гениально и почему-то многим совершенно не понятно.

                                          В вашей интерпретации — коротко и ясно. А вот в статье — не о чём.

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

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