Стоило мне только написать про поиск работы, как в ленте хабра попадается классная статья на ту же тему. Делюсь ей с вами: https://habr.com/ru/articles/872244/

Софты рулят?

Часто встречаю мнение, что основополагающее в карьере программиста - это софты, а не харды. Но так ли это на самом деле?

Прежде всего нужно разобраться, что такое «софты». За мою многолетнюю карьеру я слышала много мнений, которые базировались в первую очередь на представлениях авторов этих самых мнений и, следовательно, существенно различались между собой. Чаще всего, когда говорят про софты, имеют ввиду некоторое умение нравиться людям, «быть привлекательным человеком».

Здесь нас подстерегает первая засада: если с хардами все понятно (можно довольно легко определить, скажем, умеет человек писать код на конкретном языке или же не умеет), то как измерить «умение быть привлекательным»? Ведь чаще всего одни люди находят нас привлекательными, а другие - нет. Ваш покорный слуга имел удовольствие слышать диаметрально противоположные мнения о своих софтах: от восторженных до резко негативных. Можно прийти на собеседование, не понравиться, прийти на другое, понравится, прийти на третье и не понравиться снова. Выходит, что «софты» определяются случайным стечением обстоятельств и зависят от того, насколько совпадает ваш вайб с тем, кто вас оценивает. На мой взгляд, опрометчиво всерьез называть это какими-то «скиллами». Все гораздо проще: вы или сошлись, или не сошлись.

Насчет «умения нравиться» в контексте карьеры программиста я осмелюсь высказать радикальную идею: больше всего нравятся программисты с сильными хардами. И чем сильнее харды, тем сильнее нравятся. Лиды и менеджеры ищут специалистов, которые решат их проблемы и не создадут новых. Отсюда растут ноги у баек про токсичных сеньоров: они всех достали, но уволить нельзя, потому что кто-то должен работу работать. Поэтому, если вы хотите нравиться и получать хорошие офферы - будьте полезными, а не просто «дружелюбными и нетоксичными».

А что насчет «софтов»? Считаю ли я, что они не нужны? Отнюдь. Но планка требований к «софтам» для программистов резко отличается от планки для продавцов или, скажем, политиков. На мой взгляд, программисту требуются два основных «софт скилла»: 1. Быть адекватным в общении 2. Не продалбываться.

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

Не продалбываться - это значит нести ответственность за свою работу и за свои обещания, которые вы дали коллегам и бизнесу, своевременно отвечать на сообщения в рабочем месенеджере, не пропускать созвоны и встречи, предупреждать, если с задачей возникли проблемы и из-за этого съезжают сроки, не скрывать рабочую информацию и реальное положение дел (например, у вас не получилось сделать одну фичу из задачи и вы про это умолчали).

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

Дело в хардах

Я наблюдала, что бывает, когда про человека говорят, что у него “хорошие софты” или “плохие софты”, дело на самом деле не в софтах, а в хардах, которые ошибочно принимают за софты. Расскажу два примера из своей профессиональной жизни.

Много лет назад, когда я была джуном, в одной из компаний на перфоманс ревью мне поставили “ниже ожидаемого” по софтам (по хардам поставили “соответствует ожиданиям”). Тимлид пояснил на встрече, что моя проблема в том, что я не высказываю свое мнение, соглашаюсь со всем, что мне предложат и не умею дискутировать - просто соглашаюсь. Таким образом, я из боевой единицы, которая способна мыслить и принимать решения, становлюсь обычным исполнителем. Но почему я не высказывала своего мнения? Дело было в том, что я была джуном и у меня вообще тогда не было никакого профессионального мнения. Я старалась освоиться в технологиях, моим единственным требованием к моему коду было “чтобы работало” и я плохо понимала, чем “хороший код” отличается от “плохого кода” и что значит “потекшая абстракция”. Удивительно ли, что при отсутствии мнения я его не высказывала? Мне поставили “ниже ожидаемого” по софтам, однако вся моя проблема была в хардах. Как только я прокачала свои харды (в плане формирования профессионального мнения особенно помогла известная книга банды четырех), у меня сразу же появилось мнение, которое я стала высказывать (иногда даже слишком часто :D но это уже другая история).

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

