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

Основный недостаток большинства оценочных процедур – их субъективность, низкая надежность при оценке знаний и навыков человека. Люди не хотят говорить правду, зачастую выдают теоретические знания за практические навыки. Чтобы отобрать правильных кандидатов, разработаны несколько видов интервью. Одно из них – это поведенческое – то из немногих, которое действительно позволяет понять, что же реально знает и умеет кандидат.

Читать дальше – будет много букв и примеров …

Приветствую уважаемое хабрасообщество!

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

Большинство работодателей на собеседовании дадут вам возможность задать любые вопросы. Это отличный шанс определить, хорош ли работодатель и стоит ли на него работать. Одной из смертельных болезней для коллектива является имитация бурной деятельности (далее ИБД). Она возникает там, где руководство заключается не в координировании работ, а заменено формальным контролем, где коллектив топчется на месте, десятками лет не получая новых задач, где нет места вашему стремлению к новым технологиям, где вы не научитесь ничему новому. Интрига усиливается тем обстоятельством, что имитатор никогда не признается, что он лишь имитирует работу. Наоборот, он будет напускать на себя и свою деятельность важность. Лишь когда вы поваритесь в коллективе годик, вы поймёте, что не надо было сюда идти, что вы просто теряете время. Но есть несколько простых признаков, по которым можно легко вычислить болезнь. О них эта заметка.

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

В качестве преамбулы — по моему опыту есть много причин по которым руководство недовольно персоналом (лень, низкий уровень подготовки, отсуствие стратегического мышления, нелояльность и т.д.). При этом 99% жалоб на руководство состоят лишь из упреков в неверной постановке задачи. Конечно же, часто этим нерадивые исполнители оправдывают собственную некомпетентность «переводя стрелки», но все-таки факт интересный. Хотите улучшить мнение сотрудников о вас? Учитесь четко ставить цели.

Целеполагание — наука не новая. Лично мне очень пригождается в жизни концепция S.M.A.R.T. и запоминается легко и слово красивое.
Расшифровок много, когда то собирал даже «коллекцию» из них. Самая простая из расшифровок —

Что за этими красивыми словами?

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

Замечательный сайт www.sorting-algorithms.com позволяет увидеть, как сортируются данные разными алгоритмами. Вы сможете посмотреть анимацию в зависимости от алгоритма, исходных данных.



Все это бегает и сортируется прямо на ваших глазах!

Работает на Google App Engine, видимо, поэтому и лежит от посетителей с «Хабра».

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

Привет, хабрадрузья!
Как уже обсуждалось здесь, на русском языке вышла книга 37 signals «Rework».
Хотел бы поделиться с вами своим мнением относительно неё.

Эту книгу ждали многие. В их числе был и я. Rework произвел на меня впечатление еще в англоязычном варианте. Оставалось узнать, насколько он хорош в русскоязычном.

Есть программа, которая должна сохранять и загружать некоторые настройки: позицию и размер главного окна программы, идентификатор выбранного языка, время последней проверки обновления. Я задался вопросом — где программа должна хранить свои настройки? Решил собрать информацию на эту тему и поделится ею с вами.

Возможные папки, для хранения настроек и файлов программы:

• Program Files
• My Documents
• User\Application Data
• User\Local Settings\Application Data
• All Users\Application data

Для того, чтобы старшему ребёнку давать примеры на сложение и вычитание в столбик, написал скрипт на Groovy, который генерирует LaTeX с примерами.
Цель была попрактиковаться в груви, ну и писать примеры от руки надоело.

Раньше на латехе ничего не писал, но что это и зачем нужен знал из Универа.
Часа два трахался с тем, как на LaTeX сделать нужный вид столбика.
Для работы с LaTeX поставил соответствующие пакеты из CygWin.

Вот скрипт, надеюсь кому нибудь пригодится:

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Итак, в новостях снова пишут, что кто-то еще умер из-за игромании. Да, опять Корея.

Какого ...? послушайте, я не пытаюсь доказать что видео игры — это героин. Я полностью понимаю, что в данном случае у жертвы было много проблем в жизни. Но, половина из вас знает что World of Warcraft затягивает и что доктора считают игровую зависимость серьёзной проблемой. А вопрос вот в чем: может быть какие-то игры намеренно разрабатывались, чтобы заставлять вас играть в них, даже если вы не получаете от этого удовольствия?

Введение

Думаю, многие из вас слышали выражение «9 женщин не могут родить ребёнка за 1 месяц!». Контекст этого выражения очевиден — в разработке ПО его применяют в качестве аллегории, когда протестуют против совершенно неприемлемого сжатия сроков. Здесь под сжатием понимают сокращение сроков разработки путём расширения команды при сохранении общей трудоёмкости разработки.


Совершенно очевидно, что сжимать сроки до бесконечности невозможно. Существует определённый предел. Например, известным экспертом в области оценки трудоёмкости разработки ПО Стивом Макконнеллом (Steve McConnell) этот порог определён как 25% от исходных оценок (см. мою предыдущую статью).
Но этот топик не об оценках трудоёмкости…
Вот я выше написал «совершенно очевидно...». Думаете, это действительно очевидно? Всем?
Мой недавний опыт показал, что это очевидно далеко не всем. Проект был очень крупный и срок сдачи неумолимо приближался. Было принято решение резко расширять команду, чтобы успеть. Довод про «9 женщин» никто не принял. Команда была расширена и в срок мы всё равно не успели. Можно ли было как-то, кроме как на словах, показать, как будут развиваться события? Вот о том, как смоделировать такую ситуацию, и будет моя статья.

В этом топике вы найдете немного ностальгии, каплю гнева и килограмм реверс-инжиниринга. Посвящается тем, кто знаком с программой «Звукозапись» не понаслышке :)

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

Шли годы. Железо становилось мощнее, а ОС функциональнее. Но «Звукозапись» не менялась. Даже в Windows XP она оставалась такой же, как и тогда. Пришло время обновить железо. 3 гигабайта оперативной памяти — раньше и мечтать о таком не приходилось. Этого уж точно должно хватить всем! Так и было, пока дело не дошло до той самой «Звукозаписи». После попытки записать небольшой звук программа невозмутимо возразила, что ей недостаточно оперативной памяти.

Представляю вашему вниманию «анимационную работу» — The Zoomquilt II
Штука весьма интересная и выносящая мозг. Нарисовано в стиле и очень даже неплохо, но главное тут — сама идея… )

P.S. Может напутал с блогом, но более подходящего не нашел
_________
UPD Перенес в блог «Странные Идеи», т.к. была найдена схожая статья, созданная там же еще в далеком 2007-ом :)
UPD2 Первая часть. Спасибо Demlock