Никогда особо не стремился в большие компании, по душе всегда были небольшие уютные игровые студии, где и "отеческий" нагоняй от лида получить легко, да и самому "парой ласковых" объяснить коллегам где они были не правы можно. Но конечно шальные мысли, а вот если бы в Я..., да какой-нибудь еще фейсгугл попробоваться. Жаль только они не делают игры, но мысль эта таилась на закорках подсознания, периодически напоминая о себе в моменты просмотра объявлений, да после писем рекрутеров на linkedin. Около года назад два моих знакомых, которые давно уже живут на другом континенте, но с кем застали еще распад питерского EA, вдруг объявились на страничке в linkedin, оставили отзывы да отсыпали скилов. Сначала я не придал этому особого значения, мало ли чего там себе люди думают, может просто сеть знакомых обновляют, есть у них там за океаном такая забава. И так получилось, что на эти отзывы сагрились hr-боты большого G..., что и привело в дальнейшем к очень интересному опыту взаимодействия с людьми, знакомством с кухней отбора, этапами собеседования и воронкой "смерти" входа. Осторожнее надо быть со своими желаниями.
Где-то уже на хабре были статьи и про G... и про Я..., такие, что читая описания задачек на собесах, волевым решением на следующее утро начинал решать leetcode. Воли обычно хватало где-то на неделю, а потом рутина боевых задач и митинги затаскивали обратно в уютную берлогу не очень большого игростроя. Почему я решил написать об этом только через год после всех событий? Да банально подмахнул на третьем собеседовании NDA о методах проведения интервью, а когда понял ЧТО подписал - уже было поздно.
Мне легко думается и пишется именно на плюсах, наверное последние вот уже лет двадцать я не изменял этой привычке и останавливаться или менять язык не думал. Но большой G... был настойчив, и почти продал мне позицию мидла на саппорте стандартной библиотеки golang в Cан-Хосе. За время работы в индустрии довелось пользоваться многими языками, большинство из вас их наверное даже и знает: MISRA C++ (конкретно диалект для BMW automotive), lua, javascript, squirrel/quirrel, jsc, mujs, dascript, haxe, scriptV, angelscript, clojurescript, papyrus и парочка самописных.
-1. Приглашение от большого G...
Погода не радовала. По виду, да и по сути, это была самая настоящая тропическая зима, с ливнями, которые смывают тебя по пути в магазин. За больше чем четыре года, я так и не привык, что дождь идет отовсюду, сверху, снизу, сбоку, а приходя домой выливаешь воду из карманов дождевика. Капли казалось проломят зонт, если его не унесет ветер. Коллеги говорили, что зонт покупать смысла нет, но я им не поверил. Остаться сухим на улице можно было перебегая из магазина в фойе отеля между зарядами дождя, но без навыков локальной телепортации в офис приходишь мокрый везде. А еще ветер, ветер это вообще отдельная тема. Узкие улочки мальтийских городов работают как самые настоящие аэродинамические трубы, в дождевике парусность значительно так увеличивается, еще не сносит, но прокладывать свой путь приходится галсами, минимизирую доступную ветру площадь тела. За две недели после приезда сломались четыре зонта, пока я не сломался их покупать. Местные зонтов не покупают, считая это пустой тратой денег. Туристы этих приколов не знают и получается: открыл зонт - выкинул зонт - купил зонт - открыл зонт - выкинул зонт. При всем этом в декабре-январе еще достаточно тепло +16 - +18 на улице, +18 в море. Вообще удивительно как ежедневно находясь на этом ветру, и мокрым добираясь до офиса и обратно особенно сильно и не болел.
За бокалом местного игристого (не ругайте сразу, картинка напитка будет в конце), я закрываю очередную таску по ИИ монстров, и тут на линкедин падает уведомление, потом на почту, и вдобавок прилетает смс на местный номер - "Леопольд, выходи. Выходи в Meet".
Шучу конечно, смс просто продублировала сообщение в линкеде. После первого, приглашения стали приходить стабильно раз в неделю, причем от разных HR-ов. С месяц я забивал на эти "письма щастья", но потом та мыслишка на закорках таки меня додавила и встреча была назначена. Судя по тому, что письма приходили от разных HR, единой базы у них нет, что довольно странно для мега конторы, особенно после слухов, что проваленное интервью закрывает минимум на полгода "дорогу из желтых кирпичей". Причем даже когда собес был забукан, два оставшихся HR продолжали звать меня с некоторой периодичностью из своей страны О(z).
0. Реши-ка ты десяток задач на leetcode
Да, вот так легко и непринужденно был поставлен вопрос на первом собеседовании. Сначала даже не было понятно, что это интервью. Девочка в сари, зачитала текст (просто сидела и читала в экран) на диком англо-хинди суржике, с очень мягкими t и s, так что не всегда даже было понятно, что за слова она произносила. Пробившись через весь этот акцент, я понял суть собеса - из представленных 10 задач надо было выбрать одну любую и написать решение онлайн не пользуясь подсказками. Надо сказать что на этапе -1, мне также скинули, что будет некий разбор задачи по выбору, но, если честно, было просто лень готовиться. Выделить время посреди майлстоуна и так проблемно, да еще Рождество, в общем было решено не читить с подготовкой. Среди списка задач была implement atoi() function, её наверное выбирает каждый первый, потому что она банальная и простая. Вот и я выбрал, ибо помнил еще её реализацию для эбмедед систем.
atoi_impl
//Implement the atoi(string s) function, convert a string to a 32-bit signed integer.
class Solution {
public:
int myAtoi(string str) {
char* i = &str[0];
char* e = i + str.size();
//trim space
for (; i != e; i++) if (*i != ' ') break;
int sign = 1;
if (*i == '-') { sign = -1; i++; }
else if (*i == '+') { i++; }
for (; i != e; i++) if (*i != '0') break;
long long num = 0;
for (int k=0; i != e, k < 11; i++, k++)
{
if (*i >= 0x30 && *i <= 0x39)
num = num * 10 + (*i - 0x30);
else
break;
}
if (num*sign > INT_MAX) return INT_MAX;
if (num*sign < INT_MIN) return INT_MIN;
return num * sign;
}
};
И... девочка в сари, начала разбирать мой код.
Тут нетолерантная шутка про индийцев, сочувствующих прошу не открывать
Что подождите? Индийские программисты? Программистки? Куда катится этот мир, Михалыч... Немного поелозив красной точкой между бровями насчет некрасивого кода и несоответствия кодстайлу задачу зачли. И на этом интервью закончилось.
Сначала меня попросили использовать оператор [] для доступа к элементам строки, на что было резонно отвечено, что вот он в самом начале используется, а дальше просто не нужен был. И вообще попеняли, что не использую интерфейс для string из std. Причина подобной претензии названа не была, кроме "так лучше", "Ситьс беття", что вероятно в переводе с новоанглийского значило "That is better". Забукано было 45 минут, потрачено где-то 20, 10 из которых я пытался понять новоанглийскую речь с очень мягким t, когда What превращается, превращается What... What превращается, в элегантный "воть", иногда даже в "во-оте". А Let в "лить, ли-ить" с протягом.
Решение забрать не дали, по памяти просто нашел эту задачу на литкоде и проверил, все ли решил правильно. Фидбек на второе (второе?) пришел через 10 дней, наверное большая загруженность. Кроме этого было предложено решить оставшиеся девять задач на leetcode, и добиться не менее 50% Beats для каждой.
И еще через две недели было приглашение на второе (или уже третье) интервью, теперь по алгоритмам c еще несколькими задачами. А простите вот это первое-второе интервью с задачками что было? Ну да ладно, не каждый день собеседуемся в большой G...
Полазив опосля по разным доступным форумам на предмет, чего же ребята интервьюверы хотели добиться на первом собесе, и почитав рассказы других бедолаг, пришел к мысли что:
код надо писать понятный, в гугловом кодстайле, тогда больше вероятность, что его смогут прочитать и понять, а непонятный код заворачивают без разбора, кто там умный такое написал
сложный код писать надо ограниченно, проверяющим пофиг, у них есть какое-то свое решение, на которое они ориентируются, и если ты в эти ограничения не попадаешь, то это твои проблемы
не выбирать задачу easy уровня, потому что в большинстве случаев прилетает отказ на следующий этап, даже если она была решена правильно и быстро. А такие там были, например посчитать медиану массива интов
1. Big O(n) with you
На этот раз что-то забуксовало в отлаженном конвейере переработки человеко-часов в место на жестком диске (все встречи пишутся с вашего согласия, если оного нет, то встреча автоматически переносится на другой день) и еще две недели меня футболили от одного инженера к другому. Честно, поначалу было обидно, просидев на первых двух встречах по десять минут, глядя в черный экран за бокалом местного игристого, часто ловил себя на мысли - "А на кой мне это всё?". Наконец долгожданная встреча состоялась, и опять человек индийской наружности с листом бумаги. Meet, индус, бокал местного игристого, поехали...
Разговор сразу не задался, потому что у Сариха (имя где-то близко, но это не точно) явно прослеживалось желание меня завалить побыстрее, не знаю чем уж я ему так не понравился. Были спрошены сложности !всех! контейнеров стандартной библиотеки, просто по порядку, написанному на листке. И еще парочки из буста, на что я честно ответил, что не знаю, ибо в бусте сам Антошка обе ноги поломает на имплементации этих контейнеров. Шутку про Антошку человек не понял.
Собеседование продолжалось, желание меня завалить у интервьюера не пропадало, в итоге он нашел таки слабое место в моих познаниях, на вопрос о реализации std::map/unordered_map я честно ответил что мало работал c ними, по той причине, что все наши игродевовские контейнеры это линейный массив, ну и какие-то его производные. Зря это сказал, потому что все следующие десять минут до конца секции по сложности алгоритмов были по мапе и разным вариантам её реализации.
Догадаетесь какую дали задачу? Ну конечно по реализации unordered_map. Сама задача выглядит безобидно, но основным условиям было не использовать стандартные контейнеры вроде map/unordered_map. Т.е. кроме самого алгоритма, он на самом деле не очень сложный, если вы когда-нибудь сталкивались с такой задачей, надо написать еще и приемлемую по времени реализацию std::map. Дается на всё это 45 минут, плюс то время, что осталось от секции про сложность, т.е. плюс 0 минут.
Given two strings of varying lengths, solve the problem of finding
the minimum window substring in one of them, such that every character
in the other string (including duplicates) is included in the window.
Позже я покопался на литкоде, и нашел эту же задачу в разделе hard, только без необходимости написания с нуля unordered_map. Тут есть на самом деле неочевидный хак, который можно упустить или некоторые интервьюеры (как опять же выяснилось дальнейшими исследованиями на форумах) забывают упомянуть. Класс map можно не реализовывать, и воспользоваться оным из стандартной библиотеки, но получить высокую оценку по ревью в этом случае не получится. Трудолюбивым и глухим придется реализовать и сам алгоритм и вспоминать - как там сделана unordered_map, потому что вариант обычной был отвергнут проверяющим как недостаточно быстрый.
В отведенное время я, понятное дело, не уложился. Вообще редко получается сделать задуманное в срок, мне всегда надо было подумать над решением, выпить чашечку кофе, потрындеть с коллегами, и вообще пик продуктивности находится в интервале 18 - 23. И поэтому когда тебя в 8 утра мучают DSA задачками, код выходит не всегда оптимальный. Дописывать пришлось уже под недовольное бурчание проверяющего и превысив лимит минут эдак на пятнадцать. Нет, никто не отбирал доступ к лайвредактору, просто шумно вздыхал, громко смотрел на часы и противно стучал клавишами. В итоге, времени на разбор самого решения почти не осталось, на сам алгоритм товарищу было откровенно наплевать, и все оставшееся время, около 10 минут было потрачено на анализ работы unordered_map. Честно, ожидал немного другого.
Cамо решение ниже, уже обкатанное на литкоде, но без всей этой возни с собственной map.
min_window_impl
class Solution {
public:
string minWindow(string s, string t) {
unordered_map<char, int> m;
m.reserve(1000);
int i = 0, j = 0, count = 0;
string res = "";
for(auto x: t) {
m[x]++, count++;
}
int nsize = s.size();
int min_len = INT_MAX;
while(j < nsize){
if(m[s[j++]]-- > 0) {
count--;
}
if(count == 0){
while(m[s[i]] < 0) {
m[s[i++]]++;
}
int len = j - i;
if(len < min_len){
min_len = len;
res = s.substr(i, len);
}
m[s[i++]]++;
count++;
}
}
return res;
}
};
Вставал из-за компа мокрый, как будто два часа бегал, а не думал. Возня и выход за временной лимит не остались безнаказанными, но все обошлось. Фидбек пришел через неделю с хвостиком. В нагрузку кинули еще задачек на https://codesignal.com/, я так понял там есть возможность создавать что-то вроде автоматических контрольных, и все правильные ответы улетают менторам на анализ.
2. Очень странные дела
Перед следующим техинтервью, мне как раз и предложили подписать mini NDA, и пройти довольно странный психологический тест. Надо было представить свое окружение, как можно с большей детализацией, как будто вы живете в пустыне, распорядок дня, занятия, животные и люди вокруг. Это был очень странный получасовой монолог с моей стороны, потому что проверяющая сторона все это время просто тупила в телефон, судя по отражению в очках, зависала в тиктоке и инсте, листая ленту, жаль не подумал это заскриншотить. В итоге моя личная пустыня очень напоминала давно смотренный фильм "Cахара", с незабываемой парочкой Макконахи и Крус, поэтому там присутствовали старый пуленепробиваемый мерседес, лошадь, собака и древний броненосец с кладом, затерянный в песках, а туареги, те которые кочевники, а не фольцвагены, бодро атаковали какой-то затерянный завод, недалеко от пирамиды Хеопса. Полчаса безудержной фантазии, за соавторством Клайва Касслера, походу ушло на прокорм очередной МL, других применений подобным тестам я не нахожу. Интервьювер? Психолог видимо подвоха не поняла, или поняла, но никоим образом этого знания не выдала. Полчаса жизни в пустую, фидбека никакого, только свежеподписанный годовой NDA. Ну хоть потренировался в английском, прям сейчас эссе пиши, на тему проживания одинокого программиста в условиях пустыни, под дикие крики фольцвагенов, т.е. крики диких туарегов.
3. Сбой в матрице
Судя по присланным, по результатам прошлого техинтервью, материалам и задачкам на CodeSignal, собеседовать меня должен был как минимум архитект, ну и или на худой конец лид. Все задачи были сплошь из секции хард на литкоде, и, если честно, это несколько пугало. Но не сильно, решая вечерами самые трудные, как мне казалось, задачи, спокойно отпраздновал день рождения и подзабил на оставшиеся, выполняя их по возможности. К тому же очередной майлстоун в студии, гугл он где-то там за океаном, а таски они вот в жире висят, и лид периодически за них спрашивает.
Пришло время интервью, я готовился к разносу в пух от мЭтров, но матрица дала сбой: интервью началось с того, что проверяющий минут десять не мог настроить камеру, и первое время мы обсуждали как перевернуть картинку в meet через конфиги, потом несколько раз пересоздавали сессию, камера несколько секунд была фоном потом переворачивалась вверх ногами и выключалась, очень похоже было на какой-то фильтр, потому что при резких движениях отдельные части тела проявлялись. Наконец все заработало и я увидел настоящего Инди программиста, знаете как показывали в фильмах в нулевые? Только в клетчатой рубашке, и с пышными усами, свисающими вниз над уголками рта. Для полного антуража не хватало только шляпы и кнута Индианы, чтобы подгонять нерадивых джунов. Собеседника звали Анджей и он был из варшавского офиса компании.
Какое-то боевое настроение улетучилось, ну как можно бояться Инди с усами, которому ты настроил камеру за тысячу километров? Это же как парное программирование, после такого уже по-другому смотришь друг на друга.
А дальше было повторение второго техинтервью, заново прошлись по всем контейнерам, их сложности, используемым алгоритмам, особенностям реализации. Мои наивные попытки было сказать пару раз, что все это уже было, разбивались об укоряющий взгляд проверяющего, несколько минут обсуждали чем отличается мой ответ от предыдущего, что я еще могу добавить и... разбор списка контейнеров продолжался дальше.
Пришлось смириться, но ощущение дежа вю, не покидало меня до самого окончания, успели пройти и обсудить две трети списка, остались queue, priority_queue и подсекция flat_map_xxx. Но заканчиваются выделенные 45 минут, собеседник прощается и выключает камеру. Э... дружище, я же тебе её настраивал десять минут, а ты так... Не хватило тех 10 минут, что я творил доброе и вечное, вот и верь после этого в людей.
Фидбек пришел как обычно через неделю.
В общем вторую алгоритмическую секцию я завалил. Оказывается это была неосновная часть, т.е. до главной секции я даже не добрался, сказать что я был расстроен? Расстроен, сильно, пришлось уговорить бутылочку местного игристого, грустно смотря на красивые Luzzu.
4. Design Review
Это было пожалуй единственное нормальное, в моем понимании, собеседование. Во-первых, оно было с открытой датой, это значит, что можно было назначить когда удобно обеим сторонам, единственное пожелание - не затягивать с прохождением. Все предыдущие просто представляли слот, если он не подходил - следующий был через неделю. Во-вторых, на нем действительно затрагивались вопросы, имеющие непосредственное отношение к моей текущей и возможно будущей позиции.
Собеседник попался опять из варшавского офиса, расспросил меня про текущий опыт работы, используемые алгоритмы и какие системы, паттерны и технологии используются на текущем месте работы. А потом попросил спроектировать одну из наших работающих систем с нуля, собственно одну из таких систем я делал с нуля, и где-то минут через десять рассказа, рисования кружков, квадратов и общего алгоритма работы, беседа плавно перешла к подробному обсуждению конкретной реализации, возможности масштабирования и различным хакам, которые были использованы. Написания кода, как такового не было, зато нарисовался и наговорился вдоволь.
Такая ненапряженная и дружелюбная атмосфера, а также внимание к деталям со стороны собеседующего превратили эту встречу скорее в разговор двух инженеров, обсуждающих технические подробности реальной работающей системы. В целом это был намного более ценный опыт, чем студенческого вида экзамены на знание DSA.
5. System review
Системное собеседование было опциональным, в принципе его можно было не проходить. По утверждению HR никаких дополнительных баллов, равно как и штрафов за непрохождение последнего не будет. Но мы же понимаем, что бесплатный сыр бывает только мышке ловкой, гулять так на все деньги. Собеседование заняло чуть больше двух часов, и было выстроено в формате вопрос ответ, если ответы были четкими и быстрыми, меня останавливали и задавался следующий вопрос. Если же проверяющему что-то не нравилось, то задавались наводящие вопросы. На каждый ответ по косвенным подсчетам было дано не больше 5 минут, это было заметно, потому что собеседник с каждым новым вопросом смотрел на часы и записывал время (вероятно время, т.к. самого листа мне видно не было) начала на бланке. По времени собеседование было разбито на две части
Принципы работы ОС
IPC, модели памяти и синхронизация
До виртуализации и принципов работы файловой системы не добрались, по причине что закончилось выделенное время на этот этап. Если вдруг соберетесь проходить эту секцию, советую перечитать Таненбаума, лучше него пожалуй никто так работу ОС и не расписал в книгах.
На какие вопросы успел ответить:
Ключевые элементы ОС
1. Абстракции (процессы, потоки, файлы, сокеты, память)
2. Объекты ядра (создание, управление, открытие, запись, распределение)
3. Политики объектов (алгоритмы LRU, EDF).Ключевые элементы исполняемого процесса
1. Stack, Heap, Registers, Data
2. PCB и модель выполнения процессаПотоки и параллелизм
1. Threads, Fibers, чем отличаются и как реализованы в разных ОС
2. Уровни реализации потоков: пользовательский и на уровне ядра
3. Понимание контекста и моделей переключенияПланировщики и алгоритмы планирования
1. Очередь задач
2. Очередь ожидания
3. Очереди устройств
4. Методы управления очередями (FIFO, Round Robin, Priorities)Управление памятью
1. Символьные адреса
2. Относительные адреса
3. Физические адреса
4. Существующие модели менеджеров памятиIPC
1. Модель общей памяти
2. Модель обмена сообщениями
3. Примитивы синхронизации
3.1 mutex (recursive)
3.2 spinlock
3.3 rwmutex
3.4 semaphore
3.5 active waiting
3.5 hw lock
3.6 memory barrier
6. Тестовое
На этом можно было закончить эпопею с собеседованиями и вернуться в родной и уютный игродев допиливать игру на букву М..., но выработанная годами привычка доводить начатое до статуса "approved in dev" не дала бросить все на половине пути.
Тестовое задание совсем не впечатлило, надо было всего лишь написать реализацию двойной очереди событий с приоритетами, по возможности без блокировок. Я уже было настроился на что-то вроде, напишите систему управления ядерным реактором, ну или на крайний случай спутником. А тут, вполне приземленное задание, не слишком сложное. Не сложное по причине широкого применения паттерна таких очередей с приоритезацией в игровых движках, где на них построено большинство компонентов, начиная от системы тасок для фрейма и заканчивая очередями загрузки ассетов. Думаю вы догадываетесь, откуда черпалось вдохновение.
Test Assignment/L4R (San Jose, golang support labs):
Objective
You goal to implement a priority double-ended queue (PriorityDeque) in C++. If you're up for a challenge, try to make it lock-free.
Tasks
-
Main Part (60 points):
Build a
PriorityDeque
class to handle insertion, removal, and retrieval from both ends of the queue.Each element must have a priority. The queue should prioritize elements with higher values first.
-
Your implementation should include these methods:
add an element with priority at the front.
add an element with priority at the back.
remove and return the front element.
remove and return the back element.
check if the queue is empty.
get the current size of the queue.
-
Optional Part (Lock-Free, 40 points):
Implement a lock-free version using atomic operations and synchronization primitives.
Detail your approach and use the right data structures and algorithms to ensure performance and correctness.
Requirements
!!! Do not use any of the C++ Standard Library (STL) components
BUT! For the lock-free part, use atomic operations from
<atomic>
.The solution must be thread-safe and handle concurrent access.
Optimize for time and memory efficiency.
Evaluation Criteria
Correctness of the solution (required).
Performance and efficiency (20 points).
Code quality and readability (10 points).
Lock-free implementation (optional, 10 points).
Comments and documentation (20 points).
Tests to verify all class methods (20 points).
Recommendations
Think about the data structure you'll use for storing elements and their priorities.
For the lock-free implementation, get familiar with algorithms and synchronization primitives like CAS (Compare-And-Swap).
Modularize your tests to cover all class functions.
Deadline
Let's aim to have this ready within one week from receiving the task.
Ну чтож, прибавление в коллекции тестовых заданий. Написать там арканоид за час или танчики за неделю, было. Написать программу для расчётов распространения звукового луча в гетерогенной среде, тоже было, но за неё хотя бы заплатили. Написать "жизнь" за пару дней, тоже было. И пусть я писал на плюсах заведомо ненужный код, для команды которая делает стандартную библиотеку для golang, это все равно было отличной проверкой знаний.
Вы наверное ждете фидбека? Он был через месяц после сдачи тестового. Между ними ничего, ни даже привет пока, просто автоответ - мы получили ваше решение. Пришлось пару раз им напомнить о себе, но в ответ получал все тоже автоматическое послание, слово в слово. На третий же раз пришел нормальный ответ, ну почти нормальный
Dear Candidate,
We've noticed that you put a lot of effort into solving this task.
You've done a commendable job addressing the challenges and have developed
a robust and proficient code, which passed most of our tests with flying colors. However, it's worth mentioning that you didn't embrace industry-standard solutions that would enable other developers to reuse your work. Additionally, we observed a lack of focus on system-level error handling.Best regards,
Golang support team
7. Финал конкурса красоты
Как вы видите по тону письма, пора было сушить весла. Но на следующее утро HR в очередной раз назначил встречу, а еще где-то через две недели был финальный этап, когда независимая комиссия из 4 человек на созвоне читала отчеты людей, которые меня собеседовали, туда же попали и отчет после системного интервью и резолюция психолога (это никуда не уйдет, говорили они). Проверяли насколько мой опыт и скилы подходят для разных команд, и вообще для позиции L4 инженегра. По общей сумме баллов на ту самую позицию мидл go (L4) разработчика в Сан Хосе я не прошел, не было 3 years securiy clearance (если я правильно понял, это сколько надо прожить и проработать в штатах, чтобы претендовать на это место), а соглашаться на L3 (де факто Junior и таких условий там не было) сам был не готов. Зато были две команды в Европе, одна в Варшаве, другая виртуальная, полностью на ремоуте, которые были готовы меня взять на L4. В августе 2023 года года прислали оффер.
Но как вы понимаете, статьи бы не было, если бы я был там, а пока что ветерок, солнце и местное игристое.
Выводы
Все вышеописанные приключения, читай собеседования, в одну из мировых компаний, кмк не проверяют абсолютно ничего из реальных навыков. Ну разве тот факт, что вы чилили на leetcode или codesignal, знаете синтаксис языка и немного понимаете в алгоритмы, об этом в следующем абзаце. Эти собеседования абсолютно не проверяют реальные знания алгоритмов и возможности их применения в реальных проектах, потому что если проверяющий сам смотрит ответы в листочке, "какой он нафиг танкист"?
Можно верить в то, что знание алгоритмов научит вас программировать на плюсах, гошечке или питоне, не научит - проверено на десятке студентов и интернов. В лучшем случае на обучение такого программиста-олимпиадника потратят уйму времени ваши коллеги и вы лично, в худшем олимпиадник останется при своем мнении, что через бинарный поиск можно сделать любую таску. А команда так и останется с незакрытыми задачами, и острой аллергией на студентов и джунов.
А еще собеседующие из больших отделов и компаний никак не мотивированы проводить адекватные собеседования, причём думаю сознательно, брать в коллеги более сильных ребят - значит готовить себе замену.
Остальные выводы делайте сами.
P.S.
От ответа на письмо эйчара, до получения оффера прошло больше чем пол года. Собеседования были каждый месяц, каждое в среднем по часу-два, кроме первого. Было три DSA-собеса, одно на дизайн, и одно системное + тестовое задание, нетехнические пропустил.
Однозначный плюс от внимания HR из крупной компании был - стали чаще заходить HR размером поменьше, да и отвечать стали охотнее, даже с учетом красноты паспорта.
pseudotech
У Вас 20 лет опыта и они заставили Вас проходить через такое??? Это, конечно, очень странно, но хотел спросить другое, а именно из Вашего рассказа не совсем понятно: это была какая-то большая геймдев компания или же просто какой-то ИТ гигант?
Sazonov
Это ещё ладно. Я в том году собеседовался на с++ лида в s&p но через индийский аутсорс. Двух индусов прошёл легко, потому что знал что отвечать. А вот собес уже непосредственно с заказчиком меня вогнал в ступор. Меня на полном серьезе попросили развернуть массив. На вопрос, пригодятся ли такие навыки на позиции техлида у них на проекте - как-то замялись и не ответили.
Зато рассказали подробнее про проект. Когда я услышал про mfc - предложил сворачивать интервью. На что собеседующие даже немного обиделись - мол мы думали что вам очень понравилась наша компания и у вас горят глаза и есть непреодолимое желание развиваться.
dalerank Автор
Ну вообще есть понятие нерелевантного опыта, как вам например поможет знание компилятора шейдеров юнити при разработке оберток над файловой системой в go? А так 2-3 DSA секции вполне себе устоявшаяся практика во многих компаниях, начиная от стартапа и заканчивая яндексом, американцы еще любят всякие reference letter просить. Есть конечно перегибы, я не люблю делать тестовые, ну тут уж кого деньги, того и правила. Все в рамках приличия было.