На мой взгляд, люди довольно часто принимают за софты харды, потому что именно сильные харды открывают перед нами возможности, а слабые харды, наоборот, закрывают. Поэтому, если вы слышите, что у кого-то “плохие софты”, не спешите делать вывод, что человек мудак - возможно, на самом деле проблема вовсе не в софтах, а в хардах.

Про работу “с горящими глазами” и “просто работу за деньги”

С тех самых пор, как разработка ПО перестала быть убежищем для гиков и стало высокооплачиваемой профессией, на просторах интернета появилось бесчисленное количество споров между теми, кто работает “с горящими глазами” и теми, чьи интересы в айти касаются исключительно зарплаты. Первые обвиняют вторых в том, что они безучастны и безынициативны, а предложенные ими решения могут обернуться для проекта проблемами впоследствии. Вторые в долгу не остаются и обвиняют первых в том, что им самим спокойно не живется и они жить не дают другим. Иногда первые переходят в лагерь вторых и рассказывают о том, как они пришли к осознанию, что проект - это собственность дяди начальника, а поэтому и беспокоиться о проекте незачем, и теперь они “просто работают за деньги”. У некоторых очевидцев таких споров может возникнуть ощущение, что “интересная работа” и “работа за деньги” - это параллельные прямые, и необходимо выбрать между этими двумя вариантами.

Моя радикальная идея заключается в том, что это ложная дихотомия. В жизни я видела другую картину: одним достается все - интересные проекты, которыми они занимаются с удовольствием, высокая зарплата, и те самые “горящие глаза”, а другим - нууу… тоже какие-то деньги, да. Давайте разберемся, как так получается. Допустим, Вася - тот самый программист “с горящими глазами”, который с кайфом работает свою работу. В какой-то момент Вася решает, что все тлен и теперь он “просто работает за деньги”, а сферу своих амбиций он лучше перенесет в пятничные посиделки с друзьями. Вырастет ли от этого зарплата Васи? Черта с два. Единственное, что вырастет у Васи, так это недовольство жизнью и усталость в конце рабочей недели.

Для того, чтобы зарплата Васи выросла, необходимо, чтобы выросла объективная ценность Васи на рынке, а это произойдет, если Вася получит новые навыки и научится решать более сложные задачи. То есть Васе нужно 1) Брать на работе более сложные задачи 2) Учиться новому после работы. Проблема людей, которые готовы терпеть свою работу исключительно за деньги в том, что у них совершенно нет сил и мотивации после работы заниматься тем же, но бесплатно. Не говоря уже о том, чтобы брать на работе более сложные задачи вместо привычных, которые можно сделать, смотря параллельно сериальчик на втором мониторе. Люди, которым не нравится то, чем они занимаются, вынуждены тратить на это свою энергию и силы в то время как те, которым то же самое в кайф, наоборот, получают энергию от этого энергию и вдохновение. Поэтому те, кто кайфует от работы, продвигается по карьере, в то время как у “работающих просто за деньги” есть силы только на то, чтобы выполнять текущие задачи абы как, лишь бы их не уволили.

Поэтому, на мой взгляд, максимально выгодно со всех сторон получать кайф от того, что ты делаешь, а выпав из такого состояния, постараться в него вернуться. Все мы периодически оказываемся на месте тех, кто просто хочет сделать задачи и завершить рабочий день - мы устаем, болеем, да и просто бываем не в настроении. Но осмысленная установка на то, чтобы “просто работать работу”, на мой взгляд, может сократить карьерные и зарплатные перспективы.

Как не продалбываться?

Выше я писала о том, что одним из важных софт скиллов является умение не продалбываться. Что это значит? Это значит, что нужно выполнять обещания, на которые ты закоммитился. Чаще всего вопрос касается того, чтобы сделать конкретную работу к определенному сроку. Однако всем разработчикам известно, что оценка задачи - дело едва ли не более сложное, чем сама задача. Во время выполнения задачи обычно возникает много неопределенностей, которые невозможно было учесть заранее. Расскажу вам про способ, которым пользуюсь я.

