Продолжаем говорить про собеседование в Thoughtworks
Этап 2. Технический кругозор (1,5 часа)
Для начала кандидата спрашивают о прошлых проектах: что было интересного и чем можно гордиться.
Я считаю это отличным началом разговора, так как человек расскажет о том, что хорошо знает, с чем он работал и чем горд. И по крайней мере перестанет нервничать, так как на первый вопрос из билета уже ответил 🙂 Ну а мы – интервьюеры — получаем пищу для последующих вопросов:
Почему выбрали микросервисы — поможет понять, анализировал ли кандидат другие варианты или взял первое, что попалось
Что бы вы сделали по другому — покажет, рефлексировал ли кандидат над содеянным
Если кандидат упомянул, что знает несколько языков, спросим какой из них любимый и почему
Можно спросить о технических деталях — про особенности распределенных транзакций и всякие garbage collector’ы, — если только кандидат упоминал, что работал с ними
В общем, пытаемся прощупать общий кругозор и позадавать вопросы в глубину. Но в общем и целом, это интервью больше напоминает беседу двух инженеров, чем собеседование
Этап 3. Culture Fit
Финальная часть собеседования, на которой оценивается насколько органично кандидат вольётся в коллектив. Для этого задаём стандартные поведенческие вопросы про ситуации на работе, два стула, вот это всё.
Если вы дошли до этого этапа, считайте что офер у вас уже есть.
Завалиться можно на каком-нибудь некрасивом поступке. Например, один кандидат игнорировал вопросы девушки и общался только с парнем.
Если вам понравился процесс и вы готовы попробовать свои силы, то сейчас Thoughtworks набирает разработчиков во Въетнам 😉
Этап 2. Технический кругозор (1,5 часа)
Для начала кандидата спрашивают о прошлых проектах: что было интересного и чем можно гордиться.
Я считаю это отличным началом разговора, так как человек расскажет о том, что хорошо знает, с чем он работал и чем горд. И по крайней мере перестанет нервничать, так как на первый вопрос из билета уже ответил 🙂 Ну а мы – интервьюеры — получаем пищу для последующих вопросов:
Почему выбрали микросервисы — поможет понять, анализировал ли кандидат другие варианты или взял первое, что попалось
Что бы вы сделали по другому — покажет, рефлексировал ли кандидат над содеянным
Если кандидат упомянул, что знает несколько языков, спросим какой из них любимый и почему
Можно спросить о технических деталях — про особенности распределенных транзакций и всякие garbage collector’ы, — если только кандидат упоминал, что работал с ними
В общем, пытаемся прощупать общий кругозор и позадавать вопросы в глубину. Но в общем и целом, это интервью больше напоминает беседу двух инженеров, чем собеседование
Этап 3. Culture Fit
Финальная часть собеседования, на которой оценивается насколько органично кандидат вольётся в коллектив. Для этого задаём стандартные поведенческие вопросы про ситуации на работе, два стула, вот это всё.
Если вы дошли до этого этапа, считайте что офер у вас уже есть.
Завалиться можно на каком-нибудь некрасивом поступке. Например, один кандидат игнорировал вопросы девушки и общался только с парнем.
Если вам понравился процесс и вы готовы попробовать свои силы, то сейчас Thoughtworks набирает разработчиков во Въетнам 😉
👍14
Когда дал джунам проект и вышел из кабинета
https://coub.com/view/3bmi5r
https://coub.com/view/3bmi5r
Coub
Игра в баскетбол в параллельной вселенной - Coub
Created by Minions. Open and watch this coub with all the loops!
😁24❤9🤡1
Мы уже рассказывали, как нанимать и мотивировать людей. Теперь расскажем, как их правильно увольнять — не нарушая прав, не превышая полномочий, без людоедства и произвола
⚠️ Описанное ниже применимо, если вы работаете по ТК в окружении адекватных менеджеров.
Представим, что у нас есть разраб и он косячит так, что за ним потом прибирают все. Допустим также, что мы уже испробовали все мирные способы: поговорили по душам, отправляли в отпуск, приглашали в офис массажиста. Разработчик раскаялся, распрямился и порозовел, но творить дичь не перестал. Остаётся только уволить.
1️⃣ Соберите числовые показатели, которым сотрудник должен соответствовать. Показатели нужны понятные, отслеживаемые и общедоступные — по SMART.
2️⃣ Поговорите с сотрудником ещё раз. Постарайтесь выяснить, какие у него проблемы и почему он так хуёво работает.
Если сотрудник внятно не отвечает, покажите список показателей. Объясните, о чем и для чего каждый, как это влияет на работу команды. Попросите подтвердить согласие со списком в письме.
Если у сотрудника проблемы, на этом этапе он перестанет отмалчиваться и всё можно будет обсудить и попробовать исправить. Иначе идём далее.
3️⃣ Назначьте условный испытательный срок внутри команды, около месяца. Если сотрудник справился — проблема вроде как решена. Если не справился — у вас появляется аргумент для кадровиков.
4️⃣ Кадровики назначат сотруднику сокращенный испытательный срок, по результатам которого рассмотрят увольнение по ТК.
Процесс занимает до трёх месяцев. Разумеется, сотрудник будет в курсе происходящего и вам придётся с ним сосуществовать и работать. Поэтому проще наладить отбор и прохождение испытательного срока. Ну или работать там, где могут уволить одним днем, в том числе и вас ✨
⚠️ Описанное ниже применимо, если вы работаете по ТК в окружении адекватных менеджеров.
Представим, что у нас есть разраб и он косячит так, что за ним потом прибирают все. Допустим также, что мы уже испробовали все мирные способы: поговорили по душам, отправляли в отпуск, приглашали в офис массажиста. Разработчик раскаялся, распрямился и порозовел, но творить дичь не перестал. Остаётся только уволить.
Если сотрудник внятно не отвечает, покажите список показателей. Объясните, о чем и для чего каждый, как это влияет на работу команды. Попросите подтвердить согласие со списком в письме.
Если у сотрудника проблемы, на этом этапе он перестанет отмалчиваться и всё можно будет обсудить и попробовать исправить. Иначе идём далее.
Процесс занимает до трёх месяцев. Разумеется, сотрудник будет в курсе происходящего и вам придётся с ним сосуществовать и работать. Поэтому проще наладить отбор и прохождение испытательного срока. Ну или работать там, где могут уволить одним днем, в том числе и вас ✨
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2
StringConcat - разработка без боли и сожалений pinned «Практический курс Разработка Enterprise-приложений без боли и сожалений На конференциях все рассказывают об успехах и высоких нагрузках. Но в реальности архитектура не предусматривает изменений, требования меняются каждый спринт, а разработчики тушат пожары…»
Жопа босса знает лучше — важная особенность китайской культуры
В Thoughtworks мне предложили поработать на нового клиента, но предупредили, что это очень традиционная китайская организация. Оказалось, это важно знать заранее. И вот почему.
Пришёл к клиенту в офис, ищу стул. Пробую один, другой, регулирую — все не очень. Говорю разработчику Чену:
— Стулья неудобные какие-то.
— А я их сам выбирал.
— Так у тебя жопа как у меня, тебе удобно, что ли?
— Неудобно, но другие нельзя было выбрать.
И рассказывает историю. Привезли в офис разных стульев на пробу, позвали Чена выбирать ягодицами. Он приходит, а там уже начальство всё попробовало, выбрало и расхваливает. Чен садится, ему неудобно, но возразить начальству он не может, в Китае не принято перечить старшим. Причём и по возрасту, и по положению. Поэтому слово начальника — закон, даже если он решил фронт на PHP писать. И уже не важно, что нужно бизнесу, что пользователю, — начальник выбрал, ты кивнул.
Для сравнения в Скандинавии царит дух равенства и даже тимлид не может решать за всю команду. Любое решение придётся продавать, а команда может его не принять. И я такое встречал даже в банке.
По моим наблюдениям в атмосфере равенства получаются более качественные продукты: каждый в команде чувствует причастность и ответственность за результат. При подходе «спустили сверху» причастности не ощущается. С другой стороны, скандинавы некоторые проблемы решают месяцами, утопая в бесконечных обсуждениях. Китайцам же консенсус искать не нужно, за них всё Конфуций решил.
В Thoughtworks мне предложили поработать на нового клиента, но предупредили, что это очень традиционная китайская организация. Оказалось, это важно знать заранее. И вот почему.
Пришёл к клиенту в офис, ищу стул. Пробую один, другой, регулирую — все не очень. Говорю разработчику Чену:
— Стулья неудобные какие-то.
— А я их сам выбирал.
— Так у тебя жопа как у меня, тебе удобно, что ли?
— Неудобно, но другие нельзя было выбрать.
И рассказывает историю. Привезли в офис разных стульев на пробу, позвали Чена выбирать ягодицами. Он приходит, а там уже начальство всё попробовало, выбрало и расхваливает. Чен садится, ему неудобно, но возразить начальству он не может, в Китае не принято перечить старшим. Причём и по возрасту, и по положению. Поэтому слово начальника — закон, даже если он решил фронт на PHP писать. И уже не важно, что нужно бизнесу, что пользователю, — начальник выбрал, ты кивнул.
Для сравнения в Скандинавии царит дух равенства и даже тимлид не может решать за всю команду. Любое решение придётся продавать, а команда может его не принять. И я такое встречал даже в банке.
По моим наблюдениям в атмосфере равенства получаются более качественные продукты: каждый в команде чувствует причастность и ответственность за результат. При подходе «спустили сверху» причастности не ощущается. С другой стороны, скандинавы некоторые проблемы решают месяцами, утопая в бесконечных обсуждениях. Китайцам же консенсус искать не нужно, за них всё Конфуций решил.
🔥15😁8🤯7
Полезное для линуксоидов и маководов
SDKMAN — пакетный менеджер для JVM-мира. Позволяет устанавливать и жонглировать SDKашками и инструментами без геморроя и ручных манипуляций с переменными окружения, как, например, в brew.
Может держать, к примеру, несколько версий и разновидностей JDK и переключаться между ними по необходимости. Ну и разновидностей JDK целый вагон.
Работает на большинстве Unix-образных систем и вроде как даже на винде через Cygwin, но я не пробовал. Не заменит
SDKMAN — пакетный менеджер для JVM-мира. Позволяет устанавливать и жонглировать SDKашками и инструментами без геморроя и ручных манипуляций с переменными окружения, как, например, в brew.
Может держать, к примеру, несколько версий и разновидностей JDK и переключаться между ними по необходимости. Ну и разновидностей JDK целый вагон.
Работает на большинстве Unix-образных систем и вроде как даже на винде через Cygwin, но я не пробовал. Не заменит
brew или же apt, но рулить Java-миром через него однозначно удобнее. Крайне рекомендую к установке.🔥9👍7
Для чего же всё-таки нужно резюме
Представьте, заходите вы в чат, а там два полярных мнения:
1. Резюме бесполезно. Соискатели всё врут, поэтому работодатели резюме не читают и всё нужное узнают на собеседовании.
2. Резюме полезно. Соискатель может показать важные кейсы, а работодатель получить общее представление и подумать, о чём спрашивать на собеседовании.
Какое сами лайкните, а какое друзьям перешлёте?
Конечно, есть спектр мнений где-то между, но нам больше интересно именно ваше отношение к вопросу и волшебные истории с собеседований. Пишите в комментариях, устроим бугурт и фестиваль ненависти.
Представьте, заходите вы в чат, а там два полярных мнения:
1. Резюме бесполезно. Соискатели всё врут, поэтому работодатели резюме не читают и всё нужное узнают на собеседовании.
2. Резюме полезно. Соискатель может показать важные кейсы, а работодатель получить общее представление и подумать, о чём спрашивать на собеседовании.
Какое сами лайкните, а какое друзьям перешлёте?
Конечно, есть спектр мнений где-то между, но нам больше интересно именно ваше отношение к вопросу и волшебные истории с собеседований. Пишите в комментариях, устроим бугурт и фестиваль ненависти.
❤1👍1
Как Netflix мигрировали на новый API и ничего не потеряли. Первая часть
У Netflix недавно рассказали, как они мигрировали на новый API без даунтайма.
Вот самое любопытное:
Netflix мигрирует с legacy API на GraphQL. Просто выключить старый API и включить новый они не могут: обязательно что-нибудь пойдёт не так и будет стоить дорого.
Чтобы проверить новый API в боевых условиях, но без ущерба для пользователей, они деплоят его рядом со старым и проверяют через Reply Testing.
Когда получается, запрос пользователя отправляется на оба API: на новый и на старый, а ответы сравниваются. Если есть разница, значит, что-то в новом API упустили. Например:
Очевидно, забыли про поле ID и отдаём null.
А тут слетела локализация:
В статье пишут, что Reply Testing помог Netflix выявить следующие ошибки:
— encoding errors
— локализация
— формат даты и времени
— ну и, конечно, числа с плавающей точкой
А в следующей заметке поговорим, как они использовали A\B-тесты.
У Netflix недавно рассказали, как они мигрировали на новый API без даунтайма.
Вот самое любопытное:
Netflix мигрирует с legacy API на GraphQL. Просто выключить старый API и включить новый они не могут: обязательно что-нибудь пойдёт не так и будет стоить дорого.
Чтобы проверить новый API в боевых условиях, но без ущерба для пользователей, они деплоят его рядом со старым и проверяют через Reply Testing.
Когда получается, запрос пользователя отправляется на оба API: на новый и на старый, а ответы сравниваются. Если есть разница, значит, что-то в новом API упустили. Например:
/data/videos/0/tags/3/id: (81496962, null)
Очевидно, забыли про поле ID и отдаём null.
А тут слетела локализация:
/data/videos/0/tags/5/displayName: (Série, value: “S\303\251rie”)
В статье пишут, что Reply Testing помог Netflix выявить следующие ошибки:
— encoding errors
— локализация
— формат даты и времени
— ну и, конечно, числа с плавающей точкой
А в следующей заметке поговорим, как они использовали A\B-тесты.
Medium
Migrating Netflix to GraphQL Safely
By Jennifer Shin, Tejas Shikhare, Will Emmanuel
👍28❤1🔥1
Как Netflix мигрировали на новый API и ничего не потеряли. Вторая часть
В прошлой заметке было про тестирование нового API идемпотентными запросами. А в этой расскажем, как Netflix тестировали функциональность, которая меняет данные, и проверяли выполнение нефункциональных требований.
Для A\B-тестов Netflix поделили миллион пользователей на 2 группы:
— контрольную на старом API
— экспериментальную на новом.
Обе группы пользовались сервисом, а разработчики тщательно сравнивали quality of experience metrics: как часто возникают ошибки на клиенте, latency и прочее.
Конечно, разница метрик — это ещё не решение. Выявление проблем похоже на детектив: какой-то показатель ухудшился, а вам ещё нужно понять, из-за чего именно. К примеру, у Netflix нестабильный latency подсказал, что нужно подкрутить TTL кешей.
A\B-тесты оказались хорошим инструментом для проверки нефункциональных характеристик. За полгода Netflix уравняли показатели и мигрировали всех пользователей на новый API.
В прошлой заметке было про тестирование нового API идемпотентными запросами. А в этой расскажем, как Netflix тестировали функциональность, которая меняет данные, и проверяли выполнение нефункциональных требований.
Для A\B-тестов Netflix поделили миллион пользователей на 2 группы:
— контрольную на старом API
— экспериментальную на новом.
Обе группы пользовались сервисом, а разработчики тщательно сравнивали quality of experience metrics: как часто возникают ошибки на клиенте, latency и прочее.
Конечно, разница метрик — это ещё не решение. Выявление проблем похоже на детектив: какой-то показатель ухудшился, а вам ещё нужно понять, из-за чего именно. К примеру, у Netflix нестабильный latency подсказал, что нужно подкрутить TTL кешей.
A\B-тесты оказались хорошим инструментом для проверки нефункциональных характеристик. За полгода Netflix уравняли показатели и мигрировали всех пользователей на новый API.
👍10
А вы что думаете по этому поводу:
Anonymous Poll
44%
Согласен, разработка — физический труд
42%
Не согласен, программирование всё ещё элитарно
14%
Приду сраться в комменты
Здравствуйте! Это пост с набросом. Вы предупреждены.
Преамбула: в одном из архитектурных чатов у нас развернулась дискуссия по поводу специальности «разработчик»: стала она уже рабочей или ещё нет.
Рабочая — это когда нужно больше физического труда, чем умственного. И в этом смысле разработчик — вполне рабочая специальность, какоператор машинного доения сборщик на конвейере: собираешь типовые решения из представленных компонент за указанное время.
Всё описано в регламентах, собрано во фреймворки, поэтому средний разраб заменяется за день. А придумывать, как оно должно работать, — работа системных инженеров. И тут у нас получается условное деление по признаку образования:
— средне специальное образование для работяг — языки, эти ваши фреймворки и среды;
— высшее образование для инженеров — системное проектирование и всякие высокие абстракции.
И с этой позиции критика высшего образования, где «не учат актуальным языкам и фреймворкам» звучит неубедительно, там вроде как другому учить должны.
Что-то подобное я говорил на archdays, где рассказывал про подход с типовыми узлами, интерфейсами и даже наймом за день.
Преамбула: в одном из архитектурных чатов у нас развернулась дискуссия по поводу специальности «разработчик»: стала она уже рабочей или ещё нет.
Рабочая — это когда нужно больше физического труда, чем умственного. И в этом смысле разработчик — вполне рабочая специальность, как
Всё описано в регламентах, собрано во фреймворки, поэтому средний разраб заменяется за день. А придумывать, как оно должно работать, — работа системных инженеров. И тут у нас получается условное деление по признаку образования:
— средне специальное образование для работяг — языки, эти ваши фреймворки и среды;
— высшее образование для инженеров — системное проектирование и всякие высокие абстракции.
И с этой позиции критика высшего образования, где «не учат актуальным языкам и фреймворкам» звучит неубедительно, там вроде как другому учить должны.
Что-то подобное я говорил на archdays, где рассказывал про подход с типовыми узлами, интерфейсами и даже наймом за день.
YouTube
Как Event Storming, DDD и чистая архитектура помогают запустить стартап. Евгений Лукьянов
Выступление на ArchDays 2022. Подробнее о конференции: https://archconf.ru/arch
Бытует мнение, что все эти DDD и прочие DD нужны, только когда ваш проект вырос и генерирует сотни денег. На примере нашей конторы мы убедились, что это не так и все это позволяет…
Бытует мнение, что все эти DDD и прочие DD нужны, только когда ваш проект вырос и генерирует сотни денег. На примере нашей конторы мы убедились, что это не так и все это позволяет…
👍8😁1
Как сэкономить 120 000 $ в год на инфраструктуре? Просто возьмите старый проверенный EC2
Ситуация: клиент попросил оценить, не слишком ли много тратить 240 000 $ в год на инфраструктуру приложения, которое обслуживает 35 пользователей с 9:00 до 18:00.
Что мы нашли под капотом:
— 6 микросервисов, потому что модно и молодёжно
— по 2 инстансы каждого, потому что отказоустойчивость
— по 2 инстанса БД на каждый сервис, см. пункт выше
— деплой на AWS Fargate
Стоило это все 8000 $ в месяц на боевом сервере + столько же на UAT-стенде с зеркалом, который должен был быть у клиента по требованию регулятора.
Что мы изменили
1. Смёржили всё в два сервиса.
Микросервисы — отличная технология, когда вам нужно независимо масштабировать сервисы, устойчивость к отказам и независимый деплоймент сервисов. Но это при условии, что у вас микросервисы независимы и у вас зрелые Devops-практики. У нашего же клиента был типичный Distributed big ball of mud, который сводил все преимущества микросервисов в ноль.
2. Перевели деплой с AWS Fargate на EC2.
У AWS есть 2 варианта деплоя контейнеров:
— традиционный EC2. Вам выделяется виртуальная машина или несколько, в каждую машину напихивается столько контейнеров, сколько влезет.
— новый-молодежный Fargate, в котором кубернетису не нужно думать, раскидывать контейнеры по виртуалкам. Просто указываем, сколько каждому контейнеру нужно CPU и памяти, а тёмные электрические силы Амазона дальше сами всё делают.
Однако у всего есть цена. В EC2 мы могли развернуть несколько контейнеров и они шарили ресурсы. Например, пока сервис отчётов ничего не делает, он делится ресурсами с бизнесовым сервисом и наоборот. С Fargate так не выйдет, платить нужно и за простой, а ресурсы не пошаришь. Поэтому, если сервисы часто простаивают, Fargate стоит очень дорого.
EC2 стоил 3000 $ вместо 8000 $ за Fargate, получилось 60 тысяч экономии в год. Столько же удалось сэкономить на UAT-стенде. Итого те самые 120 тысяч в год из заголовка.
Ситуация: клиент попросил оценить, не слишком ли много тратить 240 000 $ в год на инфраструктуру приложения, которое обслуживает 35 пользователей с 9:00 до 18:00.
Что мы нашли под капотом:
— 6 микросервисов, потому что модно и молодёжно
— по 2 инстансы каждого, потому что отказоустойчивость
— по 2 инстанса БД на каждый сервис, см. пункт выше
— деплой на AWS Fargate
Стоило это все 8000 $ в месяц на боевом сервере + столько же на UAT-стенде с зеркалом, который должен был быть у клиента по требованию регулятора.
Что мы изменили
1. Смёржили всё в два сервиса.
Микросервисы — отличная технология, когда вам нужно независимо масштабировать сервисы, устойчивость к отказам и независимый деплоймент сервисов. Но это при условии, что у вас микросервисы независимы и у вас зрелые Devops-практики. У нашего же клиента был типичный Distributed big ball of mud, который сводил все преимущества микросервисов в ноль.
2. Перевели деплой с AWS Fargate на EC2.
У AWS есть 2 варианта деплоя контейнеров:
— традиционный EC2. Вам выделяется виртуальная машина или несколько, в каждую машину напихивается столько контейнеров, сколько влезет.
— новый-молодежный Fargate, в котором кубернетису не нужно думать, раскидывать контейнеры по виртуалкам. Просто указываем, сколько каждому контейнеру нужно CPU и памяти, а тёмные электрические силы Амазона дальше сами всё делают.
Однако у всего есть цена. В EC2 мы могли развернуть несколько контейнеров и они шарили ресурсы. Например, пока сервис отчётов ничего не делает, он делится ресурсами с бизнесовым сервисом и наоборот. С Fargate так не выйдет, платить нужно и за простой, а ресурсы не пошаришь. Поэтому, если сервисы часто простаивают, Fargate стоит очень дорого.
EC2 стоил 3000 $ вместо 8000 $ за Fargate, получилось 60 тысяч экономии в год. Столько же удалось сэкономить на UAT-стенде. Итого те самые 120 тысяч в год из заголовка.
👏19👍3❤1
Наткнулся на неплохой мануал с примерами по spring-security и oauth
Как известно, в
Как известно, в
spring-security сам черт ногу сломит, а если туда oauth добавить, то, вообще, никогда в жизни не разберёшься. В мануале автор неплохо объясняет, как что устроено с точки зрения спринга.GitHub
spring-addons/samples/tutorials at master · ch4mpy/spring-addons
Ease OAuth2 / OpenID in Spring RESTful backends. Contribute to ch4mpy/spring-addons development by creating an account on GitHub.
🔥12
Я тут систематизировал стратегии как я торговался за оффер в Thoughtworks 4 года назад. 🙂 https://www.youtube.com/watch?v=jtu_FdNDxNc
Кстати, а как вы обычно выбиваете на собеседованиях зарплату по-больше?
Кстати, а как вы обычно выбиваете на собеседованиях зарплату по-больше?
YouTube
Как торговаться о зарплате без контроффера
3 способа как можно торговаться по зарплате даже если у вас на руках только один оффер.
☝ Поваренная книга дядюшки боба: Как готовить Clean Architecture:
🎓 Курс : https://howto.stringconcat.ru/cleanarchitecture?utm_source=youtube&utm_content=how_to_negotiate_offer…
☝ Поваренная книга дядюшки боба: Как готовить Clean Architecture:
🎓 Курс : https://howto.stringconcat.ru/cleanarchitecture?utm_source=youtube&utm_content=how_to_negotiate_offer…
👍9
Небольшая заметка о том, как гарантированно заехать в дурку, находясь в айтишечке
💯19👍5
Наш студент запилил для походов на работу
🔥50👍7
Привет, зазываем на курс!
15 сентября — старт новой группы по практическому курсу Разработка Enterprise-приложений без боли и сожалений.
Самое время учиться: кризис в индустрии свирепствует, СhatGPT душит Stack Overflow. Скоро нейросети научатся перекидывать JSON в DTO, и многие кодеры окажутся не нужны, как знатоки Drupal. Чтобы остаться востребованным, нужно начинать мыслить не инструментами, а методологиями проектирования.
В общем, если хотите начать думать как тимлид, архитектор и техдир, идите на наш курс. Мы его переработали, так что теперь там ещё больше индивидуального подхода и обратной связи.
До 1 сентября курс стоит 90 000 ₽
Со 2 сентября — 140 000 ₽
Подайте заявку и сэкономьте 30% Изи мани, рил ток
15 сентября — старт новой группы по практическому курсу Разработка Enterprise-приложений без боли и сожалений.
Самое время учиться: кризис в индустрии свирепствует, СhatGPT душит Stack Overflow. Скоро нейросети научатся перекидывать JSON в DTO, и многие кодеры окажутся не нужны, как знатоки Drupal. Чтобы остаться востребованным, нужно начинать мыслить не инструментами, а методологиями проектирования.
В общем, если хотите начать думать как тимлид, архитектор и техдир, идите на наш курс. Мы его переработали, так что теперь там ещё больше индивидуального подхода и обратной связи.
До 1 сентября курс стоит 90 000 ₽
Со 2 сентября — 140 000 ₽
Подайте заявку и сэкономьте 30% Изи мани, рил ток
👍12💩5🤩3🔥2