4 сентября

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

Блог компании Цифровые ЭкосистемыКарьера в IT-индустрииIT-компании
Перевод
Автор оригинала: Curtis Einsmann
Сегодня я праздную пять лет работы в 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. В будущем я надеюсь дать сообществу разработчиков ещё больше, потому что знаю, каково это – быть самозванцем.
Теги:amazonfaangкарьера программистакарьера в itкарьерный ростсиндром самозванца
Хабы: Блог компании Цифровые Экосистемы Карьера в IT-индустрии IT-компании
+29
34,1k 117
Комментарии 53
Похожие публикации
Лучшие публикации за сутки