Ох уж мне эти эксперты... Прочитал статью, на которую автор ссылается, посмотрел немного про автора... Мне любопытно, откуда она взяла эти самые мистические числа "95%" и "5%"? В статье написано, что она взяла их из "личного опыта". Учитывая, что личного опыта у нее не так уж и много - менее десяти лет разработки в пяти компаниях - я бы не придавал этим обобщениям так уж много значения. Спектр типов компаний, в которых так или иначе идет разработка софта, невероятно широк, и у них ну очень разные требования как к качеству, так и к скорости разработки (кстати, мне совершенно не ясно, почему она валит в одну кучу большое количество багов и медленные релизы?).
Я пользовался их бетой. Было очень неплохо. Но когда они объявили цену, я сказал "нафиг-нафиг!" и перебрался на Outlook. Я, конечно, извиняюсь, но 50 долларов в год за почтовый клиент (неплохой, но ничего сверхъестественного) - перебор.
Нормального квалифицированного опытного сотрудника никто просто так выгонять не стремится. Чтобы такое написать, нужно ну уж совсем не понимать, как функционируют компании. В той статье, на которую имеется ссылка в начале, описан совершенно другой случай - токсичная примадонна. И, как верно сказано в той же статье, а также в ее продолжении, именно проблемы в менеджменте привели к тому, что вся эта ситуация зашла так далеко.
И, конечно, если автор видит менеджмент как кучку посредственностей, только и занимающихся тем, чтобы "спускать вниз очередное дурацкое распоряжение", то он (автор) просто еще немного не готов для анализа таких ситуаций. (Впрочем, после тезиса о том, что "текучка кадров выгодна компании" все стало ясно, и дальше читать не имело смысла).
Все вопросы, которые приведены в статье, очень правильные, и действительно по делу. Однако, к сожалению, они в основном относятся к общей осведомленности кандидата о современных аспектах разработки и к его способности хорошо об этом поговорить. Это важно; однако, когда я ищу разработчика, мне важны еще несколько вещей:
Умение не только говорить, но и делать - способен ли кандидат написать работающий код, пусть и не супер сложный? Ну не ФиззБазз - но, скажем, вариацию на тему Фибоначчи. Увы, мне попадалось немало кандидатов, красиво рассуждающих о тестировании и контейнерах, но неспособных самостоятельно перевести в лоб заданный алгоритм в рабочий код.
Наличие базового уровня технической грамотности. Хреново, если кандидат вообще себе не представляет разницу между линейной и квадратичной вычислительной сложностью.
Наличие опыта (если речь не идет о самой начальной позиции). Помимо рассуждений о том, как надо - пытался ли кандидат таки сделать так, как он рассказывает, и что из этого вышло (и почему).
И вот для того, чтобы получить представление об этих способностях кандидата, и приходится спрашивать про хэш-таблицы, заставлять писать код и въедливо допрашивать про прошлые проекты.
"Бизнесу на самом деле наплевать, когда будет сделана задача 12 а когда задача 23, главное чтобы в сумме за полгода было сделано более-менее много всего."
Это совсем не так. То есть ну просто СОВСЕМ не так. Каждая задача происходит от какого-то бизнес-проекта. Что-то обещано уже существующим клиентам, что-то нужно для новых, что-то - чтобы выполнить всевозможные требования или законы... Зависит от бизнеса, конечно. Но даже если речь идет просто о развитии продукта, то на выполнение задач в определенное время может быть завязано очень много чего - связи с другими компонентами, тестирование, документация...
А что касается переключений контекста... При планировании спринта эти соображения вполне нужно высказать, и совершенно нормально (если только не зверский цейтнот) включить задачу в спринт именно потому, что уже делается что-то близкое. Но вообще меня как руководителя весьма заинтересовало бы, почему на переключение окружения нужен целый день. Ну а про два дня на "буду сидеть злой" и "буду вспоминать" даже как-то и говорить неловко. Но да, переключение контекстов не бесплатно, и при планировании спринта это обычно по возможности стараются учитывать.
Я - менеджер в технологической компании в США. Эта статья написана человеком, который мало что понимает и в роли менеджера, и в бизнесе, и в офисной структуре.
В условиях распределенной команды важность роли менеджера и ее сложность только увеличилась. Менеджер - вовсе не надсмотрщик с плетью. Задача менеджера - построить команду, помочь ей организоваться и развиться и устранить все посторонние препятствия на ее пути. Да, в условиях удаленки некоторые из этих задач усложнились. Например, при личном общении, пусть даже и кратком, гораздо легче заметить признаки изменяющихся отношений в команде, увидеть невербальные признаки конфликтов, выгорания, потери интереса, и соответственно среагировать.
В офисе, кроме того, гораздо легче создавать культуру компании и команды. Мне посчастливилось работать в компании, где в офисе, помимо работы, кипела интереснейшая жизнь. Проводились лекции и семинары; в большом актовом зале разные техкомпании города периодически устраивали свои мероприятия - и мы могли присутствовать; разные отделы устраивали презентации своих разработок, зачастую в необычных формах; была куча клубов по интересам - клуб фотографов устраивал свои выставки, клуб любителей вина проводил тематические дегустации; была секция йоги, были замечательные праздники... В этот офис хотелось приходить, в нем хотелось быть. И эта культура помогала привлекать талантливых и интересных людей для работы и мотивировала их оставаться. В условиях удаленки создание подобной обстановки гораздо сложнее (если вообще возможно). Переманить людей становится гораздо проще - и это весьма волнует менеджеров.
Пресловутое увеличение производительности - вопрос не до конца ясный. На примитивном уровне - взял тикет, написал код, коммитнул, закрыл тикет - она, несомненно увеличилась. Но вот про более крупный уровень, когда мы говорим о создании систем, продуктов и решении бизнес-задач, есть сомнения; здесь как раз и нужны вот эти самые встречи и переговоры, поскольку нужно обсудить много вещей и связать много разных команд.
Что же касается ведения побочного бизнеса в рабочее время и прав на разработки, то, помимо этических вопросов (компания платит за рабочее время, предполагая полную отдачу), есть еще и сложнейшие юридические вопросы, которые возникают в таких случаях. Понятно, что если сотрудник, в период работы над системой параллельных вычислений, разработал новую методику охлаждения пива, вопросов не будет (как правило). Но вот если он разработал принципиально новую технологию распределения вычислительной нагрузки, ситуация становится принципиально иной. Беда в том, что между этими двумя полюсами - огромная "серая" зона, и зачастую проще решить вопрос кардинально.
Fail fast не всегда хорошая идея в мире игр. Я сам работал в геймдеве; на моих глазах зарубили пару вполне достойных проектов, которые можно было бы вырастить в большие — просто из-за того, что они не стали «мгновенными бестселлерами».
«Например, на последней работе я сделал прототип проекта за сутки — и это 60% всей работы, нужной для выхода на рынок.» — на самом деле это примерно 15-20 процентов, если, конечно, мы говорим о продукте, а не о мелкой кустарной поделке. Как уже сказали выше, в разработке программного продукта собственно программирование занимает далеко не основное время.
Все зависит от того, зачем и почему изобретается велосипед. Если это делается чтобы сделать новый велосипед без недостатков старого, или такой, какого еще не было (и который при этом нужен), то это здорово и нужно. При этом предполагается что изобретатель хорошо знает уже существующие образцы, и понимает, что, как и почему в них сделано и может вразумительно ответить на вопрос, что именно он хочет сделать по-другому.
Но, к сожалению, в большинстве случаев велосипеды изобретают из тщеславия — очень хочется сделать свой знаменитый проект — или из лени и неграмотности, когда не могут или не хотят разобраться с уже существующими решениями. И вот это скверно.
Мне вообще не очень понятно, как можно «в принципе» запретить таргетированную рекламу. Но, допустим, будет принят очередной безумный закон и как-то запретят. Значит ли это, что станет меньше рекламы? Нет. Скорее, наоборот. Реклама будет менее интересна и ее будет больше. Ее количество увеличится по одной простой причине. Таргетированная реклама приносит больше денег, поскольку она более эффективна. Если эффективность уменьшится, рекламодатели станут меньше платить, и доход владельцев площадок снизится. Значит, для получения того же дохода владельцы должны будут увеличить количество показов.
А ждать до 45 и не пришлось бы :) Этот этап интервью у меня идет онлайн, и как только появится первое рабочее решение, можно будет двигаться дальше. Мы бы обсудили оптимизацию, и многое другое — но главная цель была бы достигнута, я бы пригласил вас на интервью в офис.
Так вот, как минимум 30%, а то и больше, кандидатов НЕ МОГУТ за 45 минут написать хоть как-то работающее решение.
Нет-нет, я не говорю про обман. Я имею в виду ситуацию, в которой человек, работая, не программирует, а модифицирует/адаптирует/клонирует чужой код. Где взял уже написанное, где на Stack Overflow сходил… Так можно очень долго работать, и даже вполне результативно. Моя цель на этом этапе совсем не вызвать стресс, поэтому я даю очень простые задачи. Ну, например, одно время давал вот такую:
«Определим последовательность Трибоначчи как последовательность, первые 3 элемента которой равны 1, а каждый последующий равен сумме трех предыдущих. Написать функцию trib(n), которая будет возвращать n-ный элемент последовательности.»
С моей точки зрения, человек, имеющий минимальный опыт программирования, должен без труда справиться с этим заданием меньше, чем за двадцать минут. Я даю на это до 45 минут, при этом сразу говорю, что основное задание — написать работающую программу, пусть даже она не оптимальна. Разве это стресс?
На самом первом собеседовании я даю задачку на HackerRank и смотрю, как кандидат ее решает. Задачку даю простую, чуть-чуть сложнее, чем FizzBuzz. Зачем? Для того, чтобы убедиться, что кандидат умеет программировать, то есть может, получив практически чистое описание несложного алгоритма, взять и закодировать его на том языке, который он выберет сам. И да, я периодически встречаю кандидатов, у которых 10 с лишним лет опыта работы, все резюме заполнено крутыми технологиями, но закодировать простой алгоритм они не в состоянии.
Знают отличие — да, все. Понимают, что из этих отличий следует (производительность, сильные и слабые стороны) — далеко не все. Осознанно принимают решение, что использовать — из джунов почти никто.
Ох уж мне эти эксперты... Прочитал статью, на которую автор ссылается, посмотрел немного про автора... Мне любопытно, откуда она взяла эти самые мистические числа "95%" и "5%"? В статье написано, что она взяла их из "личного опыта". Учитывая, что личного опыта у нее не так уж и много - менее десяти лет разработки в пяти компаниях - я бы не придавал этим обобщениям так уж много значения. Спектр типов компаний, в которых так или иначе идет разработка софта, невероятно широк, и у них ну очень разные требования как к качеству, так и к скорости разработки (кстати, мне совершенно не ясно, почему она валит в одну кучу большое количество багов и медленные релизы?).
Для меня лично дороговизна синхронизации этот инструмент делает непригодным.
А как же забыли "Детскую вычислительную машину ДВМ-1М"? https://bolknote.ru/all/4430/
Я пользовался их бетой. Было очень неплохо. Но когда они объявили цену, я сказал "нафиг-нафиг!" и перебрался на Outlook. Я, конечно, извиняюсь, но 50 долларов в год за почтовый клиент (неплохой, но ничего сверхъестественного) - перебор.
Нормального квалифицированного опытного сотрудника никто просто так выгонять не стремится. Чтобы такое написать, нужно ну уж совсем не понимать, как функционируют компании. В той статье, на которую имеется ссылка в начале, описан совершенно другой случай - токсичная примадонна. И, как верно сказано в той же статье, а также в ее продолжении, именно проблемы в менеджменте привели к тому, что вся эта ситуация зашла так далеко.
И, конечно, если автор видит менеджмент как кучку посредственностей, только и занимающихся тем, чтобы "спускать вниз очередное дурацкое распоряжение", то он (автор) просто еще немного не готов для анализа таких ситуаций. (Впрочем, после тезиса о том, что "текучка кадров выгодна компании" все стало ясно, и дальше читать не имело смысла).
Все вопросы, которые приведены в статье, очень правильные, и действительно по делу. Однако, к сожалению, они в основном относятся к общей осведомленности кандидата о современных аспектах разработки и к его способности хорошо об этом поговорить. Это важно; однако, когда я ищу разработчика, мне важны еще несколько вещей:
Умение не только говорить, но и делать - способен ли кандидат написать работающий код, пусть и не супер сложный? Ну не ФиззБазз - но, скажем, вариацию на тему Фибоначчи. Увы, мне попадалось немало кандидатов, красиво рассуждающих о тестировании и контейнерах, но неспособных самостоятельно перевести в лоб заданный алгоритм в рабочий код.
Наличие базового уровня технической грамотности. Хреново, если кандидат вообще себе не представляет разницу между линейной и квадратичной вычислительной сложностью.
Наличие опыта (если речь не идет о самой начальной позиции). Помимо рассуждений о том, как надо - пытался ли кандидат таки сделать так, как он рассказывает, и что из этого вышло (и почему).
И вот для того, чтобы получить представление об этих способностях кандидата, и приходится спрашивать про хэш-таблицы, заставлять писать код и въедливо допрашивать про прошлые проекты.
"Бизнесу на самом деле наплевать, когда будет сделана задача 12 а когда задача 23, главное чтобы в сумме за полгода было сделано более-менее много всего."
Это совсем не так. То есть ну просто СОВСЕМ не так. Каждая задача происходит от какого-то бизнес-проекта. Что-то обещано уже существующим клиентам, что-то нужно для новых, что-то - чтобы выполнить всевозможные требования или законы... Зависит от бизнеса, конечно. Но даже если речь идет просто о развитии продукта, то на выполнение задач в определенное время может быть завязано очень много чего - связи с другими компонентами, тестирование, документация...
А что касается переключений контекста... При планировании спринта эти соображения вполне нужно высказать, и совершенно нормально (если только не зверский цейтнот) включить задачу в спринт именно потому, что уже делается что-то близкое. Но вообще меня как руководителя весьма заинтересовало бы, почему на переключение окружения нужен целый день. Ну а про два дня на "буду сидеть злой" и "буду вспоминать" даже как-то и говорить неловко. Но да, переключение контекстов не бесплатно, и при планировании спринта это обычно по возможности стараются учитывать.
Похоже, наблюдаем начало конца американской индустрии разработки игр.
Я - менеджер в технологической компании в США. Эта статья написана человеком, который мало что понимает и в роли менеджера, и в бизнесе, и в офисной структуре.
В условиях распределенной команды важность роли менеджера и ее сложность только увеличилась. Менеджер - вовсе не надсмотрщик с плетью. Задача менеджера - построить команду, помочь ей организоваться и развиться и устранить все посторонние препятствия на ее пути. Да, в условиях удаленки некоторые из этих задач усложнились. Например, при личном общении, пусть даже и кратком, гораздо легче заметить признаки изменяющихся отношений в команде, увидеть невербальные признаки конфликтов, выгорания, потери интереса, и соответственно среагировать.
В офисе, кроме того, гораздо легче создавать культуру компании и команды. Мне посчастливилось работать в компании, где в офисе, помимо работы, кипела интереснейшая жизнь. Проводились лекции и семинары; в большом актовом зале разные техкомпании города периодически устраивали свои мероприятия - и мы могли присутствовать; разные отделы устраивали презентации своих разработок, зачастую в необычных формах; была куча клубов по интересам - клуб фотографов устраивал свои выставки, клуб любителей вина проводил тематические дегустации; была секция йоги, были замечательные праздники... В этот офис хотелось приходить, в нем хотелось быть. И эта культура помогала привлекать талантливых и интересных людей для работы и мотивировала их оставаться. В условиях удаленки создание подобной обстановки гораздо сложнее (если вообще возможно). Переманить людей становится гораздо проще - и это весьма волнует менеджеров.
Пресловутое увеличение производительности - вопрос не до конца ясный. На примитивном уровне - взял тикет, написал код, коммитнул, закрыл тикет - она, несомненно увеличилась. Но вот про более крупный уровень, когда мы говорим о создании систем, продуктов и решении бизнес-задач, есть сомнения; здесь как раз и нужны вот эти самые встречи и переговоры, поскольку нужно обсудить много вещей и связать много разных команд.
Что же касается ведения побочного бизнеса в рабочее время и прав на разработки, то, помимо этических вопросов (компания платит за рабочее время, предполагая полную отдачу), есть еще и сложнейшие юридические вопросы, которые возникают в таких случаях. Понятно, что если сотрудник, в период работы над системой параллельных вычислений, разработал новую методику охлаждения пива, вопросов не будет (как правило). Но вот если он разработал принципиально новую технологию распределения вычислительной нагрузки, ситуация становится принципиально иной. Беда в том, что между этими двумя полюсами - огромная "серая" зона, и зачастую проще решить вопрос кардинально.
Интересно, Тесла имел в виду «шарашки»?
Но, к сожалению, в большинстве случаев велосипеды изобретают из тщеславия — очень хочется сделать свой знаменитый проект — или из лени и неграмотности, когда не могут или не хотят разобраться с уже существующими решениями. И вот это скверно.
Так вот, как минимум 30%, а то и больше, кандидатов НЕ МОГУТ за 45 минут написать хоть как-то работающее решение.
«Определим последовательность Трибоначчи как последовательность, первые 3 элемента которой равны 1, а каждый последующий равен сумме трех предыдущих. Написать функцию trib(n), которая будет возвращать n-ный элемент последовательности.»
С моей точки зрения, человек, имеющий минимальный опыт программирования, должен без труда справиться с этим заданием меньше, чем за двадцать минут. Я даю на это до 45 минут, при этом сразу говорю, что основное задание — написать работающую программу, пусть даже она не оптимальна. Разве это стресс?