Комментарии 320
«Что конкретно вы хотите обо мне узнать?» — обычно отвечаю я и наблюдаю разочарование в глазах босса

Извините за откровенность, но какая-то инфантильная реакция со стороны автора.
Что мешало заранее (ведь вы идёте на собеседование) подготовить краткий спич на тему "Расскажите о себе"? Ничего не мешало.
Это нормально. И продумать свой ответ на этот вопрос заранее – это нормальная практика взрослых людей.


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


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

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


Оценивать уточняющие вопросы как инфантильность тоже не сильно вам помогает в поиске реально мыслящих людей. С моей стороны инфантильно выглядит спихивание вины.

задача программиста — программировать, а не кратко-спичить

Это простая и понятная мысль. И логичная.
Но не хочется брать к себе человека, который на вопрос "Вась, как ты вот это делал?" будет каждый раз ворчать "Я программист! Я не обязан объяснять, я могу сделать и всё!"
А именно такой потенциал я вижу в вас, как в моём потенциальном коллеге. Оно нам надо?
Я не HR, а очень даже рядовой Если КонецЕсли.

На такой вопрос я бы ответил уточнением (что конкретно непонятно? а что ты уже понял?), а не отказом, но дискуссия то не обо мне. И было бы здорово если бы дискуссия осталась в плоскости идей, не переходя на личности.


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


Вместо вопроса "кто виноват?", вопроса, который мгновенно схлопывает проблему до объяснения и ставит в тупик, я предлагаю задуматься над вопросом "что делать?".

Изменить отношение к собеседованиям.
Это неизбежно, что там надо рассказать о себе и хоть что-то озвучить. Работодатель не может брать на работу ходячий компилятор. Работодатель ищет человека.

Работодатель не может брать на работу ходячий компилятор. Работодатель ищет человека
В смысле «человека»? Человечища что-ли, глыбу как Л.Н.Толстого?

Работодатель не ищет человека или компилятор. Он ищет способ решить свою проблему.

Да, но это человек ему поможет решить проблему, а не компилятор.

Задача развлекать начальство во время похода в баню и задача писать код — немного разные задачи.
Это бы сказал, не побоясь данного слова, что это две большие разницы.


Оценивать навыки второго по первому…

что конкретно непонятно?

Не надо так.
У меня тут был проект, в котором было совершенно у***щное ТЗ.
Я пришел к менеджеру с уведомлением, что я не понимаю это ТЗ.
И она задала этот самый вопрос:
«что конкретно непонятно? скажи, я спрошу у заказчика.»
А я не могу на это ответить. Потому что всё ТЗ говно. Я не могу сформулировать вопрос вида «Вот здесь не понятно и вот здесь не понятно», за короткий промежуток времени.

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

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

Если человеку не понятно что-то конкретное — он придет с конкретным вопросом. Если он с ним не пришел — спрашивать чего ему конкретно не понятно — бред.
Задача формирования ТЗ — это отдельная важная задача и на начало проекта ТЗ должно быть в адекватном виде. Как вообще можно брать проект в работу с неформализованным ТЗ?

Те кто собеседует — тоже люди, и они не могут только сухие тех данные спрашивать. Более того не у всех их есть четкий план собеседования и поэтому берутся стандартные вопросы "о себе". Если говорить про hr, то там вообще каша, только что секретаря смотрели, а сейчас программиста.


Одни не умеют грамотно презентоваться, другие — грамотно собеседовать. Но каждый найдет что-нибудь.


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

1) Задача найти подходящего. Необходимо разработать батарею профессионально-психологических тестов аналогичных тем, что предлагают абитуриентам военных училищ. В них (тестах) измеряется способность работать в команде, способность к концентрации, память, изучается особенности принятия решений и логическое мышление конкретного индивида и т.п. Тесты основаны на объективных метриках и не зависят от предпочтений руководителя отдела кадров и технического директора конторы.
2) а) Для задачи найти лучшего — устраиваем хакатон, если позиция требует уникальных навыков и оригинальных технологических решений или б) на рядовую позицию — просто экзамен, где в качестве заданий — уже решённые в данной компании бизнес-проблемы и вопросы на нетривиальную логику, чтобы отсечь гугл-программистов (не бывших сотрудников гугла, а злоупотребляющих поиском)

Может, тогда достаточно попросить рассказать о решении задачи (с прошлого проекта, с интервью, с тестового, с гитхаба кандидата)?


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


Что вообще на такое отвечать? Какой спич у вас заготовлен?

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


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

Что тебя мотивирует

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


какие нетехнические интересы

Их, считайте, нет.


Ты робот жгучий свое зрение и на работе и после за компом пока не выгоришь?

Почти, да. Ещё за книжками и тетрадками, но это тоже технические интересы.


Образ жизни полностью сидячий или вполне активный?

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


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

А какой вывод должен сделать интервьювер на базе вышесказанного?

>программировать, а не кратко-спичить.
Да-да. У меня был коллега DBA, который как-то приходит утром, и говорит: чуваки, а давайте нашу БД разделим на две? А потом мы вдвоем пытались из него часа четыре вытянуть, а какой же профит он хотет получить от разделения? Так и не смогли…

Что характерно — этот профит на самом деле существует и вполне выражается в двух-трех предложениях, а дальше уже можно обсуждать, сравнивать преимущества и недостатки, и т.п.

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

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


Забавно что вы сформулировали результат "так и не смогли" вместо "он так и не смог".

Ну я сознательно преувеличиваю в другую сторону, чтобы было понятнее. Если вы хотите софт-скилл, то его все-таки как-то надо проверять. И когда вы же говорите, что не сможете рассказать, как нормализовать базу — у меня возникает вопрос, а сможет ли такой человек на позиции синьора объяснить джуну, хотя бы не «как», но «зачем» нужно нормализовать вот в этом месте, и нужно ли вообще?

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

>Забавно что вы сформулировали результат «так и не смогли» вместо «он так и не смог».
Э… ну на самом деле, цель была в какой-то степени прокачать его софт скилл, потому что мы-то для себя поняли профит предложения. И пытались лишь добиться, чтобы коллега его сформулировал словами. Мы не достигли своей цели, а он не смог сформулировать.
Если вы хотите софт-скилл, то его все-таки как-то надо проверять.

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


у меня возникает вопрос, а сможет ли такой человек на позиции синьора объяснить джуну, хотя бы не «как», но «зачем» нужно нормализовать вот в этом месте, и нужно ли вообще?

В наших головах разные ожидания от синьора. Я не ожидаю от синьора просветительской деятельности, такие ожидания у меня есть к тимлиду, задача которого по сути — "родить одного ребенка" силами нескольких программистов за два месяца. Вот с него требовать высоких коммуникативных навыков — естественно. Синьор же вместо того чтобы тратить своё время на разжёвывание очевидных для него вещей другому человеку пойдет и сделает это сам, а если у него нет на это времени или желания — поставит задачу джуну (или отклонит его пулл-реквест с минимальным комментарием) и пускай джун сам пытается понять что и почему не понравилось синьору, проводит исследование, раскачивает собственное мышление. И дело тут не в коммуникативных навыках синьора, они у него могут быть любой величины, а дело в том чтобы не формировать у джунов зависимость от авторитета, из-за которой они меньше думают своей головой, больше полагаясь на "ну этот умный парень мне сейчас поможет". "Умный парень" в такой ситуации слишком часто отвлекается на просветительскую деятельность, которая у него прокачана не так сильно как скилл программирования, в результате его общая производительность падает.
Кратко:
— обучать программированию != программировать
— есть вариант не экономить на курсах повышения квалификации для джунов, на которых заточенные на обучение люди будут их прокачивать
— еще есть вариант уволить джуна, неспособного самостоятельно "догнать" те области знаний и навыков, которые требуются


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

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

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


А первую статью, книжку, разговор или ролик нам передал бог или инопланетяне!

То есть достаточное количество разговоров и книжек всё же может заменить реальный опыт?

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

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

Мне начинает казаться, что вы троллите.
Садишься, включаешь мозг, ищешь зависимости, формулируешь их словами. Чуть погодя уточняешь формулировки. То же программирование по сути, только язык человеческий.

А можно не готовить спичи. Просто научиться импровизировать, перехватывать инициативу, уметь отстаивать и вести свою линию в переговорах. Это не сложно, на самом деле :) но такие навыки очень вручают по жизни, а не только на собеседованиях. Рекомендую.

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


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

Что мешало заранее (ведь вы идёте на собеседование) подготовить краткий спич на тему «Расскажите о себе»? Ничего не мешало.

Какой вопрос — такой ответ.
Я о себе могу рассказывать, например, долго — все-таки 40 лет пожил.
Могу в два слова — «я офигенен».
Если контекст не задан — вопрос возвращается вопрошающему: конкретизируй, что ты хочешь узнать.

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

Я думаю, у вас на интервью должно быть предположение о том, что именно интересно о вас знать. Так что вполне можно как-то более конкретнее, нет?


часового или даже двухчасового интервью.

Интервью это не монолог. Спросивший вполне может направить беседу в интересующее его русло.

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

А с низкими софт-скиллами ещё и не заметишь что говоришь не то, что ожидают, а потом вынесут вердикт "робот, а нам нужен человек" или "рассказал о семье, о хобби, но нафигам нам это — балабол"

