От переводчика: Валерий Алексиев, опытный программист, рассказал о том, что лучше делать разработчику ПО в самом начале карьерного пути. В частности, какие инструменты стоит использовать и на что обращать внимание на собеседованиях.

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

Собеседования


Начав карьеру программиста, вы сразу поймете, что собеседования — отстой. Они могут быть ужасными для всех вовлеченных сторон. Это просто убийцы времени, стресс-образующий фактор и первое препятствие на пути к успешной карьере. Но вам придется иметь с ними дело, так что лучше знать, к чему готовиться.

Подготовка к битве

Вопросы и задачи могут быть самыми разными, в качестве примера приведу популярную задачу FizzBuzz.

Напишите программу, которая выводит цифры от 1 до 100. Но для чисел, кратных трем, нужно выводить Fizz вместо самой цифры, а для чисел, кратных пяти, Buzz. Для чисел, которые кратны и трем, и пяти, выводите на экран слово FizzBuzz.

Вроде бы все просто и ясно, как день, верно? На самом деле большинство начинающих программистов на собеседовании проваливают это задание. Я видел даже случаи, когда задачу не выполняли претенденты на позицию senior, причем у них был доступ к сети. Мой совет — выполните эту задачу до собеседования на том языке программирования, который вы используете чаще всего. В противном случае собеседование станет пустой тратой времени для всех его участников.

Конечно, вам необходим гораздо больший объем знаний. В частности:

  • Основные структуры данных и алгоритмы: связанные списки, массивы, деревья и сортировки.
  • Общая информация о «вашем» языке, включая неизменяемость строк, управление памятью и другое.
  • Объектно-ориентированные концепции программирования, такие как класс vs объект и наследование.

Все это необходимо в буквальном смысле отполировать до блеска, если вам хочется себя показать с лучшей стороны. Я могу посоветовать вот такие ресурсы, которые помогут подготовиться к собеседованиям:

  • “Cracking the Coding Interview”, просто фантастическая книга, которая содержит информацию о большом количестве проблем программирования и их решениях;
  • CodeWars, сайт с необычными задачами по программированию, которые вы сможете решить прямо в браузере при помощи различных языков.

Skillbox рекомендует: Практический курс «Профессия веб-разработчик».

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

И еще немного всего



Есть еще пара моментов, которые помогут вам приобрести дополнительные знания и опыт.

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

Во-вторых, выкладывайте примеры своего кода на GitHub или любой другой открытый репозиторий. Образцы кода не должны быть слишком сложными, но код нужно сделать чистым и рациональным. Это ваш шанс показать часть своих умений еще до интервью.

Попробуйте принять участие в open-source-проекте. Это покажет ваш опыт и научит работать в команде.

Собеседуйте вашего интервьюера

Да, на собеседовании должны спрашивать не только вас. Вы можете и должны интересоваться различными нюансами своей будущей работы и компании. Внимательно прислушивайтесь к ответам. Они могут быть очень важными, содержать явную и не очень информацию о том, что представляет собой новая компания, ее команда и работа.

Вот примеры вопросов, которые стоит задавать.

Каким будет мой стандартный рабочий день?
Это важный вопрос, поскольку задачи разработчика ПО в разных компаниях могут заметно отличаться. Если ответ будет не слишком уверенным или расплывчатым, можете считать это предупреждением, индикатором того, что здесь что-то не так. У человека, который вас нанимает, должно быть четкое понимание того, зачем вы компании.

Как вы тестируете ваше ПО?
В идеале тестирование должно быть достаточно разнообразным. Если ответом будет нечто вроде «Мы просто сразу все пишем без багов, хаха», — стоит понимать это так, что ошибки есть, но исправлять их никто не хочет или не может.

Какую систему контроля версий вы используете?
Важный вопрос, поскольку это необходимо для работы в команде. Если ответ: «Что, система контроля версий?» — то убегайте с такого собеседования быстро и далеко.



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

Вы проводите ревью кода?
На самом деле, ревью кода — важный этап работы в команде, поскольку он позволяет выявлять многие ошибки. Если вам отвечают отрицательно, значит, командная работа поставлена не очень хорошо. Конечно, могут быть и исключения, но в большинстве случаев это так. Если вам говорят нечто вроде «Мы доверяем друг другу», то стоит задуматься. Скорее всего, в этой компании никто ничего не выверяет.

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



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

Как вы решаете проблему технического долга?
Технический долг, или долг кодинга — термины, которые обозначают баги-долгожители в коде или архитектуре приложения. Проблемы накапливаются и в конце концов становятся весьма серьезным препятствием для дальнейшей работы над проектом.

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

Что вы можете расказать о корпоративной культуре?
У разных компаний атмосфера и культура очень разные. Но имейте в виду, что вам нужно будет находиться внутри коллектива 40+ часов в неделю в течение нескольких лет, так что прислушивайтесь к тому, что вам говорят.

Работа в качестве программиста


Окей, вы прошли все стадии собеседования и устроились на работу. Поздравляю!



Что теперь? Нужно осознать много интересных и не очень вещей. Поскольку мы программисты, давайте остановимся на обсуждении кода.

Хороший код

Он должен соответствовать следующим критериям:

  • Быть читаемым, ведь код анализируют гораздо чаще, чем пишут. Так что ваш код должен быть читаемым и понятным как вам самому, так и коллегам.
  • Надежным. Вы должны быть уверены в том, что все классы и методы используются корректно и не приведут к падению программы.
  • Оптимизированным. Не стоит быть перфекционистом, но и регулярно рецензировать свой код все же нужно. Вы всегда должны быть готовы провести небольшую оптимизацию кода.

Вот еще несколько вещей, которые вам предстоит усвоить.

Вы не будете много программировать.

Да, это может показаться странным, но действительно гораздо больше времени вы будете проводить за:

  • отладкой;
  • чтением кода;
  • встречами и написанием e-mail/ответов;
  • планированием.

И еще давайте поговорим о скиллах, которые важны для карьеры программиста.

Отладка и чтение кода



  • Для того, чтобы стать профи в отладке, нужно определиться с соответствующим инструментарием. У большинства популярных языков программирования есть необходимые средства для отладки. Ознакомьтесь с ними, научитесь их использовать, — это сэкономит вам бесчисленные часы.
  • Разберитесь с основой, структурой базы кода. Вы сможете изучать код при помощи таких инструментов, как ReSharper, grep или Sourcegraph.
  • Изучите мануалы. Вы удивитесь, если узнаете, как мало разработчиков изучают техническую документацию. В результате многие просто не знают, как должно работать программное обеспечение, а значит, больше времени уходит на отладку. Просто читайте документацию — это сэкономит вам время.

Организация и планирование

Поскольку вам много придется много общаться с коллегами, заниматься планированием и выполнять таски (причем некоторые — одновременно), нужно уметь организовывать свое время. В этом вам помогут:

  • TODO/задачи. У вашей компании, скорее всего, есть система ведения тасков и контроля их выполнения, но не помешает завести собственную систему. Используйте Trello, Todoist или что-то еще.
  • Заметки. В процессе работы часто нужно запоминать разные нужные мелочи. Лучше всего их записывать — например, при помощи Evernote, OneNote и других инструментов.
  • Графики и визуализация. Лучше всего оценивать эффективность своей работы при помощи таких инструментов, как Lucidchart, Visio и других.

Когда использовать библиотеки?

Практически всегда. Нет нужды изобретать велосипед снова и снова. В большинстве случаев работа без библиотек приводит к потере времени. Конечно, это не значит, что вы должны оставаться в неведении насчет того, как использовать алгоритмы или какова структура баз данных, — ведь вам нужно понимать, как и где все это использовать.

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

Вы не должны бояться работать с дополнительными библиотеками, если они помогают сэкономить время. Это могут быть:

  • Open-source-библиотеки, где вы можете оценить качество кода.
  • Библиотеки по лицензии MIT и BSD, вы можете использовать их без проблем. C осторожностью относитесь к GPL.
  • Те, что уже находятся в употреблении продолжительное время и обладают широким спектром возможностей.
  • Поддерживаемые — те, что регулярно получают обновления.
  • Используемые другими компаниями/проектами, что может свидетельствовать об их надежности.

Постоянно совершенствуйтесь

Это может звучать банально, но учиться нужно даже во время работы, а также в свободное время — каждый день. В этом помогают онлайн-курсы, книги, блоги, а также второе (третье) образование. Также стоит уделять внимание конференциям и разного рода воркшопам. Среди наиболее известных конференций я бы выделил GOTO (общее направление), Strange Loop (тоже общее), PyCon (Python), CPPCon (C++), DEF CON (безопасность), Fluent (webdev).

Комментарии (15)


  1. KevlarBeaver
    13.11.2018 15:33
    +1

    Не хочу выпендриваться, но никогда не понимал, даже ещё будучи совсем нубом, как вообще можно FizzBuzz написать неправильно. Более того, не понимаю, как можно претендовать на роль программиста будучи неспособным написать эту «программу». Я допускаю, если человека будут бить током, вокруг — водить хороводы цигане с медведями, а за час до этого он примет тройную дозу слабительного — то может поошибаться и с первого-второго прогона программа отработает некорректно, ну так возьми ещё пять минут и исправь. Это уж действительно, не ракеты в космос запускать.


    1. BubaVV
      13.11.2018 18:00

      Тут недавно проскакивала статья про развод работодателей кандидатами. Так что от такого вопроса хуже точно не будет


    1. Magikan
      13.11.2018 19:06
      +3

      Оу, Вы даже не представляете какие кадры приходят на роль middle/senior/team leader. Такого насмотришься и наслушаешься, что аж глаза вытекают и уши кровоточат…
      Junior'ы за частую показывают себя куда, как лучше.


      1. KevlarBeaver
        14.11.2018 18:40

        Не представляю. Никогда небыл со стороны собеседующих. Но, разве нельзя о человеке представление заиметь до того, как он прийдёт на собеседование? Ну я понимаю, что в резюме можно что угодно написать и с предыдущими местами работы что-то придумать… но есть же другие симптомы: pet-проекты, например… да и просто можно по телефону поговорить… не знаю.


    1. cyberly
      14.11.2018 07:35

      Ну, например, есть риск «обмануть самого себя», решив, что if/else — это слишком тупо, изобрести что-нибудь более изящное, а потом в этом запутаться (вероятность запутывания несколько увеличивает непривычная обстановка). А если результат проверяет робот (при онлайн-собеседовании), добавляются всякие риски типа «забыл, что надо было выводить через запятую».

      Специально попробовал написать, заработало только со второго прогона. Случился мой классический косяк — скопипастил условие проверки делимости и забыл поправить делитель.


      1. KevlarBeaver
        14.11.2018 18:30

        изобрести что-нибудь более изящное

        Ну я бы на собеседовании не занимался всё же изобретательством. А на месте собеседующего спросил, мол, парень, зачем выпендриваешься, реши задачу «в лоб».

        Специально попробовал написать, заработало только со второго прогона.

        Я тоже со второго раза правильно написал после прочтения этой статьи. Открыл консольку браузера и в одну строчку решил задачу, но забыл про var, область видимости и циклы в js, потому моя программа хоть и выводила правильно Fizz/Buzz/FizzBuzz, но предваряла некоторые слова числом. Исправил — на втором прогоне всё норм стало. А можно было даже просто var на let заменить… но не суть, я о том, что поспешишь — людей насмешишь, и это не должно на собеседовании быть показателем, что человек — плохой программист, ведь работать он будет в более спокойной обстановке.


        1. Neikist
          14.11.2018 19:30

          реши задачу «в лоб»

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


          1. KevlarBeaver
            15.11.2018 01:07

            … использовать ли мне паттерн «стратегия» или фабрику замутить… хм… а может собеседующий хочет, чтобы я показал навыки динамического программирования…


  1. hardmodebitch
    13.11.2018 21:20
    +1

    За чек-лист "собеседуй собеседующего" отдельное спасибо.


  1. sbh
    14.11.2018 04:53

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


  1. ehots
    14.11.2018 16:53

    А почему пропустили кодинг на листочке? Такое любят устраивать, хотелось бы услышать мнение автора, раз он дает советы, как побеждать среду разработки «чистый А4»?


    1. KevlarBeaver
      14.11.2018 18:35

      Мне доводилось общаться на одном собеседовании с человеком и листочком A4. Правда, там было много нюансов. Компания (точнее, её отдел) был совершенно бестолковым, а вот собеседующий — на удивление адекватным, я даже допускаю, что у него просто компа на нашлось (а ноутов там и небыло), за которым было бы комфортно мне дать код пописать и самому посмотреть. В итоге — очень продуктивно и интересно пообщались, больше писал он — а я в основном отвечал на вопросы… Вобщем, я к тому, что один плохой симптом — это не всегда плохо, косяки у всех случаются, главное, чтобы в целом было всё адекватно. И вот собеседование оказалось очень интересным и адекватным, а компания — тем ещё отстоем.


    1. Neusser
      14.11.2018 18:57

      Зачем ее побеждать? Я однажды писал на собеседовании код на А4. Ничего сложного.


  1. SerJook
    14.11.2018 17:23
    +1

    Вторая часть заголовка заинтриговала, но ответа в статье я не нашел. Как разработчику сохранить своё здоровье и не «сгореть» на работе? Я где-то слышал, что большинство из тех, кто проработал программистом достаточное количество лет, имеют определенные проблемы с психикой.


    1. KevlarBeaver
      14.11.2018 18:37
      +1

      Программист с пятнадцатилетним стажем. Лежал в психбольнице, хоть и по собственному желанию ))))
      Я один, конечно, не являюсь репрезентативной выборкой, но, да, стоило бы задуматься )))