Comments 320
«Что конкретно вы хотите обо мне узнать?» — обычно отвечаю я и наблюдаю разочарование в глазах босса
Извините за откровенность, но какая-то инфантильная реакция со стороны автора.
Что мешало заранее (ведь вы идёте на собеседование) подготовить краткий спич на тему "Расскажите о себе"? Ничего не мешало.
Это нормально. И продумать свой ответ на этот вопрос заранее – это нормальная практика взрослых людей.
Дальше вы пишете, что за полтора часа невозможно оценить коммуникативные навыки, ведь "все мы на собеседованиях открыты и адекватны".
Так вот нет же. Вы приходите на собеседование и буквально за пять минут я вижу, что не хочу брать на работу человека, который изначально стоит в позе обиженного и вряд ли отвечает командному запросу на адекватность. Всё просто. "Вы не подходите, мы вас перезвоним". Но вина на львиную долю полностью ваша.
Я могу подготовить краткие спичи на множество разных вопросов. На множество, но не на все. Пытаюсь донести до вас идею о том что оценка этих кратких спичей в собеседовании на позицию программиста дает вам очень мало пользы, поскольку задача программиста — программировать, а не кратко-спичить.
Оценивать уточняющие вопросы как инфантильность тоже не сильно вам помогает в поиске реально мыслящих людей. С моей стороны инфантильно выглядит спихивание вины.
задача программиста — программировать, а не кратко-спичить
Это простая и понятная мысль. И логичная.
Но не хочется брать к себе человека, который на вопрос "Вась, как ты вот это делал?" будет каждый раз ворчать "Я программист! Я не обязан объяснять, я могу сделать и всё!"
А именно такой потенциал я вижу в вас, как в моём потенциальном коллеге. Оно нам надо?
Я не HR, а очень даже рядовой Если КонецЕсли.
На такой вопрос я бы ответил уточнением (что конкретно непонятно? а что ты уже понял?), а не отказом, но дискуссия то не обо мне. И было бы здорово если бы дискуссия осталась в плоскости идей, не переходя на личности.
Идея то о том, что человек с техническим складом ума и продвинутыми навыками программирования чаще испытывает затруднения в объяснении и передаче навыка, чем непосредственно в реализации, и чем другие люди со складом ума, заточенным на коммуникацию. И в результате собеседований (оценивающих в основном коммуникационные навыки) такие "технари" отсеиваются в пользу более продвинутых "болтунов". Результаты не очень: фирма не находит потенциал (не видя его), а технарь вынужден прокачиваться на курсах "как пройти собеседование", вместо того чтобы изучить дополнительную технологию или решить задачу.
Вместо вопроса "кто виноват?", вопроса, который мгновенно схлопывает проблему до объяснения и ставит в тупик, я предлагаю задуматься над вопросом "что делать?".
Изменить отношение к собеседованиям.
Это неизбежно, что там надо рассказать о себе и хоть что-то озвучить. Работодатель не может брать на работу ходячий компилятор. Работодатель ищет человека.
что конкретно непонятно?
Не надо так.
У меня тут был проект, в котором было совершенно у***щное ТЗ.
Я пришел к менеджеру с уведомлением, что я не понимаю это ТЗ.
И она задала этот самый вопрос:
«что конкретно непонятно? скажи, я спрошу у заказчика.»
А я не могу на это ответить. Потому что всё ТЗ говно. Я не могу сформулировать вопрос вида «Вот здесь не понятно и вот здесь не понятно», за короткий промежуток времени.
В итоге я просто две недели из этого «ТЗ» вычленял какие-то кусочки логики и на их основе писал отдельно формальное ТЗ. И это ТЗ мы потом отдельно утверждали.
Понимать ТЗ, вычленять из него непонятное и невозможное — пожалуй, одна из самых тяжелых задач в нашей работе. Неудивительно что мозг изо-всех сил старается спрыгнуть с нее, начиная с обвинений в адрес менеджера, заканчивая увольнением. Вопрос "что конкретно непонятно?" то тут непричем, заданный в другом контексте при других условиях он может открыть скрытое и сэкономить время.
Задача формирования ТЗ — это отдельная важная задача и на начало проекта ТЗ должно быть в адекватном виде. Как вообще можно брать проект в работу с неформализованным ТЗ?
Те кто собеседует — тоже люди, и они не могут только сухие тех данные спрашивать. Более того не у всех их есть четкий план собеседования и поэтому берутся стандартные вопросы "о себе". Если говорить про hr, то там вообще каша, только что секретаря смотрели, а сейчас программиста.
Одни не умеют грамотно презентоваться, другие — грамотно собеседовать. Но каждый найдет что-нибудь.
Решение: любой вопрос — узнать больше информации о человеке, не любой провал — отказ.
Нечего сказать о себе — есть более важные плюсы, кому надо увидит.
2) а) Для задачи найти лучшего — устраиваем хакатон, если позиция требует уникальных навыков и оригинальных технологических решений или б) на рядовую позицию — просто экзамен, где в качестве заданий — уже решённые в данной компании бизнес-проблемы и вопросы на нетривиальную логику, чтобы отсечь гугл-программистов (не бывших сотрудников гугла, а злоупотребляющих поиском)
Да-да. У меня был коллега DBA, который как-то приходит утром, и говорит: чуваки, а давайте нашу БД разделим на две? А потом мы вдвоем пытались из него часа четыре вытянуть, а какой же профит он хотет получить от разделения? Так и не смогли…
Что характерно — этот профит на самом деле существует и вполне выражается в двух-трех предложениях, а дальше уже можно обсуждать, сравнивать преимущества и недостатки, и т.п.
Должен ли программист, который претендует быть синьором, или даже архитектором, уметь связать два предложения, или это уже слишком длинный спич?
Вы перекинулись из крайности в крайность, упустив формулировку "сильный софт-скилл". Возможно это я недостаточно ее развернул? Сильный софт-скилл в моём понимании — это когда ты не только связываешь множество предложений, но еще и улавливаешь то что пытаются тебе сказать люди, не обладающие таким высоким навыком коммуникации. Иными словами — навык, необходимый менеджеру, а не программисту. Конечно бывают люди обладающие и тем и другим, но разговор то сейчас не о них. Или вы нацелены на то чтобы любой программист в вашей фирме мог заменить любого менеджера и наоборот?
Забавно что вы сформулировали результат "так и не смогли" вместо "он так и не смог".
>Конечно бывают люди обладающие и тем и другим, но разговор то сейчас не о них.
Почему не? На мой взгляд, вопрос в том, сколько у человека того и другого. Потому что такие, кто вообще не может связать пару слов, вряд ли нужны.
>Забавно что вы сформулировали результат «так и не смогли» вместо «он так и не смог».
Э… ну на самом деле, цель была в какой-то степени прокачать его софт скилл, потому что мы-то для себя поняли профит предложения. И пытались лишь добиться, чтобы коллега его сформулировал словами. Мы не достигли своей цели, а он не смог сформулировать.
Если вы хотите софт-скилл, то его все-таки как-то надо проверять.
Если я хочу от кандидата на должность исполнителя высокий софт-скилл, то у меня автоматически возникают вопросы относительно моего. Желание же обычного софт-скилла естественно к любым людям, не только к кандидатам. Измерить его с приемлемой точностью за пару часов разговоров, разумеется, нельзя. Можно только отсеять совершенно неспособных к коммуникации. Главное не спутать их с медленно отвечающими и задающими уточняющие вопросы.
у меня возникает вопрос, а сможет ли такой человек на позиции синьора объяснить джуну, хотя бы не «как», но «зачем» нужно нормализовать вот в этом месте, и нужно ли вообще?
В наших головах разные ожидания от синьора. Я не ожидаю от синьора просветительской деятельности, такие ожидания у меня есть к тимлиду, задача которого по сути — "родить одного ребенка" силами нескольких программистов за два месяца. Вот с него требовать высоких коммуникативных навыков — естественно. Синьор же вместо того чтобы тратить своё время на разжёвывание очевидных для него вещей другому человеку пойдет и сделает это сам, а если у него нет на это времени или желания — поставит задачу джуну (или отклонит его пулл-реквест с минимальным комментарием) и пускай джун сам пытается понять что и почему не понравилось синьору, проводит исследование, раскачивает собственное мышление. И дело тут не в коммуникативных навыках синьора, они у него могут быть любой величины, а дело в том чтобы не формировать у джунов зависимость от авторитета, из-за которой они меньше думают своей головой, больше полагаясь на "ну этот умный парень мне сейчас поможет". "Умный парень" в такой ситуации слишком часто отвлекается на просветительскую деятельность, которая у него прокачана не так сильно как скилл программирования, в результате его общая производительность падает.
Кратко:
— обучать программированию != программировать
— есть вариант не экономить на курсах повышения квалификации для джунов, на которых заточенные на обучение люди будут их прокачивать
— еще есть вариант уволить джуна, неспособного самостоятельно "догнать" те области знаний и навыков, которые требуются
Ну и еще мне не понятно, как можно донести до другого человека собственный опыт, полученный не из лекций в университете, не из статей на хабре, не из документации или роликах на ютюбе и не из разговоров с другими людьми. Опыт, полученный в результате реальной работы, проб и ошибок и их исправления — непередаваем языком.
Иными словами:
— джун нуждается в информации — даешь джуну ссылку на нее и пускай он ее исследует, самостоятельно; в этом смысл конвеера, а не в том чтобы постоянно отвлекаться от своих задач, помогая делать чужие,
— джун нуждается в опыте — в идеале дать ему аналогичную задачу и показать где расположен аналогичный код, пускай он ее попытается сделать, пускай неправильно, пусть набьет шишек и получит свой собственный настоящий опыт; но выдача задач — это задача не программиста, а менеджера или тимлида,
Ну и еще мне не понятно, как можно донести до другого человека собственный опыт, полученный не из лекций в университете, не из статей на хабре, не из документации или роликах на ютюбе и не из разговоров с другими людьми. Опыт, полученный в результате реальной работы, проб и ошибок и их исправления — непередаваем языком.
Т.е. статьи на хабре, разговоры, книжки и ролики получаются из других разговоров, статей, книжек и роликов и никак не из опыта.
А первую статью, книжку, разговор или ролик нам передал бог или инопланетяне!
Ну и еще мне не понятно, как можно донести до другого человека собственный опыт, полученный не из лекций в университете, не из статей на хабре, не из документации или роликах на ютюбе и не из разговоров с другими людьми. Опыт, полученный в результате реальной работы, проб и ошибок и их исправления — непередаваем языком.
Мне начинает казаться, что вы троллите.
Садишься, включаешь мозг, ищешь зависимости, формулируешь их словами. Чуть погодя уточняешь формулировки. То же программирование по сути, только язык человеческий.
А можно не готовить спичи. Просто научиться импровизировать, перехватывать инициативу, уметь отстаивать и вести свою линию в переговорах. Это не сложно, на самом деле :) но такие навыки очень вручают по жизни, а не только на собеседованиях. Рекомендую.
Навыки подобного рода, как и навыки программирования — можно изучать бесконечно. Это два океана слабо связанных друг с другом. Вопрос лишь в том каких навыков вам не хватает в данный период вашей жизни.
Например приходит к вам на собеседование технарь с 10 летним стажем работы и вы чувствуете что диалог как-то не вяжется. Здесь у вас грубо говоря развилка:
— вы можете оценить его софт-скилл как недостаточно высокий для вашей фирмы
— вы можете задуматься о том, что этому человеку каким-то образом хватало его софт-скилла все эти годы
Что мешало заранее (ведь вы идёте на собеседование) подготовить краткий спич на тему «Расскажите о себе»? Ничего не мешало.
Какой вопрос — такой ответ.
Я о себе могу рассказывать, например, долго — все-таки 40 лет пожил.
Могу в два слова — «я офигенен».
Если контекст не задан — вопрос возвращается вопрошающему: конкретизируй, что ты хочешь узнать.
Так что нет. «Расскажите о себе» — слишком абстрактный запрос, чтобы быть удовлетворенным в рамках часового или даже двухчасового интервью.
Могу в два слова — «я офигенен».
Я думаю, у вас на интервью должно быть предположение о том, что именно интересно о вас знать. Так что вполне можно как-то более конкретнее, нет?
часового или даже двухчасового интервью.
Интервью это не монолог. Спросивший вполне может направить беседу в интересующее его русло.
В том-то и дело, что предположения будут не обоснованы ничем. В разных компаниях ожидают разные "о себе". Кого-то интересует пересказ резюме, кого-то увлечения, семья и т. п. Если интервьювер не обозначает контекст, то говорить что-то — это гадание на кофейной гуще. А с низкими софт-скиллами ещё и не заметишь что говоришь не то, что ожидают, а потом вынесут вердикт "робот, а нам нужен человек" или "рассказал о семье, о хобби, но нафигам нам это — балабол"
А с низкими софт-скиллами ещё и не заметишь что говоришь не то, что ожидают, а потом вынесут вердикт "робот, а нам нужен человек" или "рассказал о семье, о хобби, но нафигам нам это — балабол"
Эти ваши выводы на каких фактах основаны?
Я думаю, у вас на интервью должно быть предположение о том, что именно интересно о вас знать.
Нет. Если человек хочет узнать что-то конкретное — он формулирует это словами через рот.
Мне неинтересно предполагать, догадываться, и вообще, делать за интервьюера его работу.
Мне в конце концов за это не платят, а излагать лишнее, чтобы дать формальную причину докопаться и отказать — тоже не в моих интересах.
Интервью это не монолог.
А перебивать — невежливо (: так что с таким запросом интервьюирующий может просто исчерпать свой лимит времени, не успев больше ничего спросить.
чтобы дать формальную причину докопаться и отказать
Адекватному интервюэру не надо докапываться до чего-то ему нужно понять с кем он беседует и стоит ли его принимать на работу. Специально валить кого-то никому не надо. А если надо, то он вам не нужен, наверное?
А перебивать — невежливо
Ну это по ситуации — можно перебить вежливо да так, что перебиваемому понравится. Мне так рекомендовали делать когда человек завел шарманку, уставился в пространство и нудит что-то свое не обращая внимание на то, что это неинтересно собеседникам.
Специально валить кого-то никому не надо. А если надо, то он вам не нужен, наверное?
Конечно. Но ведь любой стимул вызывает реакцию. Поэтому моя задача — ограничить информацию для интервьюера тем минимумом, который не вызовет у него разнообразных негативных ассоциаций в любом направлении. Поэтому, не спрашивают — не говорим лишнего.
Ну это по ситуации — можно перебить вежливо да так, что перебиваемому понравится.
Ну, это грозит перерасти в битву двух йокодзун. Если интервьюер будет настаивать на семи взаимно параллельных линиях красного цвета прозрачной краской, например. Такого грех не затроллить.
Ну, это грозит перерасти в битву двух йокодзун.
Это зависит от подхода обоих. Если вы сильно нужны, то к вам будут приспосабливаться даже если вы не хотите пойти навстречу. С другой стороны если вы покажете что искренне хотите понять собеседника и рассказать, что он хочет слышать, то вам будет плюс.
А перебивать — невежливо
Надо перебивать вежливо. Например, ребята из Индии будут говорить вечно, т.к. считают если собеседник молчит, значит он хочет услышать больше и будет не вежливо ему в этом отказать.
Детский сад и демагогия.
Собеседование на определённую должность – достаточный уровень конкретизации.
Детский сад и демагогия.
Собеседование на определённую должность – достаточный уровень конкретизации.
Абсолютно нет. В рамках собеседования на определенную должность — все написано в резюме, и вопрос «расскажите о себе» — избыточен. И говорит о том, что интервьюер не утрудился с оным ознакомиться.
А правильные вопросы вот:
— «расскажите о том, что вы считаете своим самым выдающимся достижением на позиции Z?»
— «у вас был интересный опыт в компании Х в году Y — можете рассказать подробнее?»
— «почему вы ушли из компании W? Она достаточно крупный работодатель, туда все стремятся.»
— «в каких прикладных областях вам довелось работать?»
И так далее. Это все про рассказать о себе, но в конкретном аспекте.
Кстати, большинство тех, кто просил рассказать о себе — тратили не более нескольких секунд на конкретизацию, никто пафосно не фыркал про детский сад.
Вы первый. Поздравляю с ачивочкой (:
Кстати, на этом вашем загнивающем западе — нередко роботы и сортируют резюме на входе, да.
Но мы же говорим про первый этап общения с кожаным мешком со стороны зарплатодателя. И «расскажите о себе» без конкретизации — для меня это флажок, что ему пофиг. Примерно такой же флажок, как инвайт на batch interview.
ОБЫЧНО, в резюме более чем достаточно, чтобы не спрашивать «расскажите о себе», а задавать более конкретные вопросы по тому же самому резюме.
Всегда можно найти более конкретный вопрос, который интересует собеседующего, чем «а расскажите что-нибудь, правда понятия не имею интересно ли это мне и относится ли вообще к интервью».
P.S. Если в резюме недостаточно — это уже говорит о качестве резюме.
ОБЫЧНО, в резюме более чем достаточно, чтобы не спрашивать «расскажите о себе», а задавать более конкретные вопросы по тому же самому резюме.
Это если вы в ответе на вопрос "расскажите о себе" ожидает услышать краткий (или развернутый) пересказ резюме. А если, например, вам интересно как человек будет реагировать на такой вопрос: уточнять его, пересказывать резюме, рассказывать о том, что в резюме не упомянуто или начнёт в форме близкой к истерике требовать "точного ТЗ"
Рассказы о себе — неинтересны большинству собеседующих, их на самом деле интересует зачастую конкретный ответ на общий вопрос.
Например я могу рассказать о том что смотрю, читаю, за кого болею — и могу именно за несовпадение личных интересов получить минус. За то что болею не за ту команду, за то что мне нравится не такой жанр музыки или вообще что я решил поговорить о семье, а не о личных пет-проектах.
Почти все жалобы на плохие интервью основаны на плохом опыте и навыке интервьюверов, которые действительно ищут пробелы в знаниях, а не сами знания. Разговорить человека не всегда бывает легко. Поэтому именно в этом контексте общие вопросы только усугубляют дело.
Я вот могу на интервью потратить целых 10 минут разговариваю на тематику, которую я знаю плохо, а собеседуемый очень хорошо. И для себя узнаю что-то полезное, и оценю как глубоко человек разбирается в том, к чему он приложил силы и душу, что он там сделал. И не важно касается это ИТ или каких-либо узкоспециализированных хобби.
которые действительно ищут пробелы в знаниях, а не сами знания.
Когда проводил собесы без "лишних глаз", то просто проходил по списку стэка и спрашивал "Чтоб сэкономить нам время просто скажите, вот что вы не знаете по PHP/MySQL/Docker?". Что назвали уже вообще не лез. Что не назвали — пару-тройку "контрольных", в которых сам плаваю обычно или сильно трудно далось.
Я, помнится, однажды незлобно пошутил над таким вот продуктом двухнедельных курсов по подбору персонала, каждый раз уточняя, на что именно она хотела услышать ответ. Окончание 10-минутного цикла было таким:
— Вы имеете в виду, нравится ли мне ездить на мотоцикле в жару?
— Да, именно это меня интересует.
— Нет, не нравится.
На второй круг девочка пойти не решилась, предложила чай и ушла, а я, в честно заслуженном одиночестве, спокойно дождался технарей.
Работать там я все равно не собирался, пройдясь по офису — шумно и добираться неудобно, терять было нечего, поэтому сделал мир чуть-чуть лучше, раз уж все равно пришел
Почему так все привязались к «Расскажите о себе»?
Потому что в контексте статьи разговор был о том, что такой вопрос задают на техническом интервью, и что из этого выходит
Можете сколько угодно трясти своей ачивкой с той стороны двери. Такие проблемные кандидаты с компостером в голове работодателю не нужны.
Следующий!
Такие проблемные кандидаты с компостером в голове работодателю не нужны.
Ну, это вам лично не нужны ) а практика показывает — что сбегаются как миленькие, и в очередь стоят. Поэтому зарплатодателей сортируем на адекватных и с хлебушком в голове.
Что ставит под сомнение ваш постулат о проблемности. Вы, кстати, его и аргументировать не потрудились, съехали на эмоциях. Что для нанимающего очень непрофессионально (:
Я не HR, я погромист.
Но я первым бы сказал менеджеру, что такого кандидата-демагога, который устраивает дискуссию вокруг стандартной фразы "Расскажите о себе", нам в коллектив не надо, пусть других посмотрит.
Да-да, вы правы. Но вас по-прежнему плохо слышно с той стороны проходной.
Такие проблемные кандидаты с компостером в голове работодателю не нужны.
Это только доказывает, что выросшие из разработчиков руководители, не умеющие в софт скиллы, могут быть еще хуже в управлении персоналом, чем HR-менеджеры.
Извините за переход на личности, могу и ошибаться.
Отсутствие софт-скиллов и обычной адекватности демонстрирует кандидат, устраивающий демагогическую лекцию в ответ на стандартный вопрос собеседования.
Хороший технарь, умеющий в софт скиллы — это слишком фантастичная и дорогая вещь, чтобы ее ожидать в массовом применении.
Самопрезентация — один из из софт-скиллов. Особенно понимание какая форма и содержание самопрезентации должны быть в той или иной ситуации, плюс снятие невербальной обратной связи со слушателей и корректировка на лету.
Как все плохо
Я не требую. Но моё общее впечатление будет от них зависеть. Нет такого, "он скучно о себе рассказал — вычеркиваем". Но вот "никакой он какой-то, просто пилит таски по очереди похоже, ничего не сказал, что хоть раз инициативу где-то проявил — лучше возьмём Петю, хоть по технике он и похуже немного, но может улучшить нам процессы, как улучшал их в X или ему интересно поддерживать зависимости в актуальном состоянии, а у нас сейчас все отнекиваются — вот ему и поручим".
Самопрезентация — один из из софт-скиллов.
При этом наличие данного скилла ничего говорит о наличии других софт-скиллов. Как и наоборот.
А как мы дошли до того что умение ответить на вопрос «расскажите о себе» стало «умение в софт скиллы»?
По сути, для технарей уровня программистов — уметь внятно отвечать на любые вопросы не о коде это именно софт скиллы. А тем более на такие абстрактные вопросы
Да даже о коде другому программисту, уровня знаний которого ты не знаешь.
Когда начали утверждать, что софт-скиллы ему не нужны. По крайней мере в объёме большем чем требуется, чтобы общей гражданской дееспособности не лишиться.
Тихо, тихо, ну что вы пугаете ребят?
Они сейчас ложку уронят и соплями всё измажут.
– Сиди, Васечка, программируй, не плачь. Дядя плохой, дядя грубый! Дядя хочет, чтобы мы с людьми разговаривали, изверг!
Прийти на работу в чистой одежде и чтобы не воняло это тоже отдельный скилл? Может нужны курсы «повышения гигиены»? И этот скилл действительно не нужен программисту в вакууме. И некоторые без него обходятся. Только это нифига не норма.
Как ни странно, за свою карьеру знаю как минимум двух человек, которых уволили именно за это. Воняли и не мылись. Один был средний специалист, другой крутой. Но на команду влияли плохо, митинги превращались в «поскорее бы сбежать».
Может на удаленке им будет жить лучше.
Простите мне моё занудное любопытство, а было ли в трудовом договоре что-то отражено на тему обязанностей быть чистым и вкусно пахнуть?
Если да — то всё верно.
Если нет — то произошла лютая социальная игра в которой одни люди, не обладающие достаточным высоким коммуникативным навыком, чтобы переубедить других людей вкусно пахнуть… выперли этих самых людей ради своего удобства.
Я знал несколько человек, у которых от природы вонючий пот. И при этом никаких проблем с ними не было, потому что они просто следили за собой.
И какие проблемы в том, чтобы выпереть нескольких людей ради удобства большинства? Это нормально.
По моему ничего сложного, ответьте в несколько предложений: «Писал на этом и на этом, опыт столько-то лет, последний проект такой-то»
а) ответы на первое и второе УЖЕ есть в резюме
б) конкретно процитированных вами запросов в исходной формулировке (расскажите о себе) не звучало.
зачем я буду додумывать за собеседника и отвечать на то, что не проговорено? (:
И в ваших интересах дать ту информацию, о которой вы готовы поговорить дальше.
Нет. В моих интересах получить необходимый минимум, чтобы принять решение — хочу я проходить собеседование дальше, или отказать.
А когда через 15 минут из запланированного часа тебе говорят "мы вам перезвоним" — это не дичь? Зачем тратить своё и чужое время, если почти сразу понимаешь, что оффер не примешь?
Обычно до очного собеседования есть созвоны с HR с которым можно выяснить много вопросов
Да, но нет. HR — очень хреновый в плане качества источник сведений. В большинстве случаев он может только переозвучить то, что известно публично, плюс — высказать субъективное мнение.
Поэтому необходимый минимум — это дойти хотя бы до первого технического интервью.
Что мешало заранее (ведь вы идёте на собеседование) подготовить краткий спич на тему "Расскажите о себе"? Ничего не мешало.
Зачем? Подготовка к собеседованию — прямой обман работодателя. Это же равносильно тому, что вы пошлете другого человека вместо себя собеседование проходить.
Вы объясните тогда — чем подготовка к собеседованию отличается от прохождения собеседования другим человеком? Почему одно обман, а другое — нет?
С точки зрения фнукционального программиста обман — каждое новое состояние — это другой человек. А с точки зрения объектно-ориентированного — не обман. У человека есть идентичность и состояние. :)
В принципе собеседующий может закладываться на то, что человек может подготовиться и умение подготовиться может быть плюсом — все равно на работу будет ходить третий человек а через месяц четвертый. С точки зрения ФП.
А одеться красивее на свидание это прямой обман потенциального романтического партнера?
Ну привели бы пример тогда с косметикой. Обман или нет? А фотошоп?
А одеться красивее на свидание это прямой обман потенциального романтического партнера?
Имхо, но больше да чем нет. Как по мне люди не должны стараться показать себя лучше/иными чем есть. Ведь им потом жить/работать вместе, и с реальным человеком, а не с образом на свидании/собеседовании.
А почему собственно это плохо. Возможно их интересует ваша способность подготовиться?
В таком варианте, да, имеет смысл готовиться. Если фактор способности быстро усвоить/освежить знания один из решающих для найма.
Я не знаю, что там были за задания, но конкретно у меня такие соображения.
В любом случае вряд ли будет 100% попадание в опыт. Грубо говоря, когда вы туда придете там будет куча технологий, которых снаружи просто нет и вам все равно придется чему-то учиться.
Или например, Вася недавно этот алгоритм использовали, а вы использовали несколько другой и у Васи будет преимущество. А Петя вообще не по алгоритмам — у него нет фундаметальных знаний и ему надо университетский курс преподать. Вот чтобы отличить вас с Васей от Пети можно вам дать тему для подготовки, чтобы уменьшить вашу разницу с Васей.
Хотя это может у меня такая работа где все время что-то новое и надо учиться (хотя какой-то маломобильный фундамент помогает), а у вас — заучил на всю жизнь и пользуйся.
Так у него всё равно ведь будет преимущество, потому что он его и на практике попробовал, и разобрался конкретно с ним в теории.
Да, поэтому интересно насколько большая эта разница.
Так если они в работе нужны, а Петя в них не шарит, то, может, ну, он вообще не подходит?
Да, именно чтобы его отбраковать так и надо делать.
А зачем её уменьшать?
Потому, что все равно конкретный алгоритм который нужен будет на работе скорее всего будет отличаться от того, который будет на собеседовании. Важнее ваша способность решать класс задач, а не конкретную задачу. Скорее всего на работе вы будете получать задачи из какого-то класса, возможно гуглить как их люди в принципе решают, выбирать наиболее применимый для вас способ решения и реализовывать.
Так, может, просто на собеседовании дать стихотворение какого-нибудь неизвестного поэта, а через 40 минут его попросить рассказать по памяти?
Это не про память а про способность понять.
И Петя, который никогда эти плюсы в жизни не видел, тоже нагугливает, зачем же нужен виртуальный деструктор, радостно вам оттарабанивает, и все счастливы.
Дальше вы можете проверить, Петя просто воспроизводит текст как попугай или понимает о чем идет речь, например. Ну это, скорее, к джунам.
Для меня это больше обман себя. )
Подготовка к собеседованию — прямой обман работодателяТогда вся жизнь — обман? </грусть>
Я правильно понимаю, что подготовка к собеседованию — это получение знаний, а получение знаний — это прямой обман работодателя? Значит, знания получать не следует, с ними надо рождаться.
«Вы не подходите, мы вас перезвоним».
Зачем перезванивать если человек вам не подошёл?
Да, по overskilled очень часто отказывают
однажды мне довелось 4 часа общаться с очень дружелюбным технарём, от которого я узнал множество интересных
это конечно же показатель его высоких софт-скиллов, что он легко и непринуждённо настроился вашу волну и увлёк разговором на по сути отвлечёную тему
Я быть может и знаю тот шаблон что вы у меня спрашиваете, но в моей голове он называется по другому и его реализация может немного отличаться.
Знание шаблонов ближе с софт-скилам — это способ быстро и однозначно объяснить или понять подход к решению задачи.
это конечно же показатель его высоких софт-скиллов, что он легко и непринуждённо настроился вашу волну и увлёк разговором на по сути отвлечёную тему
Добавляя сарказм в предложение вы затрудняете понимание идеи, которую пытаетесь донести. Вот я и не понял причем тут софт-скилл одного человека, история про которого была встроена просто для того чтобы показать что бывают исключения.
Знание шаблонов ближе с софт-скилам — это способ быстро и однозначно объяснить или понять подход к решению задачи.
Возможно вы имели в виду знания названий шаблонов, а не знания шаблонов. Но даже в этом случае я не могу с вами согласиться, для меня очевидно, что невозможно быстро и однозначно объяснить\понять подход к решению задачи, используя термины, под которыми в свёрнутом состоянии лежат довольно много нюансов, причем свернуты они в разных головах по разному. Поэтому я предпочитаю пожертвовать быстротой в пользу разжевывания нюансов.
Шаблоны по определению не про нюансы. Это примерно как в обсуждении задачи прийти к выводу, что необходимо обойти все элементы. Один подразумевает оператор foreach, а другой метод map(). И на этом этапе не нужно разжёвывание нюансов.
Больше похоже на человека с расстройством аутистического спектра.
Люди склонны обвинять или выдавать диагнозы, когда слабо разбираются в том как мыслят другие люди. Если бы вы немного поварили в голове мысль о том почему одних людей такой вопрос вводит в ступор, когда другие отвечают на него сразу, возможно вы бы начали улавливать эту разницу в подходе к мышлению.
В таком случае компании нужно нанять помимо вас ещё одного личного помощника, который будет переводить с вашего на общекомпанейский.
Тут вы совершенно верно уловили идею о конвеере. Одно дело — клепать детали, совершенно иное дело — учить клепать детали. И третье дело — координировать весь конвеер. И мне кажется странным, когда фирма отбирает человека, способного учить клепать детали на позицию клепальщика. Клепание в данном примере — ужасный выбор, поскольку клепать определенную деталь можно научиться в ограниченное время, а вот учиться программировать можно всю жизнь.
Если вы очень крутой рокстар в своей области — и это область нужна компании, то может так она и сделает.
Пытаюсь донести что вот эту самую крутость невозможно оценить за собеседование.
Совсем в общих чертах и буллет поинтах вы уже это написали в резюме. Значит немного подробнее чем там.
"Что и где конкретно подробнее вы хотите узнать?"
Собеседующие, которых раздражают встречные вопросы, могли бы задуматься о собственном софт-скилле.
а расскажите о вашем сервисе
Конкретные вопросы не вызывают ступор у технарей. Цимес ситуации в том, что спрашивающий будет оценивать не сам сервис, и не скиллы которые были использованы (хотя изо всех сил будет делать вид что он оценивает именно это). Он будет оценивать складность выдаваемых предложений, их "мелодичность" звучания. А это далеко не самое важное для программиста.
В любом случае человек который может объяснить что он делает при прочих равных полезнее человека который может сделать чёрный ящик, а объяснить не может (магия что ли?).
Утверждая что-то на 100% вы автоматически падаете в ошибку определенности. Вот мне мой опыт показывает мне что существуют очень талантливые в своей сфере люди, не обладающие даже средним навыком коммуникации. Сконтачиться с такими людьми, включить их в процесс и заработать вместе с ними денег — задача босса.
Забавно что мой проект изначально назывался Black Box ^_^
Черные ящики на то и чёрные, что вам не нужно лезть к ним внутрь, чтобы ими пользоваться.
И вы знаете это потому что ваши коммуникационные скиллы на уровне чтения чужих мыслей? Или вам сам интервьюер нашептал после собеса что он оценивал?
Я знаю это потому что сам задавал подобные вопросы и "оценивал" ответы на них. В собеседовании невозможно толком оценить ни сервис ни скиллы, а оценить нечто необходимо, потому мозг спрыгивает с сути на мелочи, некоторые из которых я привел просто для примера.
Ага. А потом талантливый человек уйдёт и разбирайся с его творением. А поскольку он и двух слов связать не может, то никто ничего не знает. Bus factor = 1.
Все боссы об этом мечтают. (Нет.)
Вы кинулись в крайность "двух слов связать не может". Я обсуждаю разницу между высоким коммуникативным навыком и средним. Кажется что мало кто здесь представляет себе что такое высокий коммуникативный навык.
Ваша стратегия "нанять человека получше умеющего связывать слова" мне примерно понятна. Мне так же интуитивно понятно, что такой человек с большей вероятностью не справится со сложной задачей или справится с ней таким образом, что оно всё разъедется и сломается в какой-то момент.
А вот нанятый "гик" после уволенного "гика" спокойно разберется в любом чёрном ящике, читая код и наблюдая поведение системы, вместо того чтобы полагаться на человеческие слова: общение и документацию, часто ошибочную, часто вообще не соответствующую тому что было реализовано на самом деле.
А сколько планируете второго гика искать? )
А у человека со средним коммуникативным скиллом никакой проблемы ответить на «расскажите о себе» нет.
Личное оценочное суждение?
А у человека со средним коммуникативным скиллом никакой проблемы ответить на «расскажите о себе» нет.
Очень спорно. Может будь у меня статистика хотя бы из 10 собеседований — я бы мог на ее основе прикинуть что скорее всего хотят узнать. Но я за всю жизнь был лишь на 2 собеседованиях. Потому я даже близко не знаю чего именно от меня хотят этим вопросом. Может хотят побольше про технический бекграунд узнать. Может про околорабочие интересы. А может вообще про личные интересы, темперамент и т.п., чтобы узнать как я в коллектив впишусь и буду ли «тимбилдиться» добровольно после работы в баре/спортзале/etc.
Включать зеркальные нейроны? Хотя, да, навык общения в первую очередь тренируется, а не учится по книжкам
А что прочитать, чтобы выучить социальные взаимодействия — непонятно.
Пытались ли вы гуглить ответ на этот вопрос? Вообще это лучше тренировать и чтобы рядом был человек, который может посмотреть на вас со стороны и дать обратную связь.
И мне кажется странным, когда фирма отбирает человека, способного учить клепать детали на позицию клепальщика.
А что ж тут странного? Фирме нужен старший клепальщик, который сможет обучать младших клепальщиков, недостатка в которых обычно нет. Но старших клепальщиков на рынке труда мало, приходится оценивать тех, кто есть, с позиции "сможет ли этот кандидат стать старшим клепальщиком в обозримой перспективе, или клепальщик второго разряда его потолок", ну и плюс оценивает, сколько ему предложить, чтобы и кандидата устроило, и фирму.
Одно дело, когда вы со своими коллегами сработались и уже много раз обсудили кто что подразумевает под каким шаблоном проектирования, привели так сказать термины к общему знаменателю. Совершенно иное дело когда вы занимаетесь этим на собеседовании с неизвестным человеком в отрыве от реальных задач.
Ой да ладно, берем любой язык программирования, ищем не самые популярные на гитхабе ORM библиотеки и начинаем смотреть сколько из них на самом деле Active Record. Отсюда вывод что много людей на самом деле не совпадают в понимании шаблонов, и поэтому никогда не мешает уточнить что именно имеется ввиду.
потому что когда я нормализую, я не использую русские слова, я использую внутренние знания, приобретенные не на парах в университете, а на «боевом» опыте.Для этого даже термин есть: «Неявное знание».
Да ладно, что все накинулись то автора обвинять.
Статья содержит много объективных мыслей.
Сам процесс собеседования реально сложный для обеих сторон и содержит немалую погрешность в конечных выводах у собеседующего и наверное у собеседника в том числе.
Все разные. Есть доля правды и там и там.
Я тоже больше люблю конкретику в тех собеседовании, а не абстрактные личные вопросы, потому что настроен на проверку и на тест больше, чем на разговор по душам, иначе рискую слишком расслабиться.
И также согласен что деталюшки выпрашивать это лишь способ показать собственную некомпетентность и отсутствие понимания процесса поиска подходящего человека.
При этом конечно это нормально рассказать немного о себе и это не должно быть проблемой. Тут уже нюансы характеров и кто как к этому относится.
Собеседований бывает и череда и как-то уже устаешь отвелкаться на лирику.
В ситуации где в мире "все такте разные" я думаю важнее чтобы собеседующий умел отличить когда человек реально не может общаться от ситуации когда ему что-то кажется важным, а что то нет.
Если это не негатив, а мнение, то его можно понять и уважать.
Все таки видно когда за ответами стоит способ мышления, а не тупо "я вот такой самый умный а вы мне не нравитесь".
А долю обиды или усталости от собеседований также очень легко можно понять.
Факт что даже при при наличии опыта с обеих сторон "баррикад" люди делают ошибки и в процессе организации собеседования и в оценке, что в целом часто заканчивается фрустрацией для по сути толкового и стоящего должности кандидата.
И что самое сложное — с ростом скилов процесс не упрощается (ведь я уже столько сделал и столько всего знаю),
а усложняется (ведь собеседующий уже тоже столько всего делал, но другого или по другому и столько знает из своего персонального опыта с прицепленными маркерами вот "это реально важно, ведь тут я столько ** съел).
По моим ощущениям "учиться собеседовать" более недооцененный момент над которым надо работать, так как в данной процессе собеседующий всегда в позиции силы и ему проще, а значит легче потерять оценку самого себя и больше надо следить за объективностью и давать шанс человеку проявить свои сильные стороны и показать процесс мышления чем тупо ждать Неверные ответы на вопросы, как здорово подмечено автором.
Я от этой проблемы также страдаю.
допустим, что программист НЕ ДОЛЖЕН обладать сильными софт-скилламиЕсли программист не хочет всю жизнь оставаться джуниором — увы, должен. Общение неизбежно. Не с клиентами, так с коллегами и руководством. Этого не надо бояться, этим надо пользоваться.
Я пытаюсь вам показать что есть альтернативные пути развития, грубо говоря предлагаемый вами вижн это "техлид", а альтернативный — это "гик". Конечно, обладая сильными софт-скиллами намного проще проходить собеседования и — как следствие — менять места работы как перчатки. Затачиваясь же на технические фишки вместо (в жертву) коммуникативных с одной стороны вы рискуете не найти себе работу сразу после форс-мажорного увольнения, но с другой стороны вы становитесь способны на реализацию систем такой сложности и глубины, которая "техлиду" только снится. Конечно даже эти две ветки условны, ведь реальный скилл зависит не только от выбора между ними, но и от выбора "изучить еще что то новенькое, создать еще что-то интересное" или "посмотреть ютюб, почитать случайные статьи на хабре".
О страхе общения речи вообще не было. Менеджер же не программирует не потому что он боится программировать.
Я думаю, на разных работах нужны разные люди. Возможно, есть какие-то места где нужны ультрагики и кто-то настолько в этом совершенен, что ему приставят секретаря-переводчика для общения с окружающими.
Где-то надо чтобы программист был аналитиком и сам понимал нужды пользователей.
Основная масса где-то посредине — не нужны не ультратехнические ни ультрасофтскиллы, но какая-то удобная смесь.
Затачиваясь же на технические фишки вместо (в жертву) коммуникативных
Тут вопрос, обязательно ли это "в жертву". Получая коммуникационные навыки можно открыть некоторые пути к получению технических скиллов от окружающих и некоторую энергию для получения скиллов другими способами (условно повысить качество отдыха в компании, например).
То что воспринимается как "нытье" на низком уровне, может быть переосмыслено как "желание улучшить" на высоком. То что воспринимается как "гнобление" — как конструктивная критика. Приятные на первый взгляд люди часто оказываются манипуляторами. Преобразовать неприятного члена команды в приятного — вот канонический пример высокого софт-скилла, совершенно не подвластного технарям.
Вам непонятна жертва потому что вы подразумеваете что-то под софт скиллами, а я веду речь про высокие софт скиллы, сильный навык коммуникации, которому, действительно, обучаются если не "за партой", то хотя бы за деньги и тратя уйму личного времени. Нежелание прокачивать коммуникативный навык действительно присутствует, особенно когда технаря манит альтернатива в виде очередной технологии или вкусной задачи.
Не похоже, что у вас высокие софтскиллы в письменном неформально общение, уж извините
Я исхожу из нескольких предположений:
- вы пишите комментарий не для того, чтобы его написать, а чтобы донести до других свою точку зрения, своё мнение, своё суждение, чтоб хотя бы её признавали одним из рациональных взглядов на ситуацию. Возможно даже убедить всех читателей, что точка зрения вашего оппонента Reuniko неверная, а ваша верная
- сознательно вы не хотите строить себе дополнительные барьеры для достижения своих целей из пункта 1
- академически межличностным коммуникациям вы не обучались, разве что курс психологии в техвузе для галочки или что-то вроде этого
А для меня не любое общение софт-скилы, а общение, которое имеет какие-то цели и не содержит элементов, которые этим целям противоречат.
Затачиваясь же на технические фишки вместо (в жертву) коммуникативных с одной стороны вы рискуете не найти себе работу сразу после форс-мажорного увольнения, но с другой стороны вы становитесь способны на реализацию систем такой сложности и глубины, которая «техлиду» только снится
Всё так. Однако, принося в жертву коммуникативные способности, вы, прежде всего, рискуете тем, что ваши сложные и глубокие системы останутся неоцененными и тот самый форс-мажор получите именно вы.
Взгляните на ситуацию глазами менеджера, в принципе не способного (и не желающего) понимать всю сложность и глубину:
- Дима — улыбчив, поддерживает беседу, проводит собеседования, каждую написанную свистосопелку сопровождает презентацией.
- Вася — гик, сидит в углу, занимается непонятно чем, уходит от разговора.
- Форс-мажорные обстоятельства требуют кого-то сократить.
Потом, возможно, все рухнет и окажется, что на Васе висела половина организации, но это потом.
Менеджеров, способных понять гика — слишком мало.
Да без форс-мажоров убедить того же менеджера что надо выделить ресурсы на рефакторинг, обновления или нанять dba или девопса…
Насчёт всё развалилась не скажу, но вот так треккеры мне доводилось внедрять на проектах много лет существующих, и перфревью не было, 1:1 только в курилке если поймаешь и т. п. Но потом звали на 2х
В том что такое иногда происходит я поверю
Ваше «иногда» будет очень сильно зависеть от среды. Какого размера компании, в какой стране, и так далее. В некоторых конкретных конторах «иногда» внезапно будет в каждой второй команде. И в целом, чем крупнее очередной кровавый энтерпрайз, тем больше в нем может быть направлений, где менеджмент совершенно не в ладах с технической реальностью, которой они вроде как управляют.
Всё более-менее нормально с управлением только у бедных (мелких стартапов и прочих) — не из-за бедности, а из-за того, что они мгновенно накрываются, если у них с управлением что-то идёт не так. А у богатых их запас прочности может покрывать очень много неэффективного управления.
Ещё кстати наверняка на часть таких историй, есть истории со стороны оставшихся людей. «Был у нас какой-то Вася, что-то делал, уволили, а мы потом заглянула туда, и ууу, лучше бы не заглядывали».
Потому что чужой код, а код, в который до увольнения Васи никто не глядел — чужой, мало кому нравится. Чтобы он нравился, он должен быть написан так, как нравится смотрящему в этот код (тут по классике «красота — в глазах смотрящего»), а он не то, что в создании кода, он даже в создании стайл и гайдлайнов для этого кода участия не принимал и ессно никогда не участвовал в код-ревью.
Поэтому да, лучше бы не заглядывал, но ведь работало, ценность для бизнеса имело. Тут понадобилось прикрутить сбоку что-то или обновить что-то старое и понеслось. Проще переписать, чем допилить, ага-ага. NIH как он есть. Причем даже не NIH, not-invented-by-me.
Главное, что все могут понимать что Вася делает хоть примерно.
Компания большая, проектов может быть еще больше, соглашения о разработке могут быть, могут не быть, могут быть, но не применимы к конкретному ЯПу (например, у нас есть соглашение для Java, а для Питона — не было). Апруверов тупо не было, человек в одну каску всё делал. Если он писал и пушил сам по себе не значит, что Вася говнокодер, а значит, что одного Васи хватало, чтобы делать то, что от него просили.
Код-ревью может просто не быть, как и других разработчиков на этом проекте. Если бы оно было, ситуация «заглянули и ужаснулись» не произошла.
И как раз поэтому нормальным является когда код ревью проводят все, а не один тимлид, как ТС предлагает. Потому что тогда все могут посмотреть и удостовериться что код удовлетворяет их стандартам качества.
Я всего лишь описал то вижн, что в текущий момент жизни кажется мне оптимальным. Понятие "нормы" субъективно, осторожней с ним.
Было бы здорово узнать поподробнее ваш вижн в котором код ревью проводят все.
Например, что происходит если условно старший кодер залил коммит, трое других его посмотрели, одному всё понравилось, а другим двум что-то непонравилось? Каков план в этой ситуации? Они собираются за круглый стол и обсуждают "как правильно" до тех пор пока не придут к общему? Или на самом деле пока кто-то из них не сдастся, полагая что так будет лучше: и времени меньше потрачено и нервов?
Ну, например у нас условие мержа было: два апрува и ни одного ченж реквеста. Формального процесса разрешения конфликтов не было, только раз или два за год применялась власть CTO, а так как-то договаривались. Вместе собирались, индивидуально, скрам-мастер привлекался, владельцыы продукта, CTO...
Если все относятся друг к другу доброжелательно и хотят закоммитить качесвенный код, то ревью воспринимается как помощь. Принципиальные разногласия случаются редко, кратковременные случаются, но обычно решается аргументами.
Здорово что вы можете позволить себе тратить так много времени на анализ и критику чужого творчества в рамках одного проекта. Можно пофантазировать на тему "а что было бы если бы мы еще ревьювили бы соседние проекты тоже". Вот опыта то подкатило бы!
Если 50/50 уступает ревьюер.
И демократия у вас тоже интересная. Два человека не смогли договориться (их общего коммуникационного скилла не хватило), значит нужно привлечь всех вокруг, устроить "судилище" с "присяжными", да еще и после этого "проигравшему" делать вид что ему это не было неприятно ни капельки.
Мы вот больше фокусируемся в декомпозицию проекта на максимально независимые куски и изоляцию программистов между ними и жонглирование задачами таким образом, чтобы к отпуску конкретного программиста их поток ослабевал или вообще ставился на паузу. Конечно, не всегда получается, но и ситуация когда ключевой программист в отпуске — редкая и переживаемая с некоторыми трудностями: заменяющему программисту приходится читать чужой код "adhoc" в момент если есть срочная задача из чужой области ответственности. А не всегда, как у вас.
Поэтому да, лучше бы не заглядывал, но ведь работало, ценность для бизнеса имело. Тут понадобилось прикрутить сбоку что-то или обновить что-то старое и понеслось. Проще переписать, чем допилить, ага-ага. NIH как он есть. Причем даже не NIH, not-invented-by-me.
Вообще говоря, за исключением совсем уж извращенных случаев, в код условного Васи, который просто где-то там работает — никто и не лезет. Проблемы начинаются тогда, когда в один прекрасный момент оказывается, что так дальше жить уже точно нельзя, надо дорабатывать — и вот там-то открывается бездна, и NIH там часто совсем не при чем. Просто при наличии Васи в штате этот код бы потихоньку рефакторился силами Васи сообразно надвигающимся изменениям, а без Васи оно всё дожило без изменений до некоего критического состояния (обычно еще и подразумевающего надвигающиеся дедлайны), и тут внезапно оказывается, что этот код, который просто работал — под новые реалии ну совсем не годится, и рефакторить надо вообще всё.
Любители всё переписать «просто потому что хочется» среди разработчиков конечно же есть (да чё там, я и сам это дело люблю), но таки кидаться и переписывать обычно бегут максимум джуны, а другие всё ж таки подгадывают это дело под другие объективно необходимые изменения.
Я сомневаюсь не в том что существует неэффективное управление, а о ситуации в целом.
Ключевой сотрудник, о котором никто не знает что он ключевой и его под нож.
Я могу детализировать, потому что я таких ситуаций повидал уже несколько (сам лично в них не был, но вот находился рядом), в том числе и в больших уважаемых конторах не из РФ.
Есть некий проект. Не mission critical для бизнеса, в том плане, что без него всё пойдет хуже, проблемнее, и дороже, но в принципе никто не умрет и бизнес не рухнет. Там работают некие технари и некое руководство. В один прекрасный момент, обычно вследствие гнетущей тишины вокруг (ничего особого не происходит, крышесносных задач никто не ставит, перспектив пробиться в ряды CEO у руководства нет) — руководство затевает некую движуху, что-нибудь там расширить, углýбить, развить, и вообще. Под эту движуху частенько происходят и кадровые перестановки, кто-то уходит, кого-то берут, и так далее. А потом проект просто накрывается: перестаёт принимать изменения (или, в особо запущенных случаях, вообще падает и больше не поднимается), не развивается, или делает через пень-колоду то, что раньше делалось без проблем.
Что произошло в реальности? В реальности был уволен или сам ушел человек, на котором держалась вся реальная функциональность проекта. В случаях, которые я наблюдал — это всегда происходило из-за конфликта этого человека с охваченным кипучей жаждой деятельности руководителем; один до боли в пятой точке хочет чего-нибудь сделать, второй говорит, что предлагаемые изменения пойдут проекту во вред. Дальше человек уходит, и… предлагаемые изменения идут проекту во вред. Даже если вообще с проектом удалось совладать силами других специалистов.
В особо тяжелых случаях руководитель с шилом в заднице силами «софт-скиллов» уходит на повышение и нафиг разламывает уже не один проект, а целый сектор. Чаще, конечно, с повышением он уходит в другую контору, а не в эту же. В обычных — его за разрушение проекта выпинывают, но только постфактум — проект уже пришел в более плачевное состояние, чем был.
>один до боли в пятой точке хочет чего-нибудь сделать, второй говорит, что предлагаемые изменения пойдут проекту во вред
Вот именно в такой. Упрощенный пример — один до боли пытается зарелизить нечто, где даже нет настроек на среду (то есть, условно, URL для коннекта к базе зашит для базы DEV, а база PROD не предусмотрена). А когда ему ключевые сотрудники говорят, что релизить это нельзя, потому что г**но, оно встает в позу, и начинается…
Я видел людей, действительно создающих системы «такой сложности и глубины, которые и не снились». У них даже отдельные
Харизма, речь, уверенность в себе, умение донести мысль, удержать внимание публики и т.п. у этих джентельменов были весьма длиннее и толще, чем в целом по организации.
Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор). Конструктор может немного покопавшись в памяти вывалить своё имя, возраст, рост и вес, национальность и цвет глаз, но при этом не поймет какое это все имеет отношение к делу, ведь он пришел продавать свой технический скилл, а не себя.
Технический скилл это разве не часть его? По этой фразе такому конструктору логично было бы рассказать как раз какой именно технический скилл, каким опытом он подтвержден, какие задачи он умеет решать и любит, какие не любит и так далее.
Это всё уже есть в резюме, потому и ступор. Не хочется повторять то что уже и так перед глазами.
Я тут не понимаю как связано второе и первое. Я, например, не впадаю в ступор каждый раз когда надо идти к зубному, но это не то, что мне хочется делать.
Я, правда, сам таких вопросов не задаю, но не понимаю отчего тут впадать в ступор. Резюме повторять необязательно, можно рассказать упрощенную версию адаптированную под конкретного человека. Боссу более общую технарю более подробную.
Непонятно зачем тратить время на пересказ того, что им уже и так известно из чтения резюме. Непонятно зачем и нужно ли подготавливать отдельную историю на такой случай. Когда технарю "непонятно зачем" он впадает в ступор, ступор выражается не остановкой двигательной и речевой функции, а попыткой обдумать и понять зачем им это. В случае если технарь уже собаку съел на собеседованиях, он, конечно, сразу задаст уточняющий вопрос. Ну а если нет, то не сразу.
Отношения к кандидату как королеве и не ожидается, достаточно того чтобы собеседующий прочитал резюме, обновил информацию в своей краткосрочной памяти минут за пять до собеседования. В противном случае складывается впечатление что либо вы в принципе не интересны этому человеку, либо он не способен организовать свой график таким образом, чтобы минимизировать трату своего и чужого времени. Что сходу в лучшем случае демотивирует, в худшем может быть воспринято как неуважение, результат предсказуем.
Ну так вы тоже не Величество и не Святейшество, и работать у вас, вероятно, не такая уж большая честь.
Просьба проявить внимательность к резюме кандидата расценивается уже как «королевская» услуга.
Не знаю клиник, где оперируют брёвна в глазу, но вы поищите. Хотя могут просто прописать курсы повышения софт-скиллов и снижения воспалённого ЧСВ.
Ну и это помогает оценить кандидата не предвзято… а то часто настроишь себя по резюме «вот он, тот кто нам нужен», а по факту даже на 10% кандидат себя не стоит… :(
80% кандидатов не в состоянии рассказать о «самом интересном проекте», «о последнем месте работы — чем конкретно он занимался, какой стек использовался, какая архитектура решения».
Если вы считаете что это бесполезная трата времени — значит нам вместе не работать :)
Поэтому рассказать о себе часто ещё и полезно.
Бывает конечно рассказ о себе выявит какой-нибуть опыт разработки в букмекерских конторах или онлайн казино, или ещё что-то такое… на что у руководства «аллергия» :)…
Весь вопрос в том кто лучше для работы в команде для реализации поставленной задачи — упоротый программист ас или просто хороший, но коммуникабельный программист.
Работа в команде программистов разительно отличается от работы в футбольной команде, например. Если в последней вам необходимы навыки коммуникации уровня чтения тела своего партнера чтобы вовремя выдать или поймать пас, то…
… в командной работе над сложным проектом бОльшая часть "магии" заключается в ловком жонглировании техлидом задач и зон ответственности между программистами с целью минимального их пересечения друг с другом.
Я бы сравнил это с рисованием картин: вы конечно можете загрузить трех художников на один холст и самозабвенно наблюдать за тем как они болтают между собой больше, чем рисуют… а можете выдать им три отдельных холста и общую рамку, обязав каждого в нее вписаться.
Тут хотелось бы ссылку на то как художники реально работают над одной картиной. Разрезают ли они холст на квадраты общаются и так далее — или метафора ничего не имеет общего с реальностью?
В моей практике программисты даже если они работают над задачами не связанными друг с другом периодически общаются для решения вопросов — один знает как искать утечки памяти, другой особенности какого-нибудь модуля и им придется обмениваться опытом. Еще иногда надо новичков обучать, иногда кто-то уходит в отпуск и хорошо, чтобы кто-то знал особенности того, что он сделал и так далее.
А еще код ревью
Как это устроено у вас?
Тут хотелось бы ссылку на то как художники реально работают над одной картиной.
Если речь идёт про digital, то может быть несколько сценариев:
1. Глава проекта намечает общую композицию, определяет единообразный художественный стиль, дробит на множество мелких объектов (персонажи, пропсы, фоны), отдаёт их художникам для детализации (возможно, после того как для картины построили черновой эскиз или 3D-модель), затем всё это пытаются свести, если получили всё необходимое в разумные сроки.
2. Есть пайплайн «лор/сюжет» — «скетч» — «лайнарт» — «шейдинг» — «колоризация», разные стадии могут быть поручены разным людям.
То что они общаются совершенно не означает что они обладают высокими коммуникативными навыками. Человек существо социальное, найдет время и повод на общение в любой ситуации, тем более рабочей. Нужно ли обращать ваше внимание на то сколько общения тратится на рабочие вопросы, а сколько на нерабочие?.. околорабочие?...
Программист программиста поймет с большей вероятностью, чем, например, продажника или менеджера или еще кого угодно, кто думает не в технической плоскости. Коммуникация между технарями — это отдельный подвид коммуникации, оценить который затруднительно человеку с социальным мышлением.
Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним. Вот тут и ответ. Отсутствие шизофрении полезно и в коде и в произведении. Количество фильмов с одним или несколькими сценаристами. И так далее. Конечно, бывают исключения.
программисты даже если они работают над задачами не связанными друг с другом периодически общаются для решения вопросов — один знает как искать утечки памяти, другой особенности какого-нибудь модуля и им придется обмениваться опытом
Это здорово, когда в команде есть авторитет по какому-то важному критичному в данный момент вопросу. Он придет на помощь и поможет, задача закроется в срок, все будут довольны. Но бывает что возникает противоположная ситуация: нужно реализовать нечто и никто не знает как это делать. Вот в такие моменты проявляется истинная сущность программиста: будет ли он последовательно отвлекать всех членов команды в надежде что они ему помогут, собирать консилиум и тратить уйму общего времени или… решит сперва самостоятельно исследовать вопрос с помощью своего мозга и интернета. На самом деле здесь нет правильного ответа, оптимальный путь лежит где то между ними.
Обучение новичков, код ревью — это к тимлиду.
"Особенности того что он сделал" вполне реально изучить самостоятельно, используя систему контроля версий, было бы желание. Но желания изучать самостоятельно нет, чтение чужого кода для большинства людей — сущий ад, вместо этого есть желание сэкономить мыслетопливо, спросив словами и получив ответ успокоиться. Здорово когда эта коммуникация происходит в рабочее время, а не когда один из разрабов попивает коктель на берегу теплого моря. Не здорово то, что эта коммуникация отвлекает одного из программистов от его текущей задачи, в результате чего он, после этой коммуникации, тратит дополнительно +- 23 минуты на то чтобы погрузиться обратно в свою задачу.
Что касается художников, попробуйте сперва припомнить навскидку количество великих картин, написанных 2+ художниками, затем написанных одним.
Насколько я понял нас не интересуют картины написанные одним художником, скорее картины написанные коллективами? Если вы считаете что все-таки работа одного художника более показательна, то интересно, кто из них как общался с авторами.
нет правильного ответа, оптимальный путь лежит где то между ними.
То есть программистам все-таки когда-то общаться нужно да?
Обучение новичков, код ревью — это к тимлиду.
Получается тимлид должен обязательно знать в деталях весь проект лучше чем каждый программист, даже который написал какой-то кусок, который сейчас правит другой программист?
"Особенности того что он сделал" вполне реально изучить самостоятельно, используя систему контроля версий, было бы желание.
Как "реально" мне лично совершенно не интересно. Мне интересно как эффективно.
Еще мне бы хотелось знать, это ваши теоретические построения или есть какой-то опыт организации команд программистов на таких принципах.
Не здорово то, что эта коммуникация отвлекает одного из программистов от его текущей задачи, в результате чего он, после этой коммуникации, тратит дополнительно +- 23 минуты на то чтобы погрузиться обратно в свою задачу.
Ну это зависит от задачи и от способа организации коммуникации. По-моему.
Опыт организации команды у меня всего один, опытов обзора организаций команд — много. Вы почему-то не замечаете разницы в моих понятиях "высокий коммуникативный навык" (высокий софт-скилл) и коммуникация между технарями. Технарю с технарем договориться на много порядков проще, чем с кем-либо еще. Поэтому, в моем вижне, этот кто-либо еще должен обладать высоким коммуникативным навыком, а не технарь, потому что иначе технарь уже не будет технарем, а станет смесью двух разных миров.
Получается тимлид должен обязательно знать в деталях весь проект лучше чем каждый программист, даже который написал какой-то кусок, который сейчас правит другой программист?
Тимлид должен знать весь проект, должен знать где копнуть чтобы вспомнить детали. Это вполне реально когда ты ведешь проект с нуля, спроектировал архитектуру и читаешь почти в реальном времени все приходящие в него коммиты. Если же проект не твоего авторства, то приходится выделить некоторое время на его изучение, чтение кода, мало кому это приятно. В процессе чтения этого кода у тимлида могут возникнуть вопросы "почему так, а не эдак", но и здесь нет проблем, поскольку он обладает высоким коммуникативным навыком, в отличие от окружающих его программистов, которые могут себе позволить сосредоточиться на технических аспектах задачи, будучи изолированными от общения с заказчиком и, возможно, менеджером. С одной стороны такая конфигурация создает дополнительную нагрузку на тимлида в те моменты, когда ее можно было бы избежать, с другой стороны у проекта падает градус шизофрении за счет общего центра, принимающего все важные ключевые решения в технической плоскости.
Я не знаю что такое высокий коммуникативный скилл по-вашему, но с моей точки зрения для того чтобы рассказать о себе он не нужен. Такое же умение структурировать информацию и слышать собеседника как и при коммуникации между программистами.
Я не очень понимаю зачем надо создавать single point of failure в виде тимлида причем тимлида с идеальной памятью. С моей точки зрения лучше чтобы сеньоры могли его поменять хотя бы в каких-то областях.
Ну да ладно мы тут пошли по кругу
И один из главных коммуникативных навыков :)
"Здорово" когда ты делаешь вывод о том, что кто-то другой чего-то не понимает. Все ясно, понятно и думать больше не надо.
Если всё же желание развивать мышление еще есть, предлагаю подумать вот над какими примерами:
1) коллега-прямой-менеджер выслал фидбек, программист его не принял:
— это у программиста отсутствует софт-скилл?
— или это проблема коммуникации с обоих сторон?
Часть великих художников представляли собой бренд, под которым работали их ученики и подмастерья, делавшие работу по их уровню скилла (скажем, мастер мог специализироваться только на лицах на больших сложных групповых портретах, ученики писали всё остальное). Это нормально для средневекового цехового уклада, хотя в наше время задают вопросы, были ли картины написаны самим мастером — или его учеником.
чтение чужого кода для большинства людей — сущий ад
То, что у вас с этим проблемы говорит только о том, что вы в этом недостаточно хороши. Глупо экстраполировать собственные недостатки на «большинстве людей».
Чтение чужого кода это, на минуточку, основное занятие программиста. 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) На мой взгляд больше толковых кандидатов можно потерять, если начать их пытать знанием плюсов, особенно такими тупыми вопросами как виртуальный деструктор и прочая классика.
Вообще говоря, результат у работы должен быть, хотя бы отрицательный (типа сделать не возможно или получается очень криво). Но с некоторыми исполнителями получается именно так, как вы написали — жопо-часы в наличии, а результата нет никакого. Именно от этого стремимся защититься.
К примеру, мой личный опыт, который я могу приводить как пример:
— 9 мест работы;
— не было среди них мест, куда бы меня взяли бы после выполненного тестового задания;
— было 9 мест, куда меня взяли без тестового задания.
Если считать по офферам, там ситуация еще хуже (в смысле офферов было больше, а на ноль всё так же делить нельзя).
Отсюда у меня сложилась связь: «выполняешь тестовое — зря теряешь время».
Задания на 1 час, как правило, дают на собеседованиях, на дом задают бОльшие задания.
А дома, в знакомой обстановке неспеша я лучше напишу что-то в пет-проект, или прослушаю запись доклада с какой-нибудь движухи. Одно сделает меня опытнее, другое — умнее (но это не точно).
Почему я на словах должен верить в том, что чувак крутой программер, а не просто имеет хороший подвешенный язык?
Во первых потому что это рынок соискателя. Во вторых потому ято я один а желающих нанять меня — вагон. В третьих потому, что вы легко можете отсеять первого от второго, уточнив нюансы и тонкости реализации.
Чего угодно. Можно достаточно быстро выяснить что человек реально делал а чего не делал если просто пройтись уточняющими вопросами по его проектам.
И вам ответят, что там все под NDA и обсуждать глубоко не будут
Хотелось бы призвать людей которые критикуют какую-то практику на собеседованиях описать, как должно проходит собеседование с их точки зрения, и, желательно, каким именно опытом подкреплена их точка зрения (хотя бы это чисто теоретическая конструкция или испытано на людях и, желательно, сколько раз).
Идеальное собеседование — милая беседа с HR, а техническое собеседование не требуется, т.к. кто-то достаточно авторитетный подтвердил твою квалификацию)
Т.е. запрашивать рекомендации с предыдущего места работы и только их — вы много так наняли?
Идеальные случаи редки, увы. Меня так наняли на текущем месте работы, всем понравилось в итоге.)
Один раз ошиблись, не сработались.
На фрилансе, по моему опыту, очень часто так происходит — либо ко мне приходят по рекомендациям, либо я сначала ищу по рекомендациям, и только в случае, если не нашёл подходящего человека, выхожу на фриланс площадки.
100 собеседований и чаще отказ? Выглядит либо как человек, который не понимает куда хочет и что умеет, либо пытающийся попасть на позицию, которой не соответствует, но "вдруг прокатит".
Что удивляет в высоком шансе отказа? Эйчары вполне могут составлять обоймы из кандидатов, которые требуется отсобеседовать целиком до найма одного из них, таким образом шанс каждого соискателя будет даже не 50%.
Сейчас я определенно вижу плюс, в том что люди в компании могут общаться плюс минус одинаково и из них не нужно вытягивать информацию щипцами.
Я на нетехнических интервью обычно начинаю с вопроса о том, что человек делает сейчас. Во первых по резюме, которое читаешь минут пять максимум, не совсем это понятно. Во вторых людям всегда есть что сказать по этой теме и проще начать разговор.
Если же у вас достаточно бюджета, вы можете попробовать следующий трюк: предложите 1 испытательный месяц работы всем желающим за пол ставкихороший способ угрохать в никуда практически любой бюджет. Даже если есть бюджет на оплату ½ ставки всем подряд, где взять столько людей, чтобы погружать их в проект, разжёвывать им особенности местного использования принятого в компании технологического стека, ставить задачи так, чтобы они сходу понимали хотя бы чуть больше трети (на половину я бы вообще не рассчитывал), а потом ещё и делать code review мутному потоку кода от них. Нет, HR-конвейер, способный переварить огромный поток
Пожалуй, я не достаточно конкретно выразился. Это совет тем фирмам, которые нацелены на найм именно лучшего, а не подходящего. Ведь бюджета то у них хватает на собеседования со всеми желающими? Вот в этом моменте они могли бы подвложиться для того чтобы достичь лучших результатов. К тому же большая часть кандидатов отвалится на моменте с половиной ставки без гарантий быть нанятым. А те кандидаты что останутся с большой вероятностью отработают вложенный в них бюджет.
А те кому достаточно просто подходящего могут продолжать работать по старинке.
Расскажите пожалуйста о своей практике в рекомендуемой вами методике приема.
Вот например принимается три новых человека на полставки на одно место. Допустим, им не надо три рабочих места — все работают удаленно.
Дальше из всех надо обучить — это делает непременно тимлид, он же делает всё код ревью и вообще всю коммуникацию по всей команде.
Как его на все хватает? Кто играет его роль, когда он уходит в отпуск? Сколько тимлидов нужно команде?
Необязательно это тимлид. В некоторых компаниях сильно распространено менторство над новичками силами разработчиков. Вплоть до того, что миддл сеньорскую позицию не получит, не "дотащив" джуна до миддла.
Это тс вашей точки зрения необязательно. А с точки зрения reuniko обязательно. А то ж разработчиками придется обращаться и у них должны быть софтскиллы. Это было явно написано ранее
Найм и онбординг качественный вообще дорогие процессы. Нужно с целями определиться для начала и какие ограничения есть по ресурсам с учётом состояния рынка. Например, я с трудом представляю, чтоб согласился на полставки работать на испыталке если после неё предлагают обычный рейт. Разве что работодатель предложит, о работе на которого я даже не мечтаю, а про завидую белой завистью тем, кто у него работает.
У меня не было подобной практики, моё предложение буквально высосано из пальца.
Однако однажды мне довелось поработать в фирме, процесс интеграции новых сотрудников в которой был оптимизирован лучше некуда:
— выдается инструкция на 3 листах А4 общекомпанейская куда подключаться и кому какие запросы слать в тех или иных случаях,
— тимлид заранее подготавливает и практически "выстреливает" все необходимые доступы к текущему проекту: гит, тестовый сервак, трекер задач; дополнительно закидывая FAQ или даже wiki, в которых раскрыто 90%+ вопросов,
В дальнейшем, конечно, многое зависит и от качества постановки задач и от уровня кандидата (многое — "время, убитое на разговоры"). Если задачи выставляются опытным тим-лидом, это вообще мёд, он сам их предварительно перечитывает из технической плоскости и сразу раскрывает почти те же самые вопросы, что возникли бы у кандидата.
Ну, это тем не менее не мешает многим компаниям так делать (это не у вас ставка ниже на исп сроке, а мы вас может быть повысим после прохождение исп срока — манипуляция? Да! Законно? Ну, на грани)
Крайне редки же случаи когда новая работа со ставкой более чем в 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 часов в сутки на протяжении многих лет. Нужно отдыхать. А отдых — это смена деятельности.
Вот вы сейчас, вместо того, чтобы учить очередной фреймворк, занимаетесь тренировкой умения связно излагать свои мысли. Почему? Потому что нужно же перерыв делать, не правда ли? А если вам для того, чтобы рассказать о себе, нужны именно «курсы коммуникации», то это явно не естественный порядок вещей. Вы же не пикапу обучаетесь, чтобы достичь мастерства в умении за пять минут уложить первую встречную девушку в постель, вам всего-то нужно поболтать пару минут перед непосредственно техническим собеседованием.
Время не бесконечно, иногда приходится выбирать одно, условно принося в жертву другое.
Жизнь жестока и иногда просмотр сериальчиков приходится приносить в жертву для того, чтобы получить знания.
Расскажите о себе
Желание отвечать только на конкретные технические вопросы и отвращение к открытым это какая-то стадия у программистов. Было время в самом начале, когда считал так же. Потом мнение поменялось. Возможно это как-то связано со школьным образованием или институтскими ценностями, где людей приучают измеряться индивидуально по четким критериям образовательной программы.
Промышленная разработка в текущем виде это коллективное занятие в условиях VUCA среды. Поэтому то, как человек коммуницирует, как реагирует на неопределенности и ситуации, рвущие шаблоны, внезапно не менее важно, чем умение писать код. В больших проектах куча проблем решается методом "просто поговорить" с нужным специалистом. Вы как правило будете не знакомы.
У нас в техзадании написаны критерии, по которым будет оцениваться результат (т.е. кандидат знает эти критерии). Само техзадание тривиально, и у него есть как минимум три простых решения. Но оно легко выявляет людей, у которых знания шаткие, потому что их начинает "нести" (речь про ансибл) — начинаются жуткие выкрутасы, которые плохо работают и которые невозможно прочитать.
Мы высылаем техзадание после первого собеседования с HR'ом, потому что приличный процент "девопсов" (которые знают умные слова но не знают, как их сделать) отсеиваются на этом этапе (т.е. не выполняют техзадание). Это экономит время всем (включая соискателя).
Судя по кавычкам вокруг слова "девопс" — это лишь вынужденное следование трендам рынка, когда сисадмины, изучившие как настраивать пайплайны в CI/CD тулзах, докер-кубернетсы, что-то из AWS/GCP/Azure, Ansible/Puppet/Terraform считают себя девопсами и откликаются исключительно на соответствующие вакансии
Ну, видите, как всё хорошо. Мы присылаем 10-минутное задание, и дальше беседуем только с теми, которые "девопсы со знанием компьютеров", а не просто "девопсы".
предложите 1 испытательный месяц работы всем желающим за пол ставки и принимайте решение по результатам работы.
Т.е. вы считаете что каждый готов уволиться со старой работы и пойти играть в такую рулетку да еще и за пол оклада?
Мне кажется если «проверка в бою», то самый оптимальный вариант — работнику на старой работе взять отпуск на пару недели и проработать их на новом месте — если все срастется — подписываем контракт и заявление об уходе (да может потребоваться пару недель отработать, но это максимум).
Испытательный срок в месяц ИМХО — не нужен за пару недель уже обычно все можно понять.
Что там можно понять? Что человек за неделю не разобрался в новом проекте?
Однажды меня позвали в компанию ведущим программистом, но о компании шла дурная слава. Предложили хорошие деньги, но я всё равно сомневался. Наконец, мы подписали договор ГПХ (подряда) и я две недели в отпуске у них отработал. Да, кое-что из дурной славы подтвердилось, но взвесив недостаки и плюсы, я подписался, и вскоре уже вышел по трудовому договору.
Кстати говоря, я не считаю, что опыт был плохим. Более того, когда меня спрашивали о той компании, честно рассказывал, что там следует ожидать.
На моей практике было когда за 2 недели надо было не только в проекте разобраться, но и правки внести т.к. через эти самые две недели в стране была деноминация и в проекте, который писался без копеек нужно было эти копейки добавить + поменять пару форм отчетности (ну у нас же любят поменять что-то с 1 января...).
Но я вписался и сделал — под бой курантов система работала с копейками. А вот центробанк платежки с копейками только к середине января научился принимать… После чего еще лег еще на пол дня т.к. его завалили всем тем, что надо было за пол месяца провести.
Грустно всё это. Я думаю процесс найма технических специалистов далёк от того, как он реально должен быть. Потому и в нашей отрасли проявляет себя принцип Парето.
Мне так сильно понравилось ваша вакансия и ваша компания и ваши идеалы корпоративной культуры,… и я понял, что вы достойны стать оправой такому восхитительному бриллианту, как я.
Проблемы в собеседовании на позицию программиста