О технических интервью.

Декабрь 13th, 2007

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

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

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

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

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

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

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

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

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

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

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

Иллюзия (не)уязвимости

Декабрь 12th, 2007

Множество фирм обладают одной из двух иллюзий – уязвимости или неуязвимости.

Иллюзия неуязвимости обычно появляется из-за того, что фирма является лидером в какой-то нише, причем абсолютным лидером, до которого просто нереально дотянуться номеру 2. Опять же возвращаясь к крупным затасканным примерам — IBM чувствовала себя неуязвимой до взлета Microsoft, а Microsoft был неуязвим до появления Google. Обычно именно в тот момент, когда компания начинает считать себя номером один, эти иллюзии развенчиваются. Происходит это из-за того, что компания, к тому времени, становится уж очень глупой (в смысле закостеневшей и медленной) и какой-нибудь шустрый и молодой стартап атакует их с абсолютно неожидaнной стороны. Естественно, компании не погибают от одной атаки, а зачастую живут десятки лет, но, тем не менее, история полна таких примеров, когда абсолютный лидер терял громадную долю рынка из-за какой-нибудь молодой и зеленой компании.

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

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

О том, как читать книги связанные с бизнесом

Декабрь 11th, 2007

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

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

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

Маленькая компания — низкие цены.

Декабрь 10th, 2007

У офшорного рынка есть интересная особенность: маленькая компания не может выставлять высокие цены за час своей работы. Да, если в ней работают супер-пупер программисты, то маленькая компания сможет выставлять в лучшем случае средние цены. Большая же компания (скажем на несколько тысяч разработчиков), имея в своем составе даже, в основном, даунов, может выставлять цены иногда в десятки раз большие.

Этому странному феномену есть несколько объяснений:

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

б) Маленькая компания редко может позволить себе длительные переговоры (например на пол года) насчет серъезных сумм (которые часто могут вообще ни к чему не привести).

в) Также у маленькой компании просто нет налаженных каналов получения проекта и нет хороших references.

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

Несколько идей о преодолении низцих цен.

— Если вы работаете в рынке с большой конкуренцией то, увы, вам прийдется таки смириться с низкими ценами.

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

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

— Если рынок «перегрет» (как например было и есть в Индии относительно IT сферы) даже маленькие компании могли брать большие и дорогие заказы.

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