Русский
Русский
English
Статистика
Реклама

Faang

Подборка Полезные статьи о релокации в США выбор визы, поиск работы, зарплаты и налоги

09.09.2020 22:19:00 | Автор: admin

Одна из самых популярных тем в нашем блоге релокация. А самым популярным направлением для переезда русскоговорящих инженеров остаются США. Это легко объяснимо в этой стране наиболее развита IT-отрасль, FAANG, тысячи стартапов, передовые технологии и вот это все.

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

Подготовка переезда: виза, стоимость жизни, выбор штата

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

Вот несколько полезных статей, которые помогут собрать побольше информации о визах и адаптации на новом месте в целом:

Работа: собеседования, зарплаты и налоги

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

В эту пятницу 17.00 Мск запускаем новый для g-mate формат вебинаров будем рассказывать про секреты найма в tech и особенности релокейта в разные страны.

В этот раз Анна Наумова, Senior Product Manager @ Zello расскажет, как пройти путь от отклика до оффера в США.

Еще немного полезных ссылок

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

Если вы хотите найти вакансии с возможностью релокации в США прямо в Телеграме подключайте бот g-mate (@g_jobbot) он будет присылать вакансии по вашему профилю прямо в чат. А компании могут опубликовать первые 3 вакансии бесплатно вот здесь.

Подробнее..

Как выглядят интервью дизайнеров и UX-специалистов в топовых ИТ-компаниях

24.09.2020 20:09:56 | Автор: admin

В нашем блоге мы много пишем о карьере в сфере ИТ, но обычно раскрываем темы, связанные с поиском работы инженеров и программистов. Сегодня же речь пойдет о том, как устроен процесс собеседований дизайнеров в топовых ИТ-компаниях уровня FAANG (Facebook, Amazon, Apple, Netflix, Google). Поехали!

Как устроен процесс

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

  • первый контакт;

  • созвон с рекрутером;

  • дизайн-челлендж;

  • on-site интервью;

  • принятие решения о предложении работы.

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

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

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

С помощью бота g-mate (@g_jobbot) вы сможете получить доступ к дизайн-вакансиям топовых ИТ-компаний в десятках стран мира. Просто укажите желаемую зарплату, локацию и профессию, чтобы получать подходящие именно вам вакансии прямо в Telegram.

Что такое Design challenge

Так называется тестовое задание, на которое могут выделять до нескольких дней. В случае Тони Аубе, Facebook и Amazon не предлагали делать такое задание, а в Apple и Google это было обязательным требованием. В обоих случаях оплаты задания не предполагалось. В Google на его выполнение давалась неделя.

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

В Apple задача была более конкретной нужно было придумать редизайн одного из приложений компании.

Главные советы по прохождению такого задания:

  • Важно очень постараться. Если рекрутер говорит, что задание занимает 8 рабочих часов, потратьте все 12. Если просят только вайрфреймы, отправьте полностью готовый UI. Если просят UI дайте интерактивный прототип. Превышение минимальных требований задания показывает мотивацию, а также тот факт, что кандидат сможет расти в компании.

  • Главное качество. Если интерфейс получился плохим, тот факт, что на его создание ушло 30 рабочих часов станет скорее большим минусом.

  • Интервьюеры хотят увидеть, как кандидат справляется с процессом от и до. В Google, например, даже выбор одной из трех проблем для решения уже часть дизайн-процесса. Тони Аубе провел базовое исследование всех трех из предложенных, выбрал одну - и включил обоснование выбора в свое решение. Затем он провел интервью с пользователями, сделал макеты, UI, прототип, пару тестов с пользователями, и даже некоторые элементы брендинга, включая логотип.

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

В каждом из двух случаев рекрутеры говорили Аубе, что были впечатлены качеством решения. Он прошел этап с design challenge как в Google, так и в Apple.

Помимо этого другой UX-специалист из Netflix в своем блоге на Medium поделился полезными ссылками для прохождения интервью на дизайн-позиции в крупных ИТ-компаниях:

Как проходят личные интервью

По словам Аубе, on-site интервью продлились почти целый день с 9-10 утра до 15:00-17:00. День включал в себя:

  • Презентацию портфолио (~1 час).

  • Общее интервью (45 минут).

  • Общение за обедом (~1 час).

  • Техническое интервью (45 минут).

  • Дизайн-ревью (45 минут).

  • Whiteboard exercise (45 минут).

Важно понимать, что от компании к компании порядок этапов может меняться, а некоторых из них может не быть вовсе.

