За все задачи, что поступают мне ответственен я, пока они не будут выполнены, либо пока на 100% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами.
Очень классная формулировка 👍 Как раз хорошо видно подход: довести до результата, а не просто передать дальше.
Более интересный вопрос не "кто виноват", а что с этим делать.
Либо принять ограничения системы, либо пытаться её менять. Но это другая большая и сложная тема. Немного затрагивал ее в прошлой статье: https://habr.com/ru/articles/719352/.
Спасибо за идею, попробую раскрыть ее в будущих статьях.
Скорее не согласен. Как раз пытался подсветить, что наша главная цель, чтобы конечный клиент получил решение своей проблемы. А попытка ограничить свою зону маленьким куском - заканчивается обычно тем, что тикеты просто закрывают без решения.
1) Взяли на себя ответственность за свою часть. Это очень хороший сигнал. 2) Фраза "в области здравого смысла" - это прямо топ и с такими людьми и хочется работать. 3) Показали, что есть опыт - брать на себя ответственность. 4) Показали какие ограничения у вас есть. (Что очень логично, чтобы бэк хорош в бэке, не во фронте и в бизнес части). 5) Показали, что умеете писать тесты.
Интересный вопрос. И вот тут как раз и возникает та самая ситуация. Если никто не возьмет на себя ownership проблемы, то пользователь так и будет с проблемой. Если тикет не закрывать, а позвать тимлида помочь с кросс-командной проблемой / проблему с другими организациями - это уже здорово и хорошее решение.
В блоке про тимлида - то, что он возьмет на себя решение проблем - это здорово. Ответ - "Я", это хороший ответ. Но поверх этого ответа важно, чтобы он умел себя масштабировать. Чтобы не в одно лицо решать все проблемы, а чтобы подключаться только в тех ситуациях, где без его помощи не справляются.
А вот тут думаю вопросы хорошо подходят. Если в ответе будет про TLA+ и chaos engineering, то это хорошее начало обсуждения для понимания инженерной зрелости.
"упирается в невозможность осуществления необходимых изменений из-за линейности своей должности."
Да, согласен, неприятная и сложная ситуация. На практике помогают идеи из моделей внедрения изменений: искать точки влияния, союзников и постепенно расширять зону ответственности.
Если вдруг нужна будет помощь - пишите в директ, попробую помочь.
Да, согласен, в идеале лучше поработать с человеком и посмотреть в деле.
Но на этапе найма у нас всегда есть ограничение по времени, поэтому приходится проводить первоначальный "скрининг".
Для меня эти вопросы не про "правильный" ответ, а про то, как человек думает и как раскрывает ситуацию. Обычно на практике ответы довольно хорошо читаются между строк.
"Возможно у него другой опыт, он побывал в других ситуациях." - да, все так, именно поэтому такие вопросы использую не как "контрольную", а как способ понять модель мышления кандидата и чего от него ожидать в работе.
Довольно сложный вопрос. К сожалению, не могу назвать пару книг, после которых можно пойти легко реализовать любой процесс.
В будущих статьях как раз хочу подробнее расписать остальные этапы и как можно применять на практике. Но каждую ситуацию надо рассматривать отдельно, очень сложно давать советы, которые будут применимы всегда и везде.
Очень классная формулировка 👍
Как раз хорошо видно подход: довести до результата, а не просто передать дальше.
Более интересный вопрос не "кто виноват", а что с этим делать.
Либо принять ограничения системы, либо пытаться её менять. Но это другая большая и сложная тема. Немного затрагивал ее в прошлой статье: https://habr.com/ru/articles/719352/.
Спасибо за идею, попробую раскрыть ее в будущих статьях.
Скорее не согласен. Как раз пытался подсветить, что наша главная цель, чтобы конечный клиент получил решение своей проблемы. А попытка ограничить свою зону маленьким куском - заканчивается обычно тем, что тикеты просто закрывают без решения.
Почему хорошие ответы:
1) Взяли на себя ответственность за свою часть. Это очень хороший сигнал.
2) Фраза "в области здравого смысла" - это прямо топ и с такими людьми и хочется работать.
3) Показали, что есть опыт - брать на себя ответственность.
4) Показали какие ограничения у вас есть. (Что очень логично, чтобы бэк хорош в бэке, не во фронте и в бизнес части).
5) Показали, что умеете писать тесты.
Со своей стороны я скорее не хотел бы работать в таком месте. Но тут я конечно, выбор у каждого свой.
Хорошие ответы!
Как очень хорошее начало разговора и что точно стоит пообщаться подробнее с кандидатом
Спасибо! Да, на стадии принятия решения после интервью - один из лучших вопросов себе.
Интересный вопрос. И вот тут как раз и возникает та самая ситуация. Если никто не возьмет на себя ownership проблемы, то пользователь так и будет с проблемой. Если тикет не закрывать, а позвать тимлида помочь с кросс-командной проблемой / проблему с другими организациями - это уже здорово и хорошее решение.
В блоке про тимлида - то, что он возьмет на себя решение проблем - это здорово. Ответ - "Я", это хороший ответ. Но поверх этого ответа важно, чтобы он умел себя масштабировать. Чтобы не в одно лицо решать все проблемы, а чтобы подключаться только в тех ситуациях, где без его помощи не справляются.
Да, юнит тесты лучше применять там, где есть бизнес логика и в вашем кейсе звучит, что будет больше пользы типизации и e2e тестов.
Как отражал в статье, это начало разговора, а не полная замена.
Хочется на скрининге заранее понимать, кто более перспективный. Пока из вашего ответа не понял как тогда лучше систему выстраивать?
Понимаю, что текущие вопросы неидеальные, но точно заинтересован в поиске более эффективных подходов.
Я бы с удовольствием заменил вопрос на более общий, если есть удачный вариант - пожалуйста, поделитесь.
А вот тут думаю вопросы хорошо подходят. Если в ответе будет про TLA+ и chaos engineering, то это хорошее начало обсуждения для понимания инженерной зрелости.
"упирается в невозможность осуществления необходимых изменений из-за линейности своей должности."
Да, согласен, неприятная и сложная ситуация. На практике помогают идеи из моделей внедрения изменений: искать точки влияния, союзников и постепенно расширять зону ответственности.
Если вдруг нужна будет помощь - пишите в директ, попробую помочь.
Как очень крутого разработчика :)
В случае низкоуровневых разработчиков точно своей отдельный контекст и стоит придумывать другую систему вопросов.
Да, согласен, в идеале лучше поработать с человеком и посмотреть в деле.
Но на этапе найма у нас всегда есть ограничение по времени, поэтому приходится проводить первоначальный "скрининг".
Для меня эти вопросы не про "правильный" ответ, а про то, как человек думает и как раскрывает ситуацию. Обычно на практике ответы довольно хорошо читаются между строк.
"Возможно у него другой опыт, он побывал в других ситуациях." - да, все так, именно поэтому такие вопросы использую не как "контрольную", а как способ понять модель мышления кандидата и чего от него ожидать в работе.
Довольно сложный вопрос. К сожалению, не могу назвать пару книг, после которых можно пойти легко реализовать любой процесс.
В будущих статьях как раз хочу подробнее расписать остальные этапы и как можно применять на практике. Но каждую ситуацию надо рассматривать отдельно, очень сложно давать советы, которые будут применимы всегда и везде.
При работе с тимлидами использую вот такой список литературы: https://github.com/wowworks-team/developer-roadmap/blob/master/FAQ_PM.md и много материалов в файле Развитие тимлида.
Если нужно,то могу пояснить, объяснить какие-то моменты со схемы в миро голосом в частном порядке.
Полностью согласен, что везде требуется здравый смысл и нужно смотреть по каждой конкретной ситуации какой подход лучшего всего применим.
Да, хорошо, давайте в личке обсудим.
Спасибо!
Да, про работу с багами были различные идеи на следущие статьи.