Эти ваши выводы на каких фактах основаны?

А с низкими софт-скиллами ещё и не заметишь что говоришь не то, что ожидают, а потом вынесут вердикт «робот, а нам нужен человек» или «рассказал о семье, о хобби, но нафигам нам это — балабол»
При чем тут какие-то софт скиллы? Если вы пришли приниматься на работу, то логично говорить о работе/работах, а не о своей даче. Если захотят послушать про дачу — спросят и переспросят.
Я думаю, у вас на интервью должно быть предположение о том, что именно интересно о вас знать.

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

Интервью это не монолог.

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

Адекватному интервюэру не надо докапываться до чего-то ему нужно понять с кем он беседует и стоит ли его принимать на работу. Специально валить кого-то никому не надо. А если надо, то он вам не нужен, наверное?


А перебивать — невежливо

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

Специально валить кого-то никому не надо. А если надо, то он вам не нужен, наверное?

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

Ну это по ситуации — можно перебить вежливо да так, что перебиваемому понравится.

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

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

А перебивать — невежливо

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

Детский сад и демагогия.
Собеседование на определённую должность – достаточный уровень конкретизации.

Детский сад и демагогия.
Собеседование на определённую должность – достаточный уровень конкретизации.

Абсолютно нет. В рамках собеседования на определенную должность — все написано в резюме, и вопрос «расскажите о себе» — избыточен. И говорит о том, что интервьюер не утрудился с оным ознакомиться.
А правильные вопросы вот:

— «расскажите о том, что вы считаете своим самым выдающимся достижением на позиции Z?»
— «у вас был интересный опыт в компании Х в году Y — можете рассказать подробнее?»
— «почему вы ушли из компании W? Она достаточно крупный работодатель, туда все стремятся.»
— «в каких прикладных областях вам довелось работать?»

И так далее. Это все про рассказать о себе, но в конкретном аспекте.
Кстати, большинство тех, кто просил рассказать о себе — тратили не более нескольких секунд на конкретизацию, никто пафосно не фыркал про детский сад.
Вы первый. Поздравляю с ачивочкой (:
все написано в резюме

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

Но мы же говорим про первый этап общения с кожаным мешком со стороны зарплатодателя. И «расскажите о себе» без конкретизации — для меня это флажок, что ему пофиг. Примерно такой же флажок, как инвайт на batch interview.
И на эту хитрую ж. уже давно нашлись методы — теперь резюме представляют собой смесь рекламы и мощного SEO в одном флаконе. А иначе через роботов пробиться шансов вообще нет. Не мы начали эту войну!
Проводил сотни интервью.

ОБЫЧНО, в резюме более чем достаточно, чтобы не спрашивать «расскажите о себе», а задавать более конкретные вопросы по тому же самому резюме.

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

P.S. Если в резюме недостаточно — это уже говорит о качестве резюме.
ОБЫЧНО, в резюме более чем достаточно, чтобы не спрашивать «расскажите о себе», а задавать более конкретные вопросы по тому же самому резюме.

Это если вы в ответе на вопрос "расскажите о себе" ожидает услышать краткий (или развернутый) пересказ резюме. А если, например, вам интересно как человек будет реагировать на такой вопрос: уточнять его, пересказывать резюме, рассказывать о том, что в резюме не упомянуто или начнёт в форме близкой к истерике требовать "точного ТЗ"

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

Рассказы о себе — неинтересны большинству собеседующих, их на самом деле интересует зачастую конкретный ответ на общий вопрос.

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

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

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

Когда проводил собесы без "лишних глаз", то просто проходил по списку стэка и спрашивал "Чтоб сэкономить нам время просто скажите, вот что вы не знаете по PHP/MySQL/Docker?". Что назвали уже вообще не лез. Что не назвали — пару-тройку "контрольных", в которых сам плаваю обычно или сильно трудно далось.

Почему так все привязались к «Расскажите о себе»? Понятно, что фраза взята от HR-ов, пришедших с краткосрочных курсов. Нормальное уточнение от программиста: «Вы имеете в виду проекты, над которыми я работал, или Вас интересует моя жизнь вне работы?». Собственно, по ответу на этот вопрос уже можно понять, кто перед вами сидит, и делать свои заключения. Не каждый HR рискнет выбрать второй вариант.
Я, помнится, однажды незлобно пошутил над таким вот продуктом двухнедельных курсов по подбору персонала, каждый раз уточняя, на что именно она хотела услышать ответ. Окончание 10-минутного цикла было таким:
— Вы имеете в виду, нравится ли мне ездить на мотоцикле в жару?
— Да, именно это меня интересует.
— Нет, не нравится.
На второй круг девочка пойти не решилась, предложила чай и ушла, а я, в честно заслуженном одиночестве, спокойно дождался технарей.
Работать там я все равно не собирался, пройдясь по офису — шумно и добираться неудобно, терять было нечего, поэтому сделал мир чуть-чуть лучше, раз уж все равно пришел
В Северной Америке «расскажите о себе» означает короткий питч на 3-5 минут: кто я такой, специализация (яростно пишу нейросетки, например), образование, самые крутые проекты с результатами, чего хочу от новой работы. Все очень кратко.

Это да, я свой спич заранее написал на аглицком для компании из Штатов, на пол-листа А4, и выучил назубок. Писал пол-дня, наверное. Но я тогда шел на менеджерскую позицию, программером я бы не заморачивался

Почему так все привязались к «Расскажите о себе»?

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

Можете сколько угодно трясти своей ачивкой с той стороны двери. Такие проблемные кандидаты с компостером в голове работодателю не нужны.
Следующий!

Такие проблемные кандидаты с компостером в голове работодателю не нужны.

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

Что ставит под сомнение ваш постулат о проблемности. Вы, кстати, его и аргументировать не потрудились, съехали на эмоциях. Что для нанимающего очень непрофессионально (:

Я не HR, я погромист.
Но я первым бы сказал менеджеру, что такого кандидата-демагога, который устраивает дискуссию вокруг стандартной фразы "Расскажите о себе", нам в коллектив не надо, пусть других посмотрит.

Я там выше все написал почему рассказать о себе — это абстрактный запрос. Мы пошли по второму кругу.

Да-да, вы правы. Но вас по-прежнему плохо слышно с той стороны проходной.

Я не хожу на собеседования в места, где есть проходная (: к счастью.

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

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


Это только доказывает, что выросшие из разработчиков руководители, не умеющие в софт скиллы, могут быть еще хуже в управлении персоналом, чем HR-менеджеры.

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

Отсутствие софт-скиллов и обычной адекватности демонстрирует кандидат, устраивающий демагогическую лекцию в ответ на стандартный вопрос собеседования.

Это понятно.
Хороший технарь, умеющий в софт скиллы — это слишком фантастичная и дорогая вещь, чтобы ее ожидать в массовом применении.
А как мы дошли до того что умение ответить на вопрос «расскажите о себе» стало «умение в софт скиллы»?

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

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

Самопрезентация — один из из софт-скиллов. Особенно понимание какая форма и содержание самопрезентации должны быть в той или иной ситуации, плюс снятие невербальной обратной связи со слушателей и корректировка на лету.

То есть вы буквально требуете ораторских качеств от кандидата?
Как все плохо

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

Как бы не получилось так что ему все-таки это не интересно)) или интерес пропадет после пары месяцев.

Поэтому открытый вопрос, а не "интересно ли тебе зависимости обновлять" )

Самопрезентация — один из из софт-скиллов.

При этом наличие данного скилла ничего говорит о наличии других софт-скиллов. Как и наоборот.

А как мы дошли до того что умение ответить на вопрос «расскажите о себе» стало «умение в софт скиллы»?


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

Да даже о коде другому программисту, уровня знаний которого ты не знаешь.

Простите, но как по мне это уже какой-то сюр.

Прийти на работу в чистой одежде и чтобы не воняло это тоже отдельный скилл? Может нужны курсы «повышения гигиены»? И этот скилл действительно не нужен программисту в вакууме. И некоторые без него обходятся. Только это нифига не норма.

В какой момент мы программисту в качестве базовой линии начали считать какого-то инвалида неспособного ни на что кроме кода?

Когда начали утверждать, что софт-скиллы ему не нужны. По крайней мере в объёме большем чем требуется, чтобы общей гражданской дееспособности не лишиться.

Тихо, тихо, ну что вы пугаете ребят?
Они сейчас ложку уронят и соплями всё измажут.
– Сиди, Васечка, программируй, не плачь. Дядя плохой, дядя грубый! Дядя хочет, чтобы мы с людьми разговаривали, изверг!

Прийти на работу в чистой одежде и чтобы не воняло это тоже отдельный скилл? Может нужны курсы «повышения гигиены»? И этот скилл действительно не нужен программисту в вакууме. И некоторые без него обходятся. Только это нифига не норма.

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

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

Простите, но если человек воняет, и ему об этом говорят несколько раз, говорят не только коллеги, но и руководство, а он ну вот ему лень мыться, то причем тут социальная игра?

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

И какие проблемы в том, чтобы выпереть нескольких людей ради удобства большинства? Это нормально.

