Совет свой себе посоветуй. Вопросы на собеседованиях

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

Почему нужен еще один человек: ответ может быть любым, и за каждым может скрываться что угодно. и поверьте, любой менеджер точно знает, что разработка идет медленно. А вот с какой скоростью она должна идти -- это философский вопрос 21 века. потому что c одной стороны есть план, а с другой -- большой мир с конкурентами. И если найм дополнительного человека в команду даст буст в скорости, пусть и не сразу, то это уже имеет смысл. мир в любом случае меняется и движется быстрее, чем разработчики код пишут. ну, увы. вот про проблемы, которые надо решить -- вопрос хороший. как ее ускорить? вот они подумали и открыли вакансию. А е*учая случайность найма это только в компаниям с инверсторскими бабками. Потому что в других случаях идти к фаундеру и CFO объяснять, что надо потратить еще немного их денег, никто не горит желанием.

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

Как оценивать: ну вообще оценивают по результату. окей, в большинстве случаев. А вот если есть вопросы к результатам, тогда начинаются вопросы к процессам и скиллам. в наше время удаленки это все более очевидно, как ни странно. и я вам тайну открою, если справляешься с задачами за 4 часа вместо 8, всем пох*й и никаких вопросов. если в компании есть, чем тебя озадачить -- это будет сделано. если нет -- хочешь в игры играй, хочешь серфи, хочешь -- ищи вторую работу. А что до системы оценки -- вы не поверите, но она есть везде. Даже там, где не описана и не формализована. Поэтому этот вопрос хорош не для того, чтобы "е*ать", а для того, чтобы понять, совпадает ли ваша собственная система оценки с системой компании. Холиварам на тему оценки разработки уже лет 20, так что вам надо только понять, одними ли попугаями вы будете мерять результат.

Как они понимают, что их код говно? Кто они? Менеджеры? Это они что ли код писали? Или разработчики? Но тогда почему они воняют? Сами же сделали говно. Окей, сейчас вы скажете, что вообще-то разрабы всегда хотят писать качественно и с учетом роста продукта, но злобные менеджеры хотят на вчера и выбирают костыли. Да. Но эй, качество кодовой базы -- прямая ответсвеность СТО и тех же разрабов. Так что тут опять какой-то самоподкоп случился. И это задача команды и менеджера планировать рефакторинг и закладывать на него время.

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

Как увольняют полезно узнать, чтобы понять, чего ждать, и есть ли шанс получить нотис день в день. Но вот на счет "увольнение -- обсер компании". А автор в курсе, что сейчас на рынке есть куча людей, которые устраиваются на оплачиваемый и.с на три работы, заранее зная, что их уволят? А в курсе ли он, что сейчас смена работы -- дело смены акка в слаке? И что не маленькая часть людей считает, что в пока в ИТ платят дофига, надо менять работу раз в 3-6 месяцев с прибавкой в 25-50%? нет? Так что на счет обсера вопрос открытый. Правда, если перенести его на уровень выше и сказать, что в таких случаях надо править систему оценки на собесах, я соглашусь и поддержу.

Мораль: все не идеальны. Да. Все не идеальны. И кандидаты тоже. И некоторые неидеальности великолепно друг друга дополняют. А другие идеальности не могут найти общий язык. Так что давайте перестанем смотреть друг на друга с мыслью как бы нае*ать визави и начнем искать свои, подходящие нам, неидеальности. И научимся наконец говорить, если нам что-то не нравится/непонятно, возьмем ответственность и на себя тоже. И тогда мир станет лучше, и уж точно интереснее.

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