Или как вариант - Николай и Василий работают в разных компаниях, оба гордо носят лычки сеньоров и пишут о себе оды в резюме. По факту Николай все также перекладывает json (но чуть большего размера и со вложенностью в несколько уровней больше, чем раньше), а Василий пишет как боженька, да ещё и менторит парочку коллег, и в архитектурных делах тащит, и ещё много чего. Посмотрит Николай - мать моя, хочу зарплату как у Василия, ведь он "такой же" сеньор. Но потянет ли - вопрос...
Сталкивался с ситуацией, когда некоторые "эффективные" притаскивают kpi другим "эффективным" - увольнение на испытательном, увольнение в первый год... После первого лоботряса, которого сохраняют "эффективные" ради своих цифирок в ущерб команде, тех.иньервьюер решает жестить больше. Случай из практики, не более.
Вы меня простите сердечно, но кроме 8 вопроса все остальные можно задать практически любой специальности и не только в айти. Интересно было бы почитать именно уникальные вопросы для дизайнера интерфейсов, если таковыми вы готовы поделиться.
Верно, а ещё бывает пройдешь все дебри многоэтапного собеседования с алгоритмами и прочими плясками, откроешь репозиторий в первый рабочий день и закроешь, чтобы не видеть весь этот "гениальный" код, который казалось бы должен быть под стать планке, заданной на собеседовании.
Особенно здорово в офисе, когда начинается битва между "мне жарко" и "мне холодно", а руководство умывает руки и не считает нужным разрулить ситуацию группировкой сотрудников со схожими тепловыми ощущениями. Выговорился, простите.
А в целом по теме - не надо никому ничего доказывать, спорить что лучше офис или удалёнке, люди разные, просто дайте выбрать им самим. Если руководство не умеет в оценку деятельности, то прикрывать это бессилие сказками как хорошо в офисе не лучшая идея. На такое не купишь людей с интеллектом.
даю справку: мало текста и много воды, перед самой главной фразой в статье - "предлагаю уникальные и востребованные услуги". предположу, что подобное у почтенной публике не в почёте.
выскажу крамольную мысль, но... работаю в большой конторе (4000+ работников) и мое субъективное наблюдение о том, что вижу вокруг в конкретном частном случае: чем больше нанимают середняков, тем больше энтропии плодят эти середняки и нужны новые середняки. не обобщаю на отрасль, возможно где-то иначе. по крайней мере на слайдах об успешном успехе многие рассказывают какие классные у всех команды. возможно неудачник это я)))
все это здорово, но как быть с сотрудниками, которые не укладываются в среднюю температуру по больнице, которую измерили опросами или иным способом? как их удовлетворять? стоит ли? интересно узнать мнение автора. иными словами - как решать противостояние "удовлетворенность сотрудникОВ vs удовлетворенность сотрудникА".
во времена перестройки один юморист (забыл фамилию) в своем монологе упоминал политического деятеля, который служил тем, кто его брал. и юморист предлагал нагрудить деятеля медалью "за неоднократную преданность".
в случае трудовых взаимоотношений (взаимо, подчеркиваю) все эти басни про одностороннюю лояльность (которую надо взращивать и изучать) выглядят как минимум нелогично. а в ответ работнику что? великая честь и футболка с логотипом компании?
буквально недавно был инцидент на работе в проде, в канале по решению проблемы более 100 человек, все софискиллованы, вовлечены в процесс, канал раскален от желания показать преданность: "какой статус?", " кто занимается? ", "какие сроки?", "подключаюсь к решению" и советы адептов капитана очевидности. в итоге компетентных ребях подключили, они этот булшит читать не стали, на тэгание и истерики не отвечали, а спокойно разрулили инцидент.
но софтскилловые лапочки потом еще вторую серию устроили - разбор инцидента и выводы как избежать в дальнейшем. а вывод один - не нанимать тем, кто языком ворочает, топит за сроки и любит достигать достижения в краткосрочной перспективе, но ни черта не понимает в технологиях и стратегическом горизонте планирования.
воистину так, но для этого необходимо, чтобы собеседующий был соответствующим образом подготовлен. а судя по вою в интернетах собеседующих отрывают от великого кодотворения и заставляют собеседовать, причем не снимая пропорционально затратам (на подготовку, проведение и составление обратной связи) нагрузку по задачам спринта. вот и выходит вакханалия на технических собеседованиях, один из случаев которой описал автор статьи.
предлагаю поиграть в ролевую игру, я допускаю, что мое видение ошибочно и покрыто налетом субъективизма, поэтому буду признателен вам, если в ходе дискуссии смогу приобрести новый опыт.
итак. вы кандидат, я - зануда интервьюер. вы пришли ко мне с метрикой "покрытие тестами" и строчкой в резюме "увеличил в 2 раза % покрытия тестами кодовой базы приложения Х". мои уточняющие занудные вопросы:
как проводились замеры до и после. что измерялось? определяемся с терминами.
почему именно в 2 раза, а не в 1.9 раза или в 2.1 раза?
почему это именно ваша заслуга? как вы выделили свое участие? при допущении, что репозиторий приложения изменяют и другие разработчики.
не знаю в среднем по больнице, но по своему текущему месту работы в отношении именно кода я бы не смог вывести не притянутые за уши метрики, потому, что затруднительно выделить именно цифровые показатели труда одного разработчика из репозиториев, в которых код изменяет команда разработчиков. и, учитывая курс в разработке на уменьшение time to market, взаимных влияний (разной направленности) не избежать. паттерн лебедь рак и щука тому пример. один рефакторит и доводит до идеала, а другой просто увеличивает добротную, но заурядную кодовую базу. и вроде как по стандартам проходит ревью, но разница есть и влияние разное. а иногда такой говнокод (субъективно) встречаешь, что руки опускаются куда-то стремиться и что-то доказывать.
у меня был похожий случай на днях. резюме у кандидата пестрило фразами улучшил, повысил и т.п. задал три вопроса: как проводил замеры, не могли ли действия кого-либо из команды разработки повлиять на эту же метрику (как со знаком плюс, так и со знаком минус), почему именно такая красивая и ровная цифра - 35%, а не 34% или не 36%. в итоге вместе посмеялись, что написано по заветам тренеров по улучшению резюме для прохода фильтров первичного отбора, придуманного первично-отбирающими. отложили в сторону эти подвиги с цифрами и мило побеседовали о разработке. фидбек дал по итогу положительный - толковый парень, на мой взгляд.
если не ошибаюсь, то окружающий мир в minecraft генерируется, используя некоторую псевдослучайность в алгоритме. это позволяет получать множество разных (в некотором отношении) миров. но есть возможность ввести последовательность цифр (сид из статьи), которая приведет к генерации конкретного мира с точным расположением каждого деревца. автор хотел попасть в мир стримера и рассказал, как он это провернул, как нашел последовательность цифр.
полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.
Ога. Простор широкий для самых разных вариантов)
Или как вариант - Николай и Василий работают в разных компаниях, оба гордо носят лычки сеньоров и пишут о себе оды в резюме. По факту Николай все также перекладывает json (но чуть большего размера и со вложенностью в несколько уровней больше, чем раньше), а Василий пишет как боженька, да ещё и менторит парочку коллег, и в архитектурных делах тащит, и ещё много чего. Посмотрит Николай - мать моя, хочу зарплату как у Василия, ведь он "такой же" сеньор. Но потянет ли - вопрос...
Сталкивался с ситуацией, когда некоторые "эффективные" притаскивают kpi другим "эффективным" - увольнение на испытательном, увольнение в первый год... После первого лоботряса, которого сохраняют "эффективные" ради своих цифирок в ущерб команде, тех.иньервьюер решает жестить больше. Случай из практики, не более.
Вы меня простите сердечно, но кроме 8 вопроса все остальные можно задать практически любой специальности и не только в айти. Интересно было бы почитать именно уникальные вопросы для дизайнера интерфейсов, если таковыми вы готовы поделиться.
Верно, а ещё бывает пройдешь все дебри многоэтапного собеседования с алгоритмами и прочими плясками, откроешь репозиторий в первый рабочий день и закроешь, чтобы не видеть весь этот "гениальный" код, который казалось бы должен быть под стать планке, заданной на собеседовании.
Особенно здорово в офисе, когда начинается битва между "мне жарко" и "мне холодно", а руководство умывает руки и не считает нужным разрулить ситуацию группировкой сотрудников со схожими тепловыми ощущениями. Выговорился, простите.
А в целом по теме - не надо никому ничего доказывать, спорить что лучше офис или удалёнке, люди разные, просто дайте выбрать им самим. Если руководство не умеет в оценку деятельности, то прикрывать это бессилие сказками как хорошо в офисе не лучшая идея. На такое не купишь людей с интеллектом.
даю справку: мало текста и много воды, перед самой главной фразой в статье - "предлагаю уникальные и востребованные услуги". предположу, что подобное у почтенной публике не в почёте.
выскажу крамольную мысль, но... работаю в большой конторе (4000+ работников) и мое субъективное наблюдение о том, что вижу вокруг в конкретном частном случае: чем больше нанимают середняков, тем больше энтропии плодят эти середняки и нужны новые середняки. не обобщаю на отрасль, возможно где-то иначе. по крайней мере на слайдах об успешном успехе многие рассказывают какие классные у всех команды. возможно неудачник это я)))
все это здорово, но как быть с сотрудниками, которые не укладываются в среднюю температуру по больнице, которую измерили опросами или иным способом? как их удовлетворять? стоит ли? интересно узнать мнение автора. иными словами - как решать противостояние "удовлетворенность сотрудникОВ vs удовлетворенность сотрудникА".
подобное притягивает подобное. в этом и суть заключения трудовых взаимо(!)отношений. на рынке есть разные компании и кандидаты.
во времена перестройки один юморист (забыл фамилию) в своем монологе упоминал политического деятеля, который служил тем, кто его брал. и юморист предлагал нагрудить деятеля медалью "за неоднократную преданность".
в случае трудовых взаимоотношений (взаимо, подчеркиваю) все эти басни про одностороннюю лояльность (которую надо взращивать и изучать) выглядят как минимум нелогично. а в ответ работнику что? великая честь и футболка с логотипом компании?
не нашел ничего про принятие решения об увеличении/уменьшении грейда и/или зарплаты. только словесные пляски - развитие, планы, отзывы...
неужели я один такой меркантильный и наивный? или невнимательный?
буквально недавно был инцидент на работе в проде, в канале по решению проблемы более 100 человек, все софискиллованы, вовлечены в процесс, канал раскален от желания показать преданность: "какой статус?", " кто занимается? ", "какие сроки?", "подключаюсь к решению" и советы адептов капитана очевидности. в итоге компетентных ребях подключили, они этот булшит читать не стали, на тэгание и истерики не отвечали, а спокойно разрулили инцидент.
но софтскилловые лапочки потом еще вторую серию устроили - разбор инцидента и выводы как избежать в дальнейшем. а вывод один - не нанимать тем, кто языком ворочает, топит за сроки и любит достигать достижения в краткосрочной перспективе, но ни черта не понимает в технологиях и стратегическом горизонте планирования.
воистину так, но для этого необходимо, чтобы собеседующий был соответствующим образом подготовлен. а судя по вою в интернетах собеседующих отрывают от великого кодотворения и заставляют собеседовать, причем не снимая пропорционально затратам (на подготовку, проведение и составление обратной связи) нагрузку по задачам спринта. вот и выходит вакханалия на технических собеседованиях, один из случаев которой описал автор статьи.
предлагаю поиграть в ролевую игру, я допускаю, что мое видение ошибочно и покрыто налетом субъективизма, поэтому буду признателен вам, если в ходе дискуссии смогу приобрести новый опыт.
итак. вы кандидат, я - зануда интервьюер. вы пришли ко мне с метрикой "покрытие тестами" и строчкой в резюме "увеличил в 2 раза % покрытия тестами кодовой базы приложения Х". мои уточняющие занудные вопросы:
как проводились замеры до и после. что измерялось? определяемся с терминами.
почему именно в 2 раза, а не в 1.9 раза или в 2.1 раза?
почему это именно ваша заслуга? как вы выделили свое участие? при допущении, что репозиторий приложения изменяют и другие разработчики.
не знаю в среднем по больнице, но по своему текущему месту работы в отношении именно кода я бы не смог вывести не притянутые за уши метрики, потому, что затруднительно выделить именно цифровые показатели труда одного разработчика из репозиториев, в которых код изменяет команда разработчиков. и, учитывая курс в разработке на уменьшение time to market, взаимных влияний (разной направленности) не избежать. паттерн лебедь рак и щука тому пример. один рефакторит и доводит до идеала, а другой просто увеличивает добротную, но заурядную кодовую базу. и вроде как по стандартам проходит ревью, но разница есть и влияние разное. а иногда такой говнокод (субъективно) встречаешь, что руки опускаются куда-то стремиться и что-то доказывать.
у меня был похожий случай на днях. резюме у кандидата пестрило фразами улучшил, повысил и т.п. задал три вопроса: как проводил замеры, не могли ли действия кого-либо из команды разработки повлиять на эту же метрику (как со знаком плюс, так и со знаком минус), почему именно такая красивая и ровная цифра - 35%, а не 34% или не 36%. в итоге вместе посмеялись, что написано по заветам тренеров по улучшению резюме для прохода фильтров первичного отбора, придуманного первично-отбирающими. отложили в сторону эти подвиги с цифрами и мило побеседовали о разработке. фидбек дал по итогу положительный - толковый парень, на мой взгляд.
если не ошибаюсь, то окружающий мир в minecraft генерируется, используя некоторую псевдослучайность в алгоритме. это позволяет получать множество разных (в некотором отношении) миров. но есть возможность ввести последовательность цифр (сид из статьи), которая приведет к генерации конкретного мира с точным расположением каждого деревца. автор хотел попасть в мир стримера и рассказал, как он это провернул, как нашел последовательность цифр.
полностью согласен, синтаксис и основные концепции выучить можно быстро, но этим язык не ограничивается. не единожды встречал ситуацию, когда вместо того, чтобы задуматься (хотя бы задуматься! поискать, взвесить за-против и т.п.) о наличии готового решения в стандартных (или общеизвестных, или проектных) библиотеках, еще раз подчеркиваю именно задуматься (а не сразу тащить в проект почем зря), разработчик с гордостью принимает решение творить свой велосипед с покрытием тестами и прочими плясками лучших практик (включая получение новых проблем из-за внедрения данного велосипеда), потому что знания синтаксиса ему (на его взгляд) более чем достаточно для решения проблемы, которая вполне вероятно (опять же почеркиваю допущение) уже решена. в этой ситуации невольно вспоминаю Косого из "Джентельменов удачи", который считал, что переводчиком уже может вполне себе работать.
почитал комментарии и полагаю себя не одиноким во мнении, что измерить точно предмет дискуссии (продуктивность разработчика) затруднительно. так или иначе придется применить какие-либо допущения, которые могут разбить в пух и прах оппоненты. абстракция и ее выбор, обоснование. на это каждый смотрит с колокольни своего опыта (наполненного ошибками, частными случаями, успехами), с колокольни процессов компании. вывести общую формулу продуктивности вряд ли возможно. поэтому, каждый решает проблему по своему - кто-то интуитивно отранжировал, кто-то разложил коллег на метрики и представил в виде персонажей ad&d... подходов может быть много и спорить можно до бесконечности.