С вонью всё понятно, она другим людям мешает (хотя я по ровно той же причине не люблю, когда люди за рабочим столом едят, но об этом на интервью вроде не спрашивают, хотя на прошлой работе мне приходилось устраивать себе 15-минутные перерывы с прогулками по зданию, когда коллега начинала есть такие чёрные пластинки из водорослей, потому что конкретно этот запах для меня почему-то был невыносим). А протёртая ли у меня одежда, хожу ли я в пиджаке или в футболке с митол-принтом, и есть ли на этой футболке пара маленьких дырочек от ремня с заклёпками — какая разница, если я не общаюсь с условными клиентами?

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

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

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

а) ответы на первое и второе УЖЕ есть в резюме
б) конкретно процитированных вами запросов в исходной формулировке (расскажите о себе) не звучало.

зачем я буду додумывать за собеседника и отвечать на то, что не проговорено? (:

И в ваших интересах дать ту информацию, о которой вы готовы поговорить дальше.

Нет. В моих интересах получить необходимый минимум, чтобы принять решение — хочу я проходить собеседование дальше, или отказать.
Обычно до очного собеседования есть созвоны с HR с которым можно выяснить много вопросов (а если он не знает — спросит у нанимающего менеджера), чтобы принять решение, стоит ли продолжать. Не знаю случаев, чтобы кандидат просто вставал и уходил в закат. Это дичь какая-то.

А когда через 15 минут из запланированного часа тебе говорят "мы вам перезвоним" — это не дичь? Зачем тратить своё и чужое время, если почти сразу понимаешь, что оффер не примешь?

Обычно до очного собеседования есть созвоны с HR с которым можно выяснить много вопросов

Да, но нет. HR — очень хреновый в плане качества источник сведений. В большинстве случаев он может только переозвучить то, что известно публично, плюс — высказать субъективное мнение.

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

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

Что мешало заранее (ведь вы идёте на собеседование) подготовить краткий спич на тему "Расскажите о себе"? Ничего не мешало.

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

А одеться красивее на свидание это прямой обман потенциального романтического партнера?

А если работодатель перед собеседованием тебе говорит «рекомендуем подготовиться, вот ресурсы». Это что — двойной обман? Обман обмана? Обман в квадрате?

Можно ещё откровений?

Вы объясните тогда — чем подготовка к собеседованию отличается от прохождения собеседования другим человеком? Почему одно обман, а другое — нет?

С точки зрения фнукционального программиста обман — каждое новое состояние — это другой человек. А с точки зрения объектно-ориентированного — не обман. У человека есть идентичность и состояние. :)


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

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

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


Ну привели бы пример тогда с косметикой. Обман или нет? А фотошоп?
А одеться красивее на свидание это прямой обман потенциального романтического партнера?

Имхо, но больше да чем нет. Как по мне люди не должны стараться показать себя лучше/иными чем есть. Ведь им потом жить/работать вместе, и с реальным человеком, а не с образом на свидании/собеседовании.
А если работодатель перед собеседованием тебе говорит «рекомендуем подготовиться, вот ресурсы». Это что — двойной обман? Обман обмана? Обман в квадрате?

Да, когда мне из гугла перед собеседованием прислали брошюрку «вот рекомендуемые материалы для подготовки к собеседованию», я отчётливо почувствовал, что что-то не то.


Это как если бы мне перед экзаменом дали список из 10 задач и сказали, что на экзамене будет пять из них.

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


Если это на самом деле нужно в последующей работе.

А почему собственно это плохо. Возможно их интересует ваша способность подготовиться?

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

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

Я не знаю, что там были за задания, но конкретно у меня такие соображения.


В любом случае вряд ли будет 100% попадание в опыт. Грубо говоря, когда вы туда придете там будет куча технологий, которых снаружи просто нет и вам все равно придется чему-то учиться.


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


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

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

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


А Петя вообще не по алгоритмам — у него нет фундаметальных знаний и ему надо университетский курс преподать.

Так если они в работе нужны, а Петя в них не шарит, то, может, ну, он вообще не подходит?


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

А зачем её уменьшать?


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

Так, может, просто на собеседовании дать стихотворение какого-нибудь неизвестного поэта, а через 40 минут его попросить рассказать по памяти? Толку будет ИМХО столько же.


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


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

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


А, кстати о синтаксисе! Стоит ли перед интервью рассылать список вопросов по языку? Ну, типа, если вы идёте на C++-программиста, то вам рассылают там десяток тем, типа, зачем нужен виртуальный деструктор, или как пользоваться std::condition_variable, все дела, вы его дома освежаете, готовитесь, и приходите на собеседование весь такой знаток C++. И Петя, который никогда эти плюсы в жизни не видел, тоже нагугливает, зачем же нужен виртуальный деструктор, радостно вам оттарабанивает, и все счастливы.

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

Да, поэтому интересно насколько большая эта разница.


Так если они в работе нужны, а Петя в них не шарит, то, может, ну, он вообще не подходит?

Да, именно чтобы его отбраковать так и надо делать.


А зачем её уменьшать?

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


Так, может, просто на собеседовании дать стихотворение какого-нибудь неизвестного поэта, а через 40 минут его попросить рассказать по памяти?

Это не про память а про способность понять.


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

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

Подготовка к собеседованию — прямой обман работодателя
Тогда вся жизнь — обман? </грусть>
То есть вы думаете, что работодатель не готовится к собеседованию? Ну, если хотите поставить себя в заведомо проигрышное положение — вам виднее.

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

Не каждое получение знаний — обман. Но некоторые — обман, например получение знаний со шпаргалки на экзамене. :)

«Вы не подходите, мы вас перезвоним».

Зачем перезванивать если человек вам не подошёл?
Прислать счет за стакан воды и посещение туалета в офисе :)
И здесь я делаю допущение: допустим, что программист НЕ ДОЛЖЕН обладать сильными софт-скиллами.

Да, по overskilled очень часто отказывают
Да, действительно, все мы разные — на мой взгляд некоторые ваши примеры попали не в ту категорию:
однажды мне довелось 4 часа общаться с очень дружелюбным технарём, от которого я узнал множество интересных

это конечно же показатель его высоких софт-скиллов, что он легко и непринуждённо настроился вашу волну и увлёк разговором на по сути отвлечёную тему

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

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

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


Знание шаблонов ближе с софт-скилам — это способ быстро и однозначно объяснить или понять подход к решению задачи.

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

В моих словах нет никакого сарказма. Искренне считаю, что процитированный пример относится не к техническим скилам.

Шаблоны по определению не про нюансы. Это примерно как в обсуждении задачи прийти к выводу, что необходимо обойти все элементы. Один подразумевает оператор foreach, а другой метод map(). И на этом этапе не нужно разжёвывание нюансов.

Можете привести побольше примеров на эту тему, пожалуйста? Желательно поближе к шаблонам. А то пока-что не понятно.

«Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор)

Больше похоже на человека с расстройством аутистического спектра.

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

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

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

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

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


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

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


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

Пытаюсь донести что вот эту самую крутость невозможно оценить за собеседование.

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

Мне действительно тяжело понять в чём проблема в этом вопросе.
Включаем логику:
вы пришли собеседоваться не как модель для одежды, а как программист. Так что их интересует не ваш вес и цвет глаз, а что вы о себе как программисте можете рассказать.
Что такое рассказать о себе как программисте? Что умею, что делал, что хочу делать.
Совсем в общих чертах и буллет поинтах вы уже это написали в резюме. Значит немного подробнее чем там.
И собственно в чём тут проблема этого вопроса? Логическая цепочка проста, я не вижу тут извините проблемы для технического ума, я вижу какие-то левые оправдания.

Это как вопрос — а расскажите о вашем сервисе. Тут тоже ступор будет?
Или будет «читайте код, доку я писать не стал, я пишу код»?..

Пытаюсь донести что вот эту самую крутость невозможно оценить за собеседование.

Как можем, так и делаем.
В любом случае человек который может объяснить что он делает при прочих равных полезнее человека который может сделать чёрный ящик, а объяснить не может (магия что ли?).
Совсем в общих чертах и буллет поинтах вы уже это написали в резюме. Значит немного подробнее чем там.

"Что и где конкретно подробнее вы хотите узнать?"
Собеседующие, которых раздражают встречные вопросы, могли бы задуматься о собственном софт-скилле.


а расскажите о вашем сервисе

Конкретные вопросы не вызывают ступор у технарей. Цимес ситуации в том, что спрашивающий будет оценивать не сам сервис, и не скиллы которые были использованы (хотя изо всех сил будет делать вид что он оценивает именно это). Он будет оценивать складность выдаваемых предложений, их "мелодичность" звучания. А это далеко не самое важное для программиста.


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

Утверждая что-то на 100% вы автоматически падаете в ошибку определенности. Вот мне мой опыт показывает мне что существуют очень талантливые в своей сфере люди, не обладающие даже средним навыком коммуникации. Сконтачиться с такими людьми, включить их в процесс и заработать вместе с ними денег — задача босса.


Забавно что мой проект изначально назывался Black Box ^_^
Черные ящики на то и чёрные, что вам не нужно лезть к ним внутрь, чтобы ими пользоваться.

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

И вы знаете это потому что ваши коммуникационные скиллы на уровне чтения чужих мыслей? Или вам сам интервьюер нашептал после собеса что он оценивал?

Сконтачиться с такими людьми, включить их в процесс и заработать вместе с ними денег — задача босса.

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