Презентация портфолио

Для презентации портфолио отлично подходят советы Шэнцзе Чжан (Shengjie Zhang), которая проходила собеседования в Google, Facebook, Twitch, & Slack и в итоге работает в Google.

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

  • Вам будут задавать вопросы. Важно быть готовым ответить на них максимально детально, но не уходить в оборону. Вопрос может звучать так: Почему вы выбрали именно этот метод? Рассматривались ли другие опции, например xxx?

  • Очень важно показать влияние на продукт. Дизайнерам нравится влиять на продукт, так что когда они видят, как ваша работа принесла результат это им понравится. Стоит разделить влияние на 2-3 разных уровня детали дизайна, направление развития продукта, какие выгоды получили стейкхолдеры.

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

Дизайнер Кирилл Зима, который живет в Амстердаме, работает в Verifone, и ранее работал в Booking.com, а также проходил собеседования в ряд компаний из списка FAANG добавляет такие вопросы, к ответу на которые стоит подготовиться:

  • Как вы пришли к такому дизайн-решению?

  • Как проводились исследования?

  • Какие метрики вы используете при принятии решения, чтобы выделить удачное и неудачное?

  • Все ли в команде с ним были согласны, и если нет, то как вы их убедили?

  • Приведите пример вашего неудачного решения, как это произошло?

  • Какие уроки вы вынесли из этого?

Многие дизайнеры и UX-специалисты часто не готовятся именно к этому этапу интервью, что их подводит. Умение презентовать дизайн очень важно, как и умение объяснять свои решения так называемый stakeholder management будет затем активно использоваться в работе.

Бонусный совет от Тони Аубе:

  • На интервью в Google используйте Google Slides, в Apple только Keynote.

Техническое интервью

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

  • Какой софт вы используете в работе?

  • Как вы передаете результат работы инженерам?

  • Насколько хорошо вы разбираетесь в технологии, с которой предстоит работать? (HTML/CSS, Swift, iOS, Android, Unity)

  • Есть ли у вас какие-то дополнительные навыки, вроде 3D, анимации, иллюстрации, фотографии и т.п.?

  • Также вас могут попросить открыть ноутбук и показать, как хранятся файлы по текущему проекту это показывает организованность кандидата. Может ли он легко найти нужный файл? Корректно ли он группирует и называет слои?

Дизайн-ревью

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

  • Каково ваше первое впечатление от дизайна?

  • Нравится ли онбординг?

  • Дизайн этого приложения хорош или нет?

  • Что думаете о цветовой палитре? Как вам лого и иконки?

  • Что бы вы улучшили здесь с точки зрения интерфейса и UX?

  • Как вы думаете, почему разработчики приложения сделали X именно так? Как бы вы улучшили это решение?

Совет: к такому интервью нужно готовиться. Для этого можно развить навык мысленно оценивать каждый встреченный в жизни интерфейс.

Whiteboard exercise

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

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

  • Не нужно сразу бросаться рисовать. Это ловушка. Задача будет специально сформулирована слишком широко. Чтобы предложить более-менее подходящее решение ее будет необходимо сузить с помощью дополнительных вопросов (именно этот подход подразумевает модель STAR). К примеру, вас могут попросить создать дизайн для превосходного процесса дарения подарка. Тут можно спросить кто будет использовать эту функцию, какие подарки можно будет дарить, кому они предназначаются, какие сейчас есть главные проблемы в процессе? И уже затем можно переходить, например, к решению одной из проблем, которую вам назовут. И решение это вовсе не обязательно мобильное приложение, не надо мыслить в жестких рамках.

  • Объясняйте свой ход мыслей. Задача будет иметь несколько решений. Выбрать будет тяжело поэтому думайте вслух. Расскажите о плюсах и минусах тех решений, что вы видите. Объясните, почему склоняетесь к какому-то из них. Скажите, что в работе бы вы провели тесты для всех из них, но прямо сейчас идеальным кажется вот этот вариант.

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

Используйте бот g-mate (@g_jobbot), чтобы получать вакансии по своему профилю от ИТ-гигантов и стартапов прямо в Telegram. Компании могут опубликовать первые 3 вакансии бесплатно переходите по ссылке.

Другие наши статьи о прохождении собеседований и поиске работы в ИТ-компаниях:

Подробнее..

Перевод Как я строил карьеру в Amazon, куда меня взяли по ошибке

