Привет.

Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.

Возможно, вы знаете, что закон РФ № 1032-1 от 19.04.1991 в редакции от 02.07.2013 г. запрещает распространять информацию, ограничивающую права или устанавливающую преимущества для соискателей по полу, возрасту, семейному положению и другим обстоятельствам, не связанным с деловыми качествами работников. И, наверняка, вы слышали, что работодатели отказывают кандидатам в связи с ограничением по возрасту. Закон запрещает декларировать это ограничение открыто и поэтому кандидатам отказывают по другим причинам. Да, это незаконно, но это существует.

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

Краткое содержание статьи — в конце текста.

Леха – отличный парень. Хорошо работает, исполнительный, с идеями, перспективный. Сделали с ним пару отличных проектов. Но он бегает от уплаты алиментов на ребенка от первого брака. Прям приходит и просит, чтобы как-то скрыть его доход, и «платить ей поменьше».

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

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

А я, когда всё это узнаю, думаю – ё ж твою через коромысло, вот нафига мне это знание?

Работа не приносит удовольствия. Рваный сон не приносит облегчения. Цвета поблекли — всё кажется серым и надоевшим. Ничего не получается, как будто тело стало чужой, незнакомой оболочкой. Код не пишется. Новые задачи воспринимаются со страхом и неуверенностью. С коллегами общаешься через силу — хочется закрыться, спрятаться, чтобы никто не трогал. Даже в почте и мессенджерах отвечать тяжело. Кажется, тебе уже никогда не стать прежним. Видишь успехи других — и понимаешь, насколько глупым и неумелым выглядишь со стороны. Срываешься на родных и друзьях — а потом ненавидишь себя за это. Крутишься белкой в мясорубке день за днём — и не видишь ни результата, ни выхода.

Знакомьтесь, если ещё не встречались. Это синдром профессионального выгорания.

В IT-сфере около 50% специалистов испытали на себе профессиональное выгорание. Этот синдром опасен самому сотруднику, и проекту, над которым он работает, и всей компании. Более 60% выгоревших сотрудников увольняются. А затраты на найм новых, обучение и онбординг чугунной гирей ложатся на бюджет. И время — оно вообще бесценно.

Раньше burn out не воспринимали всерьёз — считалось, что это способ особо хитроумных сотрудников поменьше делать и побольше отдыхать. Постепенно в наших пампасах культура психологический гигиены в бизнесе доросла хотя бы до признания, что профессиональное выгорание и депрессия — это реальные проблемы.

На митапе «День Техдира» Даниил Подольский, руководитель разработки MTGroup, сделал доклад по профессиональному выгоранию. Мне его выступление было интересно тем, что это взгляд управленца на проблему, а не просто рассказ рядового сотрудника о своём личном примере выгорания.

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

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

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

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

• «У телефона слишком много недостатков, чтобы его можно было серьезно рассматривать, как средство коммуникации. Устройство не представляет для нас никакой ценности», — писали специалисты Western Union, тогда крупнейшей телеграфной компании в 1876 году. 
  
• «У радио нет будущего. Летательные аппараты тяжелее воздуха невозможны. Рентгенография окажется обманом», — зажигал Уильям Томсон лорд Кельвин в 1899, и можно, конечно, шутить, что британские ученые зажигали еще в XIX веке, но мы еще долго будем измерять температуру в Кельвинах, и сомневаться в том, что многоуважаемый лорд был хорошим физиком, причин нет. 
  
• «Кто, черт возьми, захочет слышать, как актеры говорят?», — говорил про звуковое кино Гарри Ворнер, основавший Warner Brothers в 1927, один из лучших экспертов по кино того времени. 
  
• «Нет причин, по которым кому-то нужен домашний компьютер», — Кен Олсон, основатель корпорации Digital Equipment в 1977, незадолго до взлета домашних компьютеров…
  
• В наше время ничего не поменялось: «Нет никаких шансов, что iPhone получит значительную долю рынка», — писал в USA Today гендиректор Microsoft Стив Балмер в апреле 2007 перед триумфальным взлетом смартфонов.
  

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

Я живу на периферии технологической тусовки. И на периферии в географическом смысле. А это значит, что:

• Я никогда не был на профессиональных конференциях. Просто потому, что никогда не предоставлялось такой возможности.
• Я никогда не покупал обучающие курсы: для меня странно платить за то, что можно изучить самому в этих ваших интернетах или по книгам. Заманчиво, конечно, получить концентрированные знания, подкрепленные выполнением практических заданий, заполучить сертификат. Но на это у меня никогда не было ни средств, ни времени.
• Я адепт цифрового аскетизма: не по своей воле, но как порождение вечной перестройки в нашей стране. В короткие периоды финансовой стабильности я обновляю электронику по остаточному принципу. Вот и сейчас пишу этот текст на Core2Duo десятилетней давности. Все еще жду следующего стабильного плато на кривой моих доходов.
• Раза три в своей жизни я покупал игры. В 90-е. Это были кассеты для отживающего своё Спектрума. На покупку ПО я смотрю с удивлением: когда все пользовались пиратским ПО, то и я пользовался, не понимая сути вопроса. А потом, в начале двухтысячных, полностью перешел на Linux и покупать стало нечего.

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

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

Вот только почти все статьи не про разработку — в них нытье про мою депрессию. Я-то рад, что мне больше не надо никому ничего доказывать. Но вы что, с ума сошли котировать разрабов за такую чушь? Я думаю, сошли, и вижу тревожные симптомы этого везде.