Я считаю, что единственный более-менее надежный способ не продолбаться - это не коммититься на работу, которую не знаешь, как выполнять. Для этого необходимо прояснить неизвестные моменты до начала работы. Например, мне нужно внедрить в проект какую-то штуку, но на проекте новый для меня фреймворк / специфическая архитектура / новый апи, я с таким не работала и точно не знаю, сколько времени это займет. Тогда я отвечаю, что возьму какое-то время на исследование и по итогу смогу оценить задачу. Во время исследования я занимаюсь разработкой proof of concept, который должен прояснить неизвестные моменты. Например, если неизвестным является новое плохо задокументированное апи, то я пишу функции, которые работают с этим апи. Таким образом, proof of concept становится неким фасадом, который разделяет неизвестное и известное: в концепте будет реализовано и проверено все, что было неизвестно, а известные вещи реализованы схематично при помощи моков.

Такой способ позволяет на этапе исследования понять, как будет выполняться работа, а следовательно, и сколько она будет выполняться. К сожалению, он тоже не дает 100%-ной гарантии, однако точность его, на мой взгляд, достаточно высока.

Ошибка 90% резюме

Позавчера S0ER выпустил очень классное видео, в котором он рассказывает, на что обращают внимание при отборе резюме и собеседовании программиста, и в видео он сказал очень важную вещь - нужно учиться говорить конкретно. Это то, что я говорю 90% ребят, которые приходят ко мне за консультациями по своему резюме, и это то, на что я в первую очередь обращаю внимание при просмотре резюме и на собеседовании.

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

В комментариях к предыдущему посту задали правомерный вопрос про примеры хороших и плохих описаний своего опыта в резюме. Приведу несколько примеров:

❌ Занимался разработкой и поддержкой фронтенда на React.
✅ Занимался разработкой фронтенда приложения для покупки и продажи недвижимости. С нуля сделал интерактивные дашборды, показывающие динамику спроса/предложения по региону. Стек: react, redux, d3.js.

❌ Работал в команде из 5 человек над crm системой на React.
✅ Занимался разработкой crm системы. Добавил в таблицу заказов возможности фильтрации и сортировки заказов, сделал пошаговый визард оформления заказа. Стек: React, typescript, react query.

❌ Занимался поддержкой старых проектов, добавлял новый функционал, исправлял баги, рефакторил.
✅ Разработал с нуля и довел до продакшна два проекта для внешних заказчиков:
1. Систему бронирования туров для турагентства. Включает в себя интерактивный список туров, возможность перейти на страницу конкретного тура, пошагавшую систему бронирования. Стек: react, typescript.
2. Сайт товаров для домашних животных. Включает в себя каталог товаров по категориям, поиск, сортировки, фильтрации, добавление товара в корзину, оформление доставки. Стек: Vue, vuex.

Как видите, во втором случае мы используем не просто общие фразы, которые можно отнести к работе любого разработчика в вашем стеке, а конкретное описание, что вы реализовали во время работы.

Войти в айти

На мой взгляд, самый простой и приятный способ получить первую работу в айти - это попасть на обучающий курс или на стажировку от какой-либо компании. Такой путь имеет много преимуществ:
- Несколько месяцев вы обучаетесь у опытных наставников и делаете обучающий проект. Таким образом, вы прокачиваете свои скиллы и у вас всегда есть, к кому обратиться за помощью - к сокурсникам или преподавателям.
- Во время обучения вы можете узнать много подробностей про работу в этой компании и понять, подходит ли это вам.
- Шанс попасть на работу по итогу такого обучения очень высок: вам достаточно ходить на лекции и вовремя и качественно делать все домашки, чтобы быть в топе.

В этом посте расскажу про несколько обучающих курсов и стажировок, с которых можно круто стартовать свою карьеру.

1. Focus Start от компании ЦФТ https://team.cft.ru/start/school

