Сегодня я праздную пять лет работы в 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. В будущем я надеюсь дать сообществу
разработчиков ещё больше, потому что знаю, каково это быть
самозванцем.
07.10.2020 10:05:19 |
Автор: 
Категории: 
iOS
Android
Разработка
Аналитика, маркетинг и монетизация
AI, Устройства, IoT
