Гид по выживанию для разработчиков ПО
Rubrain.com подготовил для вас перевод отличной статьи “A Software Engineering survival guide“. Если вы решили построить карьеру в качестве разработчика программного обеспечения, эта статья будет отличным подспорьем на первых этапах
Навыки, которые помогут вам в начале вашей карьеры
Первые несколько лет моей карьеры стали периодом интенсивного обучения. Я столкнулся с реалиями профессии разработчика и должен было освоить те навыки, о необходимости которых я даже не предполагал в начале. Оглядываясь назад я понимаю, что было бы неплохо все это знать и уметь в самом начале профессионального пути.
Итак, я написал это руководство, основываясь на опыте сотрудничества с разработчиками, начинающими свою карьеру (первые несколько лет профессиональной деятельности), а также на собственном опыте и опыте моих коллег.
Я расскажу:
- Как успешно провести/пройти интервью
- Как выжить (и процветать) в профессии разработчика ПО
- И какие ресурсы нужно учитывать для постоянного развития.
Интервью
Как только вы начнете карьеру разработчика ПО, вы сразу столкнетесь с одним неоспоримым фактом. Интервью – отстой.
Они могут быть просто ужасными для всех участников. Будучи как интервьюером, так и интервьюируемым, могу с уверенностью сказать, что интервью отнимает очень много времени, нервов и это реально может отразиться на эффективности вашей будущей работы. Тем не менее интервью – это тот ад, к которому и вам, и кандидату лучше подготовиться.
Подготовка к битве
Если вы решили построить свою карьеру в области разработки программного обеспечения, обязательно изучите наиболее часто используемые тестовые кейсы по программированию, например, «FizzBuzz»:
“Напишите программу, которая печатает числа от 1 до 100. Но вместо чисел, кратных трем, необходимо печатать «Fizz», а вместо чисел, кратных пяти – «Buzz». Вместо чисел, которые одновременно кратны и трем, и пяти, программа должна печатать «FizzBuzz»”. (Кодовый хоррор)
Звучит достаточно просто, не так ли?
Ну, подавляющее большинство опрашиваемых проваливают этот простой тест, не говоря уже о более сложных вариантах.
Я лично видел, как многие кандидаты на позиции уровня senior не прошли этот тест, имея полный доступ в Интернет. Поэтому, если в вашем резюме указан язык программирования, то убедитесь, что вы точно знаете, как сделать в нем хотя бы “FizzBuzz”. В противном случае вы просто тратите свое и чужое время.
Конечно, для выживания на интервью вам нужно знать гораздо больше, чем просто FizzBuzz.
Вы также должны убедиться, что знаете:
- Основные структуры данных и алгоритмы: такие как связанные списки, массивы, древовидные структуры и сортировки.
- Стандартные подводные камни выбранного вами языка программирования, такие как неизменяемость строк и способы управления памятью.
- Объектно-ориентированные концепции программирования, такие как “класс против объекта” и наследование.
В начале вашей карьеры вам нужно блистать в этих вопросах, так как у вас еще нет опыта работы, который смог бы подтвердить ваш уровень. Есть два ресурса, которые я всегда рекомендую при подготовке к интервью:
- «Cracking the Coding Interview» – фантастическая книга, в которой много полезной информации о проблемах с кодированием и их решениях, а также список навыков, которыми вам нужно обладать, чтобы решать аналогичные проблемы самостоятельно
- CodeWars – сайт с огромной подборкой кейсов по программированию, которые вы можете решить прямо в браузере, выбрав нужный вам язык. Самое полезное на CodeWars – возможность посмотреть как решали эту проблему другие пользователи. Так вы сможете увидеть различные подходы к одной и той же проблеме и изучить новые инструменты выбранного вами языка программирования.
Предусмотрите дополнительное преимущество
Есть несколько вещей, сделав которые, вы дадите себе дополнительную фору:
Во-первых, научитесь рассказывать о своем опыте. У вас должна быть заготовлена короткая емкая презентация, который суммирует опыт и знания, указанные в вашем резюме, в последовательный и интересный рассказ.
Кроме того, крайне важно знать свое собственное резюме! Это звучит глупо, но я сам не раз сталкивался с тем, что многие кандидаты испытывали трудности, объясняя конкретный пункт из их резюме. Вы должны быть в состоянии ответить на вопросы о любом из пунктов, который вы упомянули в своем резюме, и объяснить, какое значение он имеет для вас как для лучшего кандидата на эту вакансию.
Далее, необходимо, чтобы примеры написанного вами кода были загружены на GitHub (или на другом открытом ресурсе).
Видеть – это верить, и интервьюеры, которые смогут ознакомиться с вашим кодом, будут смотреть на вас совсем по-другому. Кроме того, наличие написанного вами кода в открытых источниках показывает, что вы понимаете системы контроля версий.
Примеры кода не должны быть слишком сложными, но они должны быть чистыми и демонстрировать хорошие методы написания кода. Это ваш шанс показать, как вы программируете в нормальных условиях (а не в стресс-условиях теста на интервью).
После того, как вы все это сделали, пришло время принять участие в проекте с открытым исходным кодом. Наличие такого опыта покажет, что вы можете работать с уже существующим кодом (написанным кем-то другим) и взаимодействовать с другими программистами.
Это будет примером работы, максимально приближенной к программированию в промышленной среде. На сегодняшний день это самый сложный и трудозатратный способ получить преимущество на интервью, поэтому советую вернуться к нему, когда все задачи, описанные мною выше, будут сделаны.
Проинтервьюируйте своего интервьюера
В суете и стрессе, связанными с поиском работы, многие кандидаты забывают, что интервью – это “улица с двусторонним движением”. Поскольку компания пытается выяснить, являетесь ли вы подходящим кандидатом для работы, вы должны выяснить, подходит ли компания для вас.
Удостоверьтесь, что вы задали все необходимые вопросы, даже если для этого вам придется отправить дополнительный e-mail уже после интервью. Имейте в виду, что часто компании могут не пользоваться преимуществом наиболее эффективных современных технологий, поэтому поэтому научитесь читать между строк.
Вот несколько вопросов, которые вы можете задать:
«Каким будет мой типичный рабочий день?»
Важно знать, чего ожидать от конкретной позиции, потому что все вакансии разработчиков программного обеспечения очень похожи в своих описаниях. Например,ожидаемо, что вы будете обслуживать серверы или общаться напрямую с клиентами.
Будьте внимательны: ответ «Я не уверен» означает, что интервьюер не является частью вашей будущей команды и/или у него нет четкого представления зачем компания нанимает вас.
«Как вы тестируете свое программное обеспечение?»
В идеале для проверки качества кода следует использовать комбинацию модульного тестирования, ручного тестирования и автоматического тестирования.
Будьте внимательны: ответ «Мы просто пишем код без ошибок, ха-ха» означает, что перед вами тот самый человек, который плодит баги в коде.
«Какую систему контроля версий вы используете?»
Системы контроля версий чрезвычайно полезны для совместной работы, и нет никаких оснований игнорировать их в профессиональной среде.
Будьте внимательны: ответ «Хм, система контроля версий?» означает только одно, бегите оттуда как можно дальше!
Будьте внимательны 2: “<insert obscure or custom VCS>” говорит о том, что скорее всего они не укладываются в дедлайны и не обновляли инфраструктуру в течение долгого времени.
«Вы делаете экспертные оценки?»
Экспертные оценки, или наличие кого-то еще, кто сможет оценить ваш код прежде чем он попадает в общую базу – это превосходный способ обнаружить глупые ошибки, который просто жизненно важен для обучения в начале карьеры.
Будьте внимательны: ответ «Мы доверяем друг другу!» означает, что скорее всего, senior-разработчики в этой компании очень трепетно относятся к своему коду и не любят получать по нему фидбек.
«Какие программы непрерывного образования у вас есть?»
Быть разработчиком ПО это значит постоянно обучаться и получать новые знания по мере появления новых технологий, которые сегодня заменяют устаревшие с головокружительной скоростью. Во многих компаниях выделяется бюджет на обучение, который используется для оплаты университетских и онлайн занятий, конференций или внутренних образовательных встреч.
Будьте внимательны: ответ «Вы имеете в виду самостоятельное ознакомление с материалами в Интернете в свободное время?» означает, что компания либо не выделяет средства на образование разработчиков, либо рассматривает разработчиков как временную, а не долгосрочную инвестицию.
«Какой процесс разработки программного обеспечения вы используете?»
Процесс имеет жизненно важное значение для разработки программного обеспечения, независимо от прочих деталей. Конечно, составляющие оптимального процесса должны подвергаться регулярным спорам, но само существование согласованного способа работы над проектом сводит к минимуму хаос и гарантирует, что все находятся на одной странице.
Будьте внимательны: ответ «Наш процесс похож на джазовую импровизацию» скорее всего, означает, что весь отдел находится в режиме пожаротушения, прыгая с одной чрезвычайной ситуации на другую без какой-либо четкой логики.
«Что вы делаете с техническим долгом?»
Технический долг – это накопление устаревших технологий и “костылей” в кодовой базе. Регулярная работа над этим чрезвычайно важна для успешной работы кода в долгосрочной перспективе.
Будьте внимательны: ответ «Мы ориентируемся исключительно на новые функции» означает, что в их кодовой базе творится полный беспорядок.
«Какая у вас корпоративная культура?»
Корпоративная культура может быть описана достаточно обтекаемо, но даже такие особенности, как опенспейс и кабинки, могут значительно изменить ваше повседневное взаимодействие с коллегами. Для этого вопроса нет особых предупреждений, просто убедитесь, что ответ вашего собеседника – это то, с чем вы можете комфортно существовать несколько лет в течение 40 часов в неделю.
Работа в качестве разработчика ПО
На этом этапе, если вы хорошо себя проявили на интервью и вас устроили ответы компании-нанимателя, вас, скорее всего, приняли на работу.
Поздравляю, теперь вы официально разработчик!
Что теперь? Ну, пришло время учиться много заново и много работать. И поскольку мы программисты, давайте начнем с обсуждения кода.
Хороший промышленный код
Хороший промышленный код должен обладать следующими свойствами (в порядке убывания значимости):
- Читаем, потому что код читается и поддерживается чаще, чем создается. Состав кода должен быть понятен для других разработчиков даже спустя годы после того, как вы его написали.
- Защищен, самыми современными методами защиты программного кода. Защищенное кодирование – отдельная тема, но суть заключается в следующем: вы должны убедиться, что неправильное использование классов и методов, которые вы написали, не приведет к сбою программного кода.
- Оптимизирован, последний пункт в этом списке, потому что большую часть времени вам не нужно думать об этом. Это не значит, что вы должны создавать плохой код, который делает что-то в O(n³), когда существует линейное решение. Но разработчики, как правило, стремятся переоптимизировать код, но в этом нет острой необходимости, тем более что часто это делается в ущерб читабельности и защищенности кода. Вы всегда должны быть в состоянии доказать, что выбранная вами оптимизация действительно необходима.
Теперь, когда вы знаете, как написать хороший код для проекта…
Вы не будете писать много кода
Это может стать неожиданностью, но большую часть времени вы не будете писать новый код, а вместо этого вы будете:
- искать и исправлять баги;
- читать существующий код;
- проводить время на встречах и писать письма;
- планировать свои дальнейшие действия.
Поэтому и те навыки, которые не касаются кодирования, будут столь же полезны для вашей карьеры.
Отладка и чтение кода
- От вас потребуется нечто большее, чем отладка с использованием логгирования (журналирования). Все широко используемые языки и технологические стеки имеют множество встроенных мощных инструментов. Научитесь использовать их, поскольку они сделают отладку легкой и позволят вам сэкономить бесчисленные рабочие часы.
- Разберитесь с кодовой базой. У большинства технологических стеков есть свои инструменты генерации кода, которые помогут вам изучить структуру кодовой базы. Корпоративные IDE обычно имеют встроенный функционал для этого. Вы также можете изучить код с помощью таких инструментов как ReSharper, grep или Sourcegraph.
- Разобраться с продуктом. Вы будете удивлены, но многие разработчики начинают исправлять код, толком не разобравшись, как создаваемое ими программное обеспечение должно на самом деле работать. Просто ознакомьтесь с документацией.
Организуйте свои мысли
Поскольку существенная часть вашего рабочего времени будет уходить на коммуникации, исследования и многозадачность, вам точно пригодятся инструменты, которые помогут организовать ваши проекты, задачи и контакты.
- Списки дел /таск-менеджеры: у вашей компании должно быть предусмотрено какое-то программное обеспечение для корпоративных задач, но оно также применимо и для личных целей. Используйте заметки-наклейки или соответствующие приложения, например, Trello или Todoist.
- Заметки. Всегда делайте заметки на собраниях, работайте над улучшением существующей документации и создавайте личную базу знаний. Используйте Evernote, OneNote или ноутбук по старинке. Это может показаться излишним, но вы будете благодарны себе за это год спустя, ведь вам не потребуется потратить 3 дня, чтобы разобрать эту задачу так, как будто вы видите ее впервые. Я никогда не встречал хорошего программиста, который не вел бы полноценные заметки.
- Диаграммы / Визуализации: Люди лучше всего воспринимают визуальную информацию, и создание диаграмм процессов и архитектур поможет вам и другим разобраться в сложных темах. Диаграммы особенно полезны при общении с нетехническими коллегами. Используйте Lucidchart, Visio или обычную меловую или маркерную доску.
Когда использовать библиотеки
Короткий ответ: Почти всегда.
Длинный ответ: 99% времени, вы не должны изобретать велосипед. Это не значит, что вы не должны знать, как работают алгоритмы и структуры данных, поскольку это поможет вам решить, что именно использовать из библиотеки и когда.
- Чтобы стать эффективным разработчиком, необходимо внимательно изучить библиотеки, которые есть в вашем распоряжении. Стандартные библиотеки самых популярных языков чрезвычайно полезны и могут помочь вам гораздо больше, чем вы предполагаете. Кроме того, кодовая база может также использовать дополнительные специализированные библиотеки. Изучите документацию и узнайте, когда их использовать.
- Не нужно бояться предлагать дополнительные библиотеки, если они позволят сэкономить время вам и вашим коллегам. Однако предварительно необходимо убедиться, что вы выбрали хорошую библиотеку для использования в проекте.
Хорошая библиотека – это:
- Открытый исходный код (open source). Это значит, что вы можете самостоятельно проверить качество кода и, возможно, исправить критические для вашего приложения ошибки
- Одобрена такими лицензиями, как MIT и BSD. Это значит, что ваша компания не столкнется с проблемами, используя эту библиотеку. Будьте осторожны с GPL, чтобы случайно не “слить” всю вашу кодовую базу в open source .
- Используется на протяжении длительного времени. Это значит, что библиотека существует уже давно и имеет богатый набор функций.
- Поддерживается в актуальном виде (часто появляются новые релизы и обновления).
- Используется другими компаниями или проектами. Это и своеобразный знак качества, и гарантия того, что библиотека будет поддерживаться и обновляться и дальше.
Непрерывное развитие
Помимо обучения навыкам, которые сделают вас лучше в повседневной работе, вам также необходимо постоянно совершенствовать остальные свои навыки и изучать новые, чтобы создавать новые возможности для карьерного роста.
Возможностей для обучения огромное количество, и многие из них вполне доступны:
- Онлайн-курсы: нельзя упускать возможность учиться у лучших в профессии. Проверьте Coursera, Udacity и edX (и не только) на курсы, которые могут развить и дополнить ваши существующие навыки.
- Онлайн-магистратуры: получение степени магистра онлайн достаточно свежая тенденция среди университетов, и вместе с тем – отличный способ продолжить образование. Онлайн образование обычно дешевле, чем очное, при этом большинство программ стоят примерно 10 000 долларов США за весь период обучения. Georgia Tech, UT и UC San Diego – некоторые из университетов, предлагающих такие степени. Я лично рекомендую онлайн-магистратуру Georgia Tech, которую я окончил в этом году.
- Блоги: Блоги – важная часть сообщества разработчиков (здесь нет ничего удивительного, поскольку вы читаете его прямо сейчас). Такие блоги, как Coding Horror, Joel on Software или даже более юмористические веб-сайты, такие как The Daily WTF, могут дать вам представление о том, что должны и не должны делать разработчики ПО. Изучайте статьи на Medium, r/programming, HackerNews и на других тематических каналах.
- Конференции. Наконец, но не в последнюю очередь, конференции – это отличная возможность для обучения, и вы обязательно должны воспользоваться образовательным бюджетом вашей компании для посещения таких мероприятий. Очень неполный список хороших конференций: GOTO; (General), Strange Loop (General), PyCon (Python), CPPCon (C ++), DEF CON (Security), Fluent (Web dev). У большинства конференций есть видео выступлений и обсуждений на YouTube, поэтому вы можете научиться чему-то новому даже без личного присутствия!
Надеюсь, эта статья вооружила вас знаниями о том, чего ожидать от начала вашей карьеры разработчика ПО и какими инструментами пользоваться, чтобы это стало захватывающим приключением!
Тяжела профессия разработчика ПО, однако.
Статья хорошая.
ИЗ собственного опыта хочу добавить:
1. Не знаю как на западе, но в России в рядовой компании, джунов на собесе просто стирают в порошок (причем стирают морально, очень часто ведя себя надменно), особенно если это компания с "неадекватным" подходом к набору сотрудников или с неадекватными сотрудниками. На заре своего пути как программиста я натолкнулся на парочку таких компаний.
2. Если на новом месте заставляют править баги дольше чем 1, максимум 2 месяца, то пора думать о смене работы, даже если тебе с трудом удалось попасть на это место, это путь в никуда.
3. Новичкам очень полезно почаще менять место работы, как это странно бы не звучало, чем больше посмотрите "как у других", тем лучше у вас будет представление как правильно работать, строить процессы.
4. Не стоит скромничать говоря о ЗП, просите столько, сколько считаете нужным :)
согласна! На самом деле все хотят middle или senior, и в России и на Западе, но для junior шанс- крупные компании, которые могут позволить себе большой штат