04.09.2020 20:08:16 | Автор: admin
Сегодня я праздную пять лет работы в Amazon. За это время я передал в продакшн боле 500 000 строк кода, проводил инспекцию чужого кода более 500 раз, проектировал, разрабатывал, развёртывал и поддерживал масштабные системы, которыми пользуются тысячи клиентов со всего света. Меня считают одним из ведущих технических лидеров в команде.

Но так было не всегда. В 2015 году меня устроили разработчиком ПО первого ранга. И напрасно. Я был самым настоящим самозванцем. Но мои скудные инженерные навыки не помешали мне в конце концов добиться повышения до второго ранга. Я хочу поделиться своей историей, чтобы помочь и другим самозванцам добиться успеха в компаниях FAANG ну, или любых других.

Как я прокрался в Amazon


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

Мой путь пролёг в обход всех этих трудностей. В 2014 году Amazon проводил в студенческом городке собеседования для желающих попасть в интерны на лето. Некоторые мои сокурсники сходили туда до меня. Все они возвращались с рассказами о головоломных вопросах по программированию, которые им задавали.

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

Интерны в Amazon, если хорошо себя покажут, получают предложение перейти на полную ставку разработчика первого ранка начального уровня. Повторно проходить собеседования им не приходится. Я проходил интернатуру в Сиэтле старательно ваял сайт на Ruby on Rails с нуля. Наработал на предложение и начал свою деятельность разработчика ПО в 2015 году в Виргинии.

О скудности моих познаний


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

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

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

Я и сам осознавал, что недотягиваю. В первое время синдром самозванца мучил меня со страшной силой.

Первые блины


Каждая инспекция кода оборачивалась катастрофой. Я отправлял фрагмент на проверку (в виде запроса на принятие изменений, допустим), мне его возвращали с восьмьюдесятью комментариями. Не годится. Я правил и отправлял новую версию. Ещё пятьдесят комментариев. Не годится. И так далее, и так далее.

С некоторыми фрагментами дела обстояли настолько плохо, что коллеги просто не знали, как объяснить суть проблемы, чтобы я понял. Им приходилось скачивать код и переписывать. Они хотели мне помочь и держались вполне доброжелательно, но я буквально со стыда сгорал. Я жил в страхе, что люди поймут: мне здесь не место. Ни одного рабочего дня не проходило без мысли о том, что вот сегодня меня и уволят.

Разоблачение самозванца


Мало-помалу я подтягивался. Наконец-то стал укладываться в сроки и стабильно отдавать код в продакшн. Спустя примерно девять месяцев у меня зародилась уверенность в собственных силах. Я решил, что пора раз и навсегда развязаться с синдромом самозванца. Я обратился к задачам на LeetCode, просто чтобы самому себе доказать, что я на своём месте. Помню, как думал: Я теперь полноправный разработчик в Amazon. У меня коммиты в проде. Что я, не справлюсь с этими простецкими задачами?.

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

Быть, а не казаться


Через два с половиной года меня повысили до разработчика второго ранга. Разработчик второго ранга способен своими силами создать и поддерживать крупную систему с минимальной помощью со стороны. Так как же мне это удалось? Как я сумел перетолковать правила игры в свою пользу?

Ну никак. В Amazon махинации не в ходу. Систему не переиграешь. Притворяйся специалистом, пока не добьёшься успеха очень распространённый и очень плохой совет. Это не работает. Единственный способ добиться того, чтобы тебя назначили разработчиком второго ранга стать разработчиком второго ранга.

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

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

Что я делал


Настраивался на максимальное принятие обратной связи

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

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

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

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

Задавал глупые вопросы

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

Например:

Я не знаю, что означает этот термин. Можешь объяснить или посоветовать, где почитать?

Какими ресурсами мне лучше всего воспользоваться, чтобы самому решить эту проблему?

Я не разобрался в том, что говорилось на совещании. Можно встретиться с тобой ещё раз и кое-что прояснить?

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

Нашёл неугомонного инспектора кода

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

Такой имеется в любой команде. Его ничья работа никогда не устраивает. Он цепляется к названию каждой переменной, каждому логу, каждому выбранному параметру API. Я специально приложил усилия, чтобы найти этого человека, и как можно чаще подкидывать ему свой код. Почему? Потому что понимал: чем больше конструктивных замечаний я буду получать, тем быстрее пойдёт обучение.

Использовал существующие образцы, чтобы избегать ошибок

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

Такого же подхода я придерживался при написании документации по дизайну и отчётов post mortem. Сначала образцы, потом действия.

