Метка «human resources»

Часть 1/3. Какие бывают 'плюшки'.
Часть 2/3. Подводные камни для «новичка».

Какие бывают работодатели. Характерные особенности.

Вместо краткого вступления, одну закономерность можно назвать сразу: чем длиннее и крупнее проект, тем древнее технологии. Хотите на практике освоить новые технологии — участвуйте в стартующих проектах длиной 3-6 месяцев.

  • Фирмы, работающие на Министерство обороны и подобные структуры

    Секретность, используется относительно узкий набор технологий — которые сертифицированы в ФСБ. Например, Java 1.6 и Tomcat сертифицированы, а EJB-контейнеры не сертифицированы, вместо них может использоваться самописная недо-пародия. Что хорошего в самописных недо-пародиях — разработчик, что называется, “под боком” и доступен для общения, что плохого — какая-то мелкая функция, которая есть, но её пока (почти год) не использовали, но которая внезапно понадобилась тебе, — может просто тупо не работать (но можно заставить разработчика быстро починить).
    Читать полностью »

Давно зрела мысль описать что-нибудь из своего трудового опыта. Постепенно она развилась до идеи написать обзор рынка труда, как его видит работник и соискатель (точнее, автор в качестве работника и соискателя;-)). Изложение получилось несколько субъективное и не претендующее на полноту и “ортонормированность”, за что автор заранее просит его простить. Cделано оно на основе опыта, в основном опыта автора и его знакомых. Уклон как-то сам собой получился в сторону описания возможных неприятных неожиданностей. Статья состоит из трёх частей — “Какие бывают 'плюшки'”, “Подводные камни для новичка” и “Какие бывают работодатели”. Наиболее объёмна и подробна центральная часть — в ней, по мнению автора, собраны моменты, наиболее стоящие внимания. Первая и третья части тоже в значительной степени написаны с точки зрения “подводных камней”.

Под конец было решено разбить получившуюся статью в 35000+ знаков на три поста. В этом посте содержится первая часть.
Читать полностью »

Часть 1/3. Какие бывают 'плюшки'.
Часть 3/3. Какие бывают работодатели. Характерные особенности.

Подводные камни для новичка

Первые подводные камни, вообще-то, могут начаться ещё на собеседовании — например, проект новый, процесс интервьюирования ещё не налажен, первый вопрос может быть “Do you have a printed copy of your CV?” от иностранного представителя, в общем, на вас в качестве одного из подопытных кроликов этот процесс и будут отлаживать. Ещё вас могут внезапно поставить на “конвейер”: пропустить через три стадии собеседования по часу с лишним каждая сразу. Проблемы это может породить, если вы не подготовились к собеседованию или если у вас на это день назначены ещё другие собеседования. Но это так, к слову.

Общие соображения

Во-первых, есть некоторая естественная склонность при возникновении непоняток (что там было про управленческие и коммуникативные навыки?), трений и, тем более, конфликтов с участием новичка истолковывать их не в его пользу. Даже если новичок прав, то всё равно есть причины чтоб его уволить: ‘менеджер не может с ним сработаться’, чел ‘не вписывается в неформальный корпоративный формат’ или ещё что-то в этом роде. Если “не сработаются” и со следующим, то через пару-тройку кандидатов с кем-нибудь сработаются или задумаются, а может быть «что-то в консерватории поправить». В общем, если вы кому-то из начальства (или “старожилов” из тех, к мнению которым прислушиваются) внезапно (т.е. это не всплыло на собеседовании) чем-то “не понравились” (ну, например, чем-то ему напоминаете неприятную ему персону, что вызывает у него постоянное желание подколоть или уязвить вас или продемонстрировать своё остроумие вместо чёткого и ясного выражения того, что от вас требуется), то, как последний довод, кого проще уволить — новичка на испытательном сроке, которому надо заплатить за три дня, или полноправного работника, которому надо при прекращении трудового договора не по его инициативе заплатить за два-три месяца и с которым уже как-то сработались (хотя ещё и вопрос — захотите ли сами работать с таким человеком?)? И если они за пару-тройку итераций всё же найдут кого хотят, то спишут случай с вами на “мало ли что бывает”. “Вершить (социальную) справедливость — не наш профиль, нас дела ждут”.
Читать полностью »

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

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

Сразу оговорюсь, что это будут лично мои выводы, с которыми многие могут быть и не согласны. Буду признателен за конструктивные и познавательные комментарии и описания фрагментов вашего опыта. Не хотелось бы попыток «священных войн» в комментариях. Помните объявления о работе в 90-х с фразой «Не Гербалайф»? Аналогично — «Не холивар».

В статье затрону три темы:

  • Взгляд на код и разработку.
  • Немного о поиске работы на московском IT-рынке.
  • Взгляд на проекты, в которых пришлось поработать сквозь призму времени и информацию, которая была позднее освоена.

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

Четкой идеологической линии «Делай так и будет тебе счастье» нет. Основная мысль, которую я хотел вложить в материал — не стоит что-то идеализировать.

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

Итак, некоротко и местами несерьезно о серьезном…

Читать полностью »

Думаю, данная статья будет актуальна для многих IT отечественных НЕсофтверных компаний большого и среднего размера с «карманным» IT, не ориентированных на выпуск «коробочных» продуктов, более всего описанные ниже ситуации характерны для компаний, где IT является «приложением» к основному бизнесу. Статья ни в коем случае не претендует на истину в последней инстанции и не дает никаких «особенных» рекомендаций, кому что нужно делать, а лишь иллюстрирует возможные варианты развития возможных участников в ситуации «как сделать так, чтобы не загубить систему» с уклоном на составление ТЗ и на отношения в коллективе. Для многих ситуация может быть более чем очевидна, а некоторым откроет глаза, так что, возможно, кому-то и будет полезна, а также принесет в жизнь немного юмора.

Рассмотрим обычный пример из жизни обычных программистов в такой компании: разрабатывается большая система X, в которой много чего сложного и интересного (а иногда — не очень интересного) — и бизнес работает вполне успешно, и программисты есть, и менеджеры/аналитики — как связующее звено между бизнесом и программистами. Все вроде бы ровно, отлажено, работает. И кода много, и багов. И актуальной документации зачастую днем с огнем не сыщешь… В общем, все «как у всех». Жить можно.

Техническое задание: почему формулировка «Сделать как здесь» не срабатывает?
Читать полностью »

Действующие лица:
X – крупная известная компания, в которой открыта вакансия аналитика (условно)
A – сотрудник компании X, который проводил собеседования
B – представитель отдела HR компании X
С – кандидат на вакансию аналитика.
Читать полностью »

Мы этого НЕ любим!

Sorry, wrong hub...

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

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

На самом деле, пост о наболевшем: о многочисленных запросах на коннекшн в LinkedIn и последующем общении. А точнее о том, что нам в этом общении не нравится. Под «нами» я подразумеваю меня и ряд моих коллег, чьи мнения на данный счет, к моему удовлетворению, более-менее сходятся с моим. Это позволило использовать собирательный образ «мы» для составления нижепредставленного списка рекомендаций, чтобы он выглядел чуть более солидно. Читать полностью »

Я давно задаю себе вопросы и сам ищу на них ответы: что же есть «идеальная» IT-компания? Для разработчика, для менеджера, для владельца, для клиентов? Что есть «хорошая» IT-компания, что в ней должно быть и чего не должно? В результате для себя я сформировал вот такой вот список, такая квинтэссенция из пожеланий и собственного опыта. Может пригодиться любому разработчику, менеджеру, CEO. Возможно, это и несколько наивно, во многом — более характерно для компаний «не IT», но тем не менее… Принципы «идеальной» IT-компании в моем представлении. Простыми словами и немного по-детски.

Правила «хорошей» IT компании

Читать полностью »

Преамбула

Я разработчик в небольшой организации. Цель моей работы — делать людям хорошо. Я ускоряю их работу, добавляя тот или иной функционал к уже существующему продукту, моими клиентами являются сотрудники самой организации. Современный бизнес очень динамичен, каждый день появляются новые идеи и потребности, то есть мой план расписан на год вперед, и каждый месяц перестраивается под новые задачи.
 
Однако, на фоне, казалось бы, динамично растущего бизнеса (кол-во сотрудников увеличивается на 10-15 человек в год) отдел IT растет значительно медленнее. Основное требование к выполняемой работе: “Быстро!”, как следствие плохо масштабируемый код, подверженный плавающим ошибкам.
 
Сейчас наша компания переживает новый виток развития ПО (период 5 лет), постепенно мы отказываемся от старых разработок и переписываем то, что есть, придерживаясь объектной модели и паттернов, а заодно и переезжаем на новые сервера (новые железо + софт), но требования остались на прежнем уровне — все должно быть  сделано вчера.
 
В очередной раз при релизе кода работа сотрудников была парализована на пару часов, и ген. директор спросила: “Ребята, сколько это еще будет продолжаться?”, на что я ответил: “Когда завершится переезд”, а спустя сутки прислал более подробный ответ, описав то, что меня волнует в последнее время все больше и больше.
 
Зачем я это рассказываю? А затем, что моя история не уникальна. Кому-то эта статья даст пищу для размышлений, а то и подтолкнет к действиям. Кто-то поделится своим опытом, а кто-то в очередной раз порадуется, что у него в компании все намного лучше.
Читать полностью »

В статье Как я искал работу voff написал замечательную фразу:

Программисты сейчас находятся на особом положении, мы можем выбирать.

Это правда. Программистов ищут везде, от Москвы и Киева до Берлина и Сан-Франциско. Другой вопрос – как программисту эту возможность использовать? Пройти 17 собеседований, “по 3-4 в день”, как сделал автор статьи – на такой экстрим не все согласны. Да и подходит это только тем, кто сейчас без работы или уже обьявил о своем уходе руководству. А хорошие разработчики без работы сидят редко.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js