Ага. А потом талантливый человек уйдёт и разбирайся с его творением. А поскольку он и двух слов связать не может, то никто ничего не знает. Bus factor = 1.
Все боссы об этом мечтают. (Нет.)
И вы знаете это потому что ваши коммуникационные скиллы на уровне чтения чужих мыслей? Или вам сам интервьюер нашептал после собеса что он оценивал?

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


Ага. А потом талантливый человек уйдёт и разбирайся с его творением. А поскольку он и двух слов связать не может, то никто ничего не знает. Bus factor = 1.
Все боссы об этом мечтают. (Нет.)

Вы кинулись в крайность "двух слов связать не может". Я обсуждаю разницу между высоким коммуникативным навыком и средним. Кажется что мало кто здесь представляет себе что такое высокий коммуникативный навык.


Ваша стратегия "нанять человека получше умеющего связывать слова" мне примерно понятна. Мне так же интуитивно понятно, что такой человек с большей вероятностью не справится со сложной задачей или справится с ней таким образом, что оно всё разъедется и сломается в какой-то момент.


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

Вы кинулись в крайность «двух слов связать не может». Я обсуждаю разницу между высоким коммуникативным навыком и средним. Кажется что мало кто здесь представляет себе что такое высокий коммуникативный навык.

А у человека со средним коммуникативным скиллом никакой проблемы ответить на «расскажите о себе» нет. Это у вас крайность — что на этот вопрос нужны какие-то сверх высокие умения софт-скиллов. Курсы какие-то и так далее.
Мне так же интуитивно понятно, что такой человек с большей вероятностью не справится со сложной задачей или справится с ней таким образом, что оно всё разъедется и сломается в какой-то момент.

Жизнь это не ДнД. Не стоит вопрос при создании персонажа — «а не убрать ли мне 3 очка из харизмы чтобы интеллект от 17 о 18 поднять?». А те кто не сделали так, проигрывают минмаксерам.

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

Личное оценочное суждение?

Да. Именно так.
А какое ещё может быть в данном разговоре?

Вот и перекидываемся противоположными мнениями.

Ну, может, исследования какие были. Или просто голосовалк типа "у меня средние навыки коммуникации и рассказать о себе на интервью составляет/не составляет проблемы" :)

А у человека со средним коммуникативным скиллом никакой проблемы ответить на «расскажите о себе» нет.

Очень спорно. Может будь у меня статистика хотя бы из 10 собеседований — я бы мог на ее основе прикинуть что скорее всего хотят узнать. Но я за всю жизнь был лишь на 2 собеседованиях. Потому я даже близко не знаю чего именно от меня хотят этим вопросом. Может хотят побольше про технический бекграунд узнать. Может про околорабочие интересы. А может вообще про личные интересы, темперамент и т.п., чтобы узнать как я в коллектив впишусь и буду ли «тимбилдиться» добровольно после работы в баре/спортзале/etc.
Не стоит вопрос при создании персонажа — «а не убрать ли мне 3 очка из харизмы чтобы интеллект от 17 о 18 поднять?».

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

Только выучить новый ЯП просто, даже если это адовая наркомания, потому что книжки есть, и что делать, понятно — ты просто берёшь и читаешь их. А что прочитать, чтобы выучить социальные взаимодействия — непонятно.

Включать зеркальные нейроны? Хотя, да, навык общения в первую очередь тренируется, а не учится по книжкам

Это только после смены мировоззрения происходит… Я не про радикальную смену говорю, типа «есть ли бог на Марсе», а про более простые, но от этого не менее важные вещи.

Так на что надо мировоззрение поменять, чтобы харизма выросла? Как говорится, action item какой?

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

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

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

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

Здорово, когда количество открытых позиций больше 1. В моём опыте открытая позиция всегда была одна, увы.

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

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

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

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

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

Ни одной?)
Кстати отдельным развлечением является указание адептам SOLID На тему того, что Active Record нарушает S. А дальше выясняется что проект не так уж и обязан следовать solid…

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

потому что когда я нормализую, я не использую русские слова, я использую внутренние знания, приобретенные не на парах в университете, а на «боевом» опыте.
Для этого даже термин есть: «Неявное знание».

Да ладно, что все накинулись то автора обвинять.
Статья содержит много объективных мыслей.


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


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


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


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


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


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


