Обучение в интернате - лучший подход?

Ответ 1

Некоторые из лучших впечатлений, которые у меня были с этим (с обеих сторон), - это 2-кратный подход.

Сначала - подготовка продукта. Покажите новому разработчику, что продукт, над которым он будет работать, и что он делает с точки зрения конечного пользователя. Это помогает создать контекст кода, находящегося под капотом. Это одна вещь, которую обычно упускают из виду; тем не менее, очень помогает, так как он также помогает новому разработчику быть более уверенным в тестировании кода, над которым он или она работает, вместо того, чтобы просто наткнуться на код.

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

Как только это будет сделано, начните кормить нового человека более мелкими задачами или попробуйте найти ошибки и создайте оттуда.

Ответ 2

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

После того, как он достаточно хорошо познакомился с С# и SQL Server, вы можете начать с него делать настоящую работу по разработке. Начните его с малого с мягкими исправлениями ошибок, а затем увеличьте сложность, пока не сможете назвать его полноценным разработчиком. Если вам повезет, вы даже не будете называть его стажером в течение месяца или двух.

Ответ 3

• Небольшие проекты, которые помогут ему сесть.
• Попросите его просмотреть код других разработчиков в проектах
• Наведите указатель на внутреннюю wiki (если используется)
• Он-лайн обучение или 2-5-дневный учебный курс Microsoft (ожидается бюджет)
• Вне ИТ-отдела, он уверен, что он наращивает свои знания о том, как бизнес работает/функции
• Удостоверьтесь, что у него есть доступ к некоторым хорошим книгам, а также к интернет-ресурсам.
• Заставьте его чувствовать себя комфортно в рабочей среде, чтобы, если он застрял, он попросит кого-нибудь о помощи. (ИТ-разработчики могут быть очень зависимыми, иногда обращаясь за помощью)

Ответ 4

Если у вас есть проекты типа "домашних" (проекты, которые ваша компания никогда не смогла бы оправдать тратить время, но были бы полезными и довольно простыми), я бы дал им это.

Было бы неплохо начать изучать материал, так как это фактическая работа (всегда сложнее узнать что-то и запомнить материал, если это просто примерная программа, а не что-то действительно полезное). Будет хорошим началом для изучения того, как использовать Google для вопросов/учебников, и строить отношения с вашей командой, задавая вопросы. Оттуда у них должен быть достаточно хороший фон, чтобы начать работу с реальными приложениями.

Если проект домашних животных достаточно мал, вы можете захотеть, чтобы они повторно посетили приложение в конце стажировки, чтобы переписать/улучшить приложение. Вероятно, они будут удивлены тем, что они получили в ходе стажировки.

Ответ 5

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

То, что вы не хотите, - это отправить их с кодировкой кучей вещей, а затем обнаружить, что код не соответствует. Что касается базы данных, будьте осторожны. Ограничьте разрешения (т.е. Woops, я не имел в виду DELETE/DROP, что!), Или, надеюсь, у вас есть специальная среда разработчика, в которой все происходит плохо, а не для восстановления. Возможно, побочный проект с образцовой базой данных для тестирования, прежде чем включать работу в реальную среду.

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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

Ответ 8

У нас есть стажер в нашей команде около 6 месяцев. Я нанимаю его, и это действительно хороший опыт. Когда я брал у него интервью, я отвечал на все вопросы CS, но когда он начал работать с нами, это было ужасно все худшие практики - совершение неработающего кода, блокировка svn файлов, копирование всех мест и всего, пространства имен с именами как Классы, длинные очень длинные методы с ОГРОМНЫМ противником против головы. и, наконец, лучший код С#, который я когда-либо видел:

bool b = DoSomeThing();
switch(b)
{
case true:
  Do();
  break;
case false:
  DonotDo(); 
  break;
default: //!!!
} 

Мое единственное предложение контролировать его.

Ответ 9

Попросите его создать диаграмму статической структуры UML для кодовой базы одного из ваших существующих проектов с умеренным размером. Это будет (1) заставлять его иметь структурное понимание на высоком уровне по крайней мере одного проекта и (2) заставлять его читать код другого человека, что, возможно, раньше не делал стажер.