Этот образовательный проект существует очень давно - я с него начинала свою карьеру frontend разработчика далеких 8 лет назад. В течение трех месяцев опытные наставники рассказывали нам про разработку на html, css, javascript и первом angular, после чего лучшие выпускники получили оффер от ЦФТ. Из 10 человек оффер получили 3 или 4 человека (точно не помню). Я, к сожалению, в число счастливчиков, начавших карьеру с ЦФТ, не попала, но обучение на курсе позволило мне довольно легко найти свою первую работу.


2. GPB IT Factory https://www.gazprombank.tech/digital/gpb-it-factory/

Образовательный проект от Газпромбанка. Мне повезло попасть в этот образовательный проект на курс по Java в прошлом году. Ребята сделали по-настоящему феноменальный курс. Тонкости проектирования бекенда нам рассказывали невероятно крутые разработчики, подача материала была на высоте. До сих пор с теплотой вспоминаю дни, проведенные за разработкой проекта на Java на этом курсе. Из 38 человек, отобранных на курс, оффер получили порядка 10.

3. Школа от KTS https://metaclass.kts.studio/

Я сама год назад училась на курсе по python в этой школе. Берут всех желающих, но в финал обучения и защиту проекта попадают только те, кто завершил все предыдущие этапы в срок. Я не завершила этот курс (ушла на курс по Java в GPB), но, насколько мне известно, обычно до финала доходит 3-5 человек.

4. Стажировки VK https://internship.vk.company/internship

Я сама не стажировалась в VK, но моя коллега проходила там стажировку. Стажировка оплачиваемая, стажеры получают на данный момент порядка 80к рублей.

5. Курс по go разработке от компании Ozon https://route256.ozon.ru/go-developer-junior

Я буду пытаться попасть на него в этом году. Если получится, то подробностями буду делиться в канале :)

6. Стажировки от Т-Банка https://education.tbank.ru/start/

Последний пост в этом канале был несколько месяцев назад, и я поняла, что хочу оживить его. За это время я успела сменить команду и получить много разного интересного опыта, которым буду делиться с вами 🥰

Сегодня хочу коснуться такой темы, как стейт менеджеры. Я с огромным удовольствием посмотрела доклад Дмитрия Бабина “Вам не нужен state менеджер “. Дмитрий сделал действительно классный анализ существующих на данный момент стейт менеджеров (упустив, однако, effector и mobx), а также сравнил их с хранением состояния средствами react. Вставлю свои пять копеек.

Дмитрий подчеркивает такую проблему стейт менеджеров, как отсутствие экосистемы (на reatom нет библиотеки работы с формой и тд), объясняя это тем, что если мы заносим в проект стейт менеджер, то мы хотим писать на нем всю бизнес логику. Я всегда относилась к стейт менеджерам иначе - в первую очередь я использовала их для хранения данных, используемых глобально (как минимум в нескольких местах приложения), а не как место для написания бизнес логики. Мои требования к стейт менеджеру следующие:

- Стейт является структурой вида “ключ-значение”.
- Содержит геттер данных по ключу.
- Содержит сеттер данных, причем для каждого поля может быть только один сеттер. Этому требованию очень удобно удовлетворяет Redux: в нем принято писать один action creator, который возвращает action, и диспатчить этот action creator из разных мест приложения; но не удовлетворяет, например, effector, потому что он допускает установку данных как в push дизайне (вызов ивента), так и в pull дизайне (подписка стора на эффект). Почему это так важно, опишу позже.
- Удобные девтулзы.

Бизнес логику я распределяла и хранила в: 1. компонентах реакт (например, вызов запроса, если он вызывается только в одном месте), 2. в ts классах (отлично подходит для кода, не требующего механизмов реактивности), 3. в redux-thunk (в небольших приложениях) или 4. в эпиках rxjs (в больших приложениях). Таким образом, я изначально проектировала свой код так, чтобы стейт менеджеру отводилась роль хранилища, поэтому с проблемой, о которой говорит Дима, я за свой профессиональный опыт так и не столкнулась.