И что самое сложное — с ростом скилов процесс не упрощается (ведь я уже столько сделал и столько всего знаю),
а усложняется (ведь собеседующий уже тоже столько всего делал, но другого или по другому и столько знает из своего персонального опыта с прицепленными маркерами вот "это реально важно, ведь тут я столько ** съел).


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

>Да ладно, что все накинулись то автора обвинять.
Да вроде никто особо не обвиняет? Статья в плюсе, хоть и в небольшом. Взгляд на вещи — ну может и необычный, и не все согласны, очевидно. А должны были?
допустим, что программист НЕ ДОЛЖЕН обладать сильными софт-скиллами
Если программист не хочет всю жизнь оставаться джуниором — увы, должен. Общение неизбежно. Не с клиентами, так с коллегами и руководством. Этого не надо бояться, этим надо пользоваться.

Я пытаюсь вам показать что есть альтернативные пути развития, грубо говоря предлагаемый вами вижн это "техлид", а альтернативный — это "гик". Конечно, обладая сильными софт-скиллами намного проще проходить собеседования и — как следствие — менять места работы как перчатки. Затачиваясь же на технические фишки вместо (в жертву) коммуникативных с одной стороны вы рискуете не найти себе работу сразу после форс-мажорного увольнения, но с другой стороны вы становитесь способны на реализацию систем такой сложности и глубины, которая "техлиду" только снится. Конечно даже эти две ветки условны, ведь реальный скилл зависит не только от выбора между ними, но и от выбора "изучить еще что то новенькое, создать еще что-то интересное" или "посмотреть ютюб, почитать случайные статьи на хабре".


О страхе общения речи вообще не было. Менеджер же не программирует не потому что он боится программировать.

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


Где-то надо чтобы программист был аналитиком и сам понимал нужды пользователей.


Основная масса где-то посредине — не нужны не ультратехнические ни ультрасофтскиллы, но какая-то удобная смесь.


Затачиваясь же на технические фишки вместо (в жертву) коммуникативных

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

Зачем брать какого-то постоянно ноящего и гнобящего всех коллег кандидата, который будет разрушать атмосферу в команде, всех раздражать и всем мешать? Если можно взять адекватного и приятного человека?
Может разве что на места, где нет никаких команд и коллег, и работник общается только с менеджером-роботом. Когда такие места появятся, тогда и можете забивать на софт-скиллы.
П.С. Совершенно непонятна «жертва», как будто софт скиллы вы учите за партой годами в универе. Нет никаких жертв здесь, только нежелание.

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


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

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

Не похоже, что у вас высокие софтскиллы в письменном неформально общение, уж извините

Не похоже, что у вас высокие софтскиллы в письменном неформально общение, уж извините
Я на интервью? Или для вас любое общение это какие-то магические «софт-скиллы»?

Я исхожу из нескольких предположений:


  1. вы пишите комментарий не для того, чтобы его написать, а чтобы донести до других свою точку зрения, своё мнение, своё суждение, чтоб хотя бы её признавали одним из рациональных взглядов на ситуацию. Возможно даже убедить всех читателей, что точка зрения вашего оппонента Reuniko неверная, а ваша верная
  2. сознательно вы не хотите строить себе дополнительные барьеры для достижения своих целей из пункта 1
  3. академически межличностным коммуникациям вы не обучались, разве что курс психологии в техвузе для галочки или что-то вроде этого

А для меня не любое общение софт-скилы, а общение, которое имеет какие-то цели и не содержит элементов, которые этим целям противоречат.

А для меня не любое общение софт-скилы,
Простите, а мой комментарий разве к вам был обращен? Я разговаривал с @Reunik, а вы вмешались в разговор, донесли до мена свою очень нужную «критику», продолжаете «критиковать» дальше, хотя я не выражал никакого желания для этого, а проблема со софт скиллами это у меня? ОК.

Размещение публичного комментария предполагает, что вам, как минимум, безразлична реакция аудитории. А то и хочется фидбэка от неё.

А то и хочется фидбэка от неё.
Не в этом случае. Сейчас главное до меня — рассказать Reuniko почему он не прав.

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

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

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

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

Потом, возможно, все рухнет и окажется, что на Васе висела половина организации, но это потом.

Менеджеров, способных понять гика — слишком мало.

Да без форс-мажоров убедить того же менеджера что надо выделить ресурсы на рефакторинг, обновления или нанять dba или девопса…

Потом, возможно, все рухнет и окажется, что на Васе висела половина организации, но это потом.

Истории достойные пикабу.
«Некомпетентный менеджер», «сокращение», «после моего ухода всё развалилось», «потом звали починить за х3 деньги, но я не стал». Прям всё по тегам.
При этом само собой в таких историях никто не знает кто что делает. Ни таск трекеров, ни перфоманс ревью, ни 1-на-1 разговоров, ни-че-го в компании нет. Есть только угрюмый молчаливый супермен, который незаметно всё держит и менеджер, который видимо по блату принят и не разбирается ни в чём.

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

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

В том что такое иногда происходит я поверю

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

Всё более-менее нормально с управлением только у бедных (мелких стартапов и прочих) — не из-за бедности, а из-за того, что они мгновенно накрываются, если у них с управлением что-то идёт не так. А у богатых их запас прочности может покрывать очень много неэффективного управления.
Я сомневаюсь не в том что существует неэффективное управление, а о ситуации в целом.
Ключевой сотрудник, о котором никто не знает что он ключевой и его под нож.

Как это работает? Он решает ключевые задачи, которые нигде не записаны? Когда людям нужно что-то узнать они идут к нему, после чего все забывают откуда они получили эту информацию? А сам Вася её получил откуда? Если он тут на проекте 20 лет сидит, то ему бы за выслугу лет выдали бы очень-важный-эксперт-сениор. И тогда бы вряд ли он пошёл бы первым на сокращение.
Если нужно обсудить крупный проект между командами, то как они проходят без него? Кто-то другой там говорит за эту часть кодбазы? Т.е. у кого-то кроме Васи на самом деле есть более-менее достаточные компетенции?
Ну возможно на самом деле не такой и важный этот Вася.

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

Ещё кстати наверняка на часть таких историй, есть истории со стороны оставшихся людей. «Был у нас какой-то Вася, что-то делал, уволили, а мы потом заглянула туда, и ууу, лучше бы не заглядывали».

То что вы поговорите про запас прочности — так это и есть один из компонентов правильного менеджмента. Крупная компания без запаса прочности выжить не может.
Ещё кстати наверняка на часть таких историй, есть истории со стороны оставшихся людей. «Был у нас какой-то Вася, что-то делал, уволили, а мы потом заглянула туда, и ууу, лучше бы не заглядывали».

Потому что чужой код, а код, в который до увольнения Васи никто не глядел — чужой, мало кому нравится. Чтобы он нравился, он должен быть написан так, как нравится смотрящему в этот код (тут по классике «красота — в глазах смотрящего»), а он не то, что в создании кода, он даже в создании стайл и гайдлайнов для этого кода участия не принимал и ессно никогда не участвовал в код-ревью.
Поэтому да, лучше бы не заглядывал, но ведь работало, ценность для бизнеса имело. Тут понадобилось прикрутить сбоку что-то или обновить что-то старое и понеслось. Проще переписать, чем допилить, ага-ага. NIH как он есть. Причем даже не NIH, not-invented-by-me.
он не то, что в создании кода, он даже в создании стайл и гайдлайнов для этого кода участия не принимал и ессно никогда не участвовал в код-ревью.

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

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

Главное, что все могут понимать что Вася делает хоть примерно.

«он» — это новый разработчик на проекте, заместо ушедшего (уволенного) Васи. Который сейчас смотрит в этот код (и ужасается).
Компания большая, проектов может быть еще больше, соглашения о разработке могут быть, могут не быть, могут быть, но не применимы к конкретному ЯПу (например, у нас есть соглашение для Java, а для Питона — не было). Апруверов тупо не было, человек в одну каску всё делал. Если он писал и пушил сам по себе не значит, что Вася говнокодер, а значит, что одного Васи хватало, чтобы делать то, что от него просили.

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

Я всего лишь описал то вижн, что в текущий момент жизни кажется мне оптимальным. Понятие "нормы" субъективно, осторожней с ним.


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

Ну, например у нас условие мержа было: два апрува и ни одного ченж реквеста. Формального процесса разрешения конфликтов не было, только раз или два за год применялась власть CTO, а так как-то договаривались. Вместе собирались, индивидуально, скрам-мастер привлекался, владельцыы продукта, CTO...

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

и обсуждают

О ужас, говорить с людьми! К такому мануал гика нас не готовили, там только git push --force упомянут.

А вообще, если серьезно, то да. Если два или больше людей не согласны, то они идут обсуждать.
Если это мелкое разногласие — например по идиоматике написания какой-то вещи (не о кодстайле), то один здоровый человек говорит «всё ок, но мне кажется лучше вот такой вариант». После чего автор кода решает взять или нет, и независимо от варианта все спокойны.

Если есть объективно лучший вариант (или тут ошибка), автор правит. Опять же автор не затаивает обидку.

Если ревьюер считает что тут крупная проблема — которую потом потенциально чинить 100500 времени, и есть лучше вариант — а автор не согласен, то они берут и обсуждают. При необходимости позовут ещё людей. Если всё равно есть значимое несогласие, то кто-нибудь уступает. Если 50/50 уступает ревьюер. В случае если проблема таки поднимется, команда просто берёт и делает лучше. Независимо от принятого решения и результата ревьюер не зубоскалится, автор кода не затаивает мегаобидки и вообще все ведут себя как взрослые люди. И все становятся немного опытнее.

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

Здорово что вы можете позволить себе тратить так много времени на анализ и критику чужого творчества в рамках одного проекта. Можно пофантазировать на тему "а что было бы если бы мы еще ревьювили бы соседние проекты тоже". Вот опыта то подкатило бы!


Если 50/50 уступает ревьюер.

И демократия у вас тоже интересная. Два человека не смогли договориться (их общего коммуникационного скилла не хватило), значит нужно привлечь всех вокруг, устроить "судилище" с "присяжными", да еще и после этого "проигравшему" делать вид что ему это не было неприятно ни капельки.


Мы вот больше фокусируемся в декомпозицию проекта на максимально независимые куски и изоляцию программистов между ними и жонглирование задачами таким образом, чтобы к отпуску конкретного программиста их поток ослабевал или вообще ставился на паузу. Конечно, не всегда получается, но и ситуация когда ключевой программист в отпуске — редкая и переживаемая с некоторыми трудностями: заменяющему программисту приходится читать чужой код "adhoc" в момент если есть срочная задача из чужой области ответственности. А не всегда, как у вас.

Два человека не смогли договориться (их общего коммуникационного скилла не хватило), значит нужно привлечь всех вокруг, устроить «судилище» с «присяжными», да еще и после этого «проигравшему» делать вид что ему это не было неприятно ни капельки.

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

Нужно уходить от инфантильного восприятия код ревью «судилищем» где все мечтают вас принизить.
Это инструмент где могут указать на пропущенные недоработки и на более хорошие решения.
Поэтому да, лучше бы не заглядывал, но ведь работало, ценность для бизнеса имело. Тут понадобилось прикрутить сбоку что-то или обновить что-то старое и понеслось. Проще переписать, чем допилить, ага-ага. NIH как он есть. Причем даже не NIH, not-invented-by-me.

Вообще говоря, за исключением совсем уж извращенных случаев, в код условного Васи, который просто где-то там работает — никто и не лезет. Проблемы начинаются тогда, когда в один прекрасный момент оказывается, что так дальше жить уже точно нельзя, надо дорабатывать — и вот там-то открывается бездна, и NIH там часто совсем не при чем. Просто при наличии Васи в штате этот код бы потихоньку рефакторился силами Васи сообразно надвигающимся изменениям, а без Васи оно всё дожило без изменений до некоего критического состояния (обычно еще и подразумевающего надвигающиеся дедлайны), и тут внезапно оказывается, что этот код, который просто работал — под новые реалии ну совсем не годится, и рефакторить надо вообще всё.

Любители всё переписать «просто потому что хочется» среди разработчиков конечно же есть (да чё там, я и сам это дело люблю), но таки кидаться и переписывать обычно бегут максимум джуны, а другие всё ж таки подгадывают это дело под другие объективно необходимые изменения.
Я сомневаюсь не в том что существует неэффективное управление, а о ситуации в целом.
Ключевой сотрудник, о котором никто не знает что он ключевой и его под нож.

Я могу детализировать, потому что я таких ситуаций повидал уже несколько (сам лично в них не был, но вот находился рядом), в том числе и в больших уважаемых конторах не из РФ.
Есть некий проект. Не mission critical для бизнеса, в том плане, что без него всё пойдет хуже, проблемнее, и дороже, но в принципе никто не умрет и бизнес не рухнет. Там работают некие технари и некое руководство. В один прекрасный момент, обычно вследствие гнетущей тишины вокруг (ничего особого не происходит, крышесносных задач никто не ставит, перспектив пробиться в ряды CEO у руководства нет) — руководство затевает некую движуху, что-нибудь там расширить, углýбить, развить, и вообще. Под эту движуху частенько происходят и кадровые перестановки, кто-то уходит, кого-то берут, и так далее. А потом проект просто накрывается: перестаёт принимать изменения (или, в особо запущенных случаях, вообще падает и больше не поднимается), не развивается, или делает через пень-колоду то, что раньше делалось без проблем.

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

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

>один до боли в пятой точке хочет чего-нибудь сделать, второй говорит, что предлагаемые изменения пойдут проекту во вред
Вот именно в такой. Упрощенный пример — один до боли пытается зарелизить нечто, где даже нет настроек на среду (то есть, условно, URL для коннекта к базе зашит для базы DEV, а база PROD не предусмотрена). А когда ему ключевые сотрудники говорят, что релизить это нельзя, потому что г**но, оно встает в позу, и начинается…
Должен прям сильными, т.е. харизма, хорошее умение читать атмосферу, хорошо поставленная речь, владеть софистикой и т.п.? Или достаточно просто уметь объясниться и вовремя замечания вставлять.
Обычно достаточно, но есть нюанс.
Я видел людей, действительно создающих системы «такой сложности и глубины, которые и не снились». У них даже отдельные башни из слоновой кости кабинеты были. Вот только застать их там было праздником, потому что архитектор — это не только уединение в чертогах разума и медитация, но и беседы с начальником, начальником начальника, начальниками других отделов, другими архитекторами, техлидами, реализующими ваши идеи, которые не всегда реализуются гладко, презентации с рисованиями на доске и ответами на вопросы аудитории и т.д. и т.п.
Харизма, речь, уверенность в себе, умение донести мысль, удержать внимание публики и т.п. у этих джентельменов были весьма длиннее и толще, чем в целом по организации.
Ну так мы и говорим про разработчиков, а не про архитекторов, тех/тим лидов, и прочий околоуправленческий люд который если и пишет самостоятельно код — то довольно редко.
Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор). Конструктор может немного покопавшись в памяти вывалить своё имя, возраст, рост и вес, национальность и цвет глаз, но при этом не поймет какое это все имеет отношение к делу, ведь он пришел продавать свой технический скилл, а не себя.

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

