Видео с вебинара 📹

В прошлую среду провел вебинар на тему «Как проходить технические собеседования». В первую очередь спасибо всем, кто записался и кто принял участие в трансляции. Главное озарение, такие встречи нужно проводить чаще - когда рассказать легче, чем сто раз написать.

Вот ссылка на вебинар, кстати в Canva можно видео редактировать и публиковать, очень удобно:
https://www.canva.com/design/DAFfnYzL_WE/pjmbpiCci3ZxMmtJcARGzg/watch?utm_content=DAFfnYzL_WE&utm_campaign=designshare&utm_medium=link&utm_source=publishsharelink

Из главного, я запускаю курс-менторство на тему алгоритмов. Пока только для небольшой группы. Главная цель - сделать так, чтобы все участники могли самостоятельно решать большинство легких и средних задач на литкоде. Я нередко менторил и взращивал юных программистов, но это мой первый опыт преподавания. Короче я этим увлекся, главное не забыть свои задачки на работе вовремя закрывать 🙂

Есть еще мысли по джава и про бэкенд порасказывать, интересно было бы послушать? Напишем свой Spring?

Легкие задачи и иллюзия развития

Недавно готовя тему для группы по алгоритмам, наконец-то смог сформулировать мысль, которая долгое время крутилась в голове.

Те, кто придумывает задачи и те, кто их решает, используют один и тот же набор знаний. Этот набор алгоритмов и структур данных всем известен, он практически не меняется с годами. Инновации в этой области или незначительные или очень специфичные, которые так и не попадают на стол к кандидатам.

А задачи придумывать нужно. Самый простой вариант - взять 2-3 знакомые темы, соединить их и сверху присыпать мишурой, как Вася и Петя решили поесть арбуз.

Соотвественно нам нужно сделать все в обратном порядке. Убрать все лишнее из задачи и попытаться понять, какая комбинация алгоритмов поможет решить проблему.

Для этого нужно напрягать мозги. Открыть задачу, прочитать, попробовать решить ее, получить ошибку и повторить все снова. Попробовать один подход, потом второй, потом комбинацию первого и второго. Так рождается опыт. Так мы учимся сводить задачу к более легким составляющим. Как засунуть жирафа в холодильник.

И в этом есть основной минус легких задач. Просто сделай, что попросили, не нужно ничего придумывать. Они не позволяют думать. Они дают лишь иллюзию развития вместо самого развития. 300, 500 или 1000 решенных легких задач - для чего это все? В чем польза? Тот случай, когда количество не переходит в качество.

- Учите теорию
- Подкрепляйте практикой
- Задача всегда должна оставаться сложной, чтобы расти

Истинное знание, как и все наиболее ценное, не должно быть легкодоступным. Чтобы получить его, надо работать, учиться, думать и, более всего, нужно молиться о нем.
— Томас Арнольд

17 причин не становиться менеджером 👨‍💼

«Мало вакансий, увольняют первым, постоянно ругают и мало хвалят»

В определенный момент времени, перед разработчиком открывается выбор - расти как технический специалист дальше или же начать развивать навыки управления командой.

Основные плюсы технического направления (IC - individual contributor) - растешь как эксперт, постоянно дорожаешь на рынке труда, решаешь сложные инженерные задачи, не утруждаешь себя организационными вопросами.

С другой стороны основные преимущества менеджера - повесить с утра пиджак, сходить на пару встреч и получить свои миллионы. Шутка. Не нужно постоянно учить технологии. Рост практически неограничен. Определяешь стратегию, а не просто получаешь задачки и тд.

Наткнулся на статью, где озвучены 17 причин, почему не стоит быть менеджером. Приведу краткий перевод:
1. Занимайтесь тем, что любите. Если вы гордитесь и получаете кайф от своей работы, подумайте дважды, прежде чем менять ее.
2. Менеджеру тяжелее найти новую работу. Собеседования не такие предсказуемые, вопросы непонятные и вообще возможно твой набор навыков управленца не соответствует нуждам компании.
3. Менеджерских вакансий намного меньше. Рынку больше нужны инженеры, 7 к 1.
4. Менеджера первые на увольнение. Инженеры приносят пользу компании, а управленцы только ее увеличивают.
5. Рост по карьерной лестнице занимает в 2-3 раза больше времени, чем у разработчика. Можно годами топтаться на одном месте.
6. Инженеры могут быть немного гавнюками. Смотреть на менеджеров свысока, считать их глупыми в техническом плане, обсуждать и посмеиваться.
7. Увольнять, давать негативный фидбек, разруливать конфликты - менеджеру приходится общаться на очень и очень неприятные темы.
8. Менеджеры не могут взять и решить задачу. Нужно влиять, убеждать и вдохновлять других сделать что-то. А власть - вещь хрупкая.
9. Вся вина лежит на менеджере, а весь успех раздается команде.
10. Менеджера должны помогать IC доносить свои мысли до руководства.
11. Сделать крутую фичу, решить сложную задачу, перетащить тикеты - дофаминовый кайф, доступный только инженерам. Требуется 1-2 года, чтобы перестроить свой мозг и получать наслаждения от менеджерских активностей.
12. IC могут пробовать самые интересные фишки менеджерства: менторство, вклад в развитие команды, обсуждение стратегии и тд, без необходимости делать ужасную работу: увольнения, бюджетирование, HR процессы и тд.
13. Работа менеджера это постоянное общение. Эмоциональное истощение на работе влияет на общение с семьей и с друзьями.
14. Твое время больше тебе не принадлежит. Нельзя просто пропасть на пару дней, ты постоянно нужен команде.
15. Большое количество встреч, а еще они постоянно двигаются по времени.
16. Сильный инженер - плохой менеджер. Если хотите быть тех лидом, не стоит идти в управление.
17. Рано или поздно придется выбрать свой путь, редко когда удается совместить оба навыка.

Ссылка на статью:
https://charity.wtf/2019/09/08/reasons-not-to-be-a-manager/

А как вы думаете, почему стоит стремиться из разработчика стать менеджером?