• Пиши резюме правильно или “умею улыбаться и пеку оладушки”

    Update статьи “Пиши резюме правильно или “умею улыбаться и пеку оладушки”.

    Начну с того, что я IT рекрутер. В этом тексте выражено только мое мнение по вопросу составления резюме. Это вовсе не значит что мои коллеги по отрасли считают также. Возможно, с чем то-то они согласны, с чем-то нет.

    Да, каюсь, в первоначальном варианте статьи, опубликованном некоторое время назад, я несколько категорично выразила свое мне о наличии и качестве фотографии в резюме. Давайте поступим так: ставить фотографию или нет — решать вам. По своему опыту могу сказать лишь, что:

    1. Работая в IT кадровом агентстве, я общаюсь с кандидатами только по телефону и мне психологически комфортнее представлять себе человека визуально. Возможно вам тоже. Часто процесс трудоустройства растягивается на недели, а то и на месяцы. В этот период я веду с кандидатом переписку, общаюсь по телефону и в скайпе. Волнуюсь за него, особенно если процесс рассмотрения резюме почему-то затягивается, а человеку срочно нужна работа. Если история заканчивается хорошо, и кандидата приглашают в компанию — радуюсь. И так изо дня в день, и из месяца в месяц. Человек становится уже в чем-то близким для меня. И не представляя его визуально — чуть сложнее и как-то грустнее, что ли, работается.

    Поэтому фото в резюме важно для меня, как для рекрутера.

    2. Для руководителя, ищущего специалиста себе в команду — фото в резюме кандидата может быть важно по другой причине: с этим человеком он и его коллеги будут работать по 8 часов в день 5 дней в неделю. И хочется, чтобы человек вписался в команду. Конечно, понять, впишется специалист в команду, или нет, можно только на собеседовании, и то не всегда. Но всех на собеседование не пригласишь, у руководителя мало времени для этого. Фото в таком случае выступает для него одним из фильтров для экономии времени.

    Отталкиваясь от этого, решать, размещать ли фотографию в резюме, и какую именно — вам. Я лишь попробовала объяснить, почему это может быть косвенно полезно при поиске работы.

    И напоследок, перед тем как вы начнете, уже наконец, читать саму статью, хочу попросить вас — не стесняйтесь комментировать! Ваше мнение для меня очень важно, потому что вы — мои друзья, или коллеги по отрасли или те, кому я звоню каждый день, говоря: ”здравствуйте, я нашла ваше резюме..."

    По долгу службы я каждый день просматриваю HeadHunter, Linkedin и множество других ресурсов для поиска на предмет IT специалистов разного толка.
    Находясь по ту сторону HeadHunter’а, не перестаю удивляться изобретательности тех, кто находится в поиске работы.
    Предлагаю поговорить о том, как эффективно позиционировать себя на рынке труда.
    Правильное продающее резюме это первый и главный шаг к работе мечты.
    Рекомендации будут практические, проверенные на собственном опыте как со стороны соискателя, так и со стороны рекрутера.
    И как же оформлять резюме?
  • Насколько в вашей компании ощущается текучка кадров?

      В последние годы ИТ сфера набрала высокую популярность и испытывает недостаток кадров. Для того чтобы заполучить ценных сотрудников, компании часто предлагают условия, о которых на представителям многих профессий даже мечтать не приходится. Агрессивно хантят людей на конференциях и ИТ тусовках, переманивают из других компаний и т.д.

      В результате личных наблюдений и из общения с друзьями, на примере нескольких компаний я заметил, что сейчас есть текучка кадров. Разработчики меняют работу раз в год, и даже раз в несколько месяцев в поисках все более лучших условий. То чай в компании не вкусный, то окна с видом не на море :)

      Интересно узнать, как с этим обстоят дела в компаниях пользователей хабра.
      Насколько в вашей компании ощущается текучка кадров?

      Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    • О техническом собеседовании

      У Вас есть продукт, устоявшаяся команда и финансирование. Вы (команда) хорошо работали, и руководство готово заплатить еще денег чтобы нанять человека, чтобы, соответственно, ускорить разработку, повысить качество и иметь возможность тратить ресурсы на технологическое развитие продукта. Вы уже разместили на hh объявление с хорошей зарплатой и ярким описанием, которое заинтересовало бы и вас самих, отобрали 20 кандидатов и уже завтра начнете проводить собеседования. Осталось только придумать, что именно спрашивать. Знакомая ситуация? Тогда добро пожаловать под кат.
      Читать дальше →
    • СПУ = PMBok, или все новое – хорошо забытое старое?

        Известно, что контуры проектного управления как современной научно-инженерной дисциплины начали оформляться в 50-х годах XX века в США. В этот период было положено начало методике календарно-сетевого планирования.

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

        Немногим известно, что в СССР существовала отдельная дисциплина под названием «Научная организация труда» (сокращенно – НОТ), включавшая в себя ключевые методы и инструменты проектирования, которые успешно применяются сегодня в PMBok.

        Но обо всем по порядку.

        Читать дальше →
      • Официальный гайд по лучшим практикам в Symfony

        • Tutorial
        Fabien Potencier, ментейнер Symfony несколько дней назад представил черновую версию гайда лучшх практик, для разработки приложений с использованием Symfony, как фреймворка (напомню, что также это набор независимых компонентов).
        Мы знаем, как сложно отучиться от старых привычек и некоторые советы шокируют вас, но следуя им вы сможете разрабатывать приложения быстрее, сделать их менее сложными и в то же время более качественными.
        В любом случае стоит помнить, что это всего лишь рекомендации и ваша команда не обязана им следовать. Вы можете продолжать использовать свои подходы, Symfony достаточно гибок для любых нужд и это никогда не изменится.

        Под катом я выписал основные тезисы, большинство из них подробно аргументируется внутри книги, в некоторых «шокирующих» местах помимо тезиса есть небольшое объяснение.
        Читать дальше →
      • Управление зависимостями в сложной Agile-среде

        Перевод статьи «Dependency Management in a Large Agile Environment».

        Краткий обзор


        Департамент разработки Salesforce.com включает в себя более 30 Scrum-команд, совместно работающих над общим кодом в одной и той же ветке системы контроля версий. Статья описывает методы, используемые salesforce.com для масштабирования Scrum-подхода и для управления межкомандными взаимосвязями.

        1 Введение


        В октябре 2006 года начался грандиозный переход отдела разработки (R&D) salesforce.com от модели водопада к гибким методологиям, основанных на Scrum. На тот момент прошло 10 месяцев с предыдущего мажорного релиза, а дата выпуска нового переносилась уже пять раз. Многих расстраивало, что продукт выпускается редко и с серьёзными опозданиями. Мы не стали дожидаться завершения релиза, реорганизовали существующие команды в Scrum-команды и с помощью процессов Scrum выпустили релиз в феврале 2007 года. С тех пор, используя наш новый гибкий подход, мы выпустили уже пять мажорных релизов (длительностью в 3-4 месяца) нашего набора SaaS приложений и платформы Force.com. Каждый из них состоялся точно в запланированный день.

        Во время реорганизации мы следовали рекомендациям Scrum для отдельных команд, но не обращали особого внимания на взаимодействие между командами. Формируя команды, мы стремились минимизировать зависимости между ними, однако код не изменился в одночасье, так что сохранилось немало взаимосвязей. Довольно скоро мы внедрили Scrum-of-Scrum meetings. Эти встречи помогали обсуждать проблемы и состояние дел, но одних только собраний было недостаточно. Работая над последними пятью релизами, мы опробовали и отшлифовали дополнительные подходы, улучшающие взаимодействие команд. Далее в статье мы расскажем о некоторых трудностях с управлением зависимостями и о том, как мы преодолели эти проблемы.
        Читать дальше →
      • Стартап: «Идея», «Реализация», «Продажи»…



          Тема «стартапинга» IT-продуктов была весьма популярна пару лет назад… Сегодня «стартап» не делал только ленивый. Сколько их — «проваленных» проектов? Тысячи, десятки тысяч?..
          Стартаперы «забывают» о простой истине: «Идея ничего не стоит без реализации. Реализация ничего не стоит без продаж.» Что нужно для «успешной» реализации? «Хорошая» команда? «Правильная» методология управления проектом? А что нужно для продаж?..

          Об этом и о многом другом рассказано в данной публикации, причем не голословно, а на примере конкретного «стартапа».

          Внимание! Под хаброкатом ОЧЕНЬ длинная статья...
          Читать дальше →
        • Как искать клиентов для небольшой региональной веб-студии

          image
          К сожалению у нас таких не было.

          Хочу поделиться нашим опытом привлечение клиентов для вновь созданной веб-студии. Основанием нашей веб-студии официально можно считать 31 августа 2012 года, именно тогда мне выдали свидетельство о регистрации меня как индивидуального предпринимателя. С этого момента было перепробовано много методов привлечения клиентов в нашу молодую веб-студию. Все будущие сотрудник еще трудились на прежних местах работы и по вечерам делали сайты, а я в свою очередь пытался найти клиентов, совмещая с эникейством нескольких не больших организаций (да и так бывает, менеджер из эникейщика). Разработкой сайтов профессионально никто из нас раньше не занимался и естественно, как и кому продавать сайты тоже не знали. Все делалось путем проб и ошибок. Сначала не было даже программиста, был дизайнер и верстальщик в одном лице (в то время не очень сильный) и я в роли менеджера (тоже откровенно слабый).
          Приступим к перечислению что делалось, как работало, а что не приносило результата:
          Читать дальше →
        • Метахабы — зло

            Метахабы — это хабы общей направленности, на которые нет смысла подписывается (если вы вообще пытаетесь фильтровать Хабр), потому что в лучшем случае на один пост в сфере ваших интересов там будет два-три вообще не для вас.

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

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

            Для примера разберу метахабы из раздела «Программирование»:
            • Программирование
            • Веб-разработка

            Читать дальше →
          • Как накормить мозг программиста… или feed your brain

            Введение


            Из всех наслаждений, отпущенных человеку в жизни,
            самое изысканное — шевелить мозгами.
            (Борис Акунин)


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

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

            В данной публикации мы рассмотрим, как правильно питаться для жизнеобеспечения мозга и как его разогнать ноотропами (в случае аврала необходимости).
            Читать дальше →