Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Сегодня я праздную пять лет работы в Amazon. За это время я передал в продакшн боле 500 000 строк кода, проводил инспекцию чужого кода более 500 раз, проектировал, разрабатывал, развёртывал и поддерживал масштабные системы, которыми пользуются тысячи клиентов со всего света. Меня считают одним из ведущих технических лидеров в команде.
Но так было не всегда. В 2015 году меня устроили разработчиком ПО первого ранга. И напрасно. Я был самым настоящим самозванцем. Но мои скудные инженерные навыки не помешали мне в конце концов добиться повышения до второго ранга. Я хочу поделиться своей историей, чтобы помочь и другим самозванцам добиться успеха в компаниях FAANG – ну, или любых других.
Я восхищаюсь людьми, которые сумели пройти полный цикл отбора кандидатов в одной из компаний 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. В будущем я надеюсь дать сообществу разработчиков ещё больше, потому что знаю, каково это – быть самозванцем.
Но так было не всегда. В 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. В будущем я надеюсь дать сообществу разработчиков ещё больше, потому что знаю, каково это – быть самозванцем.
