Найм программистов. Советы от программиста

    image

    Уже несколько раз натыкался на материалы о найме программистов и не без интереса читал их, ведь Я сам программист, и мне любопытно было узнать, как нас оценивают на собеседованиях.

    Мои впечатления? Я в печали... Почти все материалы, на мой взгляд, напоминают «вредные советы».

    Сразу оговорюсь, вся статья — это сугубо личное мнение, однако нашедшее поддержку в лице друзей и коллег программистов.

    Итак…

    Первая встреча, собеседование без тех специалиста


    HR-ы, не обманывайте себя. Вы никогда не поймёте на сколько хорош программист…

    Разве что только когда сможете воткнуть электроды ему в ухо и запустить end-to-end теститрование. Но пока таких технологий нет, всё что Вы можете оценить — это адекватность и, хотя бы отчасти, мотивацию человека сидящего перед Вами.

    И поверьте, этого достаточно.

    Ведь Ваша задача: найти человека, который сможет влиться в коллектив, плодотворно в нём работать и чтобы его работа вознаграждалась тем способом, который он ожидает, и который может обеспечить Ваша компания (деньги, признание, интересные проекты и т.д.).

    Все попытки спрашивать какие то технические нюансы будут выглядеть неуместно и беспомощно. Лично меня очень сильно раздражает, когда меня спрашиваю о том, в чем сами не разбираются. Хочется просто встать и уйти.

    Что ещё можно спросить на первом этапе? Зависит от специфики вакансии.

    Если Вам нужен опытный человек — спрашивайте об опыте, узнавайте какие задачи он решал, какие трудности преодолевал.

    Если Вам нужен человек, которого можно обучить, дайте ему пару логических задачек, проверьте живость ума.

    Собранной на первом этапе информации хватит чтобы отсеять 80% — 90% кандидатов.

    Часть вторая. Собеседование с тех специалистом


    НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ вне контекста практического опыта конкретного разработчика!

    Лично знаю несколько человек, которые учились со мной на программистов. У них от зубов отскакивали все теоретические выкладки, но когда дело доходило до реального программирования — ничего путного они сделать не могли.

    Что же, по моему, нужно спрашивать у кандидата?


    Спрашивайте технические нюансы из их предыдущего опыта, особенно те, которые пересекаются с будущей работой.

    По тому, как человек рассказывает, будет понятно:

    • Реально ли он разбирается в вопросе или просто придумал эти пункты для набивания себе цены.
    • На сколько его опыт и знания подходят для текущей вакансии.
    • Сможет ли он справиться с будущей работой.
    • Сможет ли он научиться, если не имеет подобного опыта.

    И, как мне кажется, этого достаточно, чтобы сделать финальный выбор.

    Больше о человеке Вы сможете узнать только на испытательном сроке.

    Надеюсь данный материал будет хоть кому-то полезен, спасибо за внимание.
    Поделиться публикацией
    Комментарии 224
      +7
      Меня как-то спрашивали формальное определение для smart-pointer. Не для чего и как устроен и какие виды его бывают и могу ли я его запрограммировать или взять из boost, напрмиер, а именно теоретическое определение. Я и сейчас не отвечу…
      Ещё спрашивали, какая сейчас самая мощная видеокарта. Я тогда хотел админом временно устроиться в сеть кофеен — ОЧЕНЬ ВАЖНО знать название самой мощной видеокарты, ценой в половину месячног ооборота этих кофеен. Снихсодительно рпиняли, но я отказался у них работать. После подобных вопросов лучше разворачиваться и скорее бежать подальше.
        0
        Вот как раз на счет видеокарты я уверен, что модель профессиональной видеокарты была бы засчитана как неправильный ответ. Не говоря уже о том что мощность видеокарты вопрос весьма дискуссионный и зависит от конкретной задачи (если конечно имеется в виду вычислительная мощность, а не электрическая).
          +1
          Увы, нет. Я стал уточнять, для чего будет использоваться комп, но меня сразу перебили и озвучили «правильный ответ» в виде самой дорогой на тот момент карточки. Ладно, не профессиональной, а что-то типа GeForseGTXUltraProGaming3 (больше десяти лет уже прошло, не помню название). Про-геймерской. При то, что компы были только для бухучёта и пасьяннса. Корчое, мне сразу «дали понять», что я не разбираюсь в железе и грош мне цена.)
            +2
            Вам дали понять, что грош вам цена в отмывании бабла на откатах. Понятно, что в бухгалтерам ничего не поставят (кроме встроенной), но в документах напишут супер-пупер-про-гейминг-карту. Конечно её никто не купит, а разницу поделят.
            Но денежки то выделены.
              0
              Правдоподобно.) Теперь я гораздо опытнее, но мне всё-равно нужно, чтобы подмигнули, тогда уже смогу «правильную» конфигурацию собрать.
            0
            Да нет, цена прямо пропорциональна вычислительной мощности. И играть на какой-нибудь Квадре P6000 можно будет с тем же комфортом как и на Титане Xp
            0
            А вопрос то неплох) Тру админы, которых я видел (особенно лет 5 назад), реально мечтали о топовом железе, чувствовали превосходство перед топ-менеджерами, так, как имели возможность себе по-тихому намутить хорошое железо для рабочего компа, и рубились в игры по локальной сети в периоды, когда у всех все работало, и их помощь не требовалась. Почти уверен, что вопрос был не в том, может ли человек сходу придумать конфиг компа под задачи, а в том, насколько он гик.
              +1
              Увы, вопрос был в том, что работодатель упорот.)
              Но ваш подход мне нравится — работодатель, проявляющий заботу об админе.Мол, нужен такой, который сможет себе игровую машину собрать, не пользуясь интернетом.)))
            +9
            Глас вопиющего в пустыне… ТС, Вы хоть понимаете, что те эйчары, которыми Вы возмущаетесь, не читают Хабр вообще. У них с утра лента ВК, где ничего, кроме их френдов, «Юмора Шрёдингера» и пары разной степени ванильности пабликов. А нормальным эйчарам Ваши советы в принципе не нужны. Они и так всё знают.
              +3
              Есть достаточно компаний, сотрудники которых сидят на хабре, но при этом принимают по старинке… Точно знаю, потому что собеседовался у таких.

              Плюс пост можно расшарить пост в ВК или скинуть ссылку знакомым, чтобы поднять общую планку наших HR-ов ;-)

              К тому же нельзя недооценивать непонимание многими людьми прописных истин. Что очевидно для разработчиков далеко не всегда очевидно для менеджеров или кадровиков.
                +1
                Уловка-22 :)
                +3
                Вообще бОльшая часть этого текста применима для собеседования любого специалиста, не только программиста. Критерий применимости — HR не понимает ни шиша в предметной области вакансии.
                  +3
                  Не так всё плохо, когда в предметной, зачастую HR не понимает в своей. «А что тут такого? Посидеть в интернете, найти пару человек по словам (зачастую не фильтруя, а листая список), позвонить, пригласить, задать несколько вопросов — обезьяна справится». Вот и получается что сисадмину звонят с предложением должности вышибалы в клубе (тоже как администратор значится) или задают дурацкие вопросы с неправильным «правильным» ответом, поскольку этот вариант написал предыдущий нанятый таким образом. Плюс только в том, что этот первый этап отсеивает не только соискателя, но и контору (желательно на этапе скайп или телефонного интервью).
                    +1
                    задают дурацкие вопросы с неправильным «правильным» ответом, поскольку этот вариант написал предыдущий нанятый таким образом.
                    Когда моего знакомого админа не взял начальник отдела после собеседования, потому что сотрудник умнее его ему был не нужен (конкурент же)…
                      0
                      Когда моего знакомого админа не взял начальник отдела после собеседования, потому что сотрудник умнее его ему был не нужен (конкурент же)…

                      А кто из участников собеседования эту версию озвучил?
                        0
                        Так как то была не работа мечты (обычная админская должность, а у друга уже была запись начальник отдела, при сравнимых зп), городок у нас маленький и многие друг друга знают или имеют общих знакомых, то сам новый начальник отдела, когда они вместе курили после собеседования. По свойски, так сказать, как один начальник отдела — другому. Хотя да, был не корректен — не умнее, а с большим опытом и знаниями.

                        Мне вот на другом месте сразу заявили, что из-за упоротой бухгалтерши, которая орет все то время, что ты пытаешься наладить работу компа, фиг ты получишь премию, которая положена по условиям головного филиала (она просто будет ставить каждый месяц низкий бал от своего отдела и всё). Ну вот в мелких городах иногда озвучивают некоторые моменты сразу)
                          0
                          Сказать честно, очень необычно, когда чувак так открыто и прямо говорит.
                          Такое и себе не всегда легко скажешь. Нужно быть сильно непростым человеком чтобы с кем то так поделиться.
                      +1
                      Вот и получается что сисадмину звонят с предложением должности вышибалы в клубе (тоже как администратор значится)

                      Было такое. Настойчиво приглашали на тимлида по JavaScript, хотя резюме было на джуна по Java. Звонила девочка раза три, и в третий раз так обижено «ну это же тоже жава, чего Вы не хотите к нам». Положил трубку и ржал в голосину просто.
                    +1
                    Да, сейчас чего только не придумают HR-ры. Раз дали тест по Laravel, в котором надо было отвечать на вопросы типа «как называется метод такого то класса который делает то то», или «как называется правило валидации такое то». В другой раз задали пару вопросов по типу «на сколько баллов от 1 до 10 я оцениваю свои занания Laravel и Symfony» и назвали это конкурсом, который я, конечно же, не прошел. Раз HR страшивала что такое ORM, Doctrine и Eloquent и что лучше, Active record или Data mapper. Видимо ей ответы не понравились, так как она потом даже не отписала ничего.
                    Технические специалисты тоже тупые вопросы задают, как раз как автор писал, ньюансы, которые не используются никогда или несущественны. Например, «что будет, если в PHP обьявить функцию внутри другой функции». Не могу даже представить, где такое можно использовать.
                    А вообще тема непрофессионализма HR-ов в последнее время становится все актуальное, в последний месяц вижу много постов и тут, и на доу, и в линкедине, но их это ничему не учит.
                      +3
                      Например, «что будет, если в PHP обьявить функцию внутри другой функции». Не могу даже представить, где такое можно использовать.

                      Можно использовать, например, для создания геттера данных для кэша. Если кэш отсутствует вызывается геттер, имеется ввиду лямбда функция, конечно.
                      +1
                      Перед интервью я всегда спрашиваю код. Любой. Обычно достаточно посмотреть на него, чтобы понять, стоит ли общаться, и, если стоит, на основании этого кода сформировать список вопросов Например: какие вещи можно улучшить и как, где можно оптимизировать, и почему выбрано вот это решение, а не другое.
                        0
                        Проблема в том, что не всегда можно показывать код с предыдущих проектов. Конфиденциальность, все дела.

                        А выдернуть какие то написанные модули, оформить и залить код в свой гитхаб не всегда время есть.

                        Но как вариант можно попросить перед собеседованием накидать пару модульков, которые что то делают и обсудить этот код. Главное не переборщить, типа — напишите нам CRM систему с блокчейном и ML, а мы подумаем собеседовать Вас или нет.
                          +2
                          Проблема в том, что не всегда можно показывать код с предыдущих проектов. Конфиденциальность, все дела.

                          Я всегда считаю, что это отмазка. У программиста не может не быть возможности показать код. Не нужно гитхабов, я прошу просто один файлик, даже одной функции достаточно. И, да, тестовое задание обычно предлагается, но не все готовы его выполнять. А если человек не готов делать ни то, ни другое — тут медицина, как говорится, бессильна. Но лично я считаю глупостью выполнять тестовое задание, если у меня куча написанного кода, который можно просто показать. К тому же ни одна компания из тех, с которыми я имел дело, так кропотливо не проверяет и не анализирует тестовые задания, как это делаю я, поэтому смысла не вижу тратить время.

                          Но как вариант можно попросить перед собеседованием накидать пару модульков, которые что то делают и обсудить этот код.


                          Да, я так делал. Но обычно половина программистов из тех, которые не могут писать код, легко отвечают на такие вопросы (теоретики), а половина из тех, которые реально успешно работают, не могут, например, потому что волнуются. А когда человек комментирует свой код, он точно про него все знает. Тут важно в первую очередь понять, его ли это код (бывали и такие случаи).
                            0
                            Тут важно в первую очеред понять, его ли это код (бывали и такие случаи).

                            Ели он чужой код может адекватно прокомментировать, есть ли разница его ли это код?

                            Проблема не в копировании со stackoverflow, а в понимании как скопированный код работает. Если понимает и умеет применять, то пусть копирует.
                              +2
                              При этом если он говорит, что это его код — этот человек не подходит. Зачем иметь дело с такими? Мне не доплачивают за работу с моральными уродами.
                                0
                                У меня все хуже — я написал например балансир для распределения нагрузки по инстансам. А через пол года мне задают в лицо вопрос «ну-ка, а расскажи нам, как это у тебя тут работает», на что я залез в код, полистал и честно дал ответ «без понятия, коробка с магией, ошибок же не было, значит коробка с рабочей магией».
                                Увы, я порой не могу вспомнить как работает то, что писалось еще позавчера — работать мне не мешает это, задачи выполняю.
                                Объяснить не очень могу, если «логика» с «изюмом»… но обычно только такие задачи и приходится решать.

                                P.S. Вот нет в webDriver какого-то функционала… и тут приходится уже и сам «драйвер» патчить/кастомить — да я такое никогда потом толком не смогу объяснить.
                                  +3
                                  Лично меня бы такой ответ не устроил. Потому что настоящая работа — это не вспоминать свой трудный код сложной системы, а разбираться и подкручивать что-то в таких вот «черных ящиках», написанных не вами. А это для вас будет задачей невыполнимой. Конечно, если ваша задача — это создание чего-то нового с нуля… Хотя и это я бы вам не доверил — вам же потом это поддерживать, а вы на это не способны. Увы, отказ.
                                    0
                                    А меня такие ответы не устроят, вам мой отказ.

                                    Поддерживать != помнить «как и что работает».
                                    Если вы не понимаете таких прописных истин — о чем вести диалог то?

                                    У человека есть ресурс «оперативной памяти» — вместо забивания своего кэша ненужным хламом предпочитаю хорошо понимать то, чем занимаюсь в данный момент. Это на тяжелых задачах требует колоссального внимания и концентрации.
                                      +3
                                      Вы можете не помнить, но вы же понимаете, что вы на собеседовании отказались разобраться в том, как работает вами же написанный код?
                                        0
                                        Эм, минуточку, есть маленький нюанс. У меня есть три вида кода (ну ок, есть еще четвертый… дома что-то могу пробовать-баловаться):
                                        — Тот, который «написать и забыть» т.к. это прямое его назначение (ну там фикс чего-то мало-значительного в SCSS, либо прикрутить календарь bootstrap-compatibility)… такое при всем желании даже не смогу «ни вспомнить, ни описать нюансы». Лишь знаю, что такое делать приходится.
                                        — Тот, который трогается очень медленно, больно, в нем нет unit-tests ибо ковыряния — это реверс-инжиниринг… в таких местах всегда любое изменение «потом» будет требовать самого тщятельного рассмотрения со всех сторон (мы ведь не хотим решения «тяп-ляп, у себя починили, у остальных сломали»?). Такое и не показать (ибо пол проекта тащить надо — задача сугубо прикладная, в «контексте»), и не объяснить человеку со стороны. Скажем даже если будем обсуждать мои правки webDriver, вы, как человек вне «темы» ничего не поймете.
                                        — Что-то, что относительно автономно, изолированно. К таким задачам я делаю отдельные микро-репозитории с кодом «только по задаче» и пишу README.MD

                                        Так вот, если будет по задаче нужно разобраться в модуле/подсистеме/проекте — я сяду и разберусь. Смогу ли я объяснить? Это зависит от собеседника. Т.е. №2 — под вопросом. №1 просто отпадает автоматом (но я могу в целом поговорить абстрактно о подобном, без перехода к тому, что делал конкретно в том случае)
                                        №3 обсудить всегда смогу — ман самописный прочесть я способен, быстро вникнуть и понять так же.

                                        При этом, если речь идет о собеседовании, то это тоже как бы «задача» (найти работу/проект) — значит даже на №2 можно и поговорить, но нужен глубоко понимающий нюансы собеседник + мне надо конкретно знать, что стоит в голове себе же освежить (иначе не отвечу почему «тут идет переписывание функционала библиотеки»).

                                        И да, я от тестового задания как раз таки не отказываюсь.

                                        Выводы? На мой взгляд они такие — у вас, исходя из нашего диалога, весьма резкое суждение по малому набору критериев и поспешные выводы.

                                        P.S. Я в жизни не знаю людей, что пишут на связке Java+PHP+JS с тонной обвеса (всевозможные системы сборок, фреймворки, библиотеки, суб-задачи) и еще при этом помнят «что писали вчера». Тут не свихнуться бы.
                                        0
                                        Хм, не гений, но не помню ни разу, что-бы я не мог объяснить как работает мой код, когда бы он ни был написан! Или я пишу хорошо, или разбираться умею…
                                  +1
                                  Проблема не в копировании со stackoverflow, а в понимании как скопированный код работает. Если понимает и умеет применять, то пусть копирует.
                                  Вот уже не первый раз читаю такие комментарии, и я не могу представить, как можно не понимать как какой-то код работает. Ну т.е. да, можно не знать какую-то библиотеку или фреймворк на основе которого написан этот код, но можно просто посидеть, поразбираться и понять, что тут происходит.
                                  Ну а если уж в данном участке используется какая-то ну суперзапутанная логика, с которой очень долго разбираться, ну так мы же говорим про код для собеседования, ну ненужно копировать такие сложные куски.
                                    0
                                    посидеть, поразбираться и понять, что тут происходит.

                                    Значит Вы с таким не сталкивались, везет. Есть много людей, которые не хотят разбираться и понимать что происходит, они хотят скопировать и чтобы всё заработало.
                                      +1
                                      Какндидаты в манагеры, что сказать. Все по классику:

                                      Воля царская моя — Не хочу знать ни х.я,
                                      Где пили, кого е.и.
                                      НО ЧТОБ БЫЛИ КОРАБЛИ!!!
                                        +1
                                        которые не хотят разбираться и понимать что происходит, они хотят скопировать и чтобы всё заработало.
                                        Увы, таким не место в инженерии.
                                    0
                                    У меня есть небольшие куски кода (до 300 строк), которые я могу показывать, однако с комментированием их проблема.
                                    Просто они достаточно сложные чтобы через пол-года после написания помнить детали логики. А читается такой код плохо.
                                    Пример — реализация универсального логирования на С++. Сложность в большом количестве интерфейсов внутри и хитрой логике добавления информации, вплоть до трассировки стека для фаталов.
                                    Другой пример — реализация на С++ максимально совместимого с QT функционала сигнал/слот (была задача с минимальным вмешательством в код позволить механизму сигнал/слот работать как с использованием QT (когда есть UI), так и на чистых C++ (в качестве библиотеки) без использования внешних препроцессоров и кодогенераторов). Сложность в большой вложенности вариативных шаблонов (variadic templates)

                                    P.S. Только не стоит говорить что такой код нельзя использовать в продакшн :).
                                      0
                                      опыт работы с графикой есть? как у вас с qml? код в студию
                                        0
                                        QML и графика — опыт посредственный, да и не скажу что работу тут ищу :)
                                        Упомянутый и другой код пока публиковать на всех не собираюсь :)
                                    +1
                                    Проблема в том, что не всегда можно показывать код с предыдущих проектов.

                                    Когда устраивался на первую работу, принес дискету со своими программами, написанными в студенчестве, они её скопировали и взяли 3 дня на изучение. Судя по тому, что меня приняли, код им понравился. Я ещё в школьные годы писал 2D-игры just for fun.

                                    Если у программиста нет своих программ, это значит, что он не увлечен всерьез программированием, такого рискованно брать — скорей всего, он будет работать безынициативно и с малой мотивацией.
                                      –4
                                      «Если у программиста нет своих программ, это значит, что он не увлечен всерьез программированием» — да ну, бред. Если ты по 8 часов в день работаешь за компом, то в свободное время нужно заняться чем то другим, или скоро начнутся проблемы со здоровьем. Конечно, если ты на работе по пол дня сидишь без дела то можно и пописать что то свое, или если целый день круды пишешь
                                        +3
                                        То есть еще вчера вы не писали программы — а сегодня уже программист? Так не бывает. Не бывает, что вы не писали программ и научились. К тому же, если вы хотите устроиться на действительно хорошую работу, надо побеспокоиться о том, чтобы доказать новому работодателю свою пригодность. А если нет — то конечно, тут можно говорить про 8 часов, и как вы устаете после работы, и что вам вообще лень что-то кому-то доказывать. Тогда прошу прощения, вам придется работать там, где не нужно напрягаться, но где и не платят высоких зарплат. Но не жалуйтесь потом на жизнь. Сами сделали выбор.
                                          –2
                                          Я не говорю о тех кто ищет первую работу. Увеличение количества рабочих часов пропорционально ухудшению качества кода.
                                            +2
                                            Тогда не понимаю о ком вы говорите. Какой-то сферический программист в вакууме. Код он писать умеет, но показать нечего.
                                              +1
                                              Представьте, что Вы нанимаете доктора. «Покажите вылеченных пациентов? Не привели? Ну, притащите истории их болезней с предыдущей работы? Не можете? Ну, покажите, кого лечили во внерабочее время? Нет таких? Ну, какой же Вы тогда доктор...»
                                                +4
                                                «Вот, тут я себе аппендицит удалил»
                                                –1
                                                Чем бы дитя не тешилось, лишь бы тестовое задание не делать.
                                                  +1
                                                  Это выглядит таким себе суперсарказмом до тех пор пока вас дантист не спросит — не против ли вы того, чтобы снимки ваших зубов попали бы в его портфолио.

                                                  И да, я был не против, если там будут только зубы, а не мои паспортные данные.

                                                  Так что попробовав «довести ситуацию до абсурда» вы, вместо этого, показали что FadeToBlack действует правильно и грамотно.
                                                    +1
                                                    У нашего ортодонта на компе десятки папок с фотками его клиентов. Он знает, какие скобки кому ставил и сфотографирован весь прогресс лечения. Фото через каждые несколько месяцев. Чтобы убедить нас работать с ним, он показывал нам фото и прогресс самых сложных случаев. А как еще работать в мире неучей и самозванцев? Одни говорят «я умею», а у других за каждым «я умею» — годы обучения и работы. С виду они похожи. Улыбаются, говорят. Умеют складывать 2+2. Но почему то проблем с кодом никогда нет у тех, у кого есть хоть какой-то опыт.
                                                  –2
                                                  Это реальный программист. По себе знаю, что бывают периоды, когда много переработок и сон то не всегда 8 часов и приходя домой меньше всего хочется что-то ещё программировать. Причем такие периоды бывали по несколько месяц, когда и в выходные работал.

                                                  Когда не перерабатываю, я человек семейный и мне надо уделить время семье + домашние дела, что-то прибить, что-то поменять. Да и отдохнуть хочется. И в таком режиме я уделяю 1 час в день на изучение новых инструментов, погружение и расширение знаний по уже изученным технологиям.

                                                  Это я к тому, что я предпочитаю развивать после работы, а не писать код для собеседований. А код, который я когда-то писал 2-3 года назад, стыдно показать :)

                                                  Но соглашусь с вами, когда я буду искать новую работу, тогда да, я сяду и напишу код, который будет отражать мои реальные знания на данный момент.
                                                    +1
                                                    А как вы эти технологии изучаете? Я вот тыкаю в Идрис — у меня есть пара не самых тривиальных решений задачек, которые не стыдно показать, например. Регулярно ковыряю свежие плюсы — тоже есть, что показать.

                                                    Ну и да, это все просто означает, что у человека несемейного будет перед вами преимущество при трудоустройстве, по крайней мере, в некоторые компании.
                                                      0
                                                      Я прохожу разные интерактивные курсы, плюс изучаю книги и статьи, решаю оттуда задачки, но я не сохраняю код простых и небольших задач. Да и тем более не сохраняю код из интерактивных курсов))

                                                      У меня просто свой список технологий, которыми я должен овладеть и подтянуть. Как-то только этот список иссякнет, тогда уже в качестве закрепления изученного, буду писать небольшие проекты. И тогда буду их сохранять, чтобы можно было показать.

                                                        0
                                                        Ну это странно. Я храню каждую строчку написанного кода. По крайней мере, стараюсь. Советую вам делать то же самое. Иногда я прихожу на собеседование, а им нужно вот прям то, что я однажды делал, потратил на это вечер, и вроде бы это фигня… Но сам факт того, что я показываю им релевантный проект играет огромную роль. А очень часто в работе нужен прям какой-то такой же алгоритм, и вроде ничего не стоит написать его самому, но… Вдруг его пишет подчиненный? Достаешь код, говоришь, что писал это в 17 лет, показываешь дату на файле. Работа идет в три раза быстрее и в разы интереснее.
                                                          0
                                                          А как же NDA?
                                                          По NDA я не могу показать то, что делаю по работе.
                                                          А то, что я пишу сам для себя дома — совсем далеко от типичных вакансий.
                                                            +2
                                                            Лично мне без разницы, далеко или близко от вакансии. Важно посмотреть на ваш код и понять, на что вы способны.
                                                              0
                                                              Ну, и как вам поможет понять на что я способен, если
                                                              — позиция по PL/SQL
                                                              — а код внерабочее время написан на C++? (или вовсе на экзотическом языке)
                                                                0
                                                                Ну вот я недавно на флаттер наткнулся и прям влюбился в него можно сказать, так что на нем напишу для себя пару приложений. Возможно выложу на гитхаб и тогда, когда в следующий раз буду искать работу, ссылку на него приложу. По крайней мере по этому коду можно будет понять что я в принципе могу использовать разные технологии, работать самостоятельно, структурировать код и т.п.
                                                                  +2
                                                                  Почему вы других людей держите за идиотов?
                                                                    0
                                                                    А по существу ответить не можете?
                                                                    Как вы не ответили как по коду на C++ сможете оценить способности по написанию кода на PL/SQL?
                                                                    habr.com/post/424569/#comment_19169069
                                                                    FadeToBlack: Лично мне без разницы, далеко или близко от вакансии. Важно посмотреть на ваш код и понять, на что вы способны.

                                                                    — ваши слова!
                                                                      0
                                                                      Допустим так:
                                                                      1. Берем код на С++
                                                                      2. Смотрим его
                                                                      3. Если он в порядке
                                                                      4. Спрашиваем про знание PL/SQL
                                                                      5. Если ответ утвердительный, берем на работу
                                                                      6. Если нет, спрашиваем про желание изучать эти технологии
                                                                      7. Если ответ утвердительный, берем на работу
                                                                      8. Если предоставленный код на С++ не в порядке
                                                                      9. Тут можно думать, спрашивать, собеседовать
                                                                      10. Но мала вероятность того, что человека можно будет взять на работу.

                                                                      Почему? Да потому, что профессионал никогда не будет присылать фиговый код. И даже не потому, что он умеет. А потому, что он знает, что он умеет, а что нет. И зная, что он не умеет с++, он его присылать не будет. А если прислал — значит толком он ни в чем не разбирается. Выводы могут показаться сомнительными.
                                                              0
                                                              Какие-то интересные и простые решения, я для себя тоже сохраняю, хотя обычно они откладываются в голове.

                                                              За совет спасибо, попробую сохранять весь код, который я пишу в нерабочее время. На собеседованиях периодически просили посмотреть код, не важно где и какой.
                                                  0
                                                  Чтобы эти проблемы не начались, достаточно двигаться час в день, и пару раз в неделю ходить в качалку.

                                                  И, получается, круды на здоровье влияют меньше, чем что-то более сложное?
                                                    0
                                                    Отказывать себе в подвижном хобби, программируя в свободное время, чтобы ходить в качалку — звучит как набор костылей. Вы нам не подходите.
                                                      +1
                                                      Программирую в свободное время я не для того, чтобы ходить в качалку, а для того, чтобы получать удовольствие от программирования. А в качалке я вообще по дорожке хожу и ставлю перед собой планшет со статьями для чтения.

                                                      Вы не слышите, что вам говорят собеседуемые. Я вам перезвоню.
                                                  0
                                                  Хоть все кому не лень сейчас и лезут в программирование, но кадров жестко не хватает. И если выбирать только среди тех, у кого есть своя кодовая база, то далеко не уедешь. Ну, мне так кажется…
                                                    +2
                                                    Вот это кстати отличный показатель — стоит ли вообще идти на собеседование. Кадров всегда хватает, просто кто-то собирается платить зарплаты ниже рынка. И вот если в какой-то компании жалуются на нехватку кадров, значит и идти к ним не стоит: там либо с деньгами будет плохо, либо с условиями.
                                                      0
                                                      но кадров жестко не хватает

                                                      Я это писал в плане того что сейчас очень много вакансий и каждый день открываются всё новые…

                                                      Вот это кстати отличный показатель — стоит ли вообще идти на собеседование

                                                      Не соглашусь. Вот например искали разработчика с опытом, ЗП выше среднего по рынку, условия стандартные, компания довольно известная. Приходит много народа, но совсем зеленые, а там нужно чтобы пришел человек и с минимум вопросов смог начать что то делать.

                                                      Мне кажется сейчас обилие программистов только на уровне джуна. А если брать планку чуть выше, то идет жесткий дефицит.

                                                      Поясню: ничего не имею против джунов, просто специфика вакансии требовала кого-то по опытнее.
                                                        0
                                                        Так и обилие вакансий тоже на уровне джунов.
                                                        По моим наблюдениям большинство не парятся и в описании вакансии включают все знакомые им страшные слова. Отсюда и кажущаяся видимость множества серьезных вакансий.
                                                          0
                                                          Я о вакансиях по ЗП обычно сужу. Не каждому джуну 120к р зп ставят. А вакансий 120к+ р хватает и их количество растет.
                                                            0
                                                            Если вы говорите про Москву то это и не удивительно.
                                                            В регионах все намного хуже.
                                                              0
                                                              Да, Я по Московским сужу)
                                                              У нас в регионе у мидла с опытом зп в среднем 70к р
                                                                0
                                                                Ну так о чём я и говорил. Если у вас мидлу предлагают 70k, а в Москве это зарплата джуна, то логично, что этот мидл поедет в столицу, на зарплату в два раза выше, и поэтому в регионах одни джуны и приходят.
                                                                  0
                                                                  В Москву не все готовые переехать, особенно если учесть что мы не в России, а в Казахстане.
                                                                    +1
                                                                    Вы не поверите, но вот только у меня в кабинете из 9 человек, 3 из Казахстана.
                                                          0
                                                          Не соглашусь. Вот например искали разработчика с опытом, ЗП выше среднего по рынку, условия стандартные, компания довольно известная. Приходит много народа, но совсем зеленые, а там нужно чтобы пришел человек и с минимум вопросов смог начать что то делать.

                                                          Мне кажется сейчас обилие программистов только на уровне джуна. А если брать планку чуть выше, то идет жесткий дефицит.

                                                          Если брать планку чуть выше — то и денег нужно предлагать чуть больше. Глупо предлагать условные 2-3 тысячи в месяц, а потом удивляться: «Ой, как так? Интересно, где опытный человек, способный придти и с минимумом вопросов начать что-то делать?»
                                                            0
                                                            ЗП выше среднего по рынку
                                                              0
                                                              ЗП выше среднего по рынку

                                                              Не бывает такой заработной платы. Бывает только в виде цифр и валют. Например: от 360 тыс. рублей в месяц. Или £50k — 90k в год.

                                                                0
                                                                У нас в регионе мидл с опытом имеет в среднем 70к деревянных.
                                                                Мы ставили 80к+.
                                                                Выше среднего по рынку…
                                                                  0

                                                                  IT рынок глобализован, поэтому среднее по региону слабо волнует людей с опытом. Судя по текущим раскладам, мидл с опытом не будет рад з/п меньше 90 т.р., а если у него ещё и с английским всё хорошо, то умножайте на 1.5.
                                                                  Всё что ниже, можно считать ниже среднего по рынку, вне зависимости от региона.

                                                                    0
                                                                    Да вот ни разу не глобализирован.

                                                                    То есть да, можно найти удаленную вакансию, хотя их и в разы меньше, но так делает очень маленький процент разработчиков. Все в офисы рвутся. Во первых потому что у нас менталитет такой, ещё не привыкли работать удаленно. Ну а вторая очень веская причина — у нас компании не умеют с удалёнщиками работать.

                                                                    Вы сами сейчас работаете удаленно?

                                                                    На западе да, это нормальная практика. Но со знанием английского лучше сразу переехать за рубеж.
                                                                      0
                                                                      То есть да, можно найти удаленную вакансию, хотя их и в разы меньше, но так делает очень маленький процент разработчиков.

                                                                      В разы меньше, чем где? Вы же сами написали, что не из Москвы, поэтому я сильно сомневаюсь, что кол-во вакансий в вашем городе может сравниться с кол-вом вакансий на удалёнку. В большинстве региональных центров по конкретному профилю редко бывает более 5-7 компаний, ещё реже бывает, чтобы они все одновременно имели открытые вакансии.


                                                                      Ну а вторая очень веская причина — у нас компании не умеют с удалёнщиками работать.

                                                                      Даже в России есть которые умеют, но необязательно себя российскими компаниями ограничивать.


                                                                      Вы сами сейчас работаете удаленно?

                                                                      Буквально в этом месяце переключился на офис для разнообразия, до этого 7 лет удалённо работал.


                                                                      Но со знанием английского лучше сразу переехать за рубеж.

                                                                      Кому лучше и зачем? У меня, например, никогда такой цели не было, хотя почти каждый месяц приглашают куда-то переехать.


                                                                      Вы поймите одно: с одной стороны, Вы хотите найти высококвалифицированных специалистов, а с другой — считаете, что они не способны удалённо работать. Это противоречащие требования. Те, кто развивается, за редким исключением личных обстоятельств, способны работать на любой рынок. А те, кто "я могу только из офиса, даже если из дома будут в 2 раза больше платить и проекты будут поинтереснее" — они почти все вечные джуны или максимум мидлы, если с офисами повезло.

                                                                        0
                                                                        В разы меньше, чем где?

                                                                        Чем в городе с количеством жителей миллион+.

                                                                        В большинстве региональных центров по конкретному профилю редко бывает более 5-7 компаний

                                                                        На чем основаны данные?

                                                                        Буквально в этом месяце переключился на офис для разнообразия

                                                                        Что значит для разнообразия? Если удаленка так прекрасна и универсальна, почему не устроиться на другую удаленную работу? Рынок же глобализирован…

                                                                        Даже в России есть которые умеют, но необязательно себя российскими компаниями ограничивать.

                                                                        Я то говорил конкретно о нас. Мы не умеем с удаленщиками работать. А так как выстраивать процесс работы с удаленщиками — дело не простое, то мы искали человека в офис.
                                                                        Если же говорить о том, что все местные хорошие разработчики работают удаленно, то сильно сомневаюсь, всё по тем же причинам, о которых писал выше.
                                                                        Ну и опять, если удалёнка так хороша, то почему у одних и тех же компаний вакансии висят очень долго? Ведь если по Вашему, к ним всё СНГ должно проситься и от резюме не должно быть отбоя.

                                                                        Кому лучше и зачем? У меня, например, никогда такой цели не было, хотя почти каждый месяц приглашают куда-то переехать.

                                                                        Ну и Вы по себе всех судите…
                                                                          0
                                                                          На чем основаны данные?

                                                                          На многолетних наблюдениях за локальным рынком. Ну ладно, в миллионниках может быть 10-15 более-менее серьёзных компаний в одном сегменте. Существенно больше только в Москве и Питере. Но всё равно это странно сравнивать с сотнями remote-вакансий.


                                                                          Что значит для разнообразия?

                                                                          Есть должности, на которых удалёнка проблематична. Решил поработать техническим директором и посмотреть насколько мне будет интересно в этой роли.


                                                                          Ну и опять, если удалёнка так хороша, то почему у одних и тех же компаний вакансии висят очень долго?

                                                                          Это Вы про кого? Какие-нибудь Crossover или Toptal? Это не конечные компании, а прослойки, поэтому у них постоянный найм.


                                                                          А так как выстраивать процесс работы с удаленщиками— дело не простое

                                                                          Это, кстати, заблуждение. Никаких кардинальных сложностей в этом нет. Просто удалёнщики должны быть способны к самоорганизации.


                                                                          Ну и Вы по себе всех судите…

                                                                          Ну а Вы по себе, поэтому я Вам и показываю альтернативный взгляд. И объясняю, почему к вам не ломанулась куча специалистов, когда вы чуть выше среднего по региону з/п поставили. Ваше право сомневаться в моём объяснении, но более правдоподобного у Вас ведь всё равно нет.

                                                                        0
                                                                        А ещё разработка сайтов очень отличается от разработки железа и вторые на удалёнке не очень популярны.
                                                                          0

                                                                          Вы имеете в виду само железо или прошивки под него? Второе, в принципе, возможно на удалёнке, но процент таких вакансий будет ниже, в силу специфики.

                                                                            0
                                                                            И железо, и прошивки. Зачастую прошивку надо залить и испытать на железе, а держать кого-то «на базе» — накладно (возможен только приводимый когда-то на хабре вариант — когда железо в Африке и ехать туде накладно и не хочется).
                                                            0
                                                            Бред. Работаю в компании, в которой отличные условия и хороший уровень зп. А кадров не хватает. Собеседуем по 5-6 человек в неделю, берем максимум 1-2 в месяц. Причем, вакансия на сеньора, приходят «программисты», которые простой код на 10 строк не могут написать за 15-20 минут.
                                                              +1
                                                              Подтверждаю, та же фигня.
                                                                0
                                                                которые простой код на 10 строк не могут написать за 15-20 минут.

                                                                А какой код, можно узнать? Просто на том же LeetCode есть сложные задачи на 5-8 строк, которые без умения решать такие задачи, минут за 15-20 не написать.

                                                                  0
                                                                  Да очень простой: сгруппировать слова, которые состоят из одного набора символов. На входе массив слов, на выходе массив групп.
                                                                    0
                                                                    О, прикольная задачка. Есть решение на 5-8 строк? Можно посмотреть?
                                                                      0
                                                                      Я бы решил так — разбил слова на символы, отсортировал все массивы и сгруппировал схожие.
                                                                      Но в коде интересно посмотреть.
                                                                      !* Возможно Я не прав… =)
                                                                        0
                                                                        Ну это и есть правильное решение, но вы-б видели что пишут «сеньоры»…
                                                                        0
                                                                        Чего мы хотим? Экономии памяти или времени? Можно ли пользоваться дополнительной памятью? Можно ли пользоваться стандартные алгоритмы?

                                                                        Хорошая задачка на «поговорить» для собеседования, не очень хорошая, если у вас есть только код.
                                                                          0
                                                                          Хотим получить рабочее решение. Можно использовать всё, что дает язык.
                                                                            0
                                                                            А если слов несколько тысяч?
                                                                            А если несколько млрдов?
                                                                            А если слова лежат на ленте?
                                                                            А набор букв очень большой?
                                                                            ;) ну и т.д.
                                                                              0
                                                                              И? К чему эти вопросы?
                                                                                +1
                                                                                Если человек сразу пытается решить задачу, то возможно он хорош как исполнитель.
                                                                                Если человек задает уточняющие вопросы, пытается выяснить окружение, и прочие детали, то возможно он лучше подходит для проектирования.
                                                                                В целом нужны и те, и те, но образ мысли кандидата помогает понять к чему склонен кандидат.
                                                                                  0
                                                                                  Или человек любит переусложнять всё ;)
                                                                                    0
                                                                                    Или человек когда-то решал задачу, а потом оказалось что всё не так и теперь пытается уточнить. Или интервьюер задаёт вопрос «сложить два числа», а сам (как в одной компании) ожидает что кандидат уточнит что за числа, отработает случай не-чисел в случае строкового ввода, обработает варианты разных записей, проверит переполнение.
                                                                                      0
                                                                                      Всё может быть. Я не говорил, что задавать вопросы запрещено.
                                                                              0
                                                                              Ну если просто рабочее решение, то можно сделать что-то типа:

                                                                              auto regroup(std::vector<std::string> words) {
                                                                                std::map<std::set<char>, std::vector<std::string>> set;
                                                                                for (const auto& word : words) {
                                                                                  const auto& key = std::set<char>(begin(word), end(word));
                                                                                  set[key].push_back(std::move(word));
                                                                                }
                                                                                std::vector<std::vector<std::string>> groups;
                                                                                for (const auto& group : set) {
                                                                                  groups.push_back(std::move(group.second));
                                                                                }
                                                                                return groups;
                                                                              }
                                                                              
                                                                              int main() {
                                                                                std::vector<std::string> input = { "ab", "xy", "ba", "yx" };
                                                                                const auto& output = regroup(input);
                                                                                for (const auto& group : output) {
                                                                                  std::cout << "[" << std::endl;
                                                                                  for (const auto& word : group) {
                                                                                    std::cout << word << std::endl;
                                                                                  }
                                                                                  std::cout << "]" << std::endl;
                                                                                }
                                                                              }
                                                                              
                                                                              

                                                                              Но тут эффективность… так себе. Памяти много тратится и всё такое… Но чтобы сделать лучше нужно больше информации про задачу…
                                                                                0
                                                                                Да какая разница, сколько памяти или времени жрёт? На собеседовании смотрим умение решать задачу, а не качество решения. Если человек решил, но плохо — даем направление подумать, как можно сделать лучше. Сделает — отлично, нет — ничего страшного. Всего-лишь один этап из 3х.
                                                                                  0
                                                                                  Так я уже сказал — это хорошая задача для собеседования, плохая для «заочной» оценки кода. Если у нас 8-битная кодировка, можно битами кодировать set — эффективность заметно улучшится. А если это «большой» Unicode с миллионом символов — то не стоит. Там лучше сортировать буквы в слове.

                                                                                  На многоядерной системе можно устраивать разного рода параллелизацию.

                                                                                  И прочее, прочее, прочее.
                                                                                  0

                                                                                  Что-то многословно. Я решу эту задачу с одной строки!


                                                                                  > yayGroup = map (map fst) . groupBy ((==) `on` snd) . sortBy (comparing snd) . map (\w -> (w, nub $ sort w)) . words
                                                                                  > yayGroup "foo ffo bar rba rrba fof"
                                                                                  [["bar","rba","rrba"],["foo","ffo","fof"]]
                                                                                    0
                                                                                    В одну всё равно не влезло. И да — C++ он такой, многословный…
                                                                                      0
                                                                                      Это просто коммент мелкий, в repl'е-то в одну строку.

                                                                                      Но такой код на ревью я бы, конечно, завернул.
                                                                                      0
                                                                                      Так не верный ответ)
                                                                                        0
                                                                                        Это зависит от того, что понимать под «одним набором символов». Разница между множеством и мультимножеством, собственно.

                                                                                        Если вы хотите вместо чётких математических терминов использовать свои изобретения — то не удивляйтесь, если вас неправильно поймут.
                                                                                          0
                                                                                          Ну да, верно. Но я не давал тут задачу 1-в-1 из собеседования, потому и решили не верно. Виноват, сорри.
                                                                                          0
                                                                                          А какой верный для этих слов?
                                                                                            0
                                                                                            Выше написал — мой косяк, надо было привести задачу 1-в-1 с собеседования, я дал упрощеное описание. Правильный ответ: [[«bar»,«rba»],[«rrba»],[«foo»],[«ffo»,«fof»]]
                                                                                              0

                                                                                              А, ну тогда убрать там nub, и будет удовлетворять этому условию.

                                                                                                0
                                                                                                В C++ в двух местах заменить придётся std::set на std::multiset… да C++ — он такой… многословный… не Java, но, тем не менее… иногда это бесит…
                                                                                  0

                                                                                  У вас реально в компании сеньоры такими задачами занимаются? Или вы просто чтобы джуниоров подбодрить называете их сеньорами?

                                                                                    0
                                                                                    Пропустили начало треда?)
                                                                                      0

                                                                                      Вы, вроде, начали с "Причем, вакансия на сеньора".

                                                                                        0
                                                                                        Верно. И это задача для собеседования, а не для реальной работы.
                                                                                        У нас 3 задачи, но мы не ищем всезнаек, ищем тех, кто умеет думать. Для этого не обязательно давать сложные задачи на 3-4 часа, достаточно парочки совсем простых.
                                                                                          0

                                                                                          Имхо, для сеньоров — это не простая задача, а тупая. И единственный ответ, который я бы от сеньора принял как правильный, — назначить этот таск джуниору или стажёру.
                                                                                          Вопросы, которые Вам выше писали тоже уместны, т.к. люди хотя бы пытаются понять с какого перепуга им прилетела эта задача, где в ней сложность, с которой не справился стажёр.
                                                                                          Если человек начинает решать такую задачу, то на должность сеньора он не подходит, т.к. не имеет навыков делегирования и проактивного подхода к задачам.

                                                                                            +1
                                                                                            Ну ок. Хотя я не согласен полностью.
                                                                                              +1
                                                                                              С таким подходом можно внезапно вместо сеньора нанять мееенеджера, который в программирование вообще не умеет.
                                                                                                0

                                                                                                Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются… Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно. Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.

                                                                                                  0
                                                                                                  Уже сотни раз писали, что обсуждать на собеседовании что-то вне контекста практической области деятельности, под которую вы ищете сотрудника, — это скорее вредно, чем полезно.
                                                                                                  И уже сто раз же отвечали, что для многих компаний искать сотрудника под конкретную практическую область — бессмысленно. Ибо проекты расширяются и сокращаются часто и работать в течении 10 лет в одной предметной области не получится.

                                                                                                  Ну а если в некой компании сеньоры преимущественно занимаются тем, что группируют массивы не важно с какой эффективностью, лишь бы работало, то вопросов нет.
                                                                                                  «Лишь бы работало» — это первый шаг, как я понял. Чтобы вот того самого «мееенеджера, который в программирование вообще не умеет» не нанять. А дальше — да, набросав за 10-15 минут какое-нибудь решение сеньор должен уметь о нём ещё и поговорить (чем и будет отличаться от джуна).
                                                                                                    0
                                                                                                    Ну, поэтому я и уточнил, какими задачами сеньоры в этой компании занимаются…
                                                                                                    Ну давайте. Возьмём конкретный пример:
                                                                                                    1. Год — работа надо локализацией UI катологизатора (что-то типа всем известного DMOZа)
                                                                                                    2. Пара лет — работа с Big Data (терабайтные базы и выискивание полезной информации в них)
                                                                                                    3. Потом — плагины для браузера и разработка sandbox'а, который должен был обеспечивать безопасность модулям, которые грузились в этот плагин.
                                                                                                    4. Ну и вишенка на тортике — JIT-комплятор для специфического байткода (текущий проект).

                                                                                                    Просто потому что там менялись задачи в том офисе, где он работал.

                                                                                                    Какие конкретно вопросы вы задали бы такому человеку с учётом того, что каждый из проектов он начинал с нуля в одиночку (фаза технико-экономическое обоснования) и получал своих джунов и стажёров уже после демонстрации прототипа?

                                                                                                    У меня есть ощущение, что вы вообще путаете сеньоров и менеджеров. Почему-то частая проблема в России вообще — где люди гордяться тем, что не умеют писать код.

                                                                                                    Просишь написать какую-нибудь вот такую простейшую задачку — а в ответ получаешь заявление, что он же сеньор, он кода уже три года не писал… какой же он, нафиг, сеньор тогда? В лучшем случае — Product Manager… тоже полезная и нужная профессия, но… она немного о другом! И критерии там — другие!
                                                                                                      0
                                                                                                      искать сотрудника под конкретную практическую область — бессмысленно

                                                                                                      Причём тут предметная область? Сравните 2 вопроса:
                                                                                                      1) напишите алгоритм группировки списка слов по таким-то условиям.
                                                                                                      2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
                                                                                                      Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий. На первый вопрос адекватный сеньор (если уж ему такой вопрос всё-таки задали) сначала спросит "для чего?". Знаете в каком коде не бывает багов?


                                                                                                      А дальше — да, набросав за 10-15 минут какое-нибудь решение сеньор должен уметь о нём ещё и поговорить (чем и будет отличаться от джуна).

                                                                                                      Бред. Если человек сразу кидается писать код — это не сеньор. Сеньор из вас сначала всю душу вытрясет, проясняя требования и зачем это вообще вам. Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.


                                                                                                      Какие конкретно вопросы вы задали бы такому человеку с учётом того, что каждый из проектов он начинал с нуля в одиночку

                                                                                                      Это уже фриланс какой-то, а не командная работа…
                                                                                                      Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?


                                                                                                      У меня есть ощущение, что вы вообще путаете сеньоров и менеджеров.

                                                                                                      Только вот путаете Вы… Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде. Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер. Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.

                                                                                                        0
                                                                                                        Потому что 80-90% работы сеньоров состоит в том, чтобы думать, а не код в редакторе набирать.
                                                                                                        Верно — но если мне сложнее такому сеньору объяснить задачу, чем решить её самому — то нафиг он, такой красивый, нужен?

                                                                                                        Это уже фриланс какой-то, а не командная работа…
                                                                                                        Почему фриланс? Обычная ситуация для крупных компаний типа Фейсбука или Майкрософта.

                                                                                                        Так что я бы спросил о том, как строилась работа после стадии прототипа, если такое вообще было. Какова была его роль в команде? Как строилась работа по проекту в целом? Как происходила декомпозиция и оценка задач? Как был построен каждый проект с точки зрения архитектуры?
                                                                                                        И нафига всё это если он стадию прототипа завалит?

                                                                                                        Сеньор — это одна из ведущих ролей, а в случае с вышеописанной микро-компанией вообще единственная ведущая роль в команде.
                                                                                                        Просто для справки: в вышеупомянутой компании на сегодня числится более пятидесяти тысяч сотрудников (не считая контракторов). Если это для вас «микро» — то что для вас будет «макро»?

                                                                                                        Сеньор — это не тот, кто пишет код от забора и до обеда так, как сказал менеджер.
                                                                                                        Верно. Это тот, кто пишет код так, как он его видит — а потом, если убедит менеджеров, получает штат на то, чтобы превратить имеющийся прототип в что-то работающее.

                                                                                                        А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.
                                                                                                        Да, конечно. Но это всё — потом. Когда вы убедите менеджеров в том, что ваша идея, собственно, вообще имеет смысл и что её реализация сможет кому-то улучшить жизнь.

                                                                                                        Ну и как ваш сеньор должен пройти начальный этап, если он программировать разучился?
                                                                                                          0
                                                                                                          Почему фриланс?

                                                                                                          Потому что в одиночку. Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.


                                                                                                          а потом, если убедит менеджеров, получает штат на то, чтобы превратить имеющийся прототип в что-то работающее.

                                                                                                          Другими словами, речь идёт об изначально никому ненужных проектах? Ну ok. Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали. Может Facebook и может себе позволить нанять людей просто про запас и дать им хобби-проектами под крылом компании заниматься. Но это просто индикатор, что до основных проектов вас пока не готовы допустить, даже в роли мидла.


                                                                                                          Ну и как ваш сеньор должен пройти начальный этап, если он программировать разучился?

                                                                                                          С чего Вы это взяли? Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.

                                                                                                            0
                                                                                                            Для разработки прототипа можно выделить 2-3 человек и это будет гораздо эффективнее, если этот прототип для кому-то нужной задачи вообще делается, а не от нечего делать.
                                                                                                            Нет, это не будет эффективнее. Команда из 2-3 человек — это вообще страшно неэффективное расходование ресурсов. Просто потому что когда у вас появляется команда — тут же появляются затраты на взаимодествие, нужно создавать внутренние документы какие-то описания, согласования и прочее. Потому скорость команды в два человека хорошо если превышает скорость работы одного, а три человека — дадут весьма небольшой выигрыш.

                                                                                                            Вот когда вы уже решили выделить на проект ресурсы — тогда можно уже создавать минимально осмыслленную команду в 5-7 человек (или в 50-70 человек — всё зависит от задачи, конечно), которая реально может дать прирост. Эффективность упадёт ещё больше, конечно, но тут уж ничего не поделать — один человек многие вещи будет доводить до релиза десятилетия, когда они уже окажутся никому не нужными.

                                                                                                            Другими словами, речь идёт об изначально никому ненужных проектах?
                                                                                                            С чего вы решили, что они «никому не нужны»? Часть выкидывается, часть превращается во что-то большое.

                                                                                                            Нормальная ситуация, когда ваша конпания не sweatshop, выполняющий задачи «для дяди» под заранее согласованное ТЗ в какой-то освоенной области, а разрабатывает новые вещи — и заранее не знает будет ли от реализации той или иной идеи польза.

                                                                                                            Большинство компаний заказной разработкой занимаются, а не тем, что Вы описали.
                                                                                                            Пресловутые пять миров? Да, очень на то похоже. Но суть тут в том, что «большинство компаний» быть может и занимается заказной разработкой — но я, конкретно, ни разу в подобных компаниях не работал и не собираюсь. Потому я сужу с точки зрение другого мира — где зарание никаких ТЗ нету, его нужно придумать — ну а после запуска оценить: взлетело или нет. Если за пару лет пользователей не больше 5-10 миллионов — значит «не взлетело», проект пора закрывать.

                                                                                                            И вот тут сеньор, умеющий только управлять джунами — нафиг никому не нужен, потому что он тупо экономически неэффективен.

                                                                                                            Уметь программировать и кидаться программировать не разобравшись в задаче — это не одно и то же.
                                                                                                            А как вы разберётесь в задаче не набросав прототип и не повертев его по-всякому? Картинки на бумажке (или на доске) могут вылядеть очень красиво, но часто попытка хотя бы примерно прикинуть в коде — всё ставит «с ног на голову».
                                                                                                              0
                                                                                                              нужно создавать внутренние документы какие-то описания, согласования и прочее

                                                                                                              Это уже от степени бюрократии зависит, а не от кол-ва людей.


                                                                                                              С чего вы решили, что они «никому не нужны»? Часть выкидывается, часть превращается во что-то большое.

                                                                                                              С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку. Если бы там была ситуация в формате "есть такая-то проблема, давайте запустим R&D и несколько человек предоставят прототипы разного варианта решения" — это бы я понял. А с ваших слов получается, что-то в формате: "сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы".


                                                                                                              Пресловутые пять миров?

                                                                                                              Возможно. Хотя классификация уже давно устарела. Но безусловно у разных компаний разная специфика.


                                                                                                              разрабатывает новые вещи

                                                                                                              Новые вещи разрабатываются крайне редко. Везде сплошная адаптация уже известных концептов под нужды бизнеса или пользователей. Ваши 4 проекта тут ни разу не исключение. Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина. Никаких концептуально новых вещей Вы не делаете. Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
                                                                                                              У нас тоже ТЗ нет никаких, но есть те самые нужды бизнеса, которые обсуждаются и под них разрабатывается решение. Причём это не в статике, нужды бизнеса меняются и решение должно легко адаптироваться.


                                                                                                              И вот тут сеньор, умеющий только управлять джунами

                                                                                                              С чего Вы взяли, что он только это умеет? Вот тут как раз в тему статья вышла. Способности программиста — это одна из 4 характеристик сеньора, само собой она важна и обязательна. Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут. Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.


                                                                                                              часто попытка хотя бы примерно прикинуть в коде — всё ставит «с ног на голову».

                                                                                                              Может просто стоило картинки чуть дольше покрутить? Реализация может вносить коррективы, но ситуация «с ног на голову» — это фейл этапа проектирования.

                                                                                                                0
                                                                                                                нужно создавать внутренние документы какие-то описания, согласования и прочее

                                                                                                                Это уже от степени бюрократии зависит, а не от кол-ва людей.
                                                                                                                Если вы делаете прототип, не имея жёсткой постановки задачи? Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?

                                                                                                                Знаете сколько человек делали, скажем, прототип Colossus'а? Двое. Но не потому что сеньор 10го или 14го или какого уж там уровня получил джуна «в подмастерья». А потому что Jeff и Sanjay работали вдвоём годами и понимают друг друга буквально с полуслова.

                                                                                                                А это, на минуточку, разработка с нуля компонента, над которым вся серверная экосистема Гугла построена. Казалось бы — куда уж важнее. Но нет — никаких джунов и «архитекторов». Потому что они только мешают на этом этапе.

                                                                                                                С того, что Вы не описали проблематику, а указали конкретные проекты, которые при этом делали в одиночку.
                                                                                                                Во-первых — с чего вы решили, что речь шла обо мне. Во-вторых — с чего вы решили, что эти проекты писались в одиночку? Прототип делается в одиночку (редко — два-три человека, очень долго работавших вместе), а уж потом в проекте может быть и под 100 человек.

                                                                                                                А с ваших слов получается, что-то в формате: «сидел я как-то без дела, ну и говорят мне: займись уж хоть чем-нибудь… если что-нибудь путное придумаешь, то может мы потом займёмся развитием этой темы».
                                                                                                                Ну не так всё жестоко. Когда какой-нибудь Inbox закрывается, то у вас, обычно, есть год или даже чуть больше, чтобы придумать что-то или найти другой проект, куда вас примут. Внутри-то информация про закрытие раньше появляется, чем снаружи.

                                                                                                                Ни идея песочницы, ни идея JIT-компилятора не принадлежат лично Вам, остальное так вообще банальщина.
                                                                                                                Так мы дойдём до того, что в компюьютерах вообще всё — сплошная банальщина, нолики и единички, что может быть проще.

                                                                                                                Единственное что непонятно из ваших сообщений — от кого исходит идея что-то начать писать.
                                                                                                                С разных сторон. Что-то вы можете вообще в коридоре услышать. Но в общем и целом… это ваша задача как сеньора — обосновать ценность и полезность той или иной разработки.

                                                                                                                С чего Вы взяли, что он только это умеет?
                                                                                                                Ну раз вы на собеседовании только это и спрашиваете — то, скорее всего, наберёте людей, которые только это и умеют…

                                                                                                                Но тут надо учитывать, что не весь код одинаково сложный, поэтому важно чтобы сеньор не тратил время зря на простые вещи, а занимался в первую очередь тем, что остальные члены команды реализуют в 5-10 раз медленнее, если вообще смогут.
                                                                                                                Это всё прекрасно, но, извините, я не видел людей, которые могли бы реализовать что-то сложное, а вот простую задачу — ну никак. И есть у меня подозрение, что такие в природе не встречаются.

                                                                                                                Увидите — покажите. До тех пор предположение о том, что человек, предлагающий в ответ на простейшую задачу на собеседовании «делегировать это джунам» сеньором, по большому счёту, не является и, соотвественно, нам не подходит — является достаточно разумным.

                                                                                                                Вы же считаете, что кроме написания кода от сеньора вообще ничего не требуется, но тогда это по сути мидл.
                                                                                                                С чего вы решили? Я всё отдельно озвучил даже. Проверка умения решать простейшие задачи — это первая стадия при найме сеньора. Ибо крайне большой количество людей, искренне считающих себя сеньорами, настолько долго «делегировали задачи», что не «реализуют в 5-10 раз быстрее то, что другие не могут», а, наоборот, «не могут вообще ничего реализовать, так как код не писали годами».

                                                                                                                Вот их — и нужно максимально быстро отсеять. Потому что они вообще не программисты уже. А уже потом уже разбираться — тянет человек на уровень сеньора или нет.
                                                                                                                  0
                                                                                                                  Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?

                                                                                                                  А кроме регламентных документов и телепатии Вы других способов общения не знаете?


                                                                                                                  Ну раз вы на собеседовании только это и спрашиваете — то, скорее всего, наберёте людей, которые только это и умеют…

                                                                                                                  Да бросьте, я спокойно доверяю людям в этом отношении. И не сомневаюсь, что отработав многие годы программистами они могут набрать код. Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.

                                                                                                                    0
                                                                                                                    Как все ваши джуниоры и миддлы должны будут догадаться что вам делать? Путём телепатического заглядывания к вам в мозг?
                                                                                                                    А кроме регламентных документов и телепатии Вы других способов общения не знаете?
                                                                                                                    Знаю — но все они выбивают человека «из колеи». Разные замеры показывали разное время, но в среднем — если ответ на вопрос занимает 1 минуту, то потери производительности, у человека, пишущего код — 15-30 минут.

                                                                                                                    Потому попытка обойтись без документации в проекте, где новые идеи всё ещё появляются раз в 2-3 дня — приводит, опять-таки, только к замедлению.

                                                                                                                    Да бросьте, я спокойно доверяю людям в этом отношении.
                                                                                                                    А сколько людей вы на работу опросили и наняли, позвольте спросить?

                                                                                                                    И не сомневаюсь, что отработав многие годы программистами они могут набрать код.
                                                                                                                    А вот я — сомневаюсь. И не напрасно. Потому что бо́льшая часть «сеньоров» код писать не умеет. Небольшая часть — просто об этом заявляет после попытки что-нибудь написать (часть с грустью, час — даже с гордостью какой-то… ага, придти на вакансию, где это — необходимое требование и мурыжить людям мозги… это же так почётно), большая часть делает вид, что вообще — они ого-го… просто сейчас не в духе.

                                                                                                                    Меня больше интересует, чтобы сеньор вёл себя согласно своей роли, а не как мега-опытный джуниор.
                                                                                                                    Ok. Вы проверили что сеньор может общаться с джунами, строить разного рода космические архитектурные замки на листе бумаги… написать три строчки кода — не может (это вы не проверили, но вероятность — больше 50%). Взяли его такого на работу. Что дальше?
                                                                                                                      0
                                                                                                                      если ответ на вопрос занимает 1 минуту, то потери производительности, у человека, пишущего код — 15-30 минут.

                                                                                                                      Это всё так, но вас послушать так программисты только и делают, что код пишут. Обсуждать идеи прежде, чем переводить их в код — очень даже полезно. И уж хватает методологий как это делать, чтобы не вызывать проблему постоянных отвлечений.


                                                                                                                      А сколько людей вы на работу опросили и наняли, позвольте спросить?

                                                                                                                      Не так много, нанимал около десятка, опрашивал соответственно в разы больше.


                                                                                                                      Потому что бо́льшая часть «сеньоров» код писать не умеет.

                                                                                                                      Тут если только вам поверить, я ни одного такого сеньора вживую не видел. Я допускаю, что есть куча сеньоров, которые не напишут на бумажке QuickSort, потому что в прошлый раз они этим интересовались 10-15 лет назад, или вообще на бумажке ничего не напишут, т.к. давным давно переложили автодополнение на IDE. Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.

                                                                                                                        0
                                                                                                                        Тут если только вам поверить, я ни одного такого сеньора вживую не видел.
                                                                                                                        Только это не только моё мнение. Я уж не знаю как вам удавалось отсеять людей, которые когда-то были программистами не задавая их вопросов по программированию — но почему-то всем другим, кто реально занимался наймом, люди способные что-то написать встречаются куда реже, чем хочется.

                                                                                                                        На собеседованиях, конечно, в реальной-то работе их не так много… именно потому что их много на собеседованиях!

                                                                                                                        Но вот чтобы они не могли код написать в обычных условиях на своём компе, такого я не встречал.
                                                                                                                        То есть печально известный подход если достаточно долго месить чан с перловой кашей, в синтаксическом мусоре можно рано или поздно узреть лик Ларри Уолла вас устраивает? Меня — нет. Особенно если речь идёт от синьоре.

                                                                                                                        Ибо шансы на то, что джун просто «ещё не умеет прогрммировать, но со временем научится» — довольны высоки. А у «сеньора» это, почти наверняка, стадия «уже разучился программировать и, соответственно, учиться не будет».
                                                                                                                          0

                                                                                                                          Да дебилизм полнейший все эти задания написать какой-то код на бумажке или в GoogleDocs. По факту вы просто отсеиваете людей, которые не умеют писать код на бумажке. Мне такой навык от сотрудников нафиг не нужен.
                                                                                                                          Ну а разучиться программировать — это из серии разучиться на велосипеде кататься.

                                                                                                                            0
                                                                                                                            Ну а разучиться программировать — это из серии разучиться на велосипеде кататься.
                                                                                                                            Если бы это было так, то не появлялись бы «архитекторы», умеющией только в Power Point… а я с такими сталкивался…
                                                                                                                              0

                                                                                                                              Где интересно такие кадры водятся? В Индии что-ли?

                                                                                                                                0
                                                                                                                                Я с ними в разных странах сталкивался. И в России (в Москве, да), и в «намазанной мёдом Калифорнии» и, безусловно, в Индии.
                                                                                                                                0
                                                                                                                                Ну, учитывая, что PowerPoint тьюринг-полный
                                                                                                            0
                                                                                                            Сравните 2 вопроса:
                                                                                                            1) напишите алгоритм группировки списка слов по таким-то условиям.
                                                                                                            2) как бы вы начали проектировать систему, помогающую разгадывать кроссворды, подбирая слова по известным буквам?
                                                                                                            Оба вопроса из одной предметной области, но при этом совершенно для разных вакансий.
                                                                                                            Я бы сказал, что они для одной вакансии, но для разных стадий интервью. Если человек не может решить первую — то это вообще не программист и дальнейшие разговоры бессмысленны. А вот если он первую уже умеет решать и мы про это знаем — тогда можно поговорить и о том, можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).
                                                                                                              0
                                                                                                              > Я бы сказал, что они для одной вакансии, но для разных стадий интервью. Если человек не может решить первую — то это вообще не программист и дальнейшие разговоры бессмысленны. А вот если он первую уже умеет решать и мы про это знаем — тогда можно поговорить и о том, можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).

                                                                                                              Самый правильный ответ во всей ветке. Спасибо.
                                                                                                                0
                                                                                                                можно ли или нельзя ли её применить к решению кроссвордов (ответ, кстати — нельзя, это скорее чуть-чуть похоже на игру в «слова», но при всей внешней похожести реально это — совсем разные задачи).

                                                                                                                И Вас даже не смутило, что в формулировке не указаны конкретные условия? А если Вы имели в виду формулировку от kruslan, то там никакой схожестью с кроссвордами вообще не пахнет. Рано Вам в сеньоры...

                                                                                                                  0
                                                                                                                  Source, а вас не смутило, что я тут никого не собеседую и дал вольное описание от своего имени? Вы сделали выводы о разработчиках, без информации. При этом настаиваете, что хороший «сеньор» докопается до самых глубин, прежде, чем решать задачу? Странно.
                                                                                                                    0

                                                                                                                    Да тут уже давно не Ваш кейс обсуждают, а в целом подход, какими вопросами какой уровень можно проверить.

                                                                                                                      0
                                                                                                                      Да тут уже давно не Ваш кейс обсуждают, а в целом подход, какими вопросами какой уровень можно проверить.


                                                                                                                      Мне показалось, что как-раз мой кейс и обсуждается: сначала проверяем умение думать, потом программировать, потом оптимизировать и управлять. Ошибся?)
                                                                                                                0
                                                                                                                Он обязан занимать проактивную позицию и докапываться до сути того, что надо сделать, в том числе предлагая решения, о которых менеджеры с заказчиком никогда бы не додумались. А также участвовать в разработке архитектурных решений, распределять задачи между другими программистами, способствовать их росту, следить за соблюдением сроков и т.д.


                                                                                                                Ну вот я понял вашу позицию. Такие «сеньоры» действительно не нужны в нашей компании. Да и «сеньорами», если честно, я их назвать не могу.
                                                                                                                  0

                                                                                                                  Правильно, судя по всему, вам и не нужны сеньоры в компанию, вам нужны линейные исполнители — нормальные джуниоры и начинающие мидлы. Для некоторых проектов этого вполне достаточно.

                                                                                                                    0
                                                                                                                    Нет, нам нужны сеньоры, а не архитекторы/продакты/etc. Если сеньор, вместо качественно решения, занимается перекладыванием задач на других сотрудников, контролем сроков других задач, архитектурной разработкой и пр. — это бездельник, а не сеньор. Каждый должен выполнять свою работу, а не лезть в чужую.
                                                                                                                      0

                                                                                                                      Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.


                                                                                                                      Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче? Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения? На кого должны равняться мидлы и джуниоры? Кто code review должен делать?
                                                                                                                      В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.

                                                                                                                        0
                                                                                                                        Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.
                                                                                                                        А кто вам сказал, что у вас есть заказчик? Нет его. Вон пользователи бегают. Миллиарды. И чего хотят — они сами не знают. И не узнают — пока вы не придумаете чего бы такого сделать и как бы это реализовать.

                                                                                                                        Да пусть даже упростим задачу — пусть вы пишите не что-то для пользователей, а какую-то промежуточную библиотеку для других разработчиков… у вас ведь тоже нет одного заказчика — вам нужно придумать что-то, что потом окажется для какой-нибудь команды полезным (лучше, конечно — для нескольких команд).

                                                                                                                        В большой команде разработки эти обязанности размажутся между тим-лидом и несколькими сеньорами. В небольшой — это всё задачи сеньора.
                                                                                                                        Это всё верно. Но это всё — потом. Когда вы убедили кого-то, что то, что вы задумали вообще имеет смысл делать!

                                                                                                                        В том-то и дело, что наличие всемогущего «заказчика» кардинально меняет всю картину! Из неё полностью выпадает «нулевой этап»: слепить что-то из гавна и палок так, чтобы на это можно было посмотреть и принять решение — нужно это вообще развивать или нет!

                                                                                                                        А если у вас нет заказчика — то это, собственно, самый важный этап.
                                                                                                                          0
                                                                                                                          А кто вам сказал, что у вас есть заказчик? Нет его. Вон пользователи бегают. Миллиарды. И чего хотят — они сами не знают. И не узнают — пока вы не придумаете чего бы такого сделать и как бы это реализовать.

                                                                                                                          В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель "напрасный труд". Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям. По описанию фигня какая-то выходит… Я честно скажу, что не понимаю чем вы там вообще занимаетесь и зачем, с моей перспективы это выглядит как работа ради работы. Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?

                                                                                                                            0
                                                                                                                            В таком случае пользователи — это и есть заказчик и кто-то должен провести исследования, проанализировать их потребности и т.д., иначе это какая-то артель «напрасный труд».
                                                                                                                            Помните гениальную фразу Генри Форда если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь? Вот и в программировании — та же история. Люди не знают, на самом деле, что им нужно.

                                                                                                                            Да, конечно, исследования. Да, разумеется, анализ. Но дальше — любом случае нужно делать что-то новое, чего никто явно не просит, но что на самом деле всем и нужно. Иначе вы попадёте в ситуация Nokia, которая годами проводила исследования на тему «а что нужно пользователям смартфонов», а потом пришли новички, предложили то, о чём ни один опрос им не сказал (возможность тыкать в экран пальцами, а не палочкой) — и вынесли лидера рынка (без кавычек, заметим!) «вперёд ногами».

                                                                                                                            Сеньор чаще всего даже в ЦА не входит, но у вас получается именно он берёт с потолка гипотезу, что нужно пользователям.
                                                                                                                            Таки да. И они часто срутся на эту тему с UX-исследователями и продакт менеджерами, которые объясняют сеньору, что их предложения кажутся ему дикими, но «надо попробовать».

                                                                                                                            Возможно, Вы просто пропустили описание самого начала: откуда вообще приходят идеи делать прототип для чего-то конкретного?
                                                                                                                            Откуда угодно. Что-то «спускают сверху» (что, кстати, вовсе не гарантия того, что это что-то имеет смысл и это нужно делать — и, кстати, самое важное отличие сеньора от джуна в том, что он умеет обосновать варианты, когда начальство хочет, а делать это не нужно), что-то придумывает сеньор, что-то придумывают UX'ы и продакт менеджеры, что-то вообще откуда-нибудь из какого-нибудь фанфика или аниме выдёргивается.

                                                                                                                            Вопрос «кто придумал» — не так важен, как раз. Важна проверка и принятие или выбрасывание идеи.
                                                                                                                              0

                                                                                                                              Всё, о чём Вы говорите, затрагивает только R&D.
                                                                                                                              И в данном контексте речь идёт по сути не о сеньорах, а об исследователях. Т.е. с одной стороны — да, человек, имеющий квалификацию сеньора, может выступать в роли исследователя. Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый. Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.

                                                                                                                                0
                                                                                                                                Но с другой стороны, в рамках всей индустрии, кейс когда сеньор что-то пилит в одиночку, опираясь только на своё видение проекта, — не такой уж частый.
                                                                                                                                Я не нанимаю сотрудников «для всей индустрии».

                                                                                                                                Поэтому я не понимаю, почему Вы так упорно пытаетесь натянуть сову на свой глобус, при всей очевидности, что так устроена работа в очень малом кол-ве компаний, а ещё точнее только в 1 департаменте этих компаний.
                                                                                                                                Я не знаю в сколько компаниях работали вы — но во всех, где работал я подавляющее большинство сеньоров работали именно в этом режиме. Хотя это были разные компании — от стартапов в 5-10 человек до монстров в десятки тысяч.

                                                                                                                                И да, я знаю, что «в рамках всей индустрии» — это редкость. Но это не редкость у нас! И вы уж как-нибудь определитесь с вашей позицией: либо у вас «во всей индустрии» сеньоры пишут код (что как-то ну вот совсем не согласуется с тем, что мы видим на собеседовании), либо — наличие этого навыка нужно проверять на собеседовании.
                                                                                                                          0
                                                                                                                          Команда должна работать как команда, а не как испорченный телефон, когда продакт поговорил с заказчиком, архитектор поговорил с продактом, спустил архитектуру команде разработке и они начали фигачить, не вдаваясь в суть.


                                                                                                                          Команда должна участвовать в обсуждении задач и проблем, здесь я полностью согласен. Но, основное слово в «senior developer» именно «developer» и зона ответственности — качественный код.

                                                                                                                          Кто по вашему должен сообщить продакту заранее, что всплыли непредвиденные сложности в какой-то задаче?

                                                                                                                          Team Lead, Tech Lead, аналитики, QA и пр. Куча вариантов. Но среди них точно нет разработчиков.

                                                                                                                          Кто должен на этапе реализации не хуже архитектора понимать почему приняты определённые архитектурные решения?

                                                                                                                          CTO, Tech Lead, Team Lead.

                                                                                                                          На кого должны равняться мидлы и джуниоры?

                                                                                                                          Ни на кого. Серьезно.

                                                                                                                          Кто code review должен делать?

                                                                                                                          Team Lead, Tech Lead, ментор, отдельный человек/команда в конце-концов. У нас, кстати, такое практикуется.

                                                                                                                          В небольшой — это всё задачи сеньора.

                                                                                                                          Нет. Задача сеньора — качественный код. Если еще и быстро реализованный — вообще отлично. А если сеньор, вместо прямых обязанностей, занимается чем угодно другим — надо переводить его на другую должность/в другой отдел.
                                                                                                                            0

                                                                                                                            Tech Lead, Lead Developer, ведущий программист — это просто альтернативные названия для Senior Developer.
                                                                                                                            И это не только моё частное мнение… Почти никто не разделяет эти роли. Вот для примера: What Defines a “Senior Developer?”

                                                                                                                              0
                                                                                                                              С «Lead Developer, ведущий программист» согласен, с Tech Lead нет. Причина — tech lead больше архитектор, а не девелопер. Ну и в коментах по ссылке указали нестыковки.
                                                                                                                                0

                                                                                                                                Имхо, Вы переусложняете классификацию… Если tech lead больше архитектор, то чем он отличается от архитектора?
                                                                                                                                Вот тут немножко про ведущего программиста.
                                                                                                                                Я бы даже не стал строгой границы между тимлидом и сеньором проводить. Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации, который в силу роли просто несколько больше управленческой работы выполняет, чем обычный сеньор.

                                                                                                                                  0
                                                                                                                                  Если tech lead больше архитектор, то чем он отличается от архитектора?

                                                                                                                                  Тем, что архитектура у архитектора основная работа и код он почти не трогает и обратная ситуация у тех.лида — он больше по коду, но участвует в формировании архитектуры. Как-то так, если упрощенно.

                                                                                                                                  Да, не каждый сеньор может выполнять роль тимлида, в силу особенностей характера, но каждый тимлид — это сеньор по квалификации

                                                                                                                                  Так вот-же провели границу. Да, тим.лид — чаще всего сеньор (хотя я видел, когда тим.лидом был мидл). И работа тим.лида — уже не код, а управление и оптимизация работы разработчиков. А девелопера (и тем более, сеньор девелопера) — код и только код.
                                                                                                                                    0

                                                                                                                                    Конечно, у каждой роли есть своя основная зона ответственности. Но на практике все эти границы размываются… И архитектор и тимлид могут сделать что-то в коде, а сеньоры обсудить архитектуру.
                                                                                                                                    Если разделять прям строго, то всё закончится фигнёй типа "это не по моей части" и чехардой перекидывания ответственности друг на друга. Вот вы пишете "код и только код", т.е. такой сеньор в любой момент времени может сказать "я так сделал, потому что мне так сказали"… такой формализованный подход, без вникания в суть.

                                                                                                                                      0
                                                                                                                                      Если разделять прям строго, то всё закончится фигнёй типа «это не по моей части»


                                                                                                                                      Лучше так — это хоть поправить можно. А вот если «сеньор» начинает делать работу продакта/тим.лида/бухгалтера и уборщицы — беда. Мало того, что он свою работу не делает, так еще, скорее всего, тормозит чужую.

                                                                                                                                      Поверьте, я видел такое в живую и даже врагу такого не пожелаю. Из последнего (с месяц назад): один из «сеньоров», "что-бы разобраться", решил выяснить как работают менеджеры и бухгалтерия у наших клиентов. Итог: таск на 2-3 часа он делал 2 недели, да и то только потому, что уже CTO велел перестать заниматься херней.
                                                                                        0
                                                                                        Если работодатель хочет увлечённого и инииативного, то есть вероятность что будут переработки, да и платить будут не очень (это счастье увлечённо работать в нашей компании).
                                                                                          –1
                                                                                          Интересно, почему в других профессиях как-то не особо распространено полагаться на любительство? В конце концов, есть рабочее время, в течение которого делается работа (как сказали и что сказали). Качественно и в срок. И все. И поверьте, в большинстве мест, даже с неплохим окладом, инициатива сверх оговоренного руководством — это хуже, чем ее отсутсвие на генетическом уровне.
                                                                                            0
                                                                                            Если у программиста нет своих программ, это значит, что он не увлечен всерьез программированием
                                                                                            Золотые слова!
                                                                                          +1
                                                                                          Стряхнуть пыль с моего графического интерфейса для DOS :)
                                                                                          Написан на TP7. Не прошел по скорости. Критические секции переписаны на ассемблере. Скорость выросла в 15 раз. Самое смешное, что через 25 лет я смогу его прокоментировать. Потому, что очень хотелось понять, что же в компиляторе TP7 настолько не оптимизировано.
                                                                                        +4

                                                                                        kolkoni, у меня два вопроса:


                                                                                        • А кого вы нанимаете?
                                                                                        • Почему, с Вашей точки зрения, задаются странные вопросы на собеседовании?

                                                                                        =====


                                                                                        Как Вы и сами замечали, есть разные типы людей. Я приведу только несколько очень сокращенных примеров:


                                                                                        • Фанат vs линейный программист. Первый будет за open source в свободное время, он будет готов перерабатывать, будет знать новейшие технологии и т.д. Однако второй сможет аккуратно поддерживать legacy проект без мысли его переписать (это особенно важно, если проект будет остановлен через год, так что надо всего лишь продержаться). С другой стороны, если будет задача "сделать быстрее выше сильнее", то фанат с радостью возьмется за задачу, сделает быстрее и лучше отстраненного "линейного программиста". Еще типы можно посмотреть тут, хабре.
                                                                                        • Тактик vs стратег. Первый может быстро и решительно исправить баг в момент релиза, он не впадет в ступор (в том числе и в случае автоаварии, это же личность такая). Однако он будет смотреть на проект как на два спринта, не будет хотеть делать тесты, улучшать environment (это стереотипно, однако идея понятна). Стратег напротив может впасть в ступор при фиксе строчной и критической ошибки, однако он уже рассматривает проект как будто он на кучу лет. Потому тут будут и тесты, и улучшение environment и своевременное обновление зависимостей.

                                                                                        Это стереотипные примеры, в реальной жизни крайних случаев мало. Однако даже на них вы сходу сможете представить, какие задачи давать этим разным людям.


                                                                                        =====


                                                                                        По поводу второго вопроса — если принять за аксиому, что HR не дегенерат, а напротив — опытный сотрудник, который получает бонусы на хороший найм, то почему же он задает идиотские вопросы? Вот несколько ответов (оба мне рассказал HR по опыту работы в США, я не поддерживаю их, однако по ним можно объяснить, почему люди задают "тупые вопросы")


                                                                                        • Экзамен на устойчивость к стрессам. Да, может быть в компании работается спокойно, однако кто захочет нанимать человека, который размякнет при первом же нажиме?
                                                                                        • Проверка на то, что человек действительно хочет здесь работать (сюда можно отнести кучу тупых задач на логику). В крупной компании сложно уволить (по моему опыту), а потому лучше сразу нанять тех, кто действительно хочет здесь работать. А сеньоры с задранными носами пусть идут к конкуренту, правильно ведь?
                                                                                        • Проверка soft skills. Не каждая компания хочет раздувать штат разными сотрудниками. Зачастую есть желание взять не просто кодера по спецификации, а специалиста, которые сможет говорить с бизнесом. Мало кто хочет в будущем получать ответы в стиле "у меня синус равен пяти, потому что в спеке так написано. И вообще, я программист, а не математик".

                                                                                        Важно: в разных компаниях разные требования. Я не говорю, что вопросы выше правильные. Однако зачастую и в них может быть смысл.


                                                                                        Далее вопрос: как вы считаете, насколько хорошо сможет наладить диалог человек, который на вопрос про полюс и медведей начинает отвечать "любой медведь, какого поставили, такой и будет"? Не будет ли он и заказчикам отвечать в стиле "что значит, чему у нас равна пи? Что введете, то и будет, хоть 10". И другой вопрос: он точно хочет здесь работать? Или просто пришел пощекотать эго?


                                                                                        =====


                                                                                        И еще раз повторю мои вопросы к статье:


                                                                                        • А кого вы нанимаете?
                                                                                        • Почему, с Вашей точки зрения, задаются странные вопросы на собеседовании?
                                                                                          0
                                                                                          А кого вы нанимаете?

                                                                                          Я сам нанимал исключительно линейных программистов, если брать типажи из ссылки.

                                                                                          По типу мышления предпочитаю стратегов. Потому как ошибки лучше вообще не допускать, нежели быстро на них реагировать, плюс умение продумывать и предвидеть очень экономит время в будущем.

                                                                                          Но т.к. выбор не так велик, как хотелось бы, брал людей, которые могут писать адекватный код, могут находить решения и могут делать то что от них требуют. А гигиена кода, принципы построения приложения, тестирование, безопасность и т.п. придет со временем при правильном руководстве.

                                                                                          Почему, с Вашей точки зрения, задаются странные вопросы на собеседовании?

                                                                                          К сожалению ситуация когда HR не дегенерат далеко не аксиома и очень часто тупые вопросы задаются именно поэтому.

                                                                                          Если же брать ситуацию с адекватным HR-ом, то тупые вопросы, на мой взгляд, рождаются из-за 2 основных причин.
                                                                                          1. В крупных компаниях из за бюрократии. Потому что на совещании где участвовало 100500 человек (половина из которых вообще не относятся к программированию) они решили что нужно спрашивать это, то и вот это.
                                                                                          2. И бывает такие вопросы появляются из-за нежелания конкретных сотрудников брать кого то на работу. Например тех.дир. хочет взять своего племянника на должность и начинает у всех приходящих спрашивать какую нибудь муть, а потом такой — а вот у меня есть племянник, он в 100 раз лучше всех этих обормотов.

                                                                                          Важно: в разных компаниях разные требования. Я не говорю, что вопросы выше правильные. Однако зачастую и в них может быть смысл.

                                                                                          Если в них есть смысл, то тогда почему бы hr-ам не озвучивать его? Просто когда меня тупыми вопросами заваливали, никто не объяснял зачем они задаются. И даже если спрашиваешь "зачем Вам это" они не могли нормально ответить, просто потому что сами не знают.

                                                                                          Не будет ли он и заказчикам отвечать в стиле «что значит, чему у нас равна пи? Что введете, то и будет, хоть 10»

                                                                                          Я считаю что между разработчиком и заказчиком обязательно должно быть промежуточное звено, а лучше 2 — те кто понимает заказчика и те кто понимает разработчика (типа product owner и scrum master).

                                                                                          Он точно хочет здесь работать? Или просто пришел пощекотать эго?

                                                                                          Тут уже вопрос о мотивации этого человека и эту самую мотивацию надо знать…
                                                                                            0
                                                                                            HR не дегенерат далеко не аксиома

                                                                                            Т.е. человек делает свою работу достаточно хорошо, чтобы начальники отделов не жаловались (я не могу ответить за все компании, однако там где я работаю, feedback дойдет крайне быстро), однако при этом он плохой HR, верно? По мне так это нетипичная ситуация. Более того: решение о найме-то (опять говорю о своей среде обитания) принимает команда (вместе с начальником отдела), так что HR'у даже отсеять будет непросто, если уже было техническое интервью.


                                                                                            на совещании <..> 100500 человек <...> решили что нужно спрашивать <...>

                                                                                            Опять-таки, по моему опыту это не так. HR задает одни вопросы (и описывает своё видение). Технари задают свои вопросы (и описывают видение). Потом решение принимает начальник отдела, как я говорил. И вопросы придумываются небольшой группой энтузиастов (просто потому что они нашли время). А далее каждый в команде может предложить свой вопрос (или выкинуть неправильный). А сам список является публичным и исключительно рекомендательным, к тому же он разный для разных отделов. Вот такой вот опыт большой компании, вот такая бюрократия.


                                                                                            тех.дир. хочет взять своего племянника на должность

                                                                                            Вы хоть раз встречали такое в IT? Я вот лишь слышал о подобном. Сейчас же в нашей сфере дикий запад и конкуренция, к тому же в IT работать придется.


                                                                                            Далее: если мы говорим про большую западную компанию, то там существует конфликт интересов (едва ли не на законодательном уровне). Так что техдиру просто не получится взять племянника в свой отдел. Подобное практикуется только в мелком семейном бизнесе, но уж ни как не в крупном. Однако, как я сказал, это реалии западной крупной компании.


                                                                                            между разработчиком и заказчиком обязательно должно быть промежуточное звено, а лучше 2

                                                                                            Он, тут будет только моё мнение. Однако я вот считаю, что хоть кто-то из команды обязан вникать в предметную область. А лучше, чтобы все вникали. Дело в том, что тогда программы делаются действительно для заказчика, а не для спецификации. Разработчик, который изучил материалы по экономике, быстро поймет, что с программой что-то не так, если волатильность доллара стала больше волатильности рубля. И к тому же это никак ему не помешает и знать про Spring, и понимать про виртуальные функции, и осознавать, чем отличается virtual метода от не-virtual.


                                                                                            Просто для сравнения: а сколько должно быть людей-посредников между таксистом и пассажиром?

                                                                                              0
                                                                                              однако при этом он плохой HR, верно

                                                                                              Не совсем понял как Вы пришли к такому умозаключению.
                                                                                              Я просто констатировал свой опыт общения с 50+ hr-ами разных компаний на разные позиции.

                                                                                              Проблемы такие:
                                                                                              • задают вопросы, которые нашли в интернете или которым их обучили на курсе, но при этом не понимают зачем они их задают, просто потому что «так надо».
                                                                                              • задают технические вопросы, в которых не разбираются, только потому что техспец не захотел на это тратить время и передал список вопрос-ответ hr-у. Как быть? Можно просто не идти на поводу, можно игнорировать и не спрашивать, можно сказать что на всё ответили. В общем при желании поступить правильно можно.
                                                                                              • задают вопросы исходя из своих, зачастую ошибочных, представлений о специалисте

                                                                                              HR'у даже отсеять будет непросто, если уже было техническое интервью

                                                                                              Как мне кажется, hr должен искать кандидатов и среди них отсеивать неадекватных или неподходящих по опыту (не в техническом плане, а в профессиональном).

                                                                                              Вот такой вот опыт большой компании, вот такая бюрократия.

                                                                                              У нас согласованный список обязательных вопросов приходил из головного отделения в Москве.

                                                                                              А у Вас в компании задают на собеседованиях тупые вопросы?

                                                                                              HR задает одни вопросы

                                                                                              Вот к этим вопросам относилось это: 100500 человек <...> решили что нужно спрашивать.

                                                                                              Технари задают свои вопросы

                                                                                              К этим перцам относится эта рекомендация из статьи: НЕ НАДО СПРАШИВАТЬ ТЕОРИЮ вне контекста практического опыта конкретного разработчика!

                                                                                              Вы хоть раз встречали такое в IT?

                                                                                              Да, встречал…

                                                                                              к тому же в IT работать придется.

                                                                                              Как Вы думаете откуда столько сырых, кривых и недоработанных продуктов например в гос секторе?

                                                                                              это реалии западной крупной компании

                                                                                              К сожалению в крупных западных не работал, пишу о реалиях СНГ.

                                                                                              А лучше, чтобы все вникали.

                                                                                              Не многие на это способны, поэтому есть всякие UX дизайнеры например. Все люди думают по разному поэтому лучше чтобы был более компетентный сотрудник, который будет давать четкие указания, тогда будет меньше брака. А дай волю программисту, он сделает что то вроде «Что введете, то и будет, хоть 10».

                                                                                              быстро поймет, что с программой что-то не так

                                                                                              Я не спорю что было бы хорошо. Но большинству программистов, которых Я знаю, не интересно вникать в дебри, при этом это не мешает им писать хороший рабочий код.

                                                                                              а сколько должно быть людей-посредников между таксистом и пассажиром?

                                                                                              Можно и без них, но один бы не помешал (диспетчер).
                                                                                              0
                                                                                              Вы на столько у верены в сво ей не отразимости, что позволяете себе оскорбления широкого круга людей?
                                                                                                0
                                                                                                Я не оскорблял, а констатировал свой опыт общения.
                                                                                                  +1
                                                                                                  «Если вокруг одни дегенераты»… Продолжить, или по контексту догадаетесь?
                                                                                                  Мнение Петра о Павле обусловлено его субъективным опытом.
                                                                                                    0
                                                                                                    А Я утверждаю что все HR плохие? Вы читаете или берет слова из контекста за которые зацепился Ваш глаз?
                                                                                                0
                                                                                                Я считаю что между разработчиком и заказчиком обязательно должно быть промежуточное звено, а лучше 2 — те кто понимает заказчика и те кто понимает разработчика (типа product owner и scrum master).
                                                                                                Из моего опыта внедрения некоторого по на двух работах — чем меньше между пользователями зеньев, тем быстрее и адекватнее решаются задачи. Именно поэтому на текущем месте работы я (вместо внедряторов от разрабов) опрашивал своих пользователей и ставил задачи, а когда у разработчиков начались проблемы с инженерами по внедрению и нам дали выход на разраба напрямую — у нас задачи стали решаться быстрее, правильнее (меньше ошибок) и сложнее по уровню, чем до этого получалось пропихнуть…
                                                                                                  0
                                                                                                  Тут Вы играете роль более компетентного промежуточного звена…
                                                                                                  Нельзя юзверям к разрабам доступ давать…
                                                                                                    0
                                                                                                    Плох тот разработчик, который не умеет общаться с пользователями. Компетенциям грош цена без коммуникативного навыка.
                                                                                                    Самовлюблённые фуллстэки на проверку зачастую оказываются закомплексованными профанами, ставащими энциклопедическое выше человеческого. Где-то тут было про virtual на собеседовании, от не-эйчара, как раз этот случай.
                                                                                                      0
                                                                                                      Плох тот разработчик, который не умеет общаться с пользователями

                                                                                                      Вот тут Я в корне не согласен. Большинство моих друзей программистов — интроверты и чуть ли не социопаты. Но при этом приложения пишут лучше, чем кто бы то ни было.

                                                                                                      Самовлюблённые фуллстэки на проверку зачастую оказываются закомплексованными профанами

                                                                                                      Цитируя Ваши же слова: Вы на столько у верены в сво ей не отразимости, что позволяете себе оскорбления широкого круга людей?
                                                                                                        +1
                                                                                                        Большинство моих друзей программистов — интроверты и чуть ли не социопаты.

                                                                                                        Интроверсия не подразумевает неспособность и неумение общаться. Социопаты же и вовсе в силу возможности оценивать коммуникацию напрямую, а не через призму рефлексии, в общении добиваются поразительных результатов.
                                                                                                        0
                                                                                                        Плох тот продавец, который не может сделать свой товар. Глупо? А почему тогда разработчик должен выолнять несвойственные задачи.
                                                                                                        Вы выступаете или в роли буфера между разработчиком и «я хочу тут синенькую кнопочку» или сами являетесь генератором такого. Вам кажется что это хорошо, но это не обязательно так.

                                                                                                        > ставащими энциклопедическое выше человеческого.

                                                                                                        Энцеклопедическое — решение проблемы, а что такое «человеческое»? Жилетку пользователю подставить? Судя по всему у вас просто сэкономили на постановщике задач. Коммуникативным навыкам без компетенции цена не грош, к сожалению, на них зачастую выезжают те, кто не умеет ничего (ещё и горядся этим, считая решающих проблемы ничтожными).
                                                                                                          0
                                                                                                          Коммуникативным навыкам без компетенции цена грош


                                                                                                          Телевизор и «уважаемые люди», мелькающие в нем, всем своим видом говорят противоположное
                                                                                                            0
                                                                                                            Они как раз компетентны. Просто их компетенция лежит в другой области.
                                                                                                          0
                                                                                                          лох тот разработчик, который не умеет общаться с пользователями.


                                                                                                          РМ, Бизнес аналитик — это не про нас, так?
                                                                                                          0
                                                                                                          Тут палка о двух концах.
                                                                                                          С одной стороны пользователи имеющие доступ к разработчикам своими требованиями и претензиями превращают жизнь в ад.
                                                                                                          А с другой стороны разработчики, которые не имеют представления для кого они пишут очень быстро отрываются от реальности и перестают понимать ради чего они пишут код.
                                                                                                            0
                                                                                                            Поэтому со стороны пользователей по хорошему иметь того, кто будет изучать их требования, понимать кого это затронет, утрясать, компилировать и выдавать общую задачу, причем еще чаще всего совсем не ту, которую просили изначально, так как она подразумевала просто сделать удобнее мучения, а задача будет — добавить кнопку «сделать правильно», которая вообще не потребует этих мучений.
                                                                                                            Проблемы начинаются, когда эту задачу начинают трактовать на свой лад все последующие звенья без обратной связи с ее поставившим.
                                                                                                      0
                                                                                                      Наконец, здравый посыл.

                                                                                                      Почему-то считается, что в hr-рных делах любой итшник разбирается лучше, чем любой hr-щик.
                                                                                                      Это не означает, что нет бездарных hr-щиков. Они есть, как и есть бездарные итшники, и любые другие бездарные… (вставить по вкусу).

                                                                                                      Плюс, все забывают, что цели у всех разные. Соответственно и действуют по разному.
                                                                                                      Не всегда же любой код нужно писать строго по Макконеллу.