Для чего я вообще использую стейт менеджеры? Главная проблема, которую они для меня решают, возникает вовсе не в процессе написания кода, а в процессе поддержки и эксплуатации. Хранение глобальных данных во время написания кода - это вообще не проблема. Я могу легко написать код, который хранит данные где угодно - в реакт хуках, в контексте, да хоть в объекте window. Однако потом наше приложение постепенно обрастает пользователями и фичами, и рано или поздно мы неизбежно сталкиваемся с багом: в наших глобальных данных почему-то лежит не то, что мы ожидаем. Ждем foo, а лежит bar. И дальше наша - понять, почему так получилось, и устранить проблему. Для этого, во-первых, надо понять, какие данные записаны неверно. И вот тут-то пригождаются топовые девтулзы редакса: я просто открываю девтулзы и смотрю текущий слепок данных, в котором достаточно легко нахожу неверные данные. Дальше надо понять, откуда записались неверные данные. Для этого я ставлю в соответствующем action creator брейкпойнт дебаггера и в два счета нахожу в колстеке виновника.

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

С большим удовольствием прочла классный пост Наташи про планировании и пару раз прослезилась от того, ну насколько же жиза!

Я уже писала выше: чтобы не продалбываться, очень важно не коммититься на то, чего ты не знаешь. То есть на вопрос «за сколько вы сделаете задачу, в которой хрен знает, что надо, в модуле, который вы раньше в глаза не видели» я отвечаю примерно так: «мне нужен день (полдня, два дня - не так важно), чтобы поковырять, а потом я дам оценку». Если за этот срок не удалось декомпозировать задачу на понятные мне куски, тогда я: 1. Называю срок работы над теми кусками, которые понятны 2. Говорю, что есть такие и такие непонятные куски, надо еще день (полдня, два дня), чтобы с этим разобраться. На этом этапе может оказаться, что задача вообще не стоит того, чтобы так долго с ней возиться, и на этом вы с менеджером можете порешать. Или уйти на новый цикл ресерча.

Про оценку задач

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

Зачем вообще вся эта чепуха с "оцените задачу в часах" концептуально нужна, понятно: чтобы можно было внятно сказать инвесторам, что "мы эту фигню сделаем, примерно, за месяц-полтора", потому что ответ формата "хз, когда закончим" они не примут.

На деле, получится закончить именно "хз, когда", а не за месяц, но проблемы в таких ситуациях решаются по мере поступления.

Так вот, что касается реализации, это всегда что-то потрясающе странное выходит.

Собирается вся команда (в моем самом дивном кейсе - 15+ человек), на стол начинают выкладываться задачки по одной (с которыми не дают ознакомиться заранее), и начинается доооолгое (самое эпичное на моей практике - 4 часа) гадание методом "пальцем в небо", совмещенное с азартными торгами.

Примерно так это выглядит:

Менеджер: - за сколько вы сделаете задачу, в которой хрен знает, что надо, в модуле, который вы раньше в глаза не видели?

Работник: - да кто бы знал. Там поресерчить бы. Заложим 5 часов?

Менеджер: - а чо не 4? Там, максимум, 4 часа будет!

Вот сам и делай за 4 часа, если все знаешь 🤌

Расскажу про самое сюрреалистичное, что лично со мной случалось. Нужно было оценить задачу, к которой не было дизайна вообще и даже толком требований, и никто не знал, как должен выглядеть интерфейс: сколько кнопок, где, что конкретно должно по кликам делаться, какие фреймы показываться и с каким содержимым.

И тут мне лид-бэк говорит шедевральное: "а ты что, не можешь оценить без дизайна и требований? Ну сколько, в общем, можно делать интерфейс?". Да как бы тебе сказать. От 3 часов до бесконечности, там миллион разных факторов влияет. А за сколько ты сам напишешь API без требований хоть каких-то, абстрактное такое API?

Короче, за все мои 4 с хвостиком года опыта я ни разу не видела ни в одной команде какого-то худо-бедно внятного планнинга, который не занимал бы вечность и не сводился к "то ли час делать, то ли до пенсии, но поставим 3 часа".

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

Сегодня общалась с человеком, который хочет попасть на летнюю стажировку по фронтенду, но боится не потянуть. Вдруг под “базовым пониманием Javascript” на самом деле скрывается требование знать наизусть последний стандарт ECMAScript?

Меня в моей профессиональной жизни от синдрома самозванца всегда спасала политика радикальной честности: я честно говорю, какие задачи я решала, какие не решала, что делала, а что не делала, и вторая сторона имеет право принять решение, сотрудничать ли со мной, на основе этой информации. Поэтому я никогда не боялась не вывезти - я просто не обещала то, насчет чего не уверена, и не заявляла того, чего не было. Благодаря такой позиции я всегда без сомнений старалась ухватить все доступные мне возможности - не беря на себя ответственность за решение второй стороны. Ну а если вдруг так вышло, что я не вывезла, то это не только моя ошибка, но и второй стороны тоже, и ответственность лежит не только на мне.

В последнее время вижу очень много постов, в которых красной нитью проходит идея ненависти к работодателю. Я читаю про то, как работодатели хотят “нагнуть” сотрудников, “внушают” им необходимость делать тестовое и писать сопроводительное к каждой вакансии, и все это делается для того, чтобы выжать из работника все соки и заставить его работать за копейки или вовсе бесплатно.

Я считаю, что такие посты преследуют понятную цель - вызвать в читающем ресентимент, а затем “продать” ему идею накрутки опыта и обмана работодателя. Большинству людей совестно обманывать интервьюеров на собеседовании, а при попытке обмана они ощущают жгучее чувство вины, что приводит к тому, что они начинают краснеть, бледнеть и заикаться и, естественно, проваливают собес. Поэтому для успеха всего этого мероприятия очень важно убедить кандидата в том, что работодатель - сволочь и классовый враг и поэтому не заслуживает человеческого к себе отношения, а стало быть, обмануть его не западло. Для меня остается загадкой, как подобные авторы сочетают в своих каналах призывы к “поднятию с колен” и посты про важность софт скиллов - как можно одновременно ненавидеть работодателя и дружелюбно и нетоксично общаться с коллегами и руководством? Если кто-нибудь понимает, как это работает, напишите мне об этом, пожалуйста - мне невероятно любопытно😊

Такой ресентимент имеет ряд побочных эффектов. Во-первых, жить и строить карьеру с чувством униженности довольно сложно. Во-вторых, это неизбежно отражается на стиле общения с работодателем. Расскажу вам две истории про моих приятелей, которые пострадали от собственной злобы к работодателю.

Первый приятель, пусть будет Саня, получил оффер на джуна в одну довольно крупную компанию. Саня был не промах и сразу решил дать понять, что его не проведешь. Всякий раз, когда hr отвечала ему в чате дольше суток, он писал ей в личку с вопросом “ну что там?”, а получив по почте пример трудового договора, написал hr-у письмо с наездом, что в договоре размыто сформулированы дни обязательной отработки из офиса и порядок премирования. В итоге компания решила, что с Саней лучше не связываться, и отозвала оффер.

Другой мой приятель, пусть будет Леха, решил не пытать счастье на джуна, а накрутить себе опыт и сразу устроиться на миддла. Однако вышло так, что на собеседовании интервьюера почему-то особо заинтересовал прошлый Лехин опыт, и интервьюер начал спрашивать, почему задачи, которые решил Леха, были сделаны именно таким, а не другим образом, какие еще варианты они рассматривали и к чему пришли. На это все Леха выпалил, что это не его, интервьюера, дело. Опыт есть? Три года указано? Ну так берите и выеживайтесь. Интервью Леха не прошел.

Со стороны поведение ребят может показаться странным: почему бы Сане не задать вопросы по договору спокойным и дружелюбным тоном, а Лехе не рассказать подробнее про опыт, который он же и выдумал? Это становится понятным, если учесть, что очень сложно общаться дружелюбно с теми, кого ты считаешь преградой, причем преградой искусственной, поставленной только для того, чтобы “нагнуть работника”. Как бы ты не скрывал свою злобу по отношению к работодателю, рано или поздно она станет заметной. Поэтому я призываю вас не поддаваться на призывы “нагнуть работодателя в ответ”, а идти путем сотрудничества с работодателем, стараться быть тем человеком, который искренне поймет проблемы и бизнес задачи работодателя и постарается их решить - и тогда у вас будут все основания на то, чтобы получать прибавки и премии.

