Javaren » 22 янв 2023, 08:19
Наверняка многие слышали про сокращения в американских компаниях. В прошлом году на весь мир прогремели увольнения в Амазоне, Мете, Твиттере и многих других компаниях. В январе этого года прошла вторая волна увольнений в Амазоне, а за ним и Гугл докатился до того же. Хотя еще месяц назад утверждал, что у них такого никогда не бывает и не будет. Интересно, что они приоставили подачу заявлений на Грин Карту. Т.е. люди, которые приехали сюда и еще не успели податься, будут находиться в некоем лимбо и ждать истечения их рабочей визы. Мета также заявила, что еще не закончила с увольнениями и будет вторая волна.
Почему так происходит и зачем увольнять людей? Одна из важных причин для этого не просто очевидное сокращение расходов. Это способ привлечения инвесторов. Когда стоки падают, рынок не очень стабилен, инвесторы уходят. Они думают, что компания не переживет кризис и ожидают неких мер от компании. Самый примитивный способ - уволить сотрудников и сократить или вовсе порубить некоторые направления. Кто владеет стоками таких компаний мог заметить тенденцию: как только проходит волна сокращений - стоки ползут вверх.
Читала исследование одного профессора. Он писал, что многие компании просто повторяют за более крупными компаниями. Они видят, что лидеры рынка готовятся к кризису и совет директоров в более мелкой компании начинает вопрошать, почему, собственно, они не предпринимают никаких мер? И такая компания тоже начинает увольнять и замораживать найм новых сотрудников. Хотя никакой объективной причины так делать у них может и не быть.
Еще одна проблема maang компаний в том, что они наняли слишком много сотрудников во время пандемии, т.к. все перешли в онлайн. Поэтому теперь, когда жизнь начала переходить в нормальное русло, стоки поползли вниз, им приходится зарубать некоторые направления. Логично было бы предположить, что глядя на всю эту ситуацию, тайное мировое правительство и Масонская ложа устроят нам вторую пандемию или еще что-то, чтобы загнать всех обратно в онлайн. Поживем увидим.
Расскажу немного как устроена работа в крупных компаниях в США, и в чем отличие работы в maang от компаний поменьше.
Для тех, кто далек от ИТ, поясню, что maang это аббревиатура для крупнейших игроков на рынке ИТ, у которых больше всего денег. Meta (бывший Facebook), Amazon, Apple, Netflix, Google. В США есть также множество других интересных компаний и стартапов, которые практически не уступают maang по зарплатам, разрабатывают интересные проекты и предоставляют возможности для карьерного роста. Работа в maang это скорее вопрос престижа, высокого заработка и построения красивого резюме. Нет никакой гарантии, что работая в maang вы будете решать исключительно интересные и инновационные задачи. Эти компании специально создают такой имидж, хотя на самом деле тут уж как повезет с командой.
Одна из проблем работы в таких компаниях в том, что они используют технологии, разработанные внутри компании для внутреннего пользования. Бывает так, что их программисты не работают с известными технологиями, используюемыми во всем мире. В таких компаниях может быть разработана своя система кеширования, например, своя система деплойментов и собственная система контроля версий. Там может не использоваться cloud, а будет свой data center. В итоге люди, которые туда попадают сразу после университета, не знают технологий, популярных на рынке, и они никогда не видели разнообразных систем, построенных на различных технологиях и никогда не имели возможности их сравнить. По-моему, это не слишком хорошо для молодых специалистов, но зато работая там они получают некую стабильность, высокие зарплаты и возможность построить другие важные навыки. И многие другие компании готовы их нанять, особо не вникая в детали, просто потому, что они работали в maang.
Какие же важные навыки можно там получить? Например, работа над проектами, которые имеют большое влияние на рынок, на пользователей. Навыки самоорганизации, навык генерировать идеи. Одно из отличий таких компаний от остальных в том, что они мыслят проектами. В обычной компании у разработчиков обычно есть спринт и конкретные задачи. Спринт - это определенный период времени, обычно 2 недели, в который планируется сделать определенный список задач. Задачи обычно хорошо описаны и продуманы заранее. Обычно этим занимается менеджер вместе с командой, когда все брейнстормят то, что надо сделать и пишут описания. Обычно программисты стараются разбить большую задачу на как можно более мелкие. Так легче работать, проще расчитать время, нужное для выполнения задачи и, самое интересное, это позволяет применять continuous integration - это когда программисты деплоят готовый код на продакшн несколько раз в день. Такой подход улучшает эффективность работы в целом. Фреймворк работы по спринтам называется Scrum и является религией, которую исповедуют большинство компаний.
В maang тоже, конечно, бывают конкретные задачи, подробно расписанные, бывают и спринты. Все зависит от команды. Но на разработчике еще обычно висят несколько проектов, которые он должен вести. Проект может начинаться с дизайна (system design) - это такое техническое определение проекта, когда решается какие сервисы будут в проекте, какую базу данных выбрать и т.д. Затем доходит дело до задач, но они зачастую не определены и описаны никем. Лидер проекта должен сам разобраться, пообщаться с нужными людьми, с менеджерами, стейкхолдерами, другими командами, должен назвать сроки проекта и подключить к работе нужное количество людей. В обычных компаниях этим обычно занимается тим лид, т.е. ведущий разработчик, либо senior разработчики. В maang этим занимаются все, кроме, разве что, совсем уж джунов.
Практически во всех компаниях, не только в maang, есть oncall (по-русски дежурство) - это легальный способ эксплуатации сотрудников без увеличения заработной платы и без выплат за переработки, позволяющий просто и эффективно следовать религии Scrum. Все разработчики, и стар и млад, принимают участие в oncall ротации. От разработчика ожидается, что он 24/7 в любой момент готов вскочить по тревоге и немедленно (или немного погодя, в зависимости от уровня проблемы) пофиксить возникший баг. В эту неделю программист обычно не работает над проектами и задачами спринта, а разбирает беклог багов, скопившийся на данный момент. Однако, религия не запрещает ему работать и над обычными задачами, а менеджеры не переносили дедлайн по проектам, так что... Oncall подход позволяет разгрузить команду, которая может продолжать работать по спринту, не отвлекаясь на баги. Также oncall - это важный способ лучше и быстрее освоить и понять систему, с которой работаешь, и быть в курсе того, что происходит. Обычно от дежурного ожидается определенная скорость реакции на тревожный звонок, поэтому пока на дежурстве ни о каких поездках и путешествиях не может быть и речи. Надо быть все время дома и желательно далеко не отходить. Так, чтобы за 20-30 минут можно было добраться до дома и пофиксить баг. И телефон всегда носить с собой с включенным интернетом, чтобы получить сообщение. И да, ходить только там, где есть интернет. Иначе, если вовремя не ответить, может произойти эскалация до менеджера. А если он не ответит, это все пойдет выше по иерархической цепочке и никто за это по голове не погладит. Иногда тревога срабатывает в 2-3 часа ночи, особенно если с системой работают люди по всему миру из разных часовых поясов. Поэтому на интервью полезно спросить у команды, сколько тикетов они в среднем получают в неделю и в какое время.
Итак, задачи, проекты, oncall. Но это еще не все, что требуется от разработчика. Подразумевается, что программист будет принимать участие в различных видах деятельности. Например, он будет проводить собеседования. Прежде чем приступить к собеседованиям обычно проходят онлайн курс, где помимо прочего освещают такие моменты как дискриминация по расе и полу и учат, как избежать bias (т.е. судить здраво и не субъективно). Любая малейшая дискриминация, если собеседник нажалуется куда следует, может привести к немедленной потере работы. Сказать что-то типа "Мы вам предлагаем N зарплату. Смотрите, это же отлично, особенно для девушки/женщины" Или спросить что-то про наличие детей и сказать, что "Ну вы же будете с вашими тремя детьми сидеть, когда вам работать" - это будет полный крах карьеры, скандал в соцсетях и на blind и увольнение. Хотя достаточно будет уже просто спросить про детей, на этом интервью и закончится, скорее всего. Также абсолютно точно не получится такую информацию включить в официальный отчет после интервью. Типа у нее трое детей, давайте не будем ее нанимать. Хорошо если не уволят, но это точно будет ваше последнее интревью. После прохождения онлайн курса делают так называемый shadowing, т.е. присоединяются к интервью как наблюдатель. После нескольких итераций можно интервьюировать самостоятельно, если допустят. Т.е. если ваши отчеты после интервью и ваши суждения не сильно отличались от остальных участников процесса. Если, например, все голосуют за, а вы все время голосуете против, это не есть хорошо. Значит, вы слишком biased.
Вообще, культура тут довольно сильно отличается от российской и то, что там кажется нормальным и общепринятым (что-то такое, что даже если нам лично неприятно, но встречается на каждом шагу), здесь может оказаться табу. Например, на работе в таких компаниях мужчина вряд ли когда-либо сделает вам комплимент по поводу вашей кофточки или юбочки, а уж сказать что-то про цвет кожи, глаз или волос вообще табу. Также, комплименты типа "Ты такая маленькая и хрупкая", здесь могут привести к жалобе в отдел кадров, потому что это указание на физические признаки и указывать на это нельзя. Фразы, сказанные даже из лучших побуждений, как например "Она такая маленькая и хрупкая давай не будем просить ее работать до поздна сегодня, когда вся команда делает релиз, а еще у нее трое детей, о которых надо позаботиться" может сделать вас врагами, и такой ход мыслей не будет понят и принят командой.
Итак, про работу. Также бывает возможность контрибьютить в различные проекты, например open source проекты, которые поддерживаются компанией. Важно периодически бывать в роли onboarding buddy. Это человек, который помогает новичку войти в курс дела, все объясняет. Это показывает, что у вас высокий уровень и вы можете кого-то обучить. Также у успешного разработчика должен быть promotion path. Это может означать, что у него появляется некий ментор, который помогает ему и подкидывает задачи и проекты уровнем выше, чтобы программист получил повышение. Это может занимать несколько лет, в зависимости от того, с какого уровня на какой промоутиться.
Раз в год в компаниях проводят perfomance review, т.е. определяют хорошо ли работал программист или же он не соответствует ожиданиям. В каждой компании свои показатели для этого. Обычно разработчики весь год работают над тем, чтобы review получился хорошим. Например, могут смотреть на количество коммитов, т.е. сколько кода программист написал. Также смотрят, сколько задач он закрыл. Успешно ли и вовремя ли завершил свои проекты. Просто писать код совершенно недостаточно, поэтому во многих компаниях программист обязательно должен сделать какое-то количество system designs. Также оценивается сделал ли разработчик что-то полезное для компании. Это может, например, быть сокращение расходов на cloud, увеличение прибыли за счет разработки какого-то решения, привлечение большего количества пользователей и т.д. Т.е. вышел ли человек за рамки своих ежедневных задач. Очень важно выходить за эти рамки, поэтому программисты весь год записывают свои достижения. Затем собираются отзывы. Обычно разработчик имеет выбор, у кого конкретно запросить отзыв на его работу. Это могут быть коллеги его уровня, но еще лучше если отзывы напишут разработчики уровнем выше, менеджеры. От performance review зависит получит ли разработчик прибавку к зарплате и сколько. Также его продвижение по карьерной лестнице очень сильно зависит от этого. Плохие показатели блокируют любое продвижение, а могут приводить и к увольнению. Всем абсолютно все равно на жизненные обстоятельства, троих детей, машину, которая все время ломается и мешает доехать до работы и прочее. Т.е. вообще все равно, и это не как в Германии. Единственное, что, наверное, может повлиять на ревью - диагностированная депрессия. Это приравнивается к инвалидности и если человек, например, плохо работал из-за депрессии, возможно, его не прям сразу уволят, а дадут возможность как-то исправиться. В США нет каких-то законов, запрещающих увольнять тех, кто плохо работает. А в Германии такие законы есть, поэтому там некоторые люди этим пользуются. В США кто не работает, тот не ест, как говорится.
Поэтому в Америке есть система пипов (PIP). Не уверена, что это есть во всех компаниях, но некоторые этим прям славятся. PIP - это performance improvement plan. Если ревью получился так себе, прежде чем человека увольняют, его ставят в известность о том, что качество его работы не соответствует ожиданиям и дают план действий, как это исправить. Обычно дается месяц-два на это. Некоторые справляются и их не увольняют. Но тут надо понимать, что это остается в истории, никто не забыт, ничто не забыто. Поэтому это сильно плохо для карьерного роста в данной компании. Т.е. о росте зарплаты и продвижении можно забыть на пару тройку лет. Также в случае сокращений такой человек в числе первых кандидатов на увольнение. Это может негативно повлиять на визовый процесс, который может быть просто приостановлен на какой-то срок.
Такая система с одной стороны позволяет отсеивать бездельников, но с другой стороны вынуждает сотрудников заниматься тем, что хорошо для их ревью, а не тем, что хорошо для компании. Например, разработчики могут изобрести велосипед, продвинуть эту идею и получить повышение как якобы за инновацию. А потом, через несколько лет, другие разработчики придут и начнут переписывать все с нуля, потому то, как сделан проект, изначально было делать нельзя, потому что это подразумевало бы затраты на поддержку этого велосипеда. А его никто не поддерживал, теперь он безнадежно устарел, он не масштабируем, он медленно и плохо работает. Но кто-то уже получил промоушен.