Есть такие области знания, которые «аршином общим не измерить...». В принципе, в моей «домашней» области, коллоидной химии, под такое направление можно спокойно помещать любое фундаментальное понятие, будь-то адсорбция (с адсорбентами) или адгезия (с клеями). Честно говоря, мысль написать про клей у меня не возникала. Но когда читатели в каждой теме, связанной с полимерами начинают просить рассказать про клеи — об этом поневоле задумаешся (ну и хочется конечно же отпарировать на «все надо клеить суперклеем»). Адгезия и клеи — очень обширная тема, поэтому я все-таки решил за нее взяться, но разбить повествование на несколько частей. Сегодня первая часть — вводно-информационная. Чтобы узнать за счет чего клей клеит, какие бывают клеи и какой клей лучше подходит для склеивания _____ (вписать нужное), традиционно идем под кат (и кладем в закладки).

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

Я был на твоем собеседовании. Не на основном, а на кроссе. Я слышал, как ты рассказывал, что сам когда-то был программистом. Потом какими-то проектами внедрения руководил. Был очень успешным. Но за каким-то [фиг]ом пришел в нашу дыру.

Ты утверждаешь, что знаешь об автоматизации все. Ты называешь себя властителем душ программистов. Говоришь, что они у тебя танцуют, как кобра под дудочку.
Что ж. Проверим.

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

Я не буду здесь писать о «том, что не надо трогать руками» — об этом и так много написано, а я не Олег Айзон и уникальных фотографий невиданных доселе радиоактивных артефактов у меня нет. Я расскажу в общем — откуда у нас берется радиация.

Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd.

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

Сейчас объясню, как это работает.

Когда мне было шесть лет, мой район служил идеальной площадкой для активного и идиллического детства. На той же улице жило полдесятка моих сверстников, и мы быстро образовали свою детскую банду. Дни напролёт мы строили рампы для велосипедов, играли с мячом у меня во дворе и просто шатались по округе.

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

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

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

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

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

Предисловие для читателей Хабра — статья о поиске работы на рынке разработки в Украине (который в основном об аутсорсе на иностранных заказчиков), поэтому некоторые вещи могут показаться странными (LinkedIn, собеседования с заказчиками, обязательное требование разговорного английского, обсуждение ЗП в долларах) или нерелевантными для РФ. Тем не менее, статья имела большой успех на локальных ресурсах, и читатели попросили меня перевести её на русский.

Этой статьей я хочу начать цикл рассказов о том, как я на протяжении нескольких месяцев проходил собеседования в примерно 20-и разных компаниях на разные должности. Тут будут мои мысли о рынке труда, процессе найма, советы а так же несколько самых интересных историй. Цикл будет состоять из нескольких частей — HR собеседования, технические собеседования, финальные собеседования. Итак, первая часть.

Немного о себе. Программирую со школьного возраста, за деньги работаю 10 с хвостиком лет. Работал админом, программистом, тимлидом, РМ-ом, линейным менеджером. Выполнял обязанности SRE/DevOps, архитекта, HR, офис-менеджера, эникейщика.

Работал в кровавом энтерпрайзе, в стартапе, в аутсорсе. В основном занимался формошлёпством и крудами, имел дело с Java и бэкендом. За последние несколько лет пересел на фуллстек микс из Java, Ruby/RoR, Python, Node.js.

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

Всего я прошел примерно 20 собеседований с рекрутерами: половина из которых были из агенств и половина — штатные рекрутеры/HR компаний. Так что, могу сказать что некоторая статистика у меня есть.

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

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

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

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

Знаете что? Пусть катятся к черту.

На Хабре уже писали о различных расстройствах, но как-то так получается, что тема шизотипического расстройства остается не раскрытой. Да и в сети сложно найти информацию для широкого круга людей по этой теме. Часто можно встретить много раз скопированные копирайтерами тексты со множеством неточностей и откровенными мифами, а еще чаще — полную противоположность, заумные тексты, написанные врачами для врачей. Так, согласно DSM, шизотипическое расстройство — это демонстрация пациентом первазивной модели социального и межличностного дефицита, отмеченного острым дискомфортом и сниженной способностью к формированию близких отношений, который испытывает когнитивное и перцептивное искажение, а также проявляет эксцентричность в поведении, начинающеюся с ранней юности и представленную в различных контекстах. Если вы ни слова из этого не поняли — добро пожаловать под кат. Сегодня мы посмотрим, как все это выглядит изнутри.

В недавней статье товарищ KvanTTT поднял вопрос:

Можете пояснить что вам не нравится в современной записи (математических положений и) формул и как ее можно улучшить?

Я постарался ответить в одном комментарии, но размер текстового поля не позволил закончить выкладки. Данная статья — чрезмерно развернутый ответ.

Сразу скажу, материал холиварный. Местами слишком эмоциональный. Очень спорный. Слишком личный — часто основан на собственном опыте, небогатом, хоть и разнообразном. Пост касается школьных и университетских текстов учебников: у «профессиональной» литературы своя специфика, своя аудитория. Решения у проблемы в текущих реалиях нет. При этом, часть «моих» наблюдений задолго до меня высказывали такие авторитеты, как Кнут и Хэмминг; чуть менее популярные ребята даже запилили инструкцию "Как читать математику".

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