Ваши вопросы к представителям компании на собеседовании - очень важный этап. Он же может стать решающим. Я как то на собеседовании в Мету на менеджера спросил могу ли я уволить всю команду в один день и нанять новую. В те далекие долэйофные годы следующего этапа не последовало. Это был один из вопросов Бугаенко "на менедждера", в Лондон я переезжать не планировал поэтому ради прикола решил спросить. Один раз живем. Так вот. По следам треда @beshenadze решил написать, что стоит спрашивать, а какие вопросы стоит задавать когда уже пройдете испытательный срок. Во-первых: совершенно точно нужно задавать вопросы! Особенно если вы идете на сеньорную позицию. Если у вас нет вопросов - это очень плохой сигнал:  Вы читали про компанию и ее бизнес? Вам совсем не важно как с кем и с чем вы будете работать? Ничего не хотите добавить к своим ответам? Что точно не стоит спрашивать Давать непрошеные советы и критиковать выбор людей. Даже если мягко. Во-первых у тебя околонулевой контекст. Даже если ты изначально спросил какая у них платформа (хороший вопрос), а потом начинаешь критивовать и сокрушаться, что они все выбрали не правильно. Тебе скорее всего ответили прямым ответом: У нас технология Х. У тебя нет необходимых данных, метрик и причин почему у них так. И за одну минуту ответа ты не сможешь открыть тупым глаза на их ошибки и заработать авторитет. Но ты можешь показать, что ты с порога несогласен. Начинаешь давать советы неразобравшись. Зачем тебя брать если ты уже недоволен с чем тебе придется работать? На собеседовании ты продаёшь не только экспертизу, но и предсказуемость. Компания (особенно если это уже работающий бизнес, а не совсем зелёный стартап) хочет понять: Ты сможешь встроиться в существующую систему? Ты будешь решать их проблемы или создавать новые? Ты уважаешь чужой контекст или сразу начинаешь мерить всё своей меркой Критиковать само собеседовение тоже не стоит. Особенно в лицо людям, которые к дизайну собеседования не имеют отношения. Как например спрашивать, пишут ли программисты алгоритмы каждый день на работе? Кому что кроме своей раздражительности ты этим вопросом хочешь показать? Особенно если ты НЕ МОЖЕШЬ решить задачу. Что стоит спрашивать На собесе ты исследователь и дипломат. Молчать совершенно точно нельзя, а задавать качественные вопросы, которые показывают сеньорность. Если ты молчишь и только киваешь, ты выглядишь как исполнитель, а не как человек, который будет влиять на архитектуру. Хороший баланс — задавать вопросы, которые раскрывают ситуацию, а не оценивают её. Про нагрузку и масштаб «Какая сейчас нагрузка? Какие планы по росту на год-два?» Про текущие боли «Какие самые болезненные проблемы прямо сейчас в инфре/деплое/костах?» Про структуру команды «Как устроена команда? Кто принимает архитектурные решения? Как выглядит процесс изменений?» Про бизнес-контекст «Какие требования бизнеса сейчас важнее всего: скорость фич, косты, надёжность?» Про квалификацию и процессы «Какой уровень экспертизы в команде по платформе/куберу/терраформу?» Про историю развития «Это первая версия системы? Как бы выглядела идеальная система для этой задачи? Какие риски в текущей архитектуре вы видите?» Можно урвать эти 5 минут и наоборот уточнить свой ответ, если вы осознали, что что-то недосказали. Этой возможностью вообще довольно редко пользуются. Самый сильный сигнал сеньорности — это когда ты: задаёшь точные вопросы; демонстрируешь, что понимаешь компромиссы; оставляешь пространство для того, что у них могут быть на все веские причины о которых тебе не рассказали. На собеседовании твоя главная задача — собрать максимум информации и показать, как ты думаешь, а не «спасти» компанию от страшной ошибки за 5 минут. А уже после оффера (или испытательного срока), когда ты внутри и у тебя есть полный контекст и выстроены отношения блядь, — можно и нужно спорить, отстаивать свою точку зрения.

За что платят программисту? Когда я был frontend-разработчиком, я писал код весь рабочий день в таком цикле: задача-реализация-задача. Свободного времени почти не оставалось, и мне казалось, что так и выглядит работа программиста. Сейчас я делаю фронт, бэк, инфраструктуру, мониторинг, разбираю проблемы на проде. Обязанностей стало больше, и они почти все технические 🙃 Но если посчитать часы, то на само написание кода уходит меньше 1/3 рабочего дня. Всё остальное это обсуждения, созвоны, скрам-церемонии, споры о том, каким должно быть решение.

Мне платят деньги не за код.

🧑‍💻 Моя ценность как сотрудника в другом. - Я понимаю, как устроена система, могу объяснить это команде и вместе с ними принять решение, за которое потом никто не будет отдуваться. На ответственных позициях требуют именно максимальной активности в обсуждениях, где решается, куда пойдёт проект. А не молча закрыть свой тикет. Мидл обычно думает, что до сеньора ему не хватает технологий "Выучу ещё фреймворк, ещё базу, буду писать хороший код - и на ревью" 🤞 Я тоже так думал. Но разница в том, что cеньор смотрит на задачу со стороны бизнеса и умеет это донести словами, а не только коммитом. 🧰 Сколько технологий ещё нужно выучить? Возможно, дело уже не в них. Стоит выйти за пределы своих задач: разобраться, как устроен проект целиком, вслух объяснять свои решения на ревью и обсуждениях и помогать людям в команде. Звучит не так эффектно, как новый фреймворк в резюме. Но именно это в какой-то момент начинает отражаться на зарплате :) — А сколько часов в день у вас уходит на код? Интересно сравнить. #карьера · yt · tg · ig