Как на самом деле выглядит типичный программист, выяснили разработчики DataArt
Давно приходилось слышать стереотипы о бородатых, угрюмых «айтишниках» в свитерах? И хотя Стив Возняк вряд ли похож на Линуса Торвальдса, как и тысячи IT-специалистов на своих коллег, в образе «типичного программиста» до сих пор ищут тот самый свитер, бороду или очки. Но действительно ли профессия так или иначе влияет на внешний вид? Этим вопросом задались специалисты DataArt, международной компании, специализирующейся на проектировании, разработке, модернизации и поддержке IT-решений. Проанализировав несколько тысяч фотографий разработчиков из восьми стран, авторы проекта составили портрет среднестатистического программиста.
Сериал «Кремниевая долина». Источник: wired.com
Как отмечают в DataArt, в компании давно сложилось внутреннее комьюнити, участники которого профессионально занимаются машинным обучением. Периодически внутри группы проводятся различные R&D проекты. Накануне несколько участников сообщества решили попробовать подойти к решению задачи создания обобщенного портрета программиста с разных сторон. Реализация идеи заняла несколько дней, в процессе работы подход к решению задачи менялся несколько раз. Для эксперимента были отобраны фото 1541 мужчин и 512 женщин, которые работают с DataArt в восьми странах мира — Аргентине, Болгарии, Великобритании, Германии, Польше, США, Украине и России. Для анализа использовался метод, описанный Сатьей Маллик и основанный на выделении ключевых 68 точек каждого лица в выборке: координат уголков глаз, бровей, губ, носа и так далее. Далее лица были разбиты на треугольники по ключевым точкам, цвет пикселей внутри полученных треугольников для всех лиц в выборке был усреднен. Код проекта был написан на языках C++ с использованием фреймворков dlib/opencv. В результате на первом этапе удалось получить портреты «типичных программистов» — мужчины и женщины. Второй этап На втором этапе исследования инженеры DataArt попытались выяснить, накладывает ли свою печать на внешность разработчика выбор той или иной технологии? Для этого авторы проекта разбили выборку еще на несколько групп и создали портреты типичных программистов, специализирующихся на конкретных языках. В частности, пока авторы проекта экспериментировали с фото разработчиков на Java и в .Net. При этом чтобы сохранить наибольшее число характерных черт при минимуме объединяемых портретов, для каждой группы был применен спектральный анализ векторов, соответствующих определенным чертам лица.
«Довольно известен эксперимент Перетта, посвященный изучению привлекательности лиц. Исследователь пришел к выводу о том, что средний портрет, составленный из многих, не всегда самый привлекательный и уступает портрету, составленному из меньшего количества лиц самых привлекательных представителей. То есть привлекательные лица как правило сильно отличаются от среднего по всем лицам вообще, таким образом, отклонение от медианы — это необходимый признак привлекательного лица. Мы решили развить эту идею и пойти дальше. Мы использовали спектральный анализ и автоматически, без участия людей выбирали лица с наибольшим отклонением от средних показателей — с самыми маленькими или большими носами, очевидно круглые и вытянутые лица и так далее. Таким образом мы добивались выполнения необходимого условия по Перетту и в результате получили не безликие лица, а вполне симпатичных людей с характером», — рассказывают авторы проекта.
В итоге эксперимент показал, что некоторые различия все же есть: разработчики в конкретной области немного отличаются от общего портрета: например, мужчины-разработчики на Java более улыбчивые, а у специалистов .Net хуже зрение — они чаще носят очки. А девушки в целом улыбаются чаще. 
По словам исследователей, первоначально слияние множества лиц привело к тому, что использование более 20-30 фотографий с усреднением ключевых точек приводит к появлению почти идентичных лиц. Отчасти это можно объяснить тем, что большинство фото – это портреты разработчиков из России и Украины, и лицо стремится к славянскому типу. Еще один вывод: усредненное лицо приобретает почти идеальные пропорции. Именно поэтому, чтобы не создавать «икону разработчика», как замечают авторы проекта, решено было применить спектральный анализ с целью отбора нескольких лиц, максимально выделяющихся из «средних по палате» и только потом комбинировать их. 
Кроме того, эксперименты с кластеризацией при помощи двух различных приложений, использованных в оригинальном методе, были слишком трудоемки, что, в свою очередь, привело к необходимости объединить приложения и решить технические проблемы: например, избыточное потребление памяти, скорость обработки батча, «потерю» лиц на исходных маленьких изображениях. В целом же, как отмечают участники проекта, эксперимент наглядно показывает: лицо «типичного программиста» почти не отличается от лица представителя какой-либо другой профессии. Хотя отдельные черты все же и могут встретиться во внешнем виде, возможно, даже вашего знакомого разработчика.
«Судя по всему, у типичного программиста нет какого-то ярко выраженного сдвига во внешности в ту или иную сторону. Этого, в общем, можно ожидать от среднего портрета и в целом соответствует ожиданиям от внешности разработчика. Возможно, 20-30 лет назад портрет среднего программиста бы отличался. Сейчас программист может выглядеть как угодно, это популярная профессия, не требующая каких-то специальных данных и не накладывающая особый отпечаток», — комментирует Дмитрий Соболев, участник проекта, senior developer.
«Трудно сделать обобщение для всех, но уже для промежуточных результатов получилось стопроцентное попадание: знакомый .Net разработчик оказался как две капли воды похожим на усредненный портрет, плюс он действительно носит очки. Неожиданным оказалось то, что требуется объединять так мало фотографий, чтобы получить почти идеальное лицо. Хотя подобное исследование привлекательности и приведено у Перетта, наблюдать то же самое “улучшение” черт лица на ограниченном наборе фото было как минимум любопытно», — подводит итоги Андрей Сорокин, участник проекта, senior developer.
DataArt показал, как в действительности выглядит типичный программист
DataArt, глобальный технологический консультант, создал портрет среднестатистического программиста. Обобщенный портрет был составлен на основе двух тысяч фотографий разработчиков из восьми стран. Вопреки распространенному мнению, у типичного программиста нет бороды.
Выражение «типичный программист» встречается довольно часто, но в действительности никто не знает, что за этим стоит. В зависимости от личного опыта, под этим могут понимать и корпулентного бородача с банкой пива, и молодого человека в толстых очках, который заправляет свитер в джинсы, и хипстера с расписными руками и розовым ирокезом. DataArt решил выяснить, кто в действительности стоит за этим понятием.
Для анализа взяли фото 1541 мужчин и 512 женщин, которые работают с DataArt в восьми странах мира — Аргентине, Болгарии, Великобритании, Германии, Польше, США, Украине и России. В результате получились портреты усредненных программистов — мужчины и женщины.
Усредненные программисты — мужчины и женщины, собранные алгоритмом из портретов более 2 тыс. человек
Для слияния предварительно обработанных алгоритмом лиц за основу был взят метод Сати Маллек, основанный на выделении ключевых 68 точек каждого лица в выборке — координат уголков глаз, бровей, губ, носа и так далее. Далее лица были разбиты на треугольники (триангулированы) по ключевым точкам, цвет пикселей внутри полученных треугольников для всех лиц в выборке был усреднен. Код проекта был написан на языках C++ с использованием фреймворков dlib/opencv.
По словам автора проекта, Андрея Сорокина, самой серьезной проблемой было большое потребление памяти (более 4 Гб), необходимой для слияния сотен изображений. Задача также была осложнена низким исходным качеством фото и различными ракурсами моделей. Проблемы были решены — объём потребляемой памяти не превышает 100 Мб.
На втором этапе исследования инженеры DataArt попытались выяснить, накладывает ли свою печать на внешность разработчика выбор той или иной технологии — происходит ли настоящая профессиональная деформация?
Для того, чтобы портрет «типичного» программиста получился с характером, сохранилось больше характерных черт при минимуме объединяемых портретов, для каждой группы был применён спектральный анализ векторов, соответствующих определенным чертам лица.
Эксперимент показал, что некоторые различия есть: например, разработчики на Java более улыбчивые, а у специалистов .Net хуже зрение —они часто носят очки.
Слева — усредненный портрет разработчика Java, справа — разработчика .Net
�� Подобається Сподобалось 0
До обраного В обраному 0
Четыре типажа программистов
Я впервые пишу в поток об управлении и найме персонала. Речь пойдет об одном из способов классифицировать ваших будущих или действующих программистов. Мой основной тезис: все разработчики, грубо говоря, делятся на 4 больших типажа и каждому из этих типажей есть своя область применения. Попытка направить неправильный типаж на решение неподходящих для него задач ведет к провалу (неэффективная работа, или сотрудник покидает команду). Хотите знать почему так — добро пожаловать под кат. Приготовьтесь, текста много.
Некогда, забавы для и пользы ради, я подрабатывал в одном неплохом кадровом агентстве — собеседовал приходящих программистов на предмет знания C#/.NET. В мои обязанности не входило полное техническое интервью — скорее, начальный скрининг кандидатов чтобы понять who is who, отфильтровать совсем уж ужас и в случае чего дать советы что почитать и как усовершенствовать навыки. И был у того кадрового агентства один интересный клиент. Он у всех на слуху, но тогда мне про него мало что сказали — я только понял, что вроде как ищет он rock stars — высококвалифицированных разработчиков, при том независимо от используемых технологий. После того, как я порекомендовал для них несколько человек — со мной связалась заместитель ген. директора и пригласила на встречу, ибо мои рекомендации не совсем устраивали заказчика. Так я познакомился с учредителем. Там мне была рассказана очень интересная история о том, зачем им нужны rock stars и как это всё вместе работает. Оказалось что вовсе не rock stars нужны. Нужны, как дал мне понять руководитель — люди с крепкими фундаментальными знаниями (алгоритмы, проектирование, операционные системы, сетевые технологии), которые будут готовы к росту и развитию. И вот они их берут и развивают, а затем отправляют реализовывать довольно сложные аутсорс-проекты. Заодно мне рассказали какие проблемы в этом плане испытывает компания. Я ушел в раздумьях и довольно долго катал в голове эту бизнес-модель, равно как и мысли о российской IT-индустрии в целом и политике работы с кадровым составом в частности.
В конечном итоге, через несколько лет я, наконец, утряс всю имеющуюся у меня в голове информацию и уложил её в модель, которая согласуется с окружающей реальностью. Это дало ответ на вопрос почему кадровый пайплайн упомянутой выше компании идеологически не может работать, а заодно и много другой интересной побочной информации. Так родилась моя классификация разработчиков по типажам.
Важно понимать что нет «плохих» типажей. Если какой-то из типажей вам кажется плохим, то вы просто не умеете его готовить. Помним: каждой задаче — подходящий инструмент. Я расскажу про все 4 типажа в виде карточек, давая краткую характеристику, указывая бэкграунд, цели и мотивацию, а так же рассказывая про сильные и слабые стороны. Особенно стоит уделить внимание бэкграунду, так как в конкретный типаж люди вырастают из своего бэкграунда. Начнем мы с чего по-проще.
Линейный программист
Соль индустрии IT-шной. На таких людях, говорят, мир держится. Он же «хомячок». Он же «гребец на галере», но я предпочитаю избегать таких ярлыков, поэтому просто — «линейный программист». Он не хватает звезд с неба, не пишет своих компиляторов и СУБД. Ну максимум — сделает пару инструментов, чтобы облегчить себе жизнь, в остальном — просто решает рабочие задачи. Редко меняет место работы. Усидчив. К работе относится как к работе, без особого энтузиазма. В меру ленив. Дисциплинирован (но бывают исключения), однако без надлежащего управления быстро «расхлябывается» и теряет фокус. Управлять такими людьми можно по стандартным методикам — описанным например в книге Дж. Рейнвотера — Как пасти котов. Квалификация может варьироваться и определяется исключительно опытом и количеством проектов, в которых линейный программист принял участие. Иногда квалифицированные линейные программисты попадают на минимальные управленческие должности — их нарекают team lead и тут-то вышеуказанная книга им и пригождается. Но самая главная особенность линейного программиста — весьма частое отсутствие желания развиваться и экспериментировать. Он прекрасно решит даже очень нудную задачу, которую вы ему предложите, если та не будет слишком сложной. Он выберет как можно более быстрый и прямолинейный инструмент из тех, что знает. Развитие для этих людей носит спорадический характер и в основном идет «вширь»: изучить новый фреймворк или новый инструмент, который поможет лучше решать повседневные рабочие задачи. Или «пришел заказчик, который использует вот такую штуку — ну что уж, будем разбираться». Примечательно, что знания полученные в результате спорадического развития отдельных линейных программистов как раз и составляют опыт аутсорс-компании. Однако, двигать горы и исследовать окружающий мир «вглубь» самостоятельно линейного программиста чаще всего просто не тянет. Например изучать новый, хайповый язык программирования ему просто не интересно. Только если новый язык помогает в решении повседневных задач. И уж тем более разрабатывать свой язык — увольте. И это — нормально. Хуже всего то, что линейные программисты «каменеют» когда долго сидят на одном месте. То есть если у вас есть человек, который стабильно занимается концептуально одними и теми же проектами на протяжении 3-5 лет — то очень маловероятно, что он сменит типаж и будет развиваться «вглубь». Но вот раньше этого эмпирического срока — все возможно и зависит от бэкграунда.
Бэкграунд: разный. В «линейных программистах» могут оказаться и люди, прошедшие онлайн-курсы, и выпускники ВУЗов, некоторые олимпиадники, бывшие ученые технических направлений и даже люди из концептуально другой профессии (известны случаи когда дальнобойщики становились разработчиками на PHP). Важно понимать, что линейный программист — само по себе является бэкграундом и почвой для прыжка в другой типаж. Но! Прыгнет человек или нет — зависит прежде всего от его личных желаний, а не от навыков. Наличие того или иного бэкграунда определяет лишь направление потенциального прыжка, а не его вероятность! А вот вероятность прыжка с течением времени резко падает. Однако если вам нужен верный сотрудник на долгосрочный контракт — научитесь выявлять желающих «прыгнуть» заранее. Сбежит с проекта — будет неприятно.
Ценит: стабильность, среднюю, но 2-раза-в-месяц-стабильную зарплату, покой и личные отношения в коллективе, нормированный рабочий день, офисные плюшки вроде бильярдной, фруктов по выходным, оплаты проезда или тренажерного зала, мед. страховку и (возможно нудную, но) ненапряжную работу.
Сильные стороны: усидчивость, ответственность, коммуникабельность (раз на раз), полная контролируемость, спокойное поведение в стрессовых для проекта ситуациях
Слабые стороны: сложные и/или нестандартные задачи, абстракции, поведение в стрессовых для компании ситуациях, говнокод опять же
Собеседование: стоит уделить внимание психологии: усидчивость, дисциплинированность, коммуникативные навыки, стремления, вот это всё. Так же имеет смысл поговорить о предыдущем опыте и посмотреть в резюме. Дать стандартное тестовое задание а-ля «написать чат на web sockets», смотреть на сроки выполнения, «вылизанность» задачи и адекватность подобранных инструментов. Хорошо идут технические вопросы на знание языков, протоколов, паттернов и стандартных бибилотек. Плюсом будет если соискатель уже имеет опыт конкретно с вашим набором фреймворков, но если нет — не беда. Если все остальное в порядке — разберется. Это его работа.
Чего спрашивать не стоит: не спрашивайте почему люки круглые (вообще ни у кого это не спрашивайте), не просите его развернуть красно-черное дерево маркером на доске, дать оценку сложности алгоритма, произвести топологическую сортировку или спроектировать высоконагруженную систему. От этого линейному программисту нехорошо, хочется врезать вам по тыкве и убежать.
Rock star (Software Scientist)
Концентрированный исследователь. Такие больше похоже на классических ученых, но только от IT. Им интересны алгоритмы, теоретические исследования, концептуально новые направления в индустрии, но прежде всего — им интересно экспериментировать. Ради этих экспериментов их и нанимают, собственно. Они готовы часами копаться в сложных штуках и решать задачи, постановка которых другим людям даже не понятна. Они — эксперты в сложных вопросах. Они точно знают в каких случаях q-sort стоит заменить на heap sort и чем они отличаются, или может быть какие алгоритмы кластеризации подойдут для анализа потока биржевых котировок, а иные знают какие оптимизации используются внутри g++ и как они помогают жить. Костяк таких людей, например, способен разработать новый язык программирования и компилятор к нему. Или значительно улучшить какую-бы то ни было существующую систему. Еще они часто предрасположены к функциональному программированию. Ни на что не намекаю — просто статистическая закономерность. Кстати, говнокодить rock stars могут (особливо на стадии прототипирования идей), но в массе своей не допускают плохой код до финальных версий разрабатываемых ими вещей, стараются сделать все красиво, с комментариями и удобными программными интерфейсами.
Как всегда есть «но», которое все портит. Важно понимать что ни при каких условях эти люди не будут решать ваши задачи. То есть да — rock stars будут решать те задачи, которые интересны им. За ваши деньги. И при том — за большие деньги. И при том — не факт что будет какой-то результат. То, что ваши задачи совпали с задачами, которые интересны rock star — очень и очень большая удача и счастливое стечение обстоятельств, не более. Но если завтра rock star-у взбредет в голову контрибьютить в GHC вместо улучшения вашей сборки MySQL — то у вас будет ограниченное количество времени чтобы быстро и решительно его уволить. При попытке заставить оного вернуться к своим задачам — получите, в зависимости от темперамента и ваших soft skills, или конфликты или тихий провал сроков. Ну хорошо хорошо, чтобы людей так капитально разворачивало — это бывает редко и происходит постепенно, да. А вот обратная ситуация — если пересадить rock star с улучшения вашей сборки MySQL на улучшение GHC против его желания — бывает достаточно часто. И, как нетрудно заметить, приводит к аналогичным последствиям. И именно это обстоятельство делает rock star категорически неприемлемым для аутсорса.
Именно поэтому rock stars лучше всего чувствуют себя в продуктовых компаниях (например JetBrains), где им дают полную свободу в рамках одного продукта и полностью исключают внезапную смену скоупа задач (разве что только через увольнение). Люди получают возможность заниматься теми задачами, которые им интересны, самореализовываться, раскрываться и их при этом особо никто не дергает. Получается хорошая штука — окей, идет в релиз. Нет? Ну и черт с ним. В таких условиях rock stars пускают корни, живут весьма долго (до десятка лет) и им хорошо.
Со стороны менеджмента здесь требуется легкий и ненавязчивый контроль — так, чтобы rock star не разбредались и их не «заносило» в бесперспективные эксперименты. Ну и так же мягко доносить, что та или иная интересная ему разработка нерелевантна.
Есть другой замечательный пример работы с rock stars — это Google, в котором rock star-у дают возможность заниматься тем, что он хочет. Google их кормит, поит, одевает и защищает от внешних угроз. Взамен — все, что rock star наизобретает — будет принадлежать и продвигаться Google, превращаясь в его продукты. Fair enough. Эдакие посевные инвестиции в отдельно взятой компании.
Бэкграунд: лицей или другая хорошая школа, высшее образование в хорошем ВУЗе по IT-специальности или же математике. Круглый (хотя бы овальный) отличник. Вероятно, участие в серьезной научно-исследовательской деятельности (научные публикации как плюс) и/или олимпиадное программирование прямо со школы.
Ценит: покой (пока решает задачу), свободный ненормированный график с возможностью удаленной работы, адекватность менеджмента, возможность поработать с другими rock stars, сложные, интересные и нестандартные задачи, стабильное финансирование. Офисные плюшки или воспринимает как должное или игнорирует напрочь, но в целом не испытывает к ним особого пиетета.
Сильные стороны: сложные задачи, исследовательская деятельность, нередко проектирование.
Слабые стороны: зачастую наличествуют проблемы в коммуникации, отсутствует стрессоустойчивость, нестабильность в компании или проекте легко спугивает rock stars, жестко поставленные сроки превращаются в стресс, невозможность переключаться по предметным областям — только разве что по своему желанию. Не смотря на всю творческость, несамостоятелен за пределами своих задач.
Собеседование: алгоритмы и структуры данных, оценки сложности, олимпиадные задачи — ваши надежные друзья. Можно заставить разворачивать дерево на доске (но зачем?) — но гораздо лучше дать несложную математическую задачу. Главное не спешите и не торопите: дайте человеку подумать столько, сколько ему нужно. Творческие задачи, задачи на соображалку (ну только не про люки же!) и задачи на проектирование в формате «давайте порассуждаем» и «предложите решение» так же неплохи. В резюме смотрите на образование и публикации. Поспрашивайте про участие в олимпиадах, научно-практических конференциях, поинтересуйтесь темой дипломной работы. Если рассказывает с горящими глазами — вы нашли то, что нужно. Так же стоит удостовериться, что соискатель знает в совершенстве какой-нибудь язык программирования (любой), иначе не очень понятно как он будет реализовывать свои эксперименты.
Чего спрашивать не стоит: не задавайте глупых вопросов. К глупым вопросам относится: детали реализации чего-либо а-ля «а что делает HTTP-заголовок Content-Length?», вопросы про коммуникативные навыки и прочая психология (да, rock stars могут обладать абсолютно мерзким характером — но что поделаешь, такова плата за них), и уж тем более не заикайтесь и даже не думайте проверять стрессоустойчивость. Пунктуальность проверяйте только на уровне «не пропадает на неделю и ладно».
Делец (Software Engineer)
Редкий зверь в наших краях. Его иногда называют «ориентированный на результат», «любой каприз за ваши деньги». Эдакий линейный программист, который неожиданно (а на самом деле — предсказуемо) обзавелся самостоятельностью, самомотивацией и начавший расти туда, куда считает нужным. Это не rock star, потому что его не интересуют глубокие и абстрактные задачи. Его интересуют работающие инструменты, приносящие конкретную, ощутимую пользу, которую можно потрогать руками здесь и сейчас (зачастую — в виде хрустящих купюр в кармане, но об этом позже). Если работающего инструмента нет — делец делает его для себя сам. Очень любит конкретику в постановках задач, в технологиях и — что самое важное — в общении. Про таких еще говорят «строгий, но справедливый». Коммуникативные навыки хорошие. Политкорректен, дружелюбен, не тяжел, хотя бывает грубоват и склонен к занудным формальностям. Делец таков не от хорошей жизни, потому как грубиянов и молчунов суровая реальность дельца быстро ставит на место. Будешь грубить — угрохаешь репутацию. Будешь молчать — не получишь заказы. Не будешь избегать и разрешать конфликты, лезть на рожон — останешься без денег. Материалист. Работает с теми задачами, которые ставит для него объективная реальность. Если чего-то не понимает — спрашивает и добивается конкретного ответа. Его хлеб — тщательно подобранный или разработанный собственноручно инструментарий, опыт, умение разбираться во всякой гадости в приемлемые сроки и работа на скорость и на качество. Инструментарий подбирает сам или посоветовавшись с другими дельцами — и не дай вам б-же дать ему совет в этот момент. Ответственный. Хороший делец не срывает сроки и обеспечивает рабочий и поддерживаемый продукт. К говнокоду относится как к одному из инструментов. Может занять технического долга, если это уместно и полезно в конкретной ситуации, учитывая специфику проекта. Сведущ в менеджменте. Нередко понимает в нем больше, чем непосредственный начальник. На основании этого может рекомендовать ad-hoc управленческие решения. Из профессиональных изъянов стоит отметить невнимательность к мелочам, но и это у хороших дельцов лечится.
Крутое описание — не правда ли? В чем же подвох? Подвоха тут два. Первый заключается в том, что делец не терпит над собой никакого начальства, особенно если оно менее квалифицированно чем сам делец. Во многом это обусловлено той самой осведомленностью о способах менеджмента. Ну еще и тем, что делец сам прекрасно понимает как делаются деньги в IT-индустрии. Как следствие — делец не подчиняется приказам. Делец сотрудничает в рамках контрактов. Любая попытка заставить дельца делать что-либо за пределами контракта (если не формально подписанного — то хотя бы устно оговоренного) — ведет к вежливому отказу в лучшем случае или к расторжению контракта в худшем. Если делец не подписывался отсылать вам ежедневные отчеты — он этого делать не будет. Если не подписывался тратить на вас 8 часов в день (при наличии сроков сдачи задания) — то он этого делать не будет. Если не подписывался на правки по проекту — ну вы поняли. Однако если вы выкупаете оптом какое-то кол-во рабочего времени дельца (без конкретных сроков и конкретных задач), то он с радостью будет выслушивать ваши стенания, невнятные требования, поддакивать и участвовать в любой корпоративной шизе — ну а что? Уплочено же. Любой каприз за ваши деньги.
Второй подвох заключается в самом отношении дельца к деньгам. Делец не подвержен нематериальной мотивации. На ваши «компания будет оплачивать вам тренажерный зал, обеды и котиков по пятницам» скорее всего ответит «давайте лучше деньгами». А денег делец любит много. И не просто много, а очень много. Да, он лоялен к нестабильности выплат, к переработкам и к оплате за результат, однако эта оплата должна быть большая.
Долгосрочными контрактами на маленькие ежемесячные суммы его не заманишь. Только на большие — выкупайте рабочее время оптом, да. Как следствие — делец часто меняет место работы (в той мере, в которой для него существует это понятие). Засидишься — станешь линейным программистом. Как следствие — квалифицирован решать довольно широкий спектр задач. Помните — хороший делец всегда стоит своих денег. А если вы не дадите ему достаточно денег — делец попытается реквизировать рычаги управления. Разными способами — от наглого увода заказчика и команды (если у него есть такие полномочия), до честного разговора по душам. Если это не удастся — он вас быстро и решительно покинет, потому как а зачем? Хорошие дельцы заканчивают открытием собственных компаний, но, как было сказано выше, дельцов в нашей стране в принципе мало.
Бэкграунд: часто самоучка. Занимается программированием потому что интересно. Высшее образование наличествует, но стоит смотреть на репутацию учебного заведения. Если учебное заведение серьезное — то троечник. Ибо как работает с первого курса. Да и вообще изучению всяких наук предпочитает по-скорее добраться до реальной работы. Очень часто фрилансит. У некоторых дельцов проблемы с фундаментальными знаниями. Однако если это точно делец — то эти проблемы легко решаются.
Ценит: высокую оплату своих услуг (именно в такой формулировке), соблюдение договоренностей, качественные решения проблем. График и плюшки — по договоренности, но обычно предпочитает свободный график, не привязанный к месту работы с фиксированными целями, а плюшки — да выдайте лучше деньгами.
Сильные стороны: широкая и в меру глубокая квалификация, самостоятельность, ответственность, ориентированность на результат, толерантность к нестабильности в компании (пока соблюдаются его контракты), толерантность к недолгосрочным контрактам и внезапным их расторжениям (не нарушениям, а расторжениям я сказал!), слоновья стрессоустойчивость.
Слабые стороны: высокая стоимость (в 2 раза выше чем у линейных программистов и это только начало), могут и сами нарушать обязательства договора (это если делец плохой и ни на что не годный — или просто начинающий), неуправляемость в режиме «я начальник-ты дурак» (если не уплочено), краткосрочность планов, непунктуальность если иного не предусмотрено договором.
Собеседование: хорошего дельца найти трудно. Ваш друг — репутация. Посмотрите резюме, не поленитесь связаться с человеком, который сотрудничал с соискателем ранее. Если речь идет об удаленной работе — посмотрите что у соискателя с доступностью. Как быстро он отвечает на почту и сообщения, телефонные звонки. Если лично — насколько пунктуален по назначенным встречам. Дальше расспросите о знаниях требуемой технологии. Но только так — без фанатизма. Конечно неплохо если делец точно знает какой адрес в памяти у функции закрытия подключения в проприетарной библиотеке, которую вы используете — но поверьте, это не то, что следует спрашивать. Неплохо будет попросить примеры проектов, которые делец уже реализовал на вашем стеке/с использованием вашей технологии. У хорошего дельца всегда найдется что показать и рассказать. Задачи на проектирование и «как решить вот эту проблему с заданной технологией» идут на ура, особенно если приправлять проектными деталями (например решить задачу в условиях когда заказчик требует релиза каждую неделю и т.п.).
Чего спрашивать не стоит: алгоритмические вопросы, математика, задачки на внимательность и прочая чепуха, которую спрашивают у rock stars. Разве что только на уровне концепции. Ну то есть делец может в общих чертах знать что такое, скажем, бикубическая интерполяция, но не заставляйте его реализовывать её на бумаге или на компьютере без интернета — будете справедливо (но вежливо) посланы. Отдельным пунктом следует упомянуть тестовое задание. Не давайте стандартных тестовых заданий: хороший делец таких заданий за всю жизнь переделал столько, что вам и не снилось и еще одно ему вот вообще не нужно. Далее. Смиритесь с тем фактом, что тестовое задание — это трата рабочего времени дельца. Приготовьтесь к тому, что оно будет платным. Предложите заключить NDA, временный контракт и сделать, например, коммит с фиксом бага для какого-нибудь вашего продукта или какой-либо системы с условием оплаты по выполнению и оговоренными требованиями к качеству. Это — самый эффективный метод. Не забудьте рассказать как настроить окружение. У хорошего дельца это не займет много времени, но бывают казусы.
Пассажир (business bullshitter)
У этого типажа много «ласковых» названий в народе. Наименее квалифицированные коллеги ему подчиняются, более квалифицированные его не любят. Начальники таких обожают и дальше я объясню почему. Кратко: пассажир харизматичен. Всё. Много и красиво говорит, но катастрофически мало (или некачественно) делает. Повышенная коммуникабельность — его хлеб и зачастую пассажир попадает на менеджерские должности, так как не знает как сделать самому, но обладает достаточным ораторским талантом чтобы заставить работать кого-то вместо себя, и — более того — убедить начальника что именно он и должен руководить проектом. Во всем он демонстрирует серьезность, рвение и уверенность в себе, стремится порешать любую проблему, организовать совещание и обсудить, обязательно учитывая мнение команды. Со стороны может показаться что у него шило в известном месте. Он почти всегда на связи, всем отвечает на письма, показательно вежлив ( так, что врезать порой хочется извините вырвалось) и может найти подход хоть к самому дьяволу. Один только минус — техническая квалификация. По правде говоря, ему не очень нравится программирование (вплоть до отвращения), но очень нравится покомандовать. Поэтому слабую техническую квалификацию (или её полное отсутствие) он часто «замазывает» красивыми словами, показным участием, заинтересованностью, дружелюбием и коммуникабельностью. Одна из самых страшных ошибок — ставить таких людей на средние менеджерские должности в командах. Как только вы это сделали — всё. Вы больше не получите достоверных данных о том, что происходит внутри команды с технической точки зрения. У вас будет красиво представленный бриф по происодящему, но те места, которые пассажир не понимает на техническом уровне будут из него исключены. А это в 90% случаев — скрытые проблемы и разнообразные детонаторы.
Тем не менее, грамотно подобранный пассажир может помочь команде общаться с заказчиком. Например, для пассажира ничего не стоит убедить заказчика перенести дату релиза — и при этом последний еще и будет думать что это наилучшее решение. Использовать пассажиров в роли дипломатов для заказчиков — одно удовольствие. Однако помните: харизматичные пассажиры — это как токсичный анестетик широкого спектра действия. Имеет смысл периодически опрыскивать им заказчиков, однако утечка бочки анестетика внутри команды приводит к весьма плачевным последствиям.
Бэкграунд: «лидер класса», «альфа-самец» в университете (жалко что не проверишь никак). Мистер обаяние. Образование может быть разным. Однако имейте в виду, что оценки могли получаться так же через ораторский навык. Программированием мог начать заниматься потому что интересно, но с таким обаянием у него были вещи в жизни и по-важнее. Нередко имеет свой персональный web-сайт на отдельном домене. Сделал его сам.
Ценит: все то же, что и линейный программист минус работа, плюс возможность поруководить.
Сильные стороны: коммуникабельность, способность убеждать, способность доносить информацию красочно, с шутками-прибаутками, про стрессоустойчивость лучше спрашивать отдельно
Слабые стороны: техническая квалификация. Многие технические вещи способен понимать лишь тезисно. Активен, но быстро теряет интерес и концентрацию на сложных и средних технических задачах. А в худшем случае — и вообще на любых задачах.
Собеседование: определитесь с тем нужен вам пассажир или нет. Если нет — при повышенной общительности и дружелюбности соискателя — держать ухо востро. Настоящие специалисты ведут себя спокойно. Старайтесь отсеивать красивые слова, общие утверждения, а выделять суть сказанного. Поинтересуйтесь достижениями в техническом плане. Попросите показать свой домашний проект, объяснить как он работает. Хорошо помогают те же вопросы что и для линейных программистов. Следите за тем, чтобы там, где соискатель не знает — честно говорил «не знаю», а не пускался в пространные рассуждения. Ну и тестовое задание как всегда. Если к тестовому заданию будет объемное пояснение, в коде — не продраться от комментариев и соискатель рвется объяснить как он это сделал — перед вами пассажир. Ежели пассажир вам все-таки нужен, то поинтересуйтесь как бы он объяснил заказчику срыв сроков релиза. Так же душевный разговор на предмет знания методик управления — SCRUM, PMBOK и разбор управленческих кейсов — могут возыметь положительный эффект. Но это уже история не про программирование.
Чего спрашивать не стоит: в случае с пассажиром — запретных тем нет (в рамках приличия). Если возникли подозрения на то, что перед вами пассажир — попробуйте вот что: задайте какой-нибудь вопрос, на который технический соискатель бы отказался отвечать по причине нерелевантности. Поговорите… Ну я даже не знаю. Про то, какую музыку любит соискатель, или фильмы, или игры. Или куда он ездил путешествовать. Если перед вами пассажир — то будет длинный рассказ. Если вы ошибаетесь — то вам ответят кратко и тезисно.
Выводы
Отдельной строкой стоит заметить, что четкой границы между этими типажами нет. Человек вполне может находиться где-то между дельцом и rock star, или rock star может дрейфовать в сторону пассажира. А прямо сейчас какой-нибудь линейный программист может перепрыгивать в дельца, увольняясь с уютной галеры и заводя аккаунт на UpWork. Поздравим же его с этим! Однако концептуально я склонен считать, что стабильно и в долгосрочной перспективе любой программист плотно обосновывается в одном из этих четырех типажей.
Возвращаясь к описанной первоначально ситуации. Если вы набираете и растите потенциальных rock stars, то использовать их на аутсорсных проектах — это как забивать микроскопом гвозди. Если же вы выращиваете дельцов — будьте готовы делиться деньгами и полномочиями. А для решения задач аутсорса вполне подходят крепкие линейные программисты. Если это сложный аутсорс — то с добавлением одного rock star или дельца в команду на «птичьих правах». В противном случае, если вы культивируете rock stars в своей компании, но у вас аутсорс — то смиритесь с тем, что единственный возможный способ на этом заработать — забирать себе промежуточные артефакты их работы. После того, как они вырастают — их надо отпускать. При том отпускание должно быть встроенно в саму бизнес-модель и кадровый пайплайн компании. Так вижу.
Именно это я бы и хотел объяснить учредителю компании из начала статьи. Но сейчас для него, боюсь, эти знания уже нерелевантны.
Спасибо за внимание! Хороших вам кадров!
Создан портрет типичного ИТ-шника. Чем отличаются программисты на Java и .NET? Фото
Путем обобщения фотографий 2 тыс. программистов, компания DataArt создала портрет среднестатистического представителя этой профессии. Как оказалось, типичный айтишник не носит очки и не имеет растительности на лице.
Портрет типичного программиста
Консультационная компания DataArt показала, как выглядят среднестатистические программисты мужского и женского пола. Для этого сквозь специальной компьютерной алгоритм были пропущены фотографии 2 тыс. айтишников из восьми стран мира: Аргентины, Болгарии, Великобритании, Германии, Польши, США, Украины и России. Проанализировав их, алгоритм определил усредненные черты типичного разработчика.
Мужской портрет был составлен на основе анализа фотографии 1541 мужчины, женский — 512 женщин. Среднестатистический мужчина-айтишник получился светлокожим, круглолицым, с обычной короткой стрижкой. Очки, усы, борода, татуировки и пирсинг на лице на усредненном фото отсутствуют. Типичная женщина-программист так же имеет округлое белокожее лицо, она более улыбчива, чем ее коллега мужчина.
Определившись с портретом типичного айтишника вообще, специалисты DataArt решили выяснить, как выглядят разработчики, специализирующиеся на конкретных направлениях в программировании. Среднестатистический разработчик Java получился очень улыбчивым человеком, а типичный специалист по .NET на обобщенном фото носит довольно отчетливо заметные очки.
Технические особенности
Алгоритм для обобщения лиц был написан на C++ с применением фреймворков dlib и opencv. Работа с чертами лица проводилось по методике разработчика Сатьи Маллика (Satya Mallick). На каждом лице были выделены 68 ключевых точек, в число которых попали уголки глаз, бровей и губ, крылья носа и прочие. После этого алгоритм провел триангуляцию лиц, то есть разделил их на треугольные фрагменты в соответствии с ключевыми точками. Обобщение тона кожи и других цветов лица проводилось отдельно в каждом треугольнике.
Так выглядят среднестатистические программисты мужского и женского пола
Как поясняет автор проекта Андрей Сорокин, разработчикам пришлось решить вопрос с чрезмерным потреблением памяти в процессе обобщения изображений. Изначально оно превышало 4 ГБ, этот показатель удалось сократить до 100 МБ. Кроме того, анализ был затруднен плохим качеством некоторых фотографий и несовпадением ракурсов на них. Различие между портретами специалистов по Java, .NET и другим направлениям разработки удалось выявить с помощью спектрального анализа векторов, проведенных по различным чертам лица.
Средняя зарплата айтишника
Ранее CNews писал, какие зарплаты в среднем получают айтишники. Например, директор по ИТ в Москве и Московской области может получать до 600 тыс. руб. в месяц — если он имеет более 4 лет опыта работы, и трудоустроен в компании, где численность штата превышает 1000 человек. Для компаний численностью от 200 до 1000 человек зарплата ИТ-директора составляет порядка 250-350 тыс. руб.
Разработчики Java склонны чаще улыбаться
Системный администратор с опытом работы от четырех лет получает от 80 до 120 тыс. руб., если он работает в компании, штат которой насчитывает менее 200 человек. В компаниях с численностью сотрудников от 200 до 1000 человек системный администратор с таким же опытом получает 120-160 тыс. руб.
Разработчик с опытом работы более 4 лет в компаниях с численностью персонала до 200 человек получает 100-140 тыс. руб., в компаниях с количеством сотрудников от 200 до 1000 человек — 120-170 тыс. руб., а в компаниях со штатом свыше 1000 человек его зарплата составляет от 120 до 180 тыс. руб.
Так выглядят типичные разработчики .NET
В отечественной ИТ-отрасли не распространено трудоустройство по контракту — большинство специалистов предпочитает ставку, даже если она рассчитывается исходя из более низких расценок. Относительной популярностью контракты пользуются только в среде разработчиков. В 2017 г. трендовыми направлениями в найме айтишников были большие данные, распознавание голоса и развитие искусственного интеллекта. В 2018 г. отрасли понадобится руководители проектов, имеющие навыки развития продуктов, а также специалисты в сфере финтеха.
Сергей Тихомиров, CUSTIS: Банки могут составить реальную конкуренцию ИТ-компаниям в создании конечных цифровых продуктов для других отраслей
Цифровизация
