Хороший интервьюер как раз и спрашиват о том, чем можно решить данную задачу, и проверяет, что кандидат понимает вещи, которые он использовал при решении задачи. Например, если используется хеш-таблица, то какие есть плюсы и минусы. Я даю задачи, которые не требуют больше чем 10-20 строк кода, даже для brute-force решения. Например: удалить из связанного списка элементы, удовлетворяющие определенному критерию. С кандидитом мы обсуждаем, как меняется решение, если имеются разные ограничения. В такой простой задаче, как удалить элемент из списка, в решение кадидатов всегда есть баги. Поэтому, мы обсуждаем тестирование и отладку.
Думаю, создание автоматической системы фильтрации с анти-читингом - очень непростая задача. Чем сложнее будет система, тем больше денег будут брать конторы по подготовке резюме. Сейчас активно используют системы online assessment, когда кандидату дают задачки и разумное время на их решение, чтобы кандидат решал их без стресса. Да и там читинга хватает. Кандидат набрал максимум баллов, а сам не знает что такое связанный список и чем он отличается от массива.
Пока еще лучше всего работает система найма по рекомендации. Там процент адекватных кандидатов сильно больше.
Людей, которые занимались leetcode-дрочеством, довольно легко отлавливать. Во-первых, они ожидают задачу, в которой все определено и разжевано. Они задают вопросы только потому, что так принято. Полученные ответы они благополучно забывают и удивляются, когда им об этом напоминаешь. Они ожидают детальных примеров.
Во-вторых, они не могут написать решение в виде псевдо-кода, в любом формате. Они сразу пытаются писать код.
В-третьих, они не могу проверить свою программу без запуска. Они не могут сгенерировать данные для тест кейсов.
Самая большая проблема - это уровень вранья. Ладно с враньем в резюме, без этого уже не пробраться через фильтры. Но когда тебе постоянно врут про свой опыт на собеседовании и знание всего на свет, то это приводит к разочарованию. Первые 100 интервью ты еще пытаешься вкладываться в кандидата, закрывашь глаза на ошибки и зависания с ответами, пытаешься помочь. Из этих 100 только ~5 оказываются адекватными, остальные - шлак. А ведь эти 100 уже прошли какой-то уровень фильтрации. Печально, что процент адекватных не растет. Так что, основной задачей интервьюера становится борьба с шлаком. К сожалению из-за большого процента шлака, страдают вполне нормальные кандидаты.
Можно ссылки на разоблачения? Выборочно посмотрел лекцию. То что услышал, встречал в книгах, например Body By Science и ряде других англоязычных. Часть вещей из лекции согласуются с моим личным опытом и более 10 лет наблюдений в спортзале. Например, люди посещающие в основном кардио классы и работающие там в полную силу, так и не избавились от жировой прослойки и не получили рельефные мышцы.
:) Там скорее смесь "доброй" и "недоброй" воли. Наша команда в Unipro (контрактора Sun) участвовала в разработке Java Compatibility Kit. Без прохождения JCK нельзя было использовать Java в названии software. Microsoft хотел быструю Java на Windows и него была JVM 1.1, но она не проходила все тесты JCK. В те времена Sun был сказочно богат и считал, что Windows это скорее враг чем друг, что пользователи Windows не приносят существенного дохода. Основной платформой для Java, Sun считал SunOS/Solaris. Вместо того, чтобы договориться и улучшить Java, Sun решил наказать Microsoft. Наша команда предоставила доказательства для суда. Только для Sun это была пиррова победа, которая привела к тому, что Java ушла с desktop на server. Умер J#, зато родился C#.
Я был в Apache Harmony с его начало. Кстати, IBM был ключевым участником в проекте Harmony. Sun не давал JCK, поэтому Apache Harmony не могла использовать Java в названии. Нам инженерам, Intel продавал светлое будущее Apache Harmony. В конце стало понятно, что основной целью Intel было усилить свои позиции в сегменте серверов. Java быстро набрала популярность в разработке enterprise приложений, а для таких приложений нужны мощные сервера :) Серверная Java была в основном не на Intel серверах, потому что Sun Java была не оптимизирована под x86. У Sun не хватало ресурсов на это, что в итоге привило к приобретению Hotspot.
Когда у Sun начались проблемы с продажей SPARC серверов, он обратил свое внимание на x86. Тут обнаружилось, Sun Java позади IBM J9 и BEA JRockit. Sun из врага Intel, стал партнером. Наша команда в Intel работала над улучшением производительности Sun Java. Другая часть людей из Harmony работала на портированием Sun Java на Itanium. Потом был проект оптимизации Android Runtime(ART) для x86.
В общем в этой истории были свои скандалы и интриги :)
Спасибо, Валера, за сохранение памяти об этих и других событиях. Хоть что-то останется записанным. Как участник тех событий: Unipro_Sun -> Intel_Harmony -> Intel_Sun -> Intel_VIP, подтверждаю - веселые были времена. VIP был очень интересным проектом. Его ISA был взрыв мозга. Особенно отладка assembler программ :) А performance analysis так вообще был на уровне magic. Часть людей осела в Arm.
Можно переименовать статью: ускорения поиска минимального числа в массиве вещественных чисел.
Но как только в цикле появится переход от целого к вещественному, то все ускорение пропадет.
Потому что GCC предполагает, что для работы с double будут использоваться в основном FP инструкции, что в целом правда. Так как целочисленных регистров всегда не хватает, компилятор старается использовать все другие регистры.
Кстати в коде для x86_64, значения также пересылаются из FP регистров XMM в целочисленные регистры. И это код сгенерированный clang.
Видно, что в цикле с is_smaller нам приходится пересылать значения из FP регистров D0/D8 в целочисленные регистры X1/X3. Цикл с is_smaller содержит в 2 раза больше инструкций.
На самом деле, большинство задач, включая design interview, которые дают на собеседованиях в FAANG не такие уж и сложные. Думаю где-то 99% тех что мне давали. Да был 1% задач, которые были реально сложные. Вся проблема заключается в стрессе. Как только человек научится контролировать стресс, он успешно будет проходить любые интервью при условии наличия нормальных технических способностей. К сожалению нет silver bullet как держать под контролем этот стресс. Каждый должен найти свой метод.
На мой взгляд, составляющие успеха:
умение преодолевать стресс: 30%
хорошее знание английского языка и умение ясно коммуницировать: 30%
Хочу поделиться своим опытом прохождения собеседований в Google (2 неудачных onsite), Facebook (1 неудачное onsite, несколько заваленных скрининг), Apple (несколько заваленных скрининг) и Amazon (2 onsite, одно заваленное скрининг).
Выпусникам вузов и Juniors, и в какой-то степени Middles, проще пройти собеседования чем Seniors, так как у них проверяют только основные навыки: основы CS, способность решать задачи и коммуницировать решение. Им больше прощают ошибки. У них только одна проблема — это, чтобы их заметили и пригласили на собеседование. Просто так отправка резюме в компании вряд ли поможет. Здесь сильно помогает посещение конференций, знакомые, особенно linkedin, стажировка в крупных компаниях. Им как раз сильно должны помочь всякие LeetCode и книжки про прохождение собеседований. Чаще всего их собеседуют без особой связи с позицией на которую подался человек.
От Seniors ожиданий больше, особенно Design Interview. Оно будет практически одним из самым главных критериев оценки. Seniors будут стараться задать как можно больше вопросов разной сложности. Поэтому очень важно уметь быстро писать код при недостатке времени. Как только код написан и доказана его корректность, начинается процесс обсуждения того как его можно улучшить. Чаще всего это и есть главный этап собеседования. Если все время ушло на написание и отладку и не хватило на обсуждение, то результат скорее всего будет негативный. Для Seniors больше шансов пройти интервью, если опыт в резюме пересекается с позицией, на которую собеседуют. Все мои попытки пройти собеседования на Generally Smart Software Engineer, провалились практически после пары первых раундов. Собеседования на позиции, где мой опыт был бы полезен, практически все заканчивались onsite интервью. Процесс подготовки Seniors отличается от процесса подготовки Juniors/Middles и занимает минимум три месяца. Оптимально — шесть. От книжек пользы не много, особенно от всюду рекламируемой Cracking the Coding Interview. За время ее существования вышла куча статей в Интернете с ее пересказом. Так что проще прочитать пару-тройку этих статей. Все другие книги пишутся как под копирку. Для подготовку к Coding Interview, я рекомендую книги по спортивному программированию. Мне больше всего помогла Guide to Competitive Programming: Learning and Improving Algorithms Through Contests. LeetCode полезен только в начале, для выработки и поддержания навыка решения задач. Больше месяца-двух тратить на него смысла нет. Можно стать умельцем решения задач LeetCode. Процесс решения задач на интервью все таки отличается. И да, не нужно ставить цель прорешать и запомнить все задачи. От этого пользы мало, так как задач очень много и их решения невозможно запомнить. Интервальные методы запоминая тут не помогут.
Пользы от независимых рекрутеров в подготовке к собеседованиям в FAANG практически мало, за исключением того когда им удалось заинтересовать FAANG вашей персоной. После этого вы все равно будете общаться в основном с рекрутерами из FAANG, которые и будут вас готовить к собеседованию. Но к моменту общения с ними вы уже должны быть более-менее подготовлены к собеседованию.
Полезно проходить собеседования в разные компании, для тренировки. Вот тут независимые рекрутеры могут быть полезны, так как они подготовят список таких компаний и быстро сведут с ними. Только не проговоритесь, что это вам для тренировки. Эти собеседования вам помогут улучшить коммуникационные навыки и стрессоустойчивость. Особо не надейтесь что они помогут вам подготовиться к техническим интервью FAANG.
Телефонные интервью — это по большей части лотерея. Способность быстро решать задачки на время увеличивает шансы выиграть в нее.
Onsite интервью — это тоже лотерея, но уже с большей вероятностью выйгрыша.
Будьте готовы к встрече с людьми с завышенным чувством собственного значения. Таким людям не нравится, когда ответ не совпадает с тем, что они хотят услышать. К счастью таких людей попадается очень мало. По большей части собеседования, особенно onsite, в FAANG оставляют приятные впечатления.
Очень помогает понимание того, что процесс собеседования в FAANG, нацелен прежде всего на минимизацию найма некомпетентного сотрудника. То что вы не прошли, еще не значит, что у вас больше нет шансов попасть в FAANG. Я в итоге прошел собеседования в Amazon и принял офер.
Если есть вопросы, спрашивайте, буду рад ответить.
Например исправили security bug в Java core или framework библиотеках. Насколько я помню любое изменение в системных компонентах требовало перекомпиляции всех приложений, но могу и ошибаться.
Хороший интервьюер как раз и спрашиват о том, чем можно решить данную задачу, и проверяет, что кандидат понимает вещи, которые он использовал при решении задачи.
Например, если используется хеш-таблица, то какие есть плюсы и минусы.
Я даю задачи, которые не требуют больше чем 10-20 строк кода, даже для brute-force решения. Например: удалить из связанного списка элементы, удовлетворяющие определенному критерию. С кандидитом мы обсуждаем, как меняется решение, если имеются разные ограничения. В такой простой задаче, как удалить элемент из списка, в решение кадидатов всегда есть баги. Поэтому, мы обсуждаем тестирование и отладку.
Думаю, создание автоматической системы фильтрации с анти-читингом - очень непростая задача. Чем сложнее будет система, тем больше денег будут брать конторы по подготовке резюме.
Сейчас активно используют системы online assessment, когда кандидату дают задачки и разумное время на их решение, чтобы кандидат решал их без стресса. Да и там читинга хватает. Кандидат набрал максимум баллов, а сам не знает что такое связанный список и чем он отличается от массива.
Пока еще лучше всего работает система найма по рекомендации. Там процент адекватных кандидатов сильно больше.
Людей, которые занимались leetcode-дрочеством, довольно легко отлавливать.
Во-первых, они ожидают задачу, в которой все определено и разжевано. Они задают вопросы только потому, что так принято. Полученные ответы они благополучно забывают и удивляются, когда им об этом напоминаешь. Они ожидают детальных примеров.
Во-вторых, они не могут написать решение в виде псевдо-кода, в любом формате. Они сразу пытаются писать код.
В-третьих, они не могу проверить свою программу без запуска. Они не могут сгенерировать данные для тест кейсов.
Самая большая проблема - это уровень вранья. Ладно с враньем в резюме, без этого уже не пробраться через фильтры. Но когда тебе постоянно врут про свой опыт на собеседовании и знание всего на свет, то это приводит к разочарованию. Первые 100 интервью ты еще пытаешься вкладываться в кандидата, закрывашь глаза на ошибки и зависания с ответами, пытаешься помочь. Из этих 100 только ~5 оказываются адекватными, остальные - шлак. А ведь эти 100 уже прошли какой-то уровень фильтрации. Печально, что процент адекватных не растет. Так что, основной задачей интервьюера становится борьба с шлаком. К сожалению из-за большого процента шлака, страдают вполне нормальные кандидаты.
Можно ссылки на разоблачения? Выборочно посмотрел лекцию. То что услышал, встречал в книгах, например Body By Science и ряде других англоязычных. Часть вещей из лекции согласуются с моим личным опытом и более 10 лет наблюдений в спортзале. Например, люди посещающие в основном кардио классы и работающие там в полную силу, так и не избавились от жировой прослойки и не получили рельефные мышцы.
:) Там скорее смесь "доброй" и "недоброй" воли.
Наша команда в Unipro (контрактора Sun) участвовала в разработке Java Compatibility Kit. Без прохождения JCK нельзя было использовать Java в названии software. Microsoft хотел быструю Java на Windows и него была JVM 1.1, но она не проходила все тесты JCK.
В те времена Sun был сказочно богат и считал, что Windows это скорее враг чем друг, что пользователи Windows не приносят существенного дохода. Основной платформой для Java, Sun считал SunOS/Solaris. Вместо того, чтобы договориться и улучшить Java, Sun решил наказать Microsoft. Наша команда предоставила доказательства для суда. Только для Sun это была пиррова победа, которая привела к тому, что Java ушла с desktop на server. Умер J#, зато родился C#.
Я был в Apache Harmony с его начало. Кстати, IBM был ключевым участником в проекте Harmony. Sun не давал JCK, поэтому Apache Harmony не могла использовать Java в названии. Нам инженерам, Intel продавал светлое будущее Apache Harmony. В конце стало понятно, что основной целью Intel было усилить свои позиции в сегменте серверов. Java быстро набрала популярность в разработке enterprise приложений, а для таких приложений нужны мощные сервера :) Серверная Java была в основном не на Intel серверах, потому что Sun Java была не оптимизирована под x86. У Sun не хватало ресурсов на это, что в итоге привило к приобретению Hotspot.
Когда у Sun начались проблемы с продажей SPARC серверов, он обратил свое внимание на x86. Тут обнаружилось, Sun Java позади IBM J9 и BEA JRockit. Sun из врага Intel, стал партнером. Наша команда в Intel работала над улучшением производительности Sun Java. Другая часть людей из Harmony работала на портированием Sun Java на Itanium. Потом был проект оптимизации Android Runtime(ART) для x86.
В общем в этой истории были свои скандалы и интриги :)
Спасибо, Валера, за сохранение памяти об этих и других событиях. Хоть что-то останется записанным.
Как участник тех событий: Unipro_Sun -> Intel_Harmony -> Intel_Sun -> Intel_VIP, подтверждаю - веселые были времена.
VIP был очень интересным проектом. Его ISA был взрыв мозга. Особенно отладка assembler программ :)
А performance analysis так вообще был на уровне magic. Часть людей осела в Arm.
:) первое, что всплыло в голове было решение задачи с помощью дерева вероятностей. После быстро набросал соотвествующий код.
Рекомендую попробовать https://github.com/corretto/heapothesys
Странно, у меня на ARM64 этот код дает неправильный результат. Вот такой код работает:
Результат:
Можно переименовать статью: ускорения поиска минимального числа в массиве вещественных чисел.
Но как только в цикле появится переход от целого к вещественному, то все ускорение пропадет.
А можно ассемблерный код?
Потому что GCC предполагает, что для работы с double будут использоваться в основном FP инструкции, что в целом правда. Так как целочисленных регистров всегда не хватает, компилятор старается использовать все другие регистры.
Кстати в коде для x86_64, значения также пересылаются из FP регистров XMM в целочисленные регистры. И это код сгенерированный clang.
AArch64, Neoverse N1
Получается, что нативная реализация в 2 раза быстрее.
Ассемблерный код:
Видно, что в цикле с
is_smallerнам приходится пересылать значения из FP регистров D0/D8 в целочисленные регистры X1/X3. Цикл сis_smallerсодержит в 2 раза больше инструкций.Сомнительное преимущество:
Есть у вас результаты бенчмарок, показывающие преимущество вашего подхода?
В ARM AArch64 есть инструкции специально для этого: FCMP и FCM*, которые исполняются за 2-3 такта: https://godbolt.org/z/cr4Mcq
На x86_64 — UCOMISD.
На самом деле, большинство задач, включая design interview, которые дают на собеседованиях в FAANG не такие уж и сложные. Думаю где-то 99% тех что мне давали. Да был 1% задач, которые были реально сложные. Вся проблема заключается в стрессе. Как только человек научится контролировать стресс, он успешно будет проходить любые интервью при условии наличия нормальных технических способностей. К сожалению нет silver bullet как держать под контролем этот стресс. Каждый должен найти свой метод.
На мой взгляд, составляющие успеха:
Хочу поделиться своим опытом прохождения собеседований в Google (2 неудачных onsite), Facebook (1 неудачное onsite, несколько заваленных скрининг), Apple (несколько заваленных скрининг) и Amazon (2 onsite, одно заваленное скрининг).
Выпусникам вузов и Juniors, и в какой-то степени Middles, проще пройти собеседования чем Seniors, так как у них проверяют только основные навыки: основы CS, способность решать задачи и коммуницировать решение. Им больше прощают ошибки. У них только одна проблема — это, чтобы их заметили и пригласили на собеседование. Просто так отправка резюме в компании вряд ли поможет. Здесь сильно помогает посещение конференций, знакомые, особенно linkedin, стажировка в крупных компаниях. Им как раз сильно должны помочь всякие LeetCode и книжки про прохождение собеседований. Чаще всего их собеседуют без особой связи с позицией на которую подался человек.
От Seniors ожиданий больше, особенно Design Interview. Оно будет практически одним из самым главных критериев оценки. Seniors будут стараться задать как можно больше вопросов разной сложности. Поэтому очень важно уметь быстро писать код при недостатке времени. Как только код написан и доказана его корректность, начинается процесс обсуждения того как его можно улучшить. Чаще всего это и есть главный этап собеседования. Если все время ушло на написание и отладку и не хватило на обсуждение, то результат скорее всего будет негативный. Для Seniors больше шансов пройти интервью, если опыт в резюме пересекается с позицией, на которую собеседуют. Все мои попытки пройти собеседования на Generally Smart Software Engineer, провалились практически после пары первых раундов. Собеседования на позиции, где мой опыт был бы полезен, практически все заканчивались onsite интервью. Процесс подготовки Seniors отличается от процесса подготовки Juniors/Middles и занимает минимум три месяца. Оптимально — шесть. От книжек пользы не много, особенно от всюду рекламируемой Cracking the Coding Interview. За время ее существования вышла куча статей в Интернете с ее пересказом. Так что проще прочитать пару-тройку этих статей. Все другие книги пишутся как под копирку. Для подготовку к Coding Interview, я рекомендую книги по спортивному программированию. Мне больше всего помогла Guide to Competitive Programming: Learning and Improving Algorithms Through Contests. LeetCode полезен только в начале, для выработки и поддержания навыка решения задач. Больше месяца-двух тратить на него смысла нет. Можно стать умельцем решения задач LeetCode. Процесс решения задач на интервью все таки отличается. И да, не нужно ставить цель прорешать и запомнить все задачи. От этого пользы мало, так как задач очень много и их решения невозможно запомнить. Интервальные методы запоминая тут не помогут.
Пользы от независимых рекрутеров в подготовке к собеседованиям в FAANG практически мало, за исключением того когда им удалось заинтересовать FAANG вашей персоной. После этого вы все равно будете общаться в основном с рекрутерами из FAANG, которые и будут вас готовить к собеседованию. Но к моменту общения с ними вы уже должны быть более-менее подготовлены к собеседованию.
Полезно проходить собеседования в разные компании, для тренировки. Вот тут независимые рекрутеры могут быть полезны, так как они подготовят список таких компаний и быстро сведут с ними. Только не проговоритесь, что это вам для тренировки. Эти собеседования вам помогут улучшить коммуникационные навыки и стрессоустойчивость. Особо не надейтесь что они помогут вам подготовиться к техническим интервью FAANG.
Телефонные интервью — это по большей части лотерея. Способность быстро решать задачки на время увеличивает шансы выиграть в нее.
Onsite интервью — это тоже лотерея, но уже с большей вероятностью выйгрыша.
Будьте готовы к встрече с людьми с завышенным чувством собственного значения. Таким людям не нравится, когда ответ не совпадает с тем, что они хотят услышать. К счастью таких людей попадается очень мало. По большей части собеседования, особенно onsite, в FAANG оставляют приятные впечатления.
Очень помогает понимание того, что процесс собеседования в FAANG, нацелен прежде всего на минимизацию найма некомпетентного сотрудника. То что вы не прошли, еще не значит, что у вас больше нет шансов попасть в FAANG. Я в итоге прошел собеседования в Amazon и принял офер.
Если есть вопросы, спрашивайте, буду рад ответить.
Еще можно поиграть с developer.arm.com/documentation/101754/0615/armlink-Reference/armlink-Command-line-Options/--lto-level