Советы молодому гуглеру
|Давайте сегодня я вам расскажу о том, что нужно и что не нужно делать, когда вы начали работать в Google на полную ставку на начальной позиции с небольшим опытом. Сразу после университета, например. Мой опыт довольно субъективный, и опирается на собирательный образ молодых гуглеров, с которыми мне приходилось работать. Эти советы вряд ли применимы к опытным кандидатам. По крайней мере я надеюсь, что большинство описанных ошибок они совершать не будут по определению.
Вводная
Когда вы начинаете работать на полную ставку, происходит несколько вещей:
- Первую неделю или две вы ходите на orientation, где вам рассказывают про различные Google технологии, как они работают и все такое.
- После этого вы начинаете работать уже в команде. Команда выделит вам mentor – человека, который будет вам выдавать задания, отвечать на ваши вопросы и рассказывать превратности закулисной командной жизни, если повезет.
Совет 1: Изучите полезные материалы по теме
В общем, почти все, что я писала для интернов, справедливо в полной мере и тут. С той лишь разницей, что вместо хоста у вас ментор. И накал страстей немного поменьше, так как на кону у вас не стоит конверсия на полную ставку. Поэтому прочитайте, выучите наизусть и да прибудет с вами мудрость, за которую ваши сокомандники сразу вас полюбят.
Совет 2: Распределяйте нагрузку
Напрягайте ментора не на 100%, распределяйте нагрузку более равномерно между основными сокомандниками. Потому, что ваш первый performance review будет писать в основном ментор, и вы не хотите, чтобы он помнил, как он вместо того, чтобы делать свою работу, занимался с вами.
Потому, что неизбежно в самом начале дела пойдут туговато – куча новой информации, и у вас будут возникать вопросы, очень много вопросов. Так вот, желательно, чтобы ваш ментор не проклял тот день, когда он согласился стать вашим ментором, отвечая на 1005 вопрос за сегодня.
Совет 3: Do your homework
Ваш ментор не является заменой википедии, Google-поиска и внутренней документации. Да, скорее всего он знает ответ на вопрос, на который бы вы потратили 10 минут в поиске, сходу. Но это не значит, что правильный ответ – сэкономить 10 минут и спросить ментора. Do your homework. И только потыкавшись какое-то время в проблему самостоятельно и застряв, спрашивайте ментора или других сокомандников.
Ментор – это ментор, а не ваша персональная няня для работы, которая сразу же должна решать ваши проблемы. Ментор нужен для того, чтобы помочь, когда вы застряли, а не решать тривиальные задачи.
Совет 4: Думайте!!!
Допустим, вы запускаете все тесты к проекту, какие-то тесты не проходят.
Неправильная реакция: Идти за ментором и просить вам объяснить где и почему ваш код поломал тесты.
Нормальная реакция: Посмотреть какие именно тесты упали, попытаться оценить насколько ваш код имеет отношение к этим тестам и к этим поломкам. В Google в частности есть информация, когда какие тесты проходили в последний раз. И если это было вчера, а код вы написали сегодня, то почти наверняка ваш код не является главной причиной поломки. Почитайте тексты ошибок и попытайтесь понять, насколько они имеют отношения к вашему коду. И так далее.
Совет 5: Решайте проблему глобально
Допустим, в прошлом пункте оказалось, что тест поломал кто-то другой. В этом случае не ограничивайтесь “а, хорошо, я тут было испугался”, а спросите у метнора или кто там вам помогает “А что в этой ситуации обычно делают? Как мне найти кто поломал тест? Лучше попробовать самому починить, или написать виновнику, или оставить все как есть? Что в этом случае принято в команде?”
Совет 6: Запоминайте!
Если вам ответили на ваш вопрос и рассказали как делать ту или иную вещь, то либо запишите, либо запомните. Но лучше запишите. И запомните золотое правило новичка: Никогда не задавайте одному человеку один и тот же вопрос дважды, если вы сказали ему, что поняли его ответ в первый раз. Если дело совсем трындец, вы ничего не записали, и решение забыли, то спрашивайте другого коллегу. Когда тот, кто вам давал ответ изначально в отпуске :).
Но постарайтесь нарушать это правило по-минимуму.
Совет 7: Никакого говнокода
В Google вам надо будет посылать свой код на review. И поверьте мне, это не пустая формальность. Поэтому постарайтесь, чтобы ваш ментор во время ревью вашего кода не выглядел так:
А именно:
- удалите закомментированный код
- напишите нормальные комментарии, которые поймет любой человек, читающий ваш код
- удостоверьтесь, что код читабельный – достаточное количество пробелов, пустых строк между функциями итп.
- удостоверьтесь, что код написан без грамматических ошибок, и комментарии тоже (variable, не veriable)
- удостоверьтесь, что структура кода нормальная – никаких мега-функций на 1000 строк
- и еще много других вещей…
Хорошая новость, что у вас будет доступ к базе кода вашей команды, поэтому не поленитесь, посмотрите как пишет код ваш ревьюер и ваша команда, и постарайтесь следовать похожим правилам.
И еще на Амазоне можно найти много хороших книжек о том, как писать хороший код – почитайте. Если совсем не знаете, с чего начать, почитайте Code Complete. И про Pragmatic programmer не забудьте, это вообще обязательное чтиво для всех, кто хочет быть хорошим программистом.
Совет 8: Не совершайте одну и ту же ошибку дважды
Допустим, вы посылаете ваш код на ревью, и вам ревьюер пишет “Пожалуйста, пиши более подробное описание к коду, чем some stuff”. Так вот – худшее, что вы можете сделать, это в следующий раз послать описание “some stuff”.
Тут я имею ввиду не спорные моменты – вроде того, что один ревьюер предпочитает писать “int& var”, а другой “int &var”. А именно принципиальные для коменды вещи – стандарты качества комментарием и написания документов, количество и качество тестов к коду итп. Если вам сказали, что важно писать комментарии или тесты к коду, то впредь не посылайте ни одного изменения без тестов и комментариев.