Сосредоточился на правильности и целесообразности

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

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

Бросался в пекло

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

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

Проявлял инициативу по мелочам

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

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

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

Разработчик второго ранга должен быть мастером создания ПО, или профессионалом, по классификации Стивена Прессфилда, автора Войны искусства. Я бросил все силы на то, чтобы писать чистый код (с одноимённой книгой нужно ознакомиться обязательно) и создавать красивые, элегантные решения.

Ясно обозначил своё стремление к повышению

В компаниях FAANG повышения никто не предлагает вы их сами просите, и не единожды. Если этого не делать, процесс затянется на долгие месяцы.

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

Ставил работу на повышение впереди прочего

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

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

Постоянно собирал свидетельства своих успехов

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

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

Осознавал, что от меня зависит, а что нет

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

И вместе с тем, я понял, что если сосредоточусь на том, чтобы работать на пределе возможностей и подходить к задачам профессионально, то буду готов к тому моменту, когда появится возможность себя показать. Появилась возможность показал себя профессионалом. Это принесло еще несколько возможностей снова сделал всё на уровне. И так далее.

Размышления


Вредит ли делу культура Leetcode, которая сложилась в процессах найма?

Мне удалось успешно закрепиться в Amazon, хотя, когда я только пришёл, задачи с Leetcode были мне не по зубам. Потом, когда я сам стал проводить собеседования, то, конечно, целенаправленно разобрал все необходимые алгоритмы и структуры данных, чтобы быть в состоянии оценивать ответы кандидатов.

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

Значит, через интернатуру легче попасть в разработчики первого ранга?

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

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

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

Так Amazon правда зря тебя нанял?

До последнего времени я был склонен отвечать утвердительно. Не вызывает сомнений, что мои знания по программированию на тот момент не соответствовали требованиям. Но постепенно я пришёл к мысли, что в долгосрочной перспективе компания не прогадала от своего решения меня нанять. Я однозначно принёс Amazon ощутимую пользу.

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

Сравниваем грейды IT-инженеров крупных зарубежных компаний Google, Facebook, Uber и Booking

26.02.2021 22:07:39 | Автор: admin

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


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





Кое-что общее про грейды итребования кразработчикам вкомпаниях уровня FAANG


  • Зарубежом очень строго относятся копыту работы. ВРоссии можно выпуститься извуза, поработать годик иустроиться куда-нибудь мидлом или даже сеньором. Зарубежом такое встречается реже опыт вгодах играет важную роль.
  • Требования кпознаниям вязыках итехнологиях укомпаний уровня FAANG изначально очень высокие. Тоесть чтобы попасть даже нанижний грейд, выуже должны классно владеть инструментами иуметь писать чистый, рабочий иоптимизированный код. Более высокие грейды это больше про системное видение ипонимание привязки бизнес-процессов кпрограммированию. Кстати, если хочется протестировать именно технические навыки, можно пройти тест работодатели учитывают его результаты при найме.
  • Российский мидл изнебольшого стартапа мидлу вкрупной зарубежной компании. Частоте, кто внебольших российских компаниях работают как мидлы идаже сеньоры вкомпании уровня FAANG получают приглашение как джуниоры.
  • Лучше пойти мидлом вFAANG, чем сеньором внебольшую компанию. Нестоит переживать, что вам предложили грейд ниже скорее всего, изарплата, иобязанности иперспективы вFAANG будут намного выше.
  • Попасть навысокий грейд извне легче, чем вырасти внутри компании. Вкомпании придется прилагать много усилий идоказывать свою компетенцию, апри собеседовании важно будет произвести правильное впечатление. Конечно, это все равно тяжело, нолучше сразу метить куда-нибудь повыше, чем надеяться подрасти уже наместе.


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




Google иFacebook


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


E3в Facebook иL3в Google, Software Engineer II. Уровень джуниора, новичка. Сюда обычно берут тех, кто только что выпустился извуза, иеще неимеет опыта работы. Или проработал год-другой внекрупной компании. Здесь важно уметь писать рабочий код поконкретной задаче, использовать инструменты проверки кода, запускать код локально. Никаких управленческих задач икомпетенций нет.


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


E4в Facebook иL4в Google, Software Engineer III. Уровень мидла. Сотрудников этого грейда вобеих компаниях больше всего. Здесь важно уже непросто выполнять команды, апонимать, что тыразрабатываешь икак это влияет напроизводство. Плюс появляется три новых компетенции: умение писать документацию, давать задачи Е3ипринимать небольшие проектные решения. Например, самому придумывать, как именно реализовать фичу.


Некоторые инженеры всю жизнь живут наэтом этапе имкомфортно просто кодить, незанимаясь управлением.


E5в Facebook иL5в Google, Senior Software Engineer. Здесь уже появляются управленческие компетенции нужно возглавлять команду, помогать нижним грейдам, ставить новые задачи ирешатьих. Наэтом уровне инженер помогает формировать общую стратегию разработки например, придумывает, как именно реализовать запрос отбизнеса.


E6в Facebook иL6в Google, Staff Software Engineer. Наэтом уровне больше взаимодействия между командами. Именно инженеры этого грейда помогают собирать вместе фичи, разработанные разными командами. Или полностью управляют своей командой, как будто это небольшой стартап внутри компании реализуют крупные проекты, помогают снаймом новых сотрудников, предлагают глобальные идеи.

Есть грейды ивыше: 7, 8, 9, 10и11. Ноони уже практически директорские состороны сюда нанимают очень редко. Рядовые разработчики ссотрудниками этих грейдов обычно даже невзаимодействуют.


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





Uber


Этой информацией снами поделилась Алина, Software Engineer II @ Uber, Амстердам. Мыуже рассказывали, как она устроилась вUber ипереехала вНидерланды.


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


Software Engineer II. Уровень мидла, примерно как L4в Google. Хороший, крепкий программист: пишет проектную документацию, может сам выбрать алгоритм для решения задачи. Часто пишет код уже без контроля сверху. Помогает Software Engineer Iииногда ставит имзадачи. Обычно работает над более крупными проектами, которые длятся несколько месяцев.


Как ивдругих компаниях, инженеров этого уровня вUber больше всего.


Senior Software Engineer. Уровень сеньора, как L5в Google. Понимает проблемы бизнеса, умеет руководить другими инженерами инаставлятьих. Пишет код, нобольше работает над тем, чтобы разбить большую задачу наподзадачи, дать указания другим разработчикам, наметить общий путь разработки. Именно вего руках довести проект доконца отпришедших отруководства требований дозапуска.


Senior Software Engineer II. Почти тоже самое, что Senior Software Engineer, только взаимодействует снесколькими командами. Обычно занимается сложными, комплексными задачами, которые решаются руками большого числа разработчиков изразных групп. Сюда очень редко нанимают людей состороны, так как сотрудник должен хорошо понимать внутреннюю кухню Uber ибизнес-процессы.


Staff Software Engineer. Влияет навсе региональное подразделение. Тесно общается сдиректорами, строит общую стратегию развития компании стехнической точки зрения.





Booking


Этой информацией снами поделился Георгий Могелашвили, Lead Developer @ Booking.com, основатель сервиса поиска менторов getmentor.dev, автор телеграм канала Мужик сбабочкой.


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


Core. Минимум три года опыта вразработке, умение работать сраспределенными системами изнание технологий, скоторыми работает компания. Наэтом грейде сотрудники занимаются только разработкой поконкретным задачам, сминимумом управления именторства. Разработчиков этого уровня вBooking больше всего.


Кстати, тут можно посмотреть технические требования конкретно кэтому грейду ввакансии наCore Developer.


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


Технические требования тоже можно посмотреть ввакансии.


Principal.12+лет опыта. Роль технического руководителя, умение управлять командой, разрабатывать концепции, оценивать ивнедрять новые технологии. Понимание того, как накод влияют требования клиентов.


Вакансия для лучшего понимания требований.



<рекламная пауза>
Предложения откомпаний уровня FAANG сами собой вруки несвалятся. Чтобы ихнайти, получить оффер ипереехать заграницу, регистрируйтесь в @g_jobbot. Подходящие вам вакансии срелокейтом будут приходить вТелеграм.
</рекламная пауза>
Подробнее..

Личный опыт Как вырасти до Senior в компании уровня FAANG на примере Uber

13.03.2021 14:14:35 | Автор: admin

Как вырасти внутри компании уровня FAANG? Какие для этого нужны навыки, что придется делать ипочему быстро получить повышение неполучится? Мыспросили про это уАлины она работает вUber инедавно получила повышение доSenior Software Engineer. Сейчас расскажет, через что ейдля этого пришлось пройти.






Всем привет, меня зовут Алина, иуже несколько лет яживу вАмстердаме иработаю вUber backend-разработчиком водной изкоманд направления финансовых сервисов (Money Hub) вUber. Вэтом году яполучила повышение сSoftware Engineer IIдоSenior Software Engineer, тоесть выросла смидла досеньора. Расскажу, что ядля этого делала икак вUber устроен карьерный рост.



Счего яначинала: первые месяцы работы ипервые перспективы роста


Когда меня только собеседовали вUber, уменя был шанс попасть наSenior Software Engineer сразу. Новитоге оффер мне пришел нагрейд пониже, Software Engineer II. Для грейда Senior нужен опыт ведения своих проектов, ионуменя был. Ноподкачал мой английский егобы нехватило для сложного общения сколлегами идля менторства, абез этого насеньоре делать нечего.


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


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


Немного оформальностях: что нужно для повышения


Система повышения вUber очень удобная. Есть 6компетенций, идля каждой четко прописано, что тыдолжен уметь иделать веерамках насоответствующем грейде. Тывсегда можешь свериться ипосмотреть, покаким компетенциям дотягиваешь, апокаким проседаешь.


Компетенции такие:


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




Натимбилдингах вUber всегда очень интересно

Software engineering. Собственно разработка написание надежного, читаемого иэффективного кода. Работа сдокументацией, сопровождение полного цикла разработки.


Design &architecture. Проектирование конкретных решений: поддерживаемых, расширяемых иповторно используемых. Умение находить компромиссы между краткосрочными идолгосрочными целями.


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


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


Creating efficiency. Улучшение общих рабочих практик ипроцессов, устранение неэффективностей вповседневной работе. Выработка стратегий для увеличения производительности работы.


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


Получить повышение можно раз вполгода, наPromotion Review. Для этого тыпишешь Impact Resume расписываешь, что икак тыделаешь, чтобы доказать, что тыуже оперируешь компетенциями наболее высоком уровне. Потом твои коллеги тоже пишут отебе рассказывают, как они видят твою работу состороны. Это все рассматривают ирешают, повысить тебя или нет.


Тоесть повышение вUber невыдача тебе новых обязанностей, аскорее признание. Тыдолжен уже работать науровень выше, чтобы тебе одобрили повышение. Итут кроется проблема. Скомпетенциями вроде Citizenship или Software engineering все просто, тыможешь работать над ними сам. АсExecution &results кпримеру сложнее утебя должен быть проект, который тыведешь. Инефакт, что такой проект подвернется вближайшее время. Поэтому попасть навысокий грейд снаружи легче, чем вырасти нанего внутри.





Путь кповышению: что яделала для роста


Казалосьбы: загод яосвоилась санглийским испроцессами вUber, меня почти готовы были взять наSenior Software Engineer почемубы сразу непойти наповышение? Нопусть ятогда была готова оперировать компетенциями наболее высоком уровне, доказать это так быстробы неполучилось.


Поэтому япросто работала иделалато, что мне нравится:


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


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


Кстати, мои статьи наHabr (как устроилась вUber ипереехала жить вНидерланды икакое впечатление отработы вкомпании уровня FAANG) тоже зачли как работу наимидж компании. Это помогло мне вповышении :)




Фото содного изтимбилдингов, которые яорганизовывала сама

Работа вon-call. Вдополнение кразработке истандартному онколлу команды яработаю напередовой Uber on-call для компании вцелом. Если включевых процессах что-то сломается, мысдругими такимиже волонтерами помогаем быстро решить проблему. Наша задача выбрать оптимальный путь, чтобы починить все быстро исминимумом потерь для компании. Летом 2020я перешла навысший уровень on-call вUber.


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


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


2. Яинициировала глобальный проект. Унас вUber давно существовал один старый сервис. Онработал, ноизменения вдругих сервисах иобщих принципах разработки сэтим сервисом уже несочетались. Ияпредложила переписать этот сервис: описала изащитила саму необходимость изменений, потом прописала что икак будет работать ипрезентовала проект перед директорами юнита. Мне все одобрили, ияначала работать над сервисом скомандой, причем именно вроли руководителя: планировала, делегировала, распределяла задачи.


Проект занял целый год, иполучилось, что именно нанем япоказала компетенции, нужные для Senior Software Engineer.




Вот так выглядел наш брейншторм вовремя этого проекта

Повышение и жизнь после него: как все получилось и что я планирую делать дальше


