Нет, если сможете на словах объяснить как он работает. В моей предыдущей компании был список задач на позицию дата инженера. Одна из задач заключалась в удалении дублирующих записей из данных. В рекомендациях был пункт о достаточности решений вида sort -u или distinct() из спарка, если кандидат мог объяснить как они работают. В той компании кодинг интервью требовали от кандидата решить минимум одну задачу и сильно продвинуться во второй. Быстрый ответ на один из вопросов сильно упрощал прохождение интервью. Есть еще крутая тактика говорить интервьюверу, что вы точно знаете решение задачи. Иногда, интервьювер принимает решение без кодинга после пары уточняющих вопросов. Я терпеть не могу задачи на графы, потому что для них долго писать юнит тесты. А еще я часто делаю ошибки в max-flow алгоритме при обновлении остаточной матрицы. Если мне попадается задача на граф, я стараюсь сразу сказать, что знаю решение, назвать алгоритм и сложность. Пока не срабатало 2 раза из где-то 10. В Убере была усложненная версия задачи уровня хард и усложнение сильно меняло решение, я, кстати, не смог его в итоге решить за час потому что потратил много времени на первую идею. Еще один раз была задача на определение является ли граф деревом, интервьювер из Reddit не знал о UnionFind. Он даже с тестами не верил, что решение работает. Не знаю, как он меня оценил, но я получил оффер. В остальных случаях тактика работала как магия. Но есть шанс получить более сложную задачу второй потому, что времени много остается.
Я не знаю как проходит дебриф в гугле. Но обычно у L5 кандидатов наибольшее влияние имеют последние два раунда. На L6 становится еще больше поведенческих интервью. А на L7 в Мете может быть вообще один раунд кодинга и в прошлом году его можно было полностью провалить и все равно получить офер. Жаль в статье эти интервью почти не раскрыты.
На кодинг интервью никому не интересны ваши навыки литкода. Точнее от кандидата по умолчанию ожидается умение решать легкие/средние задачи с литкода быстро. Это такой негласный контракт между кандидатами и интервьюверами. Вы должны знать несколько десятков алгоритмов, уметь их применять и, самое главное, уметь их понятно обьяснить в рамках задачи. Даже если это кажется вам бесполезным. Это как правило хорошего этикета, второе проще есть ложкой, но нужно уметь пользоваться ножом и вилкой. Так же и на интервью, отсутствие умения решать задачи или знания о базовых алгоритмах это красные флаги.
В моей команде в рамках кодинг интервью индивидуально оцениваются несколько параметров, которые формируют финальную оценку. Прямо сейчас в рамках кодинг интервью мы оцениваем релевантность предыдущего опыта, ответ на короткий поведенческий вопрос, решение проблемы (problem solving skill), стиль кода, работоспособность финального решения и тесты, коммуникативные навыки. В зависимости от позиции и кандидата вес параметров меняется. У нас были кейсы, когда очень релевантный опыт в узкой сфере перевешивал все остальное. Так и плохие коммуникативные навыки могут перевесить все остальное для высоких позиций. Автор делает акцент на правильное финальное в конце, но на самом деле оно может оказывать минимальное влияние на финальное решение на L5.
Еще интервьюверы смотрят на красные флаги и могут провоцировать кандидатов на красные флаги. Я проходил интервью тренинги Gayle McDowell, она построила карьеру на том, что учит компании проводить интервью как в Гугле. Она сказала, что поиск красных флагов это одно из главных причин интервью панелей с множеством этапов. False negative решения о найме в виду иногда надуманных красных флагов дешевле для компании, чем найм человека с серьезными поведенческими или коммуникатывными проблемами.
ПС: вопрос "а как вы используете такие алгоритмы в работе?" с пассивно-агрессивным подтекстом, что алгоритмы бесполезны, это красный флаг, который часто встречается у кандидатов из России и Индии.
1) Проблему прогрева in-memory кэшов можно решать с помощью файлов. Собирать кэш по частоте запросов в файл с помощью оффлайн процесса. На старте дергать файл из Object Storage и десериализовать в память. Это быстрее и дешевле, чем пиковые нагрузки KV хранилища при рестарте.
Инвалидацию и обновление так же оставить на кафке. Приложение может начать читать обновления с оффсета прописанного в файле кэша.
2) У вас низкое соотношение ядер к памяти. Если поднять до стандартных 1к4 или 1к8 для RAM-оптимизированных, то можно отказать от внешнего кэша совсем при правильном шардировании или sticky-sessions без изменения логики приложения. Я так сэкономил 200к$/месяц перенеся кэши из редиса в память general purpose AWS EC2-инстансов.
3) Посмотрите в сторону memory-mapped файлов на SSD и их индексов в памяти. Сам видел 200Гб информации о товарах на SSD для системы рекоммендации от вашего азиатского конкурента. У них latency SLO был около полсекунды и это включая рекомендации. Но у них не было обновлений. По идее можно хранить последние обновления в памяти, пока новый индекс не подъедет.
Могу немного рассказать про роль в рамках американских компаний. Последние 5 лет имел роль L6 архитектора в компании из fortune 20. Для контекста, мой орг насчитывал 70 человек в 3 странах. Мы поддерживали 3 платформы с миллионными QPS и реализовывали десятки E2E решений в год для определенного круга бизнес задач. Я напрямую репортил L8 синьор директору, периодами VP.
Для платформ я был system architect. Основные обязанности были: 1) Предоставление виденья развития на следующие 1-5 лет. 2) Выявление и документирование и внедрение инженерных стратегий на основе архитектурных записей. 3) Помогать продуктовым и инженерным менеджерам с квартальным планированием. 4) Ревью дизайн документов. Можно заметить, что я не занимался дизайном решений сам. У платформ есть тех лидеры и несколько стафф инженеров, для которых проектная работа важнее в плане роста. Но я контролировал, какие решения выбирает команда и как они согласуются со стратегиями и виденьем.
Для E2E решений я был solution architect. Обычно в проекте участвовало 50-60 человек из 10-15 команд. Но были у меня и проекты на 400 человек. Основные обязанности: 1) Сбор требований для проекта 2) Разработка модели 3) Согласование с безопасниками и юристами 4) Согласование со всеми командами и лидерами. Для больших проектов согласование может быть в формате офф-сайт на 100+ человек на 2-3 дня, как правило, в долине, но однажды был в Нью-Йорке. 5) Помощь в планировании 6) Помощь с внезапными вопросами в процессе реализации. 7) Ретроспектива и обновление стратегий/видения. Опять же отличается от описанного в статье. Дизайн, реализация, тестирование и поддержка ложатся на плечи лид инженеров из соответствующих команд. Контроль выполнения, решение комуникационных проблем и "мотивирование" успеть в срок лежит на TPM. У TPM, как правило, 1-3 важных проекта на квартал, у них есть на это время. У моей команды обычно было 10-15 важных проекта на квартал. Я либо сам участвовал, либо спонсировал своих падаванов.
Еще в обязанности входит менторинг, обучение команды и прочие technical excellence. Обычно мне на квартал давали 2-3 человека, и еще двое помогали мне на постоянной основе. Я хостил минимум один коричневый мешок в квартал. Плюс иногда отвечал за technical excellence проекты, например, смещение акцента с юнит тестов на интеграционные и внешние функциональные. Такой проект обычно включает несколько презентаций и близкую работу с тех лидами в течении квартала.
Можно заметить, что горизонт планирования у меня был квартал. Это означает, что надо мной было еще 2 уровня архитекторов. Надо мной был архитектор ответственный за 10к орг. Ее горизонт планирования в районе года. Обычно я с ней созванивался пару раз в неделю. Над ней был еще круг из 3х архитекторов, чьи позиции эквивалентны VP+, они ответственны за стратегические решения, которые повлияют на компанию в следующие 3+ года, может десятилетия.
По поводу должен ли архитектор писать код. На первом интервью с рекрутерои на L6+ вам скажут, что ожидают от линейных инженеров на этой позиции 70% проектной работы и 30% написания кода. Как архитектор, я иногда пилил маленькие проверки идей в последний месяц квартала, если удача была на моей стороне. Но никто не просил меня писать код. Я пытался хотя бы делать код ревью ключевых фич в моих проектах чтобы поддерживать связь с реальностью.
Нет, если сможете на словах объяснить как он работает. В моей предыдущей компании был список задач на позицию дата инженера. Одна из задач заключалась в удалении дублирующих записей из данных. В рекомендациях был пункт о достаточности решений вида sort -u или distinct() из спарка, если кандидат мог объяснить как они работают. В той компании кодинг интервью требовали от кандидата решить минимум одну задачу и сильно продвинуться во второй. Быстрый ответ на один из вопросов сильно упрощал прохождение интервью.
Есть еще крутая тактика говорить интервьюверу, что вы точно знаете решение задачи. Иногда, интервьювер принимает решение без кодинга после пары уточняющих вопросов. Я терпеть не могу задачи на графы, потому что для них долго писать юнит тесты. А еще я часто делаю ошибки в max-flow алгоритме при обновлении остаточной матрицы. Если мне попадается задача на граф, я стараюсь сразу сказать, что знаю решение, назвать алгоритм и сложность. Пока не срабатало 2 раза из где-то 10. В Убере была усложненная версия задачи уровня хард и усложнение сильно меняло решение, я, кстати, не смог его в итоге решить за час потому что потратил много времени на первую идею. Еще один раз была задача на определение является ли граф деревом, интервьювер из Reddit не знал о UnionFind. Он даже с тестами не верил, что решение работает. Не знаю, как он меня оценил, но я получил оффер. В остальных случаях тактика работала как магия. Но есть шанс получить более сложную задачу второй потому, что времени много остается.
Я не знаю как проходит дебриф в гугле. Но обычно у L5 кандидатов наибольшее влияние имеют последние два раунда. На L6 становится еще больше поведенческих интервью. А на L7 в Мете может быть вообще один раунд кодинга и в прошлом году его можно было полностью провалить и все равно получить офер. Жаль в статье эти интервью почти не раскрыты.
На кодинг интервью никому не интересны ваши навыки литкода. Точнее от кандидата по умолчанию ожидается умение решать легкие/средние задачи с литкода быстро. Это такой негласный контракт между кандидатами и интервьюверами. Вы должны знать несколько десятков алгоритмов, уметь их применять и, самое главное, уметь их понятно обьяснить в рамках задачи. Даже если это кажется вам бесполезным. Это как правило хорошего этикета, второе проще есть ложкой, но нужно уметь пользоваться ножом и вилкой. Так же и на интервью, отсутствие умения решать задачи или знания о базовых алгоритмах это красные флаги.
В моей команде в рамках кодинг интервью индивидуально оцениваются несколько параметров, которые формируют финальную оценку. Прямо сейчас в рамках кодинг интервью мы оцениваем релевантность предыдущего опыта, ответ на короткий поведенческий вопрос, решение проблемы (problem solving skill), стиль кода, работоспособность финального решения и тесты, коммуникативные навыки. В зависимости от позиции и кандидата вес параметров меняется. У нас были кейсы, когда очень релевантный опыт в узкой сфере перевешивал все остальное. Так и плохие коммуникативные навыки могут перевесить все остальное для высоких позиций. Автор делает акцент на правильное финальное в конце, но на самом деле оно может оказывать минимальное влияние на финальное решение на L5.
Еще интервьюверы смотрят на красные флаги и могут провоцировать кандидатов на красные флаги. Я проходил интервью тренинги Gayle McDowell, она построила карьеру на том, что учит компании проводить интервью как в Гугле. Она сказала, что поиск красных флагов это одно из главных причин интервью панелей с множеством этапов. False negative решения о найме в виду иногда надуманных красных флагов дешевле для компании, чем найм человека с серьезными поведенческими или коммуникатывными проблемами.
ПС: вопрос "а как вы используете такие алгоритмы в работе?" с пассивно-агрессивным подтекстом, что алгоритмы бесполезны, это красный флаг, который часто встречается у кандидатов из России и Индии.
Какой у вас объем данных во внешних кэшах?
1) Проблему прогрева in-memory кэшов можно решать с помощью файлов. Собирать кэш по частоте запросов в файл с помощью оффлайн процесса. На старте дергать файл из Object Storage и десериализовать в память. Это быстрее и дешевле, чем пиковые нагрузки KV хранилища при рестарте.
Инвалидацию и обновление так же оставить на кафке. Приложение может начать читать обновления с оффсета прописанного в файле кэша.
2) У вас низкое соотношение ядер к памяти. Если поднять до стандартных 1к4 или 1к8 для RAM-оптимизированных, то можно отказать от внешнего кэша совсем при правильном шардировании или sticky-sessions без изменения логики приложения. Я так сэкономил 200к$/месяц перенеся кэши из редиса в память general purpose AWS EC2-инстансов.
3) Посмотрите в сторону memory-mapped файлов на SSD и их индексов в памяти. Сам видел 200Гб информации о товарах на SSD для системы рекоммендации от вашего азиатского конкурента. У них latency SLO был около полсекунды и это включая рекомендации. Но у них не было обновлений. По идее можно хранить последние обновления в памяти, пока новый индекс не подъедет.
Могу немного рассказать про роль в рамках американских компаний. Последние 5 лет имел роль L6 архитектора в компании из fortune 20. Для контекста, мой орг насчитывал 70 человек в 3 странах. Мы поддерживали 3 платформы с миллионными QPS и реализовывали десятки E2E решений в год для определенного круга бизнес задач. Я напрямую репортил L8 синьор директору, периодами VP.
Для платформ я был system architect. Основные обязанности были: 1) Предоставление виденья развития на следующие 1-5 лет. 2) Выявление и документирование и внедрение инженерных стратегий на основе архитектурных записей. 3) Помогать продуктовым и инженерным менеджерам с квартальным планированием. 4) Ревью дизайн документов. Можно заметить, что я не занимался дизайном решений сам. У платформ есть тех лидеры и несколько стафф инженеров, для которых проектная работа важнее в плане роста. Но я контролировал, какие решения выбирает команда и как они согласуются со стратегиями и виденьем.
Для E2E решений я был solution architect. Обычно в проекте участвовало 50-60 человек из 10-15 команд. Но были у меня и проекты на 400 человек. Основные обязанности: 1) Сбор требований для проекта 2) Разработка модели 3) Согласование с безопасниками и юристами 4) Согласование со всеми командами и лидерами. Для больших проектов согласование может быть в формате офф-сайт на 100+ человек на 2-3 дня, как правило, в долине, но однажды был в Нью-Йорке. 5) Помощь в планировании 6) Помощь с внезапными вопросами в процессе реализации. 7) Ретроспектива и обновление стратегий/видения. Опять же отличается от описанного в статье. Дизайн, реализация, тестирование и поддержка ложатся на плечи лид инженеров из соответствующих команд. Контроль выполнения, решение комуникационных проблем и "мотивирование" успеть в срок лежит на TPM. У TPM, как правило, 1-3 важных проекта на квартал, у них есть на это время. У моей команды обычно было 10-15 важных проекта на квартал. Я либо сам участвовал, либо спонсировал своих падаванов.
Еще в обязанности входит менторинг, обучение команды и прочие technical excellence. Обычно мне на квартал давали 2-3 человека, и еще двое помогали мне на постоянной основе. Я хостил минимум один коричневый мешок в квартал. Плюс иногда отвечал за technical excellence проекты, например, смещение акцента с юнит тестов на интеграционные и внешние функциональные. Такой проект обычно включает несколько презентаций и близкую работу с тех лидами в течении квартала.
Можно заметить, что горизонт планирования у меня был квартал. Это означает, что надо мной было еще 2 уровня архитекторов. Надо мной был архитектор ответственный за 10к орг. Ее горизонт планирования в районе года. Обычно я с ней созванивался пару раз в неделю. Над ней был еще круг из 3х архитекторов, чьи позиции эквивалентны VP+, они ответственны за стратегические решения, которые повлияют на компанию в следующие 3+ года, может десятилетия.
По поводу должен ли архитектор писать код. На первом интервью с рекрутерои на L6+ вам скажут, что ожидают от линейных инженеров на этой позиции 70% проектной работы и 30% написания кода. Как архитектор, я иногда пилил маленькие проверки идей в последний месяц квартала, если удача была на моей стороне. Но никто не просил меня писать код. Я пытался хотя бы делать код ревью ключевых фич в моих проектах чтобы поддерживать связь с реальностью.