Тезисы, сформулированные во время распития чая, о процессе интервью, с позиции интервьирующего
В моей жизни было четыре периода, когда я активно принимал участие в интервьировании людей на работу. В 1998 для своего стартапа в области программ для проектирования микросхем, в 2010–11 для MIPS Technologies (компания среднего размера, но престижная в свое время в узком кругу процессоростроителей), в 2019 для Wave Computing (хайповый стартап в хардверном AI) и сейчас для Samsung (на позиции дизайнеров графических процессоров телефонов). Я не собирался писать длинный текст, но пока я пью чай, набросаю несколько тезисов, первое, что приходит в голову:
Большинство текстов в интернете про поиски работы концентрируются на советах по оформлению резюме и по прохождению бихевиорального интервью. Мой персональный взгляд: настоящая борьба происходит не там. Научить правильно писать резюме можно за полчаса. А с компаниями, которые делают упор на бихевиоральное интервью, имхо лучше вообще не связываться. Главным фокусом является два умения: умение внятно рассказать, что вы делали на предыдущих работах, и умение решать задачки.
По поводу резюме: оно должно быть кратким и строго по делу. Длинные резюме на восемь страниц пишут сумасшедшие. Если вам меньше 30 лет, одна страница оптимальна, потом можно две. Под каждым местом работы должно стоять достижение. Не «программировал на Си», а «разработал и реализовал алгоритм выделения регистров в компиляторе с такого то языка, учитывающий эффекты конвейера такого-то процессора». Не нужно упоминать все компании и все умения — комбинация «RTL лид блока wireless чипа в [топ-10 электронной компании]» и «умею работать с Microsoft Word» — это маразм.
Вносить в резюме нужно только то, за что вы готовы ответить на вопросы. Один соискатель написал что он программировал на языке Jovial, думая что ему просто поверят (на этом языке американские военные писали программы в старину). Соискателю не повезло: я однажды пролистал книжку по Jovial в библиотеке Стенфорда. Выражение лица соискателя, когда я задал ему вопрос про Jovial, было бесценно.
Рассказ о том, что вы делали на предыдущей работе, должен быть хорошо структурирован. Сначала нужно описать чип или ядро, внутри которого вы разрабатывали или верифицировали блок. Потом вам нужно нарисовать на доске (реальной или виртуальной в зуме) ключевые элементы вашего блока (интерфейсы, памяти, очереди FIFO), описать ход транзакций между ними и микроархитектурные проблемы, которые при этом возникали. Упомянуть решение проблем с таймингом и энергопотреблением, а также чем это лучше других решений. Интервьюер должен почувствовать, что вы это делали, делали с пониманием, и можете передать ваше понимание окружающим.
Здесь имеется тонкий момент: вам нельзя выдавать секреты текущего или предыдущего работодателя. К счастью, блоки процессоров или сетевых чипов в разных компаниях (например TLB MMU в процессорах или там Egress Processing в роутерах) имеют похожую структуру. Также компании часто используют открытые изобретения из академической среды (пример: предсказатель переходов TAGE). Поэтому вам достаточно плясать вокруг некоего общего знания, разлитого по всей индустрии среди понимающих людей, с небольшими вариациями. А также не упоминать никакие бенчмарки, пропускные способности, особые патентуемые находки, планы и другую конкретно секретную информацию.
Уровень вопросов и задачек связан с вашим опытом в резюме. Если вы свежий интерн, у которого в резюме только курсовой проект, в котором вы писали execution unit в учебном RISC-V процессоре, готовьтесь ответить про задержки и байпасы в конвейере. Если вы упоминаете в резюме FIFO или SPI протокол, готовьтесь написать перед глазами интевьюера код для простого FIFO или SPI приемника на верилоге.
Бывают соискатели из недавних студентов, которые могут рассказать словами и картинками, но не набили руку на механике писания кода на верилоге. Это плохая комбинация. Да, я знаю, что есть мнение «он понимает сложные проблемы и выучит простое кодерство за пару месяцев». Такое мнение встречается у менеджмента, особенно если студент — отличник и позитивен. Но это плохо работает во время интервью с инженерами команды (см. примечание 1).
Вообще, для тех кто не знает: типичное интервью в крупной электронной компании состоит из нескольких этапов: 1) рекрутер; 2) технический скрининг нанимающим менеджером или одним из опытных инженеров; 3) большое интервью в котором вы за 4–6 часов говорите с 5–8 инженерами; 4) разговор с начальником на два уровня выше и 5) обсуждение предложения. Критической является часть (3).
У этой темы есть вариации: пункт (3) может быть в два приема — на два дня; инженеры могут интервьировать вас парами интервьюеров, а не поодиночке; в редких случаях бывают презентации соискателя всей инженерной команде итд.
Для старших инженеров критично знать некое общее ноу-хау индустрии, которое все применяют, но которое слабо представлено в учебниках. Например комбинация из конвейера, очереди FIFO и кредитного счетчика широко применяется в сетевых чипах для обработки потока фрагментов пакетов, и в графических чипах для обработки потоков треугольников. Но в учебниках это описано очень слабо: я видел это в контексте сетевого софтвера (не хардвера), а также в фрагменте лекции в Принстоне. Если соискатель работал в команде, которая это однозначно применяет, например в группе проектирования системы на кристалле в Apple, то его можно 1) сначала спросить «что такое credit based flow control»? 2) если он ответит «нет» то найти другую похожую область; 3), а если он ответит «да» то задать одну из многих задачек на эту тему.
Некоторые вещи, которые спрашивают на интервью, разобраны в статях от Cliff Cummings, идеи для тренировок на микроархитектурные задачки можно черпать из сайта RTLery итд.
С задачками на интервью есть такая проблема, что любой ваш вопрос может быть передан на вебсайт типа glassdoor, где люди делятся, чему их спрашивали на интервью. Против этого есть противоядие — делать вариации задачек. Например есть широкоизвестный интервьюшный вопрос «напишите код на верилоге, который принимает числа по битам (один бит каждый такт) и определяет, делится ли это число на три (длина числа не ограничивается — оно может быть хоть миллиард бит). Так как этот вопрос стоит на таких сайтах стоит сто лет, то в чистом виде его спрашивать нельзя: нужно делать вариацию, например 1) биты могут приходить как от старшего к младшему, так и от младшего к старшему или 2) определяте не остаток от деления на 3, а остаток от деления на 7. Итд.
В заключение добавлю, что вы можете познать все что я выше описал, на практике: если вы проектировщик микросхем на уровне регистровых передач, хотите работать в интересном проекте в GPU и (увы, это ограничение) имеете право на работу в США, то присылайте мне ваше резюме.
Примечание 1. Существует разрыв между уровнем базовых курсов в университетах и уровнем навыков, требуемых для успешной работы в компаниях. Если студент не набивал руку на учебных проектах сам, а только сдавал зачеты по картинкам из учебника и простейшим упражнениям, у него будет проблема. Столкнувшись с задачей чуть дальше учебника, студент может обнаружить, что то, что ему казалось простым (пример: gearbox, конвертор ширины шины c valid/ready интерфейсами на входе и выходе), вдруг стало сложным. Если он при этом нетвердо владеет механикой верилога типа блокирующих и неблокирующих присваиваний, параметризацией итд, то у него будут глюки и он будет биться как рыба об лед, наслаивать говнокод и заплаты, отлаживать это бесконечно, надеяться, что кто-то исправит за него итд. Этот этап нужно пройти в учебных проектах, не на производстве. Да и всякие алгоритмы замещения кэша и прочее из картинок в учебнике тогда будут выглядеть по другому.
