Monthly Archives: December 2010

Признаки увольнения, которые работают, но не всегда

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

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

  • человеку скучно. Он все время сидит, откинувшись на спинку стула, непрерывно ходит курить или пить чай, целыми днями торчит на развлекательных и новостных сайтах. Конечно, есть люди, для которых скука – естественное состояние. Тут важно заметить изменение – было ли так, что человек раньше пахал, а теперь ленится? Когда и после чего это произошло?
    А у меня было так: мне было скучно и я искал, чтобы все таки делать не скучное. И выглядело это как повышенная активность. И с “новостями” было все наоборот.
  • человеку лениво. Новые задачи принимает неохотно, на совещаниях спит, способен несколько дней смотреть на один и тот же баг. Именно смотреть, не пытаясь его разрулить.
    А у меня было так: новые задачи не принимал, зато как альтернативы предлагал другие решения, которые, по-моему (именно по-моему, вокруг много умных людей и они чатсо предлагали лучше моего), были на много лучше. А выглядело со стороны как очень мотивированный человек.
    Также получалось, что за все не хватался, а только за то, что интересно, а такая стратегия еще в добавок и результаты лучшие давала, потому что не распылялся и делал то, что больше нравится.
  • человек критикует. Ему все не так: заказчик – кретин, начальство – идиоты, нет нужного чая, а железо – тормознутое. В общем, «так жить нельзя». Примечание для менеджеров: в присутствии руководства рядовые сотрудники часто стесняются ворчать, поэтому признаками будут внезапно завершающиеся разговоры в вашем присутствии и массовые выходы в курилку даже некурящих. Особенно после сложных совещаний.
    А у меня было так: критиковал все время с самого начала, потом все меньше и меньше – ну, мол, что тут поделаешь, а в конце многие заметили что-то не то – ничего не критиковал. Ну оно и понятно, зачем критиковать, еще и конструктивно – это требует энергии, которая для меня важна была уже в другом направлении. Очевидно, довести до конца бы не получилось, поэтому и не хотелось критиковать (хотя все таки сдерживаться не получилось), а особенно если это могло на всю команду плохо повлиять.
  • при рассказе о долговременных целях по проекту и по фирме, человеку не интересно. Его-то это уже не коснется.
    А у меня было так: решения виделись довольно легко, но выполнять то не мне, поэтому можно было и помечтать
    🙂 Говорить – не мешки таскать, и сомнений предлагать что-то, что потом можешь не вылонить не было. И конечно же, понятно, что все таки я понимал, что не стоит давать знать что меня не будет в дологовременных перспективах – явно я это все таки не говорил. Но, все таки, хотелось, чтобы компания развивалась, и поэтому я действовал очень близко к тому, как бы это было, если бы я не собирался уходить.
  • человек дистанцируется – отодвигается от коллектива. Раньше кушал со всеми, теперь за своим компом. Раньше всегда ходил на корпоративы, теперь – нет. Раньше часто поддерживал любые разговоры, теперь – куда меньше.
    А у меня было так: Во первых поменял питание и поэтому начал ходить со своим и начал соответственно обедать со всеми в столовой в офисе, а не на улице, как раньше. А во вторых – стало интереснее как все вместе работает,  а не “копаться в деталях”, поэтому общаться наоборот стало интересней. Тем более, когда уже задачи не очень то и важны сами по себе, то начал смотреть как бы со стороны и свободнее себя чувствовать. И начал обращать больше внимания на то, какие интересные люди работают в компании. Свое все таки поднадоело, потому что начало получаться лучше. А принципиальные изменения делать не было особого желания – ценность и взгяды на них в моих глазах и глазах компании были разные.
    А общаться с людьми стало наоборот интересней, поскольку решение по сути уже было принято и сделать конкретный шаг было просто делом времени. И я, как будто бы, использовал последние моменты для общения.
  • человек много нахваливает фирмы-конкуренты.
    А у меня было так. Я всегда нахваливал фирмы-конкуренты, когда видел у них что-то лучшее. А в последнее время придерживался позиции, которая довольно далеко стоит от текущего моего положения. Видимо, окружающие воспринимали как интерес и не более, и уж точно, что никак это не приведет к каким-либо конкретным действиям. Как говорят, хочешь спрятать что-то – поставь его на самом видном месте. Для IT такое видное место – это Хабрахабр, хотя явно я там почти ничего не писал, да и применимо оно ко мне было далеко не во всем. Видимо, поэтому при уходе мне было довольно сложно объяснить, почему я ухожу.
