буквально недавно был инцидент на работе в проде, в канале по решению проблемы более 100 человек, все софискиллованы, вовлечены в процесс, канал раскален от желания показать преданность: "какой статус?", " кто занимается? ", "какие сроки?", "подключаюсь к решению" и советы адептов капитана очевидности. в итоге компетентных ребях подключили, они этот булшит читать не стали, на тэгание и истерики не отвечали, а спокойно разрулили инцидент.
но софтскилловые лапочки потом еще вторую серию устроили - разбор инцидента и выводы как избежать в дальнейшем. а вывод один - не нанимать тем, кто языком ворочает, топит за сроки и любит достигать достижения в краткосрочной перспективе, но ни черта не понимает в технологиях и стратегическом горизонте планирования.
воистину так, но для этого необходимо, чтобы собеседующий был соответствующим образом подготовлен. а судя по вою в интернетах собеседующих отрывают от великого кодотворения и заставляют собеседовать, причем не снимая пропорционально затратам (на подготовку, проведение и составление обратной связи) нагрузку по задачам спринта. вот и выходит вакханалия на технических собеседованиях, один из случаев которой описал автор статьи.
предлагаю поиграть в ролевую игру, я допускаю, что мое видение ошибочно и покрыто налетом субъективизма, поэтому буду признателен вам, если в ходе дискуссии смогу приобрести новый опыт.
итак. вы кандидат, я - зануда интервьюер. вы пришли ко мне с метрикой "покрытие тестами" и строчкой в резюме "увеличил в 2 раза % покрытия тестами кодовой базы приложения Х". мои уточняющие занудные вопросы:
как проводились замеры до и после. что измерялось? определяемся с терминами.
почему именно в 2 раза, а не в 1.9 раза или в 2.1 раза?
почему это именно ваша заслуга? как вы выделили свое участие? при допущении, что репозиторий приложения изменяют и другие разработчики.
не знаю в среднем по больнице, но по своему текущему месту работы в отношении именно кода я бы не смог вывести не притянутые за уши метрики, потому, что затруднительно выделить именно цифровые показатели труда одного разработчика из репозиториев, в которых код изменяет команда разработчиков. и, учитывая курс в разработке на уменьшение time to market, взаимных влияний (разной направленности) не избежать. паттерн лебедь рак и щука тому пример. один рефакторит и доводит до идеала, а другой просто увеличивает добротную, но заурядную кодовую базу. и вроде как по стандартам проходит ревью, но разница есть и влияние разное. а иногда такой говнокод (субъективно) встречаешь, что руки опускаются куда-то стремиться и что-то доказывать.
у меня был похожий случай на днях. резюме у кандидата пестрило фразами улучшил, повысил и т.п. задал три вопроса: как проводил замеры, не могли ли действия кого-либо из команды разработки повлиять на эту же метрику (как со знаком плюс, так и со знаком минус), почему именно такая красивая и ровная цифра - 35%, а не 34% или не 36%. в итоге вместе посмеялись, что написано по заветам тренеров по улучшению резюме для прохода фильтров первичного отбора, придуманного первично-отбирающими. отложили в сторону эти подвиги с цифрами и мило побеседовали о разработке. фидбек дал по итогу положительный - толковый парень, на мой взгляд.
если не ошибаюсь, то окружающий мир в minecraft генерируется, используя некоторую псевдослучайность в алгоритме. это позволяет получать множество разных (в некотором отношении) миров. но есть возможность ввести последовательность цифр (сид из статьи), которая приведет к генерации конкретного мира с точным расположением каждого деревца. автор хотел попасть в мир стримера и рассказал, как он это провернул, как нашел последовательность цифр.
полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.
расскажу мой случай... причина проста - в опенспейсе рядом сидят люди с различными теплоощущениями. вариант решения, лежащего на поверхности - рассадить мерзлячих и горячих по разные стороны не нашел поддержку у руководства т.к. "мы тут по отделам сидим". в итоге горячие парни ноют "как душно" и открывают окна, мерзлячие ноют "как холодно" и закрывают. так весь день и проходит в открытии и закрытии. вариант решения "давайте настроим температурный режим системы кондиционирования" сводится к первому, только вместо открытия окон - тыкание в пульт кондиционера.
все, кроме 9 и 11 пункта можно смело отзеркалить на "лучших" представителей нанимающей стороны - достаточно почитать вакансии и сообщениях от них. человеческая природа - допускать ошибки, указывать другим и не видеть у аналогичные у себя. будучи в роли кандидата, практически не встречал что-либо сопоставимое с моим субъективным видением "вакансия мечты", обычно boilerplate из лжи и штампов. так может хватит уже скакать на ветрянные мельницы под названием "бревно в чужом глазу"? лукавят все, а те, кто утверждает обратное, возможно лукавят сильнее. нет объективного хорошо и объективного плохо, объективного правильно и объективного неправильно. есть допущения и компромиссы, на которые идут стороны при оформлении трудовых отношений. в каждом случае свои, в каждом случае субъективнее некуда.
все эти рекомендации по решению конфликтов великолепны ровно до тех пор, пока не встретятся две стороны, каждая из которых не собирается уступать. хрестоматийный случай в каждом openspace - "мне дует" и "мне жарко". коучи по конфликтологии начинают сразу генерировать великое множество идей (ребята, ну как вы не догадались - вот же как надо!), но беда в том, что в ситуации "уперлись два барана с милыми улыбками на мордах и подчеркнуто-вежливым поведением с полным зеркалированием друг друга" все идеи не работают. а ненависть в душе множится.
со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из jira" или "у меня nda". в таких случаях уже переходим на разбор моих кейсов - это обычно ревью заготовленного кода или архитектуры - из текущего проекта с долей упрощения, разумеется. да, я готовлюсь к собеседованию, и кейсы мне дает реальная практика с проектов. надо просто оправданий лени не искать. и зачастую очень любопытные и непринуждённые беседы выходят.
руководство (как говорится в расхожей фразе) хочет волшебников, а получает сказочников. недавно было два случая в копилку, что называется.
первый. наняли мегасупермилорда, который должен решать проблемы одним взглядом, но по факту абсолютно не командный игрок (субъективное мнение мое, разумеется) и вместо решения проблем пошло создание новых, оправдания почему нельзя пилить фичи и классическое предложение "все переписать с нуля". разошлись на испытательном сроке.
второй. наняли опытного разработчика, он сразу влился в процессы, подстроился под процессы и стиль разработки (опять же не могу судить без субъективизма хорошие у нас процессы или плохие, они такие как есть) стал пилить фичи с первой недели.
резюмируя. кто хороший и плохой, кто прав и виноват в этих двух случаях можно решать до бесконечности. основная мысль, что просто бывает по-разному при прочих равных.
история с наймом джунов сугубо индивидуальна - в одних командах есть и задачи, и менторы, на других - иначе. мерить единым мерилом за или против не стал бы. на моем опыте были и джуны-звезды, и сеньоры-лоботрясы. и задачи удавалось подбирать для постепенного погружения в проект, и не удавалось. очень все по-разному и субъективно.
Не могли бы вы поделиться соображениями по следующему вопросу? Я не специалист в нагрузочном тестирование, поэтому заранее прошу простить мне мой обывательский взгляд на проблематику. Работаю в компании, где разработчик и швец, и жнец, и на дуде игрец... Учусь, перенимаю опыт. Предположим у вас есть некое REST API, оно состоит из N методов. За вызовом каждого метода с вашей стороны стоит различное множество микросервисных взаимодействий (в т.ч. с источниками данных, интеграциями с внешними системами и т.п.) - соответственно средняя скорость и сложность выполнения у методов разная. Каким образом вы моделируете нагрузку, чтобы построить гипотезы на тему "какое количество пользователей выдержит текущая реализация вашего REST API"? Вижу такие варианты: 1. Использовать статистику частоты вызовов методов с production и скалировать пропорционально, сравнивать относительный прирост-падение производительности. 2. Принять частоту вызовов методов равномерной, далее по п.1 3. Выбрать самый медленный метод и принять его за бутылочное горлышко (не принимая в расчет частоту его вызовов), нагружать его и найти возможность улучшения до "средних по больнице" величин. 4. Сформировать пользовательские сценарии - очередность вызова методов. Как быть с многоообразием таковых сценариев? Или этот пункт по факту сводится к пункту 1?
не нашел ничего про принятие решения об увеличении/уменьшении грейда и/или зарплаты. только словесные пляски - развитие, планы, отзывы...
неужели я один такой меркантильный и наивный? или невнимательный?
буквально недавно был инцидент на работе в проде, в канале по решению проблемы более 100 человек, все софискиллованы, вовлечены в процесс, канал раскален от желания показать преданность: "какой статус?", " кто занимается? ", "какие сроки?", "подключаюсь к решению" и советы адептов капитана очевидности. в итоге компетентных ребях подключили, они этот булшит читать не стали, на тэгание и истерики не отвечали, а спокойно разрулили инцидент.
но софтскилловые лапочки потом еще вторую серию устроили - разбор инцидента и выводы как избежать в дальнейшем. а вывод один - не нанимать тем, кто языком ворочает, топит за сроки и любит достигать достижения в краткосрочной перспективе, но ни черта не понимает в технологиях и стратегическом горизонте планирования.
воистину так, но для этого необходимо, чтобы собеседующий был соответствующим образом подготовлен. а судя по вою в интернетах собеседующих отрывают от великого кодотворения и заставляют собеседовать, причем не снимая пропорционально затратам (на подготовку, проведение и составление обратной связи) нагрузку по задачам спринта. вот и выходит вакханалия на технических собеседованиях, один из случаев которой описал автор статьи.
предлагаю поиграть в ролевую игру, я допускаю, что мое видение ошибочно и покрыто налетом субъективизма, поэтому буду признателен вам, если в ходе дискуссии смогу приобрести новый опыт.
итак. вы кандидат, я - зануда интервьюер. вы пришли ко мне с метрикой "покрытие тестами" и строчкой в резюме "увеличил в 2 раза % покрытия тестами кодовой базы приложения Х". мои уточняющие занудные вопросы:
как проводились замеры до и после. что измерялось? определяемся с терминами.
почему именно в 2 раза, а не в 1.9 раза или в 2.1 раза?
почему это именно ваша заслуга? как вы выделили свое участие? при допущении, что репозиторий приложения изменяют и другие разработчики.
не знаю в среднем по больнице, но по своему текущему месту работы в отношении именно кода я бы не смог вывести не притянутые за уши метрики, потому, что затруднительно выделить именно цифровые показатели труда одного разработчика из репозиториев, в которых код изменяет команда разработчиков. и, учитывая курс в разработке на уменьшение time to market, взаимных влияний (разной направленности) не избежать. паттерн лебедь рак и щука тому пример. один рефакторит и доводит до идеала, а другой просто увеличивает добротную, но заурядную кодовую базу. и вроде как по стандартам проходит ревью, но разница есть и влияние разное. а иногда такой говнокод (субъективно) встречаешь, что руки опускаются куда-то стремиться и что-то доказывать.
у меня был похожий случай на днях. резюме у кандидата пестрило фразами улучшил, повысил и т.п. задал три вопроса: как проводил замеры, не могли ли действия кого-либо из команды разработки повлиять на эту же метрику (как со знаком плюс, так и со знаком минус), почему именно такая красивая и ровная цифра - 35%, а не 34% или не 36%. в итоге вместе посмеялись, что написано по заветам тренеров по улучшению резюме для прохода фильтров первичного отбора, придуманного первично-отбирающими. отложили в сторону эти подвиги с цифрами и мило побеседовали о разработке. фидбек дал по итогу положительный - толковый парень, на мой взгляд.
если не ошибаюсь, то окружающий мир в minecraft генерируется, используя некоторую псевдослучайность в алгоритме. это позволяет получать множество разных (в некотором отношении) миров. но есть возможность ввести последовательность цифр (сид из статьи), которая приведет к генерации конкретного мира с точным расположением каждого деревца. автор хотел попасть в мир стримера и рассказал, как он это провернул, как нашел последовательность цифр.
полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.
расскажу мой случай... причина проста - в опенспейсе рядом сидят люди с различными теплоощущениями. вариант решения, лежащего на поверхности - рассадить мерзлячих и горячих по разные стороны не нашел поддержку у руководства т.к. "мы тут по отделам сидим". в итоге горячие парни ноют "как душно" и открывают окна, мерзлячие ноют "как холодно" и закрывают. так весь день и проходит в открытии и закрытии. вариант решения "давайте настроим температурный режим системы кондиционирования" сводится к первому, только вместо открытия окон - тыкание в пульт кондиционера.
база для командной работы (и не только в IT) - это умение формулировать "мои мысли - мои скакуны" в устную и письменную речь.
мой любимый паттерн компаний - мы не будем дискриминировать по фото, но будем дискриминировать по факту наличия или отсутствия фото (#этодругое)
все, кроме 9 и 11 пункта можно смело отзеркалить на "лучших" представителей нанимающей стороны - достаточно почитать вакансии и сообщениях от них. человеческая природа - допускать ошибки, указывать другим и не видеть у аналогичные у себя. будучи в роли кандидата, практически не встречал что-либо сопоставимое с моим субъективным видением "вакансия мечты", обычно boilerplate из лжи и штампов. так может хватит уже скакать на ветрянные мельницы под названием "бревно в чужом глазу"? лукавят все, а те, кто утверждает обратное, возможно лукавят сильнее. нет объективного хорошо и объективного плохо, объективного правильно и объективного неправильно. есть допущения и компромиссы, на которые идут стороны при оформлении трудовых отношений. в каждом случае свои, в каждом случае субъективнее некуда.
все эти рекомендации по решению конфликтов великолепны ровно до тех пор, пока не встретятся две стороны, каждая из которых не собирается уступать. хрестоматийный случай в каждом openspace - "мне дует" и "мне жарко". коучи по конфликтологии начинают сразу генерировать великое множество идей (ребята, ну как вы не догадались - вот же как надо!), но беда в том, что в ситуации "уперлись два барана с милыми улыбками на мордах и подчеркнуто-вежливым поведением с полным зеркалированием друг друга" все идеи не работают. а ненависть в душе множится.
хорошие вопросы, я как тех.интервьюер отвечаю на подобные вопросы и встречный интерес проявляю - как работал кандидат.
со стороны интервьюера вижу тоже палку о двух концах. начинаю собеседование всегда с предоставления слова кандидату и прошу рассказать об интересных с технической точки зрения кейсах из практики, попутно уточняя детали. но... т.к. умение рассказывать это тоже умение и оно есть далеко не у всех, то зачастую рассказ кандидата выглядит как "делал задачки из jira" или "у меня nda". в таких случаях уже переходим на разбор моих кейсов - это обычно ревью заготовленного кода или архитектуры - из текущего проекта с долей упрощения, разумеется. да, я готовлюсь к собеседованию, и кейсы мне дает реальная практика с проектов. надо просто оправданий лени не искать. и зачастую очень любопытные и непринуждённые беседы выходят.
благодарю!
руководство (как говорится в расхожей фразе) хочет волшебников, а получает сказочников. недавно было два случая в копилку, что называется.
первый. наняли мегасупермилорда, который должен решать проблемы одним взглядом, но по факту абсолютно не командный игрок (субъективное мнение мое, разумеется) и вместо решения проблем пошло создание новых, оправдания почему нельзя пилить фичи и классическое предложение "все переписать с нуля". разошлись на испытательном сроке.
второй. наняли опытного разработчика, он сразу влился в процессы, подстроился под процессы и стиль разработки (опять же не могу судить без субъективизма хорошие у нас процессы или плохие, они такие как есть) стал пилить фичи с первой недели.
резюмируя. кто хороший и плохой, кто прав и виноват в этих двух случаях можно решать до бесконечности. основная мысль, что просто бывает по-разному при прочих равных.
история с наймом джунов сугубо индивидуальна - в одних командах есть и задачи, и менторы, на других - иначе. мерить единым мерилом за или против не стал бы. на моем опыте были и джуны-звезды, и сеньоры-лоботрясы. и задачи удавалось подбирать для постепенного погружения в проект, и не удавалось. очень все по-разному и субъективно.
Не могли бы вы поделиться соображениями по следующему вопросу? Я не специалист в нагрузочном тестирование, поэтому заранее прошу простить мне мой обывательский взгляд на проблематику. Работаю в компании, где разработчик и швец, и жнец, и на дуде игрец... Учусь, перенимаю опыт.
Предположим у вас есть некое REST API, оно состоит из N методов. За вызовом каждого метода с вашей стороны стоит различное множество микросервисных взаимодействий (в т.ч. с источниками данных, интеграциями с внешними системами и т.п.) - соответственно средняя скорость и сложность выполнения у методов разная.
Каким образом вы моделируете нагрузку, чтобы построить гипотезы на тему "какое количество пользователей выдержит текущая реализация вашего REST API"?
Вижу такие варианты:
1. Использовать статистику частоты вызовов методов с production и скалировать пропорционально, сравнивать относительный прирост-падение производительности.
2. Принять частоту вызовов методов равномерной, далее по п.1
3. Выбрать самый медленный метод и принять его за бутылочное горлышко (не принимая в расчет частоту его вызовов), нагружать его и найти возможность улучшения до "средних по больнице" величин.
4. Сформировать пользовательские сценарии - очередность вызова методов. Как быть с многоообразием таковых сценариев? Или этот пункт по факту сводится к пункту 1?