Это всё уже есть в резюме, потому и ступор. Не хочется повторять то что уже и так перед глазами.

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


Я, правда, сам таких вопросов не задаю, но не понимаю отчего тут впадать в ступор. Резюме повторять необязательно, можно рассказать упрощенную версию адаптированную под конкретного человека. Боссу более общую технарю более подробную.

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

Когда технарю "непонятно зачем" он впадает в ступор

Речь идет обо всех технарях или о каком-то конкретном ;)?

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

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

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

Ну так вы тоже не Величество и не Святейшество, и работать у вас, вероятно, не такая уж большая честь.

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

Не знаю клиник, где оперируют брёвна в глазу, но вы поищите. Хотя могут просто прописать курсы повышения софт-скиллов и снижения воспалённого ЧСВ.
Не знаю клиник, где оперируют брёвна в глазу, но вы поищите. Хотя могут просто прописать курсы повышения софт-скиллов и снижения воспалённого ЧСВ.
Ваши батхерты по пустяковым поводам тоже говорят о вас не в лучшем свете.
Я вам так скажу — в резюме все врут! Я видел только пару честных кандидатов, кто не приврал. И читать своё резюме за 5 минут до собеседования следует кандидатам, а не собеседствующему, ибо кандидаты даже не удосуживаются упомнить чего они там о себе такого написали. Моё мнение — техническому специалисту, проводящего собеседование, резюме кандидата надо читать после прохождения, а не до! Дабы понять причину почему на какие-то вопросы кандидат ответил именно так или почему именно так выполнил тестовое задание, — понять опыт его работы.
Ну и это помогает оценить кандидата не предвзято… а то часто настроишь себя по резюме «вот он, тот кто нам нужен», а по факту даже на 10% кандидат себя не стоит… :(
80% кандидатов не в состоянии рассказать о «самом интересном проекте», «о последнем месте работы — чем конкретно он занимался, какой стек использовался, какая архитектура решения».
Если вы считаете что это бесполезная трата времени — значит нам вместе не работать :)
Дополню — а бывает наоборот. Кандидат в резюме по какой-то причине не указал опыт в фриланс, к примеру, но по очень реаливантному стеку, пет-проект, которым «может гордится», опять же решение может быть очень интересно компании. При этом в резюме — сухая выдержка, пара ключевых строк. Также часто резюме делают под вакансию… и если был опыт в других сферах — у нас же как считается — «специалист во всём — значит ни в чем — развиваться надо в конкретной области». А вот опыт в других сферах компании тоже мог быть интересен.
Поэтому рассказать о себе часто ещё и полезно.
Бывает конечно рассказ о себе выявит какой-нибуть опыт разработки в букмекерских конторах или онлайн казино, или ещё что-то такое… на что у руководства «аллергия» :)…

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

Работа в команде программистов разительно отличается от работы в футбольной команде, например. Если в последней вам необходимы навыки коммуникации уровня чтения тела своего партнера чтобы вовремя выдать или поймать пас, то…
… в командной работе над сложным проектом бОльшая часть "магии" заключается в ловком жонглировании техлидом задач и зон ответственности между программистами с целью минимального их пересечения друг с другом.


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

Тут хотелось бы ссылку на то как художники реально работают над одной картиной. Разрезают ли они холст на квадраты общаются и так далее — или метафора ничего не имеет общего с реальностью?


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


А еще код ревью


Как это устроено у вас?

Тут хотелось бы ссылку на то как художники реально работают над одной картиной.


Если речь идёт про digital, то может быть несколько сценариев:
1. Глава проекта намечает общую композицию, определяет единообразный художественный стиль, дробит на множество мелких объектов (персонажи, пропсы, фоны), отдаёт их художникам для детализации (возможно, после того как для картины построили черновой эскиз или 3D-модель), затем всё это пытаются свести, если получили всё необходимое в разумные сроки.
2. Есть пайплайн «лор/сюжет» — «скетч» — «лайнарт» — «шейдинг» — «колоризация», разные стадии могут быть поручены разным людям.

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

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


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


Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним. Вот тут и ответ. Отсутствие шизофрении полезно и в коде и в произведении. Количество фильмов с одним или несколькими сценаристами. И так далее. Конечно, бывают исключения.


программисты даже если они работают над задачами не связанными друг с другом периодически общаются для решения вопросов — один знает как искать утечки памяти, другой особенности какого-нибудь модуля и им придется обмениваться опытом

Это здорово, когда в команде есть авторитет по какому-то важному критичному в данный момент вопросу. Он придет на помощь и поможет, задача закроется в срок, все будут довольны. Но бывает что возникает противоположная ситуация: нужно реализовать нечто и никто не знает как это делать. Вот в такие моменты проявляется истинная сущность программиста: будет ли он последовательно отвлекать всех членов команды в надежде что они ему помогут, собирать консилиум и тратить уйму общего времени или… решит сперва самостоятельно исследовать вопрос с помощью своего мозга и интернета. На самом деле здесь нет правильного ответа, оптимальный путь лежит где то между ними.


Обучение новичков, код ревью — это к тимлиду.


"Особенности того что он сделал" вполне реально изучить самостоятельно, используя систему контроля версий, было бы желание. Но желания изучать самостоятельно нет, чтение чужого кода для большинства людей — сущий ад, вместо этого есть желание сэкономить мыслетопливо, спросив словами и получив ответ успокоиться. Здорово когда эта коммуникация происходит в рабочее время, а не когда один из разрабов попивает коктель на берегу теплого моря. Не здорово то, что эта коммуникация отвлекает одного из программистов от его текущей задачи, в результате чего он, после этой коммуникации, тратит дополнительно +- 23 минуты на то чтобы погрузиться обратно в свою задачу.

Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним.

Насколько я понял нас не интересуют картины написанные одним художником, скорее картины написанные коллективами? Если вы считаете что все-таки работа одного художника более показательна, то интересно, кто из них как общался с авторами.


нет правильного ответа, оптимальный путь лежит где то между ними.

То есть программистам все-таки когда-то общаться нужно да?


Обучение новичков, код ревью — это к тимлиду.

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


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

Как "реально" мне лично совершенно не интересно. Мне интересно как эффективно.


Еще мне бы хотелось знать, это ваши теоретические построения или есть какой-то опыт организации команд программистов на таких принципах.


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

Ну это зависит от задачи и от способа организации коммуникации. По-моему.

Опыт организации команды у меня всего один, опытов обзора организаций команд — много. Вы почему-то не замечаете разницы в моих понятиях "высокий коммуникативный навык" (высокий софт-скилл) и коммуникация между технарями. Технарю с технарем договориться на много порядков проще, чем с кем-либо еще. Поэтому, в моем вижне, этот кто-либо еще должен обладать высоким коммуникативным навыком, а не технарь, потому что иначе технарь уже не будет технарем, а станет смесью двух разных миров.


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

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

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


Я не очень понимаю зачем надо создавать single point of failure в виде тимлида причем тимлида с идеальной памятью. С моей точки зрения лучше чтобы сеньоры могли его поменять хотя бы в каких-то областях.


Ну да ладно мы тут пошли по кругу

Раскачиваю:


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

"Здорово" когда ты делаешь вывод о том, что кто-то другой чего-то не понимает. Все ясно, понятно и думать больше не надо.


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

> Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним.

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

То, что у вас с этим проблемы говорит только о том, что вы в этом недостаточно хороши. Глупо экстраполировать собственные недостатки на «большинстве людей».

Чтение чужого кода это, на минуточку, основное занятие программиста. Code review, исходники фреймворков, унаследованные проекты.

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

Ну я бы уточнил. Не любого программиста. Джунов этому еще нужно учить. Но начиная с некоторого уровня — да.
Тестовое задание. У нас принято тестовое задание решать прямо во время собеседования — в коллабе. Задание очень простое, больше расчитано на то, чтобы обсудить его с кандидатом и его понимании о том, как его решение работает под капотом.

Но! В последнее время пошли кандидаты, которые наотрез отказываются писать тестовое задание. Это что, товарищи? Почему я на словах должен верить в том, что чувак крутой программер, а не просто имеет хороший подвешенный язык?
У нас принято тестовое задание решать прямо во время собеседования — в коллабе.
Это не тестовое задание, а обычное идиотское вайтбоард тех интервью. Я бы тоже сразу отказался.
Вся идея и польза тестового задания, что кандидат пишет его в комфортной для себя, и максимально приближенной к обычной рабочей атмосфере обстановке.

А почему вайтбоард? Вроде про вайтбоард никто не говорил.

Ну да, в вашей фразе ничего про доску не было. Я обычно на выбор даю или там или там. И ни разу не выбирали доску.

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

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

Интересно, почему — вроде писать какой-то простой тестовый код не так трудно, чтобы он собирался.

Нахрена мне его собирать? ))) Ещё предположите, что я запускать его стану… )

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

Я же писал:
Задание очень простое, больше расчитано на то, чтобы обсудить его с кандидатом и его понимание о том, как его решение работает под капотом.


Например, можно задачу решить так, что в ней будет всего лишь одно выделение памяти, а можно так, что выделений будет O(n). Причем выделения будут неявными. Мне важно, чтобы программист понимал все side effect'ы кода, а не только его семантику. А возможность код собрать и отдебажить — это, мне кажется, вещи более мелкого порядка важности. То есть, если человек дошел до понимания того, о чем я тут пишу, то всяко он разобрался с тем, как компилять и дебажить, а вместе с тем, как включать компьютер )

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

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

Ну а потом это же не честно. Получается человек пришел на интервью, и так в стрессовой ситуации и его просят сделать 100% работающее решение. А проверяющий, в своей обычной обстановке и почему-то не своей головой проверяет решение, а пользуется машиной.
То что он там забудет название ф-ции, перепутает в ней аргументы или забудет точку с запятой, это же никакой дополнительной информации не дает.

Я не даю заданий на память. Только на логику и дизайн. Если человек, например, пишет в резюме 5 лет работы с технологией, то вроде с IDE он должен справиться — если забудет точку с запятой она подскажет. А потом интересно, как он будет убеждаться в работоспособности. А еще интересно как он трансформирует код. Например, использует буфер обмена или рефакторинги. Всякие мелочи я сам ему подскажу.


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

Понимаете, тут нет никакого соревнования между проверяющим и кандидатом. Есть соревнование между кандидатом и другими кандидатами. Так что неравенство здесь не играет роли.

Только на логику и дизайн.

Согласен полностью. Только у меня это в другом порядке, дизайн и логику.

Насчет остального, мне кажется мы просто в разных отраслях работаем. У меня это больше firmware и системное программирование. Иногда из IDE у нас просто vi в консоли. Да и когда мне код на ревью приходит то как-то все равно как его писали и рефакторили.

Так что неравенство здесь не играет роли.

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

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


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

То есть как. Вы вообще всех нанимаете кто хоть как-то подходит? Если их пришла 1000 наймёте 1000 — не будете искать одного лучшего?

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

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

Я как-то, на заре деятельности, просил у HR «а можно всех посмотреть». На меня странно смотрели, а потом обьяснили, что не так.

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


Какая вам разница был он первый, кто прошел тесты или один из 1000? Он же всем вашим требованиям удовлетворяет.

А если сеньёра нет, но сойдет и мидл, но если есть сеньёр лучше сеньёра?


Как в кафе — хочу кашу на завтрак, но если ничего уж совсем нет — давайте ваш эгг макмаффин.

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

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

А если сеньёра нет, но сойдет и мидл, но если есть сеньёр лучше сеньёра?

Если позицию технически можно закрыть мидлом то может и просить мидла нужно? И конечно же сеньор от сеньора отличается. Для этого есть рейтинг. Интервьюеры дают оценку насколько человек по какому-то скилу удовлетворяет определенному уровню. Например «На уровне ожиданий», «выше ожиданий», «существенно выще ожиданий». Так и формулируется заявка на позицию «нужен человек с уровнем сеньор, оцененный „выше ожиданий“.

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

А почему нельзя "всех посмотреть"? Конкурсы запрещены внутренними правилами или законодательством?

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

Вот представьте, что есть несколько кандидатов которые прошли отбор по формальным признакам. Потом кто-то их сравнил и выбрал одного. Это же непаханное поле, чтобы судиться. Обиженные кандидаты подадут иск, что их отвергли потому-что кто-то старше/моложе, светлее/темнее и т.д.
>потому-что кто-то старше/моложе, светлее/темнее и т.д.
Умнее, ага…
Даже, если человек нужен прямо в вашу команду в западной компании вы будете лишь одним из принимающих решение (и не всегда с правом решающего голоса). Этим решается во-первых дикриминация, во-вторых возможный конфликт интересов, когда менеджеру нужно заполнить вакансию кем угодно, а компания заинтересована в лучших кандидатах.
Такое задание, о котором вы говорите, как правило, существенно сложнее и подразумевает, что не только вы напишите код, но и протестируете его, пришлете собирающийся проект и тестовое множество.

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

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

Почему чувак должен хотеть работать в вашей компании достаточно сильно, чтобы согласиться на бесплатную работу (пусть и на час)?
На рынке есть некоторый пул компаний, в которые нанимают после того, как зададут пару-тройку вопросов инженерного толка, после которых не ощущаешь себя выжатым досуха, как лимон. Если перебирать достаточно интенсивно, вполне можно на них наткнуться. Закономерно, что работники стремятся минимизировать неоплачиваемую неприятную работу и фильтруют компании, которые устраивают чрезмерно жёсткие на их взгляд вступительные испытания без заметного вознаграждения.
Почему чувак должен хотеть работать в вашей компании достаточно сильно, чтобы согласиться на бесплатную работу (пусть и на час)?


1) Работа подразумевает некоторый полезный результат. Здесь о пользе результата говорить не приходится. О каких деньгах тут вообще речь?
2) Там не на час, а минут на 15-30.
3) Я смею вас уверить, что проходить собеседование и отвечать круто на технические вопросы — это такой скил, который вообще ничего не имеет общего с написанием кода. Вот, например, недавно пришел кандидат и начал нам очень складно петь о том, что он с ещё одним чуваком вдвоем сделали полностью систему для автоматизации парковки. На одноплатном компьютере с ARM, на Linux 2.4 и прочими блэкджеками. Когда же дошло до задачи, то он (заявляя вначале, что он ас в плюсах) стал сползать, что давно на плюсах не писал, а всё больше на С. Ок, пиши на С. В общем час трепыхался не написал ничего толкового. Задача, к слову, в один проход пройтись по строке и слепить из неё вторую строку. Потом, через третьи руки я узнал, что он был ПМ в одной конторе, провалил проект и его там выгнали. Но пел, аки соловей.
4) На мой взгляд больше толковых кандидатов можно потерять, если начать их пытать знанием плюсов, особенно такими тупыми вопросами как виртуальный деструктор и прочая классика.
1 — работа подразумевает трудозатраты, и не обязательно результат, с точки зрения исполнителя. Так что основной вопрос в том, кто эти трудозатраты оплатит. Если работодатель хочет получить больше желающих выполнить тестовое задание, то может оплатить эту работу. Если рабочего не зовут на собеседования, то, теоретически, он мог бы оплатить время собеседующего и тем взять затраты на себя.
> 1 — работа подразумевает трудозатраты, и не обязательно результат, с точки зрения исполнителя.

Вообще говоря, результат у работы должен быть, хотя бы отрицательный (типа сделать не возможно или получается очень криво). Но с некоторыми исполнителями получается именно так, как вы написали — жопо-часы в наличии, а результата нет никакого. Именно от этого стремимся защититься.
«пишу тестовое задание только за деньги», пусть даже тестовое задание занимает всего один час.
А приехать на интервью, возможно взяв полдня отпуска за свой счет, черте куда, потратив несколько часов на все — это ОК? Потратить час дома в знакомой обстановке неспеша написав код — ни в коем случае?
Зависит от обстоятельств (или личного опыта), честно говоря.
К примеру, мой личный опыт, который я могу приводить как пример:
— 9 мест работы;
— не было среди них мест, куда бы меня взяли бы после выполненного тестового задания;
— было 9 мест, куда меня взяли без тестового задания.
Если считать по офферам, там ситуация еще хуже (в смысле офферов было больше, а на ноль всё так же делить нельзя).
Отсюда у меня сложилась связь: «выполняешь тестовое — зря теряешь время».
Задания на 1 час, как правило, дают на собеседованиях, на дом задают бОльшие задания.
А дома, в знакомой обстановке неспеша я лучше напишу что-то в пет-проект, или прослушаю запись доклада с какой-нибудь движухи. Одно сделает меня опытнее, другое — умнее (но это не точно).
Почему я на словах должен верить в том, что чувак крутой программер, а не просто имеет хороший подвешенный язык?

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

Чего угодно. Можно достаточно быстро выяснить что человек реально делал а чего не делал если просто пройтись уточняющими вопросами по его проектам.

И вам ответят, что там все под NDA и обсуждать глубоко не будут

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

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

Идеальное собеседование — милая беседа с HR, а техническое собеседование не требуется, т.к. кто-то достаточно авторитетный подтвердил твою квалификацию)

Т.е. запрашивать рекомендации с предыдущего места работы и только их — вы много так наняли?

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

Меня так нанимали трижды.
Один раз ошиблись, не сработались.

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

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

Чтобы получилось такое число, достаточно просто ходить на собесы 1-2 раза в месяц 6 лет кряду, чтобы сложить для себя представление о том что востребовано.

