2014-02-18
Представим, что вы ищете новую работу. Ну, или просто задумались о смене карьерного пути.
Вы думаете о компании, в которой хотели бы работать. Определяетесь: хотите работать в небольшом стартапе, в компании средних размеров или в международной корпорации.
А сейчас остановитесь. Вы всё делаете неправильно.
Попытайтесь сейчас представить себя на месте рекрутера. Он ничего о вас не знает. Зато ему известны интересы и потребности своей компании. Всё, что ему от вас нужно – это узнать, сможете ли вы закрыть эти потребности.
Технологии меняются, поэтому ни один язык программирования не даст вам гарантии вечной востребованности. Однако, есть навыки, пользующиеся спросом всегда. Если подчеркнуть владение ими, помимо технической подкованности в Java или SQL, ваше резюме значительно выделится из общей массы.
Если вы на собеседовании скажете: «Знаю всё об абстракциях», – это не принесёт никакой практической пользы. Вместо этого вам стоит объяснить, чем ваши знания могут помочь развитию компании.
Вам нужно рассказать о себе и своей технологической подкованности так, чтобы вас понял любой менеджер.
Итак, какие же навыки разработчика наиболее полезны для любого бизнеса?
Понимание связи между циклом разработки и делом компании.
Если вы понимаете способны осознать цикл продаж и бизнес-модель компании, вы будете разумнее подходить к распределению своих сил и ресурсов в цикле разработки. Иными словами, вы будете правильно расставлять приоритеты у задач.
Контроль версий.
Если разработчик не может ответить на вопрос, какой системой контроля версий он пользуется, скорее всего, он так себе разработчик. Без системы контроля версий невозможно заниматься совместной разработкой, отслеживать историю, откатываться до предыдущих версий, управлять ими, заниматься рефакторингом или лечить багги.
Модульное тестирование.
Модульное тестирование и TDD позволяют определить самое главное: что должно делать ПО. Вместе с TDD программное обеспечение всегда готово к выпуску, при условии, что ПО прошло все тесты. Модульные тесты позволяют внести изменения в сложные системы без опасений, что они сломают что-то в других кусках кода.
Автоматизация с помощью Jenkins, Maven, Ant и непрерывная интеграция.
Если разрабатывать и деплоить ПО вручную, это чревато многочисленными ошибками, потерей времени и неграмотным распределением командных ресурсов. В идеале хорошо бы иметь сервер с установленным, к примеру, Jenkins, который ребилдит ПО после всех изменений.
Понимание архитектуры ПО и паттернов дизайна.
Никто не будет строить дом без чертежа. Так же и программу нельзя построить без проектирования. Необходимо понимать взаимосвязи между модулями и общие компоненты.
Написание и чтение документации.
Гуглинг, чтение официальной документации и неофициальных блогов – бесценно. Если проект не имеет вики-документации, это мёртвый проекты. Всё, за что команда борется неделями, должно быть записано: контактная информация, где находятся важные репозитории, базы данных, утилиты, инсталляторы…
Понимание масштабируемости и повторяемости.
Вы должны понимать, что каждое ваше действие должно быть воспроизводимо в будущем. Если какой-либо процесс не воспроизводим, скорее всего, вы делаете что-то не так. Если веб-сайт падает при увеличении нагрузки, значит, вы ошиблись на этапе проектирования. Если вы настроили свой Dev-сервер, скорее всего, вам понадобится продублировать окружение и для QA-сервера, и для Production-сервера.
Оценка сроков.
Нет такой компании, которой не были бы важны крайние сроки, и нет таких людей, у которых бы получалось поставить крайний срок верно. Основное правило, которое работает при постановке сроков: «Прикиньте в уме, сколько времени вам для этого понадобится, и умножьте на пять».
Знать, когда нужна/не нужна оптимизация.
ПО не должно быть отстойным. Оно не должно воровать ресурсы у CPU и время у пользователя. Не всё нужно оптимизировать. Если ваш ресурс показывает в онлайне 15-гигабайтные видео, экономия в 3 Кб ничего не изменит для пользователя.
Agile.
Правильно выстроенный Agile – это: модульноу тестирование, коммуникации между разработчиками/тестировщиками/менеджерами, прозрачность, взаимное обучение между разработчиками, постоянный продакшн. Неправильно выстроенный: чрезмерно плотные графики, невнятное назначение продукта, бессвязный набор функций, куча багов и несчастные разработчики, забитые в угол.
Рефакторинг.
Рефакторинг – это способность переписать внутренние функции модуля, не задевая его внешнее поведение. Первое правило рефакторинга сформулировал ещё Гиппократ: «Не навреди».
Миграция.
Необходимо понимать саму концепцию и реализацию миграции. Как совершить переход для пользователей с версии 1 на версию 2? Как мигрировать изменения с Dev-окружения в QA-окружение? Как мигрировать код с одной технологии на другую?
Знание API.
Вы должны знать, как разделять свою работу от работы других людей (т.н. декаплинг). Возможно, вам нужно будет создать инструментарий для других разработчиков. Зачастую идеальным способом для этого является создание API.
Написание воспроизводимого кода (обычно это объектно-ориентированное программирование).
Если в продукте ожидается 50 всплывающих диалоговых окон, сколько для этого необходимо написать компонентов? Правильный ответ: один, максимум два. Несмотря на это, бесчисленная орда разработчиков не использует компоненты многократно. В хорошем проекте безотказно действует правило: чем меньше кода, тем лучше.
Есть один вопрос-лакмусовая бумажка для определения воспроизводимости кода. Если я попрошу вас изменить стиль и ширину каждой кнопки в приложении, сколько времени на это понадобится? Минута? Час? Неделя? Месяц? Год?
Окружение, на которое можно положиться.
Ваша ценность многократно возрастает, если вы можете быстро найти ответы на свои вопросы благодаря сообществу разработчиков.
Система трэкинга (Jira).
Необходимо знать хотя бы одну баг-трэкинговую систему, уметь её администрировать, конфигурировать дэшборды, составлять отчёты.
Excel или Google Docs не могут считаться баг-трэкинговой системой.
Достаточные знания в аппаратной части.
Нет, вам не нужно быть экспертом по «железу». Но и полным чайником быть не стоит. По крайней мере, добавить памяти в свою машину, создать бэкап и исправить неполадки в сети вы должны быть способны.
Достаточные знания инструментов и технологий, которыми вы не пользуетесь.
Фрезеровщик кругом видит лишь станки, станки, станки… Так и вы: если вы не будете видеть ничего, кроме ActionScript, которым привыкли пользоваться, вы так и останетесь со станками. Знайте своих врагов в лицо.
Достаточные знания об уровнях конфигурации веб-сервера.
Хороший разработчик хотя бы поверхностно представляет уровни разработки: от бэкенда к фронтенду. К примеру, если пользователю нужно ввести свой email, какую проверку проводит UI, что делает среднее звено сервера, и что в итоге обрабатывает бэкенд?
Приблизительно это должен представлять себе каждый.
Понимание того, что релиз – это всегда новые функции.
Ничто так не раздражает разработчиков, как вопросы о том, «когда же всё будет готово». Есть один волшебный рецепт от таких вопросов. Если кто-то даёт вам задание на разработку новой функции, скажите следующую фразу:
«Это новая незапланированная функция, которая обязательно скажется на текущем расписании разработки. Нам необходимо либо внести изменения в расписание и привлечь к проекту больше ресурсов, либо же избавиться от некоторых уже существующих функций и выпустить их уже в следующей версии. Вам какой вариант больше нравится»
Говорите это каждый раз, когда запрашивается новая функция. На текущий момент основная задача – выпустить версию N, содержащую заранее обговорённые функции, а новые пойдут в версию N+1 или N+3.
Абстракции.
Под абстракцией в программировании понимается способность сокрытия от пользователя деталей реализации возможностей программы. Абстракция требует декаплинга большого количества модулей. Если весь мой UI-код взаимодействует с базой данных Oracle, и в один прекрасный день я обнаруживаю, что бэкэнд-разработчик перешёл на базу данных Microsoft, и не смогу быстро справиться с этим – я плохой разработчик.
Избавляться от ошибок компилятора.
Если бы мне дали пять минут на то, чтобы определить, насколько хорошо пишет код соискатель, я бы использовал лишь один простой инструмент: посмотрел, сколько ошибок и предупреждений выдаёт компилятор.
Знать, когда (не) настаивать на своём.
Самыми невыносимыми разработчиками часто оказываются те, кто настаивают на изобретении колеса. Если вы не используете в своей работе чужие библиотеки и API, вы теряете время и деньги. Если есть библиотека, экспортирующая данные в Excel, а вы пишете собственный экспортер, вы либо не умеете гуглить, либо слишком любите себя.
Хотя задирать нос от того, что вы умеете вбить пару слов в поисковике, тоже не стоит.
В заключение
Остаётся лишь один вопрос: как донести ваши технические знания на первом собеседовании с человеком нетехнического склада ума?
Давайте представим разговор.
Интервьюер: Скажите, пожалуйста, насколько ваш текущий опыт работы соотносится с нашей вакансией?
Вы: А для этого мне надо узнать, какие проблемы есть сейчас.
Интервьюер: Ну, с масштабируемостью у нас как-то не очень…
Вы: <вставьте здесь ваш гениальный ответ, полный технических подробностей>
Интервьюер: Звучит немного сложно для меня… Может быть, назначим второе собеседование с бэкенд-разработчиком?
Вы: Конечно. Я лишь хотел сказать, что на масштабируемость влияет очень много факторов. Но моей целью является не просто создание масштабируемого приложения. Главное – понять то, что нужно компании, оценить возможные технические проблемы, время, которое нужно потратить на реализацию, и распределить задачи между программистами.
Интервьюер: А вот так гораздо понятней!
(занавес)
Перевод: Люся Ширшова. Спасибо мыслям блога ZeusProd.
