Мы, к сожалению, k8s в проекте не используем, точнее используем, но на несколько уровней ниже под нами (я думаю). Но из подкаста я вынес что это тул именно для локального развертывания всей среды и видимости ошибок.
«Логи приложений следует агрегировать в какой-либо системе и анализировать» — агрегация логов вещь всегда необходимая, но не совсем для анализа на операционные проблемы и ошибки сервиса в реальном времени. Для этого лучше использовать метрики, fault rate для данного примера вполне подошло бы. Если у кого-то появлялось желание анализировать логи, то у нас обычно спрашивали «Какой метрики тут не хватает?». Хотя, CloudWatch Logs позволяет создавать метрики из логов, тоже вариант. Но идея в том, что алерты реагируют именно на метрики, а не на логи.
«такой healthcheck должен осмотреть здоровье/доступность критичных для функционирования сервиса систем (доступы до очередей, БД, доступность сервисов И так далее)»
Слишком глубокий healthcheck может привести к расширению радиуса проблемы, если их дергает балансировщик. В случае проблемы с БД или внешним сервисом — все healthcheck-и могут отвалиться и балансировщик может вывести из строя чуть ли не весь флот. Поэтому смотря для чего используется healthcheck — ему стоит или не стоит проверять здоровье внешних зависимостей. Для мониторинга — стоит дергать deep healthcheck (не говоря конечно о том, что внешние зависимости должны иметь и свой мониторинг тоже). Для работы балансировщика — стоит дергать только local healthcheck, который проверяет что сервис локально здоров (память, диск, конфиги, credentials) и способен обрабатывать запросы.
Хорошая статья от AWS с более детальным анализом healthcheck-ов (как и вся коллекция).
Я не помню на какой платформе, может это тоже был хакеранк, но во время телефонного и очного интервью мы не просто набивали код и останавливались, а сразу запускали его с разными вводными данными. Это было дико удобно и прогрессивно, хотя и несколько волнительно кликать в Run :) Даже в Гугле на самописной платформе (а как же иначе, все только свое) ничего подобного и близко не было.
Ни подсказок, ни решений? Если так, то это сильно уступает литкоду, где мало того, что часто есть решения (и даже несколько) плюс форум на каждую задачу, так еще и бенчмарк на производительность. Где медленное «в лоб» решение просто выкинут через полсекунды с ошибкой «Time Exceeded».
Чтение книг и университетские курсы займут, к сожалению, слишком много времени. Хотя если не хватает базы, то да, без нее не обойтись. Тут поможет любой обычный базовый курс или книга по структурам данных и алгоритмам (Кормен я бы сказал будет слишком большим трудом для цели прохождения интервью). Честно, становиться спецом в алгоритмах и хорошо пройти интервью — это две разные вещи. Тут ведь важно помнить — интервью всегда ограничены по времени и задачи не могут быть очень сложными или запутанными, так как кандидаты должны в своей массе их решить и написать *весь код* минут за 30. Соответственно чисто на код порой остается минут 10-15 (а бывает и того меньше). Там просто не может быть никакого заумного алгоритма.
Поэтому я верю, что очень помогает видеть готовые решения. Не подсказки, а именно *готовые решения*, чтобы в голове в результате начала вырисовываться картина типичных подходов. А они таки довольно одинаковые в результате. Ссылка в пред ответе отлично их суммирует! Рекурсия, проходы по деревьям, хождение по доске, dynamic programming, бектрекинг, сдвигающееся окно в массиве, двойные поинтеры и так далее. Шаблоны решений неизменно выстраиваются в голове с количеством разобранных задач, которые рано или поздно повторяются.
Лучше всего, думаю, получается у чуваков увлеченных competitive programming. Не знатоков множества алгоритмов, а людей, которые уже нарешали сотни и тысячи задач. Это совсем не rocket science. Временной лимит жестко ограничивает размер решения, оно по определнию будет четким и коротким.
Еще есть вариант это платные курсы типа outco.io, interviewhelp.io, techseries.dev/interview но это слишком дорого и на мой взгляд того не стоит (у Outco просто конские цены, в варианте без предоплаты они просят 10% *годовой зарплаты*, если я правильно помню). Несколько месяцев Литкода или любой другой похожей платформы где есть готовые решения должно вполне хватить.
Сначала надо будет устроиться. В Штаты без работы и визы просто так не приехать (а приехать туристом и искать работу незаконно), в Германию можно приехать с визой для поиска работы: bit.ly/3dsSOHe
Когда мы вернемся к обычной жизни, можно искать выездные сессии крупных компаний. Фирмы часто летают в другие страны и там интервьюируют кандидатов.
Да, из книг (если есть время) как я понимаю хороша «Elements of Programming Interviews in Java: The Insiders' Guide», хотя сам я с ней еще на работал, оставил на след заход. Широко известная и рекомендуемая «Cracking the Coding Interview» мне не очень помогла. И другие люди тоже не очень советовали с ней связываться, слишком банальная.
Подсматривать ответы, конечно. На Литкоде либо есть ответ, либо форум, где решений полно. Я тоже часто бился часами в полном затыке, пока не лез в решения. Потом перестал мучаться и если задача не шла ни в какую (давал себе час или два) — смотрел решение или гуглил. Важно ж много решений насобирать, совсем не критично ко всем придти самостоятельно. Время дороже. А если на интервью попадется что то зубодробительное, ну значит не судьба. Для этого я шел на интервью с чуть ли не десятком компаний.
Полезно еще просматривать чужие решения, на случай если кто придумал что-то классное. Я обычно пролистывал форум на Литкоде и смотрел есть ли что кардинально другое.
Дома на скорость я не решал. Когда готовился осенью, то одну или две за вечер разбирал, чаще всего одну, так как залипал со скоростью чтобы попасть в топ решений. Литкод требует больше чем на интервью, на самом деле — 1) отработка всех крайних вариантов до полной корректности и 2) скорости. На интервью же этого нет, особенно если код пишется на доске. В Гугле мне давали Хромбук, но только как редактор, код не запускался (самое смешное что интервьюеры тоже доступа к коду не имели и вынуждены были его списывать с экрана).
Кстати, я всюду ходил со своим Хромбуком и если меня просили писать код на доске предлагал «А давайте вы сядете рядом и я на лэптопе, так будет удобнее». Некоторые охотно соглашались, и мне потом файлик в коллекцию вопросов.
Так они тоже не дураки, вопрос о визе и спонсорстве обычно задается на ранних этапах. Не узнать это сразу будет большим косяком рекрутера.
К нам в Амазон переходил сотрудник с H1B, не получилось. В теории H1B позволяет менять работодателей, а на практике это нудный бюрокатический процесс с негарантированным результатом.
Очень даже стоит напомнить о себе, конечно. Это вообще никогда лишним не бывает. Личный контакт с рекрутером на LinkedIn или в почте — уже большой плюс.
На он-сайт хард были не все, конечно. Но по моим ощущениям добрая половина в Эппле, Убере и Фейсбуке. Телефонные интервью обычно легче, согласен. В Гугле, кстати, задачки были менее типичные, т.е все пришлось решать с чистого листа, хотя готовился я несколько месяцев. В Убере, Эппле и Фейсбуке были уже более типичные. Самая халява в плане задач это, конечно, Амазон. Там обычно спрашивают совсем легкие задачи, если готовиться и сложность скорее с LP (leadership principles). Судят строго, сам принимал интервью.
Да, конечно, начинать с харда и не получится, я сам начинал с easy, потом перешел к medium и уже потом решал только харды. На самом деле, если войти во вкус, решать ниже харда уже не так и интересно, по крайней мере так было у меня. Да и харды тоже много кода никогда не требовали. Просто хитрее. В результате кода не больше 10-20 строк, больше ж на интервью все равно не успеть.
Добавлю чуток из своего опыта (после интервью в Amazon, HBO, Facebook, Apple, Google, Uber).
1) Совсем не обязательно фокусироваться на долине. Сиэтл отлично представлен крупными и не только игроками. Жить здесь дешевле, налоги ниже, климат другой и природы на мой взгляд больше. Кому как нравится. Сейчас так вообще все работают удаленно и ожидается что многие фирмы станут более гибкими в этом вопросе, чем раньше. Все понимают, что WFH (work from home) после эпидемии станет более привычным явлением, хотя и раньше с этим проблем обычно не было.
2) Если сидеть на Литкоде то лучше на уровне Hard и не тратить время на остальное. Задачи на backtracking (перебрать все варианты), dynamic programming и доска/сетка с ходами по ней (с препятствиями и без) наиболее часто встречающиеся, должны от зубов отскакивать, что называется. В моем случае успех или неудача определяли скорее встречал ты уже эту/похожую задачу или видишь ее впервые. Если встречал, то код писался легко и все складывалось отлично. А если впервые, то за 45 минут (а это обычное время одного слота) и решить задачу и написать весь код будет непросто — можно успеть решить, но не успеть написать код. Так что большой багаж решенных задач будет самым полезным.
3) Интервью на system design в моем случае оказались намного проще чем я ожидал. Обычного опыта вполне хватило (а я перелопатил тонну материала от AWS и многих других источников), сильно налегать и готовиться оказалось лишним, лучше было решить еще штук 100 хардов на Литкоде.
Мое интервью в Гугле было самым неприятным из всех. Сначала согласование даты растянулось чуть ли не на месяц, а в конце парень который этим занимался и отвечал на письма неделями ушел (или его ушли). Потом интервью отменили и перенесли меньше чем за сутки из-за непогоды (пошел снег, а в Сиэтле это может быть неприятно, safety!). В день интервью инженеры чудо-фирмы были банально неготовы, первый из них не мог найти комнату на этаже и мы бегали кругами минут 10, он же не знал, что время каждого слота сократили до 45 минут и к нам вдруг вовсю начал стучаться следующий. Другой инженер (не знаю какой) задал не тот вопрос и в результате пришлось решать еще одну задачку, а потом проводить из дома видео сессию по leadership principles (ой, мы забыли). Так что план интервью который мне предоставил рекрутер сильно расходился с действительностью.
В дальнейшем желания иметь с ними дело нет абсолютно никакого.
Мне казалось статья об уровнях «senior и выше», а не о «junior и выше». Я в принципе согласен с вашей системой градации от junior к senior разве кроме того что, опять же, по моим наблюдениям от senior как раз ожидают координацию и влияние на несколько команд — подозреваю что именно в этом месте опыт российских фирм (где влиять и координировать судя по всему может только лицо с админ ресурсом и полномочиями) отличается от европейских и штатовских (где влиять и координировать может кто сможет и у кого хватит умения с желанием).
Про качество кода я вроде ни разу не упоминал и как раз наоборот, подчеркнул что на одном коде и технических скилах далеко не уехать. По крайней мере в тех местах где работал я.
И я вижу тут уже не первый раз всплывает тема «под чью ответственность». Мне это напоминает поиск виноватых в случае не совсем верных решений. Отвечает не один человек, который предложил какой-то дизайн, а вся команда. Потому что проект это командное усилие, а не личная территория контроля одного человека. Кто-то предлагает решение, команда обсудила, одобрили/доработали и поехали. А попытка навешивать всю ответственность на одного человека опять же напоминает мне вертикаль власти. А также снимает всю ответственность со всех остальных игроков, что губительно. Да, за дизайном обычно стоит driver, который его толкает вперед вместе со всеми (и которому потом учтут все его инициативы на perf review), но это не то же самое что теперь это «его ответственность».
Я говорил о тенденции и большинстве случаев. Лично я не встречал вертикальных команд, ни там, ни там. В Израиле так особенно иерархичность в отношениях не приветствуется. Один раз в жизни я это встретил и это была российская фирма с офисом в Европе. Сразу понял что не мое от слова совсем.
«одобренных обычно руководством», «человек без административного ресурса», «выполняя менеджерскую роль» — друзья, возможно вам менее знакомо понятие командного лидерства (о котором я собственно и говорю с самого начала), но зато хорошо знакомы иерархические отношения и «админ ресурсы», где все делается или не делается по указанию и одобрению начальства. Или человека наделенного oсобым титулом или полномочиями (лычкой).
Здесь (США, Израиль) так обычно не работает. Начальник занимается карьерным ростом людей и направляет проект в нужную сторону. Команда «плоская» (есть разные позиции, но нет никаких иерархий, голоса всех равны, просто кто опытнее обычно приводит более убедительные аргументы) и сама делает все остальное и каждый проявляет ровно столько инициативы, сколько может и умеет. Раздавать пинки, разрешать/запрещать и трясти перед людьми «админ ресурсом» это уже очень российская реальность, с которой я плохо знаком. Хотя нет, вру, довелось однажды работать в российской конторе. То еще осталось впечатление от выстроенных там пирамид и иерархий.
«такой healthcheck должен осмотреть здоровье/доступность критичных для функционирования сервиса систем (доступы до очередей, БД, доступность сервисов И так далее)»
Слишком глубокий healthcheck может привести к расширению радиуса проблемы, если их дергает балансировщик. В случае проблемы с БД или внешним сервисом — все healthcheck-и могут отвалиться и балансировщик может вывести из строя чуть ли не весь флот. Поэтому смотря для чего используется healthcheck — ему стоит или не стоит проверять здоровье внешних зависимостей. Для мониторинга — стоит дергать deep healthcheck (не говоря конечно о том, что внешние зависимости должны иметь и свой мониторинг тоже). Для работы балансировщика — стоит дергать только local healthcheck, который проверяет что сервис локально здоров (память, диск, конфиги, credentials) и способен обрабатывать запросы.
Хорошая статья от AWS с более детальным анализом healthcheck-ов (как и вся коллекция).
Чтение книг и университетские курсы займут, к сожалению, слишком много времени. Хотя если не хватает базы, то да, без нее не обойтись. Тут поможет любой обычный базовый курс или книга по структурам данных и алгоритмам (Кормен я бы сказал будет слишком большим трудом для цели прохождения интервью). Честно, становиться спецом в алгоритмах и хорошо пройти интервью — это две разные вещи. Тут ведь важно помнить — интервью всегда ограничены по времени и задачи не могут быть очень сложными или запутанными, так как кандидаты должны в своей массе их решить и написать *весь код* минут за 30. Соответственно чисто на код порой остается минут 10-15 (а бывает и того меньше). Там просто не может быть никакого заумного алгоритма.
Поэтому я верю, что очень помогает видеть готовые решения. Не подсказки, а именно *готовые решения*, чтобы в голове в результате начала вырисовываться картина типичных подходов. А они таки довольно одинаковые в результате. Ссылка в пред ответе отлично их суммирует! Рекурсия, проходы по деревьям, хождение по доске, dynamic programming, бектрекинг, сдвигающееся окно в массиве, двойные поинтеры и так далее. Шаблоны решений неизменно выстраиваются в голове с количеством разобранных задач, которые рано или поздно повторяются.
Лучше всего, думаю, получается у чуваков увлеченных competitive programming. Не знатоков множества алгоритмов, а людей, которые уже нарешали сотни и тысячи задач. Это совсем не rocket science. Временной лимит жестко ограничивает размер решения, оно по определнию будет четким и коротким.
Еще есть вариант это платные курсы типа outco.io, interviewhelp.io, techseries.dev/interview но это слишком дорого и на мой взгляд того не стоит (у Outco просто конские цены, в варианте без предоплаты они просят 10% *годовой зарплаты*, если я правильно помню). Несколько месяцев Литкода или любой другой похожей платформы где есть готовые решения должно вполне хватить.
Пара ссылок:
Когда мы вернемся к обычной жизни, можно искать выездные сессии крупных компаний. Фирмы часто летают в другие страны и там интервьюируют кандидатов.
Полезно еще просматривать чужие решения, на случай если кто придумал что-то классное. Я обычно пролистывал форум на Литкоде и смотрел есть ли что кардинально другое.
Кстати, я всюду ходил со своим Хромбуком и если меня просили писать код на доске предлагал «А давайте вы сядете рядом и я на лэптопе, так будет удобнее». Некоторые охотно соглашались, и мне потом файлик в коллекцию вопросов.
К нам в Амазон переходил сотрудник с H1B, не получилось. В теории H1B позволяет менять работодателей, а на практике это нудный бюрокатический процесс с негарантированным результатом.
Да, конечно, начинать с харда и не получится, я сам начинал с easy, потом перешел к medium и уже потом решал только харды. На самом деле, если войти во вкус, решать ниже харда уже не так и интересно, по крайней мере так было у меня. Да и харды тоже много кода никогда не требовали. Просто хитрее. В результате кода не больше 10-20 строк, больше ж на интервью все равно не успеть.
1) Совсем не обязательно фокусироваться на долине. Сиэтл отлично представлен крупными и не только игроками. Жить здесь дешевле, налоги ниже, климат другой и природы на мой взгляд больше. Кому как нравится. Сейчас так вообще все работают удаленно и ожидается что многие фирмы станут более гибкими в этом вопросе, чем раньше. Все понимают, что WFH (work from home) после эпидемии станет более привычным явлением, хотя и раньше с этим проблем обычно не было.
2) Если сидеть на Литкоде то лучше на уровне Hard и не тратить время на остальное. Задачи на backtracking (перебрать все варианты), dynamic programming и доска/сетка с ходами по ней (с препятствиями и без) наиболее часто встречающиеся, должны от зубов отскакивать, что называется. В моем случае успех или неудача определяли скорее встречал ты уже эту/похожую задачу или видишь ее впервые. Если встречал, то код писался легко и все складывалось отлично. А если впервые, то за 45 минут (а это обычное время одного слота) и решить задачу и написать весь код будет непросто — можно успеть решить, но не успеть написать код. Так что большой багаж решенных задач будет самым полезным.
3) Интервью на system design в моем случае оказались намного проще чем я ожидал. Обычного опыта вполне хватило (а я перелопатил тонну материала от AWS и многих других источников), сильно налегать и готовиться оказалось лишним, лучше было решить еще штук 100 хардов на Литкоде.
В дальнейшем желания иметь с ними дело нет абсолютно никакого.
Про качество кода я вроде ни разу не упоминал и как раз наоборот, подчеркнул что на одном коде и технических скилах далеко не уехать. По крайней мере в тех местах где работал я.
И я вижу тут уже не первый раз всплывает тема «под чью ответственность». Мне это напоминает поиск виноватых в случае не совсем верных решений. Отвечает не один человек, который предложил какой-то дизайн, а вся команда. Потому что проект это командное усилие, а не личная территория контроля одного человека. Кто-то предлагает решение, команда обсудила, одобрили/доработали и поехали. А попытка навешивать всю ответственность на одного человека опять же напоминает мне вертикаль власти. А также снимает всю ответственность со всех остальных игроков, что губительно. Да, за дизайном обычно стоит driver, который его толкает вперед вместе со всеми (и которому потом учтут все его инициативы на perf review), но это не то же самое что теперь это «его ответственность».
Здесь (США, Израиль) так обычно не работает. Начальник занимается карьерным ростом людей и направляет проект в нужную сторону. Команда «плоская» (есть разные позиции, но нет никаких иерархий, голоса всех равны, просто кто опытнее обычно приводит более убедительные аргументы) и сама делает все остальное и каждый проявляет ровно столько инициативы, сколько может и умеет. Раздавать пинки, разрешать/запрещать и трясти перед людьми «админ ресурсом» это уже очень российская реальность, с которой я плохо знаком. Хотя нет, вру, довелось однажды работать в российской конторе. То еще осталось впечатление от выстроенных там пирамид и иерархий.