Являются ли пет-проекты релеватным опытом?

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

Как лучше всего описать такой опыт? Зависит от того, что именно вы делали. Если вы разрабатывали какую-то библиотеку, которая нужна для вашей повседневной разработки, то стоит указать, какую задачу ваш инструмент решает. Если же вы завели проект просто для отработки новых паттернов/подходов к разработке, то стоит описать функциональность. В обоих случаях стоит рассказать о том, как технически устроено ваше решение, какая архитектура и библиотеки выбраны, с чем вы сравнивали и что вам в итоге дал ваш выбор.

Классных вам пет проектов и не забывайте, что они достойное украшение вашего резюме🙂

Как же мне откликается этот пост! Я видела очень много хейта в сторону новых технологий - зачем тайпскрипт, зачем фреймворки, на жиквери же нормально писали… Появление новых технологий - это неизбежная эволюция, и лично меня радует и вдохновляет, что она происходит прямо на моих глазах

Каково быть женщиной в айти?

Казалось бы, 2025 год на дворе, однако я до сих пор иногда встречаю мнение, что айти - мужское дело. По правде говоря, такую позицию я встречаю в основном за пределами айтишной тусовки: как-то раз я столкнулась с искренним удивлением по поводу моей профессии от мастера маникюра, а на одной из съемок визажист заметила, что я “слишком симпатичная для программистки”. Не могу сказать, что в сфере не существует никаких предубеждений против женщин - мне встречались айтишники, которые считали, что женщины не могут программировать и единственные допустимые для женщин профессии в айти - это тестирование и менеджмент.

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

Когда я начинала свой карьерный путь, я видела вокруг себя совсем мало женщин-программисток, но сейчас ситуация сильно изменилась. На митапах и конференциях я вижу все больше и больше женщин. На курсе по разработке бекенда на java, который я проходила в прошлом году, женщин было минимум треть группы. Меня очень радует, что гендерный баланс в айти потихоньку выравнивается - и я вижу, что это будет происходить и дальше.

Неоплачиваемые стажировки: за/против

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

Прежде всего нужно понять: проект проекту рознь. Это - самый главный фактор, который определяет, есть ли смысл вписываться в какой-либо проект на волонтерских началах. Для того, чтобы вы могли прокачать свои навыки на проекте, на этом проекте вы должны получать обратную связь от опытного разработчика, который подсветит вам ваши пробелы и ошибки. Например, блоггер S0ER периодически набирает ребят в проект Naris. Я сама участвовала в этом проекте, будучи уже далеко не джуном, и подчерпнула для себя много интересных разработческих фишек. Также многие крупные компании - например, Газпромбанк, Озон, ЦФТ, KTS - периодически набирают учеников на бесплатные курсы, в рамках которого вы также будете делать какой-либо учебный проект и получать обратную связь от менторов. Прокачка скиллов на таких проектах позволит вам не просто писать работоспособный код, но и сделать его гибким, поддерживаемым и масштабируемым.

Однако сейчас на рынке появилось много предложений бесплатных стажировок от мелких работодателей. Часто в таких вакансиях обещают нанять вас в штат после бесплатной стажировки. За редким исключением, такие проекты не способны вас ничему научить, потому что у них нет такой цели, на них не применяются best practices, часто формальное ревью. По сути, это просто бесплатная работа. Я советую вам избегать таких проектов и не надеяться, что после бесплатной стажировки вас обязательно возьмут в штат, потому что у работодателя есть прекрасная возможность этого не делать. На таком проекте вы просто потеряете время и мало чему научитесь.

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

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

Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: "УТЕЧКА ЯДОВИТОГО ГАЗА!!!".
— Как так–то, б..ть! Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу:
— Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что–то в проекте менял?

— Немного, швабры вынес...
— Швабры потолок держали!
— Что??? Что, б...ть, извините???
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.

— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его, б...ть, демонтировал сразу же!
— Зачем?
— Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик бл...ских ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.

— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и у..бывайте!

—-
Баян, но каждый раз смеюсь