Простите мне моё занудное любопытство, а было ли в трудовом договоре что-то отражено на тему обязанностей быть чистым и вкусно пахнуть?
Если да — то всё верно.
Если нет — то произошла лютая социальная игра в которой одни люди, не обладающие достаточным высоким коммуникативным навыком, чтобы переубедить других людей вкусно пахнуть… выперли этих самых людей ради своего удобства.
Умение связно излагать свои мысли никак не помешает выучить очередной фреймворк.
Так я обращаю внимание не на конкурирование навыка (умение связно излагать мысли) с процессом получения навыка (выучивание очередного фреймворка), а на конкурирование процесса получения навыка (курсы коммуникации) с процессом получения навыка (выучивание очередного фреймворка). Время не бесконечно, иногда приходится выбирать одно, условно принося в жертву другое. Можно конечно и за двумя зайцами гнаться, бывает даже что у кого-то это получается, но опять же за счет чего-то третьего, от чего пришлось отказаться. Мне кажется что степень\глубина специализации обратно коррелирует с числом этих самых специализаций. Конечно, бывают исключения.
Что касается "умения связно излагать свои мысли" это дико субъективная штука. Вам может казаться что кандидат не может излагать связно, а вашему компаньону может показаться наоборот, потому что в его голове есть некоторые знания и связи, благодаря которым он автоматически достраивает излагаемую историю до связанной.
Прежде чем делать выводы о каком-то человеке я стараюсь сперва разузнать о нем как можно больше, захожу в профиль на хабре например, просматриваю публикации. Чего и вам желаю ;)
Опыт организации команды у меня всего один, опытов обзора организаций команд — много. Вы почему-то не замечаете разницы в моих понятиях "высокий коммуникативный навык" (высокий софт-скилл) и коммуникация между технарями. Технарю с технарем договориться на много порядков проще, чем с кем-либо еще. Поэтому, в моем вижне, этот кто-либо еще должен обладать высоким коммуникативным навыком, а не технарь, потому что иначе технарь уже не будет технарем, а станет смесью двух разных миров.
Получается тимлид должен обязательно знать в деталях весь проект лучше чем каждый программист, даже который написал какой-то кусок, который сейчас правит другой программист?
Тимлид должен знать весь проект, должен знать где копнуть чтобы вспомнить детали. Это вполне реально когда ты ведешь проект с нуля, спроектировал архитектуру и читаешь почти в реальном времени все приходящие в него коммиты. Если же проект не твоего авторства, то приходится выделить некоторое время на его изучение, чтение кода, мало кому это приятно. В процессе чтения этого кода у тимлида могут возникнуть вопросы "почему так, а не эдак", но и здесь нет проблем, поскольку он обладает высоким коммуникативным навыком, в отличие от окружающих его программистов, которые могут себе позволить сосредоточиться на технических аспектах задачи, будучи изолированными от общения с заказчиком и, возможно, менеджером. С одной стороны такая конфигурация создает дополнительную нагрузку на тимлида в те моменты, когда ее можно было бы избежать, с другой стороны у проекта падает градус шизофрении за счет общего центра, принимающего все важные ключевые решения в технической плоскости.
Пожалуй, я не достаточно конкретно выразился. Это совет тем фирмам, которые нацелены на найм именно лучшего, а не подходящего. Ведь бюджета то у них хватает на собеседования со всеми желающими? Вот в этом моменте они могли бы подвложиться для того чтобы достичь лучших результатов. К тому же большая часть кандидатов отвалится на моменте с половиной ставки без гарантий быть нанятым. А те кандидаты что останутся с большой вероятностью отработают вложенный в них бюджет.
А те кому достаточно просто подходящего могут продолжать работать по старинке.
То что воспринимается как "нытье" на низком уровне, может быть переосмыслено как "желание улучшить" на высоком. То что воспринимается как "гнобление" — как конструктивная критика. Приятные на первый взгляд люди часто оказываются манипуляторами. Преобразовать неприятного члена команды в приятного — вот канонический пример высокого софт-скилла, совершенно не подвластного технарям.
Вам непонятна жертва потому что вы подразумеваете что-то под софт скиллами, а я веду речь про высокие софт скиллы, сильный навык коммуникации, которому, действительно, обучаются если не "за партой", то хотя бы за деньги и тратя уйму личного времени. Нежелание прокачивать коммуникативный навык действительно присутствует, особенно когда технаря манит альтернатива в виде очередной технологии или вкусной задачи.
То что они общаются совершенно не означает что они обладают высокими коммуникативными навыками. Человек существо социальное, найдет время и повод на общение в любой ситуации, тем более рабочей. Нужно ли обращать ваше внимание на то сколько общения тратится на рабочие вопросы, а сколько на нерабочие?.. околорабочие?...
Программист программиста поймет с большей вероятностью, чем, например, продажника или менеджера или еще кого угодно, кто думает не в технической плоскости. Коммуникация между технарями — это отдельный подвид коммуникации, оценить который затруднительно человеку с социальным мышлением.
Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним. Вот тут и ответ. Отсутствие шизофрении полезно и в коде и в произведении. Количество фильмов с одним или несколькими сценаристами. И так далее. Конечно, бывают исключения.
программисты даже если они работают над задачами не связанными друг с другом периодически общаются для решения вопросов — один знает как искать утечки памяти, другой особенности какого-нибудь модуля и им придется обмениваться опытом
Это здорово, когда в команде есть авторитет по какому-то важному критичному в данный момент вопросу. Он придет на помощь и поможет, задача закроется в срок, все будут довольны. Но бывает что возникает противоположная ситуация: нужно реализовать нечто и никто не знает как это делать. Вот в такие моменты проявляется истинная сущность программиста: будет ли он последовательно отвлекать всех членов команды в надежде что они ему помогут, собирать консилиум и тратить уйму общего времени или… решит сперва самостоятельно исследовать вопрос с помощью своего мозга и интернета. На самом деле здесь нет правильного ответа, оптимальный путь лежит где то между ними.
Обучение новичков, код ревью — это к тимлиду.
"Особенности того что он сделал" вполне реально изучить самостоятельно, используя систему контроля версий, было бы желание. Но желания изучать самостоятельно нет, чтение чужого кода для большинства людей — сущий ад, вместо этого есть желание сэкономить мыслетопливо, спросив словами и получив ответ успокоиться. Здорово когда эта коммуникация происходит в рабочее время, а не когда один из разрабов попивает коктель на берегу теплого моря. Не здорово то, что эта коммуникация отвлекает одного из программистов от его текущей задачи, в результате чего он, после этой коммуникации, тратит дополнительно +- 23 минуты на то чтобы погрузиться обратно в свою задачу.
Отношения к кандидату как королеве и не ожидается, достаточно того чтобы собеседующий прочитал резюме, обновил информацию в своей краткосрочной памяти минут за пять до собеседования. В противном случае складывается впечатление что либо вы в принципе не интересны этому человеку, либо он не способен организовать свой график таким образом, чтобы минимизировать трату своего и чужого времени. Что сходу в лучшем случае демотивирует, в худшем может быть воспринято как неуважение, результат предсказуем.
Работа в команде программистов разительно отличается от работы в футбольной команде, например. Если в последней вам необходимы навыки коммуникации уровня чтения тела своего партнера чтобы вовремя выдать или поймать пас, то…
… в командной работе над сложным проектом бОльшая часть "магии" заключается в ловком жонглировании техлидом задач и зон ответственности между программистами с целью минимального их пересечения друг с другом.
Я бы сравнил это с рисованием картин: вы конечно можете загрузить трех художников на один холст и самозабвенно наблюдать за тем как они болтают между собой больше, чем рисуют… а можете выдать им три отдельных холста и общую рамку, обязав каждого в нее вписаться.
Непонятно зачем тратить время на пересказ того, что им уже и так известно из чтения резюме. Непонятно зачем и нужно ли подготавливать отдельную историю на такой случай. Когда технарю "непонятно зачем" он впадает в ступор, ступор выражается не остановкой двигательной и речевой функции, а попыткой обдумать и понять зачем им это. В случае если технарь уже собаку съел на собеседованиях, он, конечно, сразу задаст уточняющий вопрос. Ну а если нет, то не сразу.
Понимать ТЗ, вычленять из него непонятное и невозможное — пожалуй, одна из самых тяжелых задач в нашей работе. Неудивительно что мозг изо-всех сил старается спрыгнуть с нее, начиная с обвинений в адрес менеджера, заканчивая увольнением. Вопрос "что конкретно непонятно?" то тут непричем, заданный в другом контексте при других условиях он может открыть скрытое и сэкономить время.
Совсем в общих чертах и буллет поинтах вы уже это написали в резюме. Значит немного подробнее чем там.
"Что и где конкретно подробнее вы хотите узнать?"
Собеседующие, которых раздражают встречные вопросы, могли бы задуматься о собственном софт-скилле.
а расскажите о вашем сервисе
Конкретные вопросы не вызывают ступор у технарей. Цимес ситуации в том, что спрашивающий будет оценивать не сам сервис, и не скиллы которые были использованы (хотя изо всех сил будет делать вид что он оценивает именно это). Он будет оценивать складность выдаваемых предложений, их "мелодичность" звучания. А это далеко не самое важное для программиста.
В любом случае человек который может объяснить что он делает при прочих равных полезнее человека который может сделать чёрный ящик, а объяснить не может (магия что ли?).
Утверждая что-то на 100% вы автоматически падаете в ошибку определенности. Вот мне мой опыт показывает мне что существуют очень талантливые в своей сфере люди, не обладающие даже средним навыком коммуникации. Сконтачиться с такими людьми, включить их в процесс и заработать вместе с ними денег — задача босса.
Забавно что мой проект изначально назывался Black Box ^_^
Черные ящики на то и чёрные, что вам не нужно лезть к ним внутрь, чтобы ими пользоваться.
Навыки подобного рода, как и навыки программирования — можно изучать бесконечно. Это два океана слабо связанных друг с другом. Вопрос лишь в том каких навыков вам не хватает в данный период вашей жизни.
Например приходит к вам на собеседование технарь с 10 летним стажем работы и вы чувствуете что диалог как-то не вяжется. Здесь у вас грубо говоря развилка:
— вы можете оценить его софт-скилл как недостаточно высокий для вашей фирмы
— вы можете задуматься о том, что этому человеку каким-то образом хватало его софт-скилла все эти годы
Если вы хотите софт-скилл, то его все-таки как-то надо проверять.
Если я хочу от кандидата на должность исполнителя высокий софт-скилл, то у меня автоматически возникают вопросы относительно моего. Желание же обычного софт-скилла естественно к любым людям, не только к кандидатам. Измерить его с приемлемой точностью за пару часов разговоров, разумеется, нельзя. Можно только отсеять совершенно неспособных к коммуникации. Главное не спутать их с медленно отвечающими и задающими уточняющие вопросы.
у меня возникает вопрос, а сможет ли такой человек на позиции синьора объяснить джуну, хотя бы не «как», но «зачем» нужно нормализовать вот в этом месте, и нужно ли вообще?
В наших головах разные ожидания от синьора. Я не ожидаю от синьора просветительской деятельности, такие ожидания у меня есть к тимлиду, задача которого по сути — "родить одного ребенка" силами нескольких программистов за два месяца. Вот с него требовать высоких коммуникативных навыков — естественно. Синьор же вместо того чтобы тратить своё время на разжёвывание очевидных для него вещей другому человеку пойдет и сделает это сам, а если у него нет на это времени или желания — поставит задачу джуну (или отклонит его пулл-реквест с минимальным комментарием) и пускай джун сам пытается понять что и почему не понравилось синьору, проводит исследование, раскачивает собственное мышление. И дело тут не в коммуникативных навыках синьора, они у него могут быть любой величины, а дело в том чтобы не формировать у джунов зависимость от авторитета, из-за которой они меньше думают своей головой, больше полагаясь на "ну этот умный парень мне сейчас поможет". "Умный парень" в такой ситуации слишком часто отвлекается на просветительскую деятельность, которая у него прокачана не так сильно как скилл программирования, в результате его общая производительность падает.
Кратко:
— обучать программированию != программировать
— есть вариант не экономить на курсах повышения квалификации для джунов, на которых заточенные на обучение люди будут их прокачивать
— еще есть вариант уволить джуна, неспособного самостоятельно "догнать" те области знаний и навыков, которые требуются
Ну и еще мне не понятно, как можно донести до другого человека собственный опыт, полученный не из лекций в университете, не из статей на хабре, не из документации или роликах на ютюбе и не из разговоров с другими людьми. Опыт, полученный в результате реальной работы, проб и ошибок и их исправления — непередаваем языком.
Иными словами:
— джун нуждается в информации — даешь джуну ссылку на нее и пускай он ее исследует, самостоятельно; в этом смысл конвеера, а не в том чтобы постоянно отвлекаться от своих задач, помогая делать чужие,
— джун нуждается в опыте — в идеале дать ему аналогичную задачу и показать где расположен аналогичный код, пускай он ее попытается сделать, пускай неправильно, пусть набьет шишек и получит свой собственный настоящий опыт; но выдача задач — это задача не программиста, а менеджера или тимлида,
Я пытаюсь вам показать что есть альтернативные пути развития, грубо говоря предлагаемый вами вижн это "техлид", а альтернативный — это "гик". Конечно, обладая сильными софт-скиллами намного проще проходить собеседования и — как следствие — менять места работы как перчатки. Затачиваясь же на технические фишки вместо (в жертву) коммуникативных с одной стороны вы рискуете не найти себе работу сразу после форс-мажорного увольнения, но с другой стороны вы становитесь способны на реализацию систем такой сложности и глубины, которая "техлиду" только снится. Конечно даже эти две ветки условны, ведь реальный скилл зависит не только от выбора между ними, но и от выбора "изучить еще что то новенькое, создать еще что-то интересное" или "посмотреть ютюб, почитать случайные статьи на хабре".
О страхе общения речи вообще не было. Менеджер же не программирует не потому что он боится программировать.
Одно дело, когда вы со своими коллегами сработались и уже много раз обсудили кто что подразумевает под каким шаблоном проектирования, привели так сказать термины к общему знаменателю. Совершенно иное дело когда вы занимаетесь этим на собеседовании с неизвестным человеком в отрыве от реальных задач.
Больше похоже на человека с расстройством аутистического спектра.
Люди склонны обвинять или выдавать диагнозы, когда слабо разбираются в том как мыслят другие люди. Если бы вы немного поварили в голове мысль о том почему одних людей такой вопрос вводит в ступор, когда другие отвечают на него сразу, возможно вы бы начали улавливать эту разницу в подходе к мышлению.
В таком случае компании нужно нанять помимо вас ещё одного личного помощника, который будет переводить с вашего на общекомпанейский.
Тут вы совершенно верно уловили идею о конвеере. Одно дело — клепать детали, совершенно иное дело — учить клепать детали. И третье дело — координировать весь конвеер. И мне кажется странным, когда фирма отбирает человека, способного учить клепать детали на позицию клепальщика. Клепание в данном примере — ужасный выбор, поскольку клепать определенную деталь можно научиться в ограниченное время, а вот учиться программировать можно всю жизнь.
Если вы очень крутой рокстар в своей области — и это область нужна компании, то может так она и сделает.
Пытаюсь донести что вот эту самую крутость невозможно оценить за собеседование.
это конечно же показатель его высоких софт-скиллов, что он легко и непринуждённо настроился вашу волну и увлёк разговором на по сути отвлечёную тему
Добавляя сарказм в предложение вы затрудняете понимание идеи, которую пытаетесь донести. Вот я и не понял причем тут софт-скилл одного человека, история про которого была встроена просто для того чтобы показать что бывают исключения.
Знание шаблонов ближе с софт-скилам — это способ быстро и однозначно объяснить или понять подход к решению задачи.
Возможно вы имели в виду знания названий шаблонов, а не знания шаблонов. Но даже в этом случае я не могу с вами согласиться, для меня очевидно, что невозможно быстро и однозначно объяснить\понять подход к решению задачи, используя термины, под которыми в свёрнутом состоянии лежат довольно много нюансов, причем свернуты они в разных головах по разному. Поэтому я предпочитаю пожертвовать быстротой в пользу разжевывания нюансов.
Вы перекинулись из крайности в крайность, упустив формулировку "сильный софт-скилл". Возможно это я недостаточно ее развернул? Сильный софт-скилл в моём понимании — это когда ты не только связываешь множество предложений, но еще и улавливаешь то что пытаются тебе сказать люди, не обладающие таким высоким навыком коммуникации. Иными словами — навык, необходимый менеджеру, а не программисту. Конечно бывают люди обладающие и тем и другим, но разговор то сейчас не о них. Или вы нацелены на то чтобы любой программист в вашей фирме мог заменить любого менеджера и наоборот?
Забавно что вы сформулировали результат "так и не смогли" вместо "он так и не смог".
Простите мне моё занудное любопытство, а было ли в трудовом договоре что-то отражено на тему обязанностей быть чистым и вкусно пахнуть?
Если да — то всё верно.
Если нет — то произошла лютая социальная игра в которой одни люди, не обладающие достаточным высоким коммуникативным навыком, чтобы переубедить других людей вкусно пахнуть… выперли этих самых людей ради своего удобства.
Так я обращаю внимание не на конкурирование навыка (умение связно излагать мысли) с процессом получения навыка (выучивание очередного фреймворка), а на конкурирование процесса получения навыка (курсы коммуникации) с процессом получения навыка (выучивание очередного фреймворка). Время не бесконечно, иногда приходится выбирать одно, условно принося в жертву другое. Можно конечно и за двумя зайцами гнаться, бывает даже что у кого-то это получается, но опять же за счет чего-то третьего, от чего пришлось отказаться. Мне кажется что степень\глубина специализации обратно коррелирует с числом этих самых специализаций. Конечно, бывают исключения.
Что касается "умения связно излагать свои мысли" это дико субъективная штука. Вам может казаться что кандидат не может излагать связно, а вашему компаньону может показаться наоборот, потому что в его голове есть некоторые знания и связи, благодаря которым он автоматически достраивает излагаемую историю до связанной.
Прежде чем делать выводы о каком-то человеке я стараюсь сперва разузнать о нем как можно больше, захожу в профиль на хабре например, просматриваю публикации. Чего и вам желаю ;)
Опыт организации команды у меня всего один, опытов обзора организаций команд — много. Вы почему-то не замечаете разницы в моих понятиях "высокий коммуникативный навык" (высокий софт-скилл) и коммуникация между технарями. Технарю с технарем договориться на много порядков проще, чем с кем-либо еще. Поэтому, в моем вижне, этот кто-либо еще должен обладать высоким коммуникативным навыком, а не технарь, потому что иначе технарь уже не будет технарем, а станет смесью двух разных миров.
Тимлид должен знать весь проект, должен знать где копнуть чтобы вспомнить детали. Это вполне реально когда ты ведешь проект с нуля, спроектировал архитектуру и читаешь почти в реальном времени все приходящие в него коммиты. Если же проект не твоего авторства, то приходится выделить некоторое время на его изучение, чтение кода, мало кому это приятно. В процессе чтения этого кода у тимлида могут возникнуть вопросы "почему так, а не эдак", но и здесь нет проблем, поскольку он обладает высоким коммуникативным навыком, в отличие от окружающих его программистов, которые могут себе позволить сосредоточиться на технических аспектах задачи, будучи изолированными от общения с заказчиком и, возможно, менеджером. С одной стороны такая конфигурация создает дополнительную нагрузку на тимлида в те моменты, когда ее можно было бы избежать, с другой стороны у проекта падает градус шизофрении за счет общего центра, принимающего все важные ключевые решения в технической плоскости.
Пожалуй, я не достаточно конкретно выразился. Это совет тем фирмам, которые нацелены на найм именно лучшего, а не подходящего. Ведь бюджета то у них хватает на собеседования со всеми желающими? Вот в этом моменте они могли бы подвложиться для того чтобы достичь лучших результатов. К тому же большая часть кандидатов отвалится на моменте с половиной ставки без гарантий быть нанятым. А те кандидаты что останутся с большой вероятностью отработают вложенный в них бюджет.
А те кому достаточно просто подходящего могут продолжать работать по старинке.
То что воспринимается как "нытье" на низком уровне, может быть переосмыслено как "желание улучшить" на высоком. То что воспринимается как "гнобление" — как конструктивная критика. Приятные на первый взгляд люди часто оказываются манипуляторами. Преобразовать неприятного члена команды в приятного — вот канонический пример высокого софт-скилла, совершенно не подвластного технарям.
Вам непонятна жертва потому что вы подразумеваете что-то под софт скиллами, а я веду речь про высокие софт скиллы, сильный навык коммуникации, которому, действительно, обучаются если не "за партой", то хотя бы за деньги и тратя уйму личного времени. Нежелание прокачивать коммуникативный навык действительно присутствует, особенно когда технаря манит альтернатива в виде очередной технологии или вкусной задачи.
То что они общаются совершенно не означает что они обладают высокими коммуникативными навыками. Человек существо социальное, найдет время и повод на общение в любой ситуации, тем более рабочей. Нужно ли обращать ваше внимание на то сколько общения тратится на рабочие вопросы, а сколько на нерабочие?.. околорабочие?...
Программист программиста поймет с большей вероятностью, чем, например, продажника или менеджера или еще кого угодно, кто думает не в технической плоскости. Коммуникация между технарями — это отдельный подвид коммуникации, оценить который затруднительно человеку с социальным мышлением.
Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним. Вот тут и ответ. Отсутствие шизофрении полезно и в коде и в произведении. Количество фильмов с одним или несколькими сценаристами. И так далее. Конечно, бывают исключения.
Это здорово, когда в команде есть авторитет по какому-то важному критичному в данный момент вопросу. Он придет на помощь и поможет, задача закроется в срок, все будут довольны. Но бывает что возникает противоположная ситуация: нужно реализовать нечто и никто не знает как это делать. Вот в такие моменты проявляется истинная сущность программиста: будет ли он последовательно отвлекать всех членов команды в надежде что они ему помогут, собирать консилиум и тратить уйму общего времени или… решит сперва самостоятельно исследовать вопрос с помощью своего мозга и интернета. На самом деле здесь нет правильного ответа, оптимальный путь лежит где то между ними.
Обучение новичков, код ревью — это к тимлиду.
"Особенности того что он сделал" вполне реально изучить самостоятельно, используя систему контроля версий, было бы желание. Но желания изучать самостоятельно нет, чтение чужого кода для большинства людей — сущий ад, вместо этого есть желание сэкономить мыслетопливо, спросив словами и получив ответ успокоиться. Здорово когда эта коммуникация происходит в рабочее время, а не когда один из разрабов попивает коктель на берегу теплого моря. Не здорово то, что эта коммуникация отвлекает одного из программистов от его текущей задачи, в результате чего он, после этой коммуникации, тратит дополнительно +- 23 минуты на то чтобы погрузиться обратно в свою задачу.
Отношения к кандидату как королеве и не ожидается, достаточно того чтобы собеседующий прочитал резюме, обновил информацию в своей краткосрочной памяти минут за пять до собеседования. В противном случае складывается впечатление что либо вы в принципе не интересны этому человеку, либо он не способен организовать свой график таким образом, чтобы минимизировать трату своего и чужого времени. Что сходу в лучшем случае демотивирует, в худшем может быть воспринято как неуважение, результат предсказуем.
Работа в команде программистов разительно отличается от работы в футбольной команде, например. Если в последней вам необходимы навыки коммуникации уровня чтения тела своего партнера чтобы вовремя выдать или поймать пас, то…
… в командной работе над сложным проектом бОльшая часть "магии" заключается в ловком жонглировании техлидом задач и зон ответственности между программистами с целью минимального их пересечения друг с другом.
Я бы сравнил это с рисованием картин: вы конечно можете загрузить трех художников на один холст и самозабвенно наблюдать за тем как они болтают между собой больше, чем рисуют… а можете выдать им три отдельных холста и общую рамку, обязав каждого в нее вписаться.
Непонятно зачем тратить время на пересказ того, что им уже и так известно из чтения резюме. Непонятно зачем и нужно ли подготавливать отдельную историю на такой случай. Когда технарю "непонятно зачем" он впадает в ступор, ступор выражается не остановкой двигательной и речевой функции, а попыткой обдумать и понять зачем им это. В случае если технарь уже собаку съел на собеседованиях, он, конечно, сразу задаст уточняющий вопрос. Ну а если нет, то не сразу.
Понимать ТЗ, вычленять из него непонятное и невозможное — пожалуй, одна из самых тяжелых задач в нашей работе. Неудивительно что мозг изо-всех сил старается спрыгнуть с нее, начиная с обвинений в адрес менеджера, заканчивая увольнением. Вопрос "что конкретно непонятно?" то тут непричем, заданный в другом контексте при других условиях он может открыть скрытое и сэкономить время.
Это всё уже есть в резюме, потому и ступор. Не хочется повторять то что уже и так перед глазами.
"Что и где конкретно подробнее вы хотите узнать?"
Собеседующие, которых раздражают встречные вопросы, могли бы задуматься о собственном софт-скилле.
Конкретные вопросы не вызывают ступор у технарей. Цимес ситуации в том, что спрашивающий будет оценивать не сам сервис, и не скиллы которые были использованы (хотя изо всех сил будет делать вид что он оценивает именно это). Он будет оценивать складность выдаваемых предложений, их "мелодичность" звучания. А это далеко не самое важное для программиста.
Утверждая что-то на 100% вы автоматически падаете в ошибку определенности. Вот мне мой опыт показывает мне что существуют очень талантливые в своей сфере люди, не обладающие даже средним навыком коммуникации. Сконтачиться с такими людьми, включить их в процесс и заработать вместе с ними денег — задача босса.
Забавно что мой проект изначально назывался Black Box ^_^
Черные ящики на то и чёрные, что вам не нужно лезть к ним внутрь, чтобы ими пользоваться.
Навыки подобного рода, как и навыки программирования — можно изучать бесконечно. Это два океана слабо связанных друг с другом. Вопрос лишь в том каких навыков вам не хватает в данный период вашей жизни.
Например приходит к вам на собеседование технарь с 10 летним стажем работы и вы чувствуете что диалог как-то не вяжется. Здесь у вас грубо говоря развилка:
— вы можете оценить его софт-скилл как недостаточно высокий для вашей фирмы
— вы можете задуматься о том, что этому человеку каким-то образом хватало его софт-скилла все эти годы
Если я хочу от кандидата на должность исполнителя высокий софт-скилл, то у меня автоматически возникают вопросы относительно моего. Желание же обычного софт-скилла естественно к любым людям, не только к кандидатам. Измерить его с приемлемой точностью за пару часов разговоров, разумеется, нельзя. Можно только отсеять совершенно неспособных к коммуникации. Главное не спутать их с медленно отвечающими и задающими уточняющие вопросы.
В наших головах разные ожидания от синьора. Я не ожидаю от синьора просветительской деятельности, такие ожидания у меня есть к тимлиду, задача которого по сути — "родить одного ребенка" силами нескольких программистов за два месяца. Вот с него требовать высоких коммуникативных навыков — естественно. Синьор же вместо того чтобы тратить своё время на разжёвывание очевидных для него вещей другому человеку пойдет и сделает это сам, а если у него нет на это времени или желания — поставит задачу джуну (или отклонит его пулл-реквест с минимальным комментарием) и пускай джун сам пытается понять что и почему не понравилось синьору, проводит исследование, раскачивает собственное мышление. И дело тут не в коммуникативных навыках синьора, они у него могут быть любой величины, а дело в том чтобы не формировать у джунов зависимость от авторитета, из-за которой они меньше думают своей головой, больше полагаясь на "ну этот умный парень мне сейчас поможет". "Умный парень" в такой ситуации слишком часто отвлекается на просветительскую деятельность, которая у него прокачана не так сильно как скилл программирования, в результате его общая производительность падает.
Кратко:
— обучать программированию != программировать
— есть вариант не экономить на курсах повышения квалификации для джунов, на которых заточенные на обучение люди будут их прокачивать
— еще есть вариант уволить джуна, неспособного самостоятельно "догнать" те области знаний и навыков, которые требуются
Ну и еще мне не понятно, как можно донести до другого человека собственный опыт, полученный не из лекций в университете, не из статей на хабре, не из документации или роликах на ютюбе и не из разговоров с другими людьми. Опыт, полученный в результате реальной работы, проб и ошибок и их исправления — непередаваем языком.
Иными словами:
— джун нуждается в информации — даешь джуну ссылку на нее и пускай он ее исследует, самостоятельно; в этом смысл конвеера, а не в том чтобы постоянно отвлекаться от своих задач, помогая делать чужие,
— джун нуждается в опыте — в идеале дать ему аналогичную задачу и показать где расположен аналогичный код, пускай он ее попытается сделать, пускай неправильно, пусть набьет шишек и получит свой собственный настоящий опыт; но выдача задач — это задача не программиста, а менеджера или тимлида,
Я пытаюсь вам показать что есть альтернативные пути развития, грубо говоря предлагаемый вами вижн это "техлид", а альтернативный — это "гик". Конечно, обладая сильными софт-скиллами намного проще проходить собеседования и — как следствие — менять места работы как перчатки. Затачиваясь же на технические фишки вместо (в жертву) коммуникативных с одной стороны вы рискуете не найти себе работу сразу после форс-мажорного увольнения, но с другой стороны вы становитесь способны на реализацию систем такой сложности и глубины, которая "техлиду" только снится. Конечно даже эти две ветки условны, ведь реальный скилл зависит не только от выбора между ними, но и от выбора "изучить еще что то новенькое, создать еще что-то интересное" или "посмотреть ютюб, почитать случайные статьи на хабре".
О страхе общения речи вообще не было. Менеджер же не программирует не потому что он боится программировать.
Одно дело, когда вы со своими коллегами сработались и уже много раз обсудили кто что подразумевает под каким шаблоном проектирования, привели так сказать термины к общему знаменателю. Совершенно иное дело когда вы занимаетесь этим на собеседовании с неизвестным человеком в отрыве от реальных задач.
Люди склонны обвинять или выдавать диагнозы, когда слабо разбираются в том как мыслят другие люди. Если бы вы немного поварили в голове мысль о том почему одних людей такой вопрос вводит в ступор, когда другие отвечают на него сразу, возможно вы бы начали улавливать эту разницу в подходе к мышлению.
Тут вы совершенно верно уловили идею о конвеере. Одно дело — клепать детали, совершенно иное дело — учить клепать детали. И третье дело — координировать весь конвеер. И мне кажется странным, когда фирма отбирает человека, способного учить клепать детали на позицию клепальщика. Клепание в данном примере — ужасный выбор, поскольку клепать определенную деталь можно научиться в ограниченное время, а вот учиться программировать можно всю жизнь.
Пытаюсь донести что вот эту самую крутость невозможно оценить за собеседование.
Добавляя сарказм в предложение вы затрудняете понимание идеи, которую пытаетесь донести. Вот я и не понял причем тут софт-скилл одного человека, история про которого была встроена просто для того чтобы показать что бывают исключения.
Возможно вы имели в виду знания названий шаблонов, а не знания шаблонов. Но даже в этом случае я не могу с вами согласиться, для меня очевидно, что невозможно быстро и однозначно объяснить\понять подход к решению задачи, используя термины, под которыми в свёрнутом состоянии лежат довольно много нюансов, причем свернуты они в разных головах по разному. Поэтому я предпочитаю пожертвовать быстротой в пользу разжевывания нюансов.
Вы перекинулись из крайности в крайность, упустив формулировку "сильный софт-скилл". Возможно это я недостаточно ее развернул? Сильный софт-скилл в моём понимании — это когда ты не только связываешь множество предложений, но еще и улавливаешь то что пытаются тебе сказать люди, не обладающие таким высоким навыком коммуникации. Иными словами — навык, необходимый менеджеру, а не программисту. Конечно бывают люди обладающие и тем и другим, но разговор то сейчас не о них. Или вы нацелены на то чтобы любой программист в вашей фирме мог заменить любого менеджера и наоборот?
Забавно что вы сформулировали результат "так и не смогли" вместо "он так и не смог".