Что удивляет в высоком шансе отказа? Эйчары вполне могут составлять обоймы из кандидатов, которые требуется отсобеседовать целиком до найма одного из них, таким образом шанс каждого соискателя будет даже не 50%.
В крупных западных компаниях на рядовые должности не сравнивают кандидатов между собой. Если человек raised the bar на конкретную роль — то его берут. Если таких трое — еще лучше, возьмут трех, пригодятся в хозяйстве.
Я бы сказал, что у нас так тоже бывает в крупных компаниях, у которых деньги в целом не особо лимитированы.
Так-то в больших компаниях эти самые софт скилы проверяют на отдельном интервью. И вопросы которые надо задавать, что конкретно они проверяют и как оценивать ответы, все это уже заранее есть и собеседующие проходят тренинги на тему как этим правильно пользоваться. На «perf review» так же оценивается такая характеристика как «citizenship».
Сейчас я определенно вижу плюс, в том что люди в компании могут общаться плюс минус одинаково и из них не нужно вытягивать информацию щипцами.

Я на нетехнических интервью обычно начинаю с вопроса о том, что человек делает сейчас. Во первых по резюме, которое читаешь минут пять максимум, не совсем это понятно. Во вторых людям всегда есть что сказать по этой теме и проще начать разговор.
Если же у вас достаточно бюджета, вы можете попробовать следующий трюк: предложите 1 испытательный месяц работы всем желающим за пол ставки
хороший способ угрохать в никуда практически любой бюджет. Даже если есть бюджет на оплату ½ ставки всем подряд, где взять столько людей, чтобы погружать их в проект, разжёвывать им особенности местного использования принятого в компании технологического стека, ставить задачи так, чтобы они сходу понимали хотя бы чуть больше трети (на половину я бы вообще не рассчитывал), а потом ещё и делать code review мутному потоку кода от них. Нет, HR-конвейер, способный переварить огромный поток индусов рандомных кандидатов и отсеять зёрна от плевел — штука хорошая, только бюджет и очередь на вход, как у гугла или там амазонов с фейсбуками есть далеко не у каждого, а без этого к такой задаче лучше не подступаться. Да и коэффициент ложноотрицательных результатов у него весьма приличный, тк он заточен именно на грубый формальный отсев хоть в чём-то неподходящих кандидатов.

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


А те кому достаточно просто подходящего могут продолжать работать по старинке.

Расскажите пожалуйста о своей практике в рекомендуемой вами методике приема.


Вот например принимается три новых человека на полставки на одно место. Допустим, им не надо три рабочих места — все работают удаленно.


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


Как его на все хватает? Кто играет его роль, когда он уходит в отпуск? Сколько тимлидов нужно команде?

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

Это тс вашей точки зрения необязательно. А с точки зрения reuniko обязательно. А то ж разработчиками придется обращаться и у них должны быть софтскиллы. Это было явно написано ранее

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

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

У меня не было подобной практики, моё предложение буквально высосано из пальца.


Однако однажды мне довелось поработать в фирме, процесс интеграции новых сотрудников в которой был оптимизирован лучше некуда:
— выдается инструкция на 3 листах А4 общекомпанейская куда подключаться и кому какие запросы слать в тех или иных случаях,
— тимлид заранее подготавливает и практически "выстреливает" все необходимые доступы к текущему проекту: гит, тестовый сервак, трекер задач; дополнительно закидывая FAQ или даже wiki, в которых раскрыто 90%+ вопросов,


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

Начнём с того что это не законно, — противоречит ТК РФ. Нельзя снижать ставку на время испытательного срока.

Ну, это тем не менее не мешает многим компаниям так делать (это не у вас ставка ниже на исп сроке, а мы вас может быть повысим после прохождение исп срока — манипуляция? Да! Законно? Ну, на грани)

Неужели на «может быть повысим» соглашаются? Это уж совсем если от безысходности. Работать 3 месяца, да хотя бы месяц на 1/2 ставки?.. — разве что эта 1/2 ставка выше полной рыночной. Обычно же работу ищут условия повысить, а не понизить. А тут получается «возмут-не возмут» — под вопросом, «повысят/неповысят» — под вопросом… а в доходе от предыдущей работы — терять в доходе.
Крайне редки же случаи когда новая работа со ставкой более чем в 2 раза выше текущего. А с любой другой оплатой ниже такового 1/2 теряет смысл.

Ну я пару раз за последние лет 10 соглашался. Правда, не на 50%, а на 10-20. Причина: компания понравилась, а доход на испыталку больше чем на последнем месте. Было пара других офферов, без этой 10-20% "скидки", но просто как-то не понравились.

grafstroganov я знаю пару компаний, где… была годовая премия 20-30% (не от месячной, а от совокупной з/п за год) в зависимости от грейда. По понятным соображениям, испытательный срок — не включается в этот срок. Бывает даже, что и надо отработать минимум 1 полный год, чтобы претендовать на годовую премию. Разные условия есть. Вот так посчитаешь и подумаешь, что действительно с этими "манипуляциями" эффективно в самом неудачном случае ты получишь как раз ½ от своего более удачного и толкового коллеги. Так что разные ситуацию бывают, даже вполне законные.

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

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

Ключевое слово наконец прозвучало: "это часть ритуала".
Обычно человека вначале спрашивают о всяком, чтобы немного наладить контакт, понять темп речи, перейти на ты, создать дружелюбную атмосферу, потом уже переходить на непосредственно к техн интервью.
Это игра с обеих сторон. Со своими неписанными правилами. Нужно принять как квест и пройти игру.

Гикам тяжело даются "ритуалы". Примерно так же тяжело как HR'у — программирование.

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

Так что же, реально за 1-2 часа разговоров оценить человека достаточно хорошо чтобы принять правильное решение?

Нереально. 3-5 минут в среднем
У вас походу проблемы с социализацией, если вы считаете, что при найме в штат у вас покупают исключительно технические навыки.
В первую очередь. Потому что программист без технических навыков — не программист.
Софтскиллы — это плюс, но они вторичны. В конце концов за толпу интроверсивных но могучих программистов вполне может общаться тимлид с подвешенным языком. Это не шутка, я видел такие команды разработки.
Он их прикрывает, изолирует от стрессовой для них коммуникации, делает команде комфортно. А ребята просто херачат код со страшной силой, во все 146% которые умеют. Потому что они в понятной и комфортной для себя психологической среде.
Потому что программист без технических навыков — не программист.
Без умения говорить языком это тоже не программист, это компилятор.

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

Не, без умения говорить языком — это, конечно, более интеллектуальная вещь, чем компилятор. Но вот не хочет человек в социалочку. Единичное число пиринговых коммуникаций поддерживает на работе — и всё. При этом работает хорошо. Выгонять не за что. Но без медиатора в команде в виде тимлида — будет работать сильно хуже.
У меня коллега такой есть, из соседней команды. До сих пор ноет, что ко мне под крылышко хочет. Но как-то же его взяли на работу, и не один раз. Значит что? Значит работодателю нужен в основном интеллектуальный компилятор.
Да, но нет. «Штат» — это всегда социальные коммуникации. Ну вот прям с тем же тимлидом, о котором вы говорите — он бездушный робот, что ли? И не надо, если компания не ит-продуктовая, то ваша обязанность херачить код не в «комфортной для себя среде», а куда и как скажут. Потому что вы обслуживающий персонал. Готовы обеспечить уборщице «комфортную для себя психологическую среду»?
Да, в непродуктовой среде такие индивидуумы не приживаются. Но как я выше описал — это не значит, что они абсолютно бесполезны. Просто у них более ограниченные условия использования.

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

Нет, не вторичны. Крупные проекты пишутся огромными командами, часто в разных странах. И если человек не может наладить контакт с коллегами — может ему там и не место?
сли человек не может наладить контакт с коллегами — может ему там и не место?

Или наоборот? Коллегам некогда налаживать контакт? Зависит же в первую очередь от профильных скиллов.
Так что — увы, но вторичны.
А что коллеги? Должны бежать ублажать нового человека который не хочет налаживать контакт? Коммуникации это дорога в обе стороны. Профильные скиллы тут вообще непричём.

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

Ну, если этот новый человек — rockstar developer — то да )

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

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


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

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

Умение связно излагать свои мысли никак не помешает выучить очередной фреймворк.

Так я обращаю внимание не на конкурирование навыка (умение связно излагать мысли) с процессом получения навыка (выучивание очередного фреймворка), а на конкурирование процесса получения навыка (курсы коммуникации) с процессом получения навыка (выучивание очередного фреймворка). Время не бесконечно, иногда приходится выбирать одно, условно принося в жертву другое. Можно конечно и за двумя зайцами гнаться, бывает даже что у кого-то это получается, но опять же за счет чего-то третьего, от чего пришлось отказаться. Мне кажется что степень\глубина специализации обратно коррелирует с числом этих самых специализаций. Конечно, бывают исключения.


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

Так я обращаю внимание не на конкурирование навыка (умение связно излагать мысли) с процессом получения навыка (выучивание очередного фреймворка), а на конкурирование процесса получения навыка (курсы коммуникации) с процессом получения навыка (выучивание очередного фреймворка). Время не бесконечно, иногда приходится выбирать одно, условно принося в жертву другое.
Популярное заблуждение. Никто не способен учиться по 16 часов в сутки на протяжении многих лет. Нужно отдыхать. А отдых — это смена деятельности.

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

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

Все верно, но до IT эта проблема только докатилась, в других сферах она была давно в таком же виде.
Расскажите о себе

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


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

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