В первом посте мы спросили тимлидов четырёх разных компаний, на что они обращают внимание во время собеседований, какие ошибки допускают кандидаты, как понять, что человек подходит в команду, и чего никогда нельзя делать во время интервью. На вопросы ответили: CTO в компании «Точка» Данила Штань, руководитель разработки в ЦИАН Михаил Юматов, руководитель группы Python-проектов в Rambler&Co Олег Чуркин и руководитель PyCharm Community в JetBrains Андрей Власовских.
— Как вы поймёте, что джуниор может быстро учиться и развиваться?
ДШ: Никак, просто даю шанс и смотрю, что происходит.
МЮ: У джуниора уже должны быть какие-то плоды его стремления учиться и развиваться — pet project'ы, багаж изучаемых технологий и т.п. Вот о них и поговорим.
ОЧ: Чтобы понять, насколько кандидат мотивирован на саморазвитие, я обычно задаю вопросы про самые сложные задачи, с которыми человек уже сумел столкнуться и слушаю, как он их в итоге решал. Чем интереснее рассказ, тем быстрее будет обучение.
АВ: Я обращаю внимание на сочетание самостоятельности, увлечения программированием и готовности к командной работе. Если кандидат ещё учится, то можно взять его на летнюю стажировку или семестровую практику, чтобы больше узнать о человеке и его перспективах.
— Какие у вас критерии отличия миддла от сеньора? Как вы проводите эту градацию уровней опытности разраба?
ДШ: Никаких, это всё бред для потокового найма, а я не люблю потоковый найм.
МЮ: Сеньор очень хорошо знает применяемые технологии (их сильные и слабые стороны, реализацию), отслеживает жизнь компонент на бою и проактивно выходит с предложениями по оптимизации и/или решению проблем с ними. Способен разработать архитектуру приложения и найти быстрые нестандартные решения в критической ситуации, самостоятельно вести проекты. Начиная с этого уровня, problem solving, умение работать с заказчиком, умение самостоятельно принимать решения и быстро переключать контекст между задачами — это обязательные требования. Автономен в решении поставленных задач, понимает, какая цель достигается в рамках решения задачи и способен найти оптимальный путь решения задачи. Всегда принимает на себя ответственность за качество выполнения задачи и названные сроки.
ОЧ: Сеньор должен хорошо разбираться в архитектуре веб-приложений и обладать достаточными личностными качествами для руководства командой. С сеньорами техническое интервью обычно переходит в дизайн-интервью, на котором и выясняется уровень.
АВ: Сеньора отличает большой опыт принятия взвешенных архитектурных решений, умение руководить джуниорами и способствовать их росту.
— На что вы смотрите при выполнении тестового задания?
ДШ: Никогда не даю тестовые задания, максимум алгоритм написать, просто чтобы понять какие-то базовые вещи про подготовку человека.
МЮ: Тестового задания у нас нет, но на собеседовании обычно что-нибудь с кандидатом проектируем. Смотрю на то, как человек рассуждает, насколько глубоко продумывает решение, как относится к остальным невидимым участникам процесса.
ОЧ: В первую очередь на его корректность. Если дефектов в коде нет, то большое внимание уделяю правильному выбору алгоритмов, умелому использованию инструментов, читаемости и красоте кода.
АВ: Помимо корректности и выбора подходящих алгоритмов, смотрю на соответствие кода лучшим практикам software engineering: разумная структура проекта, тесты, документация и т.д.
— Ваша любимая логическая задачка, которую вы задаете на собеседовании?
ДШ: Отсутствует, логические задачки на собеседованиях — это изобретение не очень компетентных HR. Нормальным людям и без этого есть, о чём поговорить с кандидатом.
МЮ: Нет такой :)
ОЧ: Есть неотсортированный список натуральных чисел от 1 до N, числа не повторяются. Из списка извлекли одно число. Необходимо определить какое за O(N) по времени и O(1) по памяти.
АВ: Любимой логической задачи нет, есть несколько алгоритмических. Конкретных называть не буду, но хорошая алгоритмическая задача позволяет придумать несколько ответов: от простых и неоптимальных до специфических, дающих выигрыш при определённых условиях.
— Наличие каких знаний/опыта необходимо и достаточно, чтобы попасть в вашу команду? И на какие «огрехи» и несовершенства вы спокойно закрываете глаза?
ДШ: Профильных знаний и профильного опыта. Желательно, в формате «сам себе режиссер».
МЮ: Про достаточные условия не скажу, а необходимые — пожалуйста. Нужно неуёмное желание уменьшать количество «магии» вокруг. Как результат — понимание используемых технологий, их устройства и работы. В том числе и Python’а.
Готовы закрывать глаза на знание используемых нами специфичных технологий. По ряду soft skills — тоже. Научим.
ОЧ: Хорошие знания Python (структуры данных, декораторы, интеграторы, генераторы, классы и наследование), понимание сложности алгоритмов, базовые знания РСУБД и *nix. Проактивность и желание развиваться.
Никогда не просил кандидатов развернуть бинарное дерево.
АВ: Мы разрабатываем инструменты разработки, поэтому интерес и знания в области языков программирования, компиляторов, статического анализа являются большим плюсом. В нашей работе требуется знание сразу нескольких языков. Если кандидат не знает одного из них, но отлично разбирается в другом, я думаю, он сможет разобраться и в не знакомом ему языке.
— Как вы определяете, что человек не впишется в вашу команду? Есть ли какие-то маркеры (кроме профессионального несоответствия требуемому уровню в вакансии)?
ДШ: Смотрю на soft skills, манеру общения, скорость реакции на вопросы. Не могу сказать, что есть какие-то формальные маркеры. Причем профессиональные скиллы часто отходят на второй план, если человек хороший.
МЮ: Если человек умеет слушать других, учитывает чужое мнение, ответственен, дисциплинирован — скорее всего, мы сработаемся.
И мы за честность. Никаких интриг, слухов, манипуляций, сплетен. Если на собеседовании видим хоть какие-то признаки, сразу нет. Извините, это не про нас.
ОЧ: Самым важным личностным качеством, на мой взгляд, является адекватное восприятие обратной связи. Если на собеседовании становится понятно, что кандидат слишком эмоционально реагирует на критику своей работы, то вряд ли он впишется в команду.
АВ: Может, это прозвучит очевидно, но человек вряд ли впишется в команду при слабых soft skills.
— Самые частые ошибки кандидатов на собеседовании? Как поведенческие, так и технические.
ДШ: Хвастаться. Заводить разговор о том, в чём плохо разбираешься. Считать собеседника идиотом.
МЮ: Опоздание на собеседование. Не люблю, когда опаздывают, это первый признак будущих проблем с дисциплиной.
Иногда кандидаты начинают рассказывать что-то, о чём их не спрашивал. Это далеко не всегда к месту — создается ощущение, что кандидат старается сбить с толку.
ОЧ: Самые частые ошибочные поведенческие паттерны: «интервьюировать интервьюера», замыкаться в себе после первого неправильного ответа, иногда кандидаты начинают уверенно говорить о теме, в которой не разбираются, и после первых неудобных вопросов становится стыдно :)
Со стороны технического интервью: почти никто не знает про frozenset и только небольшой процент кандидатов смог написать параметризированный декоратор.
АВ: Порой кандидаты переоценивают уровень своих знаний: начинают уверенно рассказывать о чём-то, но когда дело доходит до конкретики, могут «поплыть». Некоторые ничего не знают о компании или о продукте, который будут разрабатывать, хотя информация публично доступна и напрямую касается их ближайшего будущего.
— Какой совет вы бы дали соискателю на собеседовании?
ДШ: Не пытайтесь «продать» себя. Показывайте свой уровень честно, демонстрируйте широкий кругозор и желание (и умение) учиться и разбираться в незнакомых проблемах.
Это важнее, чем список «технологий» или «участия в проектах» в резюме.
МЮ: Всегда отвечай честно. Если чего-то не знаешь, стоит прямо об этом сказать. Не набивай себе цену — это видно.
ОЧ: Не теряться, размышлять вслух, потренироваться писать код на бумаге.
АВ: Для многих собеседование — это небольшой стресс: легко запутаться, забыть что-то. Старайтесь рассуждать вслух. Если вы не понимаете условия или ограничения задания, проговорите это вслух, задайте вопросы.
Еще можно почитать советы Остина Белкейка из Майкрософт о том, как легко пройти собеседование
16-17 июля со всеми ребятами можно будет познакомиться на конференции PyConRu. Андрей Власовских объяснит, что может Python на микроконтроллерах, Михаил Юматов расскажет, какие есть инструменты для слежения за производительностью веб-приложений, Олег Чуркин расскажет, какие требования к процессу разработки и инфраструктуре проекта необходимо выполнить, чтобы относительно быстро, эффективно и вполне безболезненно попробовать микро(сервисы). Данила Штань будет ведущим и модератором. Итоговая сетка со всеми докладами готова.
Спасибо нашим спонсорам, которые делают конференцию возможной: золотому спонсору — компании Adcombo, серебряным спонсорам — Rambler&Co и ДомКлик, бронзовому спонсору — MediaScope. Спасибо за поддержку партнеру энергии и хорошего настроения компании ЦИАН и Python Software Foundation.
Комментарии (49)
Lofer
05.07.2017 12:53умение руководить джуниорами и способствовать их росту.
Зачем навыки «умение руководить джуниорами» если есть ПМ и это его работа?
Интересно, а откуда навыки управления и планирования у Senior или по принципу «обезьянка видит — обезьянка делает»? или соблюдение «корпоративых ритуалов» и «строгий Scrum» автоматически порождает хорошего управленца?
Если учесть, что, по хорошему, на управленца, на архитектора, на разрабочика нужно вложить как минимум год… другой обучения учиться — проверить навыки — поучиться еще раз — проверить навыки — готовый ПМ/Архитектор. то как-то это выглядит оптимистично слишкомVolCh
05.07.2017 15:05+1"Сеньор" — по-советскороссийски будет "старший инженер-программист". Эта должность предполагает руководство менее квалифицированными кадрами. Техническое руководство прежде всего. Грубо, ПМы с джунами по техническим вопросам не общаются, первые ставят задачи сеньорам, те декомпозируют и частично делегируют джунам, а то и миддлам.
Caravus
05.07.2017 15:41+4Вы путаете сеньора и тимлида. Да, часто бывает так что эти должности совмещает в себе один человек, но это не одно и тоже.
Lofer
05.07.2017 15:53Техническое руководство прежде всего.
Для технического руководства есть архитектор(ы) :)
Грубо, ПМы с джунами по техническим вопросам не общаются,
первые ставят задачи сеньорам, те декомпозируют и частично делегируют джунам, а то и миддлам.
Грубо говоря все делают то, что скажет ПМ и делают так, как скажут архитекторы.
Это разные роли. Другое дело что отсутсвие квалифицированных кадров вынуждает совмещать кучу ролей в одной персоне. Но это, противоречит, правилам управления :)VolCh
06.07.2017 16:27Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.
Lofer
06.07.2017 17:07Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.
Имелось ввиду не конкретнное задание, а «тут база, тут интерфес такой, тут такая схема и стек технологий такой».
А кто будет делат и когда — «не барское дело» :)
VolCh
06.07.2017 16:33Отправил раньше: времени предыдущий.
Архитекторы разрабатывают архитектуру, а не занимаются техническим руководством джунов.
Другое дело что отсутсвие квалифицированных кадров вынуждает совмещать кучу ролей в одной персоне.
Скорее о недостатке кадров говорит то, что ПМ и архитектор за каждым джуном бегают. При нормальной организации работ как раз на объёмную задачу создаётся временная группа инженеров под технический руководством старшего (вариант — ведущего) инженера, а ПМ и архитектор осуществляют лишь общий контроль и разруливают вопросы вне рамок задачи или вопросы взаимодействия между такими группами.
Это как в армии: "Иванов, Петров и Сидоров сегодня копают яму отсюда и до обеда. Иванов за старшего".
balexa
05.07.2017 20:33+1Потому что когда ПМ поручает какой-то фронт работ сеньору Васе, мидлу Диме и джунам Пете и Маше, то априори подразумевается, что отвечать за результат будет именно Вася.
А это значит, что именно Васе придется как-то разделить работу, назвать примерное время выполнения, заложить туда объяснение и обучение джуниоров, что автоматом подразумевает какие-то навыки управления и планирования.
ПМ не может этого делать, хотя бы потому что он гораздо хуже знает технические детали.Lofer
05.07.2017 20:55Потому что когда ПМ поручает какой-то фронт работ сеньору Васе, мидлу Диме и джунам Пете и Маше, то априори подразумевается, что отвечать за результат будет именно Вася.
Странная модель управления в виде делегирования роли управленца.
Нормальный ПМ (менеджер проекта) обычно консультируется и с Васей и с Петей перед тем как провести оценку задач и рисков, сбаласировать ресурсы, что бы критический путь попадал в ожидания Заказчика. А если не попадает то найти ресурсы или как-то решать это вопрос с клиентом.
Можно понять, что Вася скажет «технические риски не оценены (хз как делать)» или «не приняты меры для ...». перед тем как стартануть.
Можно Васю вздрючить, что не провел codereview, хреново логирование сделал, или еще какие метрики или процессы производства нарушены после того как…
Вася то тут в чем ответственный в планировании? Какие у него инструменты?balexa
05.07.2017 21:27+1Да нет тут делегирования роли. Отвечать перед руководством будет ПМ в любом случае. И про ответственность за планирование я не писал.
Я лишь хотел сказать, что в задачу сеньора, входит в том числе
- разбиение глобальной задачи на подзадачи — ПМ не может этим заниматься, поскольку не имеет достаточной технической экспертизы и не понимает что надо сделать для «добавить кнопку на сайт»
- примерная оценка трудозатрат и озвучивание их ПМу — опять таки, странно считать сеньором
человека который не способен оценить что именно надо сделать для решения задачи - обучение джуниоров. Кто-то же должен их учить и объяснять почему так можно делать, а так нельзя. Опять таки, ПМ этим заниматься не способен
- оценка технических рисков, да.
Это все относится к навыкам планирования и в какой-то степени управления.Lofer
05.07.2017 21:47разбиение глобальной задачи на подзадачи — ПМ не может этим заниматься, поскольку не имеет достаточной технической экспертизы и не понимает что надо сделать для «добавить кнопку на сайт»
Делать должен ПМ, используя доступные ресурсы и инструменты. Senior тут такой же тулз как Excel :)
примерная оценка трудозатрат и озвучивание их ПМу — опять таки, странно считать сеньоромчеловека который не способен оценить что именно надо сделать для решения задачи
Задача " оценить сделать кнопку" это не есть планирование. Это небольшая часть :)
обучение джуниоров. Кто-то же должен их учить и объяснять почему так можно делать, а так нельзя. Опять таки, ПМ этим заниматься не способен
Это личная проблема конторы, и в частности работа ПМ что делать с рисками «не умеют и не знают» — курсы-лекции-тренинги-расстрелы- и т.д.
оценка технических рисков, да.
Не оценка рисков, а идентификация рисков. и опять же процесс управления рисками — проблема ПМ. Senior один из возможных тулзов.balexa
05.07.2017 22:09+1Senior тут такой же тулз как Excel :)
Нет конечно. Вот на пальцах
Поставлена задача — добавить кнопку. Это именно задача сеньора сказать, что для данной кнопки надо будет менять базу, бакенд, объяснить что нельзя просто добавить колонку в таблицу, потому что у кастомеров стопицот записей в этой таблице. Как это все заменить экселем, лично мне непонятно.
Задача " оценить сделать кнопку" это не есть планирование. Это небольшая часть
Я и не говорил что планирование == «оценить сделать кнопку». Я писал, что для оценки трудоемкости создания кнопки какие-то навыки планирования необходимы. Не пойму, о чем спор.
Это личная проблема конторы, и в частности работа ПМ что делать с рисками «не умеют и не знают» — курсы-лекции-тренинги-расстрелы- и т.д.
Я правильно вас понимаю, что где-то конторы, которые посылают своих джуниоров на лекции-курсы-тренинги и получают оттуда матерых сеньоров?
В моем мире к сожалению такое редкость, обычно джуны приставляются в команду к более старшим разработчикам и там осваивают навыки.
И соответственно, от Васи требуется достаточное количество навыков руководства-обучения-софтскиллов — называйте это как хотите, чтобы увидев косяк на ревью не орать что Петя профнепригоден и ему нельзя давать ничего кодить, а спокойно и аргументированно объяснить в чем недостаток решения и что надо исправить.
Не оценка рисков, а идентификация рисков
Это игра слов. В реальной жизни разница между этими понятиями весьма размыта.
процесс управления рисками — проблема ПМ.
Я разве спорю?Lofer
05.07.2017 22:31Senior тут такой же тулз как Excel :)
Нет конечно. Вот на пальцах
Поставлена задача — добавить кнопку. Это именно задача сеньора сказать, что для данной кнопки надо будет менять базу, бакенд, объяснить что нельзя просто добавить колонку в таблицу, потому что у кастомеров стопицот записей в этой таблице. Как это все заменить экселем, лично мне непонятно.
В нормальной конторе, ПМ поднимет документацию, пнет ВА & архитектора и они выдадут перечень решений-изменений, потом с Senior-ом разработки проставят таски и оценки разработки, потом с QA оценят тесты. А потом ПМ будет в одиночестве раскладавать «пасьянс», что бы у ресурса не получилось 36 рабочих часов в день или не расползлась вся простынка. потом бюджеты и сроки прочее…
Я правильно вас понимаю, что где-то конторы, которые посылают своих джуниоров на лекции-курсы-тренинги и получают оттуда матерых сеньоров?
Может быть удивлю, но бывают/знаю конторы, что организовывали внутри тренинги, обучали своих сотрудников, периодически проводят последующую «переоценку» работников-активы с повышением зарплаты. Иногда оплачивают обучение и сертификацию работника с последующим повышением.
Это игра слов. В реальной жизни разница между этими понятиями весьма размыта.
Смешно :) Однажда граница этого размытия была порядка 15 миллионов долларов, другой раз ошибка порядка 3 месяцев планирования-исполнения :) Так что это конкретный порядок действий с конкретными результатами.
Вы слишком упрощенно представляете работу ПМ :)balexa
05.07.2017 22:49ПМ поднимет документацию, пнет ВА & архитектора и они выдадут перечень решений-изменений, потом с Senior-ом разработки проставят таски и оценки разработки,
Я не очень понял, зачем вам тут сеньор на этом этапе. Ну и если уж мы коснулись оценок разработки, за это сеньор отвечает хоть?
Вместо вас заранее напишу, что умение проставлять таски и оценки разработки это не есть планирование. Это небольшая часть.
Может быть удивлю, но бывают/знаю конторы, что организовывали внутри тренинги, обучали своих сотрудников, периодически проводят последующую «переоценку» работников-активы с повышением зарплаты. Иногда оплачивают обучение и сертификацию работника с последующим повышением.
Вы с чем спорите, еще раз спрошу? Я тоже знаю конторы которые регулярно посылают своих сотрудников на тренинги, курсы, да и сам работаю в такой.
Речь шла о том, что тренинги далеко не единственное, что требуется для обучения джуниоров. И даже не основное.
Смешно :) Однажда граница этого размытия была порядка 15 миллионов долларов, другой раз ошибка порядка 3 месяцев планирования-исполнения :) Так что это конкретный порядок действий с конкретными результатами.
Вы решили помериться достоинством, у кого риски и ошибки были больше, или что? Во первых вы не знаете где я работаю и какие суммы проходят через системы в разработке которых я принимал участие и сколько эти системы стоят, во вторых вы как-то перепрыгиваете с тезиса на тезис. Я слабо понимаю как эта ваша прохладная история о потерях относится к обсуждаемой теме.
Напомню, мой изначальный тезис был что для сеньора необходимо иметь навыки планирования, руководства и обучения.
Вы слишком упрощенно представляете работу ПМ :)
Я вообще про нее ничего не говорил.
Вы уже который раз в данной дискуссии приписываете мне какие-то тезисы и аргументы и с жаром их опровергаете. Это какая-то демагогия.Lofer
05.07.2017 23:14далеко не единственное, что требуется для обучения джуниоров. И даже не основное.
Вопрос был «является ли обучение ответственностью Senior-ов ?» Оказывается есть нормальные механизмы исключающие Senior-ов из этого, по крайнй мере в рамках проекта.
Во первых вы не знаете где я работаю и какие суммы проходят через системы в разработке которых я принимал участие и сколько эти системы стоят,
Нет. не знаю. Но трактовать «оценка рисков… идентификация рисков» как «Это игра слов.» аргументируя «В реальной жизни разница между этими понятиями весьма размыта.» с учетом того, что на это есть стандарт и сертифкация, это весьма смелое утверждение.
Напомню, мой изначальный тезис был что для сеньора необходимо иметь навыки планирования, руководства и обучения.
Тогда обозначьте границы — сheck list с объективными методолгиями оценки :)
Коммуникационные навыки это вопрос психологи и они субъективны.
RomanArzumanyan
05.07.2017 14:23+10Самые частые ошибочные поведенческие паттерны: «интервьюировать интервьюера»
Что в этом плохого? Хочется знать, с кем потенциально предстоит работать.
Bahusss
05.07.2017 16:28-2Эта фраза относится к кандидатам, которые после нескольких неудачных ответов на вопросы, пытаются проверить технические знания интервьюера, что выглядит слегка наивным «ах вот ты как? а сам то сможешь ответить?».
К вопросам про работу\процессы после интервью это конечно не относится.
Кстати часто собеседуют не те люди, с которыми предстоит работать и это тоже стоит иметь ввиду.RomanArzumanyan
05.07.2017 16:54+4ИМХО, на должность senior'а и выше, интервьюировать непосредственного руководителя совершенно необходимо (если это технический спец). Нужно быть уверенным в тех людях, с кем предстоит работать.
Bahusss
05.07.2017 16:57+2Какие вопросы вы бы задали непосредственному руководителю, чтобы быть в нем уверенным?
RomanArzumanyan
05.07.2017 17:58-1Из той области, которой занимаюсь: как определить тип памяти видеокарты (дискретная либо общая с CPU), не запрашивая свойств самой видекарты?
Правильный ответ: сделать отображение участка памяти из адресного пространства GPU в CPU и обратно. Если время преобразования не зависит от размера участка памяти, то физически память общая. В противном случае — либо память дискретная, либо общая, но представление объектов в памяти иное (например, тайловое вместо построчного и т. п.).habradante
05.07.2017 18:11Это то, в чем должен разбираться руководитель чтобы исполнять свои обязанности?
RomanArzumanyan
05.07.2017 18:51Да, в конкретном рассматриваемом случае. Развёрнутый ответ — под комментарием Bahusss.
Bahusss
05.07.2017 18:14Понятно. Это тот тип вопросов, который не стоит спрашивать на собеседовании :)
Ваш будущий руководитель совсем не обязан разбираться в каких-то определенных технических тонкостях. По разным причинам. Например он хочет нанять вас, чтобы вы смогли усилить его команду с вашими знаниями в нужных технологиях. Более подробно этот момент описан в книге «Как пасти котов» Дж. Рейнвотера.habradante
05.07.2017 18:21В Российских реалиях, руководитель видится лидером во всем. И команда зачастую ждет доказательства его состоятельности. В Европе и Штатах зачастую команда удовлетворяется просто тем что им говорят «вот Боб, он ваш начальник». В России после этого идет проверка руководителя «на прочность».
У нас, пока, не все понимают что руководитель не должен быть круче всей команды, он должен исполнять другие обязанности с другими компетенциями.
Думаю, это исходит из того что начальником часто назначали самого выдающегося работника, не глядя на то, что теперь он должен выполнять совсем другие обязанности. Ну и сам по себе менеджмент в России не так давно появился, как отдельная дисциплина.
RomanArzumanyan
05.07.2017 18:38Это базовые знания в целевой области. Если их нет, то работать вместе будет трудно.
Я не представляю себе performance architect'а (моего руководителя), который не знает таких вещей. Или с такими performance architect'ами лучше не связываться. Он просто не будет понимать, чем я занят в рабочее время.habradante
05.07.2017 19:16+3Наверное, у нас разное понятие руководителя. По-моему, архитектор это не руководитель. Но, это по-моему.
RomanArzumanyan
05.07.2017 19:56Скажем так, это человек, который ставит задачи и оценивает результаты работы. Я могу охарактеризовать такого человека, как моего непосредственного руководителя. Собственно, он и проводит техническую часть собеседования.
Если говорить о «чистых» менеджерах, которые не решают инженерные вопросы (тем не менее, являются начальством), то с ними, конечно, нет смысла говорить на исключительно технические темы. Но этот момент был отмечен в исходном комментарии.
balexa
05.07.2017 20:46+1Само собой. Руководитель не обязан разбираться в технологиях. Но хороший руководитель, который не разбирается в технических тонкостях, не будет проводить техническое интервью по данной теме. Если человек проводит техническое интервью, то почему бы не спросить у него технические вопросы?
Bahusss
05.07.2017 21:03+1Сколько вопросов вы зададите интервьюеру, чтобы понять насколько он технически подкован? Почему он должен отвечать на ваши вопросы, если на интервью пришли вы а не он?
Конечно технические вопросы нужно задавать и на это обычно дают время в конце интервью, но спрашивая узкие технические вопросы, вы скорее всего потратите время и не узнаете то что действительно важно. Пример с вопросом про видеокарту именно такой.
В комментарии ниже вы привели пример хорошего вопроса после интервью, а еще можно спросить – какие архитектурные проблемы сейчас есть у проекта? как их планируют решать? почему выбрали именно такой стек технологий? как устроен процесс разработки (кто ставит задачи, есть ли тестирование)?
Это тоже хорошие вопросы, которые позволяют понять и техническую развитость компании\команды, культуры разработки и проблемы над которыми нужно будет работать.
balexa
05.07.2017 21:52+2Почему он должен отвечать на ваши вопросы, если на интервью пришли вы а не он?
А почему бы и нет? Мне хочется узнать уровень людей, с кем мне предстоит работать. Не только вы выбираете из соискателей, соискатель тоже выбирает из кучи предложений. Подобное допустимо если вы какой-нибудь гугл или можете предложить в два раза больше чем все остальные. Рамблер контора конечно крупная, но далеко не верх карьеры и мечтаний для хорошего программиста.
В комментарии ниже вы привели пример хорошего вопроса после интервью
Это вопрос задается если на собеседовании были такие же вопросы.
Если там были задачи из спортивного программирования, причем такие, ответ на которые невозможно придумать за 20 минут, не зная алгоритма или вопрос на знание тонкостей реализации какой-либо библиотеки (особенно когда эти тонкости редко когда могут понадобиться и любой вменяемый программист способен узнать их почитав исходники или доку/СО), то почему бы и соискателю не спросить аналогичный вопрос?
Из моей практики подобные вопросы задаются в основном для повышения ЧСВ интервьюера и для того чтобы прогнуть собеседуемого по зарплате.
Lofer
05.07.2017 17:49Эта фраза относится к кандидатам, которые после нескольких неудачных ответов на вопросы, пытаются проверить технические знания интервьюера, что выглядит слегка наивным «ах вот ты как? а сам то сможешь ответить?».
Может это не «злой умысел», а банальное не совпадение «глоссария» общающихся. Вполне уместная попытка собрать общий глоссарий и продолжить общение. Может несколько корявая.
А если возникает такая защитная реакция на собеседований, то явно что-то не так и возможно с обеих сторонBahusss
05.07.2017 18:19Вспомнив несколько таких случаев, могу сказать, что чаще всего такая защитная реакция возникает у излишне самоуверенных кандидатов, которые не очень показывают себя на интервью.
На мой взгляд такое поведение подтверждает наличие проблем с теми самыми «soft skills» у кандидата и поэтому я отнес его к «антипаттернам».
balexa
05.07.2017 20:44+2Понятно что после такого вопроса уже никакого оффера не состоится, но по моему это вполне нормально если интервьюер задает всякие пазлы и справочные данные.
Я так делал несколько раз, просто для развлечения, в ответ спрашивал знакомые мне пазлы и справочные данные. Это такой троллинг вживую, не очень корректный возможно, но тем не менее.
Второй вариант тоже возможен. Когда на вопрос «А вы сказали что у вас X используется. Мы ее тоже пробовали, и у нас вылезла вот такая проблема, вы как это обошли?» Это тоже вполне нормальный технический вопрос, мне хочется узнать, насколько там адекватные люди работают, а может и просто интересно.
habradante
05.07.2017 17:37Думаю, тут имеется в виду когда собеседуемый вместо ответа на вопрос, или не отвеитв на него начинает «а ты сам знаешь frozenset, а докажи?».
PolinaRuRu
05.07.2017 15:37+6Если бы дали выбор у кого проходить собеседование, то выбрала бы Данилу Штань. Самый адекватный, имхо, в рамках такого опросника.
Не знаю почему, но именно после собеседований с людьми с похожими взглядами, брали на работу. :)
dcheremnov
07.07.2017 07:50>> АВ: Я обращаю внимание на сочетание самостоятельности, увлечения программированием и готовности к командной работе.
Согласен на 100%.
Многие замыкаются только на языке программирования.
Наш начальник в первую очередь при приеме на работу юниора проверяет навыки командной работы,
если новичок не умеет/не хочет работать в команде, то мало чему научиться…
А для командной профессиональной разработки требуются дополнительные компетенции и базовые навыки процесса разработки.
Можете проверить свои компетенции (и если подпишитесь на рассылку, то изучить их):
http://it-check-list.asvoip.com
Lofer
07.07.2017 09:20Наш начальник в первую очередь при приеме на работу юниора проверяет навыки командной работы,
А как это проверяется, если человек еще молодой и не опытный? Это при собеседовании или во время испытательного срока?
Germanets
07.07.2017 14:17Какие-то способности и склонности будут видны даже при собеседовании, ведь человек в любом случае уже имеет какой-то опыт общения с другими людьми, совместного решения задач. В том же вузе частенько попадаются коллективные задания и т.д.
Ну и тут главное не то, что человек хорошо умеет это делать, а чтобы у него не было явного нежелания этим заниматься, что не позволит в дальнейшем нормально выстроить общение в команде.Lofer
07.07.2017 22:07То есть применяются субъективные критерии, и в лучшем случае «экспертная оценка» группой из нескольких коллег.
Понятно, спасибо.
VolCh
Как-то "soft skills" звучит так, что не имеет никакого отношения к софту. Новая эйчаровская "ачивка", вместо традиционного "трудолюбив, целеустремлён, адекватен, обучаем"?
Caravus
Да, под «soft skills» обычно понимают навыки общения.
Ramm
Да, просто это короче. :)
https://en.wikipedia.org/wiki/Soft_skills
Alexeyco
Я все ждал, когда про умение
писатьчитать чужой код пластинка заиграет.