В эту пятницу в 17 часов по Москве поговорим про собеседования в большие компании с ребятами из g-mate. Я расскажу про свой опыт с Яндексом, Toptal и Facebook и постараюсь дать рекомендации, которые вы сразу сможете применить на следующем собеседовании. Вебинар будет длиться всего час, так что плотность информации будет высокой. Регистрируйтесь!

Ещё я давно хотел сделать форму для вопросов и актуальных тем, чтобы у канала была более широкая повестка. Вот она: предложить тему для обсуждения.

Ответить подробно на большинство вопросов мне наверное не удастся, потому что вебинар короткий, но я обязательно коснусь каждого в постах на канале. Буду благодарен за ваши идеи и предложения!

Нашёл классный ресурс с “дорожными картами” для разработчиков: https://roadmap.sh/
Особенно полезно и интересно будет тем, кто только начинает или недавно начал, либо тем, кто меняет специализацию. Конечно, это не полная энциклопедия всех возможных навыков (кайф начинается, когда совмещаются специализации - например, backend и devops), но вам наверняка будет интересно сравнить свои знания с commmunity-driven эталоном.

Как разработчику успешно пройти собеседования в FAANG

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

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

📝 Делайте резюме под каждую позицию. Упоминайте только релевантный опыт, а для позиций уровня senior и выше описывайте не только свои достижения в разработке, но и в организации командной работы и найме, достижении бизнес-целей.

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

👩‍💻 Подготовьте связный рассказ о себе и своём опыте. Он точно пригодится на поведенческих интервью, а сокращённая версия с примерами успешных проектов и вашими пожеланиями к новой работе - для вводного рассказа о себе на каждой секции. Репетируйте вслух и с диктофоном.

🦾 Отведите несколько месяцев на подготовку к алгоритмическим задачам. Прорешайте не меньше 30-50 задач на Leetcode по разным темам, найдите или придумайте обобщённый алгоритм решения задач и придерживайтесь его. Старайтесь начинать писать код только когда алгоритм решения задачи известен, включая edge-кейсы и его сложность.

📣 Говорите во время решения задач. То, как вы размышляете, не менее важно, чем то, насколько быстро и верно вы находите решение задачи. Ведите диалог с собеседующим, чтобы получать постоянную обратную связь. Если вы не уверены, уточните, что правильно поняли задачу.

⚙️ На system design интервью обозначьте общую архитектуру решения и постарайтесь углубиться в область, в которой вы разбираетесь лучше всего. Ведите себя как техлид, уточняющий требования у заказчика, и двигайтесь от общего к частному. Держите в голове план решения задачи и следите за временем.

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

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

💰 Собеседуйтесь в несколько компаний и старайтесь получить несколько оферов. Это поможет торговаться (в пределах рынка и вилки зарплат на данной позиции) и чувствовать себя спокойнее. Будьте открыты к предложениям рекрутеров, держите их в курсе процесса и сообщайте о получении других оферов.

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

Ну и напоследок: не рвитесь исключительно в FAANG только ради строчки в резюме. Лучше оказаться на своём месте в небольшой компании, делать что-то важное, развиваться и иметь слово в принятии решений, чем быть винтиком в большом корпоративном механизме. Удачи!

#вслух

Все мы в существенной степени "продукт среды". Например, я после 9 класса думал не как закончить 10-11 класс получше и поступить в хороший университет, а о том, как бы побыстрее сбежать из школы и начать наконец зарабатывать. Это в 13-14 лет-то! Среда была такая - вечная нужда во всём, привычка выживать. Ну и пошёл настраивать компьютеры, барыжил железками на радиорынке.

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

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

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

Грубо говоря, у среднего подростка должно быть больше шансов вырасти не наркоманом (пытался подобрать не пошлый синоним слову "успешный", но не смог), а у среднего программиста - узнать, каково это - работать в любой компании или жить в другой стране - и решить, что делать.

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

Не боги горшки обжигают

Классная фраза из обсуждения к статье, написанной по мотивам нашего с Лёшей вебинара полторы недели назад. Читатель отметил, что код “выпускника” из какого-то техногиганта его вообще не впечатлил. А мне кажется, это вполне логично. Вот мой комментарий:

