Села обновлять своё резюме для международного рынка и выяснила, что первый в гугл-выдаче сайт для создания резюме Resume.io — это скам. Как пишут на Reddit, он предлагает за 2 доллара один(!) раз скачать резюме в pdf, а после еще списывает 20$ якобы за подписку. В общем, будьте осторожны.
В целом выяснилось, что генерировать резюме онлайн - не лучшая идея, так как такие документы не проходят ATS. Эти системы плохо считывают информацию из сложных и красивых файлов. Автоматические скрининги лучше всего проходят простые классические резюме.
Такие шаблоны можно найти, например, вот тут:
- Microsoft CV templates
- Google Docs Templates
- https://resumeworded.com/resume-templates
Еще в ЕС есть стандарт резюме, который называется Europass. Его можно бесплатно создать на официальном сайте https://europass.europa.eu/en.
Только начала разбираться в этой теме и много еще не понятно. Например, как толково описать 9 лет опыта в 4х компаниях в одностраничном формате. Или как не умереть, редактируя свое резюме под каждую компанию и ее ATS. Если у кого-то есть хорошие советы/ссылки/инструменты по этой теме - делитесь в комментариях🤗.
В целом выяснилось, что генерировать резюме онлайн - не лучшая идея, так как такие документы не проходят ATS. Эти системы плохо считывают информацию из сложных и красивых файлов. Автоматические скрининги лучше всего проходят простые классические резюме.
Такие шаблоны можно найти, например, вот тут:
- Microsoft CV templates
- Google Docs Templates
- https://resumeworded.com/resume-templates
Еще в ЕС есть стандарт резюме, который называется Europass. Его можно бесплатно создать на официальном сайте https://europass.europa.eu/en.
Только начала разбираться в этой теме и много еще не понятно. Например, как толково описать 9 лет опыта в 4х компаниях в одностраничном формате. Или как не умереть, редактируя свое резюме под каждую компанию и ее ATS. Если у кого-то есть хорошие советы/ссылки/инструменты по этой теме - делитесь в комментариях🤗.
👍25🔥9❤2
Мне сложно дается грамотное ведение LinkedIn, поэтому решила поучаствовать в прожарке профилей в прямом эфире AgileFluent. Мой и еще 10 профилей разберет эксперт по международному найму🫣.
Страшно, конечно, но обещают много полезного. Расскажут, как вести эту хитрую соцсеть так, чтобы рекрутеры всех стран хотели нас схантить.
Приходите посмотреть на мой позор 17 декабря в 19:00 Мск в канале ребят. Все подробности и канал тут.
UPD: Запись эфира https://youtu.be/ci_YU9hpCmI
Страшно, конечно, но обещают много полезного. Расскажут, как вести эту хитрую соцсеть так, чтобы рекрутеры всех стран хотели нас схантить.
Приходите посмотреть на мой позор 17 декабря в 19:00 Мск в канале ребят. Все подробности и канал тут.
UPD: Запись эфира https://youtu.be/ci_YU9hpCmI
YouTube
Прожарка LinkedIn с Агелиной Волковой
#agilefluent #работазарубежом #карьеразаграницей
🔥31🗿5🤣3👏2👌2💊1
О КАНАЛЕ И АВТОРЕ
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю рекламу, но иногда могу анонсировать мероприятия коллег.
Я пишу о том, что мне кажется интересным. И последние несколько лет меня увлекают вопросы интеграций систем. Но не исключено, что в какой-то момент тут станет больше контента про бизнес-анализ, менеджмент или программирование🙈.
Иногда у меня бывают сложные периоды, и постов становится меньше, иногда получается поддерживать регулярность. Но бросать я точно не собираюсь. Мне очень нравится писать, формулировать и консолидировать знания. И, конечно, общаться с вами.
Очень благодарна вам за то, что читаете этот канал, оставляете реакции и комментарии - это очень важно для меня❤️.
Предлагаю в комментариях нам познакомиться: напишите о себе, почему вы читаете этот блог, о каких темах вам было бы интересно узнать в следующих постах? Или что-то, что хочется тут написать. Буду рада знакомству и общению🤗.
LinkedIn
Хабр
Medium (eng)
Донаты: ЮMoney | PayPal
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю рекламу, но иногда могу анонсировать мероприятия коллег.
Я пишу о том, что мне кажется интересным. И последние несколько лет меня увлекают вопросы интеграций систем. Но не исключено, что в какой-то момент тут станет больше контента про бизнес-анализ, менеджмент или программирование🙈.
Иногда у меня бывают сложные периоды, и постов становится меньше, иногда получается поддерживать регулярность. Но бросать я точно не собираюсь. Мне очень нравится писать, формулировать и консолидировать знания. И, конечно, общаться с вами.
Очень благодарна вам за то, что читаете этот канал, оставляете реакции и комментарии - это очень важно для меня❤️.
Предлагаю в комментариях нам познакомиться: напишите о себе, почему вы читаете этот блог, о каких темах вам было бы интересно узнать в следующих постах? Или что-то, что хочется тут написать. Буду рада знакомству и общению🤗.
Хабр
Medium (eng)
Донаты: ЮMoney | PayPal
❤91👍19🔥10
Системный сервант
Мне сложно дается грамотное ведение LinkedIn, поэтому решила поучаствовать в прожарке профилей в прямом эфире AgileFluent. Мой и еще 10 профилей разберет эксперт по международному найму🫣. Страшно, конечно, но обещают много полезного. Расскажут, как вести…
Тем временем, прожарка моего LinkedIn уже завтра😳
Telegram
Системный сервант
Мне сложно дается грамотное ведение LinkedIn, поэтому решила поучаствовать в прожарке профилей в прямом эфире AgileFluent. Мой и еще 10 профилей разберет эксперт по международному найму🫣.
Страшно, конечно, но обещают много полезного. Расскажут, как вести…
Страшно, конечно, но обещают много полезного. Расскажут, как вести…
⚡7🆒5🥴1
Пока ничего содержательного не пишется, поделюсь своими любимыми околорабочими мемами. И вы делитесь в комментариях!
😁41🔥9🤣5❤1
Какого размера должны быть микросервисы?
Несколько лет назад я уже писала о своем опыте работы с MSA. Там про знакомство и взаимодействие аналитика с микросервисами. Сейчас опыта стало побольше и хочется поговорить про то, как размер сервисов влияет на разработку.
Название архитектурного паттерна как бы намекает, что сервисы в MSA должны быть небольшими. Но что значит небольшим? И в масштабах какой системы?
По канонам, сервис может считаться микросервисом, если он соответствует основным принципам MSA:
- Он имеет чёткие границы и сферу ответственности,
- он независимо развертывается,
- у него своя база данных,
- он взаимодействует с другими сервисами через API.
То есть про размер ничего нет. Ни в большую, ни в меньшую сторону.
В рекомендациях часто косвенно связывают размер микросервиса с размером команды. То есть команда, разрабатывающая 1 (и в идеале только 1) микросервис, должна быть 6-12 человек (правило 2х пицц). И, кажется, что это правило - результат сложного опыта и ошибок.
Иногда разработчики делают микросервисы настолько маленькими, что между ними возникает большая и разветвленная сеть APIs. Происходит много сетевых вызовов, сервисы ломают друг друга, команды много и неэффективно общаются между собой. То есть сервисы зависят друг от друга и мы получаем распределенный монолит. Хотя формально эти сервисы соответствуют принципам MSA, но фактически такая архитектура противоречит смыслу разработки микросервисов - она не избавляет систему от зависимостей, но увеличивает ее сложность за счет интеграций и инфраструктуры.
Бывают и обратные ситуации. В примерах микросервисов часто можно увидеть такие агрегаты, как Оплата, Заказ, Доставка, Склад и др.
При определенном масштабе системы такие бизнес-функции могут включать в себя много сложной логики.
Например, платежный микросервис будет содержать данные об оплатах, проверки транзакий, интеграции с платежными шлюзами, бухгалтерией, антифродом и пр. То есть на выходе получается не то чтобы “микро-” сервис.
И если с этим справляется одна двухпиццевая команда, то все отлично - сервис автономен, не сильно зависит от других сервисов и представляет сам по себе ценность для бизнеса.
Но системы имеют свойство развиваться. И в какой-то момент 12 человек уже может не хватать, чтобы поддерживать всю логику и контракты. Команда вырастет, незаметно для всех разобьется на подкоманды, каждая со своей зоной ответственности. Эти подкоманды начнут друг другу мешаться, долго разрабатывать и еще дольше деплоить. В результате получится мини-монолит в микросервисной шкуре.
Можно, конечно, попросить системных аналитиков держать всю эту махину под контролем. Но иногда и их ресурсов не хватает, чтобы осознать, запомнить и задокументировать весь контекст “микро-”сервиса. В таких случаях рекомендуют распиливать получившийся мини-монолит - скорее всего, образуя из подкоманд отдельные команды.
В общем, микросервисы это и так сложно, а тут еще приставка “микро-” сильно сбивает с толку.
Например, на одном моем проекте распределенную систему из “среднего” размера сервисов причисляли к SOA-паттерну. Хотя там не было ни ESB-шины, ни общих баз данных, ни централизованной оркестрации. По факту это была распределенная система из микросервисов и мини-монолитов, которые все вместе вполне отвечали принципам MSA.
По моему опыту все-таки лучше иметь дело с мини-монолитами, чем собирать слово “Вечность” из слишком мелких и сильно связанных микросервисов.
Многие эксперты тоже советуют “не мельчить”, например здесь и здесь.
А с какими микросервисами вы сталкивались в своей практике? И как вам такой опыт?
Несколько лет назад я уже писала о своем опыте работы с MSA. Там про знакомство и взаимодействие аналитика с микросервисами. Сейчас опыта стало побольше и хочется поговорить про то, как размер сервисов влияет на разработку.
Название архитектурного паттерна как бы намекает, что сервисы в MSA должны быть небольшими. Но что значит небольшим? И в масштабах какой системы?
По канонам, сервис может считаться микросервисом, если он соответствует основным принципам MSA:
- Он имеет чёткие границы и сферу ответственности,
- он независимо развертывается,
- у него своя база данных,
- он взаимодействует с другими сервисами через API.
То есть про размер ничего нет. Ни в большую, ни в меньшую сторону.
В рекомендациях часто косвенно связывают размер микросервиса с размером команды. То есть команда, разрабатывающая 1 (и в идеале только 1) микросервис, должна быть 6-12 человек (правило 2х пицц). И, кажется, что это правило - результат сложного опыта и ошибок.
Иногда разработчики делают микросервисы настолько маленькими, что между ними возникает большая и разветвленная сеть APIs. Происходит много сетевых вызовов, сервисы ломают друг друга, команды много и неэффективно общаются между собой. То есть сервисы зависят друг от друга и мы получаем распределенный монолит. Хотя формально эти сервисы соответствуют принципам MSA, но фактически такая архитектура противоречит смыслу разработки микросервисов - она не избавляет систему от зависимостей, но увеличивает ее сложность за счет интеграций и инфраструктуры.
Бывают и обратные ситуации. В примерах микросервисов часто можно увидеть такие агрегаты, как Оплата, Заказ, Доставка, Склад и др.
При определенном масштабе системы такие бизнес-функции могут включать в себя много сложной логики.
Например, платежный микросервис будет содержать данные об оплатах, проверки транзакий, интеграции с платежными шлюзами, бухгалтерией, антифродом и пр. То есть на выходе получается не то чтобы “микро-” сервис.
И если с этим справляется одна двухпиццевая команда, то все отлично - сервис автономен, не сильно зависит от других сервисов и представляет сам по себе ценность для бизнеса.
Но системы имеют свойство развиваться. И в какой-то момент 12 человек уже может не хватать, чтобы поддерживать всю логику и контракты. Команда вырастет, незаметно для всех разобьется на подкоманды, каждая со своей зоной ответственности. Эти подкоманды начнут друг другу мешаться, долго разрабатывать и еще дольше деплоить. В результате получится мини-монолит в микросервисной шкуре.
Можно, конечно, попросить системных аналитиков держать всю эту махину под контролем. Но иногда и их ресурсов не хватает, чтобы осознать, запомнить и задокументировать весь контекст “микро-”сервиса. В таких случаях рекомендуют распиливать получившийся мини-монолит - скорее всего, образуя из подкоманд отдельные команды.
В общем, микросервисы это и так сложно, а тут еще приставка “микро-” сильно сбивает с толку.
Например, на одном моем проекте распределенную систему из “среднего” размера сервисов причисляли к SOA-паттерну. Хотя там не было ни ESB-шины, ни общих баз данных, ни централизованной оркестрации. По факту это была распределенная система из микросервисов и мини-монолитов, которые все вместе вполне отвечали принципам MSA.
По моему опыту все-таки лучше иметь дело с мини-монолитами, чем собирать слово “Вечность” из слишком мелких и сильно связанных микросервисов.
Многие эксперты тоже советуют “не мельчить”, например здесь и здесь.
А с какими микросервисами вы сталкивались в своей практике? И как вам такой опыт?
Хабр
Микросервисы глазами аналитика
Расскажу про системы с микросервисной архитектурой (MSA). Как они устроены, как я их анализировала, какие увидела проблемы и преимущества. Статья не раскрывает лучшие практики использования...
👍25❤11🔥3
Курсы по основам программирования
Решила освежить базу и пройти легендарный гарвардский курс CS50: Introduction to Computer Science.
Пока прослушала половину лекций и мне все очень нравится.
Курс бесплатный и очень качественный. Особенно ценно, что он обновляется каждый год и дает актуальную информацию и современные примеры.
Из возможных сложностей отмечу, что материала много и он на английском. Но английский очень понятный, B1 должно спокойно хватать. Есть перевод на русский от JavaRush, но там версия 2015го года.
В CS50 не дают лишних подробностей и не перегружают терминами, а стараются объяснить так, чтобы появилось общее понимание базовых концепций и принципов.
Мне кажется очень грамотным, что основы программирования начинают объяснять на примере C, а не Python, как это делается в большинстве современных стартовых курсов. Потому что на C все расписывается подробно и долго — а это очень помогает усвоению информации.
Также полезно понимать, как работают функции, встроенные в высокоуровневые языки. А С — это отличный способ разобраться в фундаменте работы программиста. Ведь многие интерпретаторы и компиляторы написаны на C (в том числе Python). И С все еще остаётся базовым языком операционных систем и низкоуровневых библиотек.
Помимо C, в курсе рассказывают про Python, память, алгоритмы, структуры данных, SQL, HTML, CSS и JavaScript. То есть информации много и даже если посмотреть только лекции — вполне можно получить общее представление об ИТ.
Отдельного восхищения достойны лектор Дэвид Мэлэн и организаторы — прекрасная подача материала и техническая подготовка. Как будто ты смотришь стендап-концерт, а не лекции по основам информационных технологий.
В общем, рекомендую.
А если CS50 кажется сложноватым — можно посмотреть на эти курсы:
🐤 ITProger: все коротко, без подробностей и иногда не очень связно, но бесплатно.
🐤 Wexler: программа хорошая, бесплатные пробные уроки понравились, но дороговато.
🐤 Udemy: программа неплохая, ее можно взять за основу самостоятельного обучения. Сами мини-лекции мне показались поверхностными и нудными.
Решила освежить базу и пройти легендарный гарвардский курс CS50: Introduction to Computer Science.
Пока прослушала половину лекций и мне все очень нравится.
Курс бесплатный и очень качественный. Особенно ценно, что он обновляется каждый год и дает актуальную информацию и современные примеры.
Из возможных сложностей отмечу, что материала много и он на английском. Но английский очень понятный, B1 должно спокойно хватать. Есть перевод на русский от JavaRush, но там версия 2015го года.
В CS50 не дают лишних подробностей и не перегружают терминами, а стараются объяснить так, чтобы появилось общее понимание базовых концепций и принципов.
Мне кажется очень грамотным, что основы программирования начинают объяснять на примере C, а не Python, как это делается в большинстве современных стартовых курсов. Потому что на C все расписывается подробно и долго — а это очень помогает усвоению информации.
Также полезно понимать, как работают функции, встроенные в высокоуровневые языки. А С — это отличный способ разобраться в фундаменте работы программиста. Ведь многие интерпретаторы и компиляторы написаны на C (в том числе Python). И С все еще остаётся базовым языком операционных систем и низкоуровневых библиотек.
Помимо C, в курсе рассказывают про Python, память, алгоритмы, структуры данных, SQL, HTML, CSS и JavaScript. То есть информации много и даже если посмотреть только лекции — вполне можно получить общее представление об ИТ.
Отдельного восхищения достойны лектор Дэвид Мэлэн и организаторы — прекрасная подача материала и техническая подготовка. Как будто ты смотришь стендап-концерт, а не лекции по основам информационных технологий.
В общем, рекомендую.
А если CS50 кажется сложноватым — можно посмотреть на эти курсы:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
1. CS50 на русском: Лекция #1 [Гарвард, Основы программирования, осень 2015 год]
Доп. материалы и задачи к лекции - https://javarush.com/s/level_0
Весь курс CS50 — https://javarush.com/s/course_cs50
Это Хогвартс? Нет, друзья, это Гарвард и первая лекция (Week 0) легендарного курса по основам программирования CS50 с русским переводом.…
Весь курс CS50 — https://javarush.com/s/course_cs50
Это Хогвартс? Нет, друзья, это Гарвард и первая лекция (Week 0) легендарного курса по основам программирования CS50 с русским переводом.…
❤22🔥14👍9🙏1
НАВИГАЦИЯ ПО КАНАЛУ
Оглавление всех постов:
О канале и авторе
🔧 HARD SKILLS
Интеграции и API
• Пректирование GraphQL API - цикл статей:
- Введение в GraphQL (07.2025)
- Схема GraphQL (07.2025)
- Архитектура и GraphQL (08.2025)
- Тестовый сервер с "живыми" примерами из статей (09.2025)
• Как познакомиться с GraphQL (10.2024)
• Чем опасен PATCH? (09.2024)
• 6 принципов проектирования API (08.2024)
• Инфографика: API technologies (07.2024)
• Проблема зависимых сообщений (07.2024)
• 12 способов сделать API безопаснее (12.2023)
• Event Driven Architecture - что почитать (07.2023)
• Доступ к данным в API (02.2023)
• Воркшоп по проектированию интеграций (11.2022)
• Идентификаторы в системах (08.2022)
• Что почитать про REST-like API (08.2022)
• Пагинация (04.2022)
• Основы интеграции систем - вебинар (03.2022)
• Обратная совместимость (01.2022)
Анализ и разработка
• Изучение Golang - первые впечатления (12.2025)
• Курсы по основам программирования (05.2025)
• Какого размера должны быть микросервисы? (04.2025)
• Дискуссия о книге Вигерса в 2024 году (08.2024)
• Важность реальных данных при разработке (12.2023)
• Памятка для погружения в новый проект (04.2022)
• Интервью о работе системного аналитика (11.2021)
• Бесплатные курсы по базам данных и SQL (10.2021)
• Статья про микросервисы на Хабре (10.2021)
• Документация в порядке - статья на Хабре (03.2021)
• Требования к ПО на пальцах - статья на Хабре (05.2020)
• А. Купер "Интерфейс" (09.2019)
🧠 SOFT SKILLS
Карьера и развитие
• Чем занимаются системные аналитики? (10.2025)
• Прожарка LinkedIn профиля (12.2024)
• Резюме для международного рынка (11.2024)
• Ресурсы для поиска работы (11.2021)
• Летний Аналитический Фестиваль (07.2021)
Написание текстов и коммуникация
• Позитивная коммуникация (11.2019)
• TED про когнитивные искажения (10.2019)
• 5 этапов написания текста (08.2019)
• Тексты, которые пишут люди - книги по писательству (08.2019)
Тайм-менеджмент и продуктивность
• Notion для личной базы знаний (08.2021)
• Книга про уверенность К. Форен (03.2021)
• Agile-методологии - космическая одиссея (10.2019)
• Энергия и откуда ее брать (09.2019)
• Секретный секрет тайм-менеджмента (09.2019)
Оглавление всех постов:
О канале и авторе
🔧 HARD SKILLS
Интеграции и API
• Пректирование GraphQL API - цикл статей:
- Введение в GraphQL (07.2025)
- Схема GraphQL (07.2025)
- Архитектура и GraphQL (08.2025)
- Тестовый сервер с "живыми" примерами из статей (09.2025)
• Как познакомиться с GraphQL (10.2024)
• Чем опасен PATCH? (09.2024)
• 6 принципов проектирования API (08.2024)
• Инфографика: API technologies (07.2024)
• Проблема зависимых сообщений (07.2024)
• 12 способов сделать API безопаснее (12.2023)
• Event Driven Architecture - что почитать (07.2023)
• Доступ к данным в API (02.2023)
• Воркшоп по проектированию интеграций (11.2022)
• Идентификаторы в системах (08.2022)
• Что почитать про REST-like API (08.2022)
• Пагинация (04.2022)
• Основы интеграции систем - вебинар (03.2022)
• Обратная совместимость (01.2022)
Анализ и разработка
• Изучение Golang - первые впечатления (12.2025)
• Курсы по основам программирования (05.2025)
• Какого размера должны быть микросервисы? (04.2025)
• Дискуссия о книге Вигерса в 2024 году (08.2024)
• Важность реальных данных при разработке (12.2023)
• Памятка для погружения в новый проект (04.2022)
• Интервью о работе системного аналитика (11.2021)
• Бесплатные курсы по базам данных и SQL (10.2021)
• Статья про микросервисы на Хабре (10.2021)
• Документация в порядке - статья на Хабре (03.2021)
• Требования к ПО на пальцах - статья на Хабре (05.2020)
• А. Купер "Интерфейс" (09.2019)
🧠 SOFT SKILLS
Карьера и развитие
• Чем занимаются системные аналитики? (10.2025)
• Прожарка LinkedIn профиля (12.2024)
• Резюме для международного рынка (11.2024)
• Ресурсы для поиска работы (11.2021)
• Летний Аналитический Фестиваль (07.2021)
Написание текстов и коммуникация
• Позитивная коммуникация (11.2019)
• TED про когнитивные искажения (10.2019)
• 5 этапов написания текста (08.2019)
• Тексты, которые пишут люди - книги по писательству (08.2019)
Тайм-менеджмент и продуктивность
• Notion для личной базы знаний (08.2021)
• Книга про уверенность К. Форен (03.2021)
• Agile-методологии - космическая одиссея (10.2019)
• Энергия и откуда ее брать (09.2019)
• Секретный секрет тайм-менеджмента (09.2019)
Telegram
Системный сервант
О КАНАЛЕ И АВТОРЕ
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю…
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю…
👍27🔥18❤9
Системный сервант pinned «НАВИГАЦИЯ ПО КАНАЛУ Оглавление всех постов: О канале и авторе 🔧 HARD SKILLS Интеграции и API • Пректирование GraphQL API - цикл статей: - Введение в GraphQL (07.2025) - Схема GraphQL (07.2025) - Архитектура и GraphQL (08.2025) …»