Понедельник начинается с LeetCode
На той недели разбирали собеседование выпускника. У него основная проблема, то что он сильно волнуется. И из-за этого не может собраться.
Ему дали задачу уровня easy и он ее решал все собеседование, целый час.
Поэтому я настоятельно рекомендую погонять задачи уровня easy.
Сегодня сам спотыкнулся на задачу по бинарному поиску. Решал ее тоже целый час ))
https://leetcode.com/problems/search-insert-position/
Аналогичную задачу видел на собеседовании в Авито.
На той недели разбирали собеседование выпускника. У него основная проблема, то что он сильно волнуется. И из-за этого не может собраться.
Ему дали задачу уровня easy и он ее решал все собеседование, целый час.
Поэтому я настоятельно рекомендую погонять задачи уровня easy.
Сегодня сам спотыкнулся на задачу по бинарному поиску. Решал ее тоже целый час ))
https://leetcode.com/problems/search-insert-position/
Аналогичную задачу видел на собеседовании в Авито.
🔥12👍7😁3
Собеседование Go Core
Добавил уроки по курсу Go.
Типы данных [#505461]
Нюансы работы с defer [#505462]
Структуры данных [#505470]
Map [#505481]
Interface [#505482]
Pointer [#505483]
Большая просьба тех кто участвует в этом эксперименте, сжать булки и добежать до конца. Уже прошел месяц, а еще никто даже 1/4 не решил. Я понимаю, что когда это бесплатно, то мотивации проходить нет. В целом я придерживаюсь такой идеи. Как только первый участник эксперимента получить оффер, то эксперимент сворачиваем и доступ на курс я отключу.
Описание курса 👉 https://job4j.ru/courses/38
Добавил уроки по курсу Go.
Типы данных [#505461]
Нюансы работы с defer [#505462]
Структуры данных [#505470]
Map [#505481]
Interface [#505482]
Pointer [#505483]
Большая просьба тех кто участвует в этом эксперименте, сжать булки и добежать до конца. Уже прошел месяц, а еще никто даже 1/4 не решил. Я понимаю, что когда это бесплатно, то мотивации проходить нет. В целом я придерживаюсь такой идеи. Как только первый участник эксперимента получить оффер, то эксперимент сворачиваем и доступ на курс я отключу.
Описание курса 👉 https://job4j.ru/courses/38
👍9🔥4
4.9.4. Собеседование Go Goroutines
Я добрался до самой жирной темы в Go.
Добавил уроки:
Ядра, процессоры, процессы и горутины [#505487]
Планировщик Go [#505490]
Go Channel [#505488]
Go Select [#505489]
sync.Map | RWMutex | atomic [#505491]
Эта теория. Еще будет 10 урок с практическими задачами реализации шаблоновон: Worker Pool, Fan-in, Fan-out и тд.
Описание курса 👉 https://job4j.ru/courses/38
Я добрался до самой жирной темы в Go.
Добавил уроки:
Ядра, процессоры, процессы и горутины [#505487]
Планировщик Go [#505490]
Go Channel [#505488]
Go Select [#505489]
sync.Map | RWMutex | atomic [#505491]
Эта теория. Еще будет 10 урок с практическими задачами реализации шаблоновон: Worker Pool, Fan-in, Fan-out и тд.
Описание курса 👉 https://job4j.ru/courses/38
🔥17
Задачи на горутины
Все тоже самое, что и в Java, только в другом API.
Но кода в разы меньше получается, по сравнению если такое же писать на Java.
Задача: WorkerPool [#505492]
Задача: FanIn [#505493]
Context [#505494]
Задача: Поиск с отменой [#505495]
Шардированный кеш [#505496]
Задача*: Продвинутый Worker Pool [#505497]
Главный маркетинговый ход в Go и тут сработал "Многопоточный код, как последовательная программа" )) Местами тут похлеще wait, notify, notifyAll.
Описание курса 👉 https://job4j.ru/courses/38
Все тоже самое, что и в Java, только в другом API.
Но кода в разы меньше получается, по сравнению если такое же писать на Java.
Задача: WorkerPool [#505492]
Задача: FanIn [#505493]
Context [#505494]
Задача: Поиск с отменой [#505495]
Шардированный кеш [#505496]
Задача*: Продвинутый Worker Pool [#505497]
Главный маркетинговый ход в Go и тут сработал "Многопоточный код, как последовательная программа" )) Местами тут похлеще wait, notify, notifyAll.
Описание курса 👉 https://job4j.ru/courses/38
👍4🔥2🤮2
Проверим идейку
Я думаю, что все Go-программисты знают Даниила Подольского.
В его творчестве есть легендарная статья на Хабре, где он с сожалением отмечает тенденции в IT.
"Наша индустрия, как бы мы это ни оценивали, уже давно живет по закону «*fail early, fail often, but always fail forward*». Для нас это означает, что мы должны делать свою работу как можно… хуже! Мы должны потратить как можно меньше сил, средств и времени — особенно времени! — на предложенную задачу, ибо никто не знает, имеет ли текущая задача практический смысл. Собственно, большую часть задач мы решаем в режиме разведки, проверяя чужие смелые бизнес-гипотезы.
В результате лучшие кадры приучаются делать только то, что им поручено, ничего, кроме того, что им поручено, и необходимый минимум того, что им поручено. И этот подход, я предполагаю, незаметно и неосознанно эти кадры распространяют и на свое обучение. Разработчик изучает только то, что ему нужно по текущей задаче: ничего, кроме этого, и ограничивается минимально возможным набором знаний.
Моё скромное мнение — так нельзя! Образование — это игра в долгую, и подходить к нему надо с другими критериями, нежели к очередному «Проверим идейку *MVP*»."
Такой же подход используется и при вкате в IT. В начале создания своего курса по Java я ставил задачу качественной подготовки учеников за счет большого количества практических заданий. И раньше это работало, потому что объем требуемых на собеседовании знаний был соизмерим с выполняемой работой. Сейчас же объем вопросов запредельный. Это в первую очередь связано с доступностью этих знаний.
Например, раньше, если тебе нужно было найти информацию о том, какие блокировки использует PostgreSQL, тебе нужно было лезть в документацию PostgreSQL и долго по крупицам собирать информацию. Сейчас же ты за секунды получаешь разжеванный ответ от LLM.
Поэтому в курсе по Go я использую подход "быстро добежать до конца". Цель — максимально быстро подготовить ученика к собеседованию. Приведу пример другой менторской программы. В этой программе проходят темы: Go Core, Go Goroutines, SQL, NoSQL, кэши, Redis, Kafka, оптимизация баз данных, мониторинг, Docker, Kubernetes, Prometheus, Grafana, CI/CD, GitLab, системный дизайн. Хотите знать, на сколько рассчитана программа? На 33 дня.
То есть задача не освоить программирование, а выучить правильные ответы на собеседовании.
Сам я тоже себя подгоняю, добивая уроки по курсу Go.
Собеседование SQL [#505498]
Задача: Индексы в PostgreSQL [#505499]
Описание курса 👉 https://job4j.ru/courses/38
Я думаю, что все Go-программисты знают Даниила Подольского.
В его творчестве есть легендарная статья на Хабре, где он с сожалением отмечает тенденции в IT.
"Наша индустрия, как бы мы это ни оценивали, уже давно живет по закону «*fail early, fail often, but always fail forward*». Для нас это означает, что мы должны делать свою работу как можно… хуже! Мы должны потратить как можно меньше сил, средств и времени — особенно времени! — на предложенную задачу, ибо никто не знает, имеет ли текущая задача практический смысл. Собственно, большую часть задач мы решаем в режиме разведки, проверяя чужие смелые бизнес-гипотезы.
В результате лучшие кадры приучаются делать только то, что им поручено, ничего, кроме того, что им поручено, и необходимый минимум того, что им поручено. И этот подход, я предполагаю, незаметно и неосознанно эти кадры распространяют и на свое обучение. Разработчик изучает только то, что ему нужно по текущей задаче: ничего, кроме этого, и ограничивается минимально возможным набором знаний.
Моё скромное мнение — так нельзя! Образование — это игра в долгую, и подходить к нему надо с другими критериями, нежели к очередному «Проверим идейку *MVP*»."
Такой же подход используется и при вкате в IT. В начале создания своего курса по Java я ставил задачу качественной подготовки учеников за счет большого количества практических заданий. И раньше это работало, потому что объем требуемых на собеседовании знаний был соизмерим с выполняемой работой. Сейчас же объем вопросов запредельный. Это в первую очередь связано с доступностью этих знаний.
Например, раньше, если тебе нужно было найти информацию о том, какие блокировки использует PostgreSQL, тебе нужно было лезть в документацию PostgreSQL и долго по крупицам собирать информацию. Сейчас же ты за секунды получаешь разжеванный ответ от LLM.
Поэтому в курсе по Go я использую подход "быстро добежать до конца". Цель — максимально быстро подготовить ученика к собеседованию. Приведу пример другой менторской программы. В этой программе проходят темы: Go Core, Go Goroutines, SQL, NoSQL, кэши, Redis, Kafka, оптимизация баз данных, мониторинг, Docker, Kubernetes, Prometheus, Grafana, CI/CD, GitLab, системный дизайн. Хотите знать, на сколько рассчитана программа? На 33 дня.
То есть задача не освоить программирование, а выучить правильные ответы на собеседовании.
Сам я тоже себя подгоняю, добивая уроки по курсу Go.
Собеседование SQL [#505498]
Задача: Индексы в PostgreSQL [#505499]
Описание курса 👉 https://job4j.ru/courses/38
🔥17❤3🤔2
Голодные игры 2025 в IT
Как я уже писал выше, поиск работы превратился в фарс. Все хотят идти в ногу со временем и использовать LLM. Компании стремятся сократить расходы и внедряют LLM там, где это нецелесообразно — например, при поиске кандидатов. Те же кандидаты с помощью LLM составляют резюме.
Когда я провожу собеседования, всегда прошу прислать ссылку на GitHub. Обычно кандидаты отвечают: «У меня его нет, или там только учебные проекты».
На самом деле не важно, насколько заполнен репозиторий, важно, что там есть какая-то активность.
Я проверил несколько репозиториев: брал ссылку и просил GPT оценить уровень кандидата — и оно очень точно определяло уровень, хотя проекты там были далеко не полными.
Но это лирика: никто так не делает… хотя кто-то может задуматься.
В целом поиск сместился на личностные контакты и прямое общение с HR, а не через HH:
1. Писать напрямую на сайтах работодателей.
2. Активно вести LinkedIn и другие соцсети.
3. Спрашивать у бывших коллег.
Как я уже писал выше, поиск работы превратился в фарс. Все хотят идти в ногу со временем и использовать LLM. Компании стремятся сократить расходы и внедряют LLM там, где это нецелесообразно — например, при поиске кандидатов. Те же кандидаты с помощью LLM составляют резюме.
Когда я провожу собеседования, всегда прошу прислать ссылку на GitHub. Обычно кандидаты отвечают: «У меня его нет, или там только учебные проекты».
На самом деле не важно, насколько заполнен репозиторий, важно, что там есть какая-то активность.
Я проверил несколько репозиториев: брал ссылку и просил GPT оценить уровень кандидата — и оно очень точно определяло уровень, хотя проекты там были далеко не полными.
Но это лирика: никто так не делает… хотя кто-то может задуматься.
В целом поиск сместился на личностные контакты и прямое общение с HR, а не через HH:
1. Писать напрямую на сайтах работодателей.
2. Активно вести LinkedIn и другие соцсети.
3. Спрашивать у бывших коллег.
🤔2👍1
Kafka | Топ вопросов
Сегодня добавил урок про Kafka в курс по Go.
Kafka [#505501]
Предлагаю провести мок-собеседование по Кафка.
1. Объясни базовые концепции Kafka: брокеры, топики, партиции, продюсеры, консьюмеры.
2. Как гарантировать доставку сообщений "ровно один раз" или хотя бы "по меньшей мере один раз" и "не больше одного раза"?
3. Зачем нужна репликация в Kafka и как это влияет на доступность и консистентность?
4. Что будет с данными Kafka при перезагрузки системы и почему?
5. Можно ли использовать шину данных Kafka для общение между микросервисами и чем это будет отличаться от общения по http соединениям?
Пишите в личку @parsentev
Для тех кто не знаком с Kafka, у нас есть отдельный курс по Kafka
👉 https://job4j.ru/courses/21
С практикой, теорией и мок-собесами.
Сегодня добавил урок про Kafka в курс по Go.
Kafka [#505501]
Предлагаю провести мок-собеседование по Кафка.
1. Объясни базовые концепции Kafka: брокеры, топики, партиции, продюсеры, консьюмеры.
2. Как гарантировать доставку сообщений "ровно один раз" или хотя бы "по меньшей мере один раз" и "не больше одного раза"?
3. Зачем нужна репликация в Kafka и как это влияет на доступность и консистентность?
4. Что будет с данными Kafka при перезагрузки системы и почему?
5. Можно ли использовать шину данных Kafka для общение между микросервисами и чем это будет отличаться от общения по http соединениям?
Пишите в личку @parsentev
Для тех кто не знаком с Kafka, у нас есть отдельный курс по Kafka
👉 https://job4j.ru/courses/21
С практикой, теорией и мок-собесами.
👍7❤1
Правые и левые взгляды в IT
Обычно на первичном скрининге задают вопрос: «Какими задачами вам хотелось бы заниматься?» Что обычно отвечают? «Мне нужны сложные задачи, с моим стеком, на современном языке, с высокой нагрузкой». Однако у компании могут быть другие задачи, такие как удовлетворение потребностей клиента или просто решение его болей.
В книге *Hooked: How to Build Habit-Forming Products* Нира Эяля приводится важное различие между "таблетками" и "витаминами".
Цитата:
> "If you want your product to be habit-forming, it needs to be more like a vitamin than a painkiller. Painkillers solve a specific problem—something urgent and compelling. Vitamins, on the other hand, are nice to have, but they are not urgent. People need painkillers, but they want vitamins."
В этой метафоре таблетки (painkillers) решают неотложную проблему, то есть продукт, который становится необходимым для пользователя, когда у него возникает проблема. Витамины (vitamins) же — это не что-то, что требуется прямо сейчас, но продукт приносит дополнительные выгоды и улучшения, делая жизнь лучше.
Давайте переведем это в контекст программирования. В данном случае программирование — это ремесло, которое приносит деньги. Здесь существуют два подхода.
Старая школа или правые
Эти ребята возводят программирование в своего рода искусство. На вопрос, что нужно, чтобы стать программистом, они отвечают следующим списком:
* теория фон Неймана
* архитектура ОС
* сети
* микропроцессорная архитектура
* теория баз данных
* теория мультипроцессорного вычисления
Список бесконечный.
В целом, то, что они проповедуют, имеет место быть в ВУЗе. Это классическая программа обучения по направлению вычислительной техники. Если вы школьник и вас интересует программирование, то безусловно, это правильный путь. А что делать, если вы уже не школьник, и учились не на программиста, а просто на инженера? Нужно снова идти в ВУЗ?
В чем проблема такого подхода? Ответим с позиции вопроса о таблетках и витаминах. В этом случае мы выступаем в роли витаминов: мы не решаем проблемы бизнеса, мы подготавливаемся к решению гипотетической задачи, которую никто нам не ставил.
Левые или «лутать золото»
Другие ребята подходят к профессии программиста с крайне приземленным подходом. Это работа, и цель работы — обменять свой труд на деньги.
Что же советуют ребята с этой стороны? Залетать в IT с двух ног, врать, рисовать опыт, обманывать, подсиживать, саботировать. Любые способы хороши, если они приносят деньги. Лишь бы это не было уголовно наказуемо. Это такие Остапы Бендеры современности. Звучит безнравственно? Вам скажут, что бизнес с вами делает то же самое, поэтому все честно. Они обманывают, и вы тоже. Все справедливо.
Здесь важно понимать, что левые не делят людей на «свой» и «чужой». То есть, если вас можно обмануть, а вы доверчивый инженер, который захотел залететь в IT с двух ног, чтобы «лутать бабло», вас без проблем обманут. Поэтому курсы IT за два месяца с обещаниями зарплаты 300+ тр до сих пор раскручиваются со всех сторон. А вы скажете: «Да, там все честно. Схема вин-вин». Предоплата 30-40 тр, а потом ты отдаешь 150% от зарплаты после трудоустройства. Это не твои деньги, а ментора, который тебе помог. Все честно, ты потом еще заработаешь.
Вернемся к таблеткам и витаминам. В этом случае это 100% таблетки, только не настоящие, а пустышки или плацебо. На эффекте плацебо существует огромный рынок инфоцыган. К сожалению, это проблема информационной эпохи. Людям проще поверить убедительным доводам, чем критически относиться к информации.
Центристы
Что же делать? Нужно взять лучшее из двух сторон. Изучайте те темы, которые требует бизнес. Сейчас главный стек в бэке — это микросервисы. Значит, нужно копать в эту сторону: Kafka, Redis, Kubernetes, Docker, Prometheus, Grafana. Если у вас нет работы, то стоит фокусироваться только на этих технологиях, а не тратить время на изучение архитектуры ПО или внутренностей процессора.
Обычно на первичном скрининге задают вопрос: «Какими задачами вам хотелось бы заниматься?» Что обычно отвечают? «Мне нужны сложные задачи, с моим стеком, на современном языке, с высокой нагрузкой». Однако у компании могут быть другие задачи, такие как удовлетворение потребностей клиента или просто решение его болей.
В книге *Hooked: How to Build Habit-Forming Products* Нира Эяля приводится важное различие между "таблетками" и "витаминами".
Цитата:
> "If you want your product to be habit-forming, it needs to be more like a vitamin than a painkiller. Painkillers solve a specific problem—something urgent and compelling. Vitamins, on the other hand, are nice to have, but they are not urgent. People need painkillers, but they want vitamins."
В этой метафоре таблетки (painkillers) решают неотложную проблему, то есть продукт, который становится необходимым для пользователя, когда у него возникает проблема. Витамины (vitamins) же — это не что-то, что требуется прямо сейчас, но продукт приносит дополнительные выгоды и улучшения, делая жизнь лучше.
Давайте переведем это в контекст программирования. В данном случае программирование — это ремесло, которое приносит деньги. Здесь существуют два подхода.
Старая школа или правые
Эти ребята возводят программирование в своего рода искусство. На вопрос, что нужно, чтобы стать программистом, они отвечают следующим списком:
* теория фон Неймана
* архитектура ОС
* сети
* микропроцессорная архитектура
* теория баз данных
* теория мультипроцессорного вычисления
Список бесконечный.
В целом, то, что они проповедуют, имеет место быть в ВУЗе. Это классическая программа обучения по направлению вычислительной техники. Если вы школьник и вас интересует программирование, то безусловно, это правильный путь. А что делать, если вы уже не школьник, и учились не на программиста, а просто на инженера? Нужно снова идти в ВУЗ?
В чем проблема такого подхода? Ответим с позиции вопроса о таблетках и витаминах. В этом случае мы выступаем в роли витаминов: мы не решаем проблемы бизнеса, мы подготавливаемся к решению гипотетической задачи, которую никто нам не ставил.
Левые или «лутать золото»
Другие ребята подходят к профессии программиста с крайне приземленным подходом. Это работа, и цель работы — обменять свой труд на деньги.
Что же советуют ребята с этой стороны? Залетать в IT с двух ног, врать, рисовать опыт, обманывать, подсиживать, саботировать. Любые способы хороши, если они приносят деньги. Лишь бы это не было уголовно наказуемо. Это такие Остапы Бендеры современности. Звучит безнравственно? Вам скажут, что бизнес с вами делает то же самое, поэтому все честно. Они обманывают, и вы тоже. Все справедливо.
Здесь важно понимать, что левые не делят людей на «свой» и «чужой». То есть, если вас можно обмануть, а вы доверчивый инженер, который захотел залететь в IT с двух ног, чтобы «лутать бабло», вас без проблем обманут. Поэтому курсы IT за два месяца с обещаниями зарплаты 300+ тр до сих пор раскручиваются со всех сторон. А вы скажете: «Да, там все честно. Схема вин-вин». Предоплата 30-40 тр, а потом ты отдаешь 150% от зарплаты после трудоустройства. Это не твои деньги, а ментора, который тебе помог. Все честно, ты потом еще заработаешь.
Вернемся к таблеткам и витаминам. В этом случае это 100% таблетки, только не настоящие, а пустышки или плацебо. На эффекте плацебо существует огромный рынок инфоцыган. К сожалению, это проблема информационной эпохи. Людям проще поверить убедительным доводам, чем критически относиться к информации.
Центристы
Что же делать? Нужно взять лучшее из двух сторон. Изучайте те темы, которые требует бизнес. Сейчас главный стек в бэке — это микросервисы. Значит, нужно копать в эту сторону: Kafka, Redis, Kubernetes, Docker, Prometheus, Grafana. Если у вас нет работы, то стоит фокусироваться только на этих технологиях, а не тратить время на изучение архитектуры ПО или внутренностей процессора.
👍16❤4🔥1
С другой стороны, процесс обучения не должен затягиваться на 5 лет. Максимум — год, и выходить на работу. Я знаю, что рынок в этом году требует других специалистов, но других нет, если те, что сейчас на рынке.
Не ведитесь, если вам говорят, что пройдя мои курсы, вы поднимете зарплату в 2 или 3 раза. А сколько времени обучение? «А, 33 дня, но у вас система вин-вин». Вначале деньги, а потом стулья. Всегда пересчитывайте на человеко-часы. Если обучение стоит 40 тр + 150% оклада, а оклад у вас будет 200 тр, значит, этот ментор должен с вами провести около 120 часов, если его час стоит 2000 рублей. Дробите задачи.
Главное, что стоит взять у левых, — это практику хождения по собеседованиям. На собеседованиях вы можете понять, что требует рынок, какие проекты существуют, что они решают. Вы же нормально относитесь к тому, что зашли в магазин, но ничего не купили. Тут точно так же. Вы пришли посмотреть, чем торгуют, но покупать или устраиваться вас никто не заставляет. Возьмите себе за практику периодически обновлять собеседования и ходить на них. Общайтесь на собеседовании как с коллегами, а не как с врагами с другой стороны.
С курсом по Go я хотел проверить схему левых. Но цифры рынка показывают, что я уже опоздал. Во-первых, даже с накрученным опытом на всех позициях Go мне отказали. Хотя я указал опыт 5 лет. Во-вторых, зарплаты для Go просели. Мало вакансий, но много новичков. Где зп 500-600 тр на Senior? Я вижу 200-250 тр. Причем стали попадаться вакансии с зарплатой около 100 тр. Благо за Java такого я не видел.
Итог
Безусловно, развивать себя в программировании — это ваша основная обязанность, но она должна быть неотрывна от производства. То есть нужно решать реальные проблемы бизнеса, а не сферические задачи. Выходить на рынок и смотреть, что предлагают.
Я сам нарушил этот принцип: хоть я и провожу собеседования, но сам на них не ходил уже лет 10. Такого быть не должно.
Наше обучение https://job4j.ru/ по классической схеме: упор на практику с балансом в теории.
Не ведитесь, если вам говорят, что пройдя мои курсы, вы поднимете зарплату в 2 или 3 раза. А сколько времени обучение? «А, 33 дня, но у вас система вин-вин». Вначале деньги, а потом стулья. Всегда пересчитывайте на человеко-часы. Если обучение стоит 40 тр + 150% оклада, а оклад у вас будет 200 тр, значит, этот ментор должен с вами провести около 120 часов, если его час стоит 2000 рублей. Дробите задачи.
Главное, что стоит взять у левых, — это практику хождения по собеседованиям. На собеседованиях вы можете понять, что требует рынок, какие проекты существуют, что они решают. Вы же нормально относитесь к тому, что зашли в магазин, но ничего не купили. Тут точно так же. Вы пришли посмотреть, чем торгуют, но покупать или устраиваться вас никто не заставляет. Возьмите себе за практику периодически обновлять собеседования и ходить на них. Общайтесь на собеседовании как с коллегами, а не как с врагами с другой стороны.
С курсом по Go я хотел проверить схему левых. Но цифры рынка показывают, что я уже опоздал. Во-первых, даже с накрученным опытом на всех позициях Go мне отказали. Хотя я указал опыт 5 лет. Во-вторых, зарплаты для Go просели. Мало вакансий, но много новичков. Где зп 500-600 тр на Senior? Я вижу 200-250 тр. Причем стали попадаться вакансии с зарплатой около 100 тр. Благо за Java такого я не видел.
Итог
Безусловно, развивать себя в программировании — это ваша основная обязанность, но она должна быть неотрывна от производства. То есть нужно решать реальные проблемы бизнеса, а не сферические задачи. Выходить на рынок и смотреть, что предлагают.
Я сам нарушил этот принцип: хоть я и провожу собеседования, но сам на них не ходил уже лет 10. Такого быть не должно.
Наше обучение https://job4j.ru/ по классической схеме: упор на практику с балансом в теории.
👍19🔥6
Yoga by Job4j
Пока рынок IT на фризе предлагаю переключиться на йогу.
Сам практикую с 2020 года. Даже есть сертификат тренера по йоге за 2023 год.
Предлагаю сегодня в 19 00 провести тренировку.
Что нужно.
1 час свободного времени, коврик.
Тренировка без шизотерики, мантр, мудр и других этнический элементов. Только физуха.
Вход бесплатный. Пишите в личку @parsentev. Добавлю в чат, где будет эфир. Желательно включить камеру, чтобы я мог править ваш позы ).
ПС. Записи не будет, только живой эфир.
Пока рынок IT на фризе предлагаю переключиться на йогу.
Сам практикую с 2020 года. Даже есть сертификат тренера по йоге за 2023 год.
Предлагаю сегодня в 19 00 провести тренировку.
Что нужно.
1 час свободного времени, коврик.
Тренировка без шизотерики, мантр, мудр и других этнический элементов. Только физуха.
Вход бесплатный. Пишите в личку @parsentev. Добавлю в чат, где будет эфир. Желательно включить камеру, чтобы я мог править ваш позы ).
ПС. Записи не будет, только живой эфир.
🔥8❤5👏3😁1
Сливы собесов | Польза и вред
Начну с нравственно-этических аспектов этой темы. Смотреть «слитые» собеседования — всё равно что получить ответы на тест. Не справедливо, правда? Для кого это несправедливо — для других кандидатов или для работодателя?
Как я уже писал, объём доступной информации сейчас огромен. Могут возразить: «В вакансии указан стек, по нему и будут вопросы». Но даже такое упрощение нисколько не уменьшает объём. Приведу пример: в вакансии может быть указано использование PostgreSQL — а это целый мир. Книга по SQL часто занимает 3000 страниц, и если копнуть глубже, понимаешь, насколько сложные механизмы скрыты внутри СУБД.
Работодатели тоже это понимают, поэтому собеседование обычно строится по схеме:
1. Алгоритмическая задача уровня easy из LeetCode. Любой, кто считает себя программистом, должен уметь решать такие задачи. Потренируйтесь на нашей платформе: [https://job4j.ru/topics](https://job4j.ru/topics)
2. SQL-запрос с
3. Теория. Даже если вы ежедневно работаете с технологиями, вы забываете детали. Прочитать 3000 страниц текста за выходные и выдать хорошие ответы в понедельник невозможно. Единственный способ узнать, что именно спрашивают в конкретной компании, — послушать реальное собеседование.
Как работать со «сливами» собеседований
> Замечание. «Слив» — это запись реального собеседования, а не мок-интервью. На моке вы расслабленно беседуете, а на настоящем интервью вам нужно доказать, что вы справитесь с задачами, и помочь интервьюерам это увидеть.
1. Слушайте полностью. От рассказа о компании до вопросов о процессах. Если у вас совсем нет опыта, вы быстро заметите, как работодатели приукрашивают описание.
2. Решайте задачи самостоятельно. Ставьте запись на паузу, пытайтесь решить — потом отправляете своё решение LLM и просите проверить. Затем слушаете, как это делал кандидат. Важно понимать, что чужое решение может быть неверным, так что не полагайтесь на него целиком.
Если у вас есть записи конкретной компании, прорешайте все её задания. Например, когда я поступал в вуз, готовился по методичкам: я полностью прорешал математические задачи и только просматривал физические. На экзамене мне попалась задача, которую я лишь просматривал — я вспомнил решение лишь фрагментарно.
3. Теория. Выпишите вопрос, поставьте запись на паузу и ответьте сами вслух (не про себя!), затем сравните с ответом кандидата и уточняющими вопросами. На настоящем интервью у вас может «встать ком в горле» — проговорите ответы вслух в спокойной обстановке, чтобы привыкнуть.
Общие правила на интервью
1. Не отвечайте грубостью на грубость. Высокомерие на высокомерие — путь к конфликту.
2. Не перебивайте. Слушайте вопрос до конца, делайте паузы, задавайте уточняющие вопросы, контролируйте темп речи.
3. Объясняйте своё решение. Лучше проговорить ход мысли и получить корректировку, чем молчать и написать неверный код.
Общие правила подготовки
1. Ежедневно решайте easy-задачи LeetCode. Не пропускайте их: на словах задача может казаться простой, но при кодировании всегда появляются ошибки.
2. Мок-собеседования ≠ реальные. Если есть выбор, смотрите реальные записи собеседований и тренируйтесь по ним.
Начну с нравственно-этических аспектов этой темы. Смотреть «слитые» собеседования — всё равно что получить ответы на тест. Не справедливо, правда? Для кого это несправедливо — для других кандидатов или для работодателя?
Как я уже писал, объём доступной информации сейчас огромен. Могут возразить: «В вакансии указан стек, по нему и будут вопросы». Но даже такое упрощение нисколько не уменьшает объём. Приведу пример: в вакансии может быть указано использование PostgreSQL — а это целый мир. Книга по SQL часто занимает 3000 страниц, и если копнуть глубже, понимаешь, насколько сложные механизмы скрыты внутри СУБД.
Работодатели тоже это понимают, поэтому собеседование обычно строится по схеме:
1. Алгоритмическая задача уровня easy из LeetCode. Любой, кто считает себя программистом, должен уметь решать такие задачи. Потренируйтесь на нашей платформе: [https://job4j.ru/topics](https://job4j.ru/topics)
2. SQL-запрос с
SELECT, JOIN, GROUP BY, HAVING — стандартный кейс в режиме реального времени. Стас отлично поработал над этим разделом на нашей платформе: [https://job4j.ru/sqlExercise](https://job4j.ru/sqlExercise)3. Теория. Даже если вы ежедневно работаете с технологиями, вы забываете детали. Прочитать 3000 страниц текста за выходные и выдать хорошие ответы в понедельник невозможно. Единственный способ узнать, что именно спрашивают в конкретной компании, — послушать реальное собеседование.
Как работать со «сливами» собеседований
> Замечание. «Слив» — это запись реального собеседования, а не мок-интервью. На моке вы расслабленно беседуете, а на настоящем интервью вам нужно доказать, что вы справитесь с задачами, и помочь интервьюерам это увидеть.
1. Слушайте полностью. От рассказа о компании до вопросов о процессах. Если у вас совсем нет опыта, вы быстро заметите, как работодатели приукрашивают описание.
2. Решайте задачи самостоятельно. Ставьте запись на паузу, пытайтесь решить — потом отправляете своё решение LLM и просите проверить. Затем слушаете, как это делал кандидат. Важно понимать, что чужое решение может быть неверным, так что не полагайтесь на него целиком.
Если у вас есть записи конкретной компании, прорешайте все её задания. Например, когда я поступал в вуз, готовился по методичкам: я полностью прорешал математические задачи и только просматривал физические. На экзамене мне попалась задача, которую я лишь просматривал — я вспомнил решение лишь фрагментарно.
3. Теория. Выпишите вопрос, поставьте запись на паузу и ответьте сами вслух (не про себя!), затем сравните с ответом кандидата и уточняющими вопросами. На настоящем интервью у вас может «встать ком в горле» — проговорите ответы вслух в спокойной обстановке, чтобы привыкнуть.
Общие правила на интервью
1. Не отвечайте грубостью на грубость. Высокомерие на высокомерие — путь к конфликту.
2. Не перебивайте. Слушайте вопрос до конца, делайте паузы, задавайте уточняющие вопросы, контролируйте темп речи.
3. Объясняйте своё решение. Лучше проговорить ход мысли и получить корректировку, чем молчать и написать неверный код.
Общие правила подготовки
1. Ежедневно решайте easy-задачи LeetCode. Не пропускайте их: на словах задача может казаться простой, но при кодировании всегда появляются ошибки.
2. Мок-собеседования ≠ реальные. Если есть выбор, смотрите реальные записи собеседований и тренируйтесь по ним.
❤18🔥6⚡2
Завтра в 19:00 | Тренировка в стиле йога
Продолжаем тренировку. Завтра в 19:00 жду всех желающий приобщиться к йоге без шизотерики. Только физика, будет жарко.
Пишите @parsentev. Я добавлю в чат.
Комментарии с предыдущей тренировки:
1. Было жарко, Смог сделать половину.
2. Я до этого занимался не йогой )).
3. Отвалилась на пауке.
Продолжаем тренировку. Завтра в 19:00 жду всех желающий приобщиться к йоге без шизотерики. Только физика, будет жарко.
Пишите @parsentev. Я добавлю в чат.
Комментарии с предыдущей тренировки:
1. Было жарко, Смог сделать половину.
2. Я до этого занимался не йогой )).
3. Отвалилась на пауке.
🔥2
Типы метрик в Prometheus
В пятницу проходил собеседование в Райф. Вначале обсуждали процессы Ci\CD.
На своем проекте я Prometheus используют только для анализа ERROR. Считаю количество ошибок за день и отправляю Alert если их больше 10.
Но типов метрик в Prometheus больше.
1. Counter (Счётчик)
- Описание: Монотонно возрастающий счётчик, который может только увеличиваться или сбрасываться в ноль при перезапуске
- Использование: Для подсчёта событий, количества запросов, ошибок и т.д.
- Примеры:
-
-
- Особенности:
- В PromQL обычно используется с функциями
2. Gauge (Измеритель)
- Описание: Значение, которое может увеличиваться и уменьшаться
- Использование: Для измерения текущего состояния (использование памяти, температура, количество одновременных соединений)
- Примеры:
-
-
-
- Особенности:
- Часто используются в графиках "как есть"
- Полезны функции
3. Histogram (Гистограмма)
- Описание: Выборка наблюдений, обычно временных характеристик или размеров ответов
- Использование: Для анализа распределения значений, особенно latency
- Примеры:
-
-
- Особенности:
- Создаёт несколько временных рядов с суффиксами
- Позволяет вычислять перцентили с
- Требует предопределённых buckets (границ корзин)
4. Summary (Сводка)
- Описание: Аналогично гистограмме, но вычисляет квантили на стороне клиента
- Использование: Когда нужно отслеживать заранее определённые квантили
- Примеры:
-
- Особенности:
- Создаёт метрики с суффиксами
- Менее гибкий, чем гистограмма, но более эффективный для предопределённых квантилей
- Квантили нельзя агрегировать
5. Untyped (Нетипизированный)
- Описание: Устаревший тип, для совместимости
- Использование: В legacy-системах
- Особенности:
- Prometheus пытается определить тип автоматически
Добавил в наш курс по DevOps урок про типы метрик в Prometheus.
👉 https://job4j.ru/courses/35
В пятницу проходил собеседование в Райф. Вначале обсуждали процессы Ci\CD.
На своем проекте я Prometheus используют только для анализа ERROR. Считаю количество ошибок за день и отправляю Alert если их больше 10.
Но типов метрик в Prometheus больше.
1. Counter (Счётчик)
- Описание: Монотонно возрастающий счётчик, который может только увеличиваться или сбрасываться в ноль при перезапуске
- Использование: Для подсчёта событий, количества запросов, ошибок и т.д.
- Примеры:
-
http_requests_total-
errors_total- Особенности:
- В PromQL обычно используется с функциями
rate(), irate() или increase()2. Gauge (Измеритель)
- Описание: Значение, которое может увеличиваться и уменьшаться
- Использование: Для измерения текущего состояния (использование памяти, температура, количество одновременных соединений)
- Примеры:
-
memory_usage_bytes-
temperature_celsius-
current_connections- Особенности:
- Часто используются в графиках "как есть"
- Полезны функции
delta(), deriv()3. Histogram (Гистограмма)
- Описание: Выборка наблюдений, обычно временных характеристик или размеров ответов
- Использование: Для анализа распределения значений, особенно latency
- Примеры:
-
http_request_duration_seconds_bucket-
response_size_bytes_bucket- Особенности:
- Создаёт несколько временных рядов с суффиксами
_bucket, _sum, _count- Позволяет вычислять перцентили с
histogram_quantile()- Требует предопределённых buckets (границ корзин)
4. Summary (Сводка)
- Описание: Аналогично гистограмме, но вычисляет квантили на стороне клиента
- Использование: Когда нужно отслеживать заранее определённые квантили
- Примеры:
-
http_request_duration_seconds_summary- Особенности:
- Создаёт метрики с суффиксами
_sum, _count и квантили _quantile- Менее гибкий, чем гистограмма, но более эффективный для предопределённых квантилей
- Квантили нельзя агрегировать
5. Untyped (Нетипизированный)
- Описание: Устаревший тип, для совместимости
- Использование: В legacy-системах
- Особенности:
- Prometheus пытается определить тип автоматически
Добавил в наш курс по DevOps урок про типы метрик в Prometheus.
👉 https://job4j.ru/courses/35
👍10❤6🔥4
Уже традиция. Субботняя йога
В 19 00. Нужен коврик и желание по потеть.
Пишите в личку @parsentev. Я добавлю в чат.
В 19 00. Нужен коврик и желание по потеть.
Пишите в личку @parsentev. Я добавлю в чат.
🔥3
Системный дизайн
В озоне у меня было два этапа с системным дизайном.
Это мой первый опыт прохождения этого блока, ранее никогда не было.
Для тех, кто тоже никогда не проходил такой блок, я советую начать с этого видео.
https://www.youtube.com/watch?v=RAMWRgt-3G0
В озоне у меня было два этапа с системным дизайном.
Это мой первый опыт прохождения этого блока, ранее никогда не было.
Для тех, кто тоже никогда не проходил такой блок, я советую начать с этого видео.
https://www.youtube.com/watch?v=RAMWRgt-3G0
YouTube
Дмитрий Волыхин — System Design-интервью для практиков
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
Скачать презентацию с сайта JPoint — https://jrg.su/SuLdn6
Как задизайнить YouTube или Dropbox за 45 минут? Представьте, что у вас System…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
Скачать презентацию с сайта JPoint — https://jrg.su/SuLdn6
Как задизайнить YouTube или Dropbox за 45 минут? Представьте, что у вас System…
🔥12👍1
Kafka | Outbox
На секциях системного дизайна в озоне использовали сервис -
https://excalidraw.com/. Мне он приглянулся. Я стал использовать его для своего курса по Kafka.
Сегодня добавил два урока:
Иденпотентность и гарантии доставки [#505524]
Outbox [#505525]
В райфе мне дали задачу, у тебя есть сервис (replica > 1), настроен outbox. Вопрос, как избежать дублирование отправки сообщений из payload таблицы?
Ответы пишите в комментарии. Свой ответ я напишу в следующем посте.
Описание курса по Kafka
👉 https://job4j.ru/courses/21
На секциях системного дизайна в озоне использовали сервис -
https://excalidraw.com/. Мне он приглянулся. Я стал использовать его для своего курса по Kafka.
Сегодня добавил два урока:
Иденпотентность и гарантии доставки [#505524]
Outbox [#505525]
В райфе мне дали задачу, у тебя есть сервис (replica > 1), настроен outbox. Вопрос, как избежать дублирование отправки сообщений из payload таблицы?
Ответы пишите в комментарии. Свой ответ я напишу в следующем посте.
Описание курса по Kafka
👉 https://job4j.ru/courses/21
👍6❤2
Субботняя йога в 19:00
Напоминаю, что мы теперь не только программируем, но и тренируемся.
Всех желающих жду завтра в 19:00 на тренировку.
Пишите в личку @parsentev.
Вход бесплатный.
Напоминаю, что мы теперь не только программируем, но и тренируемся.
Всех желающих жду завтра в 19:00 на тренировку.
Пишите в личку @parsentev.
Вход бесплатный.
❤6
Кто диктует правила фронт vs бек
В пятницу у меня было финальное собеседование в Озон.
Этот этап называется "знакомство с командой", но по факту он даже серьезнее технического интервью, потому что здесь нет правильных ответов.
Конечно, был вопрос о процессах разработки и взаимодействии с другими командами.
В своём курсе по DevOps я описывал элемент инженерной культуры — спецификации.
Один из примеров касался RPC, например, REST API или gRPC, описанных через Swagger.
Что это даёт? Самое главное — теперь команда backend и frontend может вести разработку параллельно.
В частности, один из тимлидов обратил на это особое внимание, потому что в их проектах команды чётко разделены на backend и frontend. То есть при разработке нового бизнес-процесса он сначала попадает в backend, и только потом — в интеграцию с frontend.
Почему так происходит? Обычно разработка идёт "от базы данных к клиенту" — это восходящее проектирование. Это связано с тем, что наибольшая вычислительная нагрузка ложится на реляционную базу данных, поэтому сначала проектируют схемы БД.
Однако в таком случае frontend-команда простаивает, так как им нужен сервер, чтобы писать свой код.
Есть и другой подход — нисходящее проектирование. Оно как раз начинается с описания API-спецификации, а затем — её реализации. В этом случае можно применять TDD, но есть высокая вероятность, что внешнее API будет меняться, что приведёт к лавинообразным изменениям в слоях приложения.
Зато такой подход позволяет заранее согласовать API между backend и frontend и начать параллельную разработку.
Тимлид отметил, что у многих разработчиков как раз и возникает проблема с координацией и обсуждением внешнего API.
А как у вас принято в проектах? Напиши в комментариях.
Наш курс по DevOps — https://job4j.ru/courses/35
В пятницу у меня было финальное собеседование в Озон.
Этот этап называется "знакомство с командой", но по факту он даже серьезнее технического интервью, потому что здесь нет правильных ответов.
Конечно, был вопрос о процессах разработки и взаимодействии с другими командами.
В своём курсе по DevOps я описывал элемент инженерной культуры — спецификации.
Один из примеров касался RPC, например, REST API или gRPC, описанных через Swagger.
Что это даёт? Самое главное — теперь команда backend и frontend может вести разработку параллельно.
В частности, один из тимлидов обратил на это особое внимание, потому что в их проектах команды чётко разделены на backend и frontend. То есть при разработке нового бизнес-процесса он сначала попадает в backend, и только потом — в интеграцию с frontend.
Почему так происходит? Обычно разработка идёт "от базы данных к клиенту" — это восходящее проектирование. Это связано с тем, что наибольшая вычислительная нагрузка ложится на реляционную базу данных, поэтому сначала проектируют схемы БД.
Однако в таком случае frontend-команда простаивает, так как им нужен сервер, чтобы писать свой код.
Есть и другой подход — нисходящее проектирование. Оно как раз начинается с описания API-спецификации, а затем — её реализации. В этом случае можно применять TDD, но есть высокая вероятность, что внешнее API будет меняться, что приведёт к лавинообразным изменениям в слоях приложения.
Зато такой подход позволяет заранее согласовать API между backend и frontend и начать параллельную разработку.
Тимлид отметил, что у многих разработчиков как раз и возникает проблема с координацией и обсуждением внешнего API.
А как у вас принято в проектах? Напиши в комментариях.
Наш курс по DevOps — https://job4j.ru/courses/35
👍9❤6
"Волки" или Остапы Бендеры из IT
«12 стульев» Ильфа и Петрова — одно из моих любимых сатирических произведений.
Остап Бендер, главный герой романа, — своего рода прародитель «волчества»: он демонстрирует, как умение играть по чужим правилам и искать лазейки позволяет быстрее достигать целей.
Вчера в чате скинули ссылку на статью про «волков». Так как не все еще знают этот жаргонизм, я решил тоже написать пару строк.
Вначале обрисую проблему. У нас есть «кабанчик» (жаргон 90-х — означает предпринимателя или просто бизнес), которому нужны рабочие руки, но эти руки стоят дорого, поэтому нанимать абы кого нельзя. Поэтому нужен процесс отбора кандидатов.
Сами программисты этим заниматься не любят, поэтому часть обязанностей выполняет кадровик. Здесь и возникает проблема.
HR не может объективно оценить программиста, потому что не имеет опыта в программировании. А для программистов заниматься наймом — неперспективная работа: слушать, как кандидат мямлит одни и те же ответы, — это скучно.
Кабанчик, чтобы решить эту проблему, просит программистов составить скрипты опроса, по которым прогоняют кандидатов и оценивают уже, как бы объективно.
Тут и появляются «волки». Волки — это социальные хакеры. Для них работа в IT — это игра. Играть можно по правилам кабанчика, а можно «взламывать» систему. Здесь появляется не только материальная подоплека, но и игровой азарт.
В этой игре есть четкая балльная система: чем больше ты зарабатываешь, тем ты круче.
Какие трюки используются при найме:
1. Подгонка резюме под фильтры — вставляют ключевые слова из описания вакансии, чтобы пройти автоскрининг.
2. Отработка шаблонных ответов — учат типовые вопросы/ответы и отрепетируют подачу.
3. Прозрачные уточняющие вопросы рекрутеру — выясняют этапы, критерии и таймлайны, чтобы управлять процессом.
4. Ведение нескольких процессов одновременно — чтобы не зависеть от одного оффера и иметь возможность торговаться.
5. Приукрашивание опыта — формулировки, которые не врут прямо, но создают более сильное впечатление.
6. Использование сливов/чужих скриптов интервью — ответы или задачи из прошлых собеседований адаптируют под новые.
7. Подсказки во время удалённого интервью — скрытое вмешательство извне.
8. Фальсификация рекомендаций или проектов — подделка подтверждений опыта.
А зарабатывать можно на всём и как угодно.
Перечислю основные направления:
1. Первая работа. Чем быстрее — тем лучше. 2–3 месяца максимум.
2. Мультиработа. Оптимизируй время. Удалённая работа позволяет работать на нескольких проектах сразу.
3. Проходи собеседования и продавай скрипты, вопросы/ответы, задания.
4. Проходи собеседования и продавай сливы этих собеседований.
5. Продавай услуги менторинга: собеседования, легенда, повышение зарплаты.
6. Продавай советы по трудоустройству.
Вы думаете, что в конце я начну осуждать деятельность этих ребят? Нисколько.
Большинство из приведённых выше трюков я и сам пробовал, а с 2010 по 2015 год даже работал сразу на нескольких проектах. Единственное — я не разделяю идею везде кричать, что так нужно делать.
Сегодня суббота. Кроме IT на https://job4j.ru/ мы ещё и тренируемся. Все, кто желает один час попотеть на коврике, — пишите в личку @parsentev.
«12 стульев» Ильфа и Петрова — одно из моих любимых сатирических произведений.
Остап Бендер, главный герой романа, — своего рода прародитель «волчества»: он демонстрирует, как умение играть по чужим правилам и искать лазейки позволяет быстрее достигать целей.
Вчера в чате скинули ссылку на статью про «волков». Так как не все еще знают этот жаргонизм, я решил тоже написать пару строк.
Вначале обрисую проблему. У нас есть «кабанчик» (жаргон 90-х — означает предпринимателя или просто бизнес), которому нужны рабочие руки, но эти руки стоят дорого, поэтому нанимать абы кого нельзя. Поэтому нужен процесс отбора кандидатов.
Сами программисты этим заниматься не любят, поэтому часть обязанностей выполняет кадровик. Здесь и возникает проблема.
HR не может объективно оценить программиста, потому что не имеет опыта в программировании. А для программистов заниматься наймом — неперспективная работа: слушать, как кандидат мямлит одни и те же ответы, — это скучно.
Кабанчик, чтобы решить эту проблему, просит программистов составить скрипты опроса, по которым прогоняют кандидатов и оценивают уже, как бы объективно.
Тут и появляются «волки». Волки — это социальные хакеры. Для них работа в IT — это игра. Играть можно по правилам кабанчика, а можно «взламывать» систему. Здесь появляется не только материальная подоплека, но и игровой азарт.
В этой игре есть четкая балльная система: чем больше ты зарабатываешь, тем ты круче.
Какие трюки используются при найме:
1. Подгонка резюме под фильтры — вставляют ключевые слова из описания вакансии, чтобы пройти автоскрининг.
2. Отработка шаблонных ответов — учат типовые вопросы/ответы и отрепетируют подачу.
3. Прозрачные уточняющие вопросы рекрутеру — выясняют этапы, критерии и таймлайны, чтобы управлять процессом.
4. Ведение нескольких процессов одновременно — чтобы не зависеть от одного оффера и иметь возможность торговаться.
5. Приукрашивание опыта — формулировки, которые не врут прямо, но создают более сильное впечатление.
6. Использование сливов/чужих скриптов интервью — ответы или задачи из прошлых собеседований адаптируют под новые.
7. Подсказки во время удалённого интервью — скрытое вмешательство извне.
8. Фальсификация рекомендаций или проектов — подделка подтверждений опыта.
А зарабатывать можно на всём и как угодно.
Перечислю основные направления:
1. Первая работа. Чем быстрее — тем лучше. 2–3 месяца максимум.
2. Мультиработа. Оптимизируй время. Удалённая работа позволяет работать на нескольких проектах сразу.
3. Проходи собеседования и продавай скрипты, вопросы/ответы, задания.
4. Проходи собеседования и продавай сливы этих собеседований.
5. Продавай услуги менторинга: собеседования, легенда, повышение зарплаты.
6. Продавай советы по трудоустройству.
Вы думаете, что в конце я начну осуждать деятельность этих ребят? Нисколько.
Большинство из приведённых выше трюков я и сам пробовал, а с 2010 по 2015 год даже работал сразу на нескольких проектах. Единственное — я не разделяю идею везде кричать, что так нужно делать.
Сегодня суббота. Кроме IT на https://job4j.ru/ мы ещё и тренируемся. Все, кто желает один час попотеть на коврике, — пишите в личку @parsentev.
👍17🔥6❤4🤔2🤝1
Кафка. Вопросы с собеседований: Райф, Альфа, Озон, X5, Сбер
В июле 2025 года проходил собеседования. Ниже собрал расширенный список вопросов о kafka.
1. Какие есть семантики доставки в Kafka: _at-most-once_, _at-least-once_, _exactly-once_? Что на них влияет (например,
2. При использовании _At-Least-Once_ — какие стратегии можно применить на стороне потребителя, чтобы избежать дубликатов в обработке? (например, идемпотентная обработка, детектирование по уникальному ключу, хранение уже обработанных, transactional read-process-write и т.п.)
3. В чём отличие между _At-Most-Once_ и _At-Least-Once_ по потерям/дубликатам?
4. Как работает схема _Exactly-Once Semantics_ (EOS) в Kafka? Какие компоненты участвуют и в каких ситуациях она всё ещё может не давать 100% гарантию?
5. Какие типы
6. Что означает
7. Что такое идемпотентный продюсер и почему просто
8. Как потребитель подтверждает, что он "прочитал" сообщения? В чём разница между авто-коммитом и ручным коммитом offset’ов?
9. В чём разница между
10. Что такое _consumer lag_ и как его мониторить? Почему это важно?
11. Что происходит, если оффсет не найден (например, из-за удаления старых данных)? Как работает
12. Что происходит, когда потребитель отключается от группы или добавляется новый? Как работает ребалансировка, какие стадии есть (revocation, assignment), и как её накладные расходы можно минимизировать (например, cooperative rebalancing)?
13. Что случится, если потребитель не вызывает
14. У тебя 3 брокера и топик с 3 партициями: как эти партиции распределяются по брокерам? Как выбирается лидер и реплики?
15. Что происходит при отказе лидера партиции? Как происходит failover и что такое ISR (in-sync replicas)?
16. Что случается при добавлении или удалении брокера — как перераспределяются партиции и кто инициирует ребалансировку партиций?
17. Как правильно подбирать
18. Как обеспечить атомарную обработку сообщения и запись результата в стороннюю систему (например, сравнение outbox pattern vs транзакционный read-process-write с Kafka)?
19. Как устроен механизм выбора лидера партиции и какие условия могут привести к длительной недоступности?
20. Какие метрики нужно смотреть, чтобы понимать, что потребители или продюсеры работают корректно и не теряют данные?
21. Как устроено гарантированное завершение транзакции при использовании транзакционного продюсера и как это согласуется с потребителями?
22. Как добиться минимального времени простоя при ребалансировке потребительской группы?
23. В каких ситуациях может возникнуть "split-brain" с точки зрения реплик и как Kafka с этим справляется?
Эти и другие вопросы мы разбираем на курсе по Kafka
👉 https://job4j.ru/courses/21
В июле 2025 года проходил собеседования. Ниже собрал расширенный список вопросов о kafka.
1. Какие есть семантики доставки в Kafka: _at-most-once_, _at-least-once_, _exactly-once_? Что на них влияет (например,
acks, retries, идемпотентность, транзакции)?2. При использовании _At-Least-Once_ — какие стратегии можно применить на стороне потребителя, чтобы избежать дубликатов в обработке? (например, идемпотентная обработка, детектирование по уникальному ключу, хранение уже обработанных, transactional read-process-write и т.п.)
3. В чём отличие между _At-Most-Once_ и _At-Least-Once_ по потерям/дубликатам?
4. Как работает схема _Exactly-Once Semantics_ (EOS) в Kafka? Какие компоненты участвуют и в каких ситуациях она всё ещё может не давать 100% гарантию?
5. Какие типы
acks есть у продюсера и как они влияют на задержку и надёжность доставки?6. Что означает
min.insync.replicas и как его настройка вместе с acks=all влияет на устойчивость и доступность?7. Что такое идемпотентный продюсер и почему просто
enable.idempotence=true недостаточно для полной защиты от повторной доставки в более сложных схемах?8. Как потребитель подтверждает, что он "прочитал" сообщения? В чём разница между авто-коммитом и ручным коммитом offset’ов?
9. В чём разница между
commitSync и commitAsync и когда какой использовать?10. Что такое _consumer lag_ и как его мониторить? Почему это важно?
11. Что происходит, если оффсет не найден (например, из-за удаления старых данных)? Как работает
auto.offset.reset?12. Что происходит, когда потребитель отключается от группы или добавляется новый? Как работает ребалансировка, какие стадии есть (revocation, assignment), и как её накладные расходы можно минимизировать (например, cooperative rebalancing)?
13. Что случится, если потребитель не вызывает
poll долгое время и превышает max.poll.interval.ms или теряет heartbeat (session.timeout.ms)? Как это отражается на группе?14. У тебя 3 брокера и топик с 3 партициями: как эти партиции распределяются по брокерам? Как выбирается лидер и реплики?
15. Что происходит при отказе лидера партиции? Как происходит failover и что такое ISR (in-sync replicas)?
16. Что случается при добавлении или удалении брокера — как перераспределяются партиции и кто инициирует ребалансировку партиций?
17. Как правильно подбирать
max.poll.records, max.poll.interval.ms, heartbeat.interval.ms и почему слишком длинный poll может вызывать проблемы?18. Как обеспечить атомарную обработку сообщения и запись результата в стороннюю систему (например, сравнение outbox pattern vs транзакционный read-process-write с Kafka)?
19. Как устроен механизм выбора лидера партиции и какие условия могут привести к длительной недоступности?
20. Какие метрики нужно смотреть, чтобы понимать, что потребители или продюсеры работают корректно и не теряют данные?
21. Как устроено гарантированное завершение транзакции при использовании транзакционного продюсера и как это согласуется с потребителями?
22. Как добиться минимального времени простоя при ребалансировке потребительской группы?
23. В каких ситуациях может возникнуть "split-brain" с точки зрения реплик и как Kafka с этим справляется?
Эти и другие вопросы мы разбираем на курсе по Kafka
👉 https://job4j.ru/courses/21
❤14🔥12👍3