Victor Ronin's IT blog

Достаточно странная ситуация складывается в компании, когда в ней принята культура «просить» людей что-то сделать. С одной стороны, чаще всего такая культура ведет к тому, что все чувствуют себя гораздо более уютно, с другой стороны именно это ведет к разнообразным проблемам в последствии.

Ну начнем, с того, что человек иметь право отказать, если его просят. Поэтому,  когда начальство просит подчиненного, то возникает странный эффект – вроде это просьба, но и отказывать вроде нельзя. Ну это еще пол беды, все и так знают, что когда начальство говорит «можно?» оно имеет ввиду «надо» и когда оно говорит «пожалуйста» — это значит «сделай-как это по быстячку».

Проблема на самом деле кроется, в том, что люди на одном ранге просят друг друга что-то сделать (вполне возможно даже одобренное уже начальство). Все идет гладко до тех пор пока тот, кого просят, выполняет просьбы и поспевает с своим задачами вовремя.  Знаете, как оно происходит, когда подходит Вася Пупкин и говорит «Не мог бы ты мне помочь с проблемой X?»

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

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

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

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

Также хорошо, когда в фирме, одной из обязанностей Team Lead’ов является помощь по разным вопросам. Это убирает необходимость идти к менеджеру и выяснять нужно или не нужно помогать для задач больших чем час.

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

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

Также, я читал блоги нескольких работодателей, которые требуют такие вещи как:

— обязательная идеальная орфография резюме

— умение поддержать разговор

— хорошая реакция на неожиданные ситуации

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

Я считаю, что один из основных критериев, по которому стоит отбирать людей на технические позиции – это “блеск в глазах” и умение учиться. Когда я говорю “блеск в глазах”, я имею в виду, что, при обсуждении интересных технических тем, собеседуемый активно реагирует – обсуждает, спорит, предлагает идеи и варианты, рассказывает о своем опыте, ну и показывает неподдельный интерес к обсуждаемым вопросам.

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

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

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