Само повышение прошло достаточно просто. Мой менеджер все одобрил, я заполнила Impact Resume, коллеги тоже написали мне хорошие отзывы. В итоге комиссия все это рассмотрела, одобрила мое повышение и первого марта мне пришла информация об этом повышении. И уже мартовская зарплата у меня будет как у Senior Software Engineer.


Интересно, что кроме зарплаты для меня практически ничего не изменилось. Я уже целый год работала как Senior Software Engineer, и по сути теперь это просто признали.


Единственное изменение коснулось моего участия в интервью новых сотрудников. Раньше я работала с кандидатами только в секции Coding, то есть могла оцениватьих навыки разработки. Теперь мне доступна еще секция Architecture & Design она открыта только для сеньоров. Но не скажу, что это что-то принципиально важное.


Следующий грейд для меня Senior Software Engineer II. Прямо сейчас я не думаю о росте планирую просто работать и делать то, что мне нравится. Тем более, что в ближайшее время повышение получить не выйдет я ведь только что доказала, что работаю на уровне Senior Software Engineer, и вряд ли уже через полгода или даже год буду оперировать уровнем выше.


Для повышения до Senior Software Engineer II нужно управлять проектами, в которых задействованы несколько команд. Если что-то такое подвернется, я с радостью этим займусь. Не ради повышения, а потому что мне интересно.


<рекламная пауза>
Хотите пройти собеседование в компанию своей мечты? Подключайте телеграм-бота @g_jobbot. Тысячи компаний, в том числе на удалёнку и с переездом. И только интересующий вас уровень по зарплате.

Например, в боте можно вызвать себе в помощь IT-рекрутера командой /human. Он поможет упаковать опыт, прокачаться в нужном направлении и ворваться в компанию уровня FAANG на коне.
</рекламная пауза>
Подробнее..

Попасть в FAANG недостаточно, или 9 шагов к карьере мечты

18.12.2020 14:16:13 | Автор: admin

Привет,с вами Громов. Недавно я провёл стрим про карьеру для студентов Школы 21, который получился очень насыщенным и я успел коснуться только около трети запланированного. Ниже его основные мысли, если у вас нет времени смотреть часовую запись.

Карьера работа

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

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

Почему попасть в FAANG недостаточно?

Технологические корпорации FAANG стали целью для многих программистов. Причём часто альтернативы не рассматриваются вообще, а отказ на собеседовании воспринимается как полный провал. На мой взгляд, в глазах таких людей фаанги сильно переоценены.

У них естьплюсы:

  • Много умных и образованных людей вокруг

  • Относительно высокий статус

  • Зарплата выше среднерыночной

  • Множество возможностей (в теории)

Но иминусысерьёзные:

  • Формальный подход к оценке вашей эффективности

  • Огромная внутренняя конкуренция за интересные проекты и возможности (на практике)

  • Низкие шансы на нелинейный карьерный рост

  • Куча рутины и проблем, специфичных только для этих компаний

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

Учитесь делать крутые штуки

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

Зачем делать крутые штуки?

  • Чтобысохранить интерес к работе. Зарплата перестаёт мотивировать, и остаётся только от души интересоваться своими проектами.

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

Как делать крутые штуки?

  • Выберитеспециализациюи придерживайтесь её хотя бы год.

  • Сохраняйтездоровый перфекционизм, чтобы иметь возможность гордиться своей работой не падайте жертвами гибких методик разработки и постоянно меняющихся бизнес-требований.

  • Рассказывайте о своих проектах знакомым, на конференциях, в интернете.

Выбирайте ответственность, а не деньги

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

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

  • Когда вы берётесь за что-то новое, вы учитесь новому и таким образом поддерживаете свой интерес к профессии.

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

Что важно в работе

Держите слово это краеугольный камень профессиональной этики. Если слово сдержать не удаётся, проактивно выходите на связь и рассказывайте про изменения в планах. Сделайте так, чтобы на вас можно было положиться.

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

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

Что насчёт денег?

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

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

В совершенстве владейте инструментами

Интересный пункт, только отчасти связанный с самими инструментами языками программирования и IDE, плагинами и стандартным Linux-утилитами.

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

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

Подсматривайте фишки у коллег

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

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

Учитесь

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

  • Качайтенавыки общения. При прочих равных (hard skills), именно разница в навыках общения, убеждения и, более широко, soft skills определяет ваш успех.

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

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

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

Подавайте себя с выгодной стороны

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

  • Говорите и пишитеграмотно и убедительно.Этому стоит поучиться, в том числе на курсах ораторского искусства.

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

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

