Теперь хороших разрабов меряют по просмотрам и подписчикам. Плохо ли это?

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


О современных собеседованиях


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


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


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


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


Тут, должно быть, мне возразят, что целью собеседования с задачками в первую очередь является проверка мышления кандидата. Да, так и есть, но далеко не все это понимают. Многие разработчики, которых HR отправляют собеседовать соискателей, об этом забывают. И тогда собеседование превращается в скучный монолог кандидата, который пытается что-то решить. Потом решение фотографируется и оно становится аргументом за или против. Правильно ли это? Нет. Я считаю, что задачи давать можно только несложные и надо помогать кандидату. Не надо рассказывать человеку все решение, но наталкивать его на правильные мысли нужно. Ведь мы разрабатываем софт не в одиночку. Разработка уже давно стала командной работой. Так почему же я до сих пор вижу разработчиков, которые на собеседовании ничего кроме условия задачки не говорят?


Я бы еще раз хотел заострить внимание: собеседования с задачками — это нормально, но только если эти задачки простые и ее решение превращается в диалог собеседующего и собеседуемого. Главное здесь — проверить, как кандидат мыслит. Как он подходит к решению задачи. Вот что важно, а не то, решит ли он эту задачу или нет. Вы же не ищете разработчиков, единственным умением которых является решение задачек с LeetCode?


Хард и софт скиллы


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


Одиночная разработка вымирает. В агониях дергаются только фрилансеры-разработчики сайтов. Любой серьезный продукт требует команду разработчиков, а часто и не одну. Поэтому как раз крутые интроверты скоро вымрут из IT, а нам придется работать с тем, что осталось.


О хайповых технологиях


Единственный поинт, в котором я соглашусь с автором статьи, но и тут не до конца. Да, проблема с посредственными и распиаренными технологиями есть. Но и тут важно заметить, что пусть лучше все пользуются чем-то одним. Единственное решение наверняка рано или поздно станет самым проработанным. Хотя бы потому, что у его разработчиков есть на это деньги и ресурсы. А иначе мы получим много решений, которые хорошо начинали, но по ходу разработки приобрели различные проблемы. Такое состояние дел только побуждает разработку "14-го стандарта". И так далее. Давайте все же все пользоваться одним решением. Когда-нибудь его проблемы будут решены, чего не скажешь о каждом из 10 разных решений с единичными пользователями.

Поделиться публикацией

