Бен Халперн, 06 февраля 2017 г.

Первоисточник:



Джонатан Гамильтон
На моей предыдущей работе наняли много младших разработчиков интерфейсов, то есть прямо из университета. Мы обнаружили, что они на самом деле не знали основ или, по крайней мере, не были в них уверены. В течение примерно месяца мы, по сути, дали им поддельный проект, в котором использовалась технология, которую они, скорее всего, будут использовать в проекте, а именно html, sass/css, javascript и git.

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

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

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

Вещи, которые я нашел наиболее эффективными

Документация (вы можете сказать, что код должен документировать сам себя, но вы забываете, что другие люди не на том же уровне, что и вы)
Тесты
Поддерживаемый код (если не документировать, почему и как с ним работать)
Парное программирование
Не судите строго
Кнопка «Любимое сердечко»

Synergist Computing
Полностью согласен! У нас очень похожий процесс в Synergist. Мы предоставляем каждому из наших новых младших разработчиков платформу для изучения концепций, которые они, возможно, не изучали в университете, и даем им проекты для развития своих навыков. Мы следим за тем, чтобы они понимали, что они уже талантливы, но есть только уровень, на который им нужно подняться, чтобы по-настоящему отточить те навыки, которыми они уже обладают; мы определенно не хотим внушать страх или тревогу, а скорее заботливую среду.

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

Филипп Озил
В Salesforce используется сочетание различных методов. Наряду со стандартными лучшими практиками, такими как документация, наставничество и проверка кода, у нас также есть больше «корпоративных» ресурсов.

У нас есть программа адаптации, которая требует, чтобы все сотрудники по всему миру посещали некоторые занятия в нашей штаб-квартире. Разработчики следуют специальной двухнедельной программе. Это позволяет им ознакомиться и привыкнуть к нашим инструментам и методологии Agile (Scrum, Kanban…).

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

Энно Релинг (恩諾)
Когда я работал в IMVU, мы давали каждому новому сотруднику наставника, в чьи обязанности входило вводить нового разработчика в курс дела. Они работали по контрольному списку типичных задач, которые нужно было выбрать с доски в первый день, первую неделю и т. д.

Мы предпочли доверять новым сотрудникам (точнее, нашему процессу найма), и одной из наших целей было то, чтобы каждый внес изменения в производственную площадку в первый же день. Быстрая итерация и непрерывное развертывание были важными частями нашей культуры, и мы хотели, чтобы новые люди как можно скорее прониклись этим и не боялись.

IIRC, новые сотрудники считались лишь половиной разработчика во время планирования спринта в течение первых трех месяцев из-за того, что им нужно было развернуть много новых вещей и что они замедляли своего наставника. Быть наставником для нового сотрудника было важным шагом для младших разработчиков, переходящих в старшие, и все с удовольствием менялись.

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

Источник для совместной работы
К сожалению, из-за уникальных географических и доменных обстоятельств мы редко нанимаем младших разработчиков. Почти каждый в нашем инженерном отделе имеет более чем 20-летний опыт работы. Когда мы нанимаем, это, как правило, другой старший разработчик, который уже был в (том же) блоке, и работа очень знакома. Большая часть нашей работы связана с аппаратным и программным обеспечением, которое имеет дело с очень известными стандартами, поэтому мы склонны работать с этим, а не с нашими собственными конструкциями.

Для нескольких недавних выпускников, которых мы наняли, мы даем им один из наших продуктов и просим их дополнить его новыми функциями. Они задают вопросы, когда застревают, а мы им говорим: «Не мучайтесь молча!» - Просто спроси! Не стыдно задавать вопросы.

Джейсон С. Макдональд
Поскольку единственный путь в нашу компанию на данный момент — это программа стажировки, мы получили свою долю студентов колледжа, которые «олени в свете фар» начинают работать в MousePaw. Games, прижимая к сердцу свои учебники по программированию и глядя на все с широко раскрытыми глазами (и долей культурного шока). Конечно, это в значительной степени метафора, поскольку на данный момент мы все сотрудничаем через Интернет, но остекленевший взгляд почти всегда присутствует во время первого видеочата.

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

После этого мы даем им одно или два достаточно простых задания. Один из них — начать читать книгу Скотта Розенберга «Dreaming in Code», которую необходимо прочитать в нашей компании. Одна только эта книга помогает новым разработчикам адаптироваться к индустрии в целом — примерно на полпути их идеалистические взгляды в значительной степени поджариваются, и они могут начать сталкиваться с реальными проблемами живого проекта.

Во-вторых, мы предлагаем им просмотреть часть кода, с которым они будут работать, обычно добавляя некоторые простые и понятные улучшения. Я сторонник хороших комментариев и документации (если кто не понял из моей статьи «Ваш проект еще не готов»), так что это облегчает переход к коду. Стажерам предлагается свободно задавать вопросы на платформе для совместной работы, и наши сотрудники всегда готовы помочь.

Пока это работает довольно хорошо для нас.