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

Думал над этим. В философской плоскости.

Отдельное огромное спасибо коллегам, на вопросы и сообщения которых в gtalk/icq я непрерывно отвечал в течение примерно часа после объявления о своем уходе. Это было неожиданно. И в этот момент я в полный рост почувствовал, что не зря провел более двух лет на этой работе. И что моя работа имела какой-то смысл. Спасибо, друзья, что вы даже не допускали мысли, что меня могут попросить “освободить помещение” Но так тоже бывает, да. И, честно говоря, я пока вижу в этом больше плюсов для себя, чем минусов.

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

По своему опыту могу эти цифры только подтвердить: чем ближе число сотрудников к 12-ти (сверху), тем больше получается вникать в задачи каждого исполнителя и тем лучше получается всё контролировать и планировать. И наоборот: чем больше превышение над двенадцатью людьми, тем больше в работе белых пятен, вплоть до “откуда взялся этот человек и чем он занимается последние 2 месяца?”

Перелопачивал сегодня резюме программистов на hh.ru. В 90% случаев люди пришли на последнюю свою работу в 2008 году. Выводы кому надо могут сделать сами.

Несколько советов тем, кого задел кризис:

1. Заведите себе почтовый ящик вида имя.фамилия@чего-то-там.com. Потому что, во-первых, адреса вида darklord@mail.ru – ну совсем не красиво. А во-вторых, я уже мысленно представляю, как весело будет, когда несколько десятков людей начнут отвечать на мои письма про работу, и в поле “From” будет написано DarkLord, SuperMegaDeveloper и прочее. И как понять, глядя на список писем, где тут письмо от Васи Петрова?
2. Сто раз подумайте, стоит ли указывать в резюме ссылку на ваш персональный сайт или блог. Сходите в свой блог и перечитайте последние 20 записей. Вы уверены, что хотите, чтобы ваш потенциальный работодатель это прочитал?
3. Если ищете работу программистом, то наверное не стоит указывать в резюме, насколько хорошо вы владеете фотошопом. Другая крайность – указывать список из 15 языков программирования. Вы правда верите в то, что работодатель, которому нужен программист на языке, который указан у вас 12-м в списке, обратит внимание на ваше резюме?
4. В названии искомой позиции лучше указать одну позицию, а не три. Если я ищу программиста и вижу в списке резюме “IT-директор / Системный админитратор / Программист” – я даже не стану открывать такое резюме. Если вы всё-таки не определились и ищете несколько разных позиций, то сделайте соответствующее количество разных резюме. Обязательно разных, а не одинаковых, потому что при поиске по слову “Perl” хедхантер покажет ваши 3 резюме рядом друг с другом, и ситуация с восприятием вашего резюме будет эквивалентна ситуации с указанием трех разных искомых должностей в одном резюме.
5. Указывайте в начале резюме ключевые слова. Для технических специалистов – это, соответсвенно, наименование основных технологий/языков. 3-5 штук, больше не нужно. Потому что приходится вчитываться в текст, чтобы где-то в середине понять, что этот товарищ – закоренелый виндузятник. То же самое относится к описнию опыта работы: работодатель будет пищать от восторга, если в описании каждого своего места работы вы укажите использованные технологии.

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

2. Нельзя брать на работу идиотов. В широком смысле. Человек может идеально знать нужные вам технологии, но при этом легко может быть клиническим идиотом. Может, например, не понимать, что ему говорят. В буквальном смысле. Может быть упертым бараном и постоянно будет делать не то, о чем его просят, а то, что сам считает нужным. Или может постоянно врать по мелочам. Первый звоночек на собеседовании: человек не отвечает прямо на поставленный вопрос, а переходит на какие-то смежные темы, и вообще очень много пиздит.

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

4. Люди в основной своей массе делятся на две категории. Тех, кто умеет очень хорошо и красиво что-то делать, умно и красиво об этом рассказывать и писать, но не доводит задачи до нормального завершения. И тех, кто просто берет и делает задачу до конца. Может быть это будет не так красиво, как в первом случае, архитектура и выбранные технологии будут неоптимальными и т.д., но задача будет сделана. Первые постоянно приносят проблемы, которые они в изобилии находят в процессе работы над задачей, и приходится тратить много времени на бесконечные совещания и бесконечную переписку, а вторые сами решают все эти проблемы. Первых на работу брать не надо. Вторых – надо. Уж лучше три раза всё переделать вместе со вторыми, чем красиво буксовать на одном месте с первыми.

5. Образование не имеет никакого значения.

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

7. Технические вопросы, тесты и задачи могут служить для отсечения людей с неадекватными ожиданиями по зарплате. Ну и для отсечения людей с недостаточной квалификацией. Если человек претендует на позицию (или зарплату) ведущего программиста, но не может отличить фронтенд от бэкенда и не знает основных принципов работы веб-сервера – это странно. Но успешное прохождение кандидатом технической части никак не должно быть поводом для найма. Я, например, вообще очень редко задаю технические вопросы. Только в случаях, когда есть сомнения в соответствии зарплатных ожиданий и квалификации. И при этом ещё ни разу не взял на работу человека, который не потянул бы именно в техническом плане. Ну и если человек чего-то не знает, и при этом не идиот, – быстро освоит, не рокетсаенс всё-таки.

Кстати, мне нужен супер-программист. Perl, Postgres. Зарплата достойная, карьерный рост, в коллективе программистов есть красивые девушки – где ещё такое встретишь?! . Пишите, если что.