Комментарии 50

    +9
    Вы ошибаетесь, считая экстра/интровертность бинарным параметром и, соответственно, рассматривая только крайности
      +4
      Соглашусь с Вами. Однако это и не пост про интровертов в мире ИТ. Я скорее хотел показать трудности, которые ждут необщительных людей в командной разработке.
        +4
        Ваши примеры не очень хороши.
        Общительный человек может точно так же сидеть неделю, поскольку он не хочет показать, что это сложно для него либо ему не приходит в голову, что в данном случае надо спросить.
          +2
          Соглашусь. Но все же речь идет не про конкретного человека и задачу, а про какие-то более общие закономерности.
      +3
      Сколько из нас каждый день на работе пишет красно-черные деревья или использует виртуальное наследование (это просто примеры, давайте, пожалуйста, не будем обсуждать в комментариях их полезность)?

      Все правильно вы говорите. И при этом — все совсем неправильно. :)

      Тут дело не в самих вопросах, а в квалификации и целях собеседующего.

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

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

      АДД: Чуть не забыл: иногда собеседования проводятся по чисто политическим причинам, а на самом деле фирма никого брать не собирается. Например, для отчета перед акционерами фирма изображает «активный набор разработчиков» — вакансии публикует, собеседования проводит, — но при этом все прекрасно понимают, что проектов для новых разрабов нет. В таких случаях собеседования проводят максимально формально, всем присылают отлупы (или молчат, как обычно), и никакого внятного отклика на недоуменные вопросы не дают.
        0
        Совершенно верно. Я лишь хотел подчеркнуть, что начальные данные кандидата редко бывают критически важны. Возможно я ошибаюсь, но мне кажется, что редко можно найти свободного кандидата, обладающего глубокими познаниями именно в нужной области. С другой стороны, многие ребята готовы достаточно быстро подучить необходимое.
          +1
          Я лишь хотел подчеркнуть, что начальные данные кандидата редко бывают критически важны.

          «Редко»? Я бы не сказал.
          Когда берут интерна на стажировку — это одно, а вот когда берут конкретного специалиста на конкретный проект — это совсем другое. В первом случае главное — чтобы соображал, учился и не мешал взрослым дядям работать, а вот во втором возможны разные варианты. :) У опытных спецов бывают удивительные закидоны и пробелы в знаниях. Работодателю желательно, чтобы специалист сразу начал знакомиться с проектом, а не тратил недели и месяцы на пустые споры с коллегами и изучение основ.

            +2
            Тут как посмотреть. Работодателю вообще желательно, чтобы работник сразу начинал работать. Желательно, чтобы при этом уже все знал и умел. И желательно еще делал это бесплатно.
            Мы же понимаем, что так не бывает. У любой задачи своя специфика, и, если знания об области в целом кандидат иметь должен, то с этой спецификой он знаком едва ли. А если и знаком, то скорее всего переходит к Вам от Вашего прямого конкурента.
              0
              У любой задачи своя специфика, и, если знания об области в целом кандидат иметь должен, то с этой спецификой он знаком едва ли.

              Это общие слова.
              Поддамся искушению и изреку банальщину: у каждого опытного разработчика свой, уникальный опыт. Так вот, этот опыт — вовсе не обязательно что-то хорошее. :)
              Я встречал людей с удивительными деформациями. Например, видел разработчика С++ с опытом 10+ лет — при этом дяденька в упор не понимал, что такое объектные файлы и линковка. Ну вот не встречался он с ними никогда — все делала за него среда разработки.
              Или видел товарища с очень, хм, своеобразными представлениями о том, как работает многопоточная программа. Разгадка проста: он работал на какой-то очень специфичной железяке с кучей аппаратных подпорок, которые умели даже дедлоки исправлять.
              Еще один гражданин вырос на языке С. В результате на С++ он писал так же, как на С — с голыми указателями, с вызовами qsort(), malloc(), bsearch() и т.п.
              Еще были кандидаты, лет по десять работавшие с какими-то самописными языками программирования.

              А самое главное — опытные граждане бывают как нормальные, так и беспощадные. Нормальные — это те, кто понимает, что не правы, и готовы учиться. Беспощадные — это те, кто уверен, что они правы, а окружающие — просто докучливые идиоты, лезущие с дурацкими поучениями.
                0
                Например, видел разработчика С++ с опытом 10+ лет — при этом дяденька в упор не понимал, что такое объектные файлы и линковка.
                Хмм. А под капот ему не интересно было залезть?
                  0
                  Да он как-то вообще не задумывался, что там под капотом.
                    0
                    Не знаю как так можно, мне было интересно даже до микросхем добраться.
          +2
          понимает биг-О нотацию

          Мне вот всегда был интересен феномен преклонения перед владением О-большим. Сколько раз в своей разработческой жизни вам приходилось мыслить понятиями О-большое?
          Ну вот прям чтоб сидеть и рассуждать, "тут O(n^2), как бы мне так O(n*log(n)) получить!?"

            0
            Десятки раз
              0

              Можно пример ситуации?

                +1
                Каждый раз, когда проектирую что-то, у чего есть коллекция, прикидываю, как её будут использовать. И в зависимости от предполагаемого использования выбираю тип коллекции. Например, если у меня есть коллекция, по которой постоянно нужно будет что-то искать, я выберу словарь, а не эрэйлист. И да, так все делают, и да, не все из них знакомы с терминологией О. Суть в том, что неплохо, когда разраб понимает, что работает быстро, а что медленно.
                  0

                  Именно об этом я и говорил. Понимать, что for(i=1;i<n;i++){for(j=1;j<n;j++){...}}, хуже, чем for(i=1;i<n;i++){for(j=i;j<n;j++){...}} и оба они хуже, чем for(i=1;i<n;i++){...} — это важно (и элементарно), а вот конкретно знать, что из них "по науке" обозначается O(n^2), что O(n log n), а что O(n), а тем паче насиловать этим на собеседовании — совсем излишне для подавляющего большинства задач.


                  Знать доказательство теоремы Пифагора — это здорово и круто, но нафиг не нужно для написания калькулятора по расчету гипотенузы.

                    +3
                    Но ведь в доке например дотнетных коллекций не написано, медленно там или быстро. Там написано, какое О.
                      +1

                      Хм… Уели — даже возразить нечего :)

                        0
                        Вообще-то сакральное знание про О-большое нужно в основном именно при работе с контейнерами всякими. В С++ стандарт тоже регламентирует сложность операций с различными контейнерами в терминах О.
                      +1
                      конкретно знать, что из них "по науке" обозначается...

                      Особенно учитывая, что алгоритм со сложностью O(n log n) в приведённых примерах отсутствует :)

                        –1

                        Я все ждал, заметит ли кто ;)

                0
                Сколько раз в своей разработческой жизни вам приходилось мыслить понятиями О-большое?

                Довольно часто. Требования у нас такие — чтобы все быстро работало.
                Понятно, что в процессе разработки прям на пальцах никто эти О не считает, но у нас — пир-ревью. И вот на ревью как раз приходится прибегать к О-большому для того, чтобы объяснить, почему выбранное решение кажется тебе не очень эффективным.
                  0
                  Я буквально вчера исправлял косяк в сервисе, где иногда возникали времена ответа в десятки секунд. В узком месте обнаружился цикл по вершинам некого графа, на каждой из итераций которого обходились все рёбра.

                  Фоновые знания про соотношение числа вершин и числа рёбер, помогли мне понять, что стоимость каждого обхода по рёбрам — O(n^2), где n — это число вершин.

                  А снаружи всё выглядело как:
                  for node in nodes:
                      ....
                      for edge in edges:
                          ....
                  


                  И ведь по форме кажется, что должно быть O(n^2), ан нет — O(n^3). Вынос обхода рёбер из цикла помог получить честное O(n^2), что решило нашу проблему.
                +2
                Неужели лучше чтобы ваш напарник неделю сидел и разбирался в каком-нибудь классе или функции из общей базы кода, чем если бы он подошел к его разработчику и спросил его, как им правильно пользоваться? Тут же можно сказать, что крутой интроверт тоже не понятно как отреагирует на вопросы к нему.


                Достали сферические ситуации в вакууме. В аврал — не лучше, если есть время — лучше.

                Крутой интроверт может на первый вопрос ответить, а на 20-й — послать. Или надо на все отвечать?
                  +1
                  К сожалению это — не сферические ситуации в вакууме. Это краткое и общее описание ситуаций, в которых я был сам. И меня же потом спрашивали, почему я просто не спросил. При этом хочу заметить, что я себя считаю экстравертом, однако будучи стажером стеснялся трогать страшных дядек синьоров.
                    +2
                    Извините, наверное я не совсем точно выразился. Под «сферическими» я имел в виду без контекста, без него обсуждать эти вещи, имхо, бессмысленно.

                    Если без разбора отвечать на всё — можно получить иждевенца.
                      0
                      С таким комментарием соглашусь.
                      Тут уже важно, чтобы человек, которого спрашивают, соблюдал некий баланс. Важные вопросы и подводные камни освещать нужно. Очевидные же вещи лучше написать единожды в документации или FAQ и отсылать вопрошающих туда.
                      С другой стороны мысль о том, что тебя могут спросить о твоем коде дисциплинирует, а если к Вам сыпятся тонны вопросов по Вашему коду, наверное это повод задуматься.
                  +4
                  Правда ли, что лучше нанять хорошего интроверта, чем средненького экстраверта

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

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

                      Ну не знаю. Я сам 100%-ый интроверт. Но с удовольствием распространяю знания, т.к. это психологически повышает собственную самооценку и значимость, нравится слушать когда говорят «какой ты умный». Но спрашивать кого-то — это уже удар по самолюбию, ожидаешь подначиваний «да ты такой ерунды даже не знаешь».
                        0
                        Один пример это все еще не закономерность. У любого правила бывают исключения.
                        В любом случае, я нисколько не хотел сказать, что интровертам в IT не место, лишь показать какие-то проблемы, с которыми, на мой взгляд, они могут столкнуться.
                        Должно быть я поспешил с этой частью статьи, учитывая, что почти все комментарии обращены именно к ней. Если это так, то прошу меня простить, я нисколько не хотел задеть ничьи чувства.
                          +4
                          Ну не знаю. Я сам 100%-ый интроверт. Но с удовольствием распространяю знания, т.к. это психологически повышает собственную самооценку и значимость, нравится слушать когда говорят «какой ты умный».

                          Это просто стадия =). В общем и целом стадии выглядят примерно так:
                          1. Ньюб — ничего не знаю, ничего не умею — учусь
                          2. «Опытный» (стаж примерно 3 года). Знаю кучу современных тулов и технологий, работаю быстро, усердно и старательно. Часто косячу по неопытности, но старшие товарищи прислушиваются к моему мнению и с удовольствием помогают. Восходящая звезда и надежда своей компании.
                          3. Реально опытный — 7+ лет. Идите на фиг — у меня нет на вас времени.
                          4. Гуру. 10+. Хочу нести знания в мир. Писать статьи, читать лекции, выступать на конференциях. Ведь я столько всего знаю.
                          5. 15+. Отстаньте от меня все — достали.
                          6. 20+. О какой забавный юноша (из пункта 2). Вроде соображает, много думает о себе правда и с каждой новой погремушкой носится как с писаной торбой, ну да ладно — стоит его покачать, глядишь толк выйдет.
                            0
                            Не в бровь, а в глаз!
                      +1
                      Спасибо автору за хороший язык. Некоторые статьи на эту тему были написаны настолько «своеобразно», что уже боязно стало читать. Оказывается и на эту тему можно говорить нормальным языком.
                        +2
                        fillpackart и binpord говорят о разном. Ни кто не говорит что на собеседовании надо давать олимпиадные задачки, fillpackart как раз о том и сожалеет что о собственно работе — проектировании кода, подходах к решению задач с ним не разговаривают, говорят о технологиях вообще, а не о том как эти технологии лучше применять.
                        По поводу давайте писать на одних технологиях, не соглашусь, ситуации бывают разные и разные инструменты могут показать разную эффективность. Жизнь не стоит на месте ни когда не будет инструментов монополистов, всегда будет выбор.
                        Про то что программисты одиночки вымрут вдвойне не соглашусь.
                        binpord видимо давно не работал в мелком бизнесе. Я последние 7 лет работаю в фирмах где даже если программистов больше пары человек, то у каждого своя тема и пилит он её почти в одного, разделение работы по специализациям это нормально.
                        Кто то пишет фронт для браузера, кто то для андроида, я пишу бэкэнд на C#/PHP, что нам вместе обсуждать? АПИ спроектировали и разошлись по углам. Обсуждают пусть бизнес аналитики с дизайнерами и заказчиками, с техподдержкой. У программистов задача своя — из мечты сделать реальность, и что бы не ломалось, а если ломается, то что бы чинилось, раньше чем кто то прочухает.
                          0

                          Как фронтенд-программист я с вами не соглашусь: довольно часто приходится вмешиваться в работу аналитиков и дизайнеров по причине непродуманности отдельных моментов или неких технических ограничений. Считаю, что это нормально. Один человек не может проработать и удержать в голове все нюансы, а программист — такой же участник команды. Если он видит проблемы, с которыми может столкнуться то или иное решение или есть более красивый способ решить задачу, то нужно его тоже обсудить. Подход «моя хата с краю» может привести к плачевным последствиям для задачи и проекта в целом.

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

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

                          +3
                          > крутые интроверты скоро вымрут из IT
                          Да неужели. И кто эти IT тогда будет, собственно, создавать? Экстраверты, способные только языком чесать? ;)
                            +2

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

                            +3
                            Одиночная разработка вымирает.

                            Вообще нет. Одиночная разработка в одиночку и в команде (да, именно), только набирает обороты. Почему? Удалёнка. Удалёнка это всегда одиночная разработка. Да, мы иногда созваниваемся/списываемся, новички спрашивают совета и просят о помощи. Но это одиночная разработка. Есть исключение в виде парного программирования, но это сильно реже. Мне не нужно для этого быть весельчаком и заводилой, толкать смешные тосты и играть на гитаре в офисе. Я интроверт-одиночка и прекрасно себя чувствую в команде на удалённой работе.

                              +2

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

                                +2
                                Это потому, что Аджил рулит. А Аджил — это вотчина экстравертов. И умение плясать в хороводе вместе со скрам-мастером и рисовать розовыми фломастерами щщастье называется умением работать в команде. Они искренне не понимают как можно это не любить.

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

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

                                  +1

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

                                    0
                                    И умение плясать в хороводе вместе со скрам-мастером и рисовать розовыми фломастерами щщастье называется умением работать в команде.

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

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

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


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

                                    0

                                    Кто в рабочее время про рыбалку, это не экстраверты, а балаболы и таких лучше изолировать от коллектива — производительность труда вырастет.

                                      0

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

                                    0
                                    «Хороших разрабов меряют по просмотрам»

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

                                    Но, с другой стороны, это, возможно, не так уж и плохо. Успех проектов всегда определялся не только профессионализмом, но и умением влиять на умы людей. Выбрав того, кто, например, талантлив вполовину от лучшего, но имеет аудиторию в 10 раз больше, чем у него — получит в итоге в 5 раз больше пользователей (подписчиков, избирателей).

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое