Итак, вы потратили 20 минут на ознакомление с репозиторием согласно двум предыдущим постам. Теперь самое время вызвать автора на разговор. На самом деле он довольно скриптовый и все вопросы можно напечатать на листочке. На большинство вопросов правильного ответа нет и они идут по критерию убедил/не убедил. Чем-то смахивает на продажи, но темы чисто технические, да и вообще: собеседование в этом случае полу-продуктовое и это норм. Если чел сечёт и в продуктовой и в технической части - ценный кадр, берите. Короче, разговор обещает быть продуктивным.
Вопрос №0: зачем? Какая задача решается?
Хороший инженер должен прекрасно понимать назначение своей разработки: как она упрощает жизнь и зачем в это ввязываться. Если человек сам не понимает, или решает несуществующую задачу, или сделал проект "по приколу" — зелёненький ещё. Правильного ответа нет, но ясно одно: человек должен чётко себе представлять зачем он делает то, что делает. Какую задачу его продукт решает.
Вопрос №1: кто ваши конкуренты? Чем они хуже?
Это любимое "а ты готовые решения погуглил?", поданное чуть сбоку. Готовое сейчас есть для всего, но у человека могут быть свои представления о прекрасном. Пусть изложит их. Если у кандидата есть целостное видение — лично я такое покупаю. А если "ниасилил" и прочее not invented here — не покупаю. Не стоит впадать в маразм и с порога орать "есть готовое — возьми!". Помните, что React и Angular — взаимные велосипеды. Конкуренция — штука хорошая, но должны быть и конкурентные преимущества.
Вопрос №2: назовите недостатки вашего решения.
Здесь мы проверяем знание своего же продукта и, внезапно, ЧСВ. Не торопите с ответом. Привёл технические недостатки - молодчик, хороший разраб. Привёл продуктовые недостатки — молодчик, хороший продакт. Не видит недостатков — фейл. Хорошие разрабы часто не видят продуктовых недостатков и в большинстве случаев это признак самолюбования. Вера в свой продукт похвальна, но надо понять насколько человек в контакте с реальностью. Вопрос основан на открытом мною лично рычаге "порог входа/функциональность": если продукт перебивает конкурентов по функциональности, то достигается это высоким порогом входа. И наоборот: ниже порог входа — меньше функциональности. В любом случае один из двух недостатков есть: продукт или сложный или нефункциональный. Неплохо, если автор это понимает. Бывает и то и другое. И это печально.
Вопрос №3: чему вы научились в ходе работы над этим проектом?
Многогранно. Отлично проверяет "горящие глаза". Хороший разраб всегда найдёт что рассказать. Как по технической части, так и по продуктовой. Тут у вас будут вводные чтобы оценить проактивность, посмотреть на ценности человека, а так же на потенциальное направление развития: начал про код лечить - супер, берём, вырастет в архитекта. Начал про продукт - супер, хватай будущего манагера. Сказал и про то и про другое — упс, ваше кресло в опасности. Начал задвигать про важность коммуникаций и маркетинг — это продаван, смотрим с пренебрежением.
Далее задаём вопросы из блокнотика, которые записаны на предыдущих этапах. Важны не столько сами ответы, а то, как автор воспринимает вопросы. По сути мы уже знаем, что человек может в код и пытаемся выяснить его, будьте вы прокляты, софт-скиллы. Слушайте внимательнее, смотрите зорче, делайте выводы, сопоставляйте со своим видением прекрасного. Вот и все дела.
Напоследок, один важный момент: человеку, который уже реализовал что-то своё писать код может быть тупо неинтересно и взятие его на должность разраба при невозможности предложить бОльшее — плохая затея. Это также валидная причина для отказа. Называется overqualified. Так бывает и в этом случае постарайтесь не мучать человека почём зря, а поблагодарить за уделённое время, похвалить и с сожалением признать что не осилите.
Итак, вы потратили 20 минут на ознакомление с репозиторием согласно двум предыдущим постам. Теперь самое время вызвать автора на разговор. На самом деле он довольно скриптовый и все вопросы можно напечатать на листочке. На большинство вопросов правильного ответа нет и они идут по критерию убедил/не убедил. Чем-то смахивает на продажи, но темы чисто технические, да и вообще: собеседование в этом случае полу-продуктовое и это норм. Если чел сечёт и в продуктовой и в технической части - ценный кадр, берите. Короче, разговор обещает быть продуктивным.
Вопрос №0: зачем? Какая задача решается?
Хороший инженер должен прекрасно понимать назначение своей разработки: как она упрощает жизнь и зачем в это ввязываться. Если человек сам не понимает, или решает несуществующую задачу, или сделал проект "по приколу" — зелёненький ещё. Правильного ответа нет, но ясно одно: человек должен чётко себе представлять зачем он делает то, что делает. Какую задачу его продукт решает.
Вопрос №1: кто ваши конкуренты? Чем они хуже?
Это любимое "а ты готовые решения погуглил?", поданное чуть сбоку. Готовое сейчас есть для всего, но у человека могут быть свои представления о прекрасном. Пусть изложит их. Если у кандидата есть целостное видение — лично я такое покупаю. А если "ниасилил" и прочее not invented here — не покупаю. Не стоит впадать в маразм и с порога орать "есть готовое — возьми!". Помните, что React и Angular — взаимные велосипеды. Конкуренция — штука хорошая, но должны быть и конкурентные преимущества.
Вопрос №2: назовите недостатки вашего решения.
Здесь мы проверяем знание своего же продукта и, внезапно, ЧСВ. Не торопите с ответом. Привёл технические недостатки - молодчик, хороший разраб. Привёл продуктовые недостатки — молодчик, хороший продакт. Не видит недостатков — фейл. Хорошие разрабы часто не видят продуктовых недостатков и в большинстве случаев это признак самолюбования. Вера в свой продукт похвальна, но надо понять насколько человек в контакте с реальностью. Вопрос основан на открытом мною лично рычаге "порог входа/функциональность": если продукт перебивает конкурентов по функциональности, то достигается это высоким порогом входа. И наоборот: ниже порог входа — меньше функциональности. В любом случае один из двух недостатков есть: продукт или сложный или нефункциональный. Неплохо, если автор это понимает. Бывает и то и другое. И это печально.
Вопрос №3: чему вы научились в ходе работы над этим проектом?
Многогранно. Отлично проверяет "горящие глаза". Хороший разраб всегда найдёт что рассказать. Как по технической части, так и по продуктовой. Тут у вас будут вводные чтобы оценить проактивность, посмотреть на ценности человека, а так же на потенциальное направление развития: начал про код лечить - супер, берём, вырастет в архитекта. Начал про продукт - супер, хватай будущего манагера. Сказал и про то и про другое — упс, ваше кресло в опасности. Начал задвигать про важность коммуникаций и маркетинг — это продаван, смотрим с пренебрежением.
Далее задаём вопросы из блокнотика, которые записаны на предыдущих этапах. Важны не столько сами ответы, а то, как автор воспринимает вопросы. По сути мы уже знаем, что человек может в код и пытаемся выяснить его, будьте вы прокляты, софт-скиллы. Слушайте внимательнее, смотрите зорче, делайте выводы, сопоставляйте со своим видением прекрасного. Вот и все дела.
Напоследок, один важный момент: человеку, который уже реализовал что-то своё писать код может быть тупо неинтересно и взятие его на должность разраба при невозможности предложить бОльшее — плохая затея. Это также валидная причина для отказа. Называется overqualified. Так бывает и в этом случае постарайтесь не мучать человека почём зря, а поблагодарить за уделённое время, похвалить и с сожалением признать что не осилите.
How to Create a Private or Public Channel on Telegram? Informative Telegram iOS app: In the “Chats” tab, click the new message icon in the right upper corner. Select “New Channel.” To delete a channel with over 1,000 subscribers, you need to contact user support Telegram has announced a number of measures aiming to tackle the spread of disinformation through its platform in Brazil. These features are part of an agreement between the platform and the country's authorities ahead of the elections in October.
from us
