Я более десяти лет жизни писал код в одной российской компании и активно собеседовал-нанимал людей. За это время успел пообщался с четырьмя сотнями кандидатов. На моих интервью было все – от алгоритмических задач до разговоров о «жизни». Но форма вторична – я рассматриваю интервью как инструмент для проверки совпадения с кандидатом по культуре. И все эти десять лет в моей компании менялся подход к оценке программиста на интервью и менялась культура.
Любое собеседование адекватно компании, которая его проводит. Даже если от собеседования «бомбит» и «подгорает» - проблема в кандидате, а не в компании. И как кандидат я очень рад такому простому фильтру для отбраковки не подходящих мне компаний. Но и компания тоже преследует свои цели – сохранение и изменение своей культуры за счет найма «правильных» людей. Проверка технических навыков тоже важна, но важнее нанимать людей, с которыми можно работать.
Далее я хочу рассмотреть в формате моей истории разные способы оценки программиста на техническом интервью. У меня нет цели рассказать обо всех методиках оценки компетенций. Мой обзор методов оценки будет не полным, эгоцентричным и предвзятым. Также часть моего рассказа будет собрана из историй про другие компании. Это не будет рассказ как все на самом деле обстоит-обстояло, и прошу считать эту историю чистым вымыслом.
Я имею довольно небольшой опыт работы в сфере разработки программного обеспечения (всего 6 лет), но я уже накопил ряд полезных и правильных практик (по моему скромному мнению), которые можно использовать при создании программного обеспечения.
В основном описаны моменты которые касаются поддержки процесса разработки программного обеспечения, не затрагиваются темы планирования хода выполнения работ. Также не затронут процесс программирования и полезные плюшки для него (например расслоение системы на уровни, использование шаблонов проектирования). Но все ниже приведенное было и остается полезным для меня лично, и я буду рад если и вам на что нибудь сгодится :)
Про полезность подхода TDD (разработка через тестирование, test driven development) не слышал только ленивый или глухой. Но сегодня мы не будем обсуждать всю его полезность и красоту, а также проблемы и недостатки. Сегодня мы попробуем посмотреть, как разрабатывать unit-тесты для spring приложений. Также мы немного тронем ручное управление транзакциями в unit-тестах.