«Разумеется, в фейсбуках работают обычные люди. Чаще всего они заинтересованные, целеустремлённые и продуктивные (система мотивации "выживает" других, как мне кажется), но далеко не обязательно лучшие инженеры.

Более того, сила техногигантов, на мой взгляд, не в их крутейшем коде (хотя и в нём тоже), а в размере (рынка, прибыли, сотрудников). Гипотетически, я бы нанимал как можно больше людей, чтобы проверять как можно больше идей (на микро- и макро-уровнях, внутри существующих продуктов и как совершенно новые инициативы) — ведь всё равно никто не знает что делать. А тут уже относительно абстрактный показатель качества или чистоты кода не слишком важен — вероятно, код будет выкинут, либо, если идея выстрелит, его потом десять лет будут рефакторить уже другие люди.»

Как обычно, в комментариях интереснее, чем в статье: https://habr.com/ru/company/gms/blog/526366/#comments-list

⏱ Программист и дедлайн

Мы все сталкиваемся с дедлайнами, и мало кому нравится спешить и перерабатывать, чтобы успеть к сроку. Ладно ещё, когда дедлайны привязаны к внешним событиям - запуску проекта или маркетинговой кампании, но ведь иногда проджект-менеджеры или руководители устанавливают их "для порядка", а по факту - для давления на разработку.

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

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

Если вы уже тимлид, включайте политическую смекалку и используйте срочность как аргумент к расширению команды. Активно нанимая, вы научитесь лучше понимать людей и увеличите своё влияние в компании. А команда, нанятая собственноручно, всегда больше уважает, слушает и любит своего руководителя.

Конечно, бывают условия, в которых с жёсткими сроками сделать ничего невозможно - например, в аутсорс-компании, находящейся на грани выживания из-за нестабильного потока заказов. В таких компаниях руководство вынуждено брать новые проекты, ещё не успев (и часто не собираясь) закончить текущие. И программисты нередко оказываются крайними, хоть и переребатывают по глупости руководства - хорошо если за деньги.

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

Как дела со сроками обстоят у вас в проекте?

Наткнулся на классную рассылку “Career Advice for Tech Professionals”. Например:

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

Я сам только что подписался, но тематика и подача (с симпатичными графиками) мне уже нравится. Если читаете на английском, рекомендую.

Если вы ищите, искали или собираетесь искать удалённую работу разработчиком в зарубежной компании, и у вас есть какие-то вопросы, напишите в личку @oleggromov - с радостью поговорю о вашем опыте и попробую помочь.

А если вы вдруг не читали мои статьи про поиски работы, вот они:
- Как найти удалённую работу за доллары
- Как пройти собеседования на удалёнку за рубеж
- Как торговаться на собеседованиях

Объясню, почему спрашиваю: я сделал Quiken, расширение для хрома, которое помогает учить английский. Практически сразу после публикации в сторе, гугл распубликовал его, потому что у меня нет странички privacy policy. Я её сделаю и обязательно опубликую расширение снова, а сейчас любопытно узнать, нужно ли поддержать ещё какие-то браузеры.

А вообще расширения для хрома - это как телеграм-боты. Их легко делать в одиночку: можно придумать кучу функций, где вообще не нужен бэкенд, а данные можно хранить в Web Storage или IndexedDB прям на клиенте.

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

Владение кодом

В прошлом гостевом посте Виктор давал советы о том, как пройти собеседования в FAANG и другие крупные компании. А что будет после принятия офера? Как преуспеть в корпорации и построить успешную карьеру разработчика?
Придётся упорно трудиться, прокачивать навыки коммуникации, учиться понимать продукт и его пользователей. И конечно, писать понятный, поддерживаемый и надёжный код. Но не только 😜

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

Я работаю в Фейсбуке в Лондоне. До этого — Toptal, Klarna, Яндекс.
Несмотря на очевидную специализацию, каждый день мне приходится взаимодействовать с разными системами, написанными на TypeScript, React, Electron, CG/SQL, C++, Hack/PHP. Кроме использования совершенно разных платформ и языков, нужно хотя бы поверхностно разобраться со всеми компонентами стека, а ещё лучше — понять архитектуру всей системы и детали реализации.

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

