Стажировка - лучший подход?

Question

У нас есть стажер, начиная со следующей недели. Он имеет степень по компьютерным наукам, но не имеет реального опыта разработки на .NET или SQL Server. Мы хотели бы довести его до такой степени, что он по крайней мере полупродуктивен в C # и SQL Server. Какие предложения могут быть у кого-то из вас, кто прошел через это, относительно того, как лучше всего начать его обучение на C # и SQL Server? Я хочу сделать это хорошим опытом для него и для нас.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

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

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