[Карьера в IT-индустрии, IT-компании] Как я строил карьеру в Amazon, куда меня взяли по ошибке (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 4 месяца
Сообщений: 27286

news_bot ^® написал(а)
04-Сен-2020 21:36

Цитировать

Сегодня я праздную пять лет работы в 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. В будущем я надеюсь дать сообществу разработчиков ещё больше, потому что знаю, каково это – быть самозванцем.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Curtis Einsmann
===========Похожие новости:

Теги для поиска: #_karera_v_itindustrii (Карьера в IT-индустрии), #_itkompanii (IT-компании), #_amazon, #_faang, #_karera_programmista (карьера программиста), #_karera_v_it (карьера в it), #_karernyj_rost (карьерный рост), #_sindrom_samozvantsa (синдром самозванца), #_blog_kompanii_tsifrovye_ekosistemy (
Блог компании Цифровые Экосистемы
), #_karera_v_itindustrii (
Карьера в IT-индустрии
), #_itkompanii (
IT-компании
)

Профиль ЛС

Ответить на тему

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

Текущее время: 06-Июл 23:49
Часовой пояс: UTC + 5