Раз так, почему крупные компании не поощряют strong code ownership, когда за развитие и надёжность каждого модуля отвечает отдельный человек? Разработчики были бы счастливы, код был бы чист, а техдолг канул бы в небытие.

Тем не менее, за 15 лет моей карьеры — столько же прошло с момента публикации Фаулером классической статьи про code ownership — ни в одной из компаний я не сталкивался с единоличным владением кодом. Каким бы естественным ни казался такой подход начинающим разработчикам, бизнес стремится уменьшить риски при потере ключевых сотрудников — чем больше людей знает, как работает система — тем лучше.

Можно подобрать и исключения. Например, библиотечный код: важные для архитектуры сервисы и модули, которые обычно создаются и поддерживаются отдельными командами, но не конкретными людьми. По Фаулеру, это не единоличное владение кодом, а скорее weak code ownership, когда за систему и код отвечает группа разработчиков.

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

А как в Facebook?
В Фейсбуке любой программист может изменить любой нужный ему кусок кода любой системы. В лучшем случае, он запросит ревью у «авторов», но в некоторых случаях обойдётся и без него. Авторство в такой системе постоянно меняется, и ревьюерами становятся те, кто внёс больше всего изменений в код, либо сделал это последним.

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

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

Главный навык
Получается, главный навык программиста в современной крупной компании с shared code ownership — не просто писать понятный, поддерживаемый и надёжный код, но и обязательно уметь делать это внутри любой системы, даже той, которую он видит впервые. А свой код проектировать максимально очевидным образом, чтобы будущие изменения минимально влияли на архитектуру и непротиворечивость.

А как организовано владение кодом у вас в проекте? Поделитесь в комментариях.

Это гостевой пост на канале. Если вы тоже хотите поделиться опытом — напишите мне в @winterview_contact_bot

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

Недавно наткнулся на список русскоязычных подкастов про IT и был приятно удивлён количеством 🙂 Что-то слушаете уже? Посоветуйте.

Самые интересные посты с апреля по декабрь 2020

Пока собирал тексты, которые буду публиковать на сайте, подумал, что вы могли что-то пропустить, и собрал всё самое интересное в список.

1. Почему программистом быть хорошо
2. Случай на удалёнке
3. Из офиса в океан
4. Почему быть программистом — отстой
5. Вслух: сложная штука этот софт
6. Я не смотрел «Кремниевую Долину» Дудя
7. Траектория и риски в карьере и вторая часть текста
8. Две недели без кофеина ☕️
9. Месяц без кофеина
10. Проклятие знания наоборот
11. Move Fast and Break Things 🤯
12. Я променял прекрасные статичные сайты на Django-монстра 😱
13. Про мотивацию и impact в Фейсбуке
14. Зачем программисту копаться в мозгах
15. Сразу в продакшн
16. Как я целеполаганием прокрастинацию победил
17. Как разработчику пройти собеседования в FAANG
18. Вслух: все мы продукт среды
19. Программист и дедлайн
20. Code ownership и главный навык разработчика

Поделитесь ссылкой на этот пост с друзьями, если какая-то тема кажется вам интересной. Хорошего воскресенья!

Важнее всего люди 🤝

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

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

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

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

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

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

В общем, одни плюсы для всех. А какие отношения у вас с руководителем и/или подчинёнными?

Фейсбук сломался - и это ожидаемо

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

Я тоже так думал долгое время, но с годами интуитивно всё чаще избегал и даже активно противостоял сложности в проектировании и реализации программных систем. Сформировалось профессиональное чутьё, идеальное отражающее “закон Мёрфи”: если что-то может пойти не так, оно пойдёт не так.

Но оставалось глубокое неприятие: как же так, стараемся, проектируем и планируем, тратим кучу времени и денег, а получается всё равно говно, которое гарантированно сломается. Что же мы все делаем не так?

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

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

Поделитесь постом с друзьями, которым приходилось исправлять баги там, где их не должно было быть 😁

Не успели мы удивиться поломке фейсбука, сдохли и сервисы гугла - ютуб, docs, gmail и прочие. Смешнее всего то, что дашборд состояния их сервисов был весь зелёный первые минут 20 поломки, и только сейчас покраснел. Как будто бы кто-то руками перевёл его в аварийное состояние.