Comments 26
Хороший обзор, спасибо. Я бы ещё добавил про Monolith First Approach - иногда рациональнее не пытаться всё создавать с микросервисов
Охренеть, постарался, спс
История из серии "ожидание - реальность".
Проходил как-то собеседование в одну из FAANG компаний. Изучил кучу подготовительных материалов (включая их собственные, которые они высылают заранее, где была схема как в статье).
На собеседовании по system design мне предложили сделать бесконечный скролл ленты новостей, при этом исключительно фронтенд, "don't worry about back-end" (huh?)
На любые мои вопросы о требованиях к дизайну фичи (о каких платформах идет речь, разрешена ли автоматическая подгрузка или пользователь должен нажать load more, сколько новостей планируется загружать за раз, какой объем данных, планируется ли подгрузка новых новостей или только старых т.е. должна ли быть лента двухсторонняя итд), собеседующий (не очень) велживо уходил от ответа.
А при попытке объяснить, что при дизайне таких систем нужно начинать с high level understanding (невозможно "просто придумать фронтенд" не зная, как будет работать бэкенд или хотя бы какие к нему должны быть требования) собеседующий предлагал "приступить уже к работе" и "начинать уже писать какой-нибудь код"
Надо сказать что по окончанию интервью я так и не понял, что именно собеседующий от меня хотел, и в компанию меня не взяли.
Это скорее неудачное исключение из правил. Сам лично смотрел много фидбэков по моим интервью, везде пишут как плюсы "Прежде чем приступить уточнил у меня задачу" и "Прежде чем кодировать поделился со мной решением". Если этих двух пунктов не сделать, это минус.
Хотя если проходить интервью у каких-нибудь международных компаний с индусами-интервьюерами, то они тупо ищут маркеры подтверждения опыта по методичке. У них записано какая должна быть реакция на каждый вопрос и для положительного фидбэка она должна быть в точности такой как ожидается. Количество ложно отброшенных профессионалов их не волнует, волнует только чтобы не проскочил кто-то не имеющий абсолютно релевантного опыта и знаний.
Неожиданно, конечно. Обычно подобные уточняющие вопросы сами по себе - жирный плюс к вашей оценке. Тогда как сам вопрос намеренно с размытой формулировкой, чтобы тысячи уточнений можно было задать.
А.. я кажется понял что это у вас было. Это вероятно был первый раунд интервью, на котором отбрасывают тех кто вообще не знает как писать код.
Например, меня тоже однажды попросили написать контроллер с пейджингом, и их интересовало исключительно, знаю ли я синтаксис. Т.е. я должен был помнить команды linq для пропуска и выбора N, нужные для пейджинга. После того как я толком не вспомнил, на полном серьезе стали объяснять мне, что пейджинг это хитрая вещь, не каждый с ней справляется и нужно сначала пропустить а потом получить N. Но в целом они были убеждены, что если человек не помнит синтаксис для пейджинга, значит он не строчит контроллеры целыми днями и значит им такой человек не нужен, будь он хоть супер-программистом.
Т.е. это то о чем я выше писал - вместо того чтобы проверить уровень разработчика они ищут маркеры, отмечающие насколько часто он сталкивается с задачами которые ему собираются давать. У меня например спрашивали что означают ошибки 400 и 404. За недостаточно уверенным ответом последовало "если вы веб разрабочтик, как вы можете плохо помнить такие просты ошибки", на ответ, что это все обычно пишут мидлы, а я уже больше 5 лет как тимлид, спросили - "эта должность была чисто менеджерская без программирования?" и так далее. Как проходить подобные интервью пока не понял, задают десяток подобных вопросов и всегда находят что-то что не помнишь здесь и сейчас и что по их мнению кодер всегда помнит.
На их вопрос про ленту надо было тупо настрочить хоть что-то чтобы они поняли что вы делаете подобные вещи периодически.
Как проходить подобные интервью пока не понял, задают десяток подобных вопросов и всегда находят что-то что не помнишь здесь и сейчас и что по их мнению кодер всегда помнит.
Если в роли предполагается знания языков программирования (ну или определенного), то необходимо показать необходимый уровень, причем каждый следующий включает в себя предыдущий. Условно говоря, джуниор может завалиться на вопросе для мидла, а синьор (и, особенно, тимлид) - нет.
Другими словами, если Вы не пишете код (а потому собеседование будет пройти непросто), то лучше выбирать роли чистого управленца, где будут спрашивать про MBA, попросят показать, как Вы выбираете risk appetite и пр.
Я еще как пишу код, и на вопросы типа "в какой момент конкурентный dictionary будет залочен весь" отвечаю без проблем. Потому что этот вопрос на понимание а не маркеры релевантности опыта.
Проблема с маркерами в том, что у вас должен быть в точности тот опыт, который они ждут и прямо вчера, иначе вы никогда не вспомните как называется что-то про что они спрашивают. Причем беда в том, что таких вопросов на маркеры задают 10 и если хотя-бы в одном не совсем в цель - сразу отбрасывают. Если ты достаточно универсальный специалист, который писал на всем подряд, то поди вспомни "Какие есть команды, чтобы прочитать последнее значение из observable RxJS?". Но они похоже рассуждат "нам нужен фулскак с ангуларом, который целыми днями шлепает формы, значит он должен это по идее помнить, если не помнит, нам такой не нужен".
Какие есть команды, чтобы прочитать последнее значение из observable RxJS?
Подобные вопросы на эрудицию, конечно же, не очень помогают найти именно хорошего синьора, тут спору нет. Вот только я видел кучу раз то, как люди заваливались на очень простых задачах на написание кода (буквально "найдите индесы всех букв 'а' в строке, выбирайте любой язык), хотя резюме претендовало очень крутого специалиста.
А потому, вопросы на live coding очень хороши (если берут не чистого управленца), но вопросы на глубокое знание одной конкретной библиотеки - это очень странно (если только человек не написал, что является экспертом в ней, тогда стоит проверить, как кандидат определяет слово эксперт).
А.. я кажется понял что это у вас было. Это вероятно был первый раунд интервью, на котором отбрасывают тех кто вообще не знает как писать код.
Лол нет. То о чем вы говорите - это phone screen. А это было именно Systems Design интервью, последний раунд on-site (хотя дело было в самом начале пандемии, так что всё-равно по видео). Уже после recruiter phone screen, technical phone screen, и трех раундов coding interview. С материалами подготовки прямо как в этой статье, которые сам интервьюер видимо не читал.
В опыте за последние два месяца phone screen - это разговор с HR. После него традиционно следует короткое тех интервью на 45 минут на котором индус с ужасным акцентом, сломанным микрофоном и половиной головы на экране проверяет по списку ответы на вопросы. Что у них дальше пока ни разу дальше не смог пройти :). Поэтому скорее примут свои аутсортеры у которых все привычнее.
Не повезло.
У меня тоже есть подобный опыт.
Вообщ процессы найма в компаниях иногда оочень странные.
Большая удача конгда интервьюэры действительно хотят разобраться в том что ты можешь а что нет и что тебя мотивирует и если это налажено уже многое говорит о компании.
Linq Skip и Take это по-моему база. Неужели трудно повторить базу перед прохождением собеса? Ну и TL оценивают и как разработчика при прохождении интервью.
Так они же в вакансии не пишут, что требуется бэк-енд девелопер, который будет писать Rest API для UI. Они пишут что нужен Angular/React - .Net фул-стак со знанием Azure/AWS, MS SQL/MongoDB, практическм опытом CI/CD, Docker, не менее одного года работы с Kafka (серьезно, так и было написано), стронг в multi-threading и безопасности.
Учитывая что шансы на каждом отдельном подобном собесе на международном рынке сейчас 1:100, представьте объем синтаксиса который нужно держать в голове для того чтобы получить работу при том что невозможно найти идеально релевантную позицию, приходится пробовать на все близкие. Еще месяц хождений по собесам и он будет у меня в голове, но это сплошная мука, если честно.
Моя теория - эти люди упрощают себе задачу. Пользуясь тем что на рынке сейчас по 10 кандидатов на каждое место они не пытаются выяснить кто может работать а просто проверяют помнишь ли ты все что по их мнению понят участники их проекта.
Возможно я не во все пока въехал. Если у кого-то есть опыт как крякнуть эти скрины с индусами, пишите :).
Есть книга, которая так и называется, Cracking the coding interview. Сильно рекоммендую.
Антон Назаров предлагает метод паровозика. Это работает следующим образом: собираются N человек, они все по очереди откликаются на одну вакансию. Первый идёт на интервью и записывает его на видео, фэйлится на нём, но расшаривает материал с участниками паровозика. Второй заучивает те дибильные вопросы, которые попали на видео, и тоже идёт на интервью. Продвигается дальше и тоже фэйлится. Процесс повторяется до тех пор, пока очередной участник паровозика не будет обладать полным банком дибильных вопросов и задач для конкретной вакансии. Он-то и получит оффер. Затем паровозик идёт штурмовать следующую вакансию, и первым в атаку идёт тот, кто получил оффер на предыдущей итерации. Недостатком такого способа является то, что пока ваш сквад проводит штурм, вакансия вполне может закрыться. Также придётся где-то находить единомышленников, согласных поучаствовать в этом, при чём надёжных, а не тех, которые будут соскакивать сразу при получении оффера. И да, кандидатов сейчас не 10, а 100-300+ человек на место в среднем
Другой способ, более хайтэковский, подразумевает использование ИИ. Т.е. либо нанять чела, который будет за вас проходить интервью и изменять свою внешность и голос с помощью DeepFake (это особенно хорошо работает с такими компаниями, где вас собесят совсем не те люди, с которыми вам в будущем придётся работать), либо подготовить такой сетап с ChatGPT, чтобы очень быстро забивать туда вопрос интервьюэра и перепечатывать/проговаривать ответ. Недостаток очевиден: очень замороченно и поначалу вам потребуется практика, чтобы притворяться беспалевно. Ну и если такое дело станет распространённым, то наниматели начнут вводить прокторинги и прочий ГУЛАГ
>кандидатов сейчас не 10, а 100-300+ человек на место в среднем
в вашей реальности население планеты 50млрд? или клонирование прогеров изобрели? может и есть такие медом намазанные конторы, но это исключения
Давайте я уточню. На международном рынке по моим впечатлениям а каждоем мето проходит по 10 кандидатов, удовлетворяющих требованиям к квалификации. Подается понятное дело по 300 и на собес попадает несколько десятков.
Говорю, потому что несколько раз в качестве фибдэка получал жалобы, что дескать у нас 5 человек прошло на это место, они все одинаковые никак не можем решить, и дальше типа "может ваш код с прошлого проекта покажете?".
Сравните с наймом начальников над программистами:
- Я подниму вам $NNN за два года. Я уже такое сделал в пяти местах. И ещё я племянник зама CFO.
- Вы приняты.
К сожалению, тема архитектуры в ИТ отдана на откуп дизайнеров, которые художники, литераторы, но никак не инженеры.
Каков смысл статьи? Это просто перечисление. Вот такой вот список содержит истину. Всё, если не выучил - досвидания. Если вызубрил - станешь архитектором. Но где здесь инженерный подход?
Инженеры гарантируют что-то в своих конструкциях доказуемо, то расчётами и ссылками на данные об известных экспериментах. Как гарантируют что-то "архитекторы" (которые художники)? Вот так:
Конструируя системы с учетом высокой доступности, разработчики способны гарантировать длительную стабильность и доступность сервисов
То есть они гарантируют, что они способны. Очень надёжная гарантия!
Или вот ещё:
Для оценки надежности часто используются такие показатели, как среднее время между отказами
Ну ведь прекрасно! Дом стоит сто лет - он надёжен! А вот самолёт непрерывно летает всего несколько часов, а потом его надо обслуживать. Он ненадёжен (по мнению архитекторов), ведь среднее время между отказами в сложной системе на порядки меньше, чем в простой. Значит архитектор всегда выберет надёжное решение - дом, который не то что летать, двигаться не сможет. Да, это решение с высокой надёжностью (в сравнении с самолётом), но решает ли оно проблемы заказчика? По критерию, выбранному архитекторами - оно прекрасно решает все возможные проблемы.
Или вот так они голосуют за безопасность:
применение лучших практик для предотвращения неавторизованного доступа, утечек данных, вредоносных воздействий и прочих рисков
В списке для презентации заказчику указаны "лучшие практики"? Указаны, аж две или три штуки! Всё, мы в безопасности!
И так же во всём остальном:
Паттерны проектирования в области системных разработок представляют собой проверенные и широко применяемые решения
Слизал стандартное решение у соседа - молодец! Оно проверено и широко применяется. Ну и что, если другие давно в кроссовках ходят вместо лаптей, зато лапти проверены тысячами лет эксплуатации!
Вы скажете ,что в лаптях неудобно бегать? Не проблема. Архитектор вам ответит вот так:
Производительность в контексте системного проектирования обозначает способность программной системы быстро и эффективно обрабатывать данные
То есть в лаптях тоже можно быстро и эффективно что-то обрабатывать. А насколько быстро? Это уже вопрос не к архитектору, он за свою работу (в основном языком) деньги уже честно получил.
Как-то так и получается в итоге, что в стране 900 000 (почти миллион, да) программистов, а автоматизацией пока лишь пугают, поскольку до завершения этого прибыльного процесса ещё очень и очень далеко. Зато сколько на такую орду нужно архитекторов!
Очень здорово когда это изложено в одном месте. Конечно, многое все еще остается за бортом, но 80% вещей с собеседований оно таки покрывает.
System Design Interview - практика хорошая. Но опасная. Так как в руках неопытного интервьюера такое собеседование очень быстро превращается в игру "угадай мелодию", и, по сути, начинает работать как инструмент "отрицательного отбора". Если кандидат угадал "идеальную" архитектуру, которую интервьюер спроектировал в своей голове - он проходит. Предложил что-то "нестандартное" - т.е. выходящее за рамки компетенций и/или профессионального опыта интервьюера - не проходит.
Поэтому, чтобы практика System Design Interview начала приносить пользу, необходимо сначала очень тщательно отобрать самих интервьюеров. И, крайне желательно, чтобы собеседование проводил не один, а несколько независимых друг от друга интервьюеров. И, чтобы независимые интервьюеры во время подготовки отчета по результатам собеседования не общались между собой и не знали оценки своих коллег. Так можно существенно снизить уровень "субъективизма" при принятии решения, и избежать отрицательного отбора.
Ни о чем :)
По сути перечисление без понимания "КАК" :)
Ну прочитали вы, что надо быть умным и красивым. А вот как таким стать...
Спасибо за перевод. Совет - прочитайте на русском , потом на английском
Что нужно знать, чтобы успешно пройти System Design Interview