В этом списке почему-то не нашел причину, если человек подходит и говорит о деньгах или о карьерном росте, что также связано с повышением ЗП в будущем – это как запретная тема какая-то 🙂 И по этому поводу я пока особо ничего не знаю, как иметь уже готовую альтернативу. Но альтернатива, как правило, с лучшими условиями, поскольку поиск уже был более целенаправленный и человек знает, куда идет. 
А еще мне  надоедает что-то делать, когда начинает получаться. Скука для меня, видимо на много хуже, чем дискомфорт.

Как писать и как не писать на Хабрахабре. Работа над ошибками

Исходные данные

На Хабрахабре есть пять статей в моем блоге с большим разбросом рейтинга от +129 до -8: +112, +129, +59, +20, -8.
“Работа над ошибками” заключается в том, чтобы понять, как писать так, чтобы получать больше голосов за статью.

  1. Сюрпризы при 3d-печати. Я ее писал, чтобы попробовать писать.
    Остальные имеют определенное отношение к моему опыту или очень близки к нему.
  2. Куда идешь, разработчик софта? – общие слова для большинства читателей. Я думаю, мало кто что-то взял для себя в плане применения на практике.
  3. Разработчики софта, давайте зарабатывать больше! – довольно конкретные мысли, которые могут применить большинство разработчиков ПО в своей жизни. Как минимум junior-ы и middle-ы. Но это требует определенных действий и выходить из зоны комфорта. Целевая аудитория Уже, чем во второй статье.
  4. В статье Профессиональная переориентация — смена технологий разработки ПО описаны конкретные сценарии, которые помогут решить абсолютно конкретную задачу. Требуемые действия еще более систематичны и требуют как краткосрочных волевых усилий, так и аккуратный долгосрочный расчет. Можно реально попасть  на деньги. Аудитория очевидно еще меньше, поскольку задача еще более конкретная и специфичная. Возможно статья бы набрала больше балов, если бы была структурирована, а не написана, как поток мыслей. Но это был в некотором плане также эксперимент.
  5. Вирусная реклама ВКонтакте — До нового года осталось… – опыт очень успешно решенной задачи. И по результатам задача решена такая, что многим разработчикам ПО даже и не снилось. Это вообще другой уровень – тут разработка ПО сильно переплетена с другими областями. ПО – это только часть успеха. Многие просто не сумели бы воспользоваться таким успехом.

Сюрпризы при 3d-печати

Большинство IT-шников любят “прикольные фишки”, вот и успех. Никакого применения в жизни 99.99% читающих быть не может, разве что для компании Materialise и ее конкурентов.

Куда идешь, разработчик софта?

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

Разработчики софта, давайте зарабатывать больше!

Очевидная стратегия была немного провокационно описана в первом абзаце. Хотя для меня было главное все таки то, что идет дальше. Но узнал, что большинство людей читают только первый абзац. Да, дальше тоже читают, но видимо на настроение читателей это уже мало влияет. Это можно понять из комментариев – складывается впечатление, что многие писали после прочтение только первого абзаца.
С учетом того, что провокационность многих провоцирует на -1, либо же на еще больший +1 (а больший +1 равен просто +1 на Хабре), то особо смысла это не имеет.
Для сравнения, на том же сайте Stackoverflow за “+” добавляют 10 балов, за “-” отнимают 2 бала. Как результат, если человек три раза “слажал” и раз качественно ответил, то он будет в плюсах и нет риска писать что-то действительно необычное и ценное. И тем, кто “не в теме” на много сложнее отправить пост в минусы.
На сколько мне известно., что публикация считается качественной, когда аудитория разделается, хотя я пока не знаю почему. Но на Хабре это ничего не дает.
Есть дополнительный риск не набрать +7, в таком случае страница не появится на главной странице и не получит своих 20000 просмотров.

Вирусная реклама ВКонтакте — До нового года осталось… редактировать

