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

Автор оригинала: 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. В будущем я надеюсь дать сообществу разработчиков ещё больше, потому что знаю, каково это – быть самозванцем.
Productivity Inside
Для старательного нет ничего невозможного

Комментарии 53

    +2

    А на чем он писал то?

      +2
      Судя по профилю в LinkedIn, на C, C++, Java, Python и Ruby.
      0
      274 строки кода в день без выходных?
        +1
        Тут скорее не 270 в день, а 2к строк за 2х недельный спринт. Это нормальная метрика для 10кк LOC проектов.
          +2
          274 строки кода в день без выходных?

          строки разные бывают.
          я когда и полстроки в день пишу, а когда и 1 000.
          +6
          Disclaimer: I’m not representing Amazon in any way. Opinions written here are strictly my own.

          Жуткая неправда. Без одобрения legal он не имел права опубликовать то, что опубликовано.
          Жалко, что не рассказал о Devlist, PIVOT, PIP и stack ranking квотах на увольнения :)
            +1

            Возможно, как раз они и попросили дописать этот дисклеймер

              +6
              Момент в том, что они заапрувили публикацию, и в этот момент он именно начинает представлять компанию. Если бы он опубликовал это без аппрувала — был бы наказан вплоть до увольнения. Если же он написал бы критическую статью — он бы не получил аппрувал…
              Потому его дисклеймер, для людей знакомых с этой политикой звучит как: дальше не читайте, ниже будет буллшит.
                0
                Забавно, но буллшит тут в первую очередь от вас.
                Я работаю в Амазоне и правила тут очень простые — ты имеешь право высказывать свою позицию, в том числе мнение о компании. Единственное что нужно — явно указать, что это личное мнение, а не позиция Амазона для того, чтобы избежать двусмысленных трактовок.
                  0
                  Это личное мнение?
            0
            За 5 лет он мог уже сменить три работы и вырасти намного сильнее, имхо. Промоушены внутри компании — самый медленный способ построения карьеры из возможных.
              +6
              Да, левел-ап внутри это примерно 5..10% к базовой ставке. Интереснее по деньгам получается, когда ты уходишь и бумерангом назад на следующий уровень возвращаешься.
              Цель статьи — создать позитивный имидж у народа, чтобы они шли в програмизды в Амазон.
              Нить прослеживается через всю статью: ты можешь быть тупой, но у тебя должны быть открыты уши и ты должен проактивно заглядывать в рот своему начальству — и у тебя всё получится!!!
                +1
                Почти во всех компаниях есть какое-то ограничение, сколько времени должно пройти, прежде чем снова устроиться можно.
                  +2
                  0,5-1год. В Америке это не так уж и важно, найти что-то лучше и пробыть там год — вообще не проблема. Квалифицированных по-настоящему кадров не хватает. Потому и экспериментирует Амазон с «выращиванием». Особенно любят выращивать из бывших военных, у них скиллы «послушание» и «подчинение» уже заточены :)
                    +1

                    Не Амазон, но другой FAANG. Когда я уходил мне ещё раз напомнили, что ушедших on good terms в течение года берут назад без дополнительных вопросов. Когда полтора года спустя я решил вернуться меня спросили только в какой команде я хочу работать.

                    0

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

                      +1
                      Да, это называется RSU. В случае SDE1 при найме ему дали мало RSU.
                      Промо SDE1->SDE2 практически не добавляет RSU. Подымает только base pay.
                      Потому найм сразу на SDE2 даст больше базовой ставки+RSU, чем тяжелым трудом полученное промо к SDE2.
                      Кроме того, стоит брать во внимание расписание выдачи RSU.
                      Обычно это четыре года с расписанием 10% 10% 40% 40%, а ведь 4 года можно и не выжить в Амазоне, потому RSU можно считать спекулятивной морковкой.
                      — В случае с позициями повыше, там ситуация ещё интереснее. В Амазоне есть лимит базовой ставки для всех работников. Он составляет $160k в год. Больше — нельзя.
                      Высшие чины (уровень директоров) мотивируют RSU, и там цифра база(160k)+RSU может иметь неприличные 500+k в год. Но не забывайте спекулятивное расписание 10% 10% 40% 40%, а так-же вокруг есть много других компаний, которые не имеют лимита базовой платы и директора охотно уходят при условии прибавки в 200k, причем в новой компании легко может быть такая цифра в виде базовой ставки, без или с маленькой частью спекулятивности.
                      — Кому в Амазоне жить хорошо?
                      Тем, кто лет 8-10 пришел в компанию, получил много сотен акций по цене в десятки или сотни долларов и не продал их. А теперь — миллионер. Но есть момент: для таких людей основное расписание выдачи акций уже прошло, и базовый пакет при найме уже в их собственности, а значит даже когда эти люди уйдут из Амазона, они останутся миллионерами.
                        0
                        Ну вот этот «10% 10% 40% 40%» на самом деле в первые два года просто получается деньгами как signing bonus, а потом он просто перетекает в акции из кэша. По факту это одинаковые суммы практически все 4 года.
                          0
                          По плану — да. По факту — нет. Легко могли давать четыре года назад сайнин+акции из расчета $600 за акцию, а по факту AMZN сейчас шагнул за 3000 :) Потому сайнин+база были меньше, чем потом 40% и 40% на третий и четвертый год.
                          Зато на годовом пересмотре базовой зарплаты тебе спекулируя говорят: смотри, акция 3 тыщи, и именно потому мы тебе базовую ставку подымать не собираемся, максимум подымем 0,5%, и всё… А о чём это говорит? А говорит о том, что какая бы производительность у тебя не была, тебя плюс-минус держат в рамках «плана» спекулируя ценой акции. Работники понимая это начинают вести себя в режиме «как бы досидеть 4 года и чтобы не выгнали» :) Если почитать blind, то там для всех две дилеммы: что делать после 4х лет и как играть в политику, чтобы эти четыре года продержаться.
                            0
                            Я слышал, что меньше не будет все равно, но вот базовую да — запросто могут не повысить при росте акций, плюс она как-то в грейде зафиксирована еще и если при устройстве успешно поторговался под верхний край своего грейда — то вообще хрен получишь прибавку независимо от результатов.
                        0

                        Когда я возвращался (в другой FAANG) мне посчитали все стоки которые у меня были и не успели завеститься (годовые рефрешы, все-все) и выдали их мне в качестве hiring grant.

                          0
                          До 6 мес — стоки возвращают как было с тем же календарём вестинга. После 6 мес и до 1 года — без интервью, но с новым расписанием и стоками, если мне не изменяет память
                            0

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

                    +8
                    Из статьи создалось ощущение, что карьерное развитие программиста в Амазоне в меньшей степени зависит от технических навыков и в большей степени от умения «продать» себя.
                      +6

                      Как и в большинстве других фирм.

                        0
                        Как при этом компании удается делать то, что они делают? Вот что странно. Кто же там «настоящие программисты»?
                        +3
                        Кажется у автора противоречащие параграфы в голове: я ноль в литкодах и всяких ваших алгоритмах и пришел к успеху, но на интервью надо спрашивать литкод и алгоритмы.
                        Почему, wtf?? Как это в голове умещается?
                        Понятно же что эта мода на вопросы литкода то же самое что и раньше было с люками, а раньше с различными групповыми динамиками, а раньше еще с какой-то очередной тупой идеей как набирать себе сотрудников. Каждая эпоха выдумывает себе какой-то бред, над которым следующая уже откровенно смеется. И придумывает себе очередной маразм как отфильтровывать кандидатов.
                        Я вот жду пока начнут как в армии устраивать что-то вроде «голодных битв» чтобы проверить мотивацию, того кто остался до конца — принимаем.
                          0
                          Да вроде он вполне внятно объяснил почему это надо делать. Давайте представим что все в этой статье правда и был человек который по везению проскочил. Он действительно учился у крутых профессионалов и благодаря этому смог хорошо вырасти.
                          А теперь представим что этого фильтра на алгоритмы отсеивающего менее крутых профессионалов нет, у кого бы он учился тогда?
                            0
                            Автор нигде не пишет что он «учился у крутых профессионалов». Нет никакой связи между «интервью на литкоде» и «крутыми профессионалами».
                            Тут скорее стадное чувство.
                              0
                              Мне кажется, текущий подход себя оправдывает. Компании заинтересованы в людях, которым хватает упорства и мотивации, чтобы учиться новому и использовать эту информацию в сочетании с уже имеющимися навыками. Сложившиеся процессы неплохо справляются с отбором таких людей.
                                0
                                Вы кем работаете если не секрет? HR? Прочитал ваш ответ несколько раз и не уловил ни капли смысловой информации. Это талант.
                                  0
                                  Это всего лишь цитата статьи где автор указывает с кем он работает и у каких людей учился.
                          +3
                          В компаниях FAANG повышения никто не предлагает – вы их сами просите, и не единожды

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

                            0

                            Ну, нет же. Когда у тебя в команде 10 прекрасных ребят/девчат и ты не знаешь кого продвинуть, а может быть и всех сразу. Если подчиненный вызывает тебя на one to one и высказывает свое желание о повышении, то именно с ним вы садитесь и прорабатываете план его развития и kpi, необходимый для повышения. Ждать, пока тебя повысят, не стоит. Нужно явно это высказать

                              0

                              Бывает и немного по-другому. Приходишь на one-to-one с менеджером (сейчас другой, не тот, который промоутил), и происходит дилог: "— Я тут короче доку создал, давай работать над твоим growth plan, чтобы промоутнуть через год. — А может не надо? Мне и так норм. — Ну давай попробуем, времени много не потратится, а вдруг хорошо получится."
                              ¯\(ツ)


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

                                0
                                Так менеджерам с этого тоже перепадает, они заинтересованы продвигать своих работников. (И так и должно быть)
                                  0
                                  должны по идее — но на кого нарвешься
                                0

                                А зачем? При условии, что хватает денег, зачем гнаться за всеми этими повышениями, рангами, и так далее? Если нравится сидеть и писать код, а не максимизировать KPI, то, может, стоит просто писать код и не париться?

                                  +1
                                  Их никогда не хватает. Всё-же есть разница, выплатишь ты ипотеку через 5 лет или через 20, согласитесь?
                                    0

                                    Разница, конечно, есть. Но, ИМХО, как-то так расшибаться в лепёшку, чтобы выплатить ипотеку через 5 лет, а не через 20, я смысла не вижу. Ну будет человек через 5 лет с квартирой, но он эти 5 лет мог бы радоваться жизни и спокойно писать код, а не гнаться за повышениями, KPI, менеджерами, ещё непонятно чем.


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

                                      0
                                      Ну и да и нет. Выплаченная ипотека скорее всего приводит ко второй ипотеке, которую можно сдать в рент и иметь как минимум выплату ипотеки с рентовых денег, а потом, немного позже — полностью пассивный доход.
                                      Кроме того, выплаченная ипотека это такой офигенный способ взять home equity кредит под 2-4% в размере выплаченной части (пары сотен тысяч долларов)…
                                0
                                Вот это, походу, самый разумный совет, ибо объем бумажной работы для промо просто пугает. Кроме того, часто в требованиях к промо есть пункты, которые ты можешь вообще на своих проектах не увидеть и хер пойми как их можно добыть.
                                +1
                                заволновался вдруг я тоже на самом деле не шарю, на всякий случай зашел на leetCode, открыл первую medium задачку leetcode.com/problems/longest-substring-without-repeating-characters, за три подхода к снаряду набросал решение которое иногда выполняется за 0ms, что типа выше чем 99% решений.
                                успокоился.
                                  0
                                  Ну вот зачем вы это? Пришлось в середине дня все бросить и считать строки. :)
                                  0

                                  Дело Генри Форда живёт и побеждает. На этот раз в ИТ. Возможно, это хорошо — не знаю. Лично меня совершенно не тянет ни в Яндекс, ни в FAANG, ни ещё в какой крупняк… Но если бы мне было 25 наверное не отказался бы. Факт.

                                    +1
                                    Именно так. Если Вы с опытом, то сразу стоит идти либо на SDE3 с общей компенсацией в ~250k USD. Либо в менеджеры SDM.
                                    SDE1 это позиция для выпускника местного ПТУ со специальностью «типа программист». В начале карьеры после колледжа — очень неплохо годик-полтора получить Амазон для CV
                                    0

                                    Как он красиво копипаст определил):
                                    "Использовал существующие образцы, чтобы избегать ошибок.
                                    Джуниоры нередко пытаются изобрести велосипед."

                                      0
                                      На самом деле и внутри конторы кода написано уже валом и многим просто в лом посмотреть, что из велосипедов уже есть в наличии (правда, часто написать самому все равно быстрее)
                                      0
                                      А почему не уволили на начальных этапах работы? Неужели компании готовы мириться с ужасной работой в надежде на потенциально хорошего разработчика?
                                        +1
                                        Всё джуниоры работают плохо, но одни демонстрируют полезные личные качества, перспективы развития и хорошую динамику роста, а другие нет, независимо от объёма и глубины теоретических знаний в момент трудоустройства.
                                          0
                                          Буду иметь в виду. Немного по другому всё это представлял.
                                          0
                                          Это как стартапы, только вкладывают в людей. Даже если 80% будут работать просто нормально, будут и единицы бриллиантов.
                                          +2
                                          Занимаюсь разработкой ПО, так или иначе, на протяжении последних 16 лет и до сих пор чувствую себя самозванцем.
                                          И это нормально, мне кажется. Иначе можно «забронзоветь» и перестать учиться.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое