Про RSU и опционы
Знакомые попросили написать несколько слов про RSU и опционы для статьи. Не уверен, что этот и без того короткий текст будет опубликован целиком - поэтому делюсь им с вами.
Многие крупные состоявшиеся компании, например Яндекс или Фейсбук, предлагают разработчикам RSU - restricted stock units, в простонародье "акции".
В отличие от опционов, которые позволяют купить акции компании по фиксированной в контракте цене, RSU выдаются бесплатно. Их выдают грантами, обычно привязанными к оговоренной денежной сумме, которые переходят в собственность (vesting) равными долями, обычно в течение 4 лет.
Например, в вашем офере может быть оговорен RSU-грант, эквивалентный $100,000. В момент выдачи гранта, если акция стоит $100, вам достанется пакет из 1000 акций.
Самое распространённое расписание вестинга будет такое, что через 1 год (cliff) вы сможете распоряжаться 1/4 частью акций, а дальше, каждый квартал, ещё 1/16 частью. Обычно их либо продают сразу, либо оставляют в надежде на рост - тогда придётся заплатить налог на рост активов (capital gains tax), если акции вырастут.
RSU проще в обращении и обычно предсказуемее опционов. Фактически, RSU - это дополнительный бонус, привязанный к стоимости акций публичной компании. Его всегда можно продать, даже по более низкой цене, чем в момент выдачи.
Опцион - скорее лотерейный билет. Часто его выдают на акции компании, которая ещё не вышла на биржу. Даже если компания публичная, стоимость акций может оказаться ниже стоимости покупки, и тогда опцион нет смысла использовать. Также на акции, полученные через опцион, обычно сложнее заплатить налог.
@gromov_com
Знакомые попросили написать несколько слов про RSU и опционы для статьи. Не уверен, что этот и без того короткий текст будет опубликован целиком - поэтому делюсь им с вами.
Многие крупные состоявшиеся компании, например Яндекс или Фейсбук, предлагают разработчикам RSU - restricted stock units, в простонародье "акции".
В отличие от опционов, которые позволяют купить акции компании по фиксированной в контракте цене, RSU выдаются бесплатно. Их выдают грантами, обычно привязанными к оговоренной денежной сумме, которые переходят в собственность (vesting) равными долями, обычно в течение 4 лет.
Например, в вашем офере может быть оговорен RSU-грант, эквивалентный $100,000. В момент выдачи гранта, если акция стоит $100, вам достанется пакет из 1000 акций.
Самое распространённое расписание вестинга будет такое, что через 1 год (cliff) вы сможете распоряжаться 1/4 частью акций, а дальше, каждый квартал, ещё 1/16 частью. Обычно их либо продают сразу, либо оставляют в надежде на рост - тогда придётся заплатить налог на рост активов (capital gains tax), если акции вырастут.
RSU проще в обращении и обычно предсказуемее опционов. Фактически, RSU - это дополнительный бонус, привязанный к стоимости акций публичной компании. Его всегда можно продать, даже по более низкой цене, чем в момент выдачи.
Опцион - скорее лотерейный билет. Часто его выдают на акции компании, которая ещё не вышла на биржу. Даже если компания публичная, стоимость акций может оказаться ниже стоимости покупки, и тогда опцион нет смысла использовать. Также на акции, полученные через опцион, обычно сложнее заплатить налог.
@gromov_com
Есть ли у вас сайд-проекты?
Anonymous Poll
17%
Да (кидайте ссылки в комментарии)
43%
Не хватает времени, но хотелось бы
3%
Нет, а зачем?
9%
Нет, мне и так кодинга хватает
28%
Посмотреть результаты
Зачем компания давать тестовые задания, а нам — тратить время на них?
На этот пост меня натолкнул текст в канале Стой под стрелой про булшит-детектор. В конце автор пишет, что пост не про тестовые задания, и я с ним согласен: полезно и важно понимать, зачем мы делаем что-либо в принципе. А повторять за кем-то, становясь последователем карго-культа, глупо.
Но написать хочу про тестовые задания на собеседованиях.
Я отсобеседовал сотни человек, в Яндекс и Топтал, и просмотрел тысячи резюме. Подходящих кандидатов - уж не знаю, почему - действительно мало. В то же время, я часто встречаю в сети скепсис по поводу тестовых заданий: нафиг мне, крутану, чей час стоит $100, выполнять задания?
Простой ответ на этот вопрос: потому что мне нравится ваша компания, продукт, команда - и я хочу с вами работать. В таком случае задания и вам полезны: присмотритесь к компании, к людям, задающим вопросы. Не понравилось - до свидания, почему нет? Иначе это как жаловаться на трату времени на первые свидания.
Если же вы откликаетесь на десятки вакансий, тратить на домашние задания по несколько часов - скорее всего, непозволительная роскошь. Но это вопрос к вам: зачем вы откликаетесь на столько позиций?
А компании? Зачем они дают тестовые задания и просят писать код на собеседовании? Неужели недостаточно гитхаба, опыта и рекомендаций?
Про гитхаб. У большинства кандидатов, которых я видел, ничего интересного в профиле нет. У существенной части гитхаб-аккуанты просто пустые. Это, кстати, отсылка к необходимости быть публичным, заниматься сайд-проектами - чтобы было что показать и о чём рассказать.
Опыт, особенно заявленный в резюме, обычно никак не проверить. Задавая каверзные вопросы на собеседовании, удаётся узнать, что человек на самом деле делал, чему научился. Нередко в резюме заявлено, что кандидат сделал проект с нуля, добился выдающихся результатов, а во время расспросов выясняется, что это ребята бэкенд на PHP писали, а он рядом стоял. Это, кстати, тоже сигнал - скорее всего, такого не наймут.
Рекомендации? Может и можно выяснить важные подробности об опыте и навыках кандидата через рекомендации. Но на практике я такого не встречал. Максимум, на что идёт большинство компаний - это проверка факта трудоустройства. А такого, чтоб звонить прошлым коллегам и руководителям и расспрашивать про бывшего коллегу, нет.
Да и сколько людей будут помнить достаточно много и хорошо, а ещё будут готовы поделиться честным фидбэком? А что делать с ситуациями, когда кандидат не делится с текущим начальством планами о смене работы?
Вообще смысл тестовых заданий шире проверки навыка писать код или решать алгоритмические задачки. Важно не только какой код был написан, а ещё и почему, какие варианты решения задачи кандидат рассматривал, на какие компромиссы пошёл.
Это и проверка на внимательность: сложно сосчитать, сколько раз я видел людей, решающих не ту задачу на собеседовании - несмотря не проговоренные условия и заданные вопросы.
В конце концов, важно уметь рассказать про то, что вы сделали. Начать от общего и идти к частному, объяснить свой образ мышления, упомянуть проблемы, которых вы изначально не учли, а также решения, которые вы приняли, и их возможные последствия.
Если я нанимаю вас в свою команду, и нам потом работать вместе несколько лет, мне важно, чтобы вы могли объяснить, пусть и не всегда технически корректно, что происходит в коде, почему архитектура именно такая, как это всё подстроится под новые требования и заработает под нагрузкой (пресловутое О-большое). Насколько ваш код понятен другим - и что вы сделали, чтобы он был понятным.
Поэтому тестовые задания и нужны компаниям. Конечно, лучше знать ответ на вопрос "зачем мы даём тестовое задание". Но даже если в какой-то команде не могут внятно этого проговорить (ну точно софт-скиллов не хватило), это не означает автоматически, что опытные интервьюеры не считывают эти сигналы неосозанно.
А если стремиться сделать найм максимально объективным и исключающим false positives, получатся FAANG-style собеседования, с десятком секций, кучей стресса и непонятными отказами.
На этот пост меня натолкнул текст в канале Стой под стрелой про булшит-детектор. В конце автор пишет, что пост не про тестовые задания, и я с ним согласен: полезно и важно понимать, зачем мы делаем что-либо в принципе. А повторять за кем-то, становясь последователем карго-культа, глупо.
Но написать хочу про тестовые задания на собеседованиях.
Я отсобеседовал сотни человек, в Яндекс и Топтал, и просмотрел тысячи резюме. Подходящих кандидатов - уж не знаю, почему - действительно мало. В то же время, я часто встречаю в сети скепсис по поводу тестовых заданий: нафиг мне, крутану, чей час стоит $100, выполнять задания?
Простой ответ на этот вопрос: потому что мне нравится ваша компания, продукт, команда - и я хочу с вами работать. В таком случае задания и вам полезны: присмотритесь к компании, к людям, задающим вопросы. Не понравилось - до свидания, почему нет? Иначе это как жаловаться на трату времени на первые свидания.
Если же вы откликаетесь на десятки вакансий, тратить на домашние задания по несколько часов - скорее всего, непозволительная роскошь. Но это вопрос к вам: зачем вы откликаетесь на столько позиций?
А компании? Зачем они дают тестовые задания и просят писать код на собеседовании? Неужели недостаточно гитхаба, опыта и рекомендаций?
Про гитхаб. У большинства кандидатов, которых я видел, ничего интересного в профиле нет. У существенной части гитхаб-аккуанты просто пустые. Это, кстати, отсылка к необходимости быть публичным, заниматься сайд-проектами - чтобы было что показать и о чём рассказать.
Опыт, особенно заявленный в резюме, обычно никак не проверить. Задавая каверзные вопросы на собеседовании, удаётся узнать, что человек на самом деле делал, чему научился. Нередко в резюме заявлено, что кандидат сделал проект с нуля, добился выдающихся результатов, а во время расспросов выясняется, что это ребята бэкенд на PHP писали, а он рядом стоял. Это, кстати, тоже сигнал - скорее всего, такого не наймут.
Рекомендации? Может и можно выяснить важные подробности об опыте и навыках кандидата через рекомендации. Но на практике я такого не встречал. Максимум, на что идёт большинство компаний - это проверка факта трудоустройства. А такого, чтоб звонить прошлым коллегам и руководителям и расспрашивать про бывшего коллегу, нет.
Да и сколько людей будут помнить достаточно много и хорошо, а ещё будут готовы поделиться честным фидбэком? А что делать с ситуациями, когда кандидат не делится с текущим начальством планами о смене работы?
Вообще смысл тестовых заданий шире проверки навыка писать код или решать алгоритмические задачки. Важно не только какой код был написан, а ещё и почему, какие варианты решения задачи кандидат рассматривал, на какие компромиссы пошёл.
Это и проверка на внимательность: сложно сосчитать, сколько раз я видел людей, решающих не ту задачу на собеседовании - несмотря не проговоренные условия и заданные вопросы.
В конце концов, важно уметь рассказать про то, что вы сделали. Начать от общего и идти к частному, объяснить свой образ мышления, упомянуть проблемы, которых вы изначально не учли, а также решения, которые вы приняли, и их возможные последствия.
Если я нанимаю вас в свою команду, и нам потом работать вместе несколько лет, мне важно, чтобы вы могли объяснить, пусть и не всегда технически корректно, что происходит в коде, почему архитектура именно такая, как это всё подстроится под новые требования и заработает под нагрузкой (пресловутое О-большое). Насколько ваш код понятен другим - и что вы сделали, чтобы он был понятным.
Поэтому тестовые задания и нужны компаниям. Конечно, лучше знать ответ на вопрос "зачем мы даём тестовое задание". Но даже если в какой-то команде не могут внятно этого проговорить (ну точно софт-скиллов не хватило), это не означает автоматически, что опытные интервьюеры не считывают эти сигналы неосозанно.
А если стремиться сделать найм максимально объективным и исключающим false positives, получатся FAANG-style собеседования, с десятком секций, кучей стресса и непонятными отказами.
Заказал я на одном популярном сайте авиабилеты. Данные пассажира выбрал из выпадашки: сайтом я пользовался уже когда-то. Мои данные там сохранены, включая номер заграна - они же и показались в менюшке, а в форме показались только имя-фамилия.
Проходит пара дней, мне падает на почту посадочный. А в нём номер моего российского паспорта - для нескольких международных перелётов. Ну как так, я же точно выбирал свой загран! Хорошо, до полётов ещё несколько дней, есть шанс всё исправить.
Захожу проверить себя, выбираю новые билеты - и точно, в выпадашке моё имя с правильными данными заграна. А вот в личном кабинете, в “Записной книжке” (тут активные путешественники угадали, о каком сайте речь) два пассажира сохранено: имя, фамилия, всё-всё-всё одинаковое, моё - но у одного российский паспорт, а у другого загран.
И тут уже не важно, в каком месте баг - в UI, в бэкенде, в неоднозначном контракте их взаимодействия. Важно, что кто-то просто не подумал, причём, наверняка, несколько разных человек.
Не удивился фронтендер, что разные паспорта одного пассажира схлопываются до последнего. Не подумал бэкендер: а что сделать ключом в табличке и какие данные отдать через API. Не подумал QA или тестировщик, что у человека может быть не один, а два, три и даже больше разных паспортов.
PM на всё это просто махнул рукой, потому что сайту авиабилетов оптимизировать надо предложения страховок и отелей, чтобы заработать. Только руководитель саппорта удивился, что после обновления интерфейса количество тикетов у его команды выросло на пару процентов.
Это, конечно, только мои предположения: реальную причину бага и ситуацию в команде я не знаю. Но что-то из этого вполне может оказаться правдой.
Поэтому даже “перекладывать джейсоны” или “делать круды” важно где. Если вам интересна предметная область, и вы с вниманием и интересом относитесь к работе, у вас есть все шансы порадовать сотни и тысячи других людей. Или, как минимум, поберечь их нервы.
Проходит пара дней, мне падает на почту посадочный. А в нём номер моего российского паспорта - для нескольких международных перелётов. Ну как так, я же точно выбирал свой загран! Хорошо, до полётов ещё несколько дней, есть шанс всё исправить.
Захожу проверить себя, выбираю новые билеты - и точно, в выпадашке моё имя с правильными данными заграна. А вот в личном кабинете, в “Записной книжке” (тут активные путешественники угадали, о каком сайте речь) два пассажира сохранено: имя, фамилия, всё-всё-всё одинаковое, моё - но у одного российский паспорт, а у другого загран.
И тут уже не важно, в каком месте баг - в UI, в бэкенде, в неоднозначном контракте их взаимодействия. Важно, что кто-то просто не подумал, причём, наверняка, несколько разных человек.
Не удивился фронтендер, что разные паспорта одного пассажира схлопываются до последнего. Не подумал бэкендер: а что сделать ключом в табличке и какие данные отдать через API. Не подумал QA или тестировщик, что у человека может быть не один, а два, три и даже больше разных паспортов.
PM на всё это просто махнул рукой, потому что сайту авиабилетов оптимизировать надо предложения страховок и отелей, чтобы заработать. Только руководитель саппорта удивился, что после обновления интерфейса количество тикетов у его команды выросло на пару процентов.
Это, конечно, только мои предположения: реальную причину бага и ситуацию в команде я не знаю. Но что-то из этого вполне может оказаться правдой.
Поэтому даже “перекладывать джейсоны” или “делать круды” важно где. Если вам интересна предметная область, и вы с вниманием и интересом относитесь к работе, у вас есть все шансы порадовать сотни и тысячи других людей. Или, как минимум, поберечь их нервы.
Баланс между порядком и хаосом
Стабильность работы в больших компаниях часто противопоставляют риску, связанному с предпринимательством. Причём иногда это выглядит так, будто бы гарантированная зарплата и понятная работа на следующие N лет - это однозначно хорошо, а вероятность ошибиться, делая что-то своё (или по-своему) - это однозначно плохо.
При этом кажется, что люди моего поколения и старше особенно часто склоняются к стабильности и предсказуемости. Моя гипотеза такова, что после хаоса 90-х (и, с натяжкой, вообще последней сотни лет) сложно отказаться от скучной, но сытой жизни в пользу каких-то неясных перспектив и приключений.
Конечно, есть личные предпочтения. Мне нравятся приключения и риск, которые в экономической деятельности ассоциируются с предпринимательством, а кому-то больше по душе размеренная и понятная жизнь без лишнего стресса. Ничто не лучше и не хуже.
Но, экстраполируя дихотомию стабильности и непредсказуемости на жизнь в общем, мы сталкиваемся с вопросом: сколько порядка и хаоса должно быть в жизни?
На этот вопрос хорошо ответил мой любимый Джордан Питерсон (если вы относитесь к его позиции скептически, посмотрите записи его лекций из университета - они намного глубже, интереснее и, в некотором смысле, нейтральнее, чем его политические взгляды). Он коснулся сразу нескольких связанных с этим идей, о которых я кратко расскажу.
Единственное, что постоянно в жизни любого человека, вне зависимости от его положения, места и времени жительства и занятия, это некий (дис)баланс между хаосом и порядком.
В восточной традиции этот баланс обозначется символом Инь-Ян. При этом порядок легко перетекает в хаос и наоборот: неудивительно, что даже кажущиеся стабильными карьеры и семьи рушатся в один момент, в то время как из хаоса, или из ничего, всё время возникают новые системы - отношения, компании и идеи.
Ещё интереснее идея Пути, или Дао. Правильным и желаемым положением для любого человека является идеальный баланс между порядком и хаосом, линия, разделяющая чёрное и белое в Инь-Ян.
Даже нервная система человека эволюционировала таким образом, чтобы максимально точно выделять в жизни ситуации идеального баланса: в таких обстоятельствах наша деятельность максимально интересует и вовлекает - и контролировать это ощущение сознательно, по-видимому, невозможно.
Советский психолог Выготский, тёзка моего сына, сформулировал те же идеи в своей теории Зоны ближайшего развития - если у вас есть дети, вы наверняка слышали о ней. Но вот что мне было неизвестно до знакомства с Питерсоном, это то, что эту концепцию можно применить к любому обучению, в том числе взрослых. Что, вероятно, и ввёл в обиход психолог Чиксентмихайи своими идеями про состояния Потока.
Оказываясь в ситуации полного порядка и предсказуемости, например, в корпорации или по какой-то причине слепо следуя догмам и правилам, человек легко превращается в бездушного раба. Это дословный перевод слов Питерсона (soulless slave) - очень неожиданно и приятно, что я обнаружил подтверждение идеям из книги Disciplined Minds в его лекции.
Полный хаос, отказ от социальной жизни и отсутствие каких-либо внешних структур - отношений, распорядка дня, обязательств и правил - могут вынести лишь единицы. Для большинства же из нас такие ситуации чреваты проблемами со сном и пищевым поведением, депрессией и ощущением постоянного стресса, даже террора.
Вывод простой и, как мне кажется, радостный: у каждого человека ещё с рождения есть точно откалиброванный инструмент для оценки своего положения и занятия.
Если вам интересно, и вы с полной отдачей вовлекаетесь в дело, наверняка вы находитесь в оптимальном для себя месте и занимаетесь чем-то стоящим. Если вам скучно, вы становитесь циничными и теряете эмоциональную связь с происходящим, вероятно, ваша жизнь стала слишком стабильной.
В большинстве случаев этот баланс будет временным, и нужно постоянно прислушиваться к себе, чтобы поддерживать его в правильном состоянии.
Стабильность работы в больших компаниях часто противопоставляют риску, связанному с предпринимательством. Причём иногда это выглядит так, будто бы гарантированная зарплата и понятная работа на следующие N лет - это однозначно хорошо, а вероятность ошибиться, делая что-то своё (или по-своему) - это однозначно плохо.
При этом кажется, что люди моего поколения и старше особенно часто склоняются к стабильности и предсказуемости. Моя гипотеза такова, что после хаоса 90-х (и, с натяжкой, вообще последней сотни лет) сложно отказаться от скучной, но сытой жизни в пользу каких-то неясных перспектив и приключений.
Конечно, есть личные предпочтения. Мне нравятся приключения и риск, которые в экономической деятельности ассоциируются с предпринимательством, а кому-то больше по душе размеренная и понятная жизнь без лишнего стресса. Ничто не лучше и не хуже.
Но, экстраполируя дихотомию стабильности и непредсказуемости на жизнь в общем, мы сталкиваемся с вопросом: сколько порядка и хаоса должно быть в жизни?
На этот вопрос хорошо ответил мой любимый Джордан Питерсон (если вы относитесь к его позиции скептически, посмотрите записи его лекций из университета - они намного глубже, интереснее и, в некотором смысле, нейтральнее, чем его политические взгляды). Он коснулся сразу нескольких связанных с этим идей, о которых я кратко расскажу.
Единственное, что постоянно в жизни любого человека, вне зависимости от его положения, места и времени жительства и занятия, это некий (дис)баланс между хаосом и порядком.
В восточной традиции этот баланс обозначется символом Инь-Ян. При этом порядок легко перетекает в хаос и наоборот: неудивительно, что даже кажущиеся стабильными карьеры и семьи рушатся в один момент, в то время как из хаоса, или из ничего, всё время возникают новые системы - отношения, компании и идеи.
Ещё интереснее идея Пути, или Дао. Правильным и желаемым положением для любого человека является идеальный баланс между порядком и хаосом, линия, разделяющая чёрное и белое в Инь-Ян.
Даже нервная система человека эволюционировала таким образом, чтобы максимально точно выделять в жизни ситуации идеального баланса: в таких обстоятельствах наша деятельность максимально интересует и вовлекает - и контролировать это ощущение сознательно, по-видимому, невозможно.
Советский психолог Выготский, тёзка моего сына, сформулировал те же идеи в своей теории Зоны ближайшего развития - если у вас есть дети, вы наверняка слышали о ней. Но вот что мне было неизвестно до знакомства с Питерсоном, это то, что эту концепцию можно применить к любому обучению, в том числе взрослых. Что, вероятно, и ввёл в обиход психолог Чиксентмихайи своими идеями про состояния Потока.
Оказываясь в ситуации полного порядка и предсказуемости, например, в корпорации или по какой-то причине слепо следуя догмам и правилам, человек легко превращается в бездушного раба. Это дословный перевод слов Питерсона (soulless slave) - очень неожиданно и приятно, что я обнаружил подтверждение идеям из книги Disciplined Minds в его лекции.
Полный хаос, отказ от социальной жизни и отсутствие каких-либо внешних структур - отношений, распорядка дня, обязательств и правил - могут вынести лишь единицы. Для большинства же из нас такие ситуации чреваты проблемами со сном и пищевым поведением, депрессией и ощущением постоянного стресса, даже террора.
Вывод простой и, как мне кажется, радостный: у каждого человека ещё с рождения есть точно откалиброванный инструмент для оценки своего положения и занятия.
Если вам интересно, и вы с полной отдачей вовлекаетесь в дело, наверняка вы находитесь в оптимальном для себя месте и занимаетесь чем-то стоящим. Если вам скучно, вы становитесь циничными и теряете эмоциональную связь с происходящим, вероятно, ваша жизнь стала слишком стабильной.
В большинстве случаев этот баланс будет временным, и нужно постоянно прислушиваться к себе, чтобы поддерживать его в правильном состоянии.
Полезные для фронтендеров алгоритмы
Когда-то у меня были сложные отношения с алгоритмами и вообще математикой. Классе в 8-м, уже увлекаясь программированием, я пришёл в какой-то кружок, где нам задали задачку: нарисовать треугольник Паскаля.
Я тогда вовсю ковырял С++ со справочником Страуструпа, но в алгоритмах ничего не понимал. Как решить задачку, я так и не сообразил - и в кружок ходить перестал. Хотя позже, уже в колледже, несколько раз ездил на олимпиады по программированию в составе команды. Мы даже привезли одну или две медали за призовые места, соревнуясь не только с колледжами, но и вузами юга России.
На олимпиадах мы решали литкод-подобные задачки (скучно) и писали алгоритмы для танчиков и самолётиков, сражающихся друг с другом (кайф). Разделение обязанностей в команде было такое: я (быстрее всех) писал код на С++, а пара других ребят выдумывала алгоритмы.
Следующие лет 10 про алгоритмы я не думал и редко сталкивался с ними в работе. Только готовясь к собеседованиям в фейсбук, прорешал штук 50 задач на литкоде. Стало понятно, почему спортивное программирование и задачки так увлекают многих: в какой-то момент, после преодоления первого сопротивления, приходит азарт и интерес - как же решить проблему максимально элегантно, понятно и эффективно?
Сейчас я считаю, что понимать базовые алгоритмы и структуры данных обязательно для любого программиста. Это как с музыкой: не важно, умеет ли музыкант читать ноты и писать аранжировки - он всё равно это делает, занимаясь музыкой. А если мы уже используем алгоритмы в работе, то почему бы не поучиться им хотя бы чуть-чуть?
Поэтому я задумал доклад про полезные алгоритмы для фронтендеров. Содержание будет примерно следующее:
— Алгоритмы обхода деревьев: BFS, DFS, рекурсивные и итеративные версии
— Подобные алгоритмы для древоподобных структур - вложенных массивов и словарей, сравнения, копирования и прочих операций с ними
— Сериализация и десериализация (парсинг): от CSV и JSON до HTML, JSX и Markdown, включая несериализуемые объекты и элементарный поиск циклов (в графе ссылок)
— Битовые операции и их приложение к компактным форматам (кстати, написал недавно библиотечку для упаковки boolean и integer значений в 32-битные числа) вроде Base64 и protobuf
Это то, что точно должно поместиться в получасовой обзорный доклад для конференции.
В дополнение хочу коснуться:
— Конечных автоматов для более элегантного парсинга и безглючной работы со сложными стейтами
— Элементарных алгоритмов поиска и сортировки
— Типовых алгоритмов на строках и массивах
Эти темы сложнее: не уверен, что смогу и успею раскрыть их в рамках доклада, и польза от них как будто бы ниже в приложении к day-to-day работе.
А вы что скажете? С какими алгоритмами приходилось сталкиваться во фронтенде и вебе?
Когда-то у меня были сложные отношения с алгоритмами и вообще математикой. Классе в 8-м, уже увлекаясь программированием, я пришёл в какой-то кружок, где нам задали задачку: нарисовать треугольник Паскаля.
Я тогда вовсю ковырял С++ со справочником Страуструпа, но в алгоритмах ничего не понимал. Как решить задачку, я так и не сообразил - и в кружок ходить перестал. Хотя позже, уже в колледже, несколько раз ездил на олимпиады по программированию в составе команды. Мы даже привезли одну или две медали за призовые места, соревнуясь не только с колледжами, но и вузами юга России.
На олимпиадах мы решали литкод-подобные задачки (скучно) и писали алгоритмы для танчиков и самолётиков, сражающихся друг с другом (кайф). Разделение обязанностей в команде было такое: я (быстрее всех) писал код на С++, а пара других ребят выдумывала алгоритмы.
Следующие лет 10 про алгоритмы я не думал и редко сталкивался с ними в работе. Только готовясь к собеседованиям в фейсбук, прорешал штук 50 задач на литкоде. Стало понятно, почему спортивное программирование и задачки так увлекают многих: в какой-то момент, после преодоления первого сопротивления, приходит азарт и интерес - как же решить проблему максимально элегантно, понятно и эффективно?
Сейчас я считаю, что понимать базовые алгоритмы и структуры данных обязательно для любого программиста. Это как с музыкой: не важно, умеет ли музыкант читать ноты и писать аранжировки - он всё равно это делает, занимаясь музыкой. А если мы уже используем алгоритмы в работе, то почему бы не поучиться им хотя бы чуть-чуть?
Поэтому я задумал доклад про полезные алгоритмы для фронтендеров. Содержание будет примерно следующее:
— Алгоритмы обхода деревьев: BFS, DFS, рекурсивные и итеративные версии
— Подобные алгоритмы для древоподобных структур - вложенных массивов и словарей, сравнения, копирования и прочих операций с ними
— Сериализация и десериализация (парсинг): от CSV и JSON до HTML, JSX и Markdown, включая несериализуемые объекты и элементарный поиск циклов (в графе ссылок)
— Битовые операции и их приложение к компактным форматам (кстати, написал недавно библиотечку для упаковки boolean и integer значений в 32-битные числа) вроде Base64 и protobuf
Это то, что точно должно поместиться в получасовой обзорный доклад для конференции.
В дополнение хочу коснуться:
— Конечных автоматов для более элегантного парсинга и безглючной работы со сложными стейтами
— Элементарных алгоритмов поиска и сортировки
— Типовых алгоритмов на строках и массивах
Эти темы сложнее: не уверен, что смогу и успею раскрыть их в рамках доклада, и польза от них как будто бы ниже в приложении к day-to-day работе.
А вы что скажете? С какими алгоритмами приходилось сталкиваться во фронтенде и вебе?
Как я прошёл собеседования в стартап
Я скоро выхожу на новую работу в стартап. Там я буду отвечать за весь фронтенд сервиса, похожего по смыслу на гугл-аналитику - личный кабинет с дашбордами, графиками, служебными страницами.
Сегодня я расскажу, как проходили собеседования и что мне, вероятно, помогло их пройти.
Ребята нашли меня на LinkedIn и, в отличие от десятков других сообщений, которые я получаю, это привлекло тем, что написал мне лично CEO. К тому моменту я уже решил, что буду уходить из Фейсбука, и предложение от стартапа, а не очередного амазона пришлось как нельзя кстати.
В начале мы созвонились с помощником CEO и поговорили про мои планы и то, кто нужен компании и на какую роль. Так как это стартап, мой интерес к продуктовой разработке, предпринимательству и соответствующее отношение к работе, вероятно, подошли под их ожидания. Плюс мы просто мило побеседовали.
В подобном разговоре - по сути, скрининге на адекватность и соответствие ожиданий - важно изложить свою историю и поделиться планами так, чтобы это звучало непротиворечиво, а также быть дружелюбным и расспросить про компанию.
Так как я ничего про Hook не знал, я спросил про количество сотрудников, ближайшие планы, источники финансирования. В конце разговора меня спросили о зарплатных ожиданиях, на что я ответил уклончиво: мол, в Фейсбуке всё равно платят больше - и тогда мне озвучили их вилку. Также я ещё раз уточнил, готовы ли они спонсировать рабочую визу.
После разговора я поискал в сети всех сотрудников компании, включая CEO, посмотрел их выступления и убедился, что история сходится и этим людям, кажется, можно доверять.
Следующим был разговор с CEO. Он очень подробно расспросил меня про планы, включая переход из найма в предпринимательство (да, я вполне открыто об этом заявляю - в стартапе это нормально), а также рассказал о компании и её ценностях, идее продукта и как он к ней пришёл, а также почему она должна полететь. Я очень много спрашивал про продукт, ожидания ко мне и бизнесовые штуки, вроде ключевых моментов в ближайший год, инвесторов, рисков.
На этом этапе стало очевидно, что мы друг другу нравимся и, вероятно, подходим. В дополнение ко всему, Hook делает аналитику для SaaS-компаний - и это классное совпадение. Мне интересны бизнесы с подписочной моделью, а ещё я много работал с аналитикой в Яндексе и кое-что понимаю в ключевых SaaS-метриках и механизмах - привлечении и удержании пользователей, онбординге, экономике.
В конце концов, я рассказал CEO о своих сайд-проектах, как и зачем я их делал, какие проблемы они решают, а также тех самых продуктовых метриках. Думаю, его впечатлило моё упорство в работе над своими проектами, а также понимание продуктовой разработки/аналитики и полного стека веб-технологий, плюс совпадающий опыт.
Потом мне дали тестовое домашнее задание с рекомендацией сделать его за час. Детали задания я раскрывать не буду, но нужно было сделать простое одностраничное веб-приложение - я выбрал React и TypeScript, написал весь код примерно за полтора часа и ещё около получаса подробно расписывал в readme что и почему я сделал, какие были подводные камни, на какие детали я обратил внимание. К репозиторию я дал доступ CTO.
В конце концов, у меня было два собеседования с CTO. На них я рассказал про домашнее задание - оно было очевидно готовым, но всегда полезно рассказать про процесс и код. Также мы коснулись моих проектов, в частности Калькулятора стоимости жизни. Тут я рассказывал про технологии и показывал код - как питонячий для парсинга и подготовки данных, так и фронтенд лендинга и самого приложения.
На следующий день я получил письмо о том, что меня готовы взять на работу и несколько раз поговорил по телефону с CEO про то, как всё прошло, зарплату, опцион, визы. Он, как и я, был очень удивлён совпадению интересов и навыков, но видел риск - тут я удивился - в том, что я захочу делать всё на свете. Сошлись на том, что и фронтенда достаточно, особенно с перспективой растить команду.
Конечно, после Фейсбука и The Trade Desk, где было по 4-5 секций и куча алгоритмов, эти собеседования прошли легко и быстро.
Я скоро выхожу на новую работу в стартап. Там я буду отвечать за весь фронтенд сервиса, похожего по смыслу на гугл-аналитику - личный кабинет с дашбордами, графиками, служебными страницами.
Сегодня я расскажу, как проходили собеседования и что мне, вероятно, помогло их пройти.
Ребята нашли меня на LinkedIn и, в отличие от десятков других сообщений, которые я получаю, это привлекло тем, что написал мне лично CEO. К тому моменту я уже решил, что буду уходить из Фейсбука, и предложение от стартапа, а не очередного амазона пришлось как нельзя кстати.
В начале мы созвонились с помощником CEO и поговорили про мои планы и то, кто нужен компании и на какую роль. Так как это стартап, мой интерес к продуктовой разработке, предпринимательству и соответствующее отношение к работе, вероятно, подошли под их ожидания. Плюс мы просто мило побеседовали.
В подобном разговоре - по сути, скрининге на адекватность и соответствие ожиданий - важно изложить свою историю и поделиться планами так, чтобы это звучало непротиворечиво, а также быть дружелюбным и расспросить про компанию.
Так как я ничего про Hook не знал, я спросил про количество сотрудников, ближайшие планы, источники финансирования. В конце разговора меня спросили о зарплатных ожиданиях, на что я ответил уклончиво: мол, в Фейсбуке всё равно платят больше - и тогда мне озвучили их вилку. Также я ещё раз уточнил, готовы ли они спонсировать рабочую визу.
После разговора я поискал в сети всех сотрудников компании, включая CEO, посмотрел их выступления и убедился, что история сходится и этим людям, кажется, можно доверять.
Следующим был разговор с CEO. Он очень подробно расспросил меня про планы, включая переход из найма в предпринимательство (да, я вполне открыто об этом заявляю - в стартапе это нормально), а также рассказал о компании и её ценностях, идее продукта и как он к ней пришёл, а также почему она должна полететь. Я очень много спрашивал про продукт, ожидания ко мне и бизнесовые штуки, вроде ключевых моментов в ближайший год, инвесторов, рисков.
На этом этапе стало очевидно, что мы друг другу нравимся и, вероятно, подходим. В дополнение ко всему, Hook делает аналитику для SaaS-компаний - и это классное совпадение. Мне интересны бизнесы с подписочной моделью, а ещё я много работал с аналитикой в Яндексе и кое-что понимаю в ключевых SaaS-метриках и механизмах - привлечении и удержании пользователей, онбординге, экономике.
В конце концов, я рассказал CEO о своих сайд-проектах, как и зачем я их делал, какие проблемы они решают, а также тех самых продуктовых метриках. Думаю, его впечатлило моё упорство в работе над своими проектами, а также понимание продуктовой разработки/аналитики и полного стека веб-технологий, плюс совпадающий опыт.
Потом мне дали тестовое домашнее задание с рекомендацией сделать его за час. Детали задания я раскрывать не буду, но нужно было сделать простое одностраничное веб-приложение - я выбрал React и TypeScript, написал весь код примерно за полтора часа и ещё около получаса подробно расписывал в readme что и почему я сделал, какие были подводные камни, на какие детали я обратил внимание. К репозиторию я дал доступ CTO.
В конце концов, у меня было два собеседования с CTO. На них я рассказал про домашнее задание - оно было очевидно готовым, но всегда полезно рассказать про процесс и код. Также мы коснулись моих проектов, в частности Калькулятора стоимости жизни. Тут я рассказывал про технологии и показывал код - как питонячий для парсинга и подготовки данных, так и фронтенд лендинга и самого приложения.
На следующий день я получил письмо о том, что меня готовы взять на работу и несколько раз поговорил по телефону с CEO про то, как всё прошло, зарплату, опцион, визы. Он, как и я, был очень удивлён совпадению интересов и навыков, но видел риск - тут я удивился - в том, что я захочу делать всё на свете. Сошлись на том, что и фронтенда достаточно, особенно с перспективой растить команду.
Конечно, после Фейсбука и The Trade Desk, где было по 4-5 секций и куча алгоритмов, эти собеседования прошли легко и быстро.
Апдейт по сайд-проектам: сайт и публичность
Некоторые из вас знают, что у меня есть сайд-проекты разной степени важности и законченности. Сегодня публикую небольшой апдейт по двум: сайту и публичной деятельности - стратегически важным проектам, которые будут жить и развиваться ещё много лет.
Сайт и online presence
В прошлом году я купил домен gromov.com и начал работу над новым сайтом. Текущий меня не устраивает ни внешним видом, ни контентом и структурой, а ещё там нет мультиязычности и комментариев.
Новый сайт должен закрыть эти проблемы, а также стать ключевым элементом моего online presence: именно туда я буду выкладывать все лонгриды, заметки, а ещё собирать ссылки на свои выступления, интервью, статьи и проекты.
Я считаю, что именно свой сайт - это максимально независимая и управляемая площадка для вещания в сети, в отличие от всяких медиумов, блогов на хабре и даже канала в телеге.
Сначала я взялся за работу со стороны движка - фактически, кастомной CMS на джанге, но быстро столкнулся с проблемой. Программировать там особо нечего, а вот понять, что именно запрограммировать, сложнее. Всякий раз, когда я сталкивался с необходимостью принять решение про дизайн или информационную архитектуру, я в итоге закапывался в какие-то дебри и забивал.
Я даже написал ТЗ для дизайнера, но быстро понял, что лучше сделаю всё сам, потому что дизайн неотрывно связан со структурой сайта и позиционированием, а отдавать эти вопросы на откуп кому-то я не готов.
Статус: дизайн ключевых страниц и элементов готов, надо программировать и выкладывать статьи и остальные важные страницы. Планирую закончить и выложить первую версию нового сайта этим летом.
Выступления и статьи
Я считаю свою публичную деятельность сайд-проектом, потому что на неё уходит достаточно времени и усилий, а также всё это нужно планировать, приоритизировать и вписывать в расписание.
Целей на ближайший год, глобально, две: ещё подрастить свою известность и авторитет в русскоязычном сообществе и выйти из сумрака в англоязычном.
Для этого я планирую выступить на нескольких конференциях, написать ещё кучу заметок в блог и несколько лонгридов, а также вовлекаться во все возможные активности и движухи. Для русскоязычной аудитории основные обновления останутся в телеграме, а для англоязычной я попробую писать в твитер, хотя управляться с несколькими площадками непросто.
Я также заребрендил свой канал, чтобы он был более человечным и обещал не только экспертность по разным вопросам, а ещё и приключения, в которые мои читатели виртуально отправляются вместе со мной.
Ютуб и другие форматы вроде подкастов я тоже обдумываю, но выдавать качественный контент с хорошим продакшеном видео и аудио сложнее, поэтому не уверен, что всерьёз займусь ими в этом году.
Статус: отправляю заявки на разные конференции, на русском и английском, более активно пишу статьи, планирую лонгриды для разных площадок и продвижение канала другими способами.
А у вас какие планы на год?
Некоторые из вас знают, что у меня есть сайд-проекты разной степени важности и законченности. Сегодня публикую небольшой апдейт по двум: сайту и публичной деятельности - стратегически важным проектам, которые будут жить и развиваться ещё много лет.
Сайт и online presence
В прошлом году я купил домен gromov.com и начал работу над новым сайтом. Текущий меня не устраивает ни внешним видом, ни контентом и структурой, а ещё там нет мультиязычности и комментариев.
Новый сайт должен закрыть эти проблемы, а также стать ключевым элементом моего online presence: именно туда я буду выкладывать все лонгриды, заметки, а ещё собирать ссылки на свои выступления, интервью, статьи и проекты.
Я считаю, что именно свой сайт - это максимально независимая и управляемая площадка для вещания в сети, в отличие от всяких медиумов, блогов на хабре и даже канала в телеге.
Сначала я взялся за работу со стороны движка - фактически, кастомной CMS на джанге, но быстро столкнулся с проблемой. Программировать там особо нечего, а вот понять, что именно запрограммировать, сложнее. Всякий раз, когда я сталкивался с необходимостью принять решение про дизайн или информационную архитектуру, я в итоге закапывался в какие-то дебри и забивал.
Я даже написал ТЗ для дизайнера, но быстро понял, что лучше сделаю всё сам, потому что дизайн неотрывно связан со структурой сайта и позиционированием, а отдавать эти вопросы на откуп кому-то я не готов.
Статус: дизайн ключевых страниц и элементов готов, надо программировать и выкладывать статьи и остальные важные страницы. Планирую закончить и выложить первую версию нового сайта этим летом.
Выступления и статьи
Я считаю свою публичную деятельность сайд-проектом, потому что на неё уходит достаточно времени и усилий, а также всё это нужно планировать, приоритизировать и вписывать в расписание.
Целей на ближайший год, глобально, две: ещё подрастить свою известность и авторитет в русскоязычном сообществе и выйти из сумрака в англоязычном.
Для этого я планирую выступить на нескольких конференциях, написать ещё кучу заметок в блог и несколько лонгридов, а также вовлекаться во все возможные активности и движухи. Для русскоязычной аудитории основные обновления останутся в телеграме, а для англоязычной я попробую писать в твитер, хотя управляться с несколькими площадками непросто.
Я также заребрендил свой канал, чтобы он был более человечным и обещал не только экспертность по разным вопросам, а ещё и приключения, в которые мои читатели виртуально отправляются вместе со мной.
Ютуб и другие форматы вроде подкастов я тоже обдумываю, но выдавать качественный контент с хорошим продакшеном видео и аудио сложнее, поэтому не уверен, что всерьёз займусь ими в этом году.
Статус: отправляю заявки на разные конференции, на русском и английском, более активно пишу статьи, планирую лонгриды для разных площадок и продвижение канала другими способами.
А у вас какие планы на год?
В чём разница между техлидом, тимлидом и архитектором?
Подписчик спрашивает: "есть возможность рассказать со своей точки зрения чем техлид/тимлид отличается от архитектора в общих чертах?".
Давно хотел коснуться этой темы. Какой-то общепризнанной классификации подобных позиций нет - но есть классный TeamLead Roadmap, который можно взять за основу для планирования карьеры.
Расскажу, глядя со своей колокольни. Моё мнение основано на 5 годах опыта работы тимлидом (в Яндексе и Топтале), а также размышлениях о том, как эффективно организовывать работу технических команд.
При этом разные команды и компании обычно работают совершенно по-разному, нарезая список активностей как требуется и называя людей на схожих позициях по-разному.
Техлид - это, как правило, самый опытный разработчик в команде. Часто, и максимально естественно, техлидом становится один из тех, кто начинал проект и принимал решения по поводу технологий и архитектуры системы. Техлид может отвечать за следующее:
- Технические решения, их надёжность, стоимость эксплутации и развития
- Часть процессов в команде: ревью кода и архитектуры фич, оценку сложности и планирование разработки, тестирование и деплои
- Часть проектов и активностей: активное управление техдолгом, миграцию на новый стек
В компаниях, где я работал, не было выделенной должности техлида. Обычно это неофициальный тайтл для человека, к которому и так приходят с вопросами на технические темы и к чьему мнению прислушиваются.
Часто техлид работает в паре с проджект-менеджером, отвечающим за реализацию проекта и, иногда, людей.
Тимлид - это должность с большим количеством обязанностей. В дополнение к ответственности за технологии, тимлиды часто отвечают за:
- Найм, адаптацию, развитие и увольнение людей
- Постановку, планирование и достижение всех целей команды - технических и бизнесовых
- Настройку и поддержание всех процессов в команде
- Активную коммуникацию и распространение информации во все стороны, а также управление ожиданиями: стейкхолдеров, менеджеров, членов команды
И в Яндексе, и в Топтале есть должность тимлида. Обычно это первая ступенька управленческого трека в карьере.
Кому-то, как мне, позиция тимлида может прийтись по вкусу - скорее всего, придётся делать кучу всего и вовлекаться не только в написание и поддержку кода, но и в продуктовые решения, планирование, обсуждения и политику.
Другим не нравится, что к тимлиду часто слишком много ожиданий - и код пиши, и людей нанимай, и проекты доводи до конца. Зарплата при этом не всегда существенно выше, чем у разработчиков.
Архитектор - более редкая птица. Я всего несколько раз встречался с людьми в такой должности, и обычно в иерархии управления они находятся вне продуктовых команд (но не обязательно над тимлидами или менеджерами).
Архитектор может отвечать за общее направление развития технологий и технические процессы в компании, касающиеся всех команд. Например, выбор и развитие архитектуры всех систем, унификацию технологий и решений, используемых для одинаковых задач, безопасность, надёжность и эффективность инфраструктуры, мониторинг и прочее.
Между целями архитекторов (сделать правильно и единообразно) и тимлидов (выпускать проекты в срок и сохранить интерес ключевых людей к работе) могут быть противоречия. Вероятно, обеим сторонам нужно активно поддерживать и корректировать баланс между чистотой решений и скоростью релизов.
А как разработка устроена у вас в компании?
Подписчик спрашивает: "есть возможность рассказать со своей точки зрения чем техлид/тимлид отличается от архитектора в общих чертах?".
Давно хотел коснуться этой темы. Какой-то общепризнанной классификации подобных позиций нет - но есть классный TeamLead Roadmap, который можно взять за основу для планирования карьеры.
Расскажу, глядя со своей колокольни. Моё мнение основано на 5 годах опыта работы тимлидом (в Яндексе и Топтале), а также размышлениях о том, как эффективно организовывать работу технических команд.
При этом разные команды и компании обычно работают совершенно по-разному, нарезая список активностей как требуется и называя людей на схожих позициях по-разному.
Техлид - это, как правило, самый опытный разработчик в команде. Часто, и максимально естественно, техлидом становится один из тех, кто начинал проект и принимал решения по поводу технологий и архитектуры системы. Техлид может отвечать за следующее:
- Технические решения, их надёжность, стоимость эксплутации и развития
- Часть процессов в команде: ревью кода и архитектуры фич, оценку сложности и планирование разработки, тестирование и деплои
- Часть проектов и активностей: активное управление техдолгом, миграцию на новый стек
В компаниях, где я работал, не было выделенной должности техлида. Обычно это неофициальный тайтл для человека, к которому и так приходят с вопросами на технические темы и к чьему мнению прислушиваются.
Часто техлид работает в паре с проджект-менеджером, отвечающим за реализацию проекта и, иногда, людей.
Тимлид - это должность с большим количеством обязанностей. В дополнение к ответственности за технологии, тимлиды часто отвечают за:
- Найм, адаптацию, развитие и увольнение людей
- Постановку, планирование и достижение всех целей команды - технических и бизнесовых
- Настройку и поддержание всех процессов в команде
- Активную коммуникацию и распространение информации во все стороны, а также управление ожиданиями: стейкхолдеров, менеджеров, членов команды
И в Яндексе, и в Топтале есть должность тимлида. Обычно это первая ступенька управленческого трека в карьере.
Кому-то, как мне, позиция тимлида может прийтись по вкусу - скорее всего, придётся делать кучу всего и вовлекаться не только в написание и поддержку кода, но и в продуктовые решения, планирование, обсуждения и политику.
Другим не нравится, что к тимлиду часто слишком много ожиданий - и код пиши, и людей нанимай, и проекты доводи до конца. Зарплата при этом не всегда существенно выше, чем у разработчиков.
Архитектор - более редкая птица. Я всего несколько раз встречался с людьми в такой должности, и обычно в иерархии управления они находятся вне продуктовых команд (но не обязательно над тимлидами или менеджерами).
Архитектор может отвечать за общее направление развития технологий и технические процессы в компании, касающиеся всех команд. Например, выбор и развитие архитектуры всех систем, унификацию технологий и решений, используемых для одинаковых задач, безопасность, надёжность и эффективность инфраструктуры, мониторинг и прочее.
Между целями архитекторов (сделать правильно и единообразно) и тимлидов (выпускать проекты в срок и сохранить интерес ключевых людей к работе) могут быть противоречия. Вероятно, обеим сторонам нужно активно поддерживать и корректировать баланс между чистотой решений и скоростью релизов.
А как разработка устроена у вас в компании?
Зачем устраиваться в FAANG и/или переезжать за границу
Роман Пушкин поделился мыслями про FAANG, и я хочу немного дополнить его пост.
В FAANG хотят попасть по разным причинам. Для кого-то это работа мечты. Может казаться, что, получив ачивку Яндекса, Фейсбука или Гугла, жизнь обретёт какую-то завершённость. Это достаточно наивная идея, активно продвигаемая, по-видимому, самими корпорациями через те самые мощные HR-бренды, на поддержание которых они тратят огромные деньги.
Разработчику в корпорации действительно непросто вырасти (в деньгах и ответственности), особенно потому, что треки individual contributor, product manager и engineering manager намеренно разделены.
Но достаточно легко представить продвижение для управленца или владельца продукта, потому что команды и продукты растут. Работа разработчика, особенно хорошего, достаточно сложно масштабируется, а умение писать или объяснять код не так уж просто сконвертировать в управленческие навыки. Плюс не очевидно, есть ли у крупных компаний причины продвигать разработчиков в менеджеров, особенно с учётом дефицита на рынке труда.
Про деньги тоже верно. FAANG часто платит немного выше рынка на входе, но основной рост дохода приходится не на базовую зарплату, а на RSU и рефрешеры. Чтобы получать их, нужно очень быстро крутить педали (и получать хорошие оценки на ревью) - и делать это много лет.
При том, что шансы попасть в интересный продукт или поменять команду на более интересную не такие уж высокие. Значит, велика вероятность заниматься какой-то фигней годами, только чтобы вырасти в деньгах и незначительно приблизиться к желаемому образу жизни.
В достаточно типовой ситуации, когда опытный программист с семьей переезжает за границу по рабочей визе и устраивается в FAANG, денег может хватать только на жизнь - и так много лет, с неясными перспективами, особенно до получения гражданства или хотя бы ПМЖ.
Сам по себе переезд за границу за лучшей жизнью - тоже не гарантированно успешный и уж точно не максимально наполненный счастливыми переживаниями путь. Переезд даже в другой город может сильно ударить по самооценке и качеству жизни, не говоря уж о другой стране. Даже если ваша зарплата выше рынка, многое за рубежом существенно дороже (жильё, детские сады, кружки и няни, образование, услуги), а в отсутствие родственников и друзей повседневная жизнь может напоминать будни гастарбайтера.
В итоге, стоит ли вообще переезжать, в частности на работу в FAANG? Сейчас для меня это неочевидно.
Сам по себе переезд корпорации помогают сделать максимально гладким со своими богатыми (и то не везде) релокационными пакетами. Но вот рабочая жизнь в совершенно новой среде едва ли так уж увлекательна. Времени, желания и возможности познакомиться с новыми людьми и по-настоящему вкусить жизнь в новом месте может и не оставаться.
Например, моя текущая жизнь в Англии достаточно тусклая в сравнении с 6 месяцами в США, когда я был студентом языковой школы и просто жил в своё удовольствие, изучая английский и путешествуя по Штатам.
Альтернативой может быть удалёнка. Как я писал в одной из статей, "удалёнка — это отличный вариант для тех, кто не хочет ввязываться в сложности переезда ради работы, а удалёнка в зарубежной компании особенно хороша из-за высокой зарплаты".
Зарабатывать можно на хорошую жизнь, крупные покупки и путешествия, оставаясь в привычной и понятной среде и не теряя связи с близкими людьми. И всегда иметь в запасе возможность переехать, если вам в какой-то момент этого захочется.
А вы как считаете, переезд за границу и работа в корпорации стоят всех сложностей?
Роман Пушкин поделился мыслями про FAANG, и я хочу немного дополнить его пост.
В FAANG хотят попасть по разным причинам. Для кого-то это работа мечты. Может казаться, что, получив ачивку Яндекса, Фейсбука или Гугла, жизнь обретёт какую-то завершённость. Это достаточно наивная идея, активно продвигаемая, по-видимому, самими корпорациями через те самые мощные HR-бренды, на поддержание которых они тратят огромные деньги.
Разработчику в корпорации действительно непросто вырасти (в деньгах и ответственности), особенно потому, что треки individual contributor, product manager и engineering manager намеренно разделены.
Но достаточно легко представить продвижение для управленца или владельца продукта, потому что команды и продукты растут. Работа разработчика, особенно хорошего, достаточно сложно масштабируется, а умение писать или объяснять код не так уж просто сконвертировать в управленческие навыки. Плюс не очевидно, есть ли у крупных компаний причины продвигать разработчиков в менеджеров, особенно с учётом дефицита на рынке труда.
Про деньги тоже верно. FAANG часто платит немного выше рынка на входе, но основной рост дохода приходится не на базовую зарплату, а на RSU и рефрешеры. Чтобы получать их, нужно очень быстро крутить педали (и получать хорошие оценки на ревью) - и делать это много лет.
При том, что шансы попасть в интересный продукт или поменять команду на более интересную не такие уж высокие. Значит, велика вероятность заниматься какой-то фигней годами, только чтобы вырасти в деньгах и незначительно приблизиться к желаемому образу жизни.
В достаточно типовой ситуации, когда опытный программист с семьей переезжает за границу по рабочей визе и устраивается в FAANG, денег может хватать только на жизнь - и так много лет, с неясными перспективами, особенно до получения гражданства или хотя бы ПМЖ.
Сам по себе переезд за границу за лучшей жизнью - тоже не гарантированно успешный и уж точно не максимально наполненный счастливыми переживаниями путь. Переезд даже в другой город может сильно ударить по самооценке и качеству жизни, не говоря уж о другой стране. Даже если ваша зарплата выше рынка, многое за рубежом существенно дороже (жильё, детские сады, кружки и няни, образование, услуги), а в отсутствие родственников и друзей повседневная жизнь может напоминать будни гастарбайтера.
В итоге, стоит ли вообще переезжать, в частности на работу в FAANG? Сейчас для меня это неочевидно.
Сам по себе переезд корпорации помогают сделать максимально гладким со своими богатыми (и то не везде) релокационными пакетами. Но вот рабочая жизнь в совершенно новой среде едва ли так уж увлекательна. Времени, желания и возможности познакомиться с новыми людьми и по-настоящему вкусить жизнь в новом месте может и не оставаться.
Например, моя текущая жизнь в Англии достаточно тусклая в сравнении с 6 месяцами в США, когда я был студентом языковой школы и просто жил в своё удовольствие, изучая английский и путешествуя по Штатам.
Альтернативой может быть удалёнка. Как я писал в одной из статей, "удалёнка — это отличный вариант для тех, кто не хочет ввязываться в сложности переезда ради работы, а удалёнка в зарубежной компании особенно хороша из-за высокой зарплаты".
Зарабатывать можно на хорошую жизнь, крупные покупки и путешествия, оставаясь в привычной и понятной среде и не теряя связи с близкими людьми. И всегда иметь в запасе возможность переехать, если вам в какой-то момент этого захочется.
А вы как считаете, переезд за границу и работа в корпорации стоят всех сложностей?
Апдейт по сайд-проектам: стартапы в зародыше
Прошлый апдейт про сайд-проекты был про новый сайт и публичную деятельность. Сегодня публикую апдейт по проектам, которые потенциально могли бы превратиться в бизнесы: калькулятору стоимости жизни и словарику Quiken.
Калькулятор стоимости жизни
Когда-то давно мне пришла в голову идея сделать калькулятор стоимости жизни в разных странах и городах. Данные в сети, собранные из разных источников, есть, а вот вменяемого интерфейса для сравнения стоимости своего образа жизни в разных локациях - пока нет.
За пару недель я собрал первый прототип продукта, потом пару месяцев доделывал лендинг и дорабатывал сам калькулятор, и сейчас они практически готовы. Осталось сделать мобильную версию и поправить всякие мелочи, а также починить конвертацию валют - открытое и бесплатное API, которое я нашёл, стало за это время недоступным без ключа.
По ссылкам из моего канала в калькулятор пришло около 400 человек, из которых порядка 250 активно пользовались им - я прикрутил метрики, которые трекаются гугл аналитикой, чтобы следить за вовлечённостью пользователей. Среднее время вовлечённой сессии - около полутора минут.
Но есть критически важная проблема: не понятно, как улучшить retention пользователей, потому что по своей природе такой калькулятор - это штука, которой воспользуешься от силы пару раз, планируя переезд. А переезжают люди нечасто.
Статус: планирую запуск через несколько месяцев, может быть осенью. Буду привлекать пользователей со всего мира через контент-маркетинг и всякие "партизанские" низкобюджетные техники, вроде партнёрств с существующими игроками на рынке.
Критические предположения, которые нужно проверить:
- для продукта есть рынок, и можно найти подходящую модель монетизации
- удастся запартнёриться с важными и заметными игроками на рынке, чтобы привлекать трафик без активных усилий
- калькулятор в принципе обеспечивает достаточную точность, чтобы быть полезным (частично провалидировано первыми пользователями)
Словарик с произношением Quiken
Quiken я начал делать по вечерам, когда Лондон закрылся на карантин. Мне казалось, что можно сделать полезную штуку для изучающих английский - но, в большей степени, хотелось доказать себе, что я могу что-то сделать от начала и до конца (после корпоративных ужасов последнего десятилетия).
Сейчас на проект я практически забил: мне недостаёт интереса к проблеме, чтобы заниматься им продолжительное время. Плюс не понятны перспективы: я достаточно подозрительно отношусь к B2C рынку изучения английского - тут и пообещать результат сложно, и денег с каждого пользователя много не взять, и конкуренция громадная. Не уверен, что хочу во всё это ввязываться.
Само браузерное расширение, хотя и полностью работоспособно уже больше года, было распубликовано гуглом за отсутствие страницы privacy policy - и я так и не сделал её. И не уверен, что сделаю, хотя дел там на полчаса.
Бэкенд сервиса вертится на 5-долларовом дроплете в Digital Ocean и смотрит в отдельный MySQL за $15. Итого: -$20 каждый месяц. Надо перенести БД в постгрес, который я использую для своего сайта - нагрузка и объём данных там мизерные, и можно сэкономить пятнашку в месяц на кофе.
Статус: нужно мигрировать базу данных и оставить проект в "музее", но делать всё это лень. А просто прибить жалко.
Мне также постоянно приходят в голову идеи разных проектов, которые я всегда записываю. Часть из них хочется поисследовать, но пока не знаю, как сложится работа в стартапе - и сколько свободного времени у меня будет оставаться.
Прошлый апдейт про сайд-проекты был про новый сайт и публичную деятельность. Сегодня публикую апдейт по проектам, которые потенциально могли бы превратиться в бизнесы: калькулятору стоимости жизни и словарику Quiken.
Калькулятор стоимости жизни
Когда-то давно мне пришла в голову идея сделать калькулятор стоимости жизни в разных странах и городах. Данные в сети, собранные из разных источников, есть, а вот вменяемого интерфейса для сравнения стоимости своего образа жизни в разных локациях - пока нет.
За пару недель я собрал первый прототип продукта, потом пару месяцев доделывал лендинг и дорабатывал сам калькулятор, и сейчас они практически готовы. Осталось сделать мобильную версию и поправить всякие мелочи, а также починить конвертацию валют - открытое и бесплатное API, которое я нашёл, стало за это время недоступным без ключа.
По ссылкам из моего канала в калькулятор пришло около 400 человек, из которых порядка 250 активно пользовались им - я прикрутил метрики, которые трекаются гугл аналитикой, чтобы следить за вовлечённостью пользователей. Среднее время вовлечённой сессии - около полутора минут.
Но есть критически важная проблема: не понятно, как улучшить retention пользователей, потому что по своей природе такой калькулятор - это штука, которой воспользуешься от силы пару раз, планируя переезд. А переезжают люди нечасто.
Статус: планирую запуск через несколько месяцев, может быть осенью. Буду привлекать пользователей со всего мира через контент-маркетинг и всякие "партизанские" низкобюджетные техники, вроде партнёрств с существующими игроками на рынке.
Критические предположения, которые нужно проверить:
- для продукта есть рынок, и можно найти подходящую модель монетизации
- удастся запартнёриться с важными и заметными игроками на рынке, чтобы привлекать трафик без активных усилий
- калькулятор в принципе обеспечивает достаточную точность, чтобы быть полезным (частично провалидировано первыми пользователями)
Словарик с произношением Quiken
Quiken я начал делать по вечерам, когда Лондон закрылся на карантин. Мне казалось, что можно сделать полезную штуку для изучающих английский - но, в большей степени, хотелось доказать себе, что я могу что-то сделать от начала и до конца (после корпоративных ужасов последнего десятилетия).
Сейчас на проект я практически забил: мне недостаёт интереса к проблеме, чтобы заниматься им продолжительное время. Плюс не понятны перспективы: я достаточно подозрительно отношусь к B2C рынку изучения английского - тут и пообещать результат сложно, и денег с каждого пользователя много не взять, и конкуренция громадная. Не уверен, что хочу во всё это ввязываться.
Само браузерное расширение, хотя и полностью работоспособно уже больше года, было распубликовано гуглом за отсутствие страницы privacy policy - и я так и не сделал её. И не уверен, что сделаю, хотя дел там на полчаса.
Бэкенд сервиса вертится на 5-долларовом дроплете в Digital Ocean и смотрит в отдельный MySQL за $15. Итого: -$20 каждый месяц. Надо перенести БД в постгрес, который я использую для своего сайта - нагрузка и объём данных там мизерные, и можно сэкономить пятнашку в месяц на кофе.
Статус: нужно мигрировать базу данных и оставить проект в "музее", но делать всё это лень. А просто прибить жалко.
Мне также постоянно приходят в голову идеи разных проектов, которые я всегда записываю. Часть из них хочется поисследовать, но пока не знаю, как сложится работа в стартапе - и сколько свободного времени у меня будет оставаться.
Интересные посты с декабря по конец мая
Привет всем новым подписчикам! Для вашего удобства публикую дайджест интересных постов с декабря по конец мая. Прошлый дайджест с начала ведения канала по конец 2020-го можно найти здесь.
1. Важнее всего люди
2. Фейсбук сломался - и это ожидаемо
3. Конспект стрима "Попасть в FAANG недостаточно"
4. Кому на удалёнке жить тяжело
5. Занудные вопросы
6. Прототип Калькулятора стоимости жизни в табличке
7. Про первый веб-прототип Калькулятора, сделанный за неделю
8. Чем круты крутые программисты
9. Год в Фейсбуке 👻
10. Год в Фейсбуке - продолжение
11. Калькулятор стоимости жизни - вести с полей
12. Четыре модальности написания кода - часть первая
13. Четыре модальности написания кода - часть вторая
14. Субботние ссылки
15. Любопытные модули из Калькулятора стоимости жизни
16. 20 лет продакт-менеджмента за 25 минут - конспект
17. Принятие решений в жизни и на работе
18. Зачем сидеть в найме
19. Ребрендинг канала: G R O M O V → Приключения Громова
20. Откуда брать информацию про предпринимательство
21. Как быть лучше подавляющего большинства разработчиков
22. Длинный гайд про блоггинг (есть ещё версия получше на Хабре)
23. Тысяча преданных фанатов
24. Вот и меня настигла прокрастинация
25. Поможет ли профессиональный блог найти работу?
26. Из Фейсбука в стартап
27. Какими должны быть условия работы программистов и почему?
28. Про RSU и опционы
29. Зачем компания давать тестовые задания, а нам — тратить время на них?
30. Как я авиабилеты заказывал
31. Баланс между порядком и хаосом ☯
32. Полезные для фронтендеров алгоритмы
33. Как я прошёл собеседования в стартап
34. Апдейт по сайд-проектам: сайт и публичность
35. В чём разница между техлидом, тимлидом и архитектором?
36. Зачем устраиваться в FAANG и/или переезжать за границу
37. Апдейт по сайд-проектам: стартапы в зародыше
Поделитесь постом с друзьями, если какие-то мысли кажутся вам интересными.
Привет всем новым подписчикам! Для вашего удобства публикую дайджест интересных постов с декабря по конец мая. Прошлый дайджест с начала ведения канала по конец 2020-го можно найти здесь.
1. Важнее всего люди
2. Фейсбук сломался - и это ожидаемо
3. Конспект стрима "Попасть в FAANG недостаточно"
4. Кому на удалёнке жить тяжело
5. Занудные вопросы
6. Прототип Калькулятора стоимости жизни в табличке
7. Про первый веб-прототип Калькулятора, сделанный за неделю
8. Чем круты крутые программисты
9. Год в Фейсбуке 👻
10. Год в Фейсбуке - продолжение
11. Калькулятор стоимости жизни - вести с полей
12. Четыре модальности написания кода - часть первая
13. Четыре модальности написания кода - часть вторая
14. Субботние ссылки
15. Любопытные модули из Калькулятора стоимости жизни
16. 20 лет продакт-менеджмента за 25 минут - конспект
17. Принятие решений в жизни и на работе
18. Зачем сидеть в найме
19. Ребрендинг канала: G R O M O V → Приключения Громова
20. Откуда брать информацию про предпринимательство
21. Как быть лучше подавляющего большинства разработчиков
22. Длинный гайд про блоггинг (есть ещё версия получше на Хабре)
23. Тысяча преданных фанатов
24. Вот и меня настигла прокрастинация
25. Поможет ли профессиональный блог найти работу?
26. Из Фейсбука в стартап
27. Какими должны быть условия работы программистов и почему?
28. Про RSU и опционы
29. Зачем компания давать тестовые задания, а нам — тратить время на них?
30. Как я авиабилеты заказывал
31. Баланс между порядком и хаосом ☯
32. Полезные для фронтендеров алгоритмы
33. Как я прошёл собеседования в стартап
34. Апдейт по сайд-проектам: сайт и публичность
35. В чём разница между техлидом, тимлидом и архитектором?
36. Зачем устраиваться в FAANG и/или переезжать за границу
37. Апдейт по сайд-проектам: стартапы в зародыше
Поделитесь постом с друзьями, если какие-то мысли кажутся вам интересными.
Самая большая проблема служб поддержки
Ничего не понимаю в организации работы поддержки (но в какой-то момент придётся разобраться), но всё же поделюсь своими размышленями и наблюдениями за работой поддержки - как изнутри, из Фейсбука или Яндекса, так и снаружи, как клиента разных компаний и пользователя разных продуктов.
Обычно служба поддержки сталкивается с десятками и сотнями достаточно дурацких вопросов: как установить-обновить-удалить, где в мессенджере сообщения, а в банковском приложении баланс. Наверное, в большинстве недорогих b2c продуктов такие вопросы правильно решать с помощью ботов и прочих FAQ, что множество компаний и делает. Но кто-то всё равно должен следить за их актуальностью, поэтому нужна служба поддержки.
Клиентам также нужна помощь с уже сделанными покупками и действиями в приложении: как поменять количество товара в оплаченном заказе без создания нового, можно ли сделать refund на другую карту, какие условия обслуживания на конкретном тарифе - и множество важных, но далеко запрятанных или неавтоматизируемых штук. Это тоже к службе поддержки, и, как правило, справляются они неплохо. Хотя часто и не быстро тоже.
Но сложнее всего наладить работу с багами и кривыми фичами, которые путают пользователей, заставляют их делать ошибки (как у меня с номером паспорта - хотя проблема была техническая на стороне агрегатора), нервничать и добиваться решений.
Сотрудники поддержки обычно совершенно не понимают, что происходит в коде. Немного чаще они знают про важные обновления приложения, но точно не следят за всеми релизами и, в отличие от разработчиков, не могут отследить связь между новыми жалобами и вчерашним релизом.
При этом сами разработчики (не везде, но много где) часто не заинтересованы в исправлении багов. Даже не потому, что они такие ленивые жопы, а потому что часто приоритеты команды другие. В Фейсбуке это impact, а от исправления багов, особенно редких и сложновоспроизводимых, импакта ноль. Зато пользователям - гемор и игнор.
Казалось бы, такая большая и богатая компания: неужели нельзя найти людей и время починить очевидные косяки. Ну, может и большая, так и продуктов у неё тоже много. Наша команда, например, состоявшая из нескольких человек до недавних пор, поддерживает внутренний чат - достаточно сложное и сырое приложение, которым пользуются десятки тысяч людей. Каждый рабочий день, в течение десятков часов, во всех часовых поясах.
У нас багов в бэклоге столько, что их и десять землекопов будут разгребать месяц. А за это время новых насыплется.
Но это в разработке такое творится, а поддержка что в это время делает? В лучшем случае, успокаивает клиентов и отвечает, что мы уже чиним и скоро всё образуется - а в худшем, осознанно или нет, сваливает проблему на самих пользователей и напрягает их рекомендациями попробовать снова или отписками в духе "сам дурак".
И наверняка у сотрудников служб поддержки есть агрессивные KPI на время реакции и разрешения проблемы, на количество открытых жалоб и так далее. То есть они зажаты тисками: с одной стороны, надо помочь как можно скорее, а с другой - помочь-то часто и невозможно.
Что с этим делать? Не знаю. Но в маленькой компании (например, в своей будущей компании) я бы дал разработчикам общаться с клиентами и решать их проблемы. Конечно, не все возможные проблемы, а только откровенно технические, где наверняка замешаны проблемы с кодом.
А вы бы как решили проблемы служб поддержки?
Ничего не понимаю в организации работы поддержки (но в какой-то момент придётся разобраться), но всё же поделюсь своими размышленями и наблюдениями за работой поддержки - как изнутри, из Фейсбука или Яндекса, так и снаружи, как клиента разных компаний и пользователя разных продуктов.
Обычно служба поддержки сталкивается с десятками и сотнями достаточно дурацких вопросов: как установить-обновить-удалить, где в мессенджере сообщения, а в банковском приложении баланс. Наверное, в большинстве недорогих b2c продуктов такие вопросы правильно решать с помощью ботов и прочих FAQ, что множество компаний и делает. Но кто-то всё равно должен следить за их актуальностью, поэтому нужна служба поддержки.
Клиентам также нужна помощь с уже сделанными покупками и действиями в приложении: как поменять количество товара в оплаченном заказе без создания нового, можно ли сделать refund на другую карту, какие условия обслуживания на конкретном тарифе - и множество важных, но далеко запрятанных или неавтоматизируемых штук. Это тоже к службе поддержки, и, как правило, справляются они неплохо. Хотя часто и не быстро тоже.
Но сложнее всего наладить работу с багами и кривыми фичами, которые путают пользователей, заставляют их делать ошибки (как у меня с номером паспорта - хотя проблема была техническая на стороне агрегатора), нервничать и добиваться решений.
Сотрудники поддержки обычно совершенно не понимают, что происходит в коде. Немного чаще они знают про важные обновления приложения, но точно не следят за всеми релизами и, в отличие от разработчиков, не могут отследить связь между новыми жалобами и вчерашним релизом.
При этом сами разработчики (не везде, но много где) часто не заинтересованы в исправлении багов. Даже не потому, что они такие ленивые жопы, а потому что часто приоритеты команды другие. В Фейсбуке это impact, а от исправления багов, особенно редких и сложновоспроизводимых, импакта ноль. Зато пользователям - гемор и игнор.
Казалось бы, такая большая и богатая компания: неужели нельзя найти людей и время починить очевидные косяки. Ну, может и большая, так и продуктов у неё тоже много. Наша команда, например, состоявшая из нескольких человек до недавних пор, поддерживает внутренний чат - достаточно сложное и сырое приложение, которым пользуются десятки тысяч людей. Каждый рабочий день, в течение десятков часов, во всех часовых поясах.
У нас багов в бэклоге столько, что их и десять землекопов будут разгребать месяц. А за это время новых насыплется.
Но это в разработке такое творится, а поддержка что в это время делает? В лучшем случае, успокаивает клиентов и отвечает, что мы уже чиним и скоро всё образуется - а в худшем, осознанно или нет, сваливает проблему на самих пользователей и напрягает их рекомендациями попробовать снова или отписками в духе "сам дурак".
И наверняка у сотрудников служб поддержки есть агрессивные KPI на время реакции и разрешения проблемы, на количество открытых жалоб и так далее. То есть они зажаты тисками: с одной стороны, надо помочь как можно скорее, а с другой - помочь-то часто и невозможно.
Что с этим делать? Не знаю. Но в маленькой компании (например, в своей будущей компании) я бы дал разработчикам общаться с клиентами и решать их проблемы. Конечно, не все возможные проблемы, а только откровенно технические, где наверняка замешаны проблемы с кодом.
А вы бы как решили проблемы служб поддержки?
На этой неделе веду твитер @itunderhood. В первый и второй день говорили про деньги в айтишке и самореализацию, а сегодня про английский язык. В канале я эту тему пока не поднимал, хотя считаю, что знание английского языка, равно как и софт-скиллы, фундаментально важны для карьеры любого айтишника.
Сделать из кучки скриптов нормальный локальный ETL
Мой Калькулятор стоимости жизни использует данные с Numbeo. Сейчас процесс выгрузки данных крайне примитивный.
- есть несколько скриптов, которые с помощью scrapy парсят сайт и складывают данные в промежуточные текстовые файлы
- ещё пара скриптов берут эти текстовые файлы, как-то обрабатывают и группируют данные и генерят JSON-файлы, которые используются в приложении
- bash-скрипт, который объединяет первые 2 шага
Всё это я запускаю локально (это намеренное решение, чтоб не городить CI/CD инфраструктуру). Деплоится всё отдельным ansible-плейбуком, чтобы разложить JSON в S3-подобное хранилище и обновить версию/URL в джаваскрипте вместе с релизом самого JS. Это тоже осознанное решение, потому что так деплоится мой сайт, а калькулятор - его часть.
Меня всё устраивает. Но дело в том, что на куче скриптов и текстовых файлов без SQL сложно делать нормальные агрегации и обрабатывать данные серьёзнее, чем просто выкинуть пустые поля или лишние символы.
Я вижу следующую итерацию этой системы как простейший ETL-пайплайн, который я также буду запускать локально.
- Extract: один питонячий скрипт, который инициализирует scrapy и сгружает всё в SQLite
- Transform: набор классов или функций, запускаемых в определённом порядке, чтобы применить все нужные обработки и создать агрегированные таблицы и всякие вьюхи
- Load: взять все получившиеся таблички и нагенерировать из них JSON-файлов
Всё это несложно запрограммировать, но мне интересно, есть ли какие-то инструменты для таких задач. Что-то типа конфигурируемого комбайна, который уже умеет парсить, складывать данные в БД, обрабатывать и писать JSON, а ты ему только реализацию каждого шага подсовывай.
Поделитесь опытом в комментариях.
Мой Калькулятор стоимости жизни использует данные с Numbeo. Сейчас процесс выгрузки данных крайне примитивный.
- есть несколько скриптов, которые с помощью scrapy парсят сайт и складывают данные в промежуточные текстовые файлы
- ещё пара скриптов берут эти текстовые файлы, как-то обрабатывают и группируют данные и генерят JSON-файлы, которые используются в приложении
- bash-скрипт, который объединяет первые 2 шага
Всё это я запускаю локально (это намеренное решение, чтоб не городить CI/CD инфраструктуру). Деплоится всё отдельным ansible-плейбуком, чтобы разложить JSON в S3-подобное хранилище и обновить версию/URL в джаваскрипте вместе с релизом самого JS. Это тоже осознанное решение, потому что так деплоится мой сайт, а калькулятор - его часть.
Меня всё устраивает. Но дело в том, что на куче скриптов и текстовых файлов без SQL сложно делать нормальные агрегации и обрабатывать данные серьёзнее, чем просто выкинуть пустые поля или лишние символы.
Я вижу следующую итерацию этой системы как простейший ETL-пайплайн, который я также буду запускать локально.
- Extract: один питонячий скрипт, который инициализирует scrapy и сгружает всё в SQLite
- Transform: набор классов или функций, запускаемых в определённом порядке, чтобы применить все нужные обработки и создать агрегированные таблицы и всякие вьюхи
- Load: взять все получившиеся таблички и нагенерировать из них JSON-файлов
Всё это несложно запрограммировать, но мне интересно, есть ли какие-то инструменты для таких задач. Что-то типа конфигурируемого комбайна, который уже умеет парсить, складывать данные в БД, обрабатывать и писать JSON, а ты ему только реализацию каждого шага подсовывай.
Поделитесь опытом в комментариях.
Способы переехать за границу
⚠️ Это обзорная статья, а не советы про переезд и его юридические тонкости. Я не юрист, и просто делюсь опытом.
Многие программисты мигрируют: сначала из провинции в Москву/Питер, а потом и за рубеж. Это классно, что такие возможности сейчас есть, хотя и работа на удалёнке из родного города с низкой стоимостью жизни - классный вариант.
Переезжают обычно по рабочей визе. У разных стран свои правила, но смысл плюс-минус один: вы умеете делать что-то редкое и востребованное рынком, поэтому вам дают возможность переехать и работать внутри чужой страны. Вы платите налоги этому государству и закрываете потребности его экономики. В некотором смысле вы нужны стране больше, чем она вам - и уж точно отдаёте ей намного больше.
Интересным этот вариант становится тогда, когда вы и сами хотите уехать, когда вам интересно работать в одной из нанимающих компаний и, наконец, когда рабочая виза потенциально превращается в ПМЖ, а потом гражданство.
Это самый распространённый путь переезда, но далеко не самый удобный. Вы обычно оказываетесь зависимы от работодателя - и должны получить новую визу, если хотите сменить работу. У вас будут очень ограниченные возможности: например, в UK нельзя открыть свою компанию и заниматься другой работой больше 20 часов в неделю. А работой не по специальности (официально) и вовсе нельзя.
В Штатах, например, полный бардак с рабочей визой - её ещё пойди получи из-за квоты, а во всяких экзотических странах вроде Сингапура или Китая гражданство никак не получить.
Но есть и другие варианты. В последнее время многие страны предлагают иммиграцию по стартап-визе. Особенно активна в этом смысле Эстония, а также Латвия, Литва и другие небогатые и небольшие страны вроде Португалии. Этот вариант может быть не намного лучше рабочей визы, так как к вам и вашей компании будут определённые требования - как для получения визы, так и для продления.
При этом в UK, например, стартап-виза вроде бы не конвертируется в ПМЖ так же легко, как и рабочая, и даётся всего на 2 года, после которых можно либо перейти на визу "состоявшегося" предпринимателя, либо просто уехать. В Эстонии получше с этим, а Португалия, к примеру, требует от компании годовой оборот около €350k спустя несколько лет.
В общем, особенностей много - но если вы хотите не работать и медленно копить на пенсию, а фигачить и предпринимательствовать, стартап-виза может быть удобнее. Например, их часто можно делать не только на себя, но и на сооснователей компании.
Но самый крутой известный мне вариант - это переезд по визе таланта. В США это виза O-1, а в UK - Global Talent. Про другие страны не знаю. Вне айти их выдают ребятам с нобелевскими премиями и всяким знаменитым артистам, но в айтишке своя жизнь - и получить такую визу может практически любой опытный разработчик, который продемонстрирует свои достижения.
К достижениям относятся, как правило, внушительный опыт работы и заслуги, рекомендации бывших коллег, публичная активность и признание сообществом, менторство и преподавание, научные работы. Я видел кучу ситуаций, когда человек без особых проблем собирает кейс за год-два и переезжает, имея намного больше прав и возможностей в новой стране, чем с рабочей визой.
Виза таланта не привязывает вас к работодателю, а значит позволяет легко менять работу и быть в менее зависимом от причуд компании положении (особенно в США, где потеря H1B может быть чревата кучей проблем). Как правило, через неё можно быстрее получить ПМЖ и потом гражданство. Вы сможете открыть свою компанию и заниматься плюс-минус чем угодно, что связано с вашей специальностью.
Есть и другие, менее распространённые варианты, например, трансфер в США по визе L-1 (такое часто делают сотрудники европейских офисов гугла и фейсбука, которые хотели в Штаты, но оказались в Европе), жизнь по digital nomad визе или визе фрилансера (такое есть в Испании, в Берлине и, кажется, много где ещё) или даже жизнь по студенческой визе + удалённая/нелегальная работа.
Про эти варианты я знаю ещё меньше, но просто имейте в виду, что они существуют.
⚠️ Это обзорная статья, а не советы про переезд и его юридические тонкости. Я не юрист, и просто делюсь опытом.
Многие программисты мигрируют: сначала из провинции в Москву/Питер, а потом и за рубеж. Это классно, что такие возможности сейчас есть, хотя и работа на удалёнке из родного города с низкой стоимостью жизни - классный вариант.
Переезжают обычно по рабочей визе. У разных стран свои правила, но смысл плюс-минус один: вы умеете делать что-то редкое и востребованное рынком, поэтому вам дают возможность переехать и работать внутри чужой страны. Вы платите налоги этому государству и закрываете потребности его экономики. В некотором смысле вы нужны стране больше, чем она вам - и уж точно отдаёте ей намного больше.
Интересным этот вариант становится тогда, когда вы и сами хотите уехать, когда вам интересно работать в одной из нанимающих компаний и, наконец, когда рабочая виза потенциально превращается в ПМЖ, а потом гражданство.
Это самый распространённый путь переезда, но далеко не самый удобный. Вы обычно оказываетесь зависимы от работодателя - и должны получить новую визу, если хотите сменить работу. У вас будут очень ограниченные возможности: например, в UK нельзя открыть свою компанию и заниматься другой работой больше 20 часов в неделю. А работой не по специальности (официально) и вовсе нельзя.
В Штатах, например, полный бардак с рабочей визой - её ещё пойди получи из-за квоты, а во всяких экзотических странах вроде Сингапура или Китая гражданство никак не получить.
Но есть и другие варианты. В последнее время многие страны предлагают иммиграцию по стартап-визе. Особенно активна в этом смысле Эстония, а также Латвия, Литва и другие небогатые и небольшие страны вроде Португалии. Этот вариант может быть не намного лучше рабочей визы, так как к вам и вашей компании будут определённые требования - как для получения визы, так и для продления.
При этом в UK, например, стартап-виза вроде бы не конвертируется в ПМЖ так же легко, как и рабочая, и даётся всего на 2 года, после которых можно либо перейти на визу "состоявшегося" предпринимателя, либо просто уехать. В Эстонии получше с этим, а Португалия, к примеру, требует от компании годовой оборот около €350k спустя несколько лет.
В общем, особенностей много - но если вы хотите не работать и медленно копить на пенсию, а фигачить и предпринимательствовать, стартап-виза может быть удобнее. Например, их часто можно делать не только на себя, но и на сооснователей компании.
Но самый крутой известный мне вариант - это переезд по визе таланта. В США это виза O-1, а в UK - Global Talent. Про другие страны не знаю. Вне айти их выдают ребятам с нобелевскими премиями и всяким знаменитым артистам, но в айтишке своя жизнь - и получить такую визу может практически любой опытный разработчик, который продемонстрирует свои достижения.
К достижениям относятся, как правило, внушительный опыт работы и заслуги, рекомендации бывших коллег, публичная активность и признание сообществом, менторство и преподавание, научные работы. Я видел кучу ситуаций, когда человек без особых проблем собирает кейс за год-два и переезжает, имея намного больше прав и возможностей в новой стране, чем с рабочей визой.
Виза таланта не привязывает вас к работодателю, а значит позволяет легко менять работу и быть в менее зависимом от причуд компании положении (особенно в США, где потеря H1B может быть чревата кучей проблем). Как правило, через неё можно быстрее получить ПМЖ и потом гражданство. Вы сможете открыть свою компанию и заниматься плюс-минус чем угодно, что связано с вашей специальностью.
Есть и другие, менее распространённые варианты, например, трансфер в США по визе L-1 (такое часто делают сотрудники европейских офисов гугла и фейсбука, которые хотели в Штаты, но оказались в Европе), жизнь по digital nomad визе или визе фрилансера (такое есть в Испании, в Берлине и, кажется, много где ещё) или даже жизнь по студенческой визе + удалённая/нелегальная работа.
Про эти варианты я знаю ещё меньше, но просто имейте в виду, что они существуют.
Личная и финансовая свобода
Удивительно, что мне почему-то понадобилось прочитать чужие слова про личную свободу, чтобы осознать, что это и есть моя основная мотивация. Несмотря на бесконечные размышления именно на эту тему.
Андрей Соловьёв, бывший учёный, которого упоминали в комментариях к посту про способы переезда за границу (как пример получения гринкарты США), писал в 2012-м году:
"Что есть личная свобода: делать то, что хочется. Не иметь начальства, дедлайнов и фиксированного рабочего дня. Не думать о визах, призывах в армии и прочих бюрократических заморочках. Если я захочу пойти на 6 месяцев по Аппалачиан трейлу, то не должен ни у кого отпрашиваться. Вот это личная свобода. Что такое финансовая свобода, надеюсь, всем понятно."
Именно так. Личная свобода - это когда мне не нужно ни перед кем отчитываться и просить разрешения сделать то, что я хочу, так, как я хочу, тогда, когда мне хочется. Ни перед государством, ни перед работодателем, ни перед любыми людьми.
Финансовая свобода - это когда мне не нужно жертвовать личной свободой ради денег.
Вот и всё.
Удивительно, что мне почему-то понадобилось прочитать чужие слова про личную свободу, чтобы осознать, что это и есть моя основная мотивация. Несмотря на бесконечные размышления именно на эту тему.
Андрей Соловьёв, бывший учёный, которого упоминали в комментариях к посту про способы переезда за границу (как пример получения гринкарты США), писал в 2012-м году:
"Что есть личная свобода: делать то, что хочется. Не иметь начальства, дедлайнов и фиксированного рабочего дня. Не думать о визах, призывах в армии и прочих бюрократических заморочках. Если я захочу пойти на 6 месяцев по Аппалачиан трейлу, то не должен ни у кого отпрашиваться. Вот это личная свобода. Что такое финансовая свобода, надеюсь, всем понятно."
Именно так. Личная свобода - это когда мне не нужно ни перед кем отчитываться и просить разрешения сделать то, что я хочу, так, как я хочу, тогда, когда мне хочется. Ни перед государством, ни перед работодателем, ни перед любыми людьми.
Финансовая свобода - это когда мне не нужно жертвовать личной свободой ради денег.
Вот и всё.
Люблю телеграм: хоть канал тут и сложно растить без внешнего продвижения, процесс у меня сложился замечательный. Раз в неделю я сажусь писать посты, когда есть настроение. Причём это очень удобно, потому что мне нужно немного расписаться - и тогда получается живенько и неплохо. Потом делаю запланированные публикации на неделю-две вперёд - и свободен. Красота!
Другое дело твитер. Я на той неделе вёл относительно популярный коллективный аккаунт
Хоть я и написал большую часть контента заранее, у меня не было инструментов отложенной публикации (говорят, надо пробовать Buffer?) плюс мне хотелось вовлекаться в обсуждения. Иначе зачем вообще писать в твитер? Поэтому я проверял уведомления как ненормальный на протяжении первых 4 дней.
Надо сказать, что отключенные уведомления (у меня они отключены везде кроме десятка избранных контактов и пары чатов уже пару лет точно) - основа концентрации и психического здоровья современного человека.
Судя по моим черновикам, я написал не меньше 60 тысяч символов и 10 тысяч слов - пятую часть неплохой книжки. Мои посты собрали около 1,8 миллионов просмотров, а приложенные ссылки - почти 6 тысяч кликов. И в телеграм пришло больше 800 новых подписчиков за это время - всем привет!
В общем, это пока моё самое публичное мероприятие (для сравнения, посты в канале собрали 60 тысяч просмотров за прошлый год, а все вместе статьи на VC и Habr - около 100-150 тысяч).
Получился интересный опыт. Мой канал хорошо подрос, а я поупражнялся в ведении твитера и немного познакомился с людьми. Наверное я взял высоковатый темп, но всё-таки вести твитер намного сложнее, чем телегу. Да и формат тоже странный: мои сообщения кучу раз выдёргивали из контекста (треда), да и делать слишком длинные треды тоже как будто бы не очень удобно.
Стало плюс-минус понятно, каково это - вести твитер, и, надо сказать, я не уверен, что очень уж хочу. Но продвигаться в англоязычном интернете как-то придётся, и популярного среди программистов твитера, видимо, не избежать.
Кстати, вам было бы удобно/интересно прочитать в канале конспекты и выдержки интересных тредов?
Я писал про деньги и самореализацию в IT, английский язык, собеседования и, в последний день, депрессию и профессиональное выгорание.
Другое дело твитер. Я на той неделе вёл относительно популярный коллективный аккаунт
@itunderhood. Запланировал 6 дней контента и 1 день свободного общения. В итоге на 4-й день я понял, что фигачить каждый день сложно и решил сделать субботу и воскресенье выходными.Хоть я и написал большую часть контента заранее, у меня не было инструментов отложенной публикации (говорят, надо пробовать Buffer?) плюс мне хотелось вовлекаться в обсуждения. Иначе зачем вообще писать в твитер? Поэтому я проверял уведомления как ненормальный на протяжении первых 4 дней.
Надо сказать, что отключенные уведомления (у меня они отключены везде кроме десятка избранных контактов и пары чатов уже пару лет точно) - основа концентрации и психического здоровья современного человека.
Судя по моим черновикам, я написал не меньше 60 тысяч символов и 10 тысяч слов - пятую часть неплохой книжки. Мои посты собрали около 1,8 миллионов просмотров, а приложенные ссылки - почти 6 тысяч кликов. И в телеграм пришло больше 800 новых подписчиков за это время - всем привет!
В общем, это пока моё самое публичное мероприятие (для сравнения, посты в канале собрали 60 тысяч просмотров за прошлый год, а все вместе статьи на VC и Habr - около 100-150 тысяч).
Получился интересный опыт. Мой канал хорошо подрос, а я поупражнялся в ведении твитера и немного познакомился с людьми. Наверное я взял высоковатый темп, но всё-таки вести твитер намного сложнее, чем телегу. Да и формат тоже странный: мои сообщения кучу раз выдёргивали из контекста (треда), да и делать слишком длинные треды тоже как будто бы не очень удобно.
Стало плюс-минус понятно, каково это - вести твитер, и, надо сказать, я не уверен, что очень уж хочу. Но продвигаться в англоязычном интернете как-то придётся, и популярного среди программистов твитера, видимо, не избежать.
Кстати, вам было бы удобно/интересно прочитать в канале конспекты и выдержки интересных тредов?
Я писал про деньги и самореализацию в IT, английский язык, собеседования и, в последний день, депрессию и профессиональное выгорание.
Интересно было бы почитать выдержки моих тредов из @itunderhood тут?
Anonymous Poll
47%
Про деньги
41%
Самореализацию
37%
Английский
38%
Собеседования
36%
Выгорание и депрессию
7%
Лучше в Твитере почитаю
14%
Посмотреть результаты
Как нестандартная архитектура сайта помогла решить проблемы с технологиями, командой и затянутым проектом редизайна
Так будет называться мой доклад на TechLead Conf в Москве, 1 июля. Расскажу историю своей команды в Toptal, куда я пришёл разработчиком, а спустя пару месяцев стал тимлидом и унаследовал кучу проблем:
- распределённая команда демотивирована, и её самые опытные члены ушли в другую команду;
- нужно сделать редизайн всего сайта, дедлайн был год назад - а не сделано ничего;
- в коде полный швах и легаси, и на это не то что нанять невозможно - самим работать тяжело.
Это только самые высокоуровневые проблемы: про ужасную скорость разработки, необратимые релизы, занимающие по часу, отсутствие инструментов младше 5 лет и подобное я вообще молчу.
Как ни странно, их удалось решить через моё изобретение - движок рендеринга, подобный Gatsby/Next, но работающий как stateless HTTP-сервис. Даём на вход название страницы и данные, получаем в ответ строчку HTML.
Это был самый "весёлый" рабочий год на моей памяти (не считая переезда в Лондон): всё это нужно было осознать и придумать, согласовать и сделать, нанять людей, уложиться в новые сроки с редизайном и не просрать накопленный SEO-капитал прошлой версии сайта.
Идёте на TechLead Conf? Заходите послушать.
Так будет называться мой доклад на TechLead Conf в Москве, 1 июля. Расскажу историю своей команды в Toptal, куда я пришёл разработчиком, а спустя пару месяцев стал тимлидом и унаследовал кучу проблем:
- распределённая команда демотивирована, и её самые опытные члены ушли в другую команду;
- нужно сделать редизайн всего сайта, дедлайн был год назад - а не сделано ничего;
- в коде полный швах и легаси, и на это не то что нанять невозможно - самим работать тяжело.
Это только самые высокоуровневые проблемы: про ужасную скорость разработки, необратимые релизы, занимающие по часу, отсутствие инструментов младше 5 лет и подобное я вообще молчу.
Как ни странно, их удалось решить через моё изобретение - движок рендеринга, подобный Gatsby/Next, но работающий как stateless HTTP-сервис. Даём на вход название страницы и данные, получаем в ответ строчку HTML.
Это был самый "весёлый" рабочий год на моей памяти (не считая переезда в Лондон): всё это нужно было осознать и придумать, согласовать и сделать, нанять людей, уложиться в новые сроки с редизайном и не просрать накопленный SEO-капитал прошлой версии сайта.
Идёте на TechLead Conf? Заходите послушать.
techleadconf.ru
Олег Громов на TechLead Conf 2021
У нас была куча проблем с сайтом — важнейшим маркетинговым инструментом компании, состоящим из тысяч страниц.Среди них: запутанный и ненадёжный код, долгие и часто необратимые релизы, поломанные и крайне долгие e2e-тесты, ужасающе низкая скорость разработки…
Онбординг-чеклист для разработчиков в небольших продуктовых компаниях
Я недавно начал работать в стартапе Hook и по этому поводу написал для себя небольшой чеклист для онбординга. Делюсь им с вами, может быть и вам когда-то пригодится.
Моя цель на первые месяц-два: разобраться в происходящем в компании и продукте, понять свою роль и ожидания коллег, научиться решать задачи end-to-end, от понимания "зачем" до работающего кода в продакшене.
1. Продукт и фичи, пользователи, рынок. Какие задачи он решает и для кого? Кто основные пользователи и клиенты, откуда деньги и где точки роста. Какие важные фичи есть, а каких не хватает. На какие метрики смотрим, чтобы отслеживать движение в нужном направлении, и где. Кто наши конкуренты, чем мы лучше и/или отличаемся в принципе. Будет ли влиять код, который я пишу, непосредственно на продукт.
2. Релизы, эксперименты, инфраструктура. Как код попадает в продакшен? В каком облаке всё работает, как конфигурируется инфраструктура и кто за это отвечает. Что за CI/CD-система используется, где работают тесты и насколько они надёжны. Как выкатить и откатить релиз, могу ли я сделать это сам или нужен кто-то ещё. Используются ли эксперименты (A/B-тесты), feature flags. На какие графики смотреть до, во время и после релиза и что делать в случае проблем.
3. Архитектура приложения, код, технологии. Как устроено приложение, с которым я буду работать? Что за архитектура, какие компоненты ключевые. Монолит, микросервисы или гибрид. Внешние зависимости, источники данных и БД, чужие API. Как это всё конфигурируется, запускается локально и в продакшене. Какие технологии и библиотеки используются, как структурирован код. Нужно ли мне изучить что-то новое. Как дебажить, какие инструменты использовать для разработки. Каков процесс разработки - github flow, trunk-based, пул-реквесты.
4. Планы, проекты, ритуалы. Как работает команда, в которой я оказался? Как происходит планирование, каковы текущие планы и цели, какие задачи входят в critical path проектов. Есть ли OKR или KPI в каком-то виде, кто принимает стратегические решения. Насколько мы укладываемся в текущие планы, есть ли жёсткие дедлайны, связанные с маркетингом или ожиданиями клиентов. Какие регулярные встречи есть, как общается команда - синхронно, асинхронно, в чатах или email, в курилке.
5. Люди, ожидания, динамика в команде. Как зовут людей, чем они занимаются в компании и вне неё? С кем мне предстоит работать больше всего. Подсмотреть полезные фишки, инструменты и техники у каждого. Каковы ожидания моего непосредственного руководства и топов. Какая динамика в команде, к кому прислушиваются и замолкают когда он(а) говорит, с кем можно поржать. Кто и какие решения принимает. У кого какие сильные стороны, в каком темпе они работают, кому и какие вопросы задавать.
Раньше я онбордился как-то хаотично, полагаясь либо на процессы компании, либо вообще на авось. Но первые месяцы в компании - слишком важный период, чтобы пускать его на самотёк. Кажется, от него зависит вся последующая вовлечённость, продуктивность и реализация моих амбиций в компании. Плюс самые глупые и неудобные вопросы комфортнее всего задавать в самом начале. Ведь новичкам всё можно.
Свои находки я стараюсь записывать (и зарисовывать) в один бумажный блокнот, чтобы лучше запоминать и иметь возможность вернуться к этим записям. Один блокнот, а не ворох бумажек или миллион заметок на компе, потому что так проще найти то, что нужно.
А как вы онбордитесь?
Я недавно начал работать в стартапе Hook и по этому поводу написал для себя небольшой чеклист для онбординга. Делюсь им с вами, может быть и вам когда-то пригодится.
Моя цель на первые месяц-два: разобраться в происходящем в компании и продукте, понять свою роль и ожидания коллег, научиться решать задачи end-to-end, от понимания "зачем" до работающего кода в продакшене.
1. Продукт и фичи, пользователи, рынок. Какие задачи он решает и для кого? Кто основные пользователи и клиенты, откуда деньги и где точки роста. Какие важные фичи есть, а каких не хватает. На какие метрики смотрим, чтобы отслеживать движение в нужном направлении, и где. Кто наши конкуренты, чем мы лучше и/или отличаемся в принципе. Будет ли влиять код, который я пишу, непосредственно на продукт.
2. Релизы, эксперименты, инфраструктура. Как код попадает в продакшен? В каком облаке всё работает, как конфигурируется инфраструктура и кто за это отвечает. Что за CI/CD-система используется, где работают тесты и насколько они надёжны. Как выкатить и откатить релиз, могу ли я сделать это сам или нужен кто-то ещё. Используются ли эксперименты (A/B-тесты), feature flags. На какие графики смотреть до, во время и после релиза и что делать в случае проблем.
3. Архитектура приложения, код, технологии. Как устроено приложение, с которым я буду работать? Что за архитектура, какие компоненты ключевые. Монолит, микросервисы или гибрид. Внешние зависимости, источники данных и БД, чужие API. Как это всё конфигурируется, запускается локально и в продакшене. Какие технологии и библиотеки используются, как структурирован код. Нужно ли мне изучить что-то новое. Как дебажить, какие инструменты использовать для разработки. Каков процесс разработки - github flow, trunk-based, пул-реквесты.
4. Планы, проекты, ритуалы. Как работает команда, в которой я оказался? Как происходит планирование, каковы текущие планы и цели, какие задачи входят в critical path проектов. Есть ли OKR или KPI в каком-то виде, кто принимает стратегические решения. Насколько мы укладываемся в текущие планы, есть ли жёсткие дедлайны, связанные с маркетингом или ожиданиями клиентов. Какие регулярные встречи есть, как общается команда - синхронно, асинхронно, в чатах или email, в курилке.
5. Люди, ожидания, динамика в команде. Как зовут людей, чем они занимаются в компании и вне неё? С кем мне предстоит работать больше всего. Подсмотреть полезные фишки, инструменты и техники у каждого. Каковы ожидания моего непосредственного руководства и топов. Какая динамика в команде, к кому прислушиваются и замолкают когда он(а) говорит, с кем можно поржать. Кто и какие решения принимает. У кого какие сильные стороны, в каком темпе они работают, кому и какие вопросы задавать.
Раньше я онбордился как-то хаотично, полагаясь либо на процессы компании, либо вообще на авось. Но первые месяцы в компании - слишком важный период, чтобы пускать его на самотёк. Кажется, от него зависит вся последующая вовлечённость, продуктивность и реализация моих амбиций в компании. Плюс самые глупые и неудобные вопросы комфортнее всего задавать в самом начале. Ведь новичкам всё можно.
Свои находки я стараюсь записывать (и зарисовывать) в один бумажный блокнот, чтобы лучше запоминать и иметь возможность вернуться к этим записям. Один блокнот, а не ворох бумажек или миллион заметок на компе, потому что так проще найти то, что нужно.
А как вы онбордитесь?