Статья набрала -8, чуть больше 4000 просмотров. Когда статьи уходят в минус (около -5), они переносятся на страницу “Отхабренные”, блог “Я пиарюсь”  и доступна только подписчикам блога – ее почти никто не видит. Это, конечно, можно потом вручную изменить.
Я этого не знал и не ожидал. Мне главное был не высокий рейтинг (на данном этапе он уже таковым не предполагался), а получиться побольше опыта. Вывод в том, что “слить” автора не так-то и просто, как мне казалось раньше. И карма в общем то упала на 1-3 балла. Видимо алгоритм такой, что карма сильно не падает при минусах. И даже при “слитой” статье автора слить не так то просто – приятная неожиданность для меня.

С другой стороны многим людям не нравилась сама вирусная реклама. И по комментариям можно понять, что людей мало интересовал сам механизм работы (это меня очень сильно удивило). Больше интересовало то, что читателям не нравятся сами картинки. Т.е. оценивают не внутренний механизм (здесь – это вирусная реклама), а результат (сами рисунки).
По ходу голосования были проведены некоторые эксперименты. Изменялся первый абзац – выводы отражены в Резюме.
Возможно также не следовало показывать рисунки самих граффити, все таки это где-то немного реклама. А если и показывать, то лучшие по симпатиям, а не, которые знаковые для развития вируса. Поскольку все хотелось сделать побыстрее, то и сама графити с эмблемой Хабрахабра делалась в спешке и была немного ниже качеством, чем другие графити. Но это я уже узнал потом. Думаю, мои друзья также найдут для себя опыт полезным. Но есть как есть. И более того, на сколько мне известно, статья позволила достичь той цели для которой  она и писалась.
В дополнение такие вещи, как логистика, переговоры, партнеры для многих всего лишь общие слова, хотя они играют неотемлемую роль в успехе проекта. Но на Хабре статья набрала отрицальное количество балов и является главным объектом исследования.
От себя могу добавит, что эта статья сопровождалась для меня очень интенсивным получением знаний. Но не это главное. Главное то, что я окунулся в атмосферу успеха…..

Резюме

Итак, конкретные рецепты, которые можно применить в будущем:

     
    • От первого абзаца зависит очень много – нужно уделять ему особое внимание при написании. 
    • Людям больше нравятся общие вещи читать. А если быть точнее, то больше читателей есть у общих вещей. 
    • Лучше писать что-то “беззубое”, чем действительно запоминающееся. Другими словами, на Хабре лучше придерживаться стратегии “Не обидеть”, чем “Кого-то удивить”. 
    • Если описываешь работу чего-то, то надо выбирать что-то популярное. А если все таки решил писать о непопулярном, то нужно разделять механизм и результат работы системы как можно сильнее. Например, в случае последней статьи – поменьше картинок, слово “успех” менять на слово “популярность”. Субъективное на объективное. 
    • Ни в коем случае не сравнивать “непопулярное” с “популярным”, если ты на стороне “непопулярного”. В данном случае в статье о ВКонтакте не должно быть ни одного слова Facebook
    • Внимательно относиться к рейтингам на разных сайтах. ВКонтакте видно лишь положительное отношение и не видно обратной стороны медали. А Хабрахабр это очень четко вскрыл – это был главный проcчет в последней статье. 
    • Не писать вначале что-то вроде “Мы знаем, что это кому-то может не понравиться, но мы пишем о внутренностях”. Никакого негатива быть не должно. После того, как я на некоторое время добавил такой момент, рейтинг с 0 (при +18-18) начал падать и упал до -4 -5, пока я эту фразу не убрал. Не могу не отметить, как мы ровно шли!!! 
    • Люди лучше относятся к тому, кто пытается их пожалеть, чем к тем, кто либо показывает действия, либо провоцирует к ним. К одной из таких статей (которая является классикой жанра) я ославил единственный абсолютно эмоциональный негативный комментарий из всех моих комментарием на Хабре. Прошу прощения за грубость, но эта статья – откровенное дерьмо. И меня удивляет ее высокий рейтинг. 
    • И самое главное. Прежде, чем писать, нужно изучить ресурс, сообщество и целевую аудитория. Многие из рецептов выше можно было бы понять, просто “полазив” по Хабру – статьи о ВКонтакте часто минусуются, если там замешан Facebook – статьи “убиваются” вообще. Также на Хабре – IT-профессионалы, а поклонники кроликов из последней статьи в основном дети. На меня рисунки никакого особого впечатления не произвели, а моя выборка состояла всего лишь из одного взрослого человека. Но с другой стороны было откуда взять позитивный опыт: блог компании ВКонтакте набирает очень неплохие балы, а иногда и очень большие. К слову, я Хабр почти не читаю.