Во всём этом сохраняйтецелостность и непротиворечивость историисвоей карьеры и планов. Будьте готовы объяснить, почему вы принимали решения в прошлом и имейте представление о будущем, к которому вы стремитесь. Так и вам будет легче во время этих непростых разговоров, и впечатление от вас будет оставаться более собранное.

Организовывайте работу

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

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

  • Учитесьпланировать и оценивать разработку.Есть множество формальных и не очень методов - от проджект-менеджмента до scrum, которыми стоит овладеть, если вы хотите увеличивать своё понимание происходящего и влияние.

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

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

Понимайте бизнес

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

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

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

Сопереживайте пользователям

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

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

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

Будьте полезны сообществу

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

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

  • Участвуйте в митапах ивыступайте на конференциях.

  • Вписывайтесь винтересные некоммерческие проекты, участвуйте в хакатонах чтобы попробовать новое и познакомиться с коллегами.

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

  • Преподавайте.

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

Найдите своё место

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

Карта профессиональной деятельности из статьи Зачем программисту копаться в мозгах (t.me/gromov_com/48)Карта профессиональной деятельности из статьи Зачем программисту копаться в мозгах (t.me/gromov_com/48)

Это вполне возможно, еслистроить карьеру сознательно, а не прыгать с работы на работу в поисках более высокой зарплаты.

Карьера = предпринимательство

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

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

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

Если вы согласны с таким подходом,подписывайтесь на мой канал о программировании, карьере и предпринимательстве. Удачи!

Полезные ссылки

  • Бесплатный курсLearning How to Learnна Курсере.

  • Книга Поток не обязательно покупать, но можно ознакомиться с основными мыслями.

  • Книга Four Favorite Toolsот Кевина Келли. Не обязательно покупать, но любопытно посмотреть, чем пользуются другие.

  • Книга War of Artоб организации творческого процесса, преодолении прогкрастинации, достижении целей. Хорошая, рекомендую.

  • Книга Путь программистаДжона Сонмеза. (по-английски Soft Skills). Достаточно водянистая, но я скоро опубликую её конспект у себя на канале подписывайтесь.

  • Джоэль Спольски об оценке проектов: Evidence Based Scheduling. Классная статья, рекомендации из которой я не взялся бы применять на практике ?

Подробнее..

Стоимость IT-компаний США превысила капитализацию всего фондового рынка Евросоюза

26.09.2020 20:04:42 | Автор: admin

Аналитики Bank of America подсчитали капитализацию американского технологического сектора и сравнили ее с показателями фондового рынка Европы. В результате оказалось, что стоимость IT-компаний США на $0,2 трлн превышает весь фондовый рынок ЕС.

Что случилось

Эксперты подразделения Bank of America Global Research опубликовали новое исследование фондовых рынков США и Европы. Согласно полученным данным, на конец августа 2020 года капитализация американского сектора высоких технологий превышала $9 трлн. При этом капитализация всего фондового рынка Европы, включая Великобританию и Швейцарию составила $8,9 трлн.

В 2007 году же IT-сектор США в четыре раза уступал по объемам капитализации рынку акций Евросоюза.

Почему растут в цене IT-компании

В последние годы рынок высоких технологий США и так развивался достаточно бурно, но глобальная пандемия коронавируса в целом еще больше способствовала повышению показателей. Так в период с января 2020 года акции Apple выросли на 66%, Amazon на 80%, Microsoft на 42%, Alphabet (материнская компания Google) на 20%, соцсети Facebook на 40%. Из этих компаний только Facebook не преодолела капитализацию в $1 трлн.

В свою очередь, рост технологических акций вытягивает за собой и целые индексы, в которые они входят например, NASDAQ Composite в 2020 году установил уже несколько исторических максимумов роста. С января он вырос с 9000 до 11 695 пунктов к концу августа. Технологический сектор индекса S&P 500 за тот же период вырос на 35%.

В Европе меньше успешных технологических компаний с огромной капитализацией, и в том числе поэтому европейские индексы показывают не столь впечатляющие результаты. Так индекс европейских голубых фишек Euro Stoxx 50 по сравнению с началом года упал на 11%, а британский FTSE 100 обвалился на 20% по сравнению с январем.

В России акции американских компаний можно купить на Санкт-Петербургской бирже. Для этого не нужно открывать счет у иностранного брокера или использовать приложения вроде Robinhood, достаточно будет российского счета. Открыть его можно онлайн.

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru