Советы молодому гуглеру

Давайте сегодня я вам расскажу о том, что нужно и что не нужно делать, когда вы начали работать в Google на полную ставку на начальной позиции с небольшим опытом. Сразу после университета, например. Мой опыт довольно субъективный, и опирается на собирательный образ молодых гуглеров, с которыми мне приходилось работать. Эти советы вряд ли применимы к опытным кандидатам. По крайней мере я надеюсь, что большинство описанных ошибок они совершать не будут по определению.

Вводная

Когда вы начинаете работать на полную ставку, происходит несколько вещей:

  1. Первую неделю или две вы ходите на orientation, где вам рассказывают про различные Google технологии, как они работают и все такое.
  2. После этого вы начинаете работать уже в команде. Команда выделит вам mentor – человека, который будет вам выдавать задания, отвечать на ваши вопросы и рассказывать превратности закулисной командной жизни, если повезет.

Совет 1: Изучите полезные материалы по теме

В общем, почти все, что я писала для интернов, справедливо в полной мере и тут. С той лишь разницей, что вместо хоста у вас ментор. И накал страстей немного поменьше, так как на кону у вас не стоит конверсия на полную ставку. Поэтому прочитайте, выучите наизусть и да прибудет с вами мудрость, за которую ваши сокомандники сразу вас полюбят.

Совет 2: Распределяйте нагрузку

Напрягайте ментора не на 100%, распределяйте нагрузку более равномерно между основными сокомандниками. Потому, что ваш первый performance review будет писать в основном ментор, и вы не хотите, чтобы он помнил, как он вместо того, чтобы делать свою работу, занимался с вами.

Потому, что неизбежно в самом начале дела пойдут туговато – куча новой информации, и у вас будут возникать вопросы, очень много вопросов. Так вот, желательно, чтобы ваш ментор не проклял тот день, когда он согласился стать вашим ментором, отвечая на 1005 вопрос за сегодня.

Совет 3: Do your homework

Ваш ментор не является заменой википедии, Google-поиска и внутренней документации. Да, скорее всего он знает ответ на вопрос, на который бы вы потратили 10 минут в поиске, сходу. Но это не значит, что правильный ответ – сэкономить 10 минут и спросить ментора. Do your homework. И только потыкавшись какое-то время в проблему самостоятельно и застряв, спрашивайте ментора или других сокомандников.

Ментор – это ментор, а не ваша персональная няня для работы, которая сразу же должна решать ваши проблемы. Ментор нужен для того, чтобы помочь, когда вы застряли, а не решать тривиальные задачи.

Совет 4: Думайте!!!

Допустим, вы запускаете все тесты к проекту, какие-то тесты не проходят.

Неправильная реакция: Идти за ментором и просить вам объяснить где и почему ваш код поломал тесты.

Нормальная реакция: Посмотреть какие именно тесты упали, попытаться оценить насколько ваш код имеет отношение к этим тестам и к этим поломкам. В Google в частности есть информация, когда какие тесты проходили в последний раз. И если это было вчера, а код вы написали сегодня, то почти наверняка ваш код не является главной причиной поломки. Почитайте тексты ошибок и попытайтесь понять, насколько они имеют отношения к вашему коду. И так далее.

Совет 5: Решайте проблему глобально

Допустим, в прошлом пункте оказалось, что тест поломал кто-то другой. В этом случае не ограничивайтесь “а, хорошо, я тут было испугался”, а спросите у метнора или кто там вам помогает “А что в этой ситуации обычно делают? Как мне найти кто поломал тест? Лучше попробовать самому починить, или написать виновнику, или оставить все как есть? Что в этом случае принято в команде?”

Совет 6: Запоминайте!

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

Но постарайтесь нарушать это правило по-минимуму.

Совет 7: Никакого говнокода

В Google вам надо будет посылать свой код на review. И поверьте мне, это не пустая формальность. Поэтому постарайтесь, чтобы ваш ментор во время ревью вашего кода не выглядел так:

wtf

А именно:

  • удалите закомментированный код
  • напишите нормальные комментарии, которые поймет любой человек, читающий ваш код
  • удостоверьтесь, что код читабельный – достаточное количество пробелов, пустых строк между функциями итп.
  • удостоверьтесь, что код написан без грамматических ошибок, и комментарии тоже (variable, не veriable)
  • удостоверьтесь, что структура кода нормальная – никаких мега-функций на 1000 строк
  • и еще много других вещей…

Хорошая новость, что у вас будет доступ к базе кода вашей команды, поэтому не поленитесь, посмотрите как пишет код ваш ревьюер и ваша команда, и постарайтесь следовать похожим правилам.

И еще на Амазоне можно найти много хороших книжек о том, как писать хороший код – почитайте. Если совсем не знаете, с чего начать, почитайте Code Complete. И про Pragmatic programmer не забудьте, это вообще обязательное чтиво для всех, кто хочет быть хорошим программистом.

Совет 8: Не совершайте одну и ту же ошибку дважды

Допустим, вы посылаете ваш код на ревью, и вам ревьюер пишет “Пожалуйста, пиши более подробное описание к коду, чем some stuff”. Так вот – худшее, что вы можете сделать, это в следующий раз послать описание “some stuff”.

Тут я имею ввиду не спорные моменты – вроде того, что один ревьюер предпочитает писать “int& var”,  а другой “int &var”. А именно принципиальные для коменды вещи – стандарты качества комментарием и написания документов, количество и качество тестов к коду итп. Если вам сказали, что важно писать комментарии или тесты к коду, то впредь не посылайте ни одного изменения без тестов и комментариев.