Осталось всего лишь проверить выводы на практике.

Почему не любят PHP или мода в ИТ и разработке Software

Оговорки

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

Что такое PHP?

С помощью PHP можно быстро создать web-приложение. Начать писать можно очень быстро.

Есть некоторые проблемы с производительностью, но они по разному решаются. Например с помощью MVC. HipHop от Facebook. Собственно Facebook по большей частью написан на PHP и поэтому если им удалось решить проблему с производительностью, то и другим удастся.

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

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

А все ли хорошо с PHP?

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

Если же взять например .NET или Java со всеми ее технологиями, то там порог входа на много выше и если человек может писать на одном из этих языков, то, как правило, он уже что-то умеет и понимает.
 Т.е. с одной стороны это усложнение, а с другой – это фильтр.

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

Да, конечно есть языки со своей узкой областью применимостью, но эта статья не об этом.

Что же все таки происходит?

А здесь банальный отрыв от реальности. Как правило программисты хотят сделать что-то “классное”. Они заинтересоване в классном проекте. Но их особо не интересует, продан ли продукт 1000 пользователей или миллиону. Да и собственно это и понятно – от этих цифр для них ничего не меняется.

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

И инетрессные задачи действительно важно для программистов. Известно, что многие предпочитают известные компании, например Google или Facebook, не смотря на то, что при работе в банковской сфере вознаграждения значительно выше.

Хочу так же описать один пример дикости в ПО.
Возникло куча библиотек для логирования в Java. Нет, чтобы они повоевали и выжила сильнейшая. Так нет, написали библиотеку SLF4J которая как бы их всех сразу разрешает использовать….. и поддерживать, и обновлять, и изучать.

Так и этого мало, теперь вышел новый язык, о чудо, Scala – очередная серебряная, пуля.  И уже Java-исты поглядывают в ту сторону.

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

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

Не спроста появились Getting Real у 37 сигналов.

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

Говорят, что фундамент ПО легко менять – да это правда. Фумент то как раз легко поменять А вот если менять архитектуру, то это больше уже на кое-что другое похоже….. Я бы сказал на смену электропроводки в отделении “Скорой помощи”. Причем в ней уже за много лет добавляли свои розетки с нарушением всех норм. Но это было допустимо, потому что так нужно было, чтобы подключить аппарат искусственного дыхания для больного, попавшего в катастрофу. И если все привести в порядок, то медсестра, которая вас не предупредила, что обязательно нужна розетка, в следующий раз в критический момент просто не найдет розетку и это будет иметь очень печальные последствия, потому что кто-то просто сделал так, как посчитал нужным.
Это к тому, что в одних случаях эта проводка меняется по ходу дела, а во вторых доводится до критического состояния. А заметным это становится уже тогда, когда лампочки перестают гореть.

Резюме

  1. Речь о том, что главное упущено.
  2. Этой модой движут два мотива. Первый — подражание с целью перенять опыт или хороший вкус, второй — страх оказаться вне общества, быть осмеянным (боязнь изоляции). 
  3. Остается неясным, как искать компромис между долгосрочной и краткосрочной производительность.
  4. При необходимости нужно уметь быстро разбираться в новых технологиях для которых очевидно, что они будут успешными. И ни в коем случае не ловиться на все “новенькое”.

Скрытые возможности

Можно думать, что с этим делать. Но я поставил вопрос по другому: какие это открывает  возможности?

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

2. Бизнес-людям находить разработчиков, которые ориентированы именно на долгосрочный бизнес-результат, а не на “следованию моды”. Такие попадаются, но их мало. И завязывать их на этот долгосрочный результат (читай: доля в компании). Это уже тоже довольно часто встречается. Более того, мне известен случай, когда человек перешел на более высокую заработную плату плюс доля в компании.

3. Если Software Development – это Core компании, то видимо нужно создавать такую атмосферу, чтобы в компании было “модно”, пристижно работать, начиная с выбора технологий, заканчивая самим продуктом. Как это делать, точно знаю. Но кто-то очевидно это моду делает: Oracle, Microsoft? Зачем? Дороже вход – больше денег? Тут могу лишь процитировать диалог из фильма о моде “Дьявол носит Prada“:

– Я еще только учусь разбираться во всех этих шмотках…
– “В этих шмотках”?
Вы думаете, что они к вам не имеют отношения.
Вы подходите к шкафу и выбираете, не знаю, этот мешковатый голубой свитер поскольку хотите всем показать, что вы – человек серьезный  и вас совсем не волнует, во что вы одеты, но вы не знаете о том, что этот свитер не просто голубой.
Не лазурный. Не бирюзовый, а небесно-голубой. И вам невдомек, что в 2002 году Де Ля Рента создал коллекцию платьев такого цвета, а затем, Ив Сен-Лоран – коллекцию небесно-голубых френчей.
К нему нужен жакет.
И вскоре другие дизайнеры ввели небесно-голубой цвет в палитру.
А затем он просочился в крупные магазины одежды, а потом спускаясь все ниже, достиг магазина уцененных товаров где вы его и выудили.
Для появления этого оттенка были затрачены миллионы и тяжкий труд.
И хотя вы уверены, что сделанный вами выбор подчеркивает вашу независимость от моды, на самом деле вы носите свитер, который был выбран для вас людьми в этой самой комнате… из горы “шмоток”.

Управляющие ЛЮДЬМИ в IT компаниях о распределенных командах и зарплатах

Посетил Встречу управляющих ЛЮДЬМИ в IT компаниях.

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

От Александра Дымо и обсуждений аудитории

  • Начинать день с совещания (по сути, start up meeting), чтобы разогреть команду, и люди не читали первых пол-дня Хабрахабр и не пили кофе, а сразу начали работать. Все остальное – второстепенное.
  • В стартапах часто нельзя набрать задач даже на неделю – используется burn-down с недотягивающим до нуля низом, который должен во время спринта вырасти (“речка”).
  • Нужно всегда иметь возможность узнать, что человек делает в любой момент времени. В удаленных командах нельзя посмотреть из-за плеча.
  • Демократия не работает. В любом случае не явно получает власть тот, кто сильнее, как правило, технически.
  • Нужно всегда искать компромис между повышением авторитета (говорить всегда правильные вещи) и развитием (ошибаться)
  • Работает правило “Мы подумали и я решил” и псевдо-возможность выбора.
  • Коммуникацию нужно не только увеличивать, но и уменьшать.
  • В удаленных командах высокое качество кода более критично, чем в локализированных, поскольку нельзя заглянуть через плечо.
  • В проекте с 10 людьми есть опыт, что новый человек создает 160% проблем на 1 коммит.
  • Если у кандидата есть дети – не брать на удаленную работу.
  • Фрилансеры работаею на результат, а в продукте надо чтобы команда любила продукт.
  • Если после запугивания на интервью человек остался – точно выживет.
  • На интервью давать нерешаемые задачи – можно узнать много нового.
  • 1 “персик” на 50 “лимонов” (будет еще ниже)
  • Мотивация – это работать в продуктовой команде (От себя: ну и чего ж тогда программисты продажников не долюбливают, в продукте ж их больше чем в аутсорсе)
  • При найме неудачного человека падает производительность у всех: (а) из за “быдлокода” (б) “он мало делает, зачем мне напрягаться?”
  • Для удаленной работы идеально брать тех кто работал в Open Source продуктах.
  • Есть люди, у которой нет той части мозга, которая парсит чужой код.
  • “Красоту” кода можна проверить на задании на 5 строк кода.

От Василия Кривоноса и обсуждений аудитории

  • Иногда менеджеры хотят разрушить личность человека путем иницирования войны между чувством справедливости и естественным принципом найменьшего сопротивления (“получить больше наименьшими усилиями”) – дают возможность человеку повышать зарплату самому себе.
  • На интервью узнают только навыки и умения, а также опыт – как человек работает в реальной ситуации узнать трудно.
  • При наличии знаний производительность зависит от мотивации.
  • ЗП на много выше, если есть гарячая позиции – простой съедает гораздо больше денег.
  • Уникальным востребованным сотрудникам платят много, за риски остаться без работы.
  • Переговоры о повышении ЗП, если пришел уникальный сотрудник, с точки зрения сравнения с другими не понятно как вести. Сотрудник не может объяснить свои требования, а менеджер свои – не с чем сравнивать. Менеджеру лучше приводить к чему то среднерыночному по ближайшей похожей вакансии, сотруднику – выбирать лучшее среди компаний.
  • Есть компании, которые ищут “персиков” и готовы платить больше в несколько раз, чем “лимонам”. Компании не могут распознать “персиков” на собеседовании. “Персикам” нужно искать правильные компании и получить вначале как “лимоны” и быстро расти.
  • “Персик” от “лимонов” удирает.
  • Если есть команда синьеров и никого нового не хочет больше принимать, только таких крутых как они, наймите девушку. Плевать на опыт.
  • По статистике при смене работы ЗП повышается в среднем на 25%. За меньшее не перейдут, а больше не дадут. Это от 25 до 35. Больше – нифига не повышать, они либо всего боятся, либо им нифига не надо, либо они CEO и им не кому повышать (они находятся в вечной войне справедливости и принципом найменьшего сопротивления).
  • При частой смене компаний ЗП растет выше, чем при росте в одной компании.
  • Ценится “быть в индустрии”. Правило: один язык в год.
  • IT-шники верят в какую-то справедливость. Если миф разрушен – их домкратом не поднимешь.
  • Бонус должен быть не менее 50% от ЗП, за что-то очень супер конкретное, например за фик супермегабаги, должен платиться вовремя.
  • Безпроцентрый кредит сотруднику еквивалентен повышению зарплаты, особенно чувствуется, как только сотрудник его выплатит.
  • Хочешь узнать, сильно ли выросла ЗП – пропей дельту и оцени бодун.
  • Повыгать нужно гигиенически и с ростом профессионализма – человек должен знать за что.
  • Если твоя ЗП в нижней части вилки, иди выбивай, на тебе экономят. Наглость – второе счастье.
  • Зарплаты друг друга не знают, пока не побухают.
  • Повыжают ЗП на 0-X-2X-3Х. Для этого всех сортируют на 4 группы и делят деньги которые выбили из “Биг Босса”. Х обычно около 6%.
  • Уходят, как правило лучшие, потому что им не доплачивают.
  • Компания теряет 18 зарплат ИТ-шника, который уходит. Один HR, который предотвратил уход одного технаря в год, с лихвой отбивает свою ЗП. Дешевле платить немного выше, чем ждать, когда человек прийдет за повышением ЗП сам.
  • Повышение ЗП человеку, который пришел ее выбивать, работает максимум один раз.
  • В IT очень мало менеджеров, обычно это координаторы проектов.
  • Западные заказчики не понимают, почему у нас такой быстрый рост левелов у программистов.
  • Если нет денег на повышение ЗП, то и не нужно тратить деньги на дорогой чай и другие офисные понты. Сотрудники не подсчитывает эти копейки, а ищут, как уличить руководство в “аморальности”.
  • Схема повышения ЗП должна быть прозрачной.
  • У “торгашей” спрашивать причины повышения.
  • На “скромнягах” не экономить – уйдут как только узнают, что на них экономят и потеряете 18 ЗП. Дайте чуть меньше рыночного, а остаток вкладывайте в развитие сотрудника.
  • Если бухгалтер случайно накинула 100 баксов мотивированному сотруднику и он превратился в динамомашину, то сотруднику ничего не говорить и не менять, бухгалтера наказать.
  • Если сотрудник хочет больше денег, предложить подработать в фрилансе. Устанет искать первый заказ и успокоется.
  • Если человек хорошо ведет переговоры, то есть основания полагать что плохо кодирует.

А также:

  • Рекрутеры на слово Java реагируют как бык на красное покрывало, “Java наше все”.
  • Чудо-миф о том, что деньги айтишникам не нужны – туфта. Зарплата должна рости с профессионализмом.
  • В Киеве еще есть компании, которым нужнй чистые C++-ки (без MFC, Win32 и прочего хвоста) 
  • После того, как людям становится тесно в больших компаниях, они часто уходят в стартапы. В основном это сильные инженеры.
  • Люди делятся информацией и не жалеют ее.  У всех все очень интересно.
  • 495 маршрутка от  Республиканского Стадиона в Циклум не ездит 🙂
  • В Циклуме  такая-же кофе машина, как и в нескольких других компаниях, в которых я был – кофе тоже вкусный. Офис – обычный для больших компаний, на хорошем уровне. Да простят меня сотрудники компании за такую транслитерацию, ну не помню я как правильно произносится.
  • Было около 30-и человек.

Вика, еще раз спасибо за организацию и еще раз с прошедшим ДР!!!

A few tips for a successful Google interview

Ниже рекомментации от Гугла, как готовиться к техническому интервью с ними.
Больше всего меня рассмешила фраза “A few tips”. Это ж для кого они Few? – очень повеселило 🙂

Но зато есть еще “A few last tips” 🙂

И еще Гугл одна из немногих компаний, которая нанимает и готова платить за Algorithmic and Math Skills.

Небольшое видео о процессе найма:

Итак, выглядят рекомендации следующим образом:

A few tips for a successful Google interview:

The interview will include topics such as coding, data structures, algorithms, computer science theory, and systems design. We recommend you spend some time exploring our website to get into the right mind frame. Google Publications and Labs is a good starting point.

Google Labs Links:
http://labs.google.com
http://labs.google.com/papers.html

System Design Publications:
Google File System (http://labs.google.com/papers/gfs.html)
Google Bigtable (http://labs.google.com/papers/bigtable.html)
Google MapReduce (http://labs.google.com/papers/mapreduce.html)

Books to assist you in preparing for your interview:
“Programming Interviews Exposed: Secrets to Landing Your Next Job”
Authors: John Mongan, Noah Suojanen, and Eric Giguиre (Wiley Computer Publishing)

“Programming Pearls”
Author: Jon Bentley

“Introduction to Algorithms”
Authors: Cormen, Leiserson, Rivest & Stein

Please review the following topics:
Big-O notations also known as “the run time characteristic of an algorithm”. You may want to refresh hash tables, heaps, binary trees, linked lists, depth-first search, recursion. For more information on Algorithms you can visit:
http://www.topcoder.com/tc?module=Static&d1=tutorials&d2=alg_index

Coding: You should know at least one programming language really well, and it should preferably be C++ or Java. C# is OK too, since it’s pretty similar to Java. You will be expected to write some code in at least some of your interviews. You will be expected to know a fair amount of detail about your favorite programming language.

Sorting: Know how to sort. Don’t do bubble-sort. You should know the details of at least one n*log(n) sorting algorithm, preferably two (say, quick sort and merge sort). Merge sort can be highly useful in situations where quick sort is impractical, so take a look at it.

Hashtables: Arguably the single most important data structure known to mankind. You absolutely should know how they work. Be able to implement one using only arrays in your favorite language, in about the space of one interview.

Trees: Know about trees; basic tree construction, traversal and manipulation algorithms. Familiarize yourself with binary trees, n-ary trees, and trie-trees. Be familiar with at least one type of balanced binary tree, whether it’s a red/black tree, a splay tree or an AVL tree, and know how it’s implemented. Understand tree traversal

Algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.

Graphs: Graphs are really important at Google. There are 3 basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list); familiarize yourself with each representation and its pros & cons. You should know the basic graph traversal algorithms: breadth-first search and depth-first search. Know their computational complexity, their tradeoffs, and how to implement them in real code. If you get a chance, try to study up on fancier algorithms, such as Dijkstra and A*.

Other Data Structures: You should study up on as many other data structures and algorithms as possible. You should especially know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem, and be able to recognize them when an interviewer asks you them in disguise. Find out whatNP-complete means.

Mathematics: Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other companies because counting problems, probability problems, and other Discrete Math 101 situations surrounds us. Spend some time before the interview refreshing your memory on (or teaching yourself) the essentials of combinatorics and probability. You should be familiar with n-choose-k problems and their ilk – the more the better.

Operating Systems: Know about processes, threads and concurrency issues. Know about locks and mutexes and semaphores and monitors and how they work. Knowabout deadlock and livelock and how to avoid them. Know what resources a processes needs, and a thread needs, and how context switching works, and how it’s initiated by the operating system and underlying hardware. Know a little about scheduling. The world is rapidly moving towards multi-core, so know the fundamentals of “modern” concurrency constructs. For information on System

Design:
http://research.google.com/pubs/DistributedSystemsandParallelComputing.html

Helpful links:
– http://www.google.com/support/jobs/bin/static.py?page=gettingintogoogle.html
– http://www.youtube.com/watch?v=w887NIa_V9w
– http://www.youtube.com/lifeatgoogle
– http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html

A few last tips:
• Talk through your thought process about the questions you are asked. In all of Google’s interviews, our engineers are evaluating not only your technical abilities but also how you approach problems and how you try to solve them.
• Ask clarifying questions if you do not understand the problem or need more information. Many of the questions asked in Google interviews are deliberately underspecified because our engineers are looking to see how you engage the problem. In particular, they are looking to see which areas leap to your mind as the most important piece of the technological puzzle you’ve been presented.
• Think about ways to improve the solution you’ll present. In many cases, the first answer that springs to mind isn’t the most elegant solution and may need some refining. It’s definitely worthwhile to talk about your initial thoughts to a question, but jumping immediately into presenting a brute force solution will be received less well than taking time to compose a more efficient solution.

Хабрахабр "Профессиональная переориентация — смена технологий разработки ПО"

Написал на Хабрахабре статью Профессиональная переориентация — смена технологий разработки ПО”.

Сначала хотел в блоге написать. Но потом увидел, что статья получается довольно большой, и, как мне показалось, что довольно интересная. Причем, периоднически встречал, что люди интересуются темой. Решил опубликовать на Хабре. Но оказалось, что она не на столько интересная читателям, как я думал. Но я теперь это точно знаю.

Еще проводил эксперимент – не структурировал ее вообще – просто поток текста. Интересно, на сколько это повлияло на ее рейтинг.

На данный момент 11000 просмотров.

Заметил в интернете казус при перепосте статьи.
В эпиграфе есть фраза: Мы ждем перемен!.
Она намеренно зачеркнута, чтобы четко дать понять, что нечего ждать. Нужно действовать.
А при перепостах она себе нормально написана, не зачеркнута, мол будем ждать с моря погоды. А погода не приходит.
“Время все меняет” – это поговорка, это не правда. Только поступки что-то меняют. Если нет поступков – все остается прежним” (с) House M.D.

5 приглашений на интервью за последние 2 недели после изменения профиля с C++ на Java

Удивило количество приглашений на интервью за последние 2 недели.
Всего 5 штук. Я инициативы никакой не проявлял.

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

    Думаю, ключевыми явились следующие факторы (в порядке значимости):

  1. Смена работы вообще. Т.е. человек готов к изменениям.
  2. Смена технологии: было C++, стала Java
  3. Появился опыт удаленной работы.
  4. Написание в Summary в своих профилях чего ты собственно хочешь и тебе интерестно.
  5. Опыт тимлидера
  6. Опыт написания алгоритмов и математика

Немного о предложениях (без названий компаний). Одна компания очень, очень известная с офисами во всем мире, до недавнего времени считалась самой желанной для работы Software Engineer-ов, сейчас ее сменил Facebook.
Вторая связана с опытом C++, Java. Опять же что интересно, HR-ам на заметку, что когда предлагают C++, то подразумавают еще Win32 API, MFC. Я полгода назад на такое интервью ходил, чтобы вспомнить что это такое.
Еще в двух предложениях все факторы сыгралы свою роль по чуть-чуть.

И последнее интерестное и необычное приглашение. 30 $/час. Это уже компания, которая собирает людей, работающих удаленно, делает для них дополнительное тестирование, помимо скриншотов требует еще и включенную веб-камеру. Похоже, что ищут мастера на все руки, который асс во всем, либо же просто пополняют свою базу.
Видимо бизнес делают на том, что предоставляют более высокое качество и меньшие риски удаленной разработки ПО по сравнению с биржами удаленной работы.

И пару слов о “незримом опыте”.
Всегда есть базовая технология/технологии, в который вы эксперт. Все остальное придает мощи, по крайней мере на первых порах.
Например, каким бы ты классным тимлидером не был, но если ты TL команды на C++, то самым плохим TL-ом на Java вряд ли получится стать, ну разве что откровенно плохим – сначала нужно подучить матчасть.
С другой стороны, при равных технологических знаниях опыт менеджмента, soft skills дает огромное преимущество, но опять же нужно иметь базовую технологию, на которую это все наматывать.
Чтобы поменять технологию, возможен даже “дауншифтинг” с последующим очень быстрым ростом за счет других качеств. Кстати, эти другие качества многим может быть очень сложно приобрести. Тут главное видеть свою дальнюю цель и к ней идти.

UPD:

За следующую неделю еще где-то 4