Данная статья — это возможно слишком близко принятая к сердцу реакция на пост о принципах работы с начинающими разработчиками. Так же, я попробовал выразить общее мнение по поводу адекватности некоторых методов приема на работу. Сразу скажу, что это мой личный взгляд и у меня нет особого опыта приема на работу новичков.
Об общей проблеме таких статей
Наверное одним из самых странных в статьях из серии «100 лучших вопросов при приеме на работу» является то предположение, что соискатели будут отвечать честно на их вопросы. Да соискатель первым прочтет такую статью и будет знать, как отвечать не стоит! А даже если не так, то я уверен все соискатели имеют свои представления по поводу того, каких ответов от них ожидают. И, по мере возможностей, стараются соответствовать им.
По чему так происходит? Все просто, тот кто прослушивает соискателей (имеется ввиду не HR, а представитель фирмы) в эту фирму уже устроился и считает пригодными те ответы, которые он готов дать сам. По-этому ему сложно понять, какими качествами отличными от его может обладать успешный сотрудник. Как и сложно понять, зачем лукавить на собеседовании — его-то честные ответы в свое время подошли. Им, так же, крайне сложно представить, что соискатель может понимать, что его искренние ответы будут отличаются от ожидаемых, и все равно считать, что они подходят для этой работы. Особенно, если это неопытный студент, которому выбирать то не приходится — ему и так нигде не рады. Так что о честности приходится забывать, и просто давать ожидаемые ответы, а дальше надеятся, что их настоящие качества не подведут.
Вообще я допускаю, что прием сотрудника может быть жестоким конкурсом с допросами и отсеиванием всех, кто хотябы на секунду заставил усомниться в своей благонадежности. Такой подход будет отсеивать множество потенциально хороших сотрудников, но не допустит того, чтобы к вам в команду попал ненадежный. При большом количестве желающих на должность можно пойти и на такие жертвы, тем более что в основном это будут жертвы не со стороны фирмы.
Но хотелось бы видеть и статьи, которые бы рассказывали бы о подходах не столь категоричных, тем более что они зачастую основаны на принципах, мало отличающихся от шаманских плясок с бубном (читай суеверий). Да в IT области не то, чтобы очень большой конкурс.
О самой статье
Когда читаешь на хабре что джуниор не должен задавать мало вопросов, но и не должен задавать много вопросов, то хочется взвыть: «Вы случайно не астрологию в университете приходили?». Если вы закончили технический вуз, то как вас может не смущать субъективные термины «много», «мало» в статье претендующей на техничность? Это и отличает научные статьи от псевдонаучных: научные пытаются дать однозначные критерии, а псевдонаучные — подходящие всем кто их услышит.
Или вот этот совет: «Дайте джуниору бессрочное задание и посмотрите, догадается ли он сделать его быстро» (цитата не точная, но смысл передан). Быстро для чего? Для «сделать качественно до конца сдачи всего проекта» или «успеть показать нетерпеливому заказчику прототип»? Как можно не давая критериев оценки быстроты предлагать ею хоть что-нибудь измерять? Вам не кажется, что специалист этот тот, кто может подобрать оптимальное решение под конкретные нужды? Но эти нужды должны быть озвучены, или дейте ему хотябы инструменты для их самостоятельной оценки — контакты заинтересованных лиц, примеры сроков выполнения задач — хоть что-нибудь.
«Как меня за#бал университет» сигналит для автора о неумении управлять своим временем. А может студент за#бался от того, что устал замаливать перед преподом прогулы занятий, темы которых он и так знал или наоборот капитально не понимал, и потому прогуливал их, чтобы потратить время на более эффективное самообучение? Конечно, знания математики нужны программисту, хотя и требуются в некоторых областях нечасто, из-за чего многие недооценивают их необходимость. Но нередко вузы плохо справляются с подачей такого материала, и, порой, все равно требуют тратить время на плохо-организованные лекции и семинары.
Идейность для автора тоже плохой знак. При этом автор не отрицает, что сам выбрал более удобные ему технологии, только потратил на это больше времени. Опять те же критерии — больше, меньше. Где объективный критерии того, что программист «идейный», а не разобрался в технологиях и выбрал себе более подходящую? Срок? Какой? Широкий кругозор? На сколько? В итоге автор лишь разметил полюса, а об их границах на предстоит самим догадаться подобно тому, как автор предлагает новичкам догадаться о неназванных сроках.
Еще автора смущает внезапные курсовые, подработки и другие отвлекающие от нужной работы маневры. И это для автора признак безответственности. Так вот, ответственность — это умение держать ответ за ошибки. Свои, а зачастую и не очень. Это, когда, за отсутствие на работе из-за какой-нибудь неурядицы, сотрудник просидит следующие несколько дней допоздна, а еще купит печеньки всем коллегам, которые из-за него пострадали. А отсутствие внезапностей — это удача или умение успешно предсказывать будущее.
Мое мнение
Я не специалист, но мне очевидно, что прием начинающих разработчиков сопровождается большими тратами и рисками на их обучение. Траты будут заключаться в невыполненных в срок проектах и отвлечении специалистов на вопросы и разъяснения. Так вот, лучшее, на мой взгляд, с чего стоит начинать работу с начинающим разработчиком — это определить границы вложений, которые готова потратить фирма на новичка, и постараться оформить отношения с новичком так, чтобы не только фирме, но и ему было невыгодно выходить за эти границы.
На собеседовании надо постараться донести информацию об этих границах до соискателя и рассказать о рисках, которые вы видете в его отношении к работе и его опыте (например о проблеме зацикливании на одной технологии или проблеме незнания математики и основ анализа алгоритмов). И чтобы в поиске истины были заинтересованы действительно обе стороны, стоит давать шанс не только тем, в ком вы уверенны, но и тем, кто уверен в себе — тогда не будет заинтересованности в обмане.
Вот о том, как этого добиться, с примерами выработки критериев оценки, и было бы интересно